Network Working Group K. Ono
Request for Comments: 4189 S. Tachimoto
Category: Informational NTT Corporation
October 2005
Network Working Group K. Ono
Request for Comments: 4189 S. Tachimoto
Category: Informational NTT Corporation
October 2005
Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的端到端安全要求
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security.
会话初始化协议（SIP）用户代理（UA）并不总是信任其请求路径中的所有中介来检查其消息体和/或其消息中包含的头。UA可能希望保护消息体和/或消息头不受中介的影响，但基于其内容提供服务的中介除外。这种情况需要一种称为“端到端安全性”的机制来保护UA和中介之间传递的信息，这不会干扰端到端安全性。本文档定义了实现端到端安全机制的一组要求。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Use Cases .......................................................2
2.1. Examples of Scenarios ......................................2
2.2. Service Examples ...........................................4
3. Scope of End-to-Middle Security .................................6
4. Requirements for a Solution .....................................6
4.1. General Requirements .......................................6
4.2. Requirements for End-to-Middle Confidentiality .............7
4.3. Requirements for End-to-Middle Integrity ...................7
5. Security Considerations .........................................8
6. Acknowledgments .................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Use Cases .......................................................2
2.1. Examples of Scenarios ......................................2
2.2. Service Examples ...........................................4
3. Scope of End-to-Middle Security .................................6
4. Requirements for a Solution .....................................6
4.1. General Requirements .......................................6
4.2. Requirements for End-to-Middle Confidentiality .............7
4.3. Requirements for End-to-Middle Integrity ...................7
5. Security Considerations .........................................8
6. Acknowledgments .................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
The Session Initiation Protocol (SIP) [2] supports hop-by-hop security using Transport Layer Security (TLS) [3] and end-to-end security using Secure MIME (S/MIME) [4]. Use of TLS assumes that a SIP UA trusts all proxy servers along its request path to inspect the message bodies contained in the message, and use of S/MIME assumes that a SIP UA does not trust any proxy servers to do so.
会话启动协议（SIP）[2]支持使用传输层安全性（TLS）[3]的逐跳安全性和使用安全MIME（S/MIME）[4]的端到端安全性。TLS的使用假设SIP UA信任其请求路径上的所有代理服务器来检查消息中包含的消息体，而S/MIME的使用假设SIP UA不信任任何代理服务器来检查消息体。
However, there is a model in which trusted and partially-trusted proxy servers are mixed along a message path. The partially-trusted proxy servers are only trusted to provide SIP routing, but these proxy servers are not trusted by users to inspect its data, except the routing headers. A hop-by-hop confidentiality service using TLS is not suitable for this model. An end-to-end confidentiality service using S/MIME is also not suitable when the intermediaries provide services based on reading the message bodies and/or headers. This problem is described in Section 23 of [2].
但是，有一种模型，其中受信任和部分受信任的代理服务器沿消息路径混合。仅信任部分受信任的代理服务器提供SIP路由，但用户不信任这些代理服务器来检查其数据，路由头除外。使用TLS的逐跳保密服务不适用于此模型。当中介机构基于读取消息体和/或消息头提供服务时，使用S/MIME的端到端保密服务也不适用。[2]第23节描述了该问题。
In some cases, a UA might want to protect its message bodies and/or headers from proxy servers along its request path, except from those that provide services based on reading its message bodies and/or headers. Conversely, a proxy server might want to view the message bodies and/or headers to sufficiently provide these services. Such proxy servers are not always the first hop from the UA. This situation requires a security mechanism to secure message bodies and/or headers between the UA and the proxy servers, while disclosing information to those that need it. We call this "end-to-middle security".
在某些情况下，UA可能希望保护其消息体和/或消息头不受其请求路径上的代理服务器的影响，但不受基于读取其消息体和/或消息头而提供服务的代理服务器的影响。相反，代理服务器可能希望查看消息体和/或消息头以充分提供这些服务。这样的代理服务器并不总是UA的第一跳。这种情况需要一种安全机制来保护UA和代理服务器之间的消息体和/或消息头，同时向需要的人披露信息。我们称之为“中间安全结束”。
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 RFC-2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-2119[1]中所述进行解释。
We describe here examples of scenarios in which trusted and partially-trusted proxy servers both exist in a message path. These situations demonstrate the reasons why end-to-middle security is required.
我们在这里描述了受信任和部分受信任的代理服务器都存在于消息路径中的场景示例。这些情况说明了为什么需要端到端安全性。
In the following example, User #1 does not know the security policies or services provided by Proxy server #1 (Proxy#1). User #1 sends a MESSAGE [5] request including S/MIME-encrypted message content for end-to-end security, as shown in Figure 1, while Proxy #1 rejects the request based on its strict security policy that prohibits the forwarding of unknown data.
在以下示例中，用户#1不知道代理服务器#1（代理#1）提供的安全策略或服务。用户#1发送消息[5]请求，包括S/MIME加密消息内容，以实现端到端的安全性，如图1所示，而代理#1基于其严格的安全策略拒绝该请求，该策略禁止转发未知数据。
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| [C] |-----| [C] |-----| C |-----User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| [C] |-----| [C] |-----| C |-----User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
C: Content that UA #1 allows the entity to inspect
[C]: Content that UA #1 prevents the entity from inspecting
C: Content that UA #1 allows the entity to inspect
[C]: Content that UA #1 prevents the entity from inspecting
Figure 1: Deployment example #1
图1：部署示例#1
In the second example, Proxy server #1 is the home proxy server of User #1 using UA #1. User #1 communicates with User #2 through Proxy #1 and Proxy #2, as shown in Figure 2. Although User #1 already knows Proxy #1's security policy, which requires the inspection of the content of the MESSAGE request, User #1 does not know whether Proxy #2 is trustworthy, and thus wants to protect the message bodies in the request. To accomplish this, UA #1 will need to be able to grant a trusted intermediary (Proxy #1) to inspect message bodies, while preserving their confidentiality from other intermediaries (Proxy #2).
在第二个示例中，代理服务器#1是使用UA#1的用户#1的主代理服务器。用户#1通过代理#1和代理#2与用户#2通信，如图2所示。虽然用户#1已经知道代理#1的安全策略，该策略要求检查消息请求的内容，但用户#1不知道代理#2是否可信，因此希望保护请求中的消息主体。为了实现这一点，UA#1需要能够授权受信任的中介（代理#1）来检查消息体，同时保护它们对其他中介（代理#2）的机密性。
Even if UA #1's request message authorizes Proxy #1 to inspect the message bodies, UA #1 is unable to authorize the same proxy server to inspect the message bodies in subsequent MESSAGE requests from UA #2.
即使UA#1的请求消息授权代理#1检查消息体，UA#1也无法授权同一代理服务器检查来自UA#2的后续消息请求中的消息体。
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| C |-----| [C] |-----| C |----- User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| C |-----| [C] |-----| C |----- User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
C: Content that UA #1 needs to disclose
[C]: Content that UA #1 needs to protect
C: Content that UA #1 needs to disclose
[C]: Content that UA #1 needs to protect
Figure 2: Deployment example #2
图2：部署示例#2
In the third example, User #1 connects UA #1 to a proxy server in a visited (potentially insecure) network, e.g., a hotspot service or a roaming service. Since User #1 wants to utilize certain home network services, UA #1 connects to a home proxy server, Proxy #1. However, UA #1 must connect to Proxy #1 via the proxy server of the visited network (Proxy A), because User #1 must follow the policy of that network. Proxy A performs access control based on the destination addresses of calls. User #1 only trusts Proxy A to route requests, not to inspect the message bodies the requests contain, as shown in Figure 3. User #1 trusts Proxy #1 both to route the requests and to inspect the message bodies.
在第三个示例中，用户1将UA 1连接到访问（可能不安全）网络中的代理服务器，例如热点服务或漫游服务。由于用户1想要利用某些家庭网络服务，UA 1连接到家庭代理服务器proxy 1。但是，UA#1必须通过访问网络的代理服务器（代理A）连接到代理#1，因为用户#1必须遵守该网络的策略。代理A根据呼叫的目标地址执行访问控制。用户#1只信任代理A路由请求，而不检查请求包含的消息体，如图3所示。用户#1信任代理#1来路由请求和检查消息体。
The same problems as in the second example also exist here.
这里也存在与第二个示例相同的问题。
Visited network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+ +-----+
User #1 -- | | C |-----| [C] |-----| C |-----| [C] |-----| C |
| +-----+ +-----+ | +-----+ +-----+ +-----+
| UA #1 Proxy A | Proxy #1 Proxy #2 UA #2
+---------------------+
Visited network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+ +-----+
User #1 -- | | C |-----| [C] |-----| C |-----| [C] |-----| C |
| +-----+ +-----+ | +-----+ +-----+ +-----+
| UA #1 Proxy A | Proxy #1 Proxy #2 UA #2
+---------------------+
C: Content that UA #1 needs to disclose
[C]: Content that UA #1 needs to protect
C: Content that UA #1 needs to disclose
[C]: Content that UA #1 needs to protect
Figure 3: Deployment example #3
图3：部署示例#3
We describe here several services that require end-to-middle security.
我们在这里描述了几种需要端到端安全性的服务。
Logging Services are provided by the archiving function, which is located in the proxy server, that logs the message content exchanged between UAs. The archiving function could be located at the originator network and/or the destination network. When the content of an instant message contains private information, UACs (UA Clients) encrypt the content for the UASes (UA Servers). The archiving function needs to log the content in a message body in bidirectional MESSAGE requests in such a way that the data is decipherable. The archiving function also needs a way to verify the data integrity of the content before logging.
日志服务由存档功能提供，存档功能位于代理服务器中，用于记录UAs之间交换的消息内容。归档功能可以位于发起人网络和/或目标网络。当即时消息的内容包含私人信息时，UACs（UA客户端）会为UAS（UA服务器）加密内容。存档功能需要以双向消息请求的方式记录消息体中的内容，以使数据可解密。归档功能还需要一种在记录之前验证内容数据完整性的方法。
This service might be deployed in financial networks, health care service provider's networks, as well as other networks in which archiving communication is required by their security policies.
此服务可能部署在金融网络、医疗保健服务提供商的网络以及其安全策略要求存档通信的其他网络中。
The Location Object [6] includes a person's geographical location information that is privacy-sensitive. Some proxy servers will have the ability to provide routing based on the geographical location information. When UAs want to employ location-based routing in non-emergency situations, the UAs need to connect to the proxy servers with such a capability and disclose the geographical location information contained in the message body of the INVITE request, while protecting it from other proxy servers along the request path. The Location Object also needs to be verified for data integrity by the proxy servers before location-based routing is applied. Sometimes the UACs want to send the Location Object to the UASes. This is another good example that presents the need for UACs to simultaneously send secure data to a proxy server and to the UASes.
位置对象[6]包括对隐私敏感的个人地理位置信息。一些代理服务器将能够根据地理位置信息提供路由。当UAs希望在非紧急情况下采用基于位置的路由时，UAs需要连接到具有这种能力的代理服务器，并公开INVITE请求消息体中包含的地理位置信息，同时保护其不受请求路径上其他代理服务器的影响。在应用基于位置的路由之前，代理服务器还需要验证位置对象的数据完整性。有时UAC希望将位置对象发送给UAS。这是另一个很好的例子，说明UAC需要同时向代理服务器和UAS发送安全数据。
The Authenticated Identity Bodies (AIBs) [7] is a digitally-signed data that is used for identifying users. Proxy servers that need to authenticate a user, verify the signature. When the originator needs anonymity, the user identity in the AIB is encrypted before being signed. Proxy servers that authenticate the user need to decrypt the body in order to view the user identity in the AIB. Such proxy servers can be located adjacently and/or non-adjacently to the UA.
身份验证机构（AIB）[7]是用于识别用户的数字签名数据。需要验证用户身份的代理服务器，验证签名。当发起人需要匿名时，AIB中的用户身份在签名之前会被加密。验证用户身份的代理服务器需要解密主体，以便在AIB中查看用户身份。此类代理服务器可以位于UA附近和/或非附近。
The AIB could be included in all request/response messages. The proxy server needs to view it in request messages in order to authenticate users. Another proxy server sometimes needs to view it in response messages for user authentication.
AIB可以包含在所有请求/响应消息中。代理服务器需要在请求消息中查看它，以便对用户进行身份验证。另一个代理服务器有时需要在响应消息中查看它以进行用户身份验证。
User authentication data for HTTP Digest authentication [8] includes potentially private information, such as a user name. The user authentication data can be set only in a SIP header of request messages. This information needs to be transmitted securely to servers that authenticate users, located either adjacently and/or non-adjacently to the UA.
HTTP摘要身份验证[8]的用户身份验证数据包括潜在的私有信息，例如用户名。用户身份验证数据只能在请求消息的SIP头中设置。该信息需要安全地传输到认证用户的服务器，该服务器位于UA附近和/或非附近。
Firewall traversal is an example of services based on media information in a message body, such as the Session Description Protocol (SDP) [9]. A firewall entity that supports the SIP protocol, or a midcom [10] agent co-located with a proxy server,
防火墙穿越是基于消息体中的媒体信息的服务示例，例如会话描述协议（SDP）[9]。支持SIP协议的防火墙实体，或与代理服务器共存的midcom[10]代理，
controls a firewall based on the address and port information of media streams in the SDP offer/answer. The address and port information in the SDP needs to be transmitted securely to recipient UAs and the proxy server operating as a midcom agent. Therefore, there is a need for a proxy server to be able to decrypt the SDP, as well as to verify the integrity of the SDP.
根据SDP提供/应答中媒体流的地址和端口信息控制防火墙。SDP中的地址和端口信息需要安全地传输到接收方UAs和作为midcom代理运行的代理服务器。因此，代理服务器需要能够解密SDP，以及验证SDP的完整性。
When the SDP includes key parameters for Secure RTP (SRTP) [11], the key parameters need to be encrypted only for end-to-end confidentiality.
当SDP包括安全RTP（SRTP）[11]的密钥参数时，密钥参数只需加密以实现端到端的机密性。
End-to-middle security consists of user authentication, data integrity, and data confidentiality. Providing data integrity requires authenticating peer who creates the data. However, this document only describes requirements for data confidentiality and data integrity, since end-to-middle authentication is covered by existing mechanisms such as HTTP Digest authentication, S/MIME Cryptographic Message Syntax (CMS) SignedData body [12], or an AIB.
端到端安全性包括用户身份验证、数据完整性和数据机密性。提供数据完整性需要对创建数据的对等方进行身份验证。然而，本文档仅描述了数据机密性和数据完整性的要求，因为端到端身份验证由现有机制（如HTTP摘要身份验证、S/MIME加密消息语法（CMS）SignedData body[12]或AIB）涵盖。
As for data integrity, the CMS SignedData body can be used for verification of the data integrity and authentication of the signer by any entities. The CMS SignedData body can be used for end-to-middle security and end-to-end security simultaneously. However, a proxy server generally does not verify the data integrity using the CMS SignedData body, and there is no way for a UA to request the proxy server to verify the message. Therefore, some new mechanisms are needed to achieve data integrity for end-to-middle security.
至于数据完整性，CMS SignedData主体可用于验证数据完整性和任何实体对签名者的身份验证。CMS SignedData主体可同时用于端到端安全和端到端安全。但是，代理服务器通常不会使用CMS SignedData正文验证数据完整性，UA也无法请求代理服务器验证消息。因此，需要一些新的机制来实现端到端安全的数据完整性。
This document mainly discusses requirements for data confidentiality and the integrity of end-to-middle security.
本文档主要讨论数据机密性和端到端安全完整性的要求。
We describe here requirements for a solution. The requirements are mainly applied during the phase of a dialog creation or sending a MESSAGE request.
我们在这里描述解决方案的需求。这些需求主要应用于对话框创建或发送消息请求的阶段。
The following are general requirements for end-to-middle confidentiality and integrity.
以下是端到端机密性和完整性的一般要求。
REQ-GEN-1: The solution SHOULD have little impact on the way a UA handles S/MIME-secured messages.
REQ-GEN-1：该解决方案应该对UA处理S/MIME安全消息的方式影响不大。
REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do not provide services based on S/MIME-secured bodies in terms of handling the existing SIP headers.
REQ-GEN-2：对于不提供基于S/MIME安全实体的服务的代理服务器，在处理现有SIP头方面，它不应产生影响。
REQ-GEN-3: It SHOULD NOT violate the standardized mechanism of proxy servers in terms of handling message bodies.
REQ-GEN-3：在处理消息体方面，它不应违反代理服务器的标准化机制。
REQ-GEN-4: It SHOULD allow a UA to discover security policies of proxy servers. Security policies imply what data is needed to disclose and/or verify in a message.
REQ-GEN-4：它应该允许UA发现代理服务器的安全策略。安全策略意味着需要在消息中披露和/或验证哪些数据。
This requirement is necessary when the UA does not know statically which proxy servers or domains need disclosing data and/or verification.
当UA静态地不知道哪些代理服务器或域需要披露数据和/或验证时，此要求是必要的。
REQ-CONF-1: The solution MUST allow encrypted data to be shared with the recipient UA and a proxy server, when a UA wants.
REQ-CONF-1：解决方案必须允许在UA需要时与接收方UA和代理服务器共享加密数据。
REQ-CONF-2: It MUST NOT violate end-to-end encryption when the encrypted data does not need to be shared with any proxy servers.
REQ-CONF-2：当加密数据不需要与任何代理服务器共享时，它不得违反端到端加密。
REQ-CONF-3: It SHOULD allow a UA to request a proxy server to view specific message bodies. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-CONF-3：它应该允许UA请求代理服务器查看特定的消息体。请求本身应该是安全的；也就是说，应对UA进行身份验证，并验证数据完整性。
REQ-CONF-4: It MAY allow a UA to request that the recipient UA disclose information to the proxy server to which the requesting UA is initially disclosing information. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-CONF-4：它可能允许UA请求接收方UA向代理服务器披露信息，请求UA最初向代理服务器披露信息。请求本身应该是安全的；也就是说，应对UA进行身份验证，并验证数据完整性。
This requirement is necessary when a provider operating the proxy server allows its security policies to be revealed to the provider serving the recipient UA.
当操作代理服务器的提供商允许向为接收方UA提供服务的提供商披露其安全策略时，此要求是必要的。
This section enumerates the requirements for the end-to-middle integrity. Verifying the data integrity requires checking that the data is created by the authenticated user and not forged by a malicious user. Therefore, verification of the data integrity requires the user authentication.
本节列举了端到中间完整性的要求。验证数据完整性需要检查数据是否由经过身份验证的用户创建，而不是由恶意用户伪造。因此，验证数据完整性需要用户身份验证。
REQ-INT-1: The solution SHOULD work even when the SIP end-to-end authentication and integrity services are enabled.
REQ-INT-1：即使启用了SIP端到端身份验证和完整性服务，该解决方案也应该可以工作。
REQ-INT-2: It SHOULD allow a UA to request a proxy server to verify specific message bodies and authenticate the user. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-INT-2：它应该允许UA请求代理服务器验证特定的消息体并对用户进行身份验证。请求本身应该是安全的；也就是说，应对UA进行身份验证，并验证数据完整性。
REQ-INT-3: It SHOULD allow a UA to request the recipient UA to send the verification data of the same information that the requesting UA is providing to the proxy server. The request itself SHOULD be secure; namely it SHOULD be authenticated for the UA and verified for the data integrity.
REQ-INT-3：它应该允许UA请求接收方UA向代理服务器发送与请求UA提供的信息相同的验证数据。请求本身应该是安全的；也就是说，应对UA进行身份验证，并验证数据完整性。
This requirement is necessary when a provider operating the proxy server allows its security policies to be revealed to the provider serving the recipient UA.
当操作代理服务器的提供商允许向为接收方UA提供服务的提供商披露其安全策略时，此要求是必要的。
This document describes the requirements for confidentiality and integrity between a UA and a proxy server. Although this document does not cover any requirements for authentication, verifying the data integrity requires peer authentication. Also, peer authentication is important in order to prevent attacks from malicious users and servers.
本文档描述了UA和代理服务器之间的机密性和完整性要求。尽管本文档未涵盖任何身份验证要求，但验证数据完整性需要对等身份验证。此外，对等身份验证对于防止恶意用户和服务器的攻击也很重要。
The end-to-middle security requires additional processing on message bodies, such as unpacking MIME structure, data decryption, and/or signature verification to proxy servers. Therefore, the proxy servers that enable end-to-middle security are vulnerable to a Denial-of-Services attack. A threat model is where a malicious user sends many complicated-MIME-structure messages to a proxy server, containing user authentication data obtained by eavesdropping. Another threat model is where a malicious proxy server sends many complicated-MIME-structure messages to a proxy server, containing the source IP address and the Via header of an adjacent proxy server. These attacks will slow down the overall performance of target proxy servers.
端到端安全性需要对消息体进行额外的处理，例如解包MIME结构、数据解密和/或对代理服务器进行签名验证。因此，支持端到端安全的代理服务器容易受到拒绝服务攻击。威胁模型是恶意用户向代理服务器发送许多复杂的MIME结构消息，其中包含通过窃听获得的用户身份验证数据。另一种威胁模型是，恶意代理服务器向代理服务器发送许多复杂的MIME结构消息，其中包含源IP地址和相邻代理服务器的Via头。这些攻击将降低目标代理服务器的总体性能。
To prevent these attacks, user and server authentication mechanisms need to be protected against replay attacks, or the user and server authentication always need to be executed simultaneously with protection of data integrity. In order to prevent these attacks, the following requirements should be met.
为了防止这些攻击，需要保护用户和服务器身份验证机制免受重播攻击，或者用户和服务器身份验证始终需要在保护数据完整性的同时执行。为了防止这些攻击，应满足以下要求。
o The solution MUST support mutual authentication, data confidentiality, and data integrity protection between a UA and a proxy server.
o 解决方案必须支持UA和代理服务器之间的相互身份验证、数据机密性和数据完整性保护。
o It SHOULD support protection against a replay attack for user authentication.
o 它应该支持针对用户身份验证的重播攻击的保护。
o It SHOULD simultaneously support user authentication and data integrity protection.
o 它应该同时支持用户身份验证和数据完整性保护。
These last two requirements are met by HTTP Digest authentication.
HTTP摘要身份验证满足了最后两个要求。
o It MUST support mutual authentication, data confidentiality, and data integrity protection between proxy servers.
o 它必须支持代理服务器之间的相互身份验证、数据机密性和数据完整性保护。
o It SHOULD support protection against a replay attack for server authentication.
o 它应该支持针对服务器身份验证的重播攻击的保护。
o It SHOULD simultaneously support server authentication and data integrity protection.
o 它应该同时支持服务器身份验证和数据完整性保护。
These last three requirements are met by TLS.
TLS满足最后三个要求。
The authors would like to thank to Rohan Mahy and Cullen Jennings for their initial support of this concept, and to Jon Peterson, Gonzalo Camarillo, Sean Olson, Mark Baugher, Mary Barnes, and others for their reviews and constructive comments.
作者要感谢Rohan Mahy和Cullen Jennings对这一概念的初步支持，感谢Jon Peterson、Gonzalo Camarillo、Sean Olson、Mark Baugher、Mary Barnes和其他人的评论和建设性意见。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[4] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[5] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, October 2005.
[6] Peterson，J.，“基于状态的GEOPRIV定位对象格式”，RFC 4119，2005年10月。
[7] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[7] Peterson，J.，“会话发起协议（SIP）认证身份主体（AIB）格式”，RFC 3893，2004年9月。
[8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[8] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[9] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[9] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[10] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[10] Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间箱通信架构和框架”，RFC3303，2002年8月。
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[11] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[12] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[12] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
Authors' Addresses
作者地址
Kumiko Ono Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
小野久美子网络服务系统实验室NTT公司9-11，日本东京武藏町3-Chome Musashino市，180-8585
EMail: ono.kumiko@lab.ntt.co.jp, kumiko@cs.columbia.edu
EMail: ono.kumiko@lab.ntt.co.jp, kumiko@cs.columbia.edu
Shinya Tachimoto Network Service Systems Laboratories NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
日本东京武藏町3-Midori Cho 3-Chome Musashino shi NTT公司网络服务系统实验室Shinya Tachimoto Network Service Systems Laboratories NTT Corporation 9-11 180-8585
EMail: tachimoto.shinya@lab.ntt.co.jp
EMail: tachimoto.shinya@lab.ntt.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。