|
ネットワーク WG Request for Comments： 3365 BCP： 61 分類： ベストカレントプラクティス |
J. Schiller Massachusetts Institute of Technology 2002年8月 |
この文書は、 インターネットの「現時点における最善の実践（ベストカレントプラクティス)」を示すものであり、 改善するために議論と示唆を求めるものです。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (2002). All Rights Reserved.
IETF標準プロトコルが適切な強いセキュリティメカニズムを利用しなければならない(MUST)ことは、 IETFの総意(コンセンサス)です。 本書は、この信条についての経緯と理論を記述し、 この信条をベストカレントプラクティスとして確立するものです。
本書の目的は、 プロトコルについてのセキュリティ要件におけるIETFの総意(コンセンサス)を文書化するとともに、 その背景と動機について提供することにあります。
インターネットは、 独自に管理されたネットワークとホストから成るグローバルなネットワークです。 それゆえ、ネットワークの運用について、中央のオーソリティは、いません。 ネットワークを横断するセキュリティの提供について責任を負う中央のオーソリティも、いません。
セキュリティは、 「エンド to エンド」もしくは「ホスト to ホスト」に提供される必要があります。 IETFのセキュリティについての役割は、 アプリケーションがインターネット越しに利用される際に、 IETF標準プロトコルが適切なセキュリティを適用するのに必要不可欠な機能を持つようにすることです。 メカニズムを実装することが強制的であることは、 慎重を要するビジネスアプリケーションを防護するために、 適切なセキュリティを提供するはずです。
本書において、我々は、プロトコル標準を規定しませんが、MUST、MAY、 SHOULD等の用語を [RFC2119] によって定義されているように使います。
[RFC2828] は、 分かりやすいインターネットワークセキュリティサービスの一覧と、 その定義を提供しています。 ここに3つの肝要な定義があります。：
既述のように、インターネットは、元来、セキュリティを提供しません。 「セキュリティは環境自体によって提供されている」とユーザが信じているような、 ネットワーキング上、孤立したネットワークは、存在します。 一例は、 グローバルなインターネットに接続されていない会社のネットワークです。
「そのような孤立したネットワークにおいて運用するために設計されたプロトコルは、 環境によってセキュリティが提供されているので、 いかなるセキュリティサービスも要求しないであろう」と考える人がいることでしょう。
歴史は、「TCP/IPプロトコルスーツを使用して運用するアプリケーションは、 インターネット上で利用されるようになってしまう」ということを示しています。 これは真実であり、 本来のアプリケーションが「広域」インターネット環境において利用されることが想定されていなかった場合においてもいえます。 アプリケーションがセキュリティを提供するように設計されていない場合、 そのアプリケーションのユーザは、 それらは攻撃に対して脆弱であることを発見することでしょう。
IETFは、いくつかのセキュリティプロトコルと標準をもっています。 IPsec (IP Security [RFC2411])、 TLS (Transport Layer Security [RFC2246])の2つは、 良く知られたプロトコルです。 SASL (Simple Authentication and Security Layer [RFC2222])とGSSAPI (Generic Security Service Application Programming Interface [RFC2743])は、 「ホスト(宿主)」プロトコルのコンテキスト内においてサービスを提供します。 それらは、 他のプロトコル内における「ツールキット」とみなすことができます。
プロトコル設計者がしなければならない決定的な選択のひとつは、 「既存のプロトコルのひとつを利用するか、 標準ツールのひとつを利用するように自らのプロトコルを工夫するか、 あるいは何か全く違うことをするか」についての選択です。
すべてのプロトコルについて、唯一の正解は無く、設計者は、 自らのプロトコルに対する脅威に本当に注目し、 適切な対策を設計する必要があります。 インターネットスタンダードトラックのRFC中に記述されることが要求される「セキュリティについての考慮事項(Security Considerations)」という章の目的は、プロトコル設計者に、 脅威を文書化し彼らのセキュリティ設計のためのロジックを説明する場所を提供することにあります。
1995年4月にマサチューセッツ州ダンヴァースで開催された「第32回IETF」において、 IESGは、 総会にIETF標準によって提供される必要があるセキュリティの強度について、 コンセンサスを求めました。 IETF前における緊急課題は、「輸出グレードのセキュリティ(すなわち、 弱いセキュリティ)を標準においてサポートするか否か」でしたが、 この問題は、広くセキュリティの一般的な論点を提起しました。
圧倒的多数によるコンセンサスは、「IETFは、国家の政策に関わらず、 利用可能な最善のセキュリティの利用について標準化する必要がある」ということでした。 このコンセンサスは、しばしば、 「ダンヴァースドクトリン」として言及されます。
以来、我々は、 すべてのIETFプロトコルはセキュアに運用する必要があることを意味するように、 「ダンヴァースドクトリン」の解釈を拡大してきました。 これに対して、どのように反論できましょうか？
1995年以降、インターネットは、様々な悪意ある者からの攻撃に、 ますます、さらされるようになりました。 2000年において、 DDoS攻撃(分散型サービス妨害攻撃)について際立った報道の割合が充てられました。 しかし、これらの攻撃の多くは、最初、 インターネット接続されたコンピュータシステムを侵すことによって放たれたのです。 目立つDDoS攻撃を放つためには、通常、多くのシステムが侵されます。
我々が以上のことから導くことができる結論は、 「我々がセキュアなプロトコルを提供することに失敗すれば、 インターネットは、 国際的な通信インフラストラクチャを提供することにおいて、 その有用性を低下させるであろう」ということであり、 これは運命であるかのようです。
プロトコル内にセキュリティを構築することに対して、 かねてより我々が聞く主張のひとつは、「当該プロトコルは、 セキュリティが問題とはならない「防護された」環境における利用のみが意図されている」という主張です。
しかし、あるプロトコルが、将来、 どのように利用されるかを予測することは困難です。 限定された環境のためのみに意図されたものも、 グローバルなインターネットにおいて採用されるようになってしまう可能性があります。 我々は、セキュリティ問題を「解消」する時点まで待つことができません。 我々がその採用を認識するときでは、遅すぎるのです。
解決策は、我々は、 プロトコルがグローバルなインターネットにおいて広く利用されるようになることが頻発する日に備えて提供するために、 強いセキュリティをすべてのプロトコルに実装しなければならない(MUST)ということです。
我々は、しばしば、 「セキュリティは必須(MUST)実装である」といいます。 「必須(MUST)実装と必須(MUST)利用は顕著に異なる」ということには、 価値がありません。
既述のように、プロトコルには、セキュリティが問題とならない、 セキュリティプロトコル処理が顕著な性能低下をもたらす可能性があるセキュアな 孤立したネットワーク内に採用される可能性があるものがあります。 それゆえ、セキュリティ機能が、 プロトコルのエンドユーザが使わないことを選べるオプションであることは、 全く合理的であるといえます。 ここで、我々は、 「エンドユーザ」の定義をあいまいに使っていることに注意してください。 我々は、究極のエンドユーザのみならず、 あらゆるテクノロジーの開発者を意味しており、これは、 会社全体である可能性があります。
しかし、セキュリティは、 エンドユーザが状況に応じてそれを可能にすることができるように必須実装(MUST IMPLEMENT)でなければなりません。
必要不可欠ではありません。 しかし、我々は、ここで、もう少し詳しく説明する必要があります。 「どのセキュリティサービスが、 与えられたプロトコルについて最適であるか」は、 実装中のアプリケーションに大きく依存します。 多くの人々は、「暗号化は守秘性を意味する」と考えます。 言い換えれば、プロトコルメッセージの中身の暗号化です。
しかし、守秘性が要件ではなく、 認証とインテグリティが要件であるアプリケーションが多くあります。
一例として、 熱と排気の制御を操作するためにIPテクノロジーを使用している制御アプリケーションを構築する際が挙げられます。 熱排気口を開閉する命令をするメッセージの守秘性を守るための要件は、 無さそうです。 しかし、 我々が悪意ある者が意のままに温度を上げ下げすることからビルを守ろうとする場合、 認証とインテグリティは、重要である可能性があります。
我々も、しばしば、 プロトコルメッセージの認証とインテグリティを実装するために暗号技術を要求します。 それゆえ、問題が「我々は、 守秘性を実装しなければならない(MUST)か？」であるならば、 その答えは「ものによる(depends)」です。 しかし、 問題が「我々は暗号技術を利用しなければならない(MUST)か？」であるならば、 その答えは、「可能性がある(likely)」です。
多くのIETFフォーラムにおける暗号技術の言及は、目を曇らせ、 注目が高まらないようにしています。
多くの人々は、「暗号技術(cryptography)」という単語を、 輸出規制や性能といった懸念と関連づけているようです。 普通の人々には、それを理解せず、それゆえ、その利用をためらう人がいます。 しかし、これらの懸念の多くには、根拠がありません。
今日、輸出規制は、少なくとも大部分の先進国からのものについては、 関心事ではなくなってきています。 そして、これが関心事である国においても、この関心事は、 暗号技術自体についてではなく、 守秘性を提供する際の利用におけるものです。
暗号技術を利用するとき、性能の論点があります。 しかし、我々は、 IETFにおいてエンジニアであることにプライドを持っています。 与えられたプロトコルにおいて暗号技術を利用することによる影響を皆無にする、 もしくは、少なくとも最小化するために、 暗号技術を利用する適切なやり方を考えることは、 エンジニアリングの課題です。
最後に、暗号技術を理解することに関してですが、あなたは、 理解する必要がありません。 言い換えれば、あなたは、 暗号技術を利用するために暗号技術者(cryptographer)になる必要はありません。 そうではなく、 あなたが直面しているエンジニアリング問題を解決するためには、 既存の良く理解されているサイファーとサイファースイートを利用するのです。
IETFのセキュリティエリアにおいて、我々がもつ目標のひとつは、 プロトコル実装者が細目まで理解しなくても適切なテクノロジーを選択できるようにするために、 ガイドを話題にすることです。
本書は、 「セキュリティがプロトコルの実装において考慮されなければならない」という IETFの要件についてのものです。 それゆえ、これ全体がセキュリティについてのものです！
著者は、セキュリティエリアアドバイザリグループの参画と、 特にRob Shirey氏、Ran Atkinson氏、Steve Bellovin氏、Marc Blanchet氏、 Steve Kent氏、Randy Bush氏、Dave Crocker氏、Stephen Farrell氏、 Paul Hoffman氏、Russ Housley氏、Christian Huitema氏、Melinda Shore氏、 Adam Shostack氏および Kurt D. Zeilenga氏に感謝します。
| [RFC2119] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119 1997年3月 |
| [RFC2222] |
Myers, J., 「SASL(シンプル認証とセキュリティ層) (Simple Authentication and Security Layer (SASL))」, RFC 2222, 1997年10月 |
| [RFC2411] |
Thayer, R., Doraswamy, N. and R. Glenn, 「IPSEC 文書ロードマップ (IP Security Document Roadmap)」, RFC 2411, 1998年11月. |
| [RFC2246] |
Dierks, T. and C. Allen, 「TLS プロトコル v1.0 (The TLS Protocol Version 1.0)」, RFC 2246, 1999年1月. |
| [RFC2743] |
Linn, J., 「GSSAPI v2 アップデート 1 (Generic Security Service Application Program Interface Version 2, Update 1.)」, RFC 2743 (English), 2000年1月. |
| [RFC2828] |
Shirey, R., 「インターネットセキュリティ小辞典 (Internet Security Glossary)」, FYI 36, RFC 2828, 2000年5月. |
Jeffrey I. Schiller
MIT Room W92-190
77 Massachusetts Avenue
Cambridge, MA 02139-4307
USA
電話： +1 (617) 253-8400
EMail： jis＠mit.edu
宮川 寧夫
情報処理推進機構
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (2002). 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.
RFC編集者のための資金は現在、 Internet Societyによって提供されています。