Network Working Group E. Rescorla
Request for Comments: 3552 RTFM, Inc.
BCP: 72 B. Korver
Category: Best Current Practice Xythos Software
Internet Architecture Board
IAB
July 2003
Network Working Group E. Rescorla
Request for Comments: 3552 RTFM, Inc.
BCP: 72 B. Korver
Category: Best Current Practice Xythos Software
Internet Architecture Board
IAB
July 2003
Guidelines for Writing RFC Text on Security Considerations
关于安全注意事项的RFC文本编写指南
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section.
所有RFC都需要有一个安全注意事项部分。从历史上看，这些部门相对薄弱。本文档为RFC作者提供了如何编写良好的安全注意事项部分的指南。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements. . . . . . . . . . . . . . . . . . . . . 3
2. The Goals of Security. . . . . . . . . . . . . . . . . . . 3
2.1. Communication Security. . . . . . . . . . . . . . . . 3
2.1.1. Confidentiality. . . . . . . . . . . . . . . . 4
2.1.2. Data Integrity . . . . . . . . . . . . . . . . 4
2.1.3. Peer Entity authentication . . . . . . . . . . 4
2.2. Non-Repudiation . . . . . . . . . . . . . . . . . . . 5
2.3. Systems Security. . . . . . . . . . . . . . . . . . . 5
2.3.1. Unauthorized Usage . . . . . . . . . . . . . . 6
2.3.2. Inappropriate Usage. . . . . . . . . . . . . . 6
2.3.3. Denial of Service. . . . . . . . . . . . . . . 6
3. The Internet Threat Model. . . . . . . . . . . . . . . . . 6
3.1. Limited Threat Models . . . . . . . . . . . . . . . . 7
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . 7
3.2.1. Confidentiality Violations . . . . . . . . . . 8
3.2.2. Password Sniffing. . . . . . . . . . . . . . . 8
3.2.3. Offline Cryptographic Attacks. . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements. . . . . . . . . . . . . . . . . . . . . 3
2. The Goals of Security. . . . . . . . . . . . . . . . . . . 3
2.1. Communication Security. . . . . . . . . . . . . . . . 3
2.1.1. Confidentiality. . . . . . . . . . . . . . . . 4
2.1.2. Data Integrity . . . . . . . . . . . . . . . . 4
2.1.3. Peer Entity authentication . . . . . . . . . . 4
2.2. Non-Repudiation . . . . . . . . . . . . . . . . . . . 5
2.3. Systems Security. . . . . . . . . . . . . . . . . . . 5
2.3.1. Unauthorized Usage . . . . . . . . . . . . . . 6
2.3.2. Inappropriate Usage. . . . . . . . . . . . . . 6
2.3.3. Denial of Service. . . . . . . . . . . . . . . 6
3. The Internet Threat Model. . . . . . . . . . . . . . . . . 6
3.1. Limited Threat Models . . . . . . . . . . . . . . . . 7
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . 7
3.2.1. Confidentiality Violations . . . . . . . . . . 8
3.2.2. Password Sniffing. . . . . . . . . . . . . . . 8
3.2.3. Offline Cryptographic Attacks. . . . . . . . . 9
3.3. Active Attacks. . . . . . . . . . . . . . . . . . . . 9
3.3.1. Replay Attacks . . . . . . . . . . . . . . . . 10
3.3.2. Message Insertion. . . . . . . . . . . . . . . 10
3.3.3. Message Deletion . . . . . . . . . . . . . . . 11
3.3.4. Message Modification . . . . . . . . . . . . . 11
3.3.5. Man-In-The-Middle. . . . . . . . . . . . . . . 12
3.4. Topological Issues. . . . . . . . . . . . . . . . . . 12
3.5. On-path versus off-path . . . . . . . . . . . . . . . 13
3.6. Link-local. . . . . . . . . . . . . . . . . . . . . . 13
4. Common Issues. . . . . . . . . . . . . . . . . . . . . . . 13
4.1. User Authentication . . . . . . . . . . . . . . . . . 14
4.1.1. Username/Password. . . . . . . . . . . . . . . 14
4.1.2. Challenge Response and One Time Passwords. . . 14
4.1.3. Shared Keys. . . . . . . . . . . . . . . . . . 15
4.1.4. Key Distribution Centers . . . . . . . . . . . 15
4.1.5. Certificates . . . . . . . . . . . . . . . . . 15
4.1.6. Some Uncommon Systems. . . . . . . . . . . . . 15
4.1.7. Host Authentication. . . . . . . . . . . . . . 16
4.2. Generic Security Frameworks . . . . . . . . . . . . . 16
4.3. Non-repudiation . . . . . . . . . . . . . . . . . . . 17
4.4. Authorization vs. Authentication. . . . . . . . . . . 18
4.4.1. Access Control Lists . . . . . . . . . . . . . 18
4.4.2. Certificate Based Systems. . . . . . . . . . . 18
4.5. Providing Traffic Security. . . . . . . . . . . . . . 19
4.5.1. IPsec. . . . . . . . . . . . . . . . . . . . . 19
4.5.2. SSL/TLS. . . . . . . . . . . . . . . . . . . . 20
4.5.3. Remote Login . . . . . . . . . . . . . . . . . 22
4.6. Denial of Service Attacks and Countermeasures . . . . 22
4.6.1. Blind Denial of Service. . . . . . . . . . . . 23
4.6.2. Distributed Denial of Service. . . . . . . . . 23
4.6.3. Avoiding Denial of Service . . . . . . . . . . 24
4.6.4. Example: TCP SYN Floods. . . . . . . . . . . . 24
4.6.5. Example: Photuris. . . . . . . . . . . . . . . 25
4.7. Object vs. Channel Security . . . . . . . . . . . . . 25
4.8. Firewalls and Network Topology. . . . . . . . . . . . 26
5. Writing Security Considerations Sections . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. SMTP. . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. Security Considerations. . . . . . . . . . . . 29
6.1.2. Communications security issues . . . . . . . . 34
6.1.3. Denial of Service. . . . . . . . . . . . . . . 36
6.2. VRRP. . . . . . . . . . . . . . . . . . . . . . . . . .36
6.2.1. Security Considerations. . . . . . . . . . . . 36
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 38
8. Normative References . . . . . . . . . . . . . . . . . . . 39
9. Informative References . . . . . . . . . . . . . . . . . . 41
10.Security Considerations. . . . . . . . . . . . . . . . . . 42
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3. Active Attacks. . . . . . . . . . . . . . . . . . . . 9
3.3.1. Replay Attacks . . . . . . . . . . . . . . . . 10
3.3.2. Message Insertion. . . . . . . . . . . . . . . 10
3.3.3. Message Deletion . . . . . . . . . . . . . . . 11
3.3.4. Message Modification . . . . . . . . . . . . . 11
3.3.5. Man-In-The-Middle. . . . . . . . . . . . . . . 12
3.4. Topological Issues. . . . . . . . . . . . . . . . . . 12
3.5. On-path versus off-path . . . . . . . . . . . . . . . 13
3.6. Link-local. . . . . . . . . . . . . . . . . . . . . . 13
4. Common Issues. . . . . . . . . . . . . . . . . . . . . . . 13
4.1. User Authentication . . . . . . . . . . . . . . . . . 14
4.1.1. Username/Password. . . . . . . . . . . . . . . 14
4.1.2. Challenge Response and One Time Passwords. . . 14
4.1.3. Shared Keys. . . . . . . . . . . . . . . . . . 15
4.1.4. Key Distribution Centers . . . . . . . . . . . 15
4.1.5. Certificates . . . . . . . . . . . . . . . . . 15
4.1.6. Some Uncommon Systems. . . . . . . . . . . . . 15
4.1.7. Host Authentication. . . . . . . . . . . . . . 16
4.2. Generic Security Frameworks . . . . . . . . . . . . . 16
4.3. Non-repudiation . . . . . . . . . . . . . . . . . . . 17
4.4. Authorization vs. Authentication. . . . . . . . . . . 18
4.4.1. Access Control Lists . . . . . . . . . . . . . 18
4.4.2. Certificate Based Systems. . . . . . . . . . . 18
4.5. Providing Traffic Security. . . . . . . . . . . . . . 19
4.5.1. IPsec. . . . . . . . . . . . . . . . . . . . . 19
4.5.2. SSL/TLS. . . . . . . . . . . . . . . . . . . . 20
4.5.3. Remote Login . . . . . . . . . . . . . . . . . 22
4.6. Denial of Service Attacks and Countermeasures . . . . 22
4.6.1. Blind Denial of Service. . . . . . . . . . . . 23
4.6.2. Distributed Denial of Service. . . . . . . . . 23
4.6.3. Avoiding Denial of Service . . . . . . . . . . 24
4.6.4. Example: TCP SYN Floods. . . . . . . . . . . . 24
4.6.5. Example: Photuris. . . . . . . . . . . . . . . 25
4.7. Object vs. Channel Security . . . . . . . . . . . . . 25
4.8. Firewalls and Network Topology. . . . . . . . . . . . 26
5. Writing Security Considerations Sections . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. SMTP. . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. Security Considerations. . . . . . . . . . . . 29
6.1.2. Communications security issues . . . . . . . . 34
6.1.3. Denial of Service. . . . . . . . . . . . . . . 36
6.2. VRRP. . . . . . . . . . . . . . . . . . . . . . . . . .36
6.2.1. Security Considerations. . . . . . . . . . . . 36
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 38
8. Normative References . . . . . . . . . . . . . . . . . . . 39
9. Informative References . . . . . . . . . . . . . . . . . . 41
10.Security Considerations. . . . . . . . . . . . . . . . . . 42
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 43
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 44
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 43
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 44
All RFCs are required by RFC 2223 to contain a Security Considerations section. The purpose of this is both to encourage document authors to consider security in their designs and to inform the reader of relevant security issues. This memo is intended to provide guidance to RFC authors in service of both ends.
RFC 2223要求所有RFC包含安全注意事项部分。这样做的目的是鼓励文档作者在设计中考虑安全性，并向读者告知相关的安全问题。本备忘录旨在为服务于双方的RFC作者提供指导。
This document is structured in three parts. The first is a combination security tutorial and definition of common terms; the second is a series of guidelines for writing Security Considerations; the third is a series of examples.
本文件由三部分组成。第一个是组合安全教程和通用术语的定义；第二个是关于编写安全注意事项的一系列指南；第三个是一系列的例子。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[关键词]中的描述进行解释。
Most people speak of security as if it were a single monolithic property of a protocol or system, however, upon reflection, one realizes that it is clearly not true. Rather, security is a series of related but somewhat independent properties. Not all of these properties are required for every application.
大多数人在谈论安全性时，就好像它是一个协议或系统的单一整体属性一样，然而，经过反思，人们意识到这显然不是真的。相反，安全性是一系列相关但在某种程度上是独立的属性。并非所有这些属性都是每个应用程序所必需的。
We can loosely divide security goals into those related to protecting communications (COMMUNICATION SECURITY, also known as COMSEC) and those relating to protecting systems (ADMINISTRATIVE SECURITY or SYSTEM SECURITY). Since communications are carried out by systems and access to systems is through communications channels, these goals obviously interlock, but they can also be independently provided.
我们可以将安全目标大致分为与保护通信相关的目标（通信安全，也称为通信安全）和与保护系统相关的目标（管理安全或系统安全）。由于通信是由系统执行的，而对系统的访问是通过通信通道进行的，因此这些目标显然是互锁的，但它们也可以独立提供。
Different authors partition the goals of communication security differently. The partitioning we've found most useful is to divide them into three major categories: CONFIDENTIALITY, DATA INTEGRITY and PEER ENTITY AUTHENTICATION.
不同的作者对通信安全的目标进行了不同的划分。我们发现最有用的分区是将它们分为三大类：机密性、数据完整性和对等实体身份验证。
When most people think of security, they think of CONFIDENTIALITY. Confidentiality means that your data is kept secret from unintended listeners. Usually, these listeners are simply eavesdroppers. When an adversary taps your phone, it poses a risk to your confidentiality.
当大多数人想到安全性时，他们想到的是保密性。机密性意味着您的数据对无意的侦听器保密。通常，这些听众只是窃听者。当对手窃听你的电话时，会给你的保密性带来风险。
Obviously, if you have secrets, then you are probably concerned about others discovering them. Thus, at the very least, you want to maintain confidentiality. When you see spies in the movies go into the bathroom and turn on all the water to foil bugging, the property they're looking for is confidentiality.
显然，如果你有秘密，那么你可能会担心别人发现它们。因此，至少，您希望保持机密性。当你看到电影中的间谍走进浴室，打开所有的水来阻止窃听，他们要找的是机密。
The second primary goal is DATA INTEGRITY. The basic idea here is that we want to make sure that the data we receive is the same data that the sender has sent. In paper-based systems, some data integrity comes automatically. When you receive a letter written in pen you can be fairly certain that no words have been removed by an attacker because pen marks are difficult to remove from paper. However, an attacker could have easily added some marks to the paper and completely changed the meaning of the message. Similarly, it's easy to shorten the page to truncate the message.
第二个主要目标是数据完整性。这里的基本思想是，我们希望确保我们收到的数据与发送方发送的数据相同。在基于纸张的系统中，一些数据完整性是自动实现的。当你收到一封用钢笔写的信时，你可以相当肯定攻击者没有删除任何文字，因为笔迹很难从纸上删除。然而，攻击者可能很容易在纸上添加一些标记，并完全改变了消息的含义。同样，缩短页面以截断消息也很容易。
On the other hand, in the electronic world, since all bits look alike, it's trivial to tamper with messages in transit. You simply remove the message from the wire, copy out the parts you like, add whatever data you want, and generate a new message of your choosing, and the recipient is no wiser. This is the moral equivalent of the attacker taking a letter you wrote, buying some new paper and recopying the message, changing it as he does it. It's just a lot easier to do electronically since all bits look alike.
另一方面，在电子世界中，由于所有比特看起来都很相似，所以在传输过程中篡改消息就很容易了。你只需从网络上删除消息，复制出你喜欢的部分，添加你想要的任何数据，然后生成一条你选择的新消息，接收者也就不那么聪明了。这在道德上相当于攻击者拿走了你写的一封信，买了一些新的纸，重新复制了信息，并在他做的时候更改了它。因为所有的比特看起来都是一样的，所以用电子方式做起来就容易多了。
The third property we're concerned with is PEER ENTITY AUTHENTICATION. What we mean by this is that we know that one of the endpoints in the communication is the one we intended. Without peer entity authentication, it's very difficult to provide either confidentiality or data integrity. For instance, if we receive a message from Alice, the property of data integrity doesn't do us much good unless we know that it was in fact sent by Alice and not the attacker. Similarly, if we want to send a confidential message to Bob, it's not of much value to us if we're actually sending a confidential message to the attacker.
我们关注的第三个属性是对等实体身份验证。我们的意思是，我们知道通信中的一个端点就是我们想要的端点。如果没有对等实体身份验证，则很难提供机密性或数据完整性。例如，如果我们收到来自Alice的消息，数据完整性属性对我们没有多大好处，除非我们知道它实际上是Alice而不是攻击者发送的。类似地，如果我们想向Bob发送一条机密消息，如果我们真的向攻击者发送一条机密消息，那么它对我们没有多大价值。
Note that peer entity authentication can be provided asymmetrically. When you call someone on the phone, you can be fairly certain that you have the right person -- or at least that you got a person who's actually at the phone number you called. On the other hand, if they don't have caller ID, then the receiver of a phone call has no idea who's calling them. Calling someone on the phone is an example of recipient authentication, since you know who the recipient of the call is, but they don't know anything about the sender.
请注意，对等实体身份验证可以不对称提供。当你打电话给某人时，你可以相当确定你找到了合适的人——或者至少你找到了一个与你所拨打的电话号码相符的人。另一方面，如果他们没有来电显示，那么电话的接收者就不知道是谁在给他们打电话。打电话给某人是收件人身份验证的一个例子，因为你知道谁是电话的收件人，但他们对发件人一无所知。
In messaging situations, you often wish to use peer entity authentication to establish the identity of the sender of a certain message. In such contexts, this property is called DATA ORIGIN AUTHENTICATION.
在消息传递情况下，您通常希望使用对等实体身份验证来确定特定消息的发送者的身份。在这种情况下，此属性称为数据源身份验证。
A system that provides endpoint authentication allows one party to be certain of the identity of someone with whom he is communicating. When the system provides data integrity a receiver can be sure of both the sender's identity and that he is receiving the data that that sender meant to send. However, he cannot necessarily demonstrate this fact to a third party. The ability to make this demonstration is called NON-REPUDIATION.
提供端点身份验证的系统允许一方确定与他通信的人的身份。当系统提供数据完整性时，接收者可以确定发送者的身份以及他正在接收发送者打算发送的数据。然而，他不一定向第三方证明这一事实。进行此演示的能力称为不可否认性。
There are many situations in which non-repudiation is desirable. Consider the situation in which two parties have signed a contract which one party wishes to unilaterally abrogate. He might simply claim that he had never signed it in the first place. Non-repudiation prevents him from doing so, thus protecting the counterparty.
在许多情况下，不可抵赖性是可取的。考虑双方签订了一方希望单方废除的合同的情况。他可能会简单地说，他一开始从未签署过。不可抵赖性阻止他这样做，从而保护对方。
Unfortunately, non-repudiation can be very difficult to achieve in practice and naive approaches are generally inadequate. Section 4.3 describes some of the difficulties, which generally stem from the fact that the interests of the two parties are not aligned -- one party wishes to prove something that the other party wishes to deny.
不幸的是，不可抵赖性在实践中很难实现，而天真的方法通常是不够的。第4.3节描述了一些困难，这些困难通常源于双方利益不一致的事实——一方希望证明另一方希望否认的事情。
In general, systems security is concerned with protecting one's machines and data. The intent is that machines should be used only by authorized users and for the purposes that the owners intend. Furthermore, they should be available for those purposes. Attackers should not be able to deprive legitimate users of resources.
一般来说，系统安全与保护机器和数据有关。其目的是，机器应仅由授权用户使用，并用于所有者打算的目的。此外，它们应可用于这些目的。攻击者不能剥夺合法用户的资源。
Most systems are not intended to be completely accessible to the public. Rather, they are intended to be used only by certain authorized individuals. Although many Internet services are available to all Internet users, even those servers generally offer a larger subset of services to specific users. For instance, Web Servers often will serve data to any user, but restrict the ability to modify pages to specific users. Such modifications by the general public would be UNAUTHORIZED USAGE.
大多数系统并不打算完全向公众开放。相反，它们只供某些授权人员使用。尽管许多互联网服务可供所有互联网用户使用，但即使是这些服务器通常也为特定用户提供更大的服务子集。例如，Web服务器通常会向任何用户提供数据，但会限制特定用户修改页面的能力。公众的这种修改将是未经授权的使用。
Being an authorized user does not mean that you have free run of the system. As we said above, some activities are restricted to authorized users, some to specific users, and some activities are generally forbidden to all but administrators. Moreover, even activities which are in general permitted might be forbidden in some cases. For instance, users may be permitted to send email but forbidden from sending files above a certain size, or files which contain viruses. These are examples of INAPPROPRIATE USAGE.
作为授权用户并不意味着您可以自由运行系统。如上所述，有些活动仅限于授权用户，有些活动限于特定用户，有些活动通常禁止管理员以外的所有人进行。此外，在某些情况下，甚至一般允许的活动也可能被禁止。例如，可能允许用户发送电子邮件，但禁止发送超过一定大小的文件或包含病毒的文件。这些都是不当使用的例子。
Recall that our third goal was that the system should be available to legitimate users. A broad variety of attacks are possible which threaten such usage. Such attacks are collectively referred to as DENIAL OF SERVICE attacks. Denial of service attacks are often very easy to mount and difficult to stop. Many such attacks are designed to consume machine resources, making it difficult or impossible to serve legitimate users. Other attacks cause the target machine to crash, completely denying service to users.
回想一下，我们的第三个目标是该系统应可供合法用户使用。可能会有各种各样的攻击威胁到这种使用。此类攻击统称为拒绝服务攻击。拒绝服务攻击通常很容易发起，也很难阻止。许多此类攻击旨在消耗机器资源，使其难以或不可能为合法用户提供服务。其他攻击导致目标计算机崩溃，完全拒绝向用户提供服务。
A THREAT MODEL describes the capabilities that an attacker is assumed to be able to deploy against a resource. It should contain such information as the resources available to an attacker in terms of information, computing capability, and control of the system. The purpose of a threat model is twofold. First, we wish to identify the threats we are concerned with. Second, we wish to rule some threats explicitly out of scope. Nearly every security system is vulnerable to a sufficiently dedicated and resourceful attacker.
威胁模型描述了假定攻击者能够针对资源部署的能力。它应该包含攻击者在信息、计算能力和系统控制方面可用的资源等信息。威胁模型的目的有两个。首先，我们希望确定我们所关注的威胁。第二，我们希望将一些威胁明确排除在范围之外。几乎每个安全系统都容易受到足够专注和足智多谋的攻击者的攻击。
The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when one of the end-systems has been compromised is
互联网环境有一个相当容易理解的威胁模型。通常，我们假设参与协议交换的终端系统本身没有受到损害。当一个终端系统受到威胁时，保护其免受攻击是必要的
extraordinarily difficult. It is, however, possible to design protocols which minimize the extent of the damage done under these circumstances.
非常困难。然而，可以设计将这些情况下造成的损害程度降至最低的协议。
By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate. This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine. Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are.
相比之下，我们假设攻击者几乎完全控制了终端系统通信的通信信道。这意味着攻击者可以读取网络上的任何PDU（协议数据单元），并在无法检测到的情况下删除、更改或将伪造数据包注入网络。这包括能够生成看起来来自可信机器的数据包。因此，即使您希望与之通信的终端系统本身是安全的，因特网环境也不能保证声称来自该系统的数据包实际上是安全的。
It's important to realize that the meaning of a PDU is different at different levels. At the IP level, a PDU means an IP packet. At the TCP level, it means a TCP segment. At the application layer, it means some kind of application PDU. For instance, at the level of email, it might either mean an RFC-822 message or a single SMTP command. At the HTTP level, it might mean a request or response.
重要的是要认识到PDU的含义在不同的层次上是不同的。在IP级别，PDU表示IP数据包。在TCP级别，它表示TCP段。在应用层，它意味着某种应用程序PDU。例如，在电子邮件级别，它可能表示RFC-822消息或单个SMTP命令。在HTTP级别，它可能意味着请求或响应。
As we've said, a resourceful and dedicated attacker can control the entire communications channel. However, a large number of attacks can be mounted by an attacker with fewer resources. A number of currently known attacks can be mounted by an attacker with limited control of the network. For instance, password sniffing attacks can be mounted by an attacker who can only read arbitrary packets. This is generally referred to as a PASSIVE ATTACK [INTAUTH].
正如我们所说的，一个足智多谋、专心致志的攻击者可以控制整个通信通道。但是，攻击者可以使用较少的资源发动大量攻击。在网络控制有限的情况下，攻击者可以发起许多当前已知的攻击。例如，只能读取任意数据包的攻击者可以发起密码嗅探攻击。这通常被称为被动攻击[INTAUTH]。
By contrast, Morris' sequence number guessing attack [SEQNUM] can be mounted by an attacker who can write but not read arbitrary packets. Any attack which requires the attacker to write to the network is known as an ACTIVE ATTACK.
相反，Morris的序列号猜测攻击[SEQNUM]可以由能够写入但不能读取任意数据包的攻击者发起。任何需要攻击者写入网络的攻击都称为主动攻击。
Thus, a useful way of organizing attacks is to divide them based on the capabilities required to mount the attack. The rest of this section describes these categories and provides some examples of each category.
因此，组织攻击的一种有用方法是根据发动攻击所需的能力来划分攻击。本节其余部分将介绍这些类别，并提供每个类别的一些示例。
In a passive attack, the attacker reads packets off the network but does not write them. The simplest way to mount such an attack is to simply be on the same LAN as the victim. On most common LAN configurations, including Ethernet, 802.3, and FDDI, any machine on the wire can read all traffic destined for any other machine on the
在被动攻击中，攻击者从网络上读取数据包，但不写入数据包。发起此类攻击的最简单方法就是与受害者在同一局域网上。在最常见的LAN配置（包括以太网、802.3和FDDI）上，线路上的任何机器都可以读取发送给网络上任何其他机器的所有通信量
same LAN. Note that switching hubs make this sort of sniffing substantially more difficult, since traffic destined for a machine only goes to the network segment which that machine is on.
同一个局域网。请注意，交换集线器使这种嗅探变得更加困难，因为发送给机器的通信量只流向该机器所在的网段。
Similarly, an attacker who has control of a host in the communications path between two victim machines is able to mount a passive attack on their communications. It is also possible to compromise the routing infrastructure to specifically arrange that traffic passes through a compromised machine. This might involve an active attack on the routing infrastructure to facilitate a passive attack on a victim machine.
类似地，在两台受害机器之间的通信路径中控制主机的攻击者能够对其通信发起被动攻击。也有可能破坏路由基础设施，专门安排流量通过受损机器。这可能涉及对路由基础设施的主动攻击，以促进对受害者机器的被动攻击。
Wireless communications channels deserve special consideration, especially with the recent and growing popularity of wireless-based LANs, such as those using 802.11. Since the data is simply broadcast on well known radio frequencies, an attacker simply needs to be able to receive those transmissions. Such channels are especially vulnerable to passive attacks. Although many such channels include cryptographic protection, it is often of such poor quality as to be nearly useless [WEP].
无线通信信道值得特别考虑，特别是随着基于无线的局域网（如使用802.11的局域网）的最近和日益普及。由于数据只是在众所周知的无线电频率上广播，攻击者只需要能够接收这些传输。此类通道尤其容易受到被动攻击。尽管许多这样的通道包括密码保护，但它的质量往往很差，几乎没有用处[WEP]。
In general, the goal of a passive attack is to obtain information which the sender and receiver would prefer to remain private. This private information may include credentials useful in the electronic world and/or passwords or credentials useful in the outside world, such as confidential business information.
一般来说，被动攻击的目标是获取发送方和接收方希望保密的信息。该私人信息可包括在电子世界中有用的凭证和/或在外部世界中有用的密码或凭证，例如机密商业信息。
The classic example of passive attack is sniffing some inherently private data off of the wire. For instance, despite the wide availability of SSL, many credit card transactions still traverse the Internet in the clear. An attacker could sniff such a message and recover the credit card number, which can then be used to make fraudulent transactions. Moreover, confidential business information is routinely transmitted over the network in the clear in email.
被动攻击的典型例子是从网络上嗅探一些固有的私有数据。例如，尽管SSL的广泛可用性，许多信用卡交易仍然在互联网上进行。攻击者可以嗅出此类消息并恢复信用卡号，然后利用该信用卡号进行欺诈交易。此外，机密商业信息通常以电子邮件形式通过网络传输。
Another example of a passive attack is PASSWORD SNIFFING. Password sniffing is directed towards obtaining unauthorized use of resources. Many protocols, including [TELNET], [POP], and [NNTP] use a shared password to authenticate the client to the server. Frequently, this password is transmitted from the client to the server in the clear over the communications channel. An attacker who can read this traffic can therefore capture the password and REPLAY it. In other words, the attacker can initiate a connection to the server and pose as the client and login using the captured password.
被动攻击的另一个例子是密码嗅探。密码嗅探旨在获得未经授权的资源使用。许多协议，包括[TELNET]、[POP]和[NNTP]都使用共享密码来向服务器验证客户端。通常，此密码通过通信通道以明文形式从客户端传输到服务器。因此，能够读取此流量的攻击者可以捕获密码并重播密码。换句话说，攻击者可以启动与服务器的连接，并冒充客户端，使用捕获的密码登录。
Note that although the login phase of the attack is active, the actual password capture phase is passive. Moreover, unless the server checks the originating address of connections, the login phase does not require any special control of the network.
请注意，尽管攻击的登录阶段是主动的，但实际的密码捕获阶段是被动的。此外，除非服务器检查连接的原始地址，否则登录阶段不需要对网络进行任何特殊控制。
Many cryptographic protocols are subject to OFFLINE ATTACKS. In such a protocol, the attacker recovers data which has been processed using the victim's secret key and then mounts a cryptanalytic attack on that key. Passwords make a particularly vulnerable target because they are typically low entropy. A number of popular password-based challenge response protocols are vulnerable to DICTIONARY ATTACK. The attacker captures a challenge-response pair and then proceeds to try entries from a list of common words (such as a dictionary file) until he finds a password that produces the right response.
许多加密协议都会受到脱机攻击。在这种协议中，攻击者恢复使用受害者密钥处理的数据，然后对该密钥发起密码分析攻击。密码是一个特别容易受到攻击的目标，因为它们通常是低熵的。许多流行的基于密码的质询-响应协议容易受到字典攻击。攻击者捕获质询-响应对，然后继续尝试常用词列表（如字典文件）中的条目，直到找到产生正确响应的密码。
A similar such attack can be mounted on a local network when NIS is used. The Unix password is crypted using a one-way function, but tools exist to break such crypted passwords [KLEIN]. When NIS is used, the crypted password is transmitted over the local network and an attacker can thus sniff the password and attack it.
当使用NIS时，可以在本地网络上发起类似的攻击。Unix密码是使用单向函数加密的，但有工具可以破解此类加密密码[KLEIN]。当使用NIS时，加密密码将通过本地网络传输，因此攻击者可以嗅探密码并对其进行攻击。
Historically, it has also been possible to exploit small operating system security holes to recover the password file using an active attack. These holes can then be bootstrapped into an actual account by using the aforementioned offline password recovery techniques. Thus we combine a low-level active attack with an offline passive attack.
历史上，也有可能利用操作系统的小安全漏洞，通过主动攻击恢复密码文件。然后，可以使用上述离线密码恢复技术将这些漏洞引导到实际帐户中。因此，我们将低级主动攻击与离线被动攻击相结合。
When an attack involves writing data to the network, we refer to this as an ACTIVE ATTACK. When IP is used without IPsec, there is no authentication for the sender address. As a consequence, it's straightforward for an attacker to create a packet with a source address of his choosing. We'll refer to this as a SPOOFING ATTACK.
当攻击涉及将数据写入网络时，我们将其称为主动攻击。如果在没有IPsec的情况下使用IP，则不会对发件人地址进行身份验证。因此，攻击者可以直接使用自己选择的源地址创建数据包。我们将此称为欺骗攻击。
Under certain circumstances, such a packet may be screened out by the network. For instance, many packet filtering firewalls screen out all packets with source addresses on the INTERNAL network that arrive on the EXTERNAL interface. Note, however, that this provides no protection against an attacker who is inside the firewall. In general, designers should assume that attackers can forge packets.
在某些情况下，这样的分组可能被网络屏蔽掉。例如，许多包过滤防火墙会屏蔽所有到达外部接口的内部网络上具有源地址的包。但是，请注意，这无法防止防火墙内的攻击者。通常，设计者应该假设攻击者可以伪造数据包。
However, the ability to forge packets does not go hand in hand with the ability to receive arbitrary packets. In fact, there are active attacks that involve being able to send forged packets but not receive the responses. We'll refer to these as BLIND ATTACKS.
然而，伪造数据包的能力与接收任意数据包的能力并不同步。事实上，存在主动攻击，包括能够发送伪造数据包但无法接收响应。我们将这些称为盲目攻击。
Note that not all active attacks require forging addresses. For instance, the TCP SYN denial of service attack [TCPSYN] can be mounted successfully without disguising the sender's address. However, it is common practice to disguise one's address in order to conceal one's identity if an attack is discovered.
请注意，并非所有主动攻击都需要伪造地址。例如，TCP SYN拒绝服务攻击[TCPSYN]可以在不伪装发送方地址的情况下成功装载。然而，如果发现攻击，通常会伪装自己的地址以隐藏自己的身份。
Each protocol is susceptible to specific active attacks, but experience shows that a number of common patterns of attack can be adapted to any given protocol. The next sections describe a number of these patterns and give specific examples of them as applied to known protocols.
每个协议都容易受到特定的主动攻击，但经验表明，许多常见的攻击模式可以适应任何给定的协议。下一节将描述其中的一些模式，并给出应用于已知协议的具体示例。
In a REPLAY ATTACK, the attacker records a sequence of messages off of the wire and plays them back to the party which originally received them. Note that the attacker does not need to be able to understand the messages. He merely needs to capture and retransmit them.
在重播攻击中，攻击者会记录一系列的无线消息，并将其回放给最初接收消息的一方。请注意，攻击者不需要能够理解这些消息。他只需要捕获并重新传输它们。
For example, consider the case where an S/MIME message is being used to request some service, such as a credit card purchase or a stock trade. An attacker might wish to have the service executed twice, if only to inconvenience the victim. He could capture the message and replay it, even though he can't read it, causing the transaction to be executed twice.
例如，考虑S/MIME消息用于请求某些服务的情况，例如信用卡购买或股票交易。攻击者可能希望执行两次服务，即使只是为了给受害者带来不便。他可以捕获消息并重放它，即使他无法读取它，从而导致事务执行两次。
In a MESSAGE INSERTION attack, the attacker forges a message with some chosen set of properties and injects it into the network. Often this message will have a forged source address in order to disguise the identity of the attacker.
在消息插入攻击中，攻击者伪造具有选定属性集的消息，并将其注入网络。通常，此消息会带有伪造的源地址，以伪装攻击者的身份。
For example, a denial-of-service attack can be mounted by inserting a series of spurious TCP SYN packets directed towards the target host. The target host responds with its own SYN and allocates kernel data structures for the new connection. The attacker never completes the 3-way handshake, so the allocated connection endpoints just sit there taking up kernel memory. Typical TCP stack implementations only
例如，可以通过插入一系列指向目标主机的虚假TCP SYN数据包来发起拒绝服务攻击。目标主机使用自己的SYN进行响应，并为新连接分配内核数据结构。攻击者永远不会完成3路握手，因此分配的连接端点只会占用内核内存。仅限典型的TCP堆栈实现
allow some limited number of connections in this "half-open" state and when this limit is reached, no more connections can be initiated, even from legitimate hosts. Note that this attack is a blind attack, since the attacker does not need to process the victim's SYNs.
在此“半开放”状态下允许有限数量的连接，当达到此限制时，无法启动更多连接，即使来自合法主机。请注意，此攻击是一种盲攻击，因为攻击者不需要处理受害者的SYN。
In a MESSAGE DELETION attack, the attacker removes a message from the wire. Morris' sequence number guessing attack [SEQNUM] often requires a message deletion attack to be performed successfully. In this blind attack, the host whose address is being forged will receive a spurious TCP SYN packet from the host being attacked. Receipt of this SYN packet generates a RST, which would tear the illegitimate connection down. In order to prevent this host from sending a RST so that the attack can be carried out successfully, Morris describes flooding this host to create queue overflows such that the SYN packet is lost and thus never responded to.
在消息删除攻击中，攻击者会从线路中删除消息。Morris的序列号猜测攻击[SEQNUM]通常需要成功执行消息删除攻击。在这种盲攻击中，地址被伪造的主机将收到来自被攻击主机的虚假TCP SYN数据包。收到此SYN数据包将生成RST，这将中断非法连接。为了防止此主机发送RST，以便成功执行攻击，Morris描述了洪泛此主机以创建队列溢出，从而导致SYN数据包丢失，因此从未响应。
In a MESSAGE MODIFICATION attack, the attacker removes a message from the wire, modifies it, and reinjects it into the network. This sort of attack is particularly useful if the attacker wants to send some of the data in the message but also wants to change some of it.
在消息修改攻击中，攻击者从网络中删除消息，对其进行修改，然后将其重新注入网络。如果攻击者希望发送消息中的某些数据，但又希望更改其中的某些数据，则这种攻击尤其有用。
Consider the case where the attacker wants to attack an order for goods placed over the Internet. He doesn't have the victim's credit card number so he waits for the victim to place the order and then replaces the delivery address (and possibly the goods description) with his own. Note that this particular attack is known as a CUT-AND-PASTE attack since the attacker cuts the credit card number out of the original message and pastes it into the new message.
考虑攻击者想要攻击放置在因特网上的商品的订单的情况。他没有受害人的信用卡号码，所以他等待受害人下订单，然后用自己的地址替换送货地址（可能还有货物描述）。请注意，此特定攻击称为剪切粘贴攻击，因为攻击者将信用卡号从原始邮件中剪切出来并粘贴到新邮件中。
Another interesting example of a cut-and-paste attack is provided by [IPSPPROB]. If IPsec ESP is used without any MAC then it is possible for the attacker to read traffic encrypted for a victim on the same machine. The attacker attaches an IP header corresponding to a port he controls onto the encrypted IP packet. When the packet is received by the host it will automatically be decrypted and forwarded to the attacker's port. Similar techniques can be used to mount a session hijacking attack. Both of these attacks can be avoided by always using message authentication when you use encryption. Note that this attack only works if (1) no MAC check is being used, since this attack generates damaged packets (2) a host-to-host SA is being used, since a user-to-user SA will result in an inconsistency between the port associated with the SA and the target port. If the receiving machine is single-user than this attack is infeasible.
[IPSPPROB]提供了剪切粘贴攻击的另一个有趣示例。如果使用IPsec ESP时没有任何MAC，则攻击者有可能在同一台计算机上读取为受害者加密的流量。攻击者将与其控制的端口对应的IP头附加到加密的IP数据包上。当主机收到数据包时，它将自动解密并转发到攻击者的端口。类似的技术可用于发起会话劫持攻击。使用加密时始终使用消息身份验证可以避免这两种攻击。请注意，此攻击仅在（1）未使用MAC检查时有效，因为此攻击会生成损坏的数据包（2）正在使用主机对主机SA，因为用户对用户SA将导致与SA关联的端口与目标端口之间不一致。如果接收机器是单用户，则此攻击不可行。
A MAN-IN-THE-MIDDLE attack combines the above techniques in a special form: The attacker subverts the communication stream in order to pose as the sender to receiver and the receiver to the sender:
中间人攻击以一种特殊形式结合了上述技术：攻击者破坏通信流，以充当发送方对接收方和接收方对发送方的角色：
What Alice and Bob think:
Alice <----------------------------------------------> Bob
What Alice and Bob think:
Alice <----------------------------------------------> Bob
What's happening:
Alice <----------------> Attacker <----------------> Bob
What's happening:
Alice <----------------> Attacker <----------------> Bob
This differs fundamentally from the above forms of attack because it attacks the identity of the communicating parties, rather than the data stream itself. Consequently, many techniques which provide integrity of the communications stream are insufficient to protect against man-in-the-middle attacks.
这与上述形式的攻击根本不同，因为它攻击的是通信方的身份，而不是数据流本身。因此，许多提供通信流完整性的技术不足以防止中间人攻击。
Man-in-the-middle attacks are possible whenever a protocol lacks PEER ENTITY AUTHENTICATION. For instance, if an attacker can hijack the client TCP connection during the TCP handshake (perhaps by responding to the client's SYN before the server does), then the attacker can open another connection to the server and begin a man-in-the-middle attack. It is also trivial to mount man-in-the-middle attacks on local networks via ARP spoofing -- the attacker forges an ARP with the victim's IP address and his own MAC address. Tools to mount this sort of attack are readily available.
当协议缺少对等实体身份验证时，中间人攻击是可能的。例如，如果攻击者可以在TCP握手期间劫持客户端TCP连接（可能通过在服务器之前响应客户端的SYN），则攻击者可以打开与服务器的另一个连接，并开始中间人攻击。通过ARP欺骗在本地网络上发起中间人攻击也很简单——攻击者利用受害者的IP地址和自己的MAC地址伪造ARP。安装此类攻击的工具随时可用。
Note that it is only necessary to authenticate one side of the transaction in order to prevent man-in-the-middle attacks. In such a situation the the peers can establish an association in which only one peer is authenticated. In such a system, an attacker can initiate an association posing as the unauthenticated peer but cannot transmit or access data being sent on a legitimate connection. This is an acceptable situation in contexts such as Web e-commerce where only the server needs to be authenticated (or the client is independently authenticated via some non-cryptographic mechanism such as a credit card number).
请注意，为了防止中间人攻击，只需要验证事务的一方。在这种情况下，对等方可以建立只有一个对等方被认证的关联。在这样的系统中，攻击者可以冒充未经身份验证的对等方发起关联，但无法传输或访问合法连接上发送的数据。在Web电子商务等环境中，这是一种可接受的情况，其中仅需要对服务器进行身份验证（或者通过一些非加密机制（如信用卡号）对客户端进行独立身份验证）。
In practice, the assumption that it's equally easy for an attacker to read and generate all packets is false, since the Internet is not fully connected. This has two primary implications.
实际上，假设攻击者读取和生成所有数据包同样容易是错误的，因为互联网没有完全连接。这有两个主要含义。
In order for a datagram to be transmitted from one host to another, it generally must traverse some set of intermediate links and gateways. Such gateways are naturally able to read, modify, or remove any datagram transmitted along that path. This makes it much easier to mount a wide variety of attacks if you are on-path.
为了将数据报从一台主机传输到另一台主机，它通常必须穿过一组中间链路和网关。这样的网关自然能够读取、修改或删除沿该路径传输的任何数据报。这样，如果您在路径上，就更容易发起各种各样的攻击。
Off-path hosts can, of course, transmit arbitrary datagrams that appear to come from any hosts but cannot necessarily receive datagrams intended for other hosts. Thus, if an attack depends on being able to receive data, off-path hosts must first subvert the topology in order to place themselves on-path. This is by no means impossible but is not necessarily trivial.
当然，非路径主机可以传输看似来自任何主机的任意数据报，但不一定能接收到用于其他主机的数据报。因此，如果攻击取决于是否能够接收数据，则非路径主机必须首先破坏拓扑，以便将自己置于路径上。这绝非不可能，但也不一定是微不足道的。
Applications protocol designers MUST NOT assume that all attackers will be off-path. Where possible, protocols SHOULD be designed to resist attacks from attackers who have complete control of the network. However, designers are expected to give more weight to attacks which can be mounted by off-path attackers as well as on-path ones.
应用程序协议设计人员不得假设所有攻击者都将离开路径。在可能的情况下，协议的设计应能抵抗完全控制网络的攻击者的攻击。然而，设计者们希望能够更加重视能够被路径外攻击者和路径上攻击者发起的攻击。
One specialized case of on-path is being on the same link. In some situations, it's desirable to distinguish between hosts who are on the local network and those who are not. The standard technique for this is verifying the IP TTL value [IP]. Since the TTL must be decremented by each forwarder, a protocol can demand that TTL be set to 255 and that all receivers verify the TTL. A receiver then has some reason to believe that conforming packets are from the same link. Note that this technique must be used with care in the presence of tunneling systems, since such systems may pass packets without decrementing TTL.
路径上的一个特殊情况是位于同一链接上。在某些情况下，需要区分本地网络上的主机和非本地网络上的主机。这方面的标准技术是验证IP TTL值[IP]。由于TTL必须由每个转发器递减，协议可以要求将TTL设置为255，并且所有接收器验证TTL。然后，接收器有理由相信一致性分组来自同一链路。注意，在存在隧道系统的情况下必须小心使用该技术，因为此类系统可以在不降低TTL的情况下传递数据包。
Although each system's security requirements are unique, certain common requirements appear in a number of protocols. Often, when naive protocol designers are faced with these requirements, they choose an obvious but insecure solution even though better solutions are available. This section describes a number of issues seen in many protocols and the common pieces of security technology that may be useful in addressing them.
虽然每个系统的安全要求都是独特的，但在许多协议中都会出现某些共同的要求。通常，当天真的协议设计者面对这些需求时，他们会选择一个明显但不安全的解决方案，即使有更好的解决方案可用。本节描述了许多协议中出现的一些问题，以及可能有助于解决这些问题的常见安全技术。
Essentially every system which wants to control access to its resources needs some way to authenticate users. A nearly uncountable number of such mechanisms have been designed for this purpose. The next several sections describe some of these techniques.
本质上，每个想要控制其资源访问的系统都需要某种方式来验证用户。为此目的设计了几乎数不清的此类机构。接下来的几节将介绍其中的一些技术。
The most common access control mechanism is simple USERNAME/PASSWORD The user provides a username and a reusable password to the host which he wishes to use. This system is vulnerable to a simple passive attack where the attacker sniffs the password off the wire and then initiates a new session, presenting the password. This threat can be mitigated by hosting the protocol over an encrypted connection such as TLS or IPSEC. Unprotected (plaintext) username/password systems are not acceptable in IETF standards.
最常见的访问控制机制是简单的用户名/密码。用户向希望使用的主机提供用户名和可重复使用的密码。此系统容易受到简单的被动攻击，攻击者会嗅出线路上的密码，然后启动一个新会话，并提供密码。通过在加密连接（如TLS或IPSEC）上托管协议，可以缓解此威胁。IETF标准中不接受无保护（明文）用户名/密码系统。
Systems which desire greater security than USERNAME/PASSWORD often employ either a ONE TIME PASSWORD [OTP] scheme or a CHALLENGE-RESPONSE. In a one time password scheme, the user is provided with a list of passwords, which must be used in sequence, one time each. (Often these passwords are generated from some secret key so the user can simply compute the next password in the sequence.) SecureID and DES Gold are variants of this scheme. In a challenge-response scheme, the host and the user share some secret (which often is represented as a password). In order to authenticate the user, the host presents the user with a (randomly generated) challenge. The user computes some function based on the challenge and the secret and provides that to the host, which verifies it. Often this computation is performed in a handheld device, such as a DES Gold card.
需要比用户名/密码更高安全性的系统通常采用一次性密码[OTP]方案或质询响应。在一次性密码方案中，向用户提供密码列表，必须按顺序使用，每次一次。（通常这些密码是从某个密钥生成的，因此用户可以简单地计算序列中的下一个密码。）SecureID和DES Gold是此方案的变体。在质询-响应方案中，主机和用户共享一些秘密（通常表示为密码）。为了对用户进行身份验证，主机向用户提供（随机生成的）质询。用户根据质询和秘密计算一些函数，并将其提供给主机，由主机进行验证。这种计算通常在手持设备（如DES金卡）中执行。
Both types of scheme provide protection against replay attack, but often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of passive attack): As previously mentioned, often the one-time password or response is computed from a shared secret. If the attacker knows the function being used, he can simply try all possible shared secrets until he finds one that produces the right output. This is made easier if the shared secret is a password, in which case he can mount a DICTIONARY ATTACK -- meaning that he tries a list of common words (or strings) rather than just random strings.
这两种类型的方案都提供了防止重放攻击的保护，但通常仍然容易受到脱机密钥搜索攻击（一种被动攻击）：如前所述，一次性密码或响应通常是根据共享密钥计算的。如果攻击者知道正在使用的函数，他可以简单地尝试所有可能的共享秘密，直到找到一个产生正确输出的秘密。如果共享秘密是密码，那么这就更容易了，在这种情况下，他可以发起字典攻击——这意味着他尝试一系列常用词（或字符串），而不仅仅是随机字符串。
These systems are also often vulnerable to an active attack. Unless communication security is provided for the entire session, the attacker can simply wait until authentication has been performed and hijack the connection.
这些系统通常也容易受到主动攻击。除非为整个会话提供通信安全性，否则攻击者只需等待身份验证完成并劫持连接即可。
CHALLENGE-RESPONSE type systems can be made secure against dictionary attack by using randomly generated shared keys instead of user-generated passwords. If the keys are sufficiently large then keysearch attacks become impractical. This approach works best when the keys are configured into the end nodes rather than memorized and typed in by users, since users have trouble remembering sufficiently long keys.
通过使用随机生成的共享密钥而不是用户生成的密码，挑战-响应型系统可以安全地抵御字典攻击。如果密钥足够大，则密钥搜索攻击变得不切实际。当密钥被配置到终端节点而不是由用户记忆和输入时，这种方法效果最好，因为用户很难记住足够长的密钥。
Like password-based systems, shared key systems suffer from management problems. Each pair of communicating parties must have their own agreed-upon key, which leads to there being a lot of keys.
与基于密码的系统一样，共享密钥系统也存在管理问题。每对通信方都必须拥有自己的约定密钥，这导致存在大量密钥。
One approach to solving the large number of keys problem is to use an online "trusted third party" that mediates between the authenticating parties. The trusted third party (generally called a a KEY DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with each party in the system. It first contacts the KDC which gives it a TICKET containing a randomly generated symmetric key encrypted under both peer's keys. Since only the proper peers can decrypt the symmetric key the ticket can be used to establish a trusted association. By far the most popular KDC system is Kerberos [KERBEROS].
解决大量密钥问题的一种方法是使用在线“可信第三方”在认证方之间进行调解。受信任的第三方（通常称为密钥分发中心（KDC））与系统中的每一方共享对称密钥或密码。它首先联系KDC，KDC给它一个票证，其中包含一个随机生成的对称密钥，该密钥在两个对等密钥下加密。由于只有适当的对等方可以解密对称密钥，因此可以使用票据建立可信关联。到目前为止，最流行的KDC系统是Kerberos[Kerberos]。
A simple approach is to have all users have CERTIFICATES [PKIX] which they then use to authenticate in some protocol-specific way, as in [TLS] or [S/MIME]. A certificate is a signed credential binding an entity's identity to its public key. The signer of a certificate is a CERTIFICATE AUTHORITY (CA), whose certificate may itself be signed by some superior CA. In order for this system to work, trust in one or more CAs must be established in an out-of-band fashion. Such CAs are referred to as TRUSTED ROOTS or ROOT CAS. The primary obstacle to this approach in client-server type systems is that it requires clients to have certificates, which can be a deployment problem.
一种简单的方法是让所有用户都拥有[PKIX]证书，然后使用这些证书以某种特定于协议的方式进行身份验证，如[TLS]或[S/MIME]。证书是一种签名凭证，将实体的标识绑定到其公钥。证书的签署者是证书颁发机构（CA），其证书本身可以由某个上级CA签署。为了使该系统工作，必须以带外方式建立对一个或多个CA的信任。此类CA称为受信任根或根CA。在客户机-服务器类型的系统中，这种方法的主要障碍是它要求客户机具有证书，这可能是一个部署问题。
There are ways to do a better job than the schemes mentioned above, but they typically don't add much security unless communications security (at least message integrity) will be employed to secure the connection, because otherwise the attacker can merely hijack the connection after authentication has been performed. A number of protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap a
有比上述方案更好的方法，但它们通常不会增加太多安全性，除非采用通信安全性（至少消息完整性）来保护连接，否则攻击者只能在执行身份验证后劫持连接。许多协议（[EKE]、[SPEKE]、[SRP]）允许安全地引导
user's password into a shared key which can be used as input to a cryptographic protocol. One major obstacle to the deployment of these protocols has been that their Intellectual Property status is extremely unclear. Similarly, the user can authenticate using public key certificates (e.g., S-HTTP client authentication). Typically these methods are used as part of a more complete security protocol.
将用户密码转换为可作为加密协议输入的共享密钥。部署这些议定书的一个主要障碍是其知识产权状况极不清楚。类似地，用户可以使用公钥证书进行身份验证（例如，S-HTTP客户端身份验证）。通常，这些方法被用作更完整的安全协议的一部分。
Host authentication presents a special problem. Quite commonly, the addresses of services are presented using a DNS hostname, for instance as a URL [URL]. When requesting such a service, one has to ensure that the entity that one is talking to not only has a certificate but that that certificate corresponds to the expected identity of the server. The important thing to have is a secure binding between the certificate and the expected hostname.
主机身份验证是一个特殊的问题。通常，服务的地址使用DNS主机名表示，例如URL[URL]。在请求此类服务时，必须确保与之交谈的实体不仅具有证书，而且该证书与服务器的预期标识相对应。重要的是在证书和预期主机名之间有一个安全绑定。
For instance, it is usually not acceptable for the certificate to contain an identity in the form of an IP address if the request was for a given hostname. This does not provide end-to-end security because the hostname-IP mapping is not secure unless secure name resolution [DNSSEC] is being used. This is a particular problem when the hostname is presented at the application layer but the authentication is performed at some lower layer.
例如，如果请求是针对给定主机名的，则通常不允许证书包含IP地址形式的标识。这不提供端到端安全性，因为主机名IP映射不安全，除非使用安全名称解析[DNSSEC]。当主机名在应用程序层显示，但身份验证在较低的层执行时，这是一个特别的问题。
Providing security functionality in a protocol can be difficult. In addition to the problem of choosing authentication and key establishment mechanisms, one needs to integrate it into a protocol. One response to this problem (embodied in IPsec and TLS) is to create a lower-level security protocol and then insist that new protocols be run over that protocol. Another approach that has recently become popular is to design generic application layer security frameworks. The idea is that you design a protocol that allows you to negotiate various security mechanisms in a pluggable fashion. Application protocol designers then arrange to carry the security protocol PDUs in their application protocol. Examples of such frameworks include GSS-API [GSS] and SASL [SASL].
在协议中提供安全功能可能很困难。除了选择认证和密钥建立机制的问题外，还需要将其集成到协议中。对此问题的一个响应（体现在IPsec和TLS中）是创建一个较低级别的安全协议，然后坚持在该协议上运行新协议。最近流行的另一种方法是设计通用的应用层安全框架。其思想是设计一个协议，允许您以可插拔的方式协商各种安全机制。然后，应用程序协议设计者安排在其应用程序协议中携带安全协议PDU。此类框架的示例包括GSS-API[GSS]和SASL[SASL]。
The generic framework approach has a number of problems. First, it is highly susceptible to DOWNGRADE ATTACKS. In a downgrade attack, an active attacker tampers with the negotiation in order to force the parties to negotiate weaker protection than they otherwise would. It's possible to include an integrity check after the negotiation and key establishment have both completed, but the strength of this integrity check is necessarily limited to the weakest common algorithm. This problem exists with any negotiation approach, but
通用框架方法存在许多问题。首先，它极易受到降级攻击。在降级攻击中，主动攻击者篡改协商，以迫使双方协商比其他方式更弱的保护。在协商和密钥建立都完成后，可以包含完整性检查，但此完整性检查的强度必须限于最薄弱的通用算法。任何谈判方法都存在这个问题，但是
generic frameworks exacerbate it by encouraging the application protocol author to just specify the framework rather than think hard about the appropriate underlying mechanisms, particularly since the mechanisms can very widely in the degree of security offered.
通用框架鼓励应用程序协议作者只指定框架，而不是认真考虑适当的底层机制，从而加剧了这种情况，特别是因为这些机制可以在提供的安全程度上广泛应用。
Another problem is that it's not always obvious how the various security features in the framework interact with the application layer protocol. For instance, SASL can be used merely as an authentication framework -- in which case the SASL exchange occurs but the rest of the connection is unprotected, but can also negotiate traffic protection, such as via GSS, as a mechanism. Knowing under what circumstances traffic protection is optional and which it is required requires thinking about the threat model.
另一个问题是，框架中的各种安全特性如何与应用层协议交互并不总是显而易见的。例如，SASL只能用作身份验证框架——在这种情况下，SASL交换发生，但连接的其余部分不受保护，但也可以协商流量保护，例如通过GSS作为一种机制。了解在什么情况下流量保护是可选的，需要考虑威胁模型。
In general, authentication frameworks are most useful in situations where new protocols are being added to systems with pre-existing legacy authentication systems. A framework allows new installations to provide better authentication while not forcing existing sites completely redo their legacy authentication systems. When the security requirements of a system can be clearly identified and only a few forms of authentication are used, choosing a single security mechanism leads to greater simplicity and predictability. In situations where a framework is to be used, designers SHOULD carefully examine the framework's options and specify only the mechanisms that are appropriate for their particular threat model. If a framework is necessary, designers SHOULD choose one of the established ones instead of designing their own.
一般来说，身份验证框架在将新协议添加到具有现有遗留身份验证系统的系统的情况下最有用。框架允许新安装提供更好的身份验证，同时不强制现有站点完全重做其遗留身份验证系统。当系统的安全需求可以清楚地识别，并且只使用了几种形式的身份验证时，选择单一的安全机制将导致更大的简单性和可预测性。在使用框架的情况下，设计师应仔细检查框架的选项，并仅指定适合其特定威胁模型的机制。如果需要一个框架，设计师应该选择一个已建立的框架，而不是设计自己的框架。
The naive approach to non-repudiation is simply to use public-key digital signatures over the content. The party who wishes to be bound (the SIGNING PARTY) digitally signs the message in question. The counterparty (the RELYING PARTY) can later point to the digital signature as proof that the signing party at one point agreed to the disputed message. Unfortunately, this approach is insufficient.
不可否认性的简单方法是在内容上使用公钥数字签名。希望被绑定的一方（签名方）对相关邮件进行数字签名。交易对手（依赖方）可以稍后将数字签名作为签名方在某一点上同意争议信息的证据。不幸的是，这种方法是不够的。
The easiest way for the signing party to repudiate the message is by claiming that his private key has been compromised and that some attacker (though not necessarily the relying party) signed the disputed message. In order to defend against this attack the relying party needs to demonstrate that the signing party's key had not been compromised at the time of the signature. This requires substantial infrastructure, including archival storage of certificate revocation information and timestamp servers to establish the time that the message was signed.
签名方拒绝该消息的最简单方法是声称其私钥已被泄露，并且某些攻击者（尽管不一定是依赖方）签署了有争议的消息。为了防御这种攻击，依赖方需要证明签名方的密钥在签名时没有被泄露。这需要大量的基础设施，包括证书撤销信息的存档存储和时间戳服务器，以确定消息的签名时间。
Additionally, the relying party might attempt to trick the signing party into signing one message while thinking he's signing another. This problem is particularly severe when the relying party controls the infrastructure that the signing party uses for signing, such as in kiosk situations. In many such situations the signing party's key is kept on a smartcard but the message to be signed is displayed by the relying party.
此外，依赖方可能会试图欺骗签署方签署一条消息，同时认为他正在签署另一条消息。当依赖方控制签名方用于签名的基础设施时，此问题尤其严重，例如在kiosk情况下。在许多此类情况下，签名方的密钥保存在智能卡上，但要签名的消息由依赖方显示。
All of these complications make non-repudiation a difficult service to deploy in practice.
所有这些复杂性使得不可否认性在实践中难以部署。
AUTHORIZATION is the process by which one determines whether an authenticated party has permission to access a particular resource or service. Although tightly bound, it is important to realize that authentication and authorization are two separate mechanisms. Perhaps because of this tight coupling, authentication is sometimes mistakenly thought to imply authorization. Authentication simply identifies a party, authorization defines whether they can perform a certain action.
授权是确定经过身份验证的一方是否具有访问特定资源或服务的权限的过程。尽管绑定紧密，但重要的是要认识到身份验证和授权是两种独立的机制。也许由于这种紧密耦合，身份验证有时被错误地认为意味着授权。身份验证只是识别一方，授权定义他们是否可以执行特定的操作。
Authorization necessarily relies on authentication, but authentication alone does not imply authorization. Rather, before granting permission to perform an action, the authorization mechanism must be consulted to determine whether that action is permitted.
授权必然依赖于身份验证，但仅身份验证并不意味着授权。相反，在授予执行操作的权限之前，必须咨询授权机制，以确定该操作是否被允许。
One common form of authorization mechanism is an access control list (ACL), which lists users that are permitted access to a resource. Since assigning individual authorization permissions to each resource is tedious, resources are often hierarchically arranged so that the parent resource's ACL is inherited by child resources. This allows administrators to set top level policies and override them when necessary.
授权机制的一种常见形式是访问控制列表（ACL），它列出了允许访问资源的用户。由于为每个资源分配单独的授权权限非常繁琐，因此资源通常是分层排列的，以便父资源的ACL由子资源继承。这允许管理员设置顶级策略，并在必要时覆盖它们。
While the distinction between authentication and authorization is intuitive when using simple authentication mechanisms such as username and password (i.e., everyone understands the difference between the administrator account and a user account), with more complex authentication mechanisms the distinction is sometimes lost.
当使用简单的身份验证机制（如用户名和密码）时，身份验证和授权之间的区别是直观的（即，每个人都理解管理员帐户和用户帐户之间的区别），而使用更复杂的身份验证机制时，这种区别有时会丢失。
With certificates, for instance, presenting a valid signature does not imply authorization. The signature must be backed by a certificate chain that contains a trusted root, and that root must be
例如，对于证书，提供有效签名并不意味着授权。签名必须由包含受信任根的证书链支持，并且该根必须是
trusted in the given context. For instance, users who possess certificates issued by the Acme MIS CA may have different web access privileges than users who possess certificates issued by the Acme Accounting CA, even though both of these CAs are "trusted" by the Acme web server.
在给定上下文中受信任。例如，拥有Acme MIS CA颁发的证书的用户可能与拥有Acme会计CA颁发的证书的用户具有不同的web访问权限，即使这两个CA都受到Acme web服务器的“信任”。
Mechanisms for enforcing these more complicated properties have not yet been completely explored. One approach is simply to attach policies to ACLs describing what sorts of certificates are trusted. Another approach is to carry that information with the certificate, either as a certificate extension/attribute [PKIX, SPKI] or as a separate "Attribute Certificate".
强化这些更复杂属性的机制尚未完全探索。一种方法是简单地将策略附加到ACL，描述哪些类型的证书是可信的。另一种方法是将该信息与证书一起携带，作为证书扩展/属性[PKIX，SPKI]或作为单独的“属性证书”。
Securely designed protocols should provide some mechanism for securing (meaning integrity protecting, authenticating, and possibly encrypting) all sensitive traffic. One approach is to secure the protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this provides security which is most fitted to the protocol, it also requires considerable effort to get right.
安全设计的协议应该提供某种机制来保护（意味着完整性保护、身份验证和可能的加密）所有敏感流量。一种方法是保护协议本身，如[DNSSEC]、[S/MIME]或[S-HTTP]。尽管这提供了最适合协议的安全性，但它也需要付出相当大的努力才能正确实现。
Many protocols can be adequately secured using one of the available channel security systems. We'll discuss the two most common, IPsec [AH, ESP] and [TLS].
使用一个可用的通道安全系统可以充分保护许多协议。我们将讨论两种最常见的方法，IPsec[AH，ESP]和[TLS]。
The IPsec protocols (specifically, AH and ESP) can provide transmission security for all traffic between two hosts. The IPsec protocols support varying granularities of user identification, including for example "IP Subnet", "IP Address", "Fully Qualified Domain Name", and individual user ("Mailbox name"). These varying levels of identification are employed as inputs to access control facilities that are an intrinsic part of IPsec. However, a given IPsec implementation might not support all identity types. In particular, security gateways may not provide user-to-user authentication or have mechanisms to provide that authentication information to applications.
IPsec协议（特别是AH和ESP）可以为两台主机之间的所有通信提供传输安全。IPsec协议支持不同粒度的用户标识，包括例如“IP子网”、“IP地址”、“完全限定域名”和单个用户（“邮箱名”）。这些不同级别的标识被用作访问控制设施的输入，访问控制设施是IPsec的固有部分。但是，给定的IPsec实现可能不支持所有标识类型。特别是，安全网关可能不提供用户到用户的身份验证，或者不具有向应用程序提供该身份验证信息的机制。
When AH or ESP is used, the application programmer might not need to do anything (if AH or ESP has been enabled system-wide) or might need to make specific software changes (e.g., adding specific setsockopt() calls) -- depending on the AH or ESP implementation being used. Unfortunately, APIs for controlling IPsec implementations are not yet standardized.
使用AH或ESP时，应用程序程序员可能不需要做任何事情（如果AH或ESP已在系统范围内启用），或者可能需要进行特定的软件更改（例如，添加特定的setsockopt（）调用），具体取决于所使用的AH或ESP实现。不幸的是，用于控制IPsec实现的API尚未标准化。
The primary obstacle to using IPsec to secure other protocols is deployment. The major use of IPsec at present is for VPN applications, especially for remote network access. Without extremely tight coordination between security administrators and application developers, VPN usage is not well suited to providing security services for individual applications since it is difficult for such applications to determine what security services have in fact been provided.
使用IPsec保护其他协议的主要障碍是部署。目前IPsec主要用于VPN应用，特别是远程网络访问。如果安全管理员和应用程序开发人员之间没有非常紧密的协调，VPN的使用就不适合为单个应用程序提供安全服务，因为这些应用程序很难确定实际提供了哪些安全服务。
IPsec deployment in host-to-host environments has been slow. Unlike application security systems such as TLS, adding IPsec to a non-IPsec system generally involves changing the operating system, either by modifying with the kernel or installing new drivers. This is a substantially greater undertaking than simply installing a new application. However, recent versions of a number of commodity operating systems include IPsec stacks, so deployment is becoming easier.
主机到主机环境中的IPsec部署一直很慢。与TLS等应用程序安全系统不同，将IPsec添加到非IPsec系统通常涉及更改操作系统，方法是使用内核进行修改或安装新的驱动程序。这比简单地安装一个新的应用程序要大得多。然而，许多商品操作系统的最新版本包括IPsec堆栈，因此部署变得更加容易。
In environments where IPsec is sure to be available, it represents a viable option for protecting application communications traffic. If the traffic to be protected is UDP, IPsec and application-specific object security are the only options. However, designers MUST NOT assume that IPsec will be available. A security policy for a generic application layer protocol SHOULD NOT simply state that IPsec must be used, unless there is some reason to believe that IPsec will be available in the intended deployment environment. In environments where IPsec may not be available and the traffic is solely TCP, TLS is the method of choice, since the application developer can easily ensure its presence by including a TLS implementation in his package.
在IPsec肯定可用的环境中，它代表了保护应用程序通信流量的可行选项。如果要保护的流量是UDP，则IPsec和特定于应用程序的对象安全性是唯一的选项。但是，设计者不能假设IPsec可用。通用应用层协议的安全策略不应简单地声明必须使用IPsec，除非有理由相信IPsec将在预期的部署环境中可用。在IPsec可能不可用且流量仅为TCP的环境中，TLS是首选方法，因为应用程序开发人员可以通过在其包中包含TLS实现轻松确保其存在。
In the special-case of IPv6, both AH and ESP are mandatory to implement. Hence, it is reasonable to assume that AH/ESP are already available for IPv6-only protocols or IPv6-only deployments. However, automatic key management (IKE) is not required to implement so protocol designers SHOULD not assume it will be present. [USEIPSEC] provides quite a bit of guidance on when IPsec is a good choice.
在IPv6的特殊情况下，AH和ESP都必须实施。因此，可以合理地假设AH/ESP已可用于仅IPv6协议或仅IPv6部署。但是，不需要实现自动密钥管理（IKE），因此协议设计者不应该假设它会出现。[USEIPSEC]提供了很多关于何时IPsec是一个好的选择的指导。
Currently, the most common approach is to use SSL or its successor TLS. They provide channel security for a TCP connection at the application level. That is, they run over TCP. SSL implementations typically provide a Berkeley Sockets-like interface for easy programming. The primary issue when designing a protocol solution around TLS is to differentiate between connections protected using TLS and those which are not.
目前，最常用的方法是使用SSL或其后续TLS。它们在应用程序级别为TCP连接提供通道安全性。也就是说，它们通过TCP运行。SSL实现通常提供类似Berkeley套接字的接口，以便于编程。围绕TLS设计协议解决方案时的主要问题是区分使用TLS保护的连接和不使用TLS的连接。
The two primary approaches used have a separate well-known port for TLS connections (e.g., the HTTP over TLS port is 443) [HTTPTLS] or to have a mechanism for negotiating upward from the base protocol to TLS as in [UPGRADE] or [STARTTLS]. When an upward negotiation strategy is used, care must be taken to ensure that an attacker can not force a clear connection when both parties wish to use TLS.
所使用的两种主要方法都有一个单独的众所周知的TLS连接端口（例如，HTTP over TLS端口为443）[HTTPTLS]，或者有一种机制，用于从基本协议向上协商到TLS，如[UPGRADE]或[STARTTLS]。当使用向上协商策略时，必须小心确保当双方都希望使用TLS时，攻击者无法强制建立清晰连接。
Note that TLS depends upon a reliable protocol such as TCP or SCTP. This produces two notable difficulties. First, it cannot be used to secure datagram protocols that use UDP. Second, TLS is susceptible to IP layer attacks that IPsec is not. Typically, these attacks take some form of denial of service or connection assassination. For instance, an attacker might forge a TCP RST to shut down SSL connections. TLS has mechanisms to detect truncation attacks but these merely allow the victim to know he is being attacked and do not provide connection survivability in the face of such attacks. By contrast, if IPsec were being used, such a forged RST could be rejected without affecting the TCP connection. If forged RSTs or other such attacks on the TCP connection are a concern, then AH/ESP or the TCP MD5 option [TCPMD5] are the preferred choices.
请注意，TLS依赖于可靠的协议，如TCP或SCTP。这产生了两个明显的困难。首先，它不能用于保护使用UDP的数据报协议。第二，TLS容易受到IPsec没有的IP层攻击。通常，这些攻击采取某种形式的拒绝服务或连接暗杀。例如，攻击者可能伪造TCP RST以关闭SSL连接。TLS具有检测截断攻击的机制，但这些机制仅允许受害者知道自己正在受到攻击，并且在面对此类攻击时不提供连接生存能力。相反，如果使用IPsec，则可以在不影响TCP连接的情况下拒绝这种伪造的RST。如果对TCP连接的伪造RST或其他此类攻击令人担忧，则AH/ESP或TCP MD5选项[TCPMD5]是首选。
If the "separate ports" approach to TLS is used, then TLS will be negotiated before any application-layer traffic is sent. This can cause a problem with protocols that use virtual hosts, such as [HTTP], since the server does not know which certificate to offer the client during the TLS handshake. The TLS hostname extension [TLSEXT] can be used to solve this problem, although it is too new to have seen wide deployment.
如果使用TLS的“独立端口”方法，那么在发送任何应用层通信之前，将协商TLS。这可能会导致使用虚拟主机（如[HTTP]）的协议出现问题，因为服务器不知道在TLS握手期间向客户端提供哪个证书。TLS主机名扩展[TLSEXT]可以用来解决这个问题，尽管它太新了，还没有广泛部署。
One difficulty with using TLS is that the server is authenticated via a certificate. This can be inconvenient in environments where previously the only form of authentication was a password shared between client and server. It's tempting to use TLS without an authenticated server (i.e., with anonymous DH or a self-signed RSA certificate) and then authenticate via some challenge-response mechanism such as SASL with CRAM-MD5.
使用TLS的一个困难是服务器通过证书进行身份验证。在以前唯一的身份验证形式是客户端和服务器之间共享密码的环境中，这可能会带来不便。在没有经过身份验证的服务器（即匿名DH或自签名RSA证书）的情况下使用TLS，然后通过一些质询响应机制（如带有CRAM-MD5的SASL）进行身份验证是很有诱惑力的。
Unfortunately, this composition of SASL and TLS is less strong than one would expect. It's easy for an active attacker to hijack this connection. The client man-in-the-middles the SSL connection (remember we're not authenticating the server, which is what ordinarily prevents this attack) and then simply proxies the SASL handshake. From then on, it's as if the connection were in the
不幸的是，SASL和TLS的这种组合并不像人们预期的那样强大。主动攻击者很容易劫持此连接。处于中间位置的客户机负责人负责SSL连接（请记住，我们不是在验证服务器，这通常可以防止这种攻击），然后简单地代理SASL握手。从那时起，就好像连接在
clear, at least as far as that attacker is concerned. In order to prevent this attack, the client needs to verify the server's certificate.
很清楚，至少对那个攻击者来说是这样。为了防止这种攻击，客户端需要验证服务器的证书。
However, if the server is authenticated, challenge-response becomes less desirable. If you already have a hardened channel then simple passwords are fine. In fact, they're arguably superior to challenge-response since they do not require that the password be stored in the clear on the server. Thus, compromise of the key file with challenge-response systems is more serious than if simple passwords were used.
但是，如果服务器经过身份验证，则质询响应将变得不那么理想。如果你已经有了一个强化的通道，那么简单的密码就可以了。事实上，它们可以说优于质询响应，因为它们不需要将密码存储在服务器上的clear中。因此，与使用简单密码相比，使用质询响应系统对密钥文件的危害更为严重。
Note that if the client has a certificate than SSL-based client authentication can be used. To make this easier, SASL provides the EXTERNAL mechanism, whereby the SASL client can tell the server "examine the outer channel for my identity". Obviously, this is not subject to the layering attacks described above.
请注意，如果客户端具有证书，则可以使用基于SSL的客户端身份验证。为了简化这一过程，SASL提供了外部机制，SASL客户机可以通过该机制告诉服务器“检查外部通道以获取我的身份”。显然，这不受上述分层攻击的影响。
In some special cases it may be worth providing channel-level security directly in the application rather than using IPSEC or SSL/TLS. One such case is remote terminal security. Characters are typically delivered from client to server one character at a time. Since SSL/TLS and AH/ESP authenticate and encrypt every packet, this can mean a data expansion of 20-fold. The telnet encryption option [ENCOPT] prevents this expansion by foregoing message integrity.
在某些特殊情况下，直接在应用程序中提供通道级安全性可能值得，而不是使用IPSEC或SSL/TLS。其中一个例子是远程终端安全。字符通常一次从客户端传递到服务器一个字符。由于SSL/TLS和AH/ESP对每个数据包进行身份验证和加密，这可能意味着数据扩展20倍。telnet加密选项[ENCOPT]通过前述消息完整性来防止这种扩展。
When using remote terminal service, it's often desirable to securely perform other sorts of communications services. In addition to providing remote login, SSH [SSH] also provides secure port forwarding for arbitrary TCP ports, thus allowing users run arbitrary TCP-based applications over the SSH channel. Note that SSH Port Forwarding can be security issue if it is used improperly to circumvent firewall and improperly expose insecure internal applications to the outside world.
在使用远程终端服务时，通常需要安全地执行其他种类的通信服务。除了提供远程登录，SSH[SSH]还为任意TCP端口提供安全的端口转发，从而允许用户通过SSH通道运行任意基于TCP的应用程序。请注意，如果SSH端口转发被不正确地用于绕过防火墙并将不安全的内部应用程序不正确地暴露给外部世界，则它可能是一个安全问题。
Denial of service attacks are all too frequently viewed as an fact of life. One problem is that an attacker can often choose from one of many denial of service attacks to inflict upon a victim, and because most of these attacks cannot be thwarted, common wisdom frequently assumes that there is no point protecting against one kind of denial of service attack when there are many other denial of service attacks that are possible but that cannot be prevented.
拒绝服务攻击经常被视为现实。一个问题是，攻击者通常可以从众多拒绝服务攻击中选择一种攻击受害者，因为这些攻击中的大多数都无法阻止，常识通常认为，当存在许多其他可能但无法预防的拒绝服务攻击时，防范一种拒绝服务攻击是没有意义的。
However, not all denial of service attacks are equal and more importantly, it is possible to design protocols so that denial of service attacks are made more difficult, if not impractical. Recent SYN flood attacks [TCPSYN] demonstrate both of these properties: SYN flood attacks are so easy, anonymous, and effective that they are more attractive to attackers than other attacks; and because the design of TCP enables this attack.
但是，并非所有拒绝服务攻击都是平等的，更重要的是，可以设计协议，使拒绝服务攻击变得更加困难（如果不是不切实际的话）。最近的SYN flood攻击[TCPSYN]证明了这两个特性：SYN flood攻击非常简单、匿名且有效，因此比其他攻击对攻击者更具吸引力；因为TCP的设计支持这种攻击。
Because complete DoS protection is so difficult, security against DoS must be dealt with pragmatically. In particular, some attacks which would be desirable to defend against cannot be defended against economically. The goal should be to manage risk by defending against attacks with sufficiently high ratios of severity to cost of defense. Both severity of attack and cost of defense change as technology changes and therefore so does the set of attacks which should be defended against.
由于完整的DoS保护非常困难，因此必须务实地处理针对DoS的安全问题。特别是，一些需要防御的攻击在经济上是无法防御的。目标应该是通过防御严重性与防御成本之比足够高的攻击来管理风险。攻击的严重性和防御成本都会随着技术的变化而变化，因此应该防御的攻击集也会随之变化。
Authors of internet standards MUST describe which denial of service attacks their protocol is susceptible to. This description MUST include the reasons it was either unreasonable or out of scope to attempt to avoid these denial of service attacks.
互联网标准的作者必须描述他们的协议容易受到哪些拒绝服务攻击。此说明必须包括试图避免这些拒绝服务攻击的不合理或超出范围的原因。
BLIND denial of service attacks are particularly pernicious. With a blind attack the attacker has a significant advantage. If the attacker must be able to receive traffic from the victim, then he must either subvert the routing fabric or use his own IP address. Either provides an opportunity for the victim to track the attacker and/or filter out his traffic. With a blind attack the attacker can use forged IP addresses, making it extremely difficult for the victim to filter out his packets. The TCP SYN flood attack is an example of a blind attack. Designers should make every attempt possible to prevent blind denial of service attacks.
盲目拒绝服务攻击尤其有害。通过盲攻击，攻击者具有显著优势。如果攻击者必须能够接收来自受害者的流量，那么他必须破坏路由结构或使用自己的IP地址。为受害者提供跟踪攻击者和/或过滤其流量的机会。通过盲攻击，攻击者可以使用伪造的IP地址，使受害者很难过滤出他的数据包。TCP SYN洪水攻击是盲攻击的一个示例。设计者应尽一切努力防止盲目拒绝服务攻击。
Even more dangerous are DISTRIBUTED denial of service attacks (DDoS) [DDOS]. In a DDoS the attacker arranges for a number of machines to attack the target machine simultaneously. Usually this is accomplished by infecting a large number of machines with a program that allows remote initiation of attacks. The machines actually performing the attack are called ZOMBIEs and are likely owned by unsuspecting third parties in an entirely different location from the true attacker. DDoS attacks can be very hard to counter because the zombies often appear to be making legitimate protocol requests and
更危险的是分布式拒绝服务攻击（DDoS）[DDoS]。在DDoS攻击中，攻击者安排多台机器同时攻击目标机器。通常，这是通过使用允许远程发起攻击的程序感染大量计算机来实现的。实际执行攻击的机器被称为僵尸，可能由毫无戒心的第三方拥有，其位置与真正的攻击者完全不同。DDoS攻击可能很难反击，因为僵尸通常会发出合法的协议请求和攻击
simply crowd out the real users. DDoS attacks can be difficult to thwart, but protocol designers are expected to be cognizant of these forms of attack while designing protocols.
只是挤出真正的用户。DDoS攻击可能很难阻止，但协议设计者在设计协议时应了解这些形式的攻击。
There are two common approaches to making denial of service attacks more difficult:
有两种常见的方法使拒绝服务攻击更加困难：
If an attacker consumes more of his resources than yours when launching an attack, attackers with fewer resources than you will be unable to launch effective attacks. One common technique is to require the attacker perform a time-intensive operation, such as a cryptographic operation. Note that an attacker can still mount a denial of service attack if he can muster substantially sufficient CPU power. For instance, this technique would not stop the distributed attacks described in [TCPSYN].
如果攻击者在发起攻击时消耗的资源多于您的资源，则资源少于您的攻击者将无法发起有效的攻击。一种常见的技术是要求攻击者执行时间密集型操作，例如加密操作。请注意，如果攻击者能够集中足够的CPU能力，则仍然可以发起拒绝服务攻击。例如，这种技术无法阻止[TCPSYN]中描述的分布式攻击。
A blind attack can be subverted by forcing the attacker to prove that they can can receive data from the victim. A common technique is to require that the attacker reply using information that was gained earlier in the message exchange. If this countermeasure is used, the attacker must either use his own address (making him easy to track) or to forge an address which will be routed back along a path that traverses the host from which the attack is being launched.
通过强迫攻击者证明他们可以从受害者处接收数据，可以颠覆盲攻击。一种常见的技术是要求攻击者使用先前在消息交换中获得的信息进行回复。如果使用此对策，攻击者必须使用自己的地址（使其易于跟踪）或伪造一个地址，该地址将沿着穿越发起攻击的主机的路径路由回去。
Hosts on small subnets are thus useless to the attacker (at least in the context of a spoofing attack) because the attack can be traced back to a subnet (which should be sufficient for locating the attacker) so that anti-attack measures can be put into place (for instance, a boundary router can be configured to drop all traffic from that subnet). A common technique is to require that the attacker reply using information that was gained earlier in the message exchange.
因此，小型子网上的主机对攻击者毫无用处（至少在欺骗攻击的情况下），因为攻击可以追溯到子网（足以定位攻击者），因此可以采取反攻击措施（例如，可以将边界路由器配置为丢弃该子网中的所有流量）。一种常见的技术是要求攻击者使用先前在消息交换中获得的信息进行回复。
TCP/IP is vulnerable to SYN flood attacks (which are described in section 3.3.2) because of the design of the 3-way handshake. First, an attacker can force a victim to consume significant resources (in this case, memory) by sending a single packet. Second, because the attacker can perform this action without ever having received data from the victim, the attack can be performed anonymously (and therefore using a large number of forged source addresses).
由于三向握手的设计，TCP/IP容易受到SYN洪水攻击（见第3.3.2节）。首先，攻击者可以通过发送单个数据包迫使受害者消耗大量资源（在本例中为内存）。其次，由于攻击者可以在从未收到受害者数据的情况下执行此操作，因此可以匿名执行攻击（因此使用大量伪造的源地址）。
[PHOTURIS] specifies an anti-clogging mechanism that prevents attacks on Photuris that resemble the SYN flood attack. Photuris employs a time-variant secret to generate a "cookie" which is returned to the attacker. This cookie must be returned in subsequent messages for the exchange to progress. The interesting feature is that this cookie can be regenerated by the victim later in the exchange, and thus no state need be retained by the victim until after the attacker has proven that he can receive packets from the victim.
[PHOTURIS]指定了一种防堵塞机制，可防止对PHOTURIS的类似SYN flood攻击的攻击。Photuris使用时变秘密生成“cookie”，并将其返回给攻击者。必须在后续消息中返回此cookie，exchange才能继续。有趣的特性是，该cookie可以由受害者稍后在交换中重新生成，因此，在攻击者证明他可以从受害者接收数据包之前，受害者不需要保留任何状态。
It's useful to make the conceptual distinction between object security and channel security. Object security refers to security measures which apply to entire data objects. Channel security measures provide a secure channel over which objects may be carried transparently but the channel has no special knowledge about object boundaries.
在概念上区分对象安全性和通道安全性是很有用的。对象安全性是指应用于整个数据对象的安全措施。通道安全措施提供了一个安全通道，在该通道上可以透明地携带物体，但通道对物体边界没有专门的知识。
Consider the case of an email message. When it's carried over an IPSEC or TLS secured connection, the message is protected during transmission. However, it is unprotected in the receiver's mailbox, and in intermediate spool files along the way. Moreover, since mail servers generally run as a daemon, not a user, authentication of messages generally merely means authentication of the daemon not the user. Finally, since mail transport is hop-by-hop, even if the user authenticates to the first hop relay the authentication can't be safely verified by the receiver.
考虑电子邮件的情况。当通过IPSEC或TLS安全连接传输时，消息在传输过程中受到保护。但是，它在接收者的邮箱中以及在途中的中间spool文件中不受保护。此外，由于邮件服务器通常作为守护进程而不是用户运行，因此消息的身份验证通常仅意味着守护进程而不是用户的身份验证。最后，由于邮件传输是逐跳的，即使用户向第一跳中继进行身份验证，接收方也无法安全地验证身份验证。
By contrast, when an email message is protected with S/MIME or OpenPGP, the entire message is encrypted and integrity protected until it is examined and decrypted by the recipient. It also provides strong authentication of the actual sender, as opposed to the machine the message came from. This is object security. Moreover, the receiver can prove the signed message's authenticity to a third party.
相反，当电子邮件使用S/MIME或OpenPGP进行保护时，整个邮件将被加密和完整性保护，直到收件人对其进行检查和解密。它还提供对实际发送者的强身份验证，而不是消息来自的机器。这是对象安全性。此外，接收方可以向第三方证明签名消息的真实性。
Note that the difference between object and channel security is a matter of perspective. Object security at one layer of the protocol stack often looks like channel security at the next layer up. So, from the perspective of the IP layer, each packet looks like an individually secured object. But from the perspective of a web client, IPSEC just provides a secure channel.
请注意，对象和通道安全性之间的差异是一个透视问题。协议栈某一层的对象安全性通常与上一层的通道安全性类似。因此，从IP层的角度来看，每个数据包看起来都像一个单独的安全对象。但从web客户端的角度来看，IPSEC只提供了一个安全通道。
The distinction isn't always clear-cut. For example, S-HTTP provides object level security for a single HTTP transaction, but a web page typically consists of multiple HTTP transactions (the base page and
区别并不总是明确的。例如，S-HTTP为单个HTTP事务提供对象级别的安全性，但一个网页通常由多个HTTP事务（基页和
numerous inline images). Thus, from the perspective of the total web page, this looks rather more like channel security. Object security for a web page would consist of security for the transitive closure of the page and all its embedded content as a single unit.
许多内联图像）。因此，从整个网页的角度来看，这看起来更像是通道安全。web页面的对象安全性包括页面的可传递闭包的安全性及其作为单个单元的所有嵌入内容。
It's common security practice in modern networks to partition the network into external and internal networks using a firewall. The internal network is then assumed to be secure and only limited security measures are used there. The internal portion of such a network is often called a WALLED GARDEN.
使用防火墙将网络分为外部网络和内部网络是现代网络中常见的安全实践。然后假设内部网络是安全的，并且仅使用有限的安全措施。这种网络的内部部分通常被称为有围墙的花园。
Internet protocol designers cannot safely assume that their protocols will be deployed in such an environment, for three reasons. First, protocols which were originally designed to be deployed in closed environments often are later deployed on the Internet, thus creating serious vulnerabilities.
互联网协议设计者不能安全地假设他们的协议将部署在这样的环境中，原因有三。首先，最初设计用于在封闭环境中部署的协议后来往往部署在互联网上，从而造成严重的漏洞。
Second, networks which appear to be topologically disconnected may not be. One reason may be that the network has been reconfigured to allow access by the outside world. Moreover, firewalls are increasingly passing generic application layer protocols such as [SOAP] or [HTTP]. Network protocols which are based on these generic protocols cannot in general assume that a firewall will protect them. Finally, one of the most serious security threats to systems is from insiders, not outsiders. Since insiders by definition have access to the internal network, topological protections such as firewalls will not protect them.
其次，看起来拓扑上断开连接的网络可能不存在。一个原因可能是网络已经重新配置，允许外部世界访问。此外，防火墙越来越多地通过[SOAP]或[HTTP]等通用应用层协议。基于这些通用协议的网络协议通常不能假定防火墙将保护它们。最后，对系统最严重的安全威胁之一来自内部人员，而不是外部人员。根据定义，内部人员可以访问内部网络，因此防火墙等拓扑保护不会保护他们。
While it is not a requirement that any given protocol or system be immune to all forms of attack, it is still necessary for authors to consider as many forms as possible. Part of the purpose of the Security Considerations section is to explain what attacks are out of scope and what countermeasures can be applied to defend against them. In
虽然不要求任何给定的协议或系统对所有形式的攻击都具有免疫力，但作者仍有必要考虑尽可能多的形式。“安全注意事项”部分的部分目的是解释哪些攻击超出范围，以及可以应用哪些对策来防范这些攻击。在里面
There should be a clear description of the kinds of threats on the described protocol or technology. This should be approached as an effort to perform "due diligence" in describing all known or foreseeable risks and threats to potential implementers and users.
应清楚描述所述协议或技术上的威胁类型。这应被视为在描述潜在实施者和用户的所有已知或可预见风险和威胁时进行“尽职调查”的一种努力。
Authors MUST describe
作者必须描述
1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against
1. 哪些攻击超出范围（以及原因！）2。哪些攻击属于范围2.1，协议易受范围2.2的影响，并且协议可防止攻击
At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. If the protocol incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.). Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled.
至少必须考虑以下形式的攻击：窃听、重播、消息插入、删除、修改和中间人。还必须确定潜在的拒绝服务攻击。如果协议包含密码保护机制，则应明确指出数据的哪些部分受到保护以及保护内容（即，仅完整性、机密性和/或端点身份验证等）。还应指出加密保护易受何种攻击。应保密的数据（键入材料、随机种子等）应清楚标记。
If the technology involves authentication, particularly user-host authentication, the security of the authentication method MUST be clearly specified. That is, authors MUST document the assumptions that the security of this authentication method is predicated upon. For instance, in the case of the UNIX username/password login method, a statement to the effect of:
如果技术涉及身份验证，特别是用户-主机身份验证，则必须明确指定身份验证方法的安全性。也就是说，作者必须记录此身份验证方法的安全性所基于的假设。例如，在UNIX用户名/密码登录方法的情况下，一条语句的作用是：
Authentication in the system is secure only to the extent that it is difficult to guess or obtain a ASCII password that is a maximum of 8 characters long. These passwords can be obtained by sniffing telnet sessions or by running the 'crack' program using the contents of the /etc/passwd file. Attempts to protect against on-line password guessing by (1) disconnecting after several unsuccessful login attempts and (2) waiting between successive password prompts is effective only to the extent that attackers are impatient.
系统中的身份验证仅在难以猜测或获取最多8个字符的ASCII密码时才是安全的。这些密码可以通过嗅探telnet会话或使用/etc/passwd文件的内容运行“crack”程序来获得。通过（1）在多次登录尝试失败后断开连接和（2）在连续的密码提示之间等待来防止在线密码猜测的尝试只有在攻击者不耐烦的情况下才有效。
Because the /etc/passwd file maps usernames to user ids, groups, etc. it must be world readable. In order to permit this usage but make running crack more difficult, the file is often split into /etc/passwd and a 'shadow' password file. The shadow file is not world readable and contains the encrypted password. The regular /etc/passwd file contains a dummy password in its place.
因为/etc/passwd文件将用户名映射到用户ID、组等，所以它必须是全世界可读的。为了允许这种使用，但使运行crack更加困难，该文件通常分为/etc/passwd和“shadow”密码文件。卷影文件不是世界可读的，并且包含加密的密码。常规/etc/passwd文件包含一个虚拟密码。
It is insufficient to simply state that one's protocol should be run over some lower layer security protocol. If a system relies upon lower layer security services for security, the protections those
仅仅声明一个人的协议应该在某个较低层的安全协议上运行是不够的。如果系统依赖较低层的安全服务来实现安全，那么这些保护
services are expected to provide MUST be clearly specified. In addition, the resultant properties of the combined system need to be specified.
必须明确规定预期提供的服务。此外，需要指定组合系统的合成特性。
Note: In general, the IESG will not approve standards track protocols which do not provide for strong authentication, either internal to the protocol or through tight binding to a lower layer security protocol.
注：通常，IESG不会批准不提供强身份验证的标准跟踪协议，无论是在协议内部还是通过与较低层安全协议的紧密绑定。
The threat environment addressed by the Security Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place, even if only to provide justification for why such consideration is out of scope for the protocol. It is not acceptable to only discuss threats applicable to LANs and ignore the broader threat environment. All IETF standards-track protocols are considered likely to have deployment in the global Internet. In some cases, there might be an Applicability Statement discouraging use of a technology or protocol in a particular environment. Nonetheless, the security issues of broader deployment should be discussed in the document.
安全注意事项部分处理的威胁环境必须至少包括跨多个管理边界跨全球互联网部署，而不假设防火墙已就位，即使只是为了证明此类注意事项超出协议范围的原因。仅讨论适用于局域网的威胁而忽略更广泛的威胁环境是不可接受的。所有IETF标准跟踪协议都可能部署在全球互联网上。在某些情况下，可能存在一种适用性声明，不鼓励在特定环境中使用技术或协议。尽管如此，文件中应讨论更广泛部署的安全问题。
There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed. Such risks might arise from compromise in a related protocol (e.g., IPsec is useless if key management has been compromised), from incorrect implementation, compromise of the security technology used for risk reduction (e.g., a cipher with a 40-bit key), or there might be risks that are not addressed by the protocol specification (e.g., denial of service attacks on an underlying link protocol). Particular care should be taken in situations where the compromise of a single system would compromise an entire protocol. For instance, in general protocol designers assume that end-systems are inviolate and don't worry about physical attack. However, in cases (such as a certificate authority) where compromise of a single system could lead to widespread compromises, it is appropriate to consider systems and physical security as well.
在部署威胁缓解措施后，应对该协议的用户或运营商的剩余风险进行明确描述。此类风险可能来自相关协议中的泄露（例如，如果密钥管理遭到泄露，则IPsec无效）、不正确的实施、用于降低风险的安全技术的泄露（例如，具有40位密钥的密码），或者可能存在协议规范未解决的风险（例如，对底层链路协议的拒绝服务攻击）。在单个系统的危害将危及整个协议的情况下，应特别小心。例如，在一般情况下，协议设计者假定终端系统不受侵犯，不担心物理攻击。但是，在（如证书颁发机构），其中单个系统的折衷可能导致广泛的妥协，适当地考虑系统和物理安全也是如此。
There should also be some discussion of potential security risks arising from potential misapplications of the protocol or technology described in the RFC. This might be coupled with an Applicability Statement for that RFC.
还应讨论因RFC中所述协议或技术的潜在误用而产生的潜在安全风险。这可能与该RFC的适用性声明相结合。
This section consists of some example security considerations sections, intended to give the reader a flavor of what's intended by this document.
本节包括一些示例安全注意事项部分，旨在让读者了解本文档的意图。
The first example is a 'retrospective' example, applying the criteria of this document to an existing widely deployed protocol, SMTP. The second example is a good security considerations section clipped from a current protocol.
第一个示例是“回顾性”示例，将本文档的标准应用于广泛部署的现有协议SMTP。第二个示例是从当前协议中裁剪的一个良好的安全注意事项部分。
When RFC 821 was written, Security Considerations sections were not required in RFCs, and none is contained in that document. [RFC 2821] updated RFC 821 and added a detailed security considerations section. We reproduce here the Security Considerations section from that document (with new section numbers). Our comments are indented and prefaced with 'NOTE:'. We also add a number of new sections to cover topics we consider important. Those sections are marked with [NEW] in the section header.
编写RFC 821时，RFC中不需要安全注意事项部分，该文档中也不包含任何内容。[RFC 2821]更新了RFC 821并添加了详细的安全注意事项部分。我们在此复制该文件中的安全注意事项部分（带有新的部分编号）。我们的评论缩进并以“备注：”开头。我们还添加了一些新的章节来涵盖我们认为重要的主题。这些节在节标题中用[NEW]标记。
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]).
SMTP邮件本质上是不安全的，因为即使是相当随意的用户也可以直接与接收和转发SMTP服务器进行协商，并创建邮件，从而欺骗天真的收件人相信他们来自其他地方。构建这样一条信息，使专家无法检测到“欺骗”行为有点困难，但还不足以对有决心和知识的人起到威慑作用。因此，随着互联网邮件知识的增加，SMTP邮件本身无法在传输级别进行身份验证或提供完整性检查的知识也会增加。真正的邮件安全性仅存在于涉及消息体的端到端方法中，例如使用数字签名的方法（参见[14]和，例如PGP[4]或S/MIME[31]）。
NOTE: One bad approach to sender authentication is [IDENT] in which the receiving mail server contacts the alleged sender and asks for the username of the sender. This is a bad idea for a number of reasons, including but not limited to relaying, TCP connection hijacking, and simple lying by the origin server. Aside from the fact that IDENT is of low security value, use of IDENT by receiving sites can lead to operational problems. Many sending sites blackhole IDENT requests, thus causing mail to be held until the receiving server's IDENT request times out.
注意：发送者身份验证的一种错误方法是[Identit]，在这种方法中，接收邮件的服务器会联系声称的发送者并询问发送者的用户名。这是一个坏主意，原因有很多，包括但不限于中继、TCP连接劫持和源服务器的简单欺骗。除了IDENT的安全值较低之外，接收站点使用IDENT可能会导致操作问题。许多发送站点屏蔽了IDENT请求，从而导致邮件被保留，直到接收服务器的IDENT请求超时。
Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful
在传输级别（例如，从SMTP客户端到SMTP服务器）提供身份验证的各种协议扩展和配置选项在一定程度上改善了上述传统情况。但是，除非他们有仔细的检查
handoffs of responsibility in a carefully-designed trust environment, they remain inherently weaker than end-to-end mechanisms which use digitally signed messages rather than depending on the integrity of the transport system.
在精心设计的信任环境中，责任的移交与使用数字签名消息而不是依赖传输系统完整性的端到端机制相比，本质上仍然较弱。
Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly.)
让用户更难设置信封返回路径和标题“发件人”字段以指向自己以外的有效地址的做法在很大程度上是错误的：它们阻碍了合法的应用程序，在这些应用程序中，邮件由一个用户代表另一个用户发送，或者错误（或正常）回复应指向一个特殊地址。（为用户提供方便的方式以每封邮件为基础更改这些字段的系统应尝试为用户建立主邮箱和永久邮箱地址，以便能够合理地生成邮件数据中的发件人字段。）
This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail.
本规范没有进一步解决与SMTP相关的身份验证问题，只是主张不要禁用有用的功能，以期为试图伪造邮件的无知用户提供少量保护。
NOTE: We have added additional material on communications security and SMTP in Section 6.1.2 In a final specification, the above text would be edited somewhat to reflect that fact.
注：我们在最终规范的第6.1.2节中添加了关于通信安全和SMTP的额外材料，将对上述文本进行编辑以反映这一事实。
Addresses that do not appear in the message headers may appear in the RCPT commands to an SMTP server for a number of reasons. The two most common involve the use of a mailing address as a "list exploder" (a single address that resolves into multiple addresses) and the appearance of "blind copies". Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the headers, either as part of trace headers or as informational or private-extension headers. Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command.
由于多种原因，邮件标题中未显示的地址可能会显示在发送给SMTP服务器的RCPT命令中。最常见的两种方法是使用邮寄地址作为“列表分解器”（一个地址分解为多个地址）和出现“盲拷贝”。特别是当存在多个RCPT命令时，为了避免违背这些机制的某些目的，SMTP客户端和服务器不应将完整的RCPT命令参数集复制到标头中，作为跟踪标头的一部分或作为信息性或专用扩展标头。由于此规则在实践中经常被违反，并且无法强制执行，因此发送知道“密件抄送”使用的SMTP系统可能会发现，将每个盲副本作为单独的邮件事务发送（仅包含一个RCPT命令）是有帮助的。
There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the headers. Receiving systems SHOULD NOT attempt to deduce such relationships and use them
SMTP事务（“信封”）中的“反向”（来自邮件、SAML等命令）或“转发”（RCPT）地址与标头中的地址之间没有固有关系。接收系统不应试图推断并使用这些关系
to alter the headers of the message for delivery. The popular "Apparently-to" header is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.
更改要传递的邮件的标题。流行的“显然是”标题违反了这一原则，也是意外信息披露的常见来源，不应使用。
As discussed in section 3.5, individual sites may want to disable either or both of VRFY or EXPN for security reasons. As a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified. If a site disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification.
如第3.5节所述，出于安全原因，各个站点可能希望禁用VRFY或EXPN中的一个或两个。作为上述的推论，允许这样做的实现不能看起来具有事实上未经验证的已验证地址。如果站点出于安全原因禁用这些命令，SMTP服务器必须返回252响应，而不是可能与验证成功或失败混淆的代码。
Returning a 250 reply code with the address listed in the VRFY command after having checked it only for syntax violates this rule. Of course, an implementation that "supports" VRFY by always returning 550 whether or not the address is valid is equally not in conformance.
在仅检查语法后返回一个地址为VRFY命令中列出的250回复代码违反了此规则。当然，无论地址是否有效，通过始终返回550来“支持”VRFY的实现也同样不一致。
Within the last few years, the contents of mailing lists have become popular as an address information source for so-called "spammers." The use of EXPN to "harvest" addresses has increased as list administrators have installed protections against inappropriate uses of the lists themselves. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. As authentication mechanisms are introduced into SMTP, some sites may choose to make EXPN available only to authenticated requesters.
在过去几年中，邮件列表的内容已成为所谓“垃圾邮件发送者”的地址信息源。由于列表管理员安装了防止不适当使用列表的保护装置，使用EXPN“获取”地址的情况有所增加。实现仍应提供对EXPN的支持，但站点应仔细评估权衡。由于SMTP中引入了身份验证机制，一些站点可能会选择仅对经过身份验证的请求者提供EXPN。
NOTE: It's not clear that disabling VRFY adds much protection, since it's often possible to discover whether an address is valid using RCPT TO.
注意：不清楚禁用VRFY是否会增加很多保护，因为通常可以使用RCPT来发现地址是否有效。
There has been an ongoing debate about the tradeoffs between the debugging advantages of announcing server type and version (and, sometimes, even server domain name) in the greeting response or in response to the HELP command and the disadvantages of exposing information that might be useful in a potential hostile attack. The utility of the debugging information is beyond doubt. Those who argue for making it available point out that it is far better to actually secure an SMTP server rather than hope that trying to conceal known vulnerabilities by hiding the server's precise identity will provide more protection. Sites are encouraged to evaluate the
关于在问候响应或帮助命令响应中公布服务器类型和版本（有时甚至是服务器域名）的调试优势与暴露可能在潜在恶意攻击中有用的信息的劣势之间的权衡，一直存在争论。调试信息的效用是毋庸置疑的。那些主张让SMTP服务器可用的人指出，实际上保护SMTP服务器的安全要好得多，而不是希望通过隐藏服务器的确切身份来隐藏已知的漏洞能够提供更多的保护。鼓励各站点评估
tradeoff with that issue in mind; implementations are strongly encouraged to minimally provide for making type and version information available in some way to other network hosts.
考虑到这一问题进行权衡；强烈建议实现尽可能少地提供类型和版本信息，以某种方式提供给其他网络主机。
In some circumstances, such as when mail originates from within a LAN whose hosts are not directly on the public Internet, trace ("Received") fields produced in conformance with this specification may disclose host names and similar information that would not normally be available. This ordinarily does not pose a problem, but sites with special concerns about name disclosure should be aware of it. Also, the optional FOR clause should be supplied with caution or not at all when multiple recipients are involved lest it inadvertently disclose the identities of "blind copy" recipients to others.
在某些情况下，例如当邮件来自主机不直接位于公共互联网上的LAN时，根据本规范生成的跟踪（“接收”）字段可能会披露主机名和通常不可用的类似信息。这通常不会造成问题，但对名称披露有特殊关注的网站应该意识到这一点。此外，当涉及多个收件人时，应谨慎提供或根本不提供可选FOR条款，以免无意中将“盲拷贝”收件人的身份泄露给其他人。
As discussed in section 3.4, use of the 251 or 551 reply codes to identify the replacement address associated with a mailbox may inadvertently disclose sensitive information. Sites that are concerned about those issues should ensure that they select and configure servers appropriately.
如第3.4节所述，使用251或551回复代码识别与邮箱相关的替换地址可能会无意中泄露敏感信息。关注这些问题的站点应确保适当地选择和配置服务器。
It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process.
这是一个公认的原则，即SMTP服务器可以出于任何操作或技术原因拒绝接受邮件，而这些原因对提供服务器的站点来说是有意义的。然而，网站和设施之间的合作使互联网成为可能。如果网站过度利用拒绝流量的权利，电子邮件的普及（互联网的优势之一）将受到威胁；如果一个站点决定对其将接受和处理的流量进行选择，则应十分小心并保持平衡。
In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate.
近年来，通过任意站点使用中继功能已被用作敌对行动的一部分，以隐藏邮件的实际来源。一些站点决定将中继功能的使用限制在已知或可识别的源上，并且实现应提供执行此类过滤的能力。当邮件因这些或其他政策原因被拒绝时，应使用550代码来响应EHLO、mail或RCPT（视情况而定）。
SMTP itself provides no protection is provided against unsolicited commercial mass e-mail (aka spam). It is extremely difficult to tell a priori whether a given message is spam or not. From a protocol perspective, spam is indistinguishable from other e-mail -- the distinction is almost entirely social and often quite subtle. (For instance, is a message from a merchant from whom you've purchased items before advertising similar items spam?) SMTP spam-suppression mechanisms are generally limited to identifying known spam senders and either refusing to service them or target them for punishment/disconnection. [RFC-2505] provides extensive guidance on making SMTP servers spam-resistant. We provide a brief discussion of the topic here.
SMTP本身不提供针对未经请求的商业海量电子邮件（又称垃圾邮件）的保护。很难先验地判断给定的消息是否是垃圾邮件。从协议的角度来看，垃圾邮件与其他电子邮件是无法区分的——这种区别几乎完全是社交性的，而且往往非常微妙。（例如，您在发布类似邮件广告之前从其购买邮件的商户发送的邮件是否为垃圾邮件？）SMTP垃圾邮件抑制机制通常仅限于识别已知的垃圾邮件发送者，并拒绝为其提供服务或针对其进行惩罚/断开连接。[RFC-2505]提供了使SMTP服务器抵御垃圾邮件的广泛指导。我们在这里简要讨论这个主题。
The primary tool for refusal to service spammers is the blacklist. Some authority such as [MAPS] collects and publishes a list of known spammers. Individual SMTP servers then block the blacklisted offenders (generally by IP address).
拒绝为垃圾邮件发送者提供服务的主要工具是黑名单。一些权威机构，如[地图]收集并发布已知垃圾邮件发送者的名单。然后，单个SMTP服务器阻止列入黑名单的违规者（通常按IP地址）。
In order to avoid being blacklisted or otherwise identified, spammers often attempt to obscure their identity, either simply by sending a false SMTP identity or by forwarding their mail through an Open Relay -- an SMTP server which will perform mail relaying for any sender. As a consequence, there are now blacklists [ORBS] of open relays as well.
为了避免被列入黑名单或以其他方式被识别，垃圾邮件发送者通常试图隐藏自己的身份，要么简单地发送一个虚假的SMTP身份，要么通过一个开放的中继转发邮件——一个将为任何发件人执行邮件中继的SMTP服务器。因此，现在也有开放式继电器的黑名单[ORB]。
To avoid being used for spam forwarding, many SMTP servers operate as closed relays, providing relaying service only for clients who they can identify. Such relays should generally insist that senders advertise a sending address consistent with their known identity. If the relay is providing service for an identifiable network (such as a corporate network or an ISP's network) then it is sufficient to block all other IP addresses). In other cases, explicit authentication must be used. The two standard choices for this are TLS [STARTTLS] and SASL [SASLSMTP].
为了避免被用于垃圾邮件转发，许多SMTP服务器作为闭合中继运行，仅为他们能够识别的客户端提供中继服务。此类中继通常应坚持要求发送者公布与其已知身份一致的发送地址。如果中继为可识别网络（如公司网络或ISP网络）提供服务，则足以阻止所有其他IP地址）。在其他情况下，必须使用显式身份验证。这方面的两个标准选择是TLS[STARTTLS]和SASL[SASLSMTP]。
Realistically, SMTP endpoints cannot refuse to deny service to unauthenticated senders. Since the vast majority of senders are unauthenticated, this would break Internet mail interoperability. The exception to this is when the endpoint server should only be
实际上，SMTP端点不能拒绝拒绝向未经身份验证的发件人提供服务。由于绝大多数发件人未经身份验证，这将破坏Internet邮件的互操作性。例外情况是，端点服务器应仅为
receiving mail from some other server which can itself receive unauthenticated messages. For instance, a company might operate a public gateway but configure its internal servers to only talk to the gateway.
接收来自其他服务器的邮件，该服务器本身可以接收未经验证的邮件。例如，一家公司可能运行一个公共网关，但将其内部服务器配置为仅与网关对话。
SMTP itself provides no communications security, and therefore a large number of attacks are possible. A passive attack is sufficient to recover the text of messages transmitted with SMTP. No endpoint authentication is provided by the protocol. Sender spoofing is trivial, and therefore forging email messages is trivial. Some implementations do add header lines with hostnames derived through reverse name resolution (which is only secure to the extent that it is difficult to spoof DNS -- not very), although these header lines are normally not displayed to users. Receiver spoofing is also fairly straight-forward, either using TCP connection hijacking or DNS spoofing. Moreover, since email messages often pass through SMTP gateways, all intermediate gateways must be trusted, a condition nearly impossible on the global Internet.
SMTP本身不提供通信安全，因此可能会发生大量攻击。被动攻击足以恢复使用SMTP传输的邮件文本。协议不提供端点身份验证。发件人欺骗是微不足道的，因此伪造电子邮件消息是微不足道的。有些实现确实添加了头行，其中主机名是通过反向名称解析派生的（只有在很难欺骗DNS的情况下才是安全的——不是很安全），尽管这些头行通常不会显示给用户。接收器欺骗也相当直接，使用TCP连接劫持或DNS欺骗。此外，由于电子邮件通常通过SMTP网关传递，因此必须信任所有中间网关，这在全球互联网上几乎是不可能的。
Several approaches are available for alleviating these threats. In order of increasingly high level in the protocol stack, we have:
有几种方法可用于缓解这些威胁。为了使协议栈中的级别越来越高，我们有：
SMTP over IPSEC SMTP/TLS S/MIME and PGP/MIME
通过IPSEC SMTP/TLS/MIME和PGP/MIME的SMTP
An SMTP connection run over IPSEC can provide confidentiality for the message between the sender and the first hop SMTP gateway, or between any pair of connected SMTP gateways. That is to say, it provides channel security for the SMTP connections. In a situation where the message goes directly from the client to the receiver's gateway, this may provide substantial security (though the receiver must still trust the gateway). Protection is provided against replay attacks, since the data itself is protected and the packets cannot be replayed.
通过IPSEC运行的SMTP连接可以为发件人和第一跳SMTP网关之间或任何一对连接的SMTP网关之间的邮件提供机密性。也就是说，它为SMTP连接提供通道安全性。在消息直接从客户端发送到接收方网关的情况下，这可以提供实质性的安全性（尽管接收方仍然必须信任网关）。由于数据本身受到保护且数据包无法重放，因此提供了防止重放攻击的保护。
Endpoint identification is a problem, however, unless the receiver's address can be directly cryptographically authenticated. Sender identification is not generally available, since generally only the sender's machine is authenticated, not the sender himself. Furthermore, the identity of the sender simply appears in the From header of the message, so it is easily spoofable by the sender. Finally, unless the security policy is set extremely strictly, there is also an active downgrade to cleartext attack.
然而，端点识别是一个问题，除非接收方的地址可以直接通过密码验证。发送者身份通常不可用，因为通常只有发送者的机器经过身份验证，而不是发送者本人。此外，发送者的身份仅出现在消息的From头中，因此发送者很容易对其进行欺骗。最后，除非安全策略设置得非常严格，否则还存在对明文攻击的主动降级。
Another problem with IPsec as a security solution for SMTP is the lack of a standard IPsec API. In order to take advantage of IPsec, applications in general need to be able to instruct the IPsec implementation about their security policies and discover what protection has been applied to their connections. Without a standard API this is very difficult to do portably.
IPsec作为SMTP安全解决方案的另一个问题是缺少标准的IPSecAPI。为了利用IPsec，应用程序通常需要能够向IPsec实现说明其安全策略，并发现对其连接应用了哪些保护。如果没有一个标准的API，这是很难做到可移植的。
Implementors of SMTP servers or SMTP administrators MUST NOT assume that IPsec will be available unless they have reason to believe that it will be (such as the existence of preexisting association between two machines). However, it may be a reasonable procedure to attempt to create an IPsec association opportunistically to a peer server when mail is delivered. Note that in cases where IPsec is used to provide a VPN tunnel between two sites, this is of substantial security value, particularly to the extent that confidentiality is provided, subject to the caveats mentioned above. Also see [USEIPSEC] for general guidance on the applicability of IPsec.
SMTP服务器或SMTP管理员的实现者不得假设IPsec将可用，除非他们有理由相信IPsec将可用（例如两台计算机之间存在预先存在的关联）。但是，在邮件传递时，尝试机会主义地创建与对等服务器的IPsec关联可能是一个合理的过程。请注意，在使用IPsec在两个站点之间提供VPN隧道的情况下，这具有重要的安全价值，特别是在提供保密性的情况下，但需遵守上述注意事项。另请参见[USEIPSEC]，了解IPsec适用性的一般指南。
SMTP can be combined with TLS as described in [STARTTLS]. This provides similar protection to that provided when using IPSEC. Since TLS certificates typically contain the server's host name, recipient authentication may be slightly more obvious, but is still susceptible to DNS spoofing attacks. Notably, common implementations of TLS contain a US exportable (and hence low security) mode. Applications desiring high security should ensure that this mode is disabled. Protection is provided against replay attacks, since the data itself is protected and the packets cannot be replayed. [Note: The Security Considerations section of the SMTP over TLS document is quite good and bears reading as an example of how to do things.]
SMTP可以与TLS组合，如[STARTTLS]中所述。这提供了与使用IPSEC时类似的保护。由于TLS证书通常包含服务器的主机名，因此收件人身份验证可能更为明显，但仍然容易受到DNS欺骗攻击。值得注意的是，TLS的常见实现包含美国可导出（因此安全性较低）模式。需要高安全性的应用程序应确保禁用此模式。由于数据本身受到保护且数据包无法重放，因此提供了防止重放攻击的保护。[注意：SMTP over TLS文档的安全注意事项部分非常好，值得阅读，作为如何操作的示例。]
S/MIME and PGP/MIME are both message oriented security protocols. They provide object security for individual messages. With various settings, sender and recipient authentication and confidentiality may be provided. More importantly, the identification is not of the sending and receiving machines, but rather of the sender and recipient themselves. (Or, at least, of cryptographic keys corresponding to the sender and recipient.) Consequently, end-to-end security may be obtained. Note, however, that no protection is provided against replay attacks. Note also that S/MIME and PGP/MIME generally provide identifying marks for both sender and receiver. Thus even when confidentiality is provided, traffic analysis is still possible.
S/MIME和PGP/MIME都是面向消息的安全协议。它们为单个消息提供对象安全性。通过各种设置，可以提供发送方和接收方身份验证和机密性。更重要的是，标识不是发送和接收机器，而是发送方和接收方本身。（或者，至少是对应于发送方和接收方的加密密钥的加密密钥）因此，可以获得端到端安全性。但是，请注意，没有针对重播攻击提供任何保护。还请注意，S/MIME和PGP/MIME通常为发送方和接收方提供识别标记。因此，即使提供了保密性，仍然可以进行流量分析。
None of these security measures provides any real protection against denial of service. SMTP connections can easily be used to tie up system resources in a number of ways, including excessive port consumption, excessive disk usage (email is typically delivered to disk files), and excessive memory consumption (sendmail, for instance, is fairly large, and typically forks a new process to deal with each message.)
这些安全措施都没有提供任何针对拒绝服务的真正保护。SMTP连接可以通过多种方式轻松地用于占用系统资源，包括过度的端口消耗、过度的磁盘使用（电子邮件通常发送到磁盘文件）和过度的内存消耗（例如，sendmail相当大，通常会分叉一个新的进程来处理每条邮件）
If transport- or application-layer security is used for SMTP connections, it is possible to mount a variety of attacks on individual connections using forged RSTs or other kinds of packet injection.
如果SMTP连接使用传输层或应用层安全，则可能使用伪造RST或其他类型的数据包注入对单个连接发起各种攻击。
The second example is from VRRP, the Virtual Router Redundance Protocol ([VRRP]). We reproduce here the Security Considerations section from that document (with new section numbers). Our comments are indented and prefaced with 'NOTE:'.
第二个例子来自虚拟路由器冗余协议（VRRP）。我们在此复制该文件中的安全注意事项部分（带有新的部分编号）。我们的评论缩进并以“备注：”开头。
VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods ranging from no authentication, simple clear text passwords, and strong authentication using IP Authentication with MD5 HMAC. The details on each approach including possible attacks and recommended environments follows.
VRRP是为一系列可能采用不同安全策略的互联网环境而设计的。该协议包括多种身份验证方法，包括无身份验证、简单明文密码和使用MD5 HMAC的IP身份验证的强身份验证。下面将详细介绍每种方法，包括可能的攻击和推荐的环境。
Independent of any authentication type VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks.
独立于任何身份验证类型，VRRP包括一种机制（设置TTL=255，接收时检查），可防止从另一远程网络注入VRRP数据包。这限制了大多数易受本地攻击的漏洞。
NOTE: The security measures discussed in the following sections only provide various kinds of authentication. No confidentiality is provided at all. This should be explicitly described as outside the scope.
注意：以下章节中讨论的安全措施仅提供各种身份验证。没有提供任何保密性。这应明确描述为超出范围。
The use of this authentication type means that VRRP protocol exchanges are not authenticated. This type of authentication SHOULD only be used in environments were there is minimal security risk and little chance for configuration errors (e.g., two VRRP routers on a LAN).
使用此身份验证类型意味着VRRP协议交换未经身份验证。只有在安全风险最小且配置错误的可能性很小的环境中（例如，局域网上的两个VRRP路由器），才应使用这种类型的身份验证。
The use of this authentication type means that VRRP protocol exchanges are authenticated by a simple clear text password.
使用这种身份验证类型意味着VRRP协议交换通过简单的明文密码进行身份验证。
This type of authentication is useful to protect against accidental misconfiguration of routers on a LAN. It protects against routers inadvertently backing up another router. A new router must first be configured with the correct password before it can run VRRP with another router. This type of authentication does not protect against hostile attacks where the password can be learned by a node snooping VRRP packets on the LAN. The Simple Text Authentication combined with the TTL check makes it difficult for a VRRP packet to be sent from another LAN to disrupt VRRP operation.
这种类型的身份验证有助于防止局域网上路由器的意外错误配置。它可以防止路由器无意中备份另一个路由器。新路由器必须首先配置正确的密码，然后才能使用其他路由器运行VRRP。这种类型的身份验证无法防止恶意攻击，因为节点可以通过窥探局域网上的VRRP数据包来获取密码。简单的文本身份验证与TTL检查相结合，使得从另一个LAN发送VRRP数据包很难中断VRRP操作。
This type of authentication is RECOMMENDED when there is minimal risk of nodes on a LAN actively disrupting VRRP operation. If this type of authentication is used the user should be aware that this clear text password is sent frequently, and therefore should not be the same as any security significant password.
当LAN上的节点主动中断VRRP操作的风险最小时，建议使用这种类型的身份验证。如果使用这种类型的身份验证，用户应该知道此明文密码经常发送，因此不应与任何重要安全密码相同。
NOTE: This section should be clearer. The basic point is that no authentication and Simple Text are only useful for a very limited threat model, namely that none of the nodes on the local LAN are hostile. The TTL check prevents hostile nodes off-LAN from posing as valid nodes, but nothing stops hostile nodes on-LAN from impersonating authorized nodes. This is not a particularly realistic threat model in many situations. In particular, it's extremely brittle: the compromise of any node the LAN allows reconfiguration of the VRRP nodes.
注：本节应更清晰。基本要点是，没有身份验证和简单文本仅对非常有限的威胁模型有用，即本地LAN上的节点都没有恶意。TTL检查可防止LAN外的敌对节点冒充有效节点，但无法阻止LAN上的敌对节点冒充授权节点。在许多情况下，这不是一个特别现实的威胁模型。特别是，它非常脆弱：局域网中任何节点的妥协都允许VRRP节点的重新配置。
The use of this authentication type means the VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AH] using [HMAC]. This provides strong protection against configuration errors, replay attacks, and packet corruption/modification.
使用此身份验证类型意味着使用IP身份验证头[AH]使用[HMAC]定义的机制对VRRP协议交换进行身份验证。这为配置错误、重播攻击和数据包损坏/修改提供了强大的保护。
This type of authentication is RECOMMENDED when there is limited control over the administration of nodes on a LAN. While this type of authentication does protect the operation of VRRP, there are other types of attacks that may be employed on shared media links (e.g., generation of bogus ARP replies) which are independent from VRRP and are not protected.
当对LAN上节点的管理控制有限时，建议使用这种类型的身份验证。虽然这种类型的身份验证确实可以保护VRRP的操作，但在共享媒体链接上可能会使用其他类型的攻击（例如，生成虚假ARP回复），这些攻击独立于VRRP，不受保护。
NOTE: It's a mistake to have AH be a RECOMMENDED in this context. Since AH is the only mechanism that protects VRRP against attack from other nodes on the same LAN, it should be a MUST for cases where there are untrusted nodes on the same network. In any case, AH should be a MUST implement.
注意：在这种情况下，将AH作为推荐值是错误的。由于AH是保护VRRP免受同一LAN上其他节点攻击的唯一机制，因此在同一网络上存在不受信任节点的情况下，AH应该是必须的。在任何情况下，啊都应该是必须实施的。
NOTE: There's an important piece of security analysis that's only hinted at in this document, namely the cost/benefit tradeoff of VRRP authentication.
注意：本文档中仅暗示了一个重要的安全分析，即VRRP身份验证的成本/收益权衡。
[The rest of this section is NEW material] The threat that VRRP authentication is intended to prevent is an attacker arranging to be the VRRP master. This would be done by joining the group (probably multiple times), gagging the master and then electing oneself master. Such a node could then direct traffic in arbitrary undesirable ways.
[本节其余部分为新材料]VRRP身份验证旨在防止的威胁是攻击者安排成为VRRP主机。这可以通过加入团队（可能多次），堵住大师的嘴，然后选择自己的大师来实现。这样的节点可以以任意不希望的方式引导通信。
However, it is not necessary for an attacker to be the VRRP master to do this. An attacker can do similar kinds of damage to the network by forging ARP packets or (on switched networks) fooling the switch VRRP authentication offers no real protection against these attacks.
但是，攻击者没有必要成为VRRP主机来执行此操作。攻击者可以通过伪造ARP数据包或（在交换网络上）欺骗交换机对网络造成类似的破坏VRRP身份验证无法提供针对这些攻击的真正保护。
Unfortunately, authentication makes VRRP networks very brittle in the face of misconfiguration. Consider what happens if two nodes are configured with different passwords. Each will reject messages from the other and therefore both will attempt to be master. This creates substantial network instability.
不幸的是，身份验证使得VRRP网络在面对错误配置时非常脆弱。考虑两个节点配置不同密码时会发生什么情况。每一个都将拒绝来自另一个的消息，因此两者都将尝试成为主消息。这造成了严重的网络不稳定。
This set of cost/benefit tradeoffs suggests that VRRP authentication is a bad idea, since the incremental security benefit is marginal but the incremental risk is high. This judgment should be revisited if the current set of non-VRRP threats are removed.
这组成本/收益权衡表明，VRRP身份验证是一个坏主意，因为增加的安全性收益微乎其微，但增加的风险很高。如果删除了当前的非VRRP威胁集，则应重新考虑该判断。
This document is heavily based on a note written by Ran Atkinson in 1997. That note was written after the IAB Security Workshop held in early 1997, based on input from everyone at that workshop. Some of the specific text above was taken from Ran's original document, and some of that text was taken from an email message written by Fred Baker. The other primary source for this document is specific comments received from Steve Bellovin. Early review of this document was done by Lisa Dusseault and Mark Schertler. Other useful comments were received from Bill Fenner, Ned Freed, Lawrence Greenfield, Steve Kent, Allison Mankin and Kurt Zeilenga.
本文件主要基于Ran Atkinson在1997年写的一份说明。该说明是在1997年初举行的IAB安全研讨会之后根据研讨会上每个人的意见编写的。上面的一些特定文本取自Ran的原始文档，其中一些文本取自Fred Baker编写的电子邮件。本文件的另一个主要来源是Steve Bellovin提供的具体意见。Lisa Dusseault和Mark Schertler对本文件进行了早期审查。比尔·芬纳、内德·弗里德、劳伦斯·格林菲尔德、史蒂夫·肯特、艾莉森·曼金和库尔特·泽林加还发表了其他有用的评论。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946, September, 2000.
[ENCOPT]Tso，T.，“Telnet数据加密选项”，RFC 29462000年9月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[GSS] Linn, J., "Generic Security Services Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSS]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "HyperText Transfer Protocol", RFC 2616, June 1999.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议”，RFC2616，1999年6月。
[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[HTTPTLS]Rescorla，E.，“HTTP over TLS”，RFC 28182000年5月。
[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[HMAC]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
KERBEROS]Kohl，J.和C.Neuman，“KERBEROS网络身份验证服务（V5）”，RFC15101993年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[OTP]Haller，N.，Metz，C.，Nesser，P.和M.Straw，“一次性密码系统”，STD 61，RFC 2289，1998年2月。
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[PHOTURIS]Karn，P.和W.Simpson，“PHOTURIS:会话密钥管理协议”，RFC2521999年3月。
[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 "Public Key Infrastructure Certificate and Certificate Restoration List (CRL) Profile", RFC 3280, April 2002.
[PKIX]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509”公钥基础设施证书和证书恢复列表（CRL）简介”，RFC 32802002年4月。
[RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC-2223]Postel J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC-2505]Lindberg，G.，“SMTP MTA的反垃圾邮件建议”，BCP 30，RFC 2505，1999年2月。
[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[SPKI]Ellison，C.，Frantz，B.，Lampson，B.，Rivest，R.，Thomas，B.和T.Ylonen，“SPKI证书理论”，RFC 26931999年9月。
[SSH] Ylonen, T., "SSH - Secure Login Connections Over the Internet", 6th USENIX Security Symposium, p. 37-42, July 1996.
[SSH]Ylonen，T.，“SSH-互联网上的安全登录连接”，第六届USENIX安全研讨会，第页。1996年7月37日至42日。
[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SASLSMTP]Myers，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[STARTTLS]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[S-HTTP]Rescorla，E.和A.Schiffman，“安全超文本传输协议”，RFC 2660，1999年8月。
[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[S/MIME]Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TELNET]Postel，J.和J.Reynolds，“TELNET协议规范”，STD 8，RFC 854，1983年5月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D. and J. Mikkelsen, "Transport Layer Security (TLS) Extensions", RFC 3546, May 2003.
[TLSEXT]Blake Wilson，S.，Nystrom，M.，Hopwood，D.和J.Mikkelsen，“传输层安全（TLS）扩展”，RFC 3546，2003年5月。
[TCPSYN] "TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory
CA-1996-21, 19 September 1996, CERT.
http://www.cert.org/advisories/CA-1996-21.html
[TCPSYN] "TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory
CA-1996-21, 19 September 1996, CERT.
http://www.cert.org/advisories/CA-1996-21.html
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[升级]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[URL] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]Berners Lee，T.，Masinter，M.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[VRRP] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M. and A. Lindemn, "Virtual Router Redundancy Protocol", RFC 2338, April 1998.
[VRRP]Knight，S.，Weaver，D.，Whipple，D.，Hinden，R.，Mitzel，D.，Hunt，P.，Higginson，P.，Shand，M.和A.Lindemn，“虚拟路由器冗余协议”，RFC 2338，1998年4月。
[DDOS] "Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28
December 1999, CERT http://www.cert.org/advisories/CA-
1999-17.html
[DDOS] "Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28
December 1999, CERT http://www.cert.org/advisories/CA-
1999-17.html
[EKE] Bellovin, S., Merritt, M., "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992.
[EKE]Bellovin，S.，Merritt，M.，“加密密钥交换：基于密码的协议防止字典攻击”，IEEE安全和隐私研究研讨会论文集，1992年5月。
[IDENT] St. Johns, M. and M. Rose, "Identification Protocol", RFC 1414, February 1993.
[识别]圣约翰，M.和M.罗斯，“识别协议”，RFC 14141993年2月。
[INTAUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[INTAUTH]Haller，N.和R.Atkinson，“互联网认证”，RFC 17041994年10月。
[IPSPPROB] Bellovin, S. M., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix UNIX Security Symposium, July 1996.
[IPSPROB]Bellovin，S.M.，“IP安全协议的问题领域”，第六届Usenix UNIX安全研讨会论文集，1996年7月。
[KLEIN] Klein, D.V., "Foiling the Cracker: A Survey of and Improvements to Password Security", 1990.
[KLEIN]KLEIN，D.V.，“挫败黑客：密码安全的调查和改进”，1990年。
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[NNTP]Kantor，B.和P.Lapsley，“网络新闻传输协议”，RFC 977，1986年2月。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[SEQNUM] Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP Software", AT&T Bell Laboratories, CSTR 117, 1985.
[SEQNUM]Morris，R.T.，“4.2 BSD UNIX TCP/IP软件中的弱点”，AT&T贝尔实验室，CSTR 117，1985年。
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D., "Simple Object Access Protocol (SOAP) 1.1", May 2000.
[SOAP]Box，D.，Ehnebuske，D.，Kakivaya，G.，Layman，A.，Mendelsoh，N.，Nielsen，H.，Thatte，S.，Winer，D.，“简单对象访问协议（SOAP）1.1”，2000年5月。
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5, pp. 5-26, October 1996.
[SPEKE]Jablon，D.，“仅强密码认证密钥交换”，《计算机通信评论》，ACM SIGCOMM，第26卷，第5期，第5-26页，1996年10月。
[SRP] Wu T., "The Secure Remote Password Protocol", ISOC NDSS Symposium, 1998.
[SRP]Wu T.，“安全远程密码协议”，ISOC NDSS研讨会，1998年。
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress.
[USEIPSEC]Bellovin，S.，“强制使用IPsec的指南”，正在进行中。
[WEP] Borisov, N., Goldberg, I., Wagner, D., "Intercepting
Mobile Communications: The Insecurity of 802.11",
http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf
[WEP] Borisov, N., Goldberg, I., Wagner, D., "Intercepting
Mobile Communications: The Insecurity of 802.11",
http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf
This entire document is about security considerations.
整个文档都是关于安全方面的考虑。
Appendix A.
附录A。
IAB Members at the time of this writing
撰写本文时的IAB成员
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
哈拉尔·阿尔维斯特兰德（Harald Alvestrand）经营的是阿特金森（Atkinson）、罗布·奥斯汀（Rob Austein）、弗雷德·贝克（Fred Baker）、莱斯利·戴格尔（Leslie Daigle）、史蒂夫·迪林（Steve Deering）、萨莉·弗洛伊德（Sally Floyd）、泰德·哈迪（Ted Hardie）、杰夫·休斯顿（Ge
Authors' Addresses
作者地址
Eric Rescorla RTFM, Inc. 2439 Alvin Drive Mountain View, CA 94043
Eric Rescorla RTFM公司，地址：加利福尼亚州阿尔文大道山景城2439号，邮编：94043
Phone: (650)-320-8549 EMail: ekr@rtfm.com
电话：（650）-320-8549电子邮件：ekr@rtfm.com
Brian Korver Xythos Software, Inc. 77 Maiden Lane, 6th Floor San Francisco, CA, 94108
Brian Korver Xythos软件公司，77梅登小径，第六楼，旧金山，CA，94108
Phone: (415)-248-3800 EMail: briank@xythos.com
电话：（415）-248-3800电子邮件：briank@xythos.com
Internet Architecture Board IAB EMail: iab@iab.org
互联网架构委员会IAB电子邮件：iab@iab.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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编辑功能的资金目前由互联网协会提供。