Network Working Group J. Schiller
Request for Comments: 3365 Massachusetts Institute of Technology
BCP: 61 August 2002
Category: Best Current Practice
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工程任务组标准协议的强大安全要求
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
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]提供了互联网安全服务及其定义的全面列表。以下是三个基本定义：
* 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协议套件运行的应用程序最终会在Internet上使用。即使最初的应用程序不打算在“广域”互联网环境中使用，情况也是如此。如果应用程序不是为提供安全性而设计的，则应用程序的用户会发现他们容易受到攻击。
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]）是两个众所周知的协议。简单身份验证和安全层（SASL[RFC2222]和通用安全服务应用程序编程接口（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.
协议设计者必须做出的一个关键选择是，是使用现有协议之一，设计自己的协议以使用标准工具之一，还是做一些完全不同的事情。
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协议都应安全运行。人们怎么能反驳这一点呢？
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.
我们不断听到的反对将安全性构建到协议中的论点之一是，给定的协议仅用于“受保护”的环境中，在这些环境中，安全性不会成为问题。
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安全领域的目标之一是提供指南，以便协议实施者可以选择适当的技术，而无需了解细节。
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、Stephen Farrell、Paul Hoffman、Russ Housley、Christian Huitema、Melinda Short和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）”，RFC22221997年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安全文档路线图”，RFC 24111998年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”，RFC2246，1999年1月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1.", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新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麻省理工学院W92-190室美国马萨诸塞州剑桥大道77号02139-4307
Phone: +1 (617) 253-8400
EMail: jis@mit.edu
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编辑功能的资金目前由互联网协会提供。