ネットワーク WG
Request for Comments: 2316
分類: 情報提供
AT&T Labs Research
S. Bellovin
1998年 4月

English

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 は、・・・

 

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

この RFC の大部分は、Thomas Narten 氏によってまとめられた議事録に基づいています。また、Thomas Narten 氏の作業は、部分的に Erik Huizer 氏と John Richardson 氏と Bob Blakley 氏がまとめたノートに基づいています。

 

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月.

補遺 A. 参加者

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. 著者についての情報

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.