| ネットワーク WG Request for Comments： 2316 分類： 情報提供 |
AT&T Labs Research S. Bellovin 1998年 4月 |
IAB セキュリティ アーキテクチャ ワークショップの報告
（Report of the IAB Security Architecture Workshop）
1. このメモの位置づけ English
このメモは、インターネットコミュニティのために情報提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布に制限はありません。
2. 著作権表記 English
Copyright (C) The Internet Society (1998). All Rights Reserved.
3. 要旨 English
1997年 3月の 3日から 5日まで、IAB は、ニュージャージー州のマリー ヒルにある Bell 研究所において「セキュリティ アーキテクチャ ワークショップ」を開催しました。我々は、アーキテクチャの核となるセキュリティコンポーネントを認識しました。そして、書かれる必要がある文書を 、いくつか特定しました。最も重要なことは、「セキュリティはオプションではなく、最初から設計の中に入っている必要があること」について合意したことです。
3.1. 用語の用法
この文書中のキーワード、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および"OPTIONAL"は、 RFC 2119 に記述されたように解釈されるべき用語です。
4. 動機 English
IAB は、1997年 3月の 3日から 5日まで、ニュージャージー州のマリー ヒルにある Bell 研究所において「セキュリティ アーキテクチャ ワークショップ」を開催しました。その究極の目的は、「インターネットにおけるセキュリティアーキテクチャを設計すること」でした。より具体的には、どのようなセキュリティツールやプロトコルが存在しているのか、あるいは開発中であるのか、どういう場合にそれらは有用であるのか、また、どのような領域に適切なセキュリティツールが欠けているのかを理解することを 我々は望んだのです。さらに、我々は、プロトコル設計者のための有用なガイダンスを提供することを望みました。つまり、「セキュリティの論点は、このメモでは検討されていません。」という文章を、将来の RFC からなくすことを望むのであれば、我々は、許容できる分析についての指針を提供しなければなりません。参加者数は、24人でした。（参加者名は、補遺 A にあります。）おそらく、このようなグループとしては驚くほどのこともないのでしょうが、圧倒的大多数が、ミーティングルームから、自身のホームサイトへ接続する際に、ある種の暗号技術を 利用していました。しかし、インターネットの他の状況では、決してこうも良いとはいえません。暗号技術を使っている人は、たとえ使うべきときでも、ほとんどいません。
問題は、攻撃に関する件数が増加していることにあります。通常の数少ないエリートハッカー達（新しいセキュリティホールを見つける者）とは別に、そこら中に攻撃スクリプトが仕掛けられています。（「ここをクリックして、このシステムを攻撃してください。」）さらに、攻撃者たちは、賢くなりました。大学のマシンを任意に攻撃するのではなく、ルーター、ハイレベルのネームサーバーなどのような、インターネットのインフラストラクチャを標的とする輩が増えています。
この問題は、組織的な怠慢を併せ持っています。ユーザやシステム管理者は、「魔法のようなセキュリティ」を望みます。（ユーザやシステム管理者は、それがセキュアであるか否かに関わらず、さらには、セキュアになり得るかに関わらず、セキュアになるものであれば何でも望みます。 ）
5. 全般的哲学 English
我々は、「一般に エンド to エンドのセキュリティが望ましい」と結論づけました。それゆえ、E メールには IPsec 層でリレーするよりも、PGP もしくは S/MIME のようなものを使用すべきです。一般に、インフラストラクチャのセキュリティに依存するのは、よい考え方とはいえません。インフラストラクチャも攻撃されているのです。ファイアウォールに保護されたイントラネットでさえ、倒される可能性があります。理想的には、インフラストラクチャは、可用性（ availability ）を提供すべきです。攻撃の最中に、インフラストラクチャ上で不合理な要求をしないようにすることは、個々のプロトコルの責任です。
6. IETF の組織構造 English
我々のセキュリティ問題には、IETF がもつ組織構造の問題が加わります。（もしくは、場合によっては、それが欠けていることもあります。）意図したことですが、我々はボランティアの組織体です。誰がセキュリティの作業をする必要があるのでしょうか？他のプロトコル設計者たちでしょうか？しばしば、彼らには時間がありませんし、興味も、それを行うための訓練も行なわれていません。セキュリティエリアのメンバーでしょうか？彼らが、その問題の領域に興味がなかったり、もしくは、彼ら自身が忙しい場合にはどうするのでしょうか？我々は、彼らに行うように命令することはできません。IETF が管理している範囲は、ワーキンググループ憲章の中で具体化されています。これらは、IESG と、各ワーキンググループの間の基本契約の中にあり、何が行なわれる予定で、どのようなスケジュールで行なわれるか、が記されています。IESG は、既存のワーキンググループで、新しい要求事項を一方的に押し付けることができるのでしょうか？数年以上にわたって動作してきた、プロトコルの基礎的な構造に、本質的な変更をせずにはセキュリティ機能を追加することができない場合にはどうするのでしょうか？
最後に、IPsec は、何らかの形でセキュリティ問題を解決するか、という未来予測の問題があります。IPsec は、解決しないでしょう。正確には、できないのです。IPsec は、トランスポート層において、すばらしいパケットの保護を提供します。しかし、個々のホストに搭載するのは困難ですし、再転送されるオブジェクト（つまり、E メールメッセージ）は保護しません。認可（authorization）の論点に対応するものでもありませんし、対象外の資源の改ざんを防ぐことなどはできません。
7. 書かれるべき文書 English
我々は、共同で、いくつかの書かれるべき文書について決定しました。
- 攻撃の分類
- プロトコルを攻撃から守るために、当然ながら、起こりうる攻撃の種類を知る必要があります。詳細仕様はプロトコルによって異なりますが、数多くの一般的な分類を行うことができます。
- 実装上のヒントと落とし穴
- たとえ、あるプロトコルがうまくできていても、そのプロトコルが正しくないやり方で実装された場合には、それを動作させているホストが弱点をもつことは、ありえることです。様々なよくあるエラーは、最善の設計をだめにする可能性があり、現にそのような例もあります。
- ファイアウォールの論点
- ファイアウォールは、普及した防御であるとともに、インターネット上の広く普及した「こぶ」です。それにもかかわらず、ファイアウォールは、すぐにはなくなりそうにありません。ファイアウォールには、配置する際に考慮すべき長所と短所の両方があります。さらに、プロトコルには、不必要にファイアウォールと相性の悪い性格をもったものがあります。そのような実践は避ける必要があります。
- ワークショップの報告
- 本書が、該当します。
8. ワーキンググループ憲章 English
ワーキンググループ憲章中の実際の文章は、次のように、いたって簡潔になります。
実際の憲章の文章では、IESG によって命令され、執行されたポリシーが表現され、度々、憲章ごとに変更される可能性があります。しかし、これは RFC に含めるのが最適です、という文章を文書中にあることを確認するように参照し、要求することが重要であることに変わりありません。
9. RFC 中の「セキュリティについての考慮事項（Security Considerations）」を書く際のガイドライン English
「脅威」とは、その定義により、動機を持った潜在的な敵が攻撃できる弱点のことをいいます。CERT アドバイザリは、脅威の対象の知識について、極めて有用です。それゆえ、CERT アドバイザリは、脅威の存在証明の代表ですが、脅威分析ではありません。要点は、どのような攻撃がありうるか（潜在的な攻撃者の「可能性（capabilities）」）を断定することと、攻撃に対する防御を定式化すること、ないし、ある環境ではその攻撃は非現実的であることや、その環境でそのプロトコルの使用制限をすべきことについての説得力のある説明を行うことにあります。推奨されるガイドライン：
- すべての RFC は、・・・
- そのプロトコル、もしくは、それが仕様を決める手続きにおいて、十分にセキュリティに対応しなければなりません（MUST）。RFC は、「敵」にそのデータをを与えており、その友達に配布して、その意図どおりのやり方で使用することをお願いしていることを考慮しなければなりません （MUST）。その状況に依拠する危険の改善について、考慮されねばなりません（MUST）。
- そのプロトコルが弱点を持つ脅威をリストする「忠実義務（due diligence）」を果たさなければなりません（MUST）。法的な用語の使用は、法的な義務を意味するものではなく、その分析に適用されることが期待される責任のレベルを意味するものです。この検討は、その文書全体にわたって、もしくは「セキュリティ関連の考慮事項」の項の中で行なわれます。その文書全体にわたる場合には、「セキュリティ関連の考慮事項」の項の中で要約され、参照されなければなりません（MUST）。
- 下記のいずれの脅威であるかを検討しなければなりません（MUST） 。
- プロトコルメカニズムによって改善させるもの
（例： SYN 攻撃は、SYN 攻撃の最中、ランダムにセッションをドロップ させる上手なコードによって改善させます。）
- 外部メカニズムを利用することによって改善させるもの
（例： IPSEC ESP によって提供される TCP データの秘匿性）
- 見当違いのもの
（「多くの場合、MIB は、それ自体はセキュリティリスクではありません。SNMP セキュリティが意図的に運用されている場合、システムの設定を変更するための MIB の使用は、ツールであって、 脅威ではありません。SNMP セキュリティの脅威分析については、RFC ZZZZ をご覧ください。」）
- プロトコルによって対応されるものではないもの
これについては、適用可能性についての表明をすることになります。
（「このプロトコルは、この攻撃の対象となる環境においては使用されるべきではありません。」）
10. 核となるセキュリティメカニズム English
今日、様々なセキュリティメカニズムが存在します。必ずしもすべてが、うまく設計されているわけではありませんし、すべてがあらゆる目的に適合するわけではありません。ワークショップのメンバーは「核」として数多くのプロトコルの設計にあたってきました。それらの中に、あなたのプロトコルへの要求に適合するプロパティをもつのがあれば、このようなプロトコルは、選択的に使用されるべきです。下記のものが、核として設計されてきました。
- IPsec [RFC 1825]
- 基本的なホスト間のセキュリティメカニズムです。アドレスに基づいた保護が使用されている場合には、いつでも使用するのが適切であるといえます。これには rsh や rlogin のようなプログラムも含まれます。プラットフォームがユーザに基づいた鍵をサポートしている場合、この方法が適用されることでしょう。
- IPsec で使用されている技術として、HMAC [RFC 2104] は、より一般的に有用です。暗号技術的な認証が必要で、暗号化は不要な場合で、かつ、IPsec が適用でない場合、HMAC が使用されるべきです。
- ISAKMP/Oakley [ISAKMP drafts]
- IPsec 用の基本的な鍵交渉（ negotiation ）プロトコルです。このように、これは IPsec が使用されている場合には採用されるべきです。これは、適切な「 domain of interpretation 」文書とともに、他のプロトコル用に、一組の鍵を交渉（ negotiate ）するのに使用されるべきです。
- DNSsec [RFC 2065]
- DNS を防御することにおいてのみ重要であるのではありません。（能動的な攻撃をしかけるのに、キャッシュの改ざんが、最も容易なやり方です。）IPsec が使われている多くの場合においても要求されるものです。
- Security/Multipart [RFC 1847]
- MIME でカプセル化された E メールに、セキュアにしたセクションを追加するための好ましいやり方です。
- DNS においてキーに署名する
- 既に述べたように、「DNS のレコード自体が保護されなければならない」という合意が広くなされています。キーレコードは、それ自体、署名される必要があり、有効な認証（ certificates ）がなされるようにしなければならないという合意は、それほどではありませんでした。とはいえ、これはインターネット認証（ certificate ）について、将来が約束された方向性のひとつです。
- X.509v3
- 明らかに認証（certificate）インフラストラクチャのためのもうひとつの選択肢です。しかし、繰り返しになりますが、この点については、強い合意はありませんでした。
- TLS [TLS draft]
- トランスポート層でのセキュリティのための好ましい選択肢であるとする人もいました。しかし、この点については共通認識はありませんでした。TLS は、IPsec よりも OS（オペレーティングシステム）に干渉しません。さらに、このやり方の方が、詳細な保護を提供するのが容易です。
プロトコルには、「有用ではあるが、核ではないもの」として設計されたものがあります。これらは、一般的とはいいきれないものであったり、新しすぎたり、もしくは、核となるプロトコルと本質的には重複しているものです。このようなものとして、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] があります。（「有用でない」という用語は、それらが正しくないという意味ではなく、また、それらに重要な情報が欠けているという意味でもありません。しかし、それらは、我々が現在、使用を薦めているようなプロトコルを記述していません。）
ひとつのセキュリティメカニズムだけが、許容できないものと考えられました。それは平文のパスワードです。つまり、暗号化されていないチャネル上で送られるパスワードに依存するプロトコルは許容できないということです。
11. 不備な部分 English
ワークショップの参加者は 3つの重要な不備な部分を認識しました。：（「オブジェクトセキュリティ」、「セキュア E メール」および「経路セキュリティ」）
「オブジェクトセキュリティ」とは、トランスポートとは独立に、個々のデータオブジェクトを保護することをいいます。セキュア DNS のようなものが既にありますが、我々が必要としているのは、より一般的なスキームです。MIME は、部分的に候補となるオブジェトフレームワークです。それは、web と E メールという 2つの最も広く採用・使用されているアプリケーションの核心部分であるからです。しかし、E メールをセキュアにすることは問題をかかえていますし、web はまだ始まったばかりです。
「セキュア Eメール」については、現在も、そして以前から極めて強い要求があります。セキュア E メールプロトコルを標準化しようとした 2つの試み（PEM と MOSS）は、コミュニティに受け入れられませんでした。一方、第 3 のプロトコル（ PGP ）が世界中でデファクトスタンダードになりました。第 4 のプロトコル、業界標準（S/MIME）が、人気を集めています。これら、後の 2 つとも、インターネット標準化過程に入りました。
「経路セキュリティ」は、最近になって極めて強く要求されるようになりました。攻撃者が巧妙になっており、様々な攻撃用ツールキットが巧妙な攻撃の件数を増加させました。この作業は、特に複雑です。それは、最高のパフォーマンスの要求と、セキュリティ向上の目標は、相容れないからです。セキュリティの向上は、ルーターの性能向上に活用できるであろう資源を奪ってしまうのです。
12. セキュリティについての考慮事項 English
セキュリティは、お菓子のクッキーの型抜きのようなものではありませんし、そうであるはずがありません。プロトコルの上に撒くとセキュアにしてくれるような妖精の魔法の粉はありません。それぞれのプロトコルは、どのような弱点があるか、どのようなリスクを導くか、どのような緩和手段をとることができるか、および残るリスクは何かを判定するために、個々に解析されなければなりません。
13. 謝辞 English
14. 参考文献 English
- [RFC 1825]
- Atkinson, R.,
「インターネットプロトコルのためのセキュリティアーキテクチャ （Security Architecture for the Internet Protocol）」,
RFC 1825, 1995年 8月.
- [RFC 2104]
- Krawcyzk, H., Bellare, M., and R. Canett,
「HMAC： メッセージ認証のための鍵付ハッシング (HMAC: Keyed-Hashing for Message Authentication)」,
RFC 2104, 1997年 2月.
- [ISAKMP drafts]
作業中。RFC 2408
- [RFC 2065]
- Eastlake, D., and C. Kaufman,
「DNS セキュリティ拡張(Domain Name System Security Extensions)」,
RFC 2065(English), 1997年 1月.
- [RFC 1847]
- Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847(English), 1995年10月.
- [TLS draft]
- Dierks, T., and C. Allen,
"The TLS Protocol Version 1.0",作業中。RFC 2246
- [RFC 1421]
- Linn, J.,
"Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures",
RFC 1421, 1993年 2月.
- [RFC 1422]
- Kent, S.,
"Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management",
RFC 1422, 1993年 2月.
- [RFC 1423]
- Balenson, D.,
"Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers",
RFC 1423, 1993年 2月.
- [RFC 1424]
- Kaliski, B.
"Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services",
RFC 1424, 1993年 2月.
- [RFC 1848]
- Crocker, S., Freed, N., Galvin, J. and S. Murphy,
"MIME Object Security Services",
RFC 1848, 1995年10月.
| 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 |
補遺 B. 著者についての情報
電話： (973) 360-8656
EMail： bellovin＠acm.org
翻訳者についての情報
宮川 寧夫
情報処理振興事業協会
セキュリティ センターEMail： miyakawa＠ipa.go.jp
著作権表記全文
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.