[要約] RFC 3365は、インターネット標準プロトコルに対する強固なセキュリティ要件を定めた文書です。このRFCの目的は、インターネットエンジニアリングタスクフォース（IETF）が開発するすべてのプロトコルが、セキュリティを重視した設計を行うことを求めることにあります。利用場面としては、新しいインターネットプロトコルの設計や既存プロトコルの改訂時に、セキュリティ要件を確実に満たすための指針として参照されます。関連するRFCには、セキュリティアーキテクチャに関するRFC 3552や、特定のセキュリティメカニズムの実装を推奨するRFC 3631などがあります。RFC 3365は、インターネットの安全性と信頼性を高めるための基盤となる文書です。
Network Working Group J. Schiller
Request for Comments: 3365 Massachusetts Institute of Technology
BCP: 61 August 2002
Category: Best Current Practice
Strong Security Requirements for Internet Engineering Task Force Standard Protocols
インターネットエンジニアリングタスク強制標準プロトコルの強力なセキュリティ要件
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのためのインターネットの最良の現在の慣行を指定し、改善のための議論と提案を要求します。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
Abstract
概要
It is the consensus of the IETF that IETF standard protocols MUST make use of appropriate strong security mechanisms. This document describes the history and rationale for this doctrine and establishes this doctrine as a best current practice.
IETF標準プロトコルが適切な強力なセキュリティメカニズムを利用しなければならないことはIETFの合意です。この文書では、この教義の歴史と根拠について説明し、最善の現在の練習としてこの教義を確立しています。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Security Services . . . . . . . . . . . . . . . . . . . . . . 2
4. The Properties of the Internet. . . . . . . . . . . . . . . . 3
5. IETF Security Technology. . . . . . . . . . . . . . . . . . . 3
6. The Danvers Doctrine. . . . . . . . . . . . . . . . . . . . . 4
7. MUST is for Implementors. . . . . . . . . . . . . . . . . . . 5
8. Is Encryption a MUST? . . . . . . . . . . . . . . . . . . . . 5
9. Crypto Seems to Have a Bad Name . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
The purpose of this document is to document the IETF consensus on security requirements for protocols as well as to provide the background and motivation for them.
この文書の目的は、プロトコルのためのセキュリティ要件に関するIETFコンセンサスを文書化し、それらの背景と動機を提供することです。
The Internet is a global network of independently managed networks and hosts. As such there is no central authority responsible for the operation of the network. There is no central authority responsible for the provision of security across the network either.
インターネットは独立して管理されているネットワークとホストのグローバルネットワークです。そのため、ネットワークの操作に責任がある中心的な権限はありません。ネットワーク全体でセキュリティの提供を担当する中心的な権限はありません。
Security needs to be provided end-to-end or host to host. The IETF's security role is to ensure that IETF standard protocols have the necessary features to provide appropriate security for the application as it may be used across the Internet. Mandatory to implement mechanisms should provide adequate security to protect sensitive business applications.
セキュリティは、ホストへのエンドツーエンドまたはホストを提供する必要があります。IETFのセキュリティロールは、IETF標準プロトコルに、インターネット全体で使用される可能性があるため、アプリケーションに対して適切なセキュリティを提供するために必要な機能が必要なことを確認することです。メカニズムを実装するための必須機密のビジネスアプリケーションを保護するために適切なセキュリティを提供する必要があります。
Although we are not defining a protocol standard in this document we will use the terms MUST, MAY, SHOULD and friends in the ways defined by [RFC2119].
私たちはこの文書でプロトコル規格を定義していませんが、必要に必要な条項は、[RFC2119]で定義されている方法で、必要とされます。
[RFC2828] provides a comprehensive listing of internetwork security services and their definitions. Here are three essential definitions:
[RFC2828]インターネットワークセキュリティサービスとその定義の包括的なリストを提供します。これが3つの必須定義です。
* Authentication service: A security service that verifies an identity claimed by or for an entity, be it a process, computer system, or person. At the internetwork layer, this includes verifying that a datagram came from where it purports to originate. At the application layer, this includes verifying that the entity performing an operation is who it claims to be.
* 認証サービス：エンティティによって、またはエンティティを主張したアイデンティティを検証するセキュリティサービス、プロセス、コンピュータシステム、または個人になります。インターネットワークレイヤーでは、データグラムが発信元の場所から来たのを検証することが含まれます。アプリケーション層では、操作を実行するエンティティがその主張しているのかという検証を含む。
* Data confidentiality service: A security service that protects data against unauthorized disclosure to unauthorized individuals or processes. (Internet Standards Documents SHOULD NOT use "data confidentiality" as a synonym for "privacy", which is a different concept. Privacy refers to the right of an entity, normally a person, acting in its own behalf, to determine the degree to which it will interact with its environment, including the degree to which the entity is willing to share information about itself with others.)
* データ機密保持サービス：不正な個人またはプロセスに不正な開示からデータを保護するセキュリティサービス。（インターネット標準書類は「プライバシー」の同義語として「データ機密性」を使用してはいけません。プライバシーは、通常、それ自身の代わりに行動する企業の権利を指し、エンティティが他の人との情報を共有している程度を含めて、環境と対話します。）
* Data integrity service: A security service that protects against unauthorized changes to data, including both intentional change (including destruction) and accidental change (including loss), by ensuring that changes to data are detectable.
* データ整合性サービス：データへの変更が検出されることを確実にすることで、意図的な変更（破壊を含む）と偶発的な変更（損失を含む）の両方を含め、不正な変更から保護するセキュリティサービス。
As mentioned earlier, the Internet provides no inherent security. Enclaves of networking exist where users believe that security is provided by the environment itself. An example would be a company network not connected to the global Internet.
前述のように、インターネットは固有のセキュリティを提供しません。ネットワーキングのエンクレーブは、セキュリティが環境自体によって提供されていると信じているユーザーが存在します。例は、グローバルインターネットに接続されていない会社ネットワークです。
One might imagine that protocols designed to operate in such an enclave would not require any security services, as the security is provided by the environment.
セキュリティが環境によって提供されるので、そのようなエンクリューブで動作するように設計されたプロトコルがセキュリティサービスを必要としないと想像するかもしれません。
History has shown that applications that operate using the TCP/IP Protocol Suite wind up being used over the Internet. This is true even when the original application was not envisioned to be used in a "wide area" Internet environment. If an application isn't designed to provide security, users of the application discover that they are vulnerable to attack.
履歴は、TCP / IPプロトコルスイートを使用して動作するアプリケーションがインターネット上で使用されていることを示しています。これは、元のアプリケーションが「ワイドエリア」インターネット環境で使用されていないことが想定されていなくても当てはまります。アプリケーションがセキュリティを提供するように設計されていない場合は、アプリケーションのユーザーが攻撃に対して脆弱であることを検出します。
The IETF has several security protocols and standards. IP Security (IPsec [RFC2411]), Transport Layer Security (TLS [RFC2246]) are two well known protocols. Simple Authentication and Security Layer (SASL [RFC2222] and the Generic Security Service Application Programming Interface (GSSAPI [RFC2743]) provide services within the context of a "host" protocol. They can be viewed as "toolkits" to use within another protocol.
IETFにはいくつかのセキュリティプロトコルと標準があります。IPセキュリティ（IPsec [RFC2411]）、トランスポート層セキュリティ（TLS [RFC2246]）は、2つの周知のプロトコルです。単純な認証とセキュリティレイヤ（SASL [RFC2222]およびGeneric Security Service Application Programming Interface（GSSAPI [RFC2743]）は、「ホスト」プロトコルのコンテキスト内でサービスを提供します。それらは他のプロトコル内で使用するための「ツールキット」と見なすことができます。
One of the critical choices that a protocol designer must make is whether to make use of one of the existing protocols, engineer their own protocol to use one of the standard tools or do something completely different.
プロトコル設計者が行わなければならない重要な選択肢の1つは、既存のプロトコルの1つを使用するかどうか、標準的なツールの1つを使用するために独自のプロトコルをエンジニアリングするか、完全に異なるものを使用することです。
There is no one correct answer for all protocols and designers really need to look at the threats to their own protocol and design appropriate counter-measures. The purpose of the "Security Considerations" Section required to be present in an RFC on the Internet Standards Track is to provide a place for protocol designers to document the threats and explain the logic to their security design.
すべてのプロトコルには正しい答えが正しい答えはありません。デザイナーは、本当に自分のプロトコルと適切な対策を設計するための脅威を調べる必要があります。インターネット規格のトラックでRFCに存在するのに必要な「セキュリティ上の考慮事項」セクションの目的は、プロトコル設計者が脅威を文書化し、それらのセキュリティ設計に論理を説明するための場所を提供することです。
At the 32cd IETF held in Danvers, Massachusetts during April of 1995 the IESG asked the plenary for a consensus on the strength of security that should be provided by IETF standards. Although the immediate issue before the IETF was whether or not to support "export" grade security (which is to say weak security) in standards the question raised the generic issue of security in general.
1995年4月中のマサチューセッツ州ダンサーズで開催された32cd IETFで、IESGは、IETF規格によって提供されるべきセキュリティの強さの合意のためにプレナリーに尋ねました。IETFの前の即時問題は、標準内で「エクスポート」グレードのセキュリティ（これは弱いセキュリティ）をサポートするかどうかは、この質問は一般的なセキュリティの一般的な問題を提起しました。
The overwhelming consensus was that the IETF should standardize on the use of the best security available, regardless of national policies. This consensus is often referred to as the "Danvers Doctrine".
圧倒的なコンセンサスは、IETFは全国方針に関係なく、利用可能な最高のセキュリティの使用を標準化するべきであるということでした。このコンセンサスはしばしば「ダンバーの教義」と呼ばれます。
Over time we have extended the interpretation of the Danvers Doctrine to imply that all IETF protocols should operate securely. How can one argue against this?
時間の経過とともに、すべてのIETFプロトコルが安全に動作することを意味するためにDanvers Doctrineの解釈を拡張しました。どうやってこれに対して主張することができますか？
Since 1995 the Internet has increasingly come under attack from various malicious actors. In 2000 significant press coverage was devoted to Distributed Denial of Service attacks. However many of these attacks were launched by first compromising an Internet connected computer system. Usually many systems are compromised in order to launch a significant distributed attack.
1995年以来、インターネットはさまざまな悪意のある俳優からの攻撃の中でますます来ました。2000年に有意なプレスカバレッジは、サービス拒否攻撃の分散拒否に専念しました。しかし、これらの攻撃の多くは、最初にインターネット接続されたコンピュータシステムを妥協することによって起動されました。通常、分散攻撃を起動するために多くのシステムが危険にさらされています。
A conclusion we can draw from all of this is that if we fail to provide secure protocols, then the Internet will become less useful in providing an international communications infrastructure, which appears to be its destiny.
結論このすべてから引き出すことができます。
One of the continuing arguments we hear against building security into protocols is the argument that a given protocol is intended only for use in "protected" environments where security will not be an issue.
議定書にセキュリティを構築することに対して聞いている継続的な引数の1つは、特定のプロトコルが「保護された」環境での使用のみを意図しているという議論です。
However it is very hard to predict how a protocol will be used in the future. What may be intended only for a restricted environment may well wind up being deployed in the global Internet. We cannot wait until that point to "fix" security problems. By the time we realize this deployment, it is too late.
しかし、将来プロトコルがどのように使用されるかを予測することは非常に困難です。制限された環境のためだけに意図されている可能性があるかもしれませんが、グローバルインターネットに展開されることがよくあります。セキュリティ上の問題を修正するまで待つことはできません。この展開を実現する時までに、遅すぎます。
The solution is that we MUST implement strong security in all protocols to provide for the all too frequent day when the protocol comes into widespread use in the global Internet.
この解決策は、プロトコルがグローバルインターネットで広く使用されている頻度の頻度を提供するために、すべてのプロトコルで強力なセキュリティを実装する必要があります。
We often say that Security is a MUST implement. It is worth noting that there is a significant different between MUST implement and MUST use.
セキュリティが実装の実装であるとよく言うことがよくあります。実装と使用しなければならない間で重要な異なる違いがあることは注目に値します。
As mentioned earlier, some protocols may be deployed in secure enclaves for which security isn't an issue and security protocol processing may add a significant performance degradation. Therefore it is completely reasonable for security features to be an option that the end user of the protocol may choose to disable. Note that we are using a fuzzy definition of "end user" here. We mean not only the ultimate end user, but any deployer of a technology, which may be an entire enterprise.
前述のように、いくつかのプロトコルは、セキュリティが問題ではなく、セキュリティプロトコル処理が大幅なパフォーマンス劣化を追加することができる安全なエンクリュブに展開されることがあります。したがって、セキュリティ機能が完全に妥当な場合は、プロトコルのエンドユーザーが無効にすることを選択できるオプションであることが完全に合理的です。ここで「エンドユーザー」のファジー定義を使用していることに注意してください。最終的なエンドユーザーだけでなく、企業全体である可能性があるテクノロジのデプロイヤーも意味します。
However security must be a MUST IMPLEMENT so that end users will have the option of enabling it when the situation calls for it.
ただし、セキュリティは必須でなければなりませんので、エンドユーザーには、状況がそれを呼び出すときに有効にするオプションがあります。
Not necessarily. However we need to be a bit more precise here. Exactly what security services are appropriate for a given protocol depends heavily on the application it is implementing. Many people assume that encryption means confidentiality. In other words the encryption of the content of protocol messages.
必ずしも。しかし、ここで少し正確になる必要があります。特定のプロトコルに適切なセキュリティサービスがどのようなものであるかは、実装中のアプリケーションに大きく依存します。多くの人は暗号化とは機密性を意味すると仮定します。言い換えれば、プロトコルメッセージの内容の暗号化。
However there are many applications where confidentiality is not a requirement, but authentication and integrity are.
ただし、機密性が要件ではなく、認証と整合性がある多くのアプリケーションがあります。
One example might be in a building control application where we are using IP technology to operate heat and vent controls. There is likely no requirement to protect the confidentiality of messages that instruct heat vents to open and close. However authentication and integrity are likely important if we are to protect the building from a malicious actor raising or lowering the temperature at will.
一例は、IP技術を使用して熱および通気制御を操作するための建築管理アプリケーションにある可能性があります。熱管を開閉するように命じるメッセージの機密性を保護する必要はありません。しかし、認証と整合性は、悪意のある俳優からの建物を保護するか、またはその温度を下げることを低下させることができれば重要です。
Yet we often require cryptographic technology to implement authentication and integrity of protocol messages. So if the question is "MUST we implement confidentiality?" the answer will be "depends". However if the question is "MUST we make use of cryptographic technology?" the answer is "likely".
それでも私たちはしばしば暗号技術を必要とし、プロトコルメッセージの認証と整合性を実装する必要があります。だから、質問が「機密性を実装する必要がありますか」の場合答えは「依存」になります。しかし、問題が「暗号化技術を利用しなければならない」答えは「おそらく」です。
The mention of cryptographic technology in many IETF forums causes eyes to glaze over and resistance to increase.
多くのIETFフォーラムにおける暗号技術の言及は、目を釉薬および増加させるために眼を引き起こす。
Many people seem to associate the word "cryptography" with concerns such as export control and performance. Some just plain do not understand it and therefore shy away from its use. However many of these concerns are unfounded.
多くの人が「暗号」という言葉を輸出管理やパフォーマンスなどの懸念に関連付けているようです。単純にわかりやすく、したがってその使用から恥ずかしがり屋です。しかし、これらの懸念の多くは根拠がありません。
Today export control, at least from most of the developed world, is becoming less of a concern. And even where it is a concern, the concern is not over cryptography itself but in its use in providing confidentiality.
少なくとも開発された世界のほとんどからの今日の輸出管理は、懸念が少なくなりつつあります。そしてそれが懸念である場合でも、懸念は暗号化自体を超えていませんが、機密性を提供するのに使われています。
There are performance issues when you make use of cryptographic technology. However we pride ourselves in the IETF as being engineers. It is an engineering exercise to figure out the appropriate way to make use of cryptographic technology so as to eliminate or at least minimize the impact of using cryptography within a given protocol.
暗号化技術を利用するとパフォーマンスがあります。しかし、私たちはエンジニアとしてのIETFに誇りを持っています。所与のプロトコル内の暗号化を排除または少なくとも最小限に抑えるために、暗号技術を利用するための適切な方法を把握するためのエンジニアリング運動である。
Finally, as to understanding cryptography, you don't have to. In other words, you do not need to become a cryptographer in order to effectively make use of cryptographic technology. Instead you make use of existing well understood ciphers and cipher suites to solve the engineering problem you face.
最後に、暗号化を理解するためには、必要ありません。言い換えれば、暗号化技術を効果的に利用するためには、暗号学者になる必要はありません。代わりに、あなたは既存のよく理解された暗号と暗号スイートを利用して、あなたが直面する工学的問題を解決します。
One of the goals that we have in the Security Area of the IETF is to come up with guides so that protocol implementers can choose appropriate technology without having to understand the minutiae.
IETFのセキュリティエリアに持っている目標の1つは、プロトコルの実装者がおとめティエを理解しなくても適切な技術を選択できるようにガイドを思いつくことです。
This document is about the IETF's requirement that security be considered in the implementation of protocols. Therefore it is entirely about security!
このドキュメントは、セキュリティがプロトコルの実装において考慮されるというIETFの要求についてです。したがって、それは完全にセキュリティについてです！
The author would like to acknowledge the participation of the Security Area Advisory Group and in particular 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 and Kurt D. Zeilenga.
著者は、セキュリティエリアアドバイザリーグループの参加、特にRob Shirey、Ran Atkinson、Steve Bellovin、Marc Blanchet、Steve Kent、Randy Bush、Dave Crocker、Paul Hoffman、Russ Ousley、Christian Huitema、Stephen Farrell、Ran AtkinsonMelinda Shore、Adam ShostackとKurt D. Zeilenga。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222]マイヤーズ、J。、「単純認証とセキュリティ層（SASL）」、RFC 2222、1997年10月。
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N. R. Glenn、「IP Security Document RoadMap」、RFC 2411、1998年11月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.およびC. Allen、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1.", RFC 2743, January 2000.
[RFC2743] Linn、J.、「Generic Security Service Application Program Interface Version 2、Update 1。」、RFC 2743、2000年1月。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828] Shirey、R。、「インターネットセキュリティ用語集」、FYI 36、RFC 2828、2000年5月。
Jeffrey I. Schiller MIT Room W92-190 77 Massachusetts Avenue Cambridge, MA 02139-4307 USA
Jeffrey I. Schiller Mit Room W92-190 77 Massachusetts Avenue Cambridge、MA 02139-4307アメリカ
Phone: +1 (617) 253-8400
EMail: jis@mit.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（c）インターネット社会（2002）。全著作権所有。
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.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。