Network Working Group S. Bellovin, Ed.
Request for Comments: 3631 J. Schiller, Ed.
Category: Informational C. Kaufman, Ed.
Internet Architecture Board
December 2003
Network Working Group S. Bellovin, Ed.
Request for Comments: 3631 J. Schiller, Ed.
Category: Informational C. Kaufman, Ed.
Internet Architecture Board
December 2003
Security Mechanisms for the Internet
因特网的安全机制
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.
为了使这些协议能够安全地提供服务，必须将安全性内置到互联网协议中。许多安全问题可以追溯到不正确的实现。然而，如果基本协议本身是可利用的，那么即使是正确的实现也会有安全问题。由于协议本身的结构不同，协议中应该如何实现安全性将有所不同。然而，已经开发的标准Internet安全机制可能适用于许多协议。适用于任何特定情况的精确方法可能会有所不同。我们回顾了许多不同的选择，解释了每种选择的性质。
Internet Security compromises can be divided into several classes, ranging from Denial of Service to Host Compromise. Denial of Service attacks based on sheer volume of traffic are beyond the scope of this document, though they are the subject of much ongoing discussion and research. It is important to note that many such attacks are made more difficult by good security practices. Host Compromise (most commonly caused by undetected Buffer Overflows) represent flaws in individual implementations rather than flaws in protocols. Nevertheless, carefully designed protocols can make such flaws less likely to occur and harder to exploit.
互联网安全危害可分为几类，从拒绝服务到主机危害。基于绝对流量的拒绝服务攻击超出了本文的范围，尽管它们是许多正在进行的讨论和研究的主题。必须指出的是，良好的安全做法使许多此类攻击变得更加困难。主机泄露（最常见的原因是未检测到的缓冲区溢出）表示单个实现中的缺陷，而不是协议中的缺陷。尽管如此，精心设计的协议可以减少此类缺陷的发生，并且更难利用。
However, there are security compromises that are facilitated by the very protocols that are in use on the Internet. If a security problem is inherent in a protocol, no manner of implementation will be able to prevent the problem.
然而，互联网上使用的协议本身也有助于安全方面的妥协。如果协议中存在固有的安全问题，则任何实现方式都无法防止该问题。
It is therefore vitally important that protocols developed for the Internet provide this fundamental security.
因此，为互联网开发的协议提供这一基本安全至关重要。
Exactly how a protocol should be secured depends on the protocol itself as well as the security needs of the protocol. However, we have developed a number of standard security mechanisms in the IETF. In many cases appropriate application of these mechanisms can provide the necessary security for a protocol.
协议的确切安全性取决于协议本身以及协议的安全需求。然而，我们在IETF中开发了许多标准安全机制。在许多情况下，适当应用这些机制可以为协议提供必要的安全性。
A number of possible mechanisms can be used to provide security on the Internet. Which one should be selected depends on many different factors. We attempt here to provide guidance, spelling out the factors and the currently-standardized (or about-to-be-standardized) solutions, as discussed at the IAB Security Architecture Workshop [RFC2316].
许多可能的机制可用于在互联网上提供安全性。选择哪一个取决于许多不同的因素。我们试图在这里提供指导，阐明因素和当前标准化（或即将标准化）的解决方案，如IAB安全体系结构研讨会[RFC2316]所述。
Security, however, is an art, not a science. Attempting to follow a recipe blindly can lead to disaster. As always, good taste in protocol design should be exercised.
然而，安全是一门艺术，而不是一门科学。试图盲目遵循食谱可能导致灾难。和往常一样，在协议设计方面要有良好的品味。
Finally, security mechanisms are not magic pixie dust that can be sprinkled over completed protocols. It is rare that security can be bolted on later. Good designs -- that is, secure, clean, and efficient designs -- occur when the security mechanisms are crafted along with the protocol. No conceivable exercise in cryptography can secure a protocol with flawed semantic assumptions.
最后，安全机制并不是可以撒在已完成协议上的神奇精灵。很少有人能在以后安装安全装置。好的设计——即安全、干净和高效的设计——发生在安全机制与协议一起构建时。在密码学中，没有一种可行的方法能够保证一个语义假设有缺陷的协议的安全。
The most important factor in choosing a security mechanism is the threat model. That is, who may be expected to attack what resource, using what sorts of mechanisms? A low-value target, such as a Web site that offers public information only, may not merit much protection. Conversely, a resource that if compromised could expose significant parts of the Internet infrastructure, say, a major backbone router or high-level Domain Name Server, should be protected by very strong mechanisms. The value of a target to an attacker depends on the purpose of the attack. If the purpose is to access sensitive information, all systems that handle this information or mediate access to it are valuable. If the purpose is to wreak havoc, systems on which large parts of the Internet depend are exceedingly
选择安全机制的最重要因素是威胁模型。也就是说，谁可能会使用什么样的机制攻击什么资源？低价值目标，如仅提供公共信息的网站，可能不值得太多保护。相反，如果资源遭到破坏，可能会暴露互联网基础设施的重要部分，例如，主要骨干路由器或高级域名服务器，则应通过非常强大的机制进行保护。目标对攻击者的价值取决于攻击目的。如果目的是访问敏感信息，则处理此信息或调解对其访问的所有系统都是有价值的。如果其目的是造成严重破坏，那么大部分互联网所依赖的系统将极度脆弱
valuable. Even if only public information is posted on a web site, changing its contents can cause embarrassment to its owner and could result in substantial damage. It is difficult when designing a protocol to predict what uses that protocol will someday have.
有价值的即使只有公共信息发布在网站上，更改其内容也会使其所有者感到尴尬，并可能造成重大损失。在设计协议时，很难预测该协议将来会有什么用途。
All Internet connected systems require a minimum amount of protection. Starting in 2000 and continuing to the present, we have witnessed the advent of a new type of Internet security attack: an Internet "worm" program that seeks out and automatically attacks systems that are vulnerable to compromise via a number of attacks built into the worm program itself. These worm programs can compromise literally thousands of systems within a very short period of time. Note that the first Internet Worm was the "Morris" worm of 1988. However, it was not followed up with similar programs for over 12 years!
所有连接互联网的系统都需要最低限度的保护。从2000年开始，一直到现在，我们目睹了一种新型的互联网安全攻击的出现：一种互联网“蠕虫”程序，它通过蠕虫程序本身内置的一系列攻击来寻找并自动攻击易受危害的系统。这些蠕虫程序可以在很短的时间内危害数千个系统。请注意，第一个互联网蠕虫是1988年的“莫里斯”蠕虫。然而，在过去的12年里，没有类似的项目跟进！
As of the writing of this document, all of these worms have taken advantage of programming errors in the implementation of otherwise reasonably secure protocols. However, it is not hard to envision an attack that targets a fundamental security flaw in a widely deployed protocol. It is therefore imperative that we strive to minimize such flaws in the protocols we design.
在撰写本文档时，所有这些蠕虫都利用了在实现其他合理安全的协议时出现的编程错误。然而，不难想象一种攻击会针对广泛部署的协议中的一个基本安全缺陷。因此，我们必须努力将我们设计的协议中的此类缺陷降至最低。
The value of a target to an attacker may depend on where it is located. A network monitoring station that is physically on a backbone cable is a major target, since it could easily be turned into an eavesdropping station. The same machine, if located on a stub net and used for word processing, would be of much less use to a sophisticated attacker, and hence would be at significantly less risk.
目标对攻击者的价值可能取决于其所在位置。物理上位于主干电缆上的网络监控站是一个主要目标，因为它很容易变成窃听站。同一台机器，如果位于存根网络上并用于字处理，对于复杂的攻击者来说用处会小得多，因此风险会大大降低。
One must also consider what sorts of attacks may be expected. At a minimum, eavesdropping must be seen as a serious threat; there have been very many such incidents since at least 1993. Often, active attacks, that is, attacks that involve insertion or deletion of packets by the attacker, are a risk as well. It is worth noting that such attacks can be launched with off-the-shelf tools, and have in fact been observed "in the wild". Of particular interest is a form of attack called "session hijacking", where someone on a link between the two communicating parties wait for authentication to complete and then impersonate one of the parties and continue the connection with the other.
我们也必须考虑到什么样的攻击是可以预料到的。至少，窃听必须被视为严重威胁；至少自1993年以来，已经发生了很多此类事件。通常，主动攻击（即攻击者插入或删除数据包的攻击）也是一种风险。值得注意的是，这种攻击可以用现成的工具发动，而且事实上“在野外”也观察到过。特别令人感兴趣的是一种称为“会话劫持”的攻击形式，即通信双方之间的链路上有人等待身份验证完成，然后冒充其中一方并继续与另一方的连接。
One of the most important tools available to us for securing protocols is cryptography. Cryptography permits us to apply various kinds of protection to data as it traverses the network, without having to depend on any particular security properties of the network itself. This is important because the Internet, by its distributed
我们可以使用的保护协议的最重要工具之一是密码术。密码学允许我们在数据通过网络时对其应用各种保护，而不必依赖于网络本身的任何特定安全属性。这一点很重要，因为互联网通过其分布式
management and control, cannot be considered a trustworthy media in and of itself. Its security derives from the mechanisms that we build into the protocols themselves, independent of the underlying media or network operators.
管理和控制本身不能被视为值得信赖的媒体。它的安全性来自于我们在协议本身中构建的机制，独立于底层媒体或网络运营商。
Finally, of course, there is the cost to the defender of using cryptography. This cost is dropping rapidly; Moore's Law, plus the easy availability of cryptographic components and toolkits, makes it relatively easy to use strong protective techniques. Although there are exceptions, public key operations are still expensive, perhaps prohibitively so if the cost of each public-key operation is spread over too few transactions, careful engineering design can generally let us spread this cost over many transactions.
当然，最后一点是，使用加密技术的捍卫者要付出代价。这一成本正在迅速下降；摩尔定律，加上加密组件和工具包的易用性，使得使用强保护技术相对容易。尽管有例外，公钥操作仍然很昂贵，因此如果每个公钥操作的成本分散在太少的事务上，那么仔细的工程设计通常可以让我们将此成本分散在许多事务上。
In general, the default today should be to use the strongest cryptography available in any protocol. Strong cryptography often costs no more, and sometimes less, then weaker cryptography. The actual performance cost of an algorithm is often unrelated to the security it provides. Depending on the hardware available, cryptography can be performed at very high rates (1+Gbps), and even in software its performance impact is shrinking over time.
一般来说，今天的默认设置应该是使用任何协议中可用的最强加密。强加密通常不会比弱加密花费更多，有时甚至更少。算法的实际性能成本通常与其提供的安全性无关。根据可用的硬件，加密可以以非常高的速率（1+Gbps）执行，即使在软件中，其性能影响也会随着时间的推移而减小。
We have evolved in the IETF the notion of "mandatory to implement" mechanisms. This philosophy evolves from our primary desire to ensure interoperability between different implementations of a protocol. If a protocol offers many options for how to perform a particular task, but fails to provide for at least one that all must implement, it may be possible that multiple, non-interoperable implementations may result. This is the consequence of the selection of non-overlapping mechanisms being deployed in the different implementations.
我们在IETF中形成了“强制实施”机制的概念。这一理念源于我们的主要愿望，即确保协议的不同实现之间的互操作性。如果协议为如何执行特定任务提供了许多选项，但没有提供至少一个所有人都必须实现的选项，则可能会导致多个不可互操作的实现。这是在不同实现中选择非重叠机制的结果。
Although a given protocol may make use of only one or a few security mechanisms, these mechanisms themselves often can make use of several cryptographic systems. The various cryptographic systems vary in strength and performance. However, in many protocols we need to specify a "mandatory to implement" to ensure that any two implementations will eventually be able to negotiate a common cryptographic system between them.
尽管给定的协议可能只使用一个或几个安全机制，但这些机制本身通常可以使用多个密码系统。各种密码系统的强度和性能各不相同。然而，在许多协议中，我们需要指定一个“强制实现”，以确保任何两个实现最终都能够在它们之间协商一个公共密码系统。
There are some protocols that were originally designed to be run in a very limited domain. It is often argued that the domain of implementation for a particular protocol is sufficiently well defined and secure that the protocol itself need not provide any security mechanisms.
有些协议最初设计用于在非常有限的域中运行。通常认为，特定协议的实现域定义充分且安全，协议本身不需要提供任何安全机制。
History has shown this argument to be wrong. Inevitably, successful protocols - even if developed for limited use - wind up used in a broader environment, where the initial security assumptions do not hold.
历史证明这一论点是错误的。不可避免地，成功的协议——即使是为有限的用途而开发的——最终会在更广泛的环境中使用，而在这种环境中，最初的安全假设并不成立。
To solve this problem, the IETF requires that *ALL* protocols provide appropriate security mechanisms, even when their domain of application is at first believed to be very limited.
为了解决这个问题，IETF要求*所有*协议提供适当的安全机制，即使最初认为它们的应用领域非常有限。
It is important to understand that mandatory mechanisms are mandatory to *implement*. It is not necessarily mandatory that end-users actually use these mechanisms. If an end-user knows that they are deploying a protocol over a "secure" network, then they may choose to disable security mechanisms that they believe are adding insufficient value as compared to their performance cost. (We are generally skeptical of the wisdom of disabling strong security even then, but that is beyond the scope of this document.)
重要的是要理解，强制性机制对*实施*是强制性的。最终用户实际使用这些机制并不一定是强制性的。如果最终用户知道他们正在“安全”网络上部署协议，那么他们可能会选择禁用他们认为与性能成本相比没有增加足够价值的安全机制。（即使在那时，我们也普遍怀疑禁用强安全性是否明智，但这超出了本文的范围。）
Insisting that certain mechanisms are mandatory to implement means that those end-users who need the protocol provided by the security mechanism have it available when needed. Particularly with security mechanisms, just because a mechanism is mandatory to implement does not imply that it should be the default mechanism or that it may not be disabled by configuration. If a mandatory to implement algorithm is old and weak, it is better to disable it when a stronger algorithm is available.
坚持某些机制是强制实施的，这意味着需要安全机制提供的协议的最终用户在需要时可以使用该协议。特别是对于安全机制，仅仅因为机制是强制实现的，并不意味着它应该是默认机制，或者它可能不会被配置禁用。如果强制实现的算法是旧的和弱的，最好在有更强的算法可用时禁用它。
Some security mechanisms can protect an entire network. While this economizes on hardware, it can leave the interior of such networks open to attacks from the inside. Other mechanisms can provide protection down to the individual user of a timeshared machine, though perhaps at risk of user impersonation if the machine has been compromised.
一些安全机制可以保护整个网络。虽然这样可以节省硬件，但会使此类网络的内部受到来自内部的攻击。其他机制可以为分时机器的单个用户提供保护，但如果机器被破坏，可能会有用户冒充的风险。
When assessing the desired granularity of protection, protocol designers should take into account likely usage patterns, implementation layers (see below), and deployability. If a protocol is likely to be used only from within a secure cluster of machines (say, a Network Operations Center), subnet granularity may be appropriate. By contrast, a security mechanism peculiar to a single application is best embedded in that application, rather than inside TCP; otherwise, deployment will be very difficult.
在评估所需的保护粒度时，协议设计者应考虑可能的使用模式、实现层（见下文）和可部署性。如果协议可能仅在安全的计算机集群（例如，网络操作中心）内使用，则子网粒度可能是合适的。相比之下，单个应用程序特有的安全机制最好嵌入到该应用程序中，而不是嵌入到TCP中；否则，部署将非常困难。
Security mechanisms can be located at any layer. In general, putting a mechanism at a lower layer protects a wider variety of higher-layer protocols, but may not be able to protect them as well. A link-layer encryptor can protect not just IP, but even ARP packets. However, its reach is just that one link. Conversely, a signed email message is protected even if sent through many store-and-forward mail gateways, can identify the actual sender, and the signature can be verified long after the message is delivered. However, only that one type of message is protected. Messages of similar formats, such as some Netnews postings, are not protected unless the mechanism is specifically adapted and then implemented in the news-handling programs.
安全机制可以位于任何层。一般来说，将一种机制放在较低的一层可以保护更广泛的高层协议，但也可能无法保护它们。链路层加密机不仅可以保护IP，甚至可以保护ARP数据包。然而，它所能触及的只是这一个环节。相反，签名的电子邮件即使通过许多存储转发邮件网关发送，也会受到保护，可以识别实际的发件人，并且签名可以在邮件传递后很久进行验证。但是，只有一种类型的消息受到保护。类似格式的消息（如某些Netnews帖子）不受保护，除非该机制经过专门调整，然后在新闻处理程序中实现。
One-time password schemes, such as that described in [RFC2289], are very much stronger than conventional passwords. The host need not store a copy of the user's password, nor is it ever transmitted over the network. However, there are some risks. Since the transmitted string is derived from a user-typed password, guessing attacks may still be feasible. (Indeed, a program to launch just this attack is readily available.) Furthermore, the user's ability to login necessarily expires after a predetermined number of uses. While in many cases this is a feature, an implementation most likely needs to provide a way to reinitialize the authentication database, without requiring that the new password be sent in the clear across the network.
一次性密码方案，如[RFC2289]中所述，比传统密码强大得多。主机不需要存储用户密码的副本，也不需要通过网络传输。然而，也存在一些风险。由于传输的字符串来自用户键入的密码，猜测攻击可能仍然可行。（事实上，一个只发起这种攻击的程序是现成的。）此外，用户登录的能力在预定的使用次数后必然会失效。虽然在许多情况下这是一项功能，但实现很可能需要提供一种重新初始化身份验证数据库的方法，而无需通过网络以明文形式发送新密码。
There are commercial hardware authentication tokens. Apart from the session hijacking issue, support for such tokens (especially challenge/response tokens, where the server sends a different random number for each authentication attempt) may require extra protocol messages.
存在商业硬件身份验证令牌。除了会话劫持问题外，支持此类令牌（特别是质询/响应令牌，其中服务器为每次身份验证尝试发送不同的随机数）可能需要额外的协议消息。
HMAC [RFC2104] is the preferred shared-secret authentication technique. If both sides know the same secret key, HMAC can be used to authenticate any arbitrary message. This includes random challenges, which means that HMAC can be adapted to prevent replays of old sessions.
HMAC[RFC2104]是首选的共享秘密认证技术。如果双方都知道相同的密钥，HMAC可以用于对任意消息进行身份验证。这包括随机挑战，这意味着HMAC可以进行调整以防止旧会话的重播。
An unfortunate disadvantage of using HMAC for connection authentication is that the secret must be known in the clear by both parties, making this undesirable when keys are long-lived.
使用HMAC进行连接身份验证的一个不幸的缺点是，双方必须清楚地知道秘密，这使得在密钥长期存在时，这是不可取的。
When suitable, HMAC should be used in preference to older techniques, notably keyed hash functions. Simple keyed hashes based on MD5 [RFC1321], such as that used in the BGP session security mechanism [RFC2385], are especially to be avoided in new protocols, given the hints of weakness in MD5.
在合适的情况下，HMAC应该优先于旧技术使用，尤其是键控哈希函数。基于MD5[RFC1321]的简单密钥散列，例如BGP会话安全机制[RFC2385]中使用的密钥散列，在新协议中尤其要避免，因为MD5中存在弱点。
HMAC can be implemented using any secure hash function, including MD5 and SHA-1 [RFC3174]. SHA-1 is preferable for new protocols because it is more frequently used for this purpose and may be more secure.
HMAC可以使用任何安全哈希函数实现，包括MD5和SHA-1[RFC3174]。SHA-1更适合用于新协议，因为它更频繁地用于此目的，并且可能更安全。
It is important to understand that an HMAC-based mechanism needs to be employed on every protocol data unit (aka packet). It is a mistake to use an HMAC-based system to authenticate the beginning of a TCP session and then send all remaining data without any protection.
重要的是要理解，每个协议数据单元（aka数据包）都需要采用基于HMAC的机制。使用基于HMAC的系统对TCP会话的开始进行身份验证，然后在没有任何保护的情况下发送所有剩余数据是错误的。
Attack programs exist that permit a TCP session to be stolen. An attacker merely needs to use such a tool to steal a session after the HMAC step is performed.
存在允许TCP会话被盗的攻击程序。攻击者只需在执行HMAC步骤后使用此类工具窃取会话。
IPsec [RFC2401],[RFC2402],[RFC2406],[RFC2407],[RFC2411] is the generic IP-layer encryption and authentication protocol. As such, it protects all upper layers, including both TCP and UDP. Its normal granularity of protection is host-to-host, host-to-gateway, and gateway-to-gateway. The specification does permit user-granularity protection, but this is comparatively rare. As such, IPsec is currently inappropriate when host-granularity is too coarse.
IPsec[RFC2401]、[RFC2402]、[RFC2406]、[RFC2407]、[RFC2411]是通用的IP层加密和身份验证协议。因此，它保护所有上层，包括TCP和UDP。它的正常保护粒度是主机到主机、主机到网关和网关到网关。该规范确实允许用户粒度保护，但这相对较少。因此，当主机粒度太粗时，IPsec目前是不合适的。
Because IPsec is installed at the IP layer, it is rather intrusive to the networking code. Implementing it generally requires either new hardware or a new protocol stack. On the other hand, it is fairly transparent to applications. Applications running over IPsec can have improved security without changing their protocols at all. But at least until IPsec is more widely deployed, most applications should not assume they are running atop IPsec as an alternative to specifying their own security mechanisms. Most modern operating systems have IPsec available; most routers do not, at least for the control path. An application using TLS is more likely to be able to assert application-specific to take advantage of its authentication.
由于IPsec安装在IP层，因此它对网络代码具有相当大的侵入性。实现它通常需要新的硬件或新的协议栈。另一方面，它对应用程序相当透明。在IPsec上运行的应用程序可以在根本不更改其协议的情况下提高安全性。但至少在IPsec得到更广泛的部署之前，大多数应用程序都不应该认为它们是在IPsec上运行的，而不是指定自己的安全机制。大多数现代操作系统都有IPsec；大多数路由器不这样做，至少对于控制路径是这样。使用TLS的应用程序更有可能断言特定于应用程序的内容，以利用其身份验证。
The key management for IPsec can use either certificates or shared secrets. For all the obvious reasons, certificates are preferred; however, they may present more of a headache for the system manager.
IPsec的密钥管理可以使用证书或共享机密。由于所有明显的原因，优先考虑证书；但是，它们可能会给系统管理员带来更大的麻烦。
There is strong potential for conflict between IPsec and NAT [RFC2993]. NAT does not easily coexist with any protocol containing embedded IP address; with IPsec, every packet, for every protocol, contains such addresses, if only in the headers. The conflict can sometimes be avoided by using tunnel mode, but that is not always an appropriate choice for other reasons. There is ongoing work to make IPsec pass through NAT more easily [NATIKE].
IPsec和NAT之间存在很大的冲突可能性[RFC2993]。NAT不容易与任何包含嵌入式IP地址的协议共存；对于IPsec，每个协议的每个数据包都包含这样的地址，即使只是在头中。使用隧道模式有时可以避免冲突，但由于其他原因，这并不总是一个合适的选择。目前正在进行的工作是使IPsec更容易通过NAT[NATIKE]。
Most current IPsec usage is for virtual private networks. Assuming that the other constraints are met, IPsec is the security protocol of choice for VPN-like situations, including the remote access scenario where a single machine tunnels back into its home network over the internet using IPsec.
当前大多数IPsec使用都是针对虚拟专用网络的。假设满足其他约束条件，IPsec是类似VPN的情况下选择的安全协议，包括远程访问场景，其中一台机器使用IPsec通过internet隧道返回其家庭网络。
TLS [RFC2246] provides an encrypted, authenticated channel that runs on top of TCP. While TLS was originally designed for use by Web browsers, it is by no means restricted to such. In general, though, each application that wishes to use TLS will need to be converted individually.
TLS[RFC2246]提供了一个在TCP之上运行的加密、经过身份验证的通道。虽然TLS最初是为Web浏览器设计的，但它绝不限于此。不过，一般来说，希望使用TLS的每个应用程序都需要单独转换。
Generally, the server side is always authenticated by a certificate. Clients may possess certificates, too, providing mutual authentication, though this is rarely deployed. It's an unfortunate reality that even server side authentication it not as secure in practice as the cryptography would imply because most implementations allow users to ignore authentication failures (by clicking OK to a warning) and most users routinely do so [Bell98]. Designers should thus be wary of demanding plaintext passwords, even over TLS-protected connections. (This requirement can be relaxed if it is likely that implementations will be able to verify the authenticity and authorization of the server's certificate.)
通常，服务器端总是通过证书进行身份验证。客户机也可能拥有证书，以提供相互身份验证，尽管这很少部署。不幸的是，即使是服务器端身份验证在实践中也不如加密技术所暗示的那样安全，因为大多数实现允许用户忽略身份验证失败（通过单击“确定”以发出警告），而大多数用户通常都会这样做[Bell98]。因此，设计者应该警惕要求明文密码，即使是通过TLS保护的连接。（如果实现可能能够验证服务器证书的真实性和授权，则可以放宽此要求。）
Although application modification is generally required to make use of TLS, there exist toolkits, both free and commercial, that provide implementations. These are designed to be incorporated into the application's code. An application using TLS is more likely to be able to assert application specific certificate policies than one using IPsec.
尽管使用TLS通常需要修改应用程序，但存在提供实现的免费和商用工具包。这些代码被设计为包含在应用程序的代码中。使用TLS的应用程序比使用IPsec的应用程序更有可能断言特定于应用程序的证书策略。
SASL [RFC2222] is a framework for negotiating an authentication and encryption mechanism to be used over a TCP stream. As such, its security properties are those of the negotiated mechanism. Specifically, unless the negotiated mechanism authenticates all of the subsequent messages or underlying protection protocol such as TLS is used, TCP connections are vulnerable to session stealing.
SASL[RFC2222]是一个用于协商TCP流上使用的身份验证和加密机制的框架。因此，其安全属性是协商机制的安全属性。具体地说，除非协商机制验证所有后续消息或使用底层保护协议（如TLS），否则TCP连接容易被会话窃取。
If you need to use TLS (or IPSec) under SASL, why bother with SASL in the first place? Why not simply use the authentication facilities of TLS and be done with it?
如果您需要在SASL下使用TLS（或IPSec），那么为什么要首先使用SASL呢？为什么不简单地使用TLS的身份验证功能并使用它呢？
The answer here is subtle. TLS makes extensive use of certificates for authentication. As commonly deployed, only servers have certificates, whereas clients go unauthenticated (at least by the TLS processing itself).
这里的答案很微妙。TLS广泛使用证书进行身份验证。通常情况下，只有服务器具有证书，而客户端未经身份验证（至少由TLS处理本身）。
SASL permits the use of more traditional client authentication technologies, such as passwords (one-time or otherwise). A powerful combination is TLS for underlying protection and authentication of the server, and a SASL-based system for authenticating clients. Care must be taken to avoid man-in-the-middle vulnerabilities when different authentication techniques are used in different directions.
SASL允许使用更传统的客户端身份验证技术，如密码（一次性或其他）。一个强大的组合是用于服务器底层保护和身份验证的TLS，以及用于客户端身份验证的基于SASL的系统。当在不同方向使用不同的身份验证技术时，必须小心避免中间人漏洞。
GSS-API [RFC2744] provides a framework for applications to use when they require authentication, integrity, and/or confidentiality. Unlike SASL, GSS-API can be used easily with UDP-based applications. It provides for the creation of opaque authentication tokens (aka chunks of memory) which may be embedded in a protocol's data units. Note that the security of GSS-API-protected protocols depends on the underlying security mechanism; this must be evaluated independently. Similar considerations apply to interoperability, of course.
GSS-API[RFC2744]为需要身份验证、完整性和/或机密性的应用程序提供了一个框架。与SASL不同，GSS-API可以轻松地用于基于UDP的应用程序。它提供了创建不透明身份验证令牌（也称为内存块）的功能，这些令牌可以嵌入到协议的数据单元中。注意，GSS API保护协议的安全性取决于底层安全机制；这必须独立评估。当然，类似的考虑也适用于互操作性。
DNSSEC [RFC2535] digitally signs DNS records. It is an essential tool for protecting against DNS cache contamination attacks [Bell95]; these in turn can be used to defeat name-based authentication and to redirect traffic to or past an attacker. The latter makes DNSSEC an essential component of some other security mechanisms, notably IPsec.
DNSSEC[RFC2535]对DNS记录进行数字签名。它是防止DNS缓存污染攻击的重要工具[Bell95]；这些反过来又可用于挫败基于名称的身份验证，并将流量重定向到或绕过攻击者。后者使DNSSEC成为其他一些安全机制（尤其是IPsec）的重要组成部分。
Although not widely deployed on the Internet at the time of the writing of this document, it offers the potential to provide a secure mechanism for mapping domain names to IP protocol addresses. It may also be used to securely associate other information with a DNS name.
尽管在编写本文档时，它还没有广泛部署在Internet上，但它提供了一种将域名映射到IP协议地址的安全机制。它还可用于安全地将其他信息与DNS名称关联。
This information may be as simple as a service that is supported on a given node, or a key to be used with IPsec for negotiating a secure session. Note that the concept of storing general purpose application keys in the DNS has been deprecated [RFC3445], but standardization of storing keys for particular applications - in particular IPsec - is proceeding.
此信息可以是给定节点上支持的服务，也可以是IPsec用于协商安全会话的密钥。请注意，在DNS中存储通用应用程序密钥的概念已被弃用[RFC3445]，但存储特定应用程序（特别是IPsec）密钥的标准化正在进行。
Security/Multiparts [RFC1847] are the preferred mechanism for protecting email. More precisely, it is the MIME framework within which encryption and/or digital signatures are embedded. Both S/MIME and OpenPGP (see below) use Security/Multipart for their encoding. Conforming mail readers can easily recognize and process the cryptographic portions of the mail.
安全/多部分[RFC1847]是保护电子邮件的首选机制。更准确地说，它是一个MIME框架，其中嵌入了加密和/或数字签名。S/MIME和OpenPGP（见下文）都使用安全性/多部分编码。一致性邮件阅读器可以轻松识别和处理邮件的加密部分。
Security/Multiparts represents one form of "object security", where the object of interest to the end user is protected, independent of transport mechanism, intermediate storage, etc. Currently, there is no general form of object protection available in the Internet.
安全性/多部分表示一种形式的“对象安全性”，终端用户感兴趣的对象受到保护，独立于传输机制、中间存储等。目前，互联网上没有通用的对象保护形式。
For a good example of using S/MIME outside the context of email, see Session Initiation Protocol [RFC 3261].
有关在电子邮件上下文之外使用S/MIME的示例，请参阅会话启动协议[RFC3261]。
One of the strongest forms of challenge/response authentication is based on digital signatures. Using public key cryptography is preferable to schemes based on secret key ciphers because no server needs a copy of the client's secret. Rather, the client has a private key; servers have the corresponding public key.
质询/响应身份验证的最强大形式之一是基于数字签名。使用公钥密码比基于密钥密码的方案更可取，因为没有服务器需要客户端密码的副本。相反，客户机具有私钥；服务器具有相应的公钥。
Using digital signatures properly is tricky. A client should never sign the exact challenge sent to it, since there are several subtle number-theoretic attacks that can be launched in such situations.
正确使用数字签名是很棘手的。客户端永远不应该对发送给它的确切挑战进行签名，因为在这种情况下可能会发起一些微妙的数论攻击。
The Digital Signature Standard [DSS] and RSA [RSA] are both good choices; each has its advantages. Signing with DSA requires the use of good random numbers [RFC1750]. If the enemy can recover the random number used for any given signature, or if you use the same random number for two different documents, your private key can be recovered. DSS has much better performance than RSA for generating new private keys, and somewhat better performance generating signatures, while RSA has much better performance for verifying signatures.
数字签名标准[DSS]和RSA[RSA]都是不错的选择；各有所长。使用DSA签名需要使用良好的随机数[RFC1750]。如果敌人可以恢复用于任何给定签名的随机数，或者如果您对两个不同的文档使用相同的随机数，则可以恢复您的私钥。DSS在生成新私钥方面比RSA有更好的性能，在生成签名方面也有更好的性能，而RSA在验证签名方面有更好的性能。
Digital signatures can be used to build "object security" applications which can be used to protect data in store and forward protocols such as electronic mail.
数字签名可用于构建“对象安全”应用程序，该应用程序可用于保护存储和转发协议（如电子邮件）中的数据。
At this writing, two different secure mail protocols, OpenPGP [OpenPGP] and S/MIME [S/MIME], have been proposed to replace PEM [PEM]. It is not clear which, if either, will succeed. While specified for use with secure mail, both can be adapted to protect data carried by other protocols. Both use certificates to identify users; both can provide secrecy and authentication of mail messages; however, the certificate formats are very different. Historically, the difference between PGP-based mail and S/MIME-based mail has been the style of certificate chaining. In S/MIME, users possess X.509 certificates; the certification graph is a tree with a very small number of roots. By contrast, PGP uses the so-called "web of trust", where any user can sign anyone else's certificate. This certification graph is really an arbitrary graph or set of graphs.
在本文中，提出了两种不同的安全邮件协议，OpenPGP[OpenPGP]和S/MIME[S/MIME]，以取代PEM[PEM]。目前尚不清楚哪一个会成功。虽然指定与secure mail一起使用，但两者都可以适用于保护其他协议所承载的数据。两者都使用证书来识别用户；两者都可以提供邮件消息的保密性和身份验证；但是，证书格式非常不同。从历史上看，基于PGP的邮件和基于S/MIME的邮件之间的区别在于证书链接的样式。在S/MIME中，用户拥有X.509证书；认证图是一棵根数非常少的树。相比之下，PGP使用所谓的“信任网”，任何用户都可以签署其他任何人的证书。这个认证图实际上是一个任意图或一组图。
With any certificate scheme, trust depends on two primary characteristics. First, it must start from a known-reliable source, either an X.509 root, or someone highly trusted by the verifier, often him or herself. Second, the chain of signatures must be reliable. That is, each node in the certification graph is crucial; if it is dishonest or has been compromised, any certificates it has vouched for cannot be trusted. All other factors being equal (and they rarely are), shorter chains are preferable.
对于任何证书方案，信任都取决于两个主要特征。首先，它必须从已知的可靠来源开始，要么是X.509根，要么是验证者高度信任的人，通常是验证者本人。其次，签名链必须可靠。也就是说，认证图中的每个节点都至关重要；如果它不诚实或已被泄露，则它所担保的任何证书都不可信。在所有其他因素相同的情况下（而且很少如此），较短的链更可取。
Some of the differences reflect a tension between two philosophical positions represented by these technologies. Others resulted from having separate design teams.
一些差异反映了这些技术所代表的两种哲学立场之间的紧张关系。另一些则是由于拥有独立的设计团队。
S/MIME is designed to be "fool proof". That is, very little end-user configuration is required. Specifically, end-users do not need to be aware of trust relationships, etc. The idea is that if an S/MIME client says, "This signature is valid", the user should be able to "trust" that statement at face value without needing to understand the underlying implications.
S/MIME被设计成“傻瓜式”。也就是说，只需要很少的最终用户配置。具体而言，最终用户不需要知道信任关系等。其想法是，如果S/MIME客户机说“此签名有效”，则用户应该能够“信任”该声明的表面价值，而无需了解其潜在含义。
To achieve this, S/MIME is typically based on a limited number of "root" Certifying Authorities (CAs). The goal is to build a global trusted certificate infrastructure.
为了实现这一点，S/MIME通常基于数量有限的“根”认证机构（CA）。目标是构建一个全局可信证书基础架构。
The down side to this approach is that it requires a deployed public key infrastructure before it will work. Two end-users may not be able to simply obtain S/MIME-capable software and begin communicating securely. This is not a limitation of the protocol, but a typical
这种方法的缺点是，它需要部署公钥基础设施才能工作。两个最终用户可能无法简单地获得支持S/MIME的软件并开始安全通信。这不是协议的限制，而是典型的
configuration restriction for commonly available software. One or both of them may need to obtain a certificate from a mutually trusted CA; furthermore, that CA must already be trusted by their mail handling software. This process may involve cost and legal obligations. This ultimately results in the technology being harder to deploy, particularly in an environment where end-users do not necessarily appreciate the value received for the hassle incurred.
常用软件的配置限制。其中一个或两个可能需要从相互信任的CA获取证书；此外，该CA必须已被其邮件处理软件信任。这一过程可能涉及成本和法律义务。这最终导致该技术更难部署，特别是在最终用户不一定会欣赏由此带来的麻烦所带来的价值的环境中。
The PGP "web of trust" approach has the advantage that two end-users can just obtain PGP software and immediately begin to communicate securely. No infrastructure is required and no fees and legal agreements need to be signed to proceed. As such PGP appeals to people who need to establish ad-hoc security associations.
PGP“信任网”方法的优点是，两个最终用户只需获得PGP软件，即可立即开始安全通信。无需基础设施，无需签署任何费用和法律协议即可继续进行。因此，PGP吸引了需要建立临时安全协会的人。
The down side to PGP is that it requires end-users to have an understanding of the underlying security technology in order to make effective use of it. Specifically it is fairly easy to fool a naive users to accept a "signed" message that is in fact a forgery.
PGP的缺点是，它要求最终用户了解底层安全技术，以便有效地利用它。具体来说，愚弄天真的用户接受事实上是伪造的“签名”消息是相当容易的。
To date PGP has found great acceptance between security-aware individuals who have a need for secure e-mail in an environment devoid of the necessary global infrastructure.
到目前为止，PGP已被具有安全意识的个人所接受，他们在缺乏必要的全球基础设施的环境中需要安全的电子邮件。
By contrast, S/MIME works well in a corporate setting where a secure internal CA system can be deployed. It does not require a lot of end-user security knowledge. S/MIME can be used between institutions by carefully setting up cross certification, but this is harder to do than it seems.
相比之下，S/MIME在可以部署安全的内部CA系统的公司环境中运行良好。它不需要很多最终用户安全知识。通过仔细设置交叉认证，可以在机构之间使用S/MIME，但这比看起来更难做到。
As of this writing a global certificate infrastructure continues to elude us. Questions about a suitable business model, as well as privacy considerations, may prevent one from ever emerging.
在撰写本文时，全球证书基础架构仍然无法实现。关于合适的商业模式的问题，以及隐私方面的考虑，可能会阻止这种模式的出现。
Firewalls are a topological defense mechanism. That is, they rely on a well-defined boundary between the good "inside" and the bad "outside" of some domain, with the firewall mediating the passage of information. While firewalls can be very valuable if employed properly, there are limits to their ability to protect a network.
防火墙是一种拓扑防御机制。也就是说，它们依赖于某个领域的好的“内部”和坏的“外部”之间定义明确的边界，防火墙调解信息的传递。如果使用得当，防火墙可能非常有价值，但它们保护网络的能力是有限的。
The first limitation, of course, is that firewalls cannot protect against inside attacks. While the actual incidence rate of such attacks is not known (and is probably unknowable), there is no doubt that it is substantial, and arguably constitutes a majority of security problems. More generally, given that firewalls require a well-delimited boundary, to the extent that such a boundary does not exist, firewalls do not help. Any external connections, whether they
当然，第一个限制是防火墙无法抵御内部攻击。虽然这类攻击的实际发生率尚不清楚（而且可能不知道），但毫无疑问，这是一个重大问题，可以说构成了大多数安全问题。更一般地说，考虑到防火墙需要一个分隔良好的边界，如果这样的边界不存在，那么防火墙就没有帮助。任何外部连接，无论是否
are protocols that are deliberately passed through the firewall, links that are tunneled through, unprotected wireless LANs, or direct external connections from nominally-inside hosts, weaken the protection. Firewalls tend to become less effective over time as users tunnel protocols through them and may have inadequate security on the tunnel endpoints. If the tunnels are encrypted, there is no way for the firewall to censor them. An oft-cited advantage of firewalls is that they hide the existence of internal hosts from outside eyes. Given the amount of leakage, however, the likelihood of successfully hiding machines is rather low.
故意通过防火墙的协议、通过隧道传输的链路、未受保护的无线局域网或来自名义上主机内部的直接外部连接是否会削弱保护。随着时间的推移，防火墙往往会变得不那么有效，因为用户通过防火墙传输协议，并且在隧道端点上可能没有足够的安全性。如果隧道是加密的，防火墙就无法对其进行审查。防火墙的一个经常被引用的优点是，它可以将内部主机的存在隐藏起来，不让外界看到。然而，考虑到泄漏量，成功隐藏机器的可能性相当低。
In a more subtle vein, firewalls hurt the end-to-end model of the Internet and its protocols. Indeed, not all protocols can be passed safely or easily through firewalls. Sites that rely on firewalls for security may find themselves cut off from new and useful aspects of the Internet.
更微妙的是，防火墙破坏了互联网的端到端模式及其协议。事实上，并非所有协议都能安全或轻松地通过防火墙。依靠防火墙进行安全保护的网站可能会发现自己与互联网的新的和有用的方面隔绝。
Firewalls work best when they are used as one element of a total security structure. For example, a strict firewall may be used to separate an exposed Web server from a back-end database, with the only opening the communication channel between the two. Similarly, a firewall that permitted only encrypted tunnel traffic could be used to secure a piece of a VPN. On the other hand, in that case the other end of the VPN would need to be equally secured.
当防火墙作为整体安全结构的一个元素使用时，它的工作效果最好。例如，可以使用严格的防火墙将公开的Web服务器和后端数据库分开，只打开两者之间的通信通道。类似地，只允许加密隧道流量的防火墙可用于保护VPN的一部分。另一方面，在这种情况下，VPN的另一端需要同样安全。
Kerberos [RFC1510] provides a mechanism for two entities to authenticate each other and exchange keying material. On the client side, an application obtains a Kerberos "ticket" and "authenticator". These items, which should be considered opaque data, are then communicated from client to server. The server can then verify their authenticity. Both sides may then ask the Kerberos software to provide them with a session key which can be used to protect or encrypt data.
Kerberos[RFC1510]为两个实体提供了一种相互验证和交换密钥材料的机制。在客户端，应用程序获得Kerberos“票证”和“验证器”。这些项目应被视为不透明数据，然后从客户端传输到服务器。然后服务器可以验证它们的真实性。然后，双方可能会要求Kerberos软件向他们提供会话密钥，该密钥可用于保护或加密数据。
Kerberos may be used by itself in a protocol. However, it is also available as a mechanism under SASL and GSSAPI. It has some known vulnerabilities [KRBATTACK] [KRBLIM] [KRB4WEAK], but it can be used securely.
Kerberos可以在协议中单独使用。但是，它也可以作为SASL和GSSAPI下的机制使用。它有一些已知的漏洞[KRBATTACK][KRBLIM][KRB4WEAK]，但可以安全使用。
SSH provides a secure connection between client and server. It operates very much like TLS; however, it is optimized as a protocol for remote connections on terminal-like devices. One of its more innovative features is its support for "tunneling" other protocols over the SSH-protected TCP connection. This feature has permitted
SSH提供了客户端和服务器之间的安全连接。它的运行非常像TLS；然而，它被优化为终端设备上远程连接的协议。它的一个更具创新性的特性是支持通过SSH保护的TCP连接“隧道”其他协议。此功能允许
knowledgeable security people to perform such actions as reading and sending e-mail or news via insecure servers over an insecure network. It is not a substitute for a true VPN, but it can often be used in place of one.
知识渊博的安全人员可以在不安全的网络上通过不安全的服务器执行阅读和发送电子邮件或新闻等操作。它不是真正的VPN的替代品，但它通常可以用来代替VPN。
Some common security mechanisms are part of the problem rather than part of the solution.
一些常见的安全机制是问题的一部分，而不是解决方案的一部分。
Plaintext passwords are the most common security mechanism in use today. Unfortunately, they are also the weakest. When not protected by an encryption layer, they are completely unacceptable. Even when used with encryption, plaintext passwords are quite weak, since they must be transmitted to the remote system. If that system has been compromised or if the encryption layer does not include effective authentication of the server to the client, an enemy can collect the passwords and possibly use them against other targets.
明文密码是当今最常用的安全机制。不幸的是，它们也是最弱的。当不受加密层保护时，它们是完全不可接受的。即使与加密一起使用，明文密码也相当脆弱，因为它们必须传输到远程系统。如果该系统已被破坏，或者如果加密层不包括服务器对客户端的有效身份验证，则敌人可以收集密码，并可能对其他目标使用密码。
Another weakness arises because of common implementation techniques. It is considered good form [MT79] for the host to store a one-way hash of the users' passwords, rather than their plaintext form. However, that may preclude migrating to stronger authentication mechanisms, such as HMAC-based challenge/response.
另一个弱点是由于常见的实现技术。主机存储用户密码的单向散列（而不是明文形式）被认为是很好的形式[MT79]。然而，这可能会妨碍迁移到更强的身份验证机制，例如基于HMAC的质询/响应。
The strongest attack against passwords, other than eavesdropping, is password-guessing. With a suitable program and dictionary (and these are widely available), 20-30% of passwords can be guessed in most environments [Klein90].
除窃听外，针对密码的最强攻击是密码猜测。有了合适的程序和字典（这些都是广泛可用的），在大多数环境中20-30%的密码都可以猜到[Klein90]。
Another common security mechanism is address-based authentication. At best, it can work in highly constrained environments. If your environment consists of a small number of machines, all tightly administered, secure systems run by trusted users, and if the network is guarded by a router that blocks source-routing and prevents spoofing of your source addresses, and you know there are no wireless bridges, and if you restrict address-based authentication to machines on that network, you are probably safe. But these conditions are rarely met.
另一种常见的安全机制是基于地址的身份验证。充其量，它可以在高度受限的环境中工作。如果您的环境由少量计算机组成，所有计算机都由受信任的用户严格管理、安全的系统运行，如果网络由路由器保护，路由器会阻止源路由并防止对源地址的欺骗，并且您知道没有无线网桥，如果您将基于地址的身份验证限制在该网络上的计算机上，则可能是安全的。但这些条件很少得到满足。
Among the threats are ARP-spoofing, abuse of local proxies, renumbering, routing table corruption or attacks, DHCP, IP address spoofing (a particular risk for UDP-based protocols), sequence number guessing, and source-routed packets. All of these can be quite potent.
这些威胁包括ARP欺骗、滥用本地代理、重新编号、路由表损坏或攻击、DHCP、IP地址欺骗（基于UDP协议的特定风险）、序列号猜测和源路由数据包。所有这些都是非常有效的。
Name-based authentication has all of the problems of address-based authentication and adds new ones: attacks on the DNS [Bell95] and lack of a one to one mapping between addresses and names. At a minimum, a process that retrieves a host name from the DNS should retrieve the corresponding address records and cross-check. Techniques such as DNS cache contamination can often negate such checks.
基于名称的身份验证具有基于地址的身份验证的所有问题，并添加了新的问题：对DNS的攻击[Bell95]，以及地址和名称之间缺乏一对一的映射。从DNS检索主机名的进程至少应检索相应的地址记录并进行交叉检查。诸如DNS缓存污染之类的技术通常会否定此类检查。
DNSSEC provides protection against this sort of attack. However, it does nothing to enhance the reliability of the underlying address. Further, the technique generates a lot of false alarms. These lookups do not provide reliable information to a machine, though they might be a useful debugging tool for humans and could be useful in logs when trying to reconstruct how and attack took place.
DNSSEC提供了针对此类攻击的保护。然而，它并不能提高底层地址的可靠性。此外，该技术会产生大量假警报。这些查找并不能为机器提供可靠的信息，尽管它们可能是一种有用的调试工具，并且在试图重建攻击发生的方式时，在日志中可能很有用。
No security mechanisms are perfect. If nothing else, any network-based security mechanism can be thwarted by compromise of the endpoints. That said, each of the mechanisms described here has its own limitations. Any decision to adopt a given mechanism should weigh all of the possible failure modes. These in turn should be weighed against the risks to the endpoint of a security failure.
没有一种安全机制是完美的。若并没有其他原因的话，任何基于网络的安全机制都可能因为端点的泄露而受阻。也就是说，这里描述的每种机制都有其自身的局限性。采用给定机制的任何决定都应权衡所有可能的故障模式。反过来，应根据安全故障对端点的风险进行权衡。
There are no IANA considerations regarding this document.
关于本文件，没有IANA考虑事项。
Brian Carpenter, Tony Hain, and Marcus Leech made a number of useful suggestions. Much of the substance comes from the participants in the IAB Security Architecture Workshop.
Brian Carpenter、Tony Hain和Marcus Leech提出了许多有用的建议。大部分内容来自IAB安全架构研讨会的参与者。
[Bell95] "Using the Domain Name System for System Break-Ins". Proc. Fifth Usenix Security Conference, 1995.
[Bell95]“使用域名系统进行系统入侵”。过程。第五届Usenix安全会议，1995年。
[Bell98] "Cryptography and the Internet", S.M. Bellovin, in Proceedings of CRYPTO '98, August 1998.
[Bell98]“密码学与互联网”，S.M.Bellovin，1998年8月出版的《1998年密码学会议录》。
[DSS] "Digital Signature Standard". NIST. May 1994. FIPS 186.
[DSS]“数字签名标准”。NIST。1994年5月。FIPS 186。
[Klein90] "Foiling the Cracker: A Survey of, and Implications to, Password Security". D. Klein. Usenix UNIX Security Workshop, August 1990.
[Klein90]“挫败黑客：密码安全调查及其影响”。克莱因。Usenix UNIX安全研讨会，1990年8月。
[KRBATTACK] "A Real-World Analysis of Kerberos Password Security". T. Wu. Network and Distributed System Security Symposium (NDSS '99). January 1999.
[KRBATTACK]“Kerberos密码安全性的真实分析”。吴先生。网络和分布式系统安全研讨会（NDSS'99）。1999年1月。
[KRBLIM] "Limitations of the Kerberos Authentication System". Proceedings of the 1991 Winter USENIX Conference, 1991.
[KRBLIM]“Kerberos身份验证系统的限制”。1991年冬季USENIX会议记录，1991年。
[KRB4WEAK] "Misplaced trust: Kerberos 4 session keys". Proceedings of the Internet Society Network and Distributed Systems Security Symposium, March 1997.
[KRB4WEAK]“错位信任：Kerberos 4会话密钥”。互联网协会网络和分布式系统安全研讨会论文集，1997年3月。
[MT79] "UNIX Password Security", R.H. Morris and K. Thompson, Communications of the ACM. November 1979.
[MT79]“UNIX密码安全”，R.H.Morris和K.Thompson，ACM通信部。1979年11月。
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Work in Progress, June 2002.
[NATIKE]Kivinen，T.等人，“IKE中NAT穿越的协商”，正在进行的工作，2002年6月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847]Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[RFC2289]Haller，N.，Metz，C.，Nesser，P.和M.Straw，“一次性密码系统”，STD 61，RFC 2289，1998年2月。
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC2316]Bellovin，S.，“IAB安全架构研讨会报告”，RFC 2316，1998年4月。
[RFC2385] Hefferman, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Hefferman，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]Thayer，R.，Doraswamy，N.和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-bindings", RFC 2744, January 2000.
[RFC2744]Wray，J.，“通用安全服务API第2版：C-绑定”，RFC 2744，2000年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, R., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，R.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]Massey，D.和S.Rose，“限制关键资源记录（RR）的范围”，RFC 34452002年12月。
[RSA] Rivest, R., Shamir, A. and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, February 1978.
[RSA]Rivest，R.，Shamir，A.和L.Adleman，“获取数字签名和公钥密码系统的方法”，ACM通信，1978年2月。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
This document is a publication of the Internet Architecture Board. Internet Architecture Board Members at the time this document was completed were:
本文件是互联网体系结构委员会的出版物。本文件完成时，互联网体系结构委员会成员为：
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle, Chair Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Michael StJohns
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle，主席Patrik Faltstrom Sally Floyd Jun ichiro Itojun Hagino Mark Handley Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Michael StJohns
Internet Architecture Board EMail: iab@iab.org
互联网架构委员会电子邮件：iab@iab.org
Steven M. Bellovin, Editor EMail: bellovin@acm.org
Steven M.Bellovin，编辑电子邮件：bellovin@acm.org
Jeffrey I. Schiller, Editor EMail: jis@mit.edu
Jeffrey I.Schiller，编辑电子邮件：jis@mit.edu
Charlie Kaufman, Editor EMail: charliek@microsoft.com
Charlie Kaufman，编辑电子邮件：charliek@microsoft.com
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。