[要約] RFC 3365は、インターネット標準プロトコルに対する強固なセキュリティ要件を定めた文書です。このRFCの目的は、インターネットエンジニアリングタスクフォース（IETF）が開発するすべてのプロトコルが、セキュリティを重視した設計を行うことを求めることにあります。
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
Internet Engineering Task Force 標準プロトコルの強力なセキュリティ要件
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.
このドキュメントは、インターネットコミュニティのための Internet Best Current Practices（インターネットにおいて現在行われている最良の慣行）を指定し、改善のための議論と提案を求めます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
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標準プロトコルは適切な強力なセキュリティメカニズムを利用しなければならない（MUST）、というのがIETFのコンセンサスです。この文書では、このドクトリンの歴史と根拠について説明し、このドクトリンを Best Current Practice（現在行われている最良の慣行）として確立します。
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標準プロトコルがインターネット全体で使用される際に、アプリケーションに適切なセキュリティを提供するために必要な機能を備えていることを保証することです。実装が必須（Mandatory to implement）とされるメカニズムは、機密性の高いビジネスアプリケーションを保護するために十分なセキュリティを提供するものであるべきです。
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]で定義されている方法で、MUST、MAY、SHOULD などの用語を使用します。
[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.)
* データ機密性サービス：権限のない個人またはプロセスへの不正な開示からデータを保護するセキュリティサービス。（インターネット標準ドキュメントは、「データ機密性」を「プライバシー」の同義語として使用すべきではありません（SHOULD NOT）。これらは異なる概念です。プライバシーは、エンティティ（通常は人）が自身のために行動し、自身に関する情報を他者と共有する意思の程度を含め、環境とどの程度相互作用するかを決定する権利を指します。）
* 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 Security（IPsec [RFC2411]）と Transport Layer Security（TLS [RFC2246]）は、2つのよく知られたプロトコルです。Simple Authentication and Security Layer（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.
すべてのプロトコルに対する唯一の正解はありません。設計者は、自身のプロトコルに対する脅威を真剣に検討し、適切な対策を設計する必要があります。Internet Standards Track の RFC に存在することが求められる「Security Considerations（セキュリティに関する考慮事項）」セクションの目的は、プロトコル設計者が脅威を文書化し、セキュリティ設計の論理を説明するための場所を提供することです。
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月にマサチューセッツ州ダンバースで開催された第32回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プロトコルは安全に動作すべきである（SHOULD）ことを意味するようにしました。これに異論を唱えることなどできるでしょうか？
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年には、分散型サービス拒否（DDoS）攻撃が大きく報道されました。しかし、これらの攻撃の多くは、最初にインターネットに接続されたコンピュータシステムを侵害することによって開始されました。通常、大規模な分散攻撃を開始するために、多くのシステムが侵害されます。
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.
解決策は、プロトコルがグローバルインターネットで広く使用されるようになるという、あまりにも頻繁に起こる事態に備えるために、すべてのプロトコルに強力なセキュリティを実装しなければならない（MUST）、ということです。
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.
我々はよく、セキュリティは実装必須（MUST implement）であると言います。実装必須（MUST implement）と使用必須（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.
しかし、状況がそれを必要とするときにエンドユーザーが有効にするという選択肢を持てるように、セキュリティは実装必須（MUST IMPLEMENT）でなければなりません。
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".
しかし、プロトコルメッセージの認証と完全性を実装するために、暗号技術が必要になることがよくあります。したがって、質問が「機密性を実装しなければならないか（MUST）？」であれば、答えは「場合による」となります。しかし、質問が「暗号技術を利用しなければならないか（MUST）？」であれば、答えは「おそらくそうなる（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.
著者は、Security Area Advisory Group の参加、特に 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., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[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, January 2000.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
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 USA
Phone: +1 (617) 253-8400
EMail: jis@mit.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
この文書とここに含まれる情報は「現状のまま（AS IS）」で提供され、インターネットソサエティおよび Internet Engineering Task Force は、明示または黙示を問わず、ここに含まれる情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的への適合性の黙示的な保証を含むがこれらに限定されない、すべての保証を放棄します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネットソサエティによって提供されています。