Network Working Group J. Arkko
Request for Comments: 3329 V. Torvinen
Category: Standards Track G. Camarillo
Ericsson
A. Niemi
T. Haukka
Nokia
January 2003
Network Working Group J. Arkko
Request for Comments: 3329 V. Torvinen
Category: Standards Track G. Camarillo
Ericsson
A. Niemi
T. Haukka
Nokia
January 2003
Security Mechanism Agreement for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的安全机制协议
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities.
本文档定义了用于协商会话发起协议（SIP）用户代理与其下一跳SIP实体之间使用的安全机制的新功能。此新功能补充了在SIP实体之间选择安全机制的现有方法。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Overview of Operation . . . . . . . . . . . . . . . . . 3
2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Protocol Operation . . . . . . . . . . . . . . . . . . . 6
2.3.1 Client Initiated . . . . . . . . . . . . . . . . . . 6
2.3.2 Server Initiated . . . . . . . . . . . . . . . . . . 8
2.4 Security Mechanism Initiation. . . . . . . . . . . . . . 9
2.5 Duration of Security Associations. . . . . . . . . . . .10
2.6 Summary of Header Field Use. . . . . . . . . . . . . . .10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Overview of Operation . . . . . . . . . . . . . . . . . 3
2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Protocol Operation . . . . . . . . . . . . . . . . . . . 6
2.3.1 Client Initiated . . . . . . . . . . . . . . . . . . 6
2.3.2 Server Initiated . . . . . . . . . . . . . . . . . . 8
2.4 Security Mechanism Initiation. . . . . . . . . . . . . . 9
2.5 Duration of Security Associations. . . . . . . . . . . .10
2.6 Summary of Header Field Use. . . . . . . . . . . . . . .10
3. Backwards Compatibility . . . . . . . . . . . . . . . . . .11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . .12
4.1 Client Initiated . . . . . . . . . . . . . . . . . . . .12
4.2 Server Initiated . . . . . . . . . . . . . . . . . . . .14
5. Security Considerations . . . . . . . . . . . . . . . . . .15
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .17
6.1 Registration Information . . . . . . . . . . . . . . . .17
6.2 Registration Template. . . . . . . . . . . . . . . . . .18
6.3 Header Field Names . . . . . . . . . . . . . . . . . . .18
6.4 Response Codes . . . . . . . . . . . . . . . . . . . . .18
6.5 Option Tags. . . . . . . . . . . . . . . . . . . . . . .19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . .19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .19
9. Normative References . . . . . . . . . . . . . . . . . . . .19
10. Informative References . . . . . . . . . . . . . . . . . . 20
A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . .21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . .24
3. Backwards Compatibility . . . . . . . . . . . . . . . . . .11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . .12
4.1 Client Initiated . . . . . . . . . . . . . . . . . . . .12
4.2 Server Initiated . . . . . . . . . . . . . . . . . . . .14
5. Security Considerations . . . . . . . . . . . . . . . . . .15
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .17
6.1 Registration Information . . . . . . . . . . . . . . . .17
6.2 Registration Template. . . . . . . . . . . . . . . . . .18
6.3 Header Field Names . . . . . . . . . . . . . . . . . . .18
6.4 Response Codes . . . . . . . . . . . . . . . . . . . . .18
6.5 Option Tags. . . . . . . . . . . . . . . . . . . . . . .19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . .19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .19
9. Normative References . . . . . . . . . . . . . . . . . . . .19
10. Informative References . . . . . . . . . . . . . . . . . . 20
A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . .21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . .24
Traditionally, security protocols have included facilities to agree on the used mechanisms, algorithms, and other security parameters. This is to add flexibility, since different mechanisms are usually suitable to different scenarios. Also, the evolution of security mechanisms often introduces new algorithms, or uncovers problems in existing ones, making negotiation of mechanisms a necessity.
传统上，安全协议包括就使用的机制、算法和其他安全参数达成一致的设施。这是为了增加灵活性，因为不同的机制通常适用于不同的场景。此外，安全机制的演变通常会引入新的算法，或揭示现有算法中的问题，这使得机制协商成为必要。
The purpose of this specification is to define negotiation functionality for the Session Initiation Protocol (SIP) [1]. This negotiation is intended to work only between a UA and its first-hop SIP entity.
本规范的目的是定义会话启动协议（SIP）[1]的协商功能。此协商旨在仅在UA与其第一跳SIP实体之间工作。
Without a secured method to choose between security mechanisms and/or their parameters, SIP is vulnerable to certain attacks. Authentication and integrity protection using multiple alternative methods and algorithms is vulnerable to Man-in-the-Middle (MitM) attacks (e.g., see [4]).
如果没有安全方法在安全机制和/或其参数之间进行选择，SIP容易受到某些攻击。使用多种替代方法和算法的身份验证和完整性保护容易受到中间人（MitM）攻击（例如，参见[4]）。
It is also hard or sometimes even impossible to know whether a specific security mechanism is truly unavailable to a SIP peer entity, or if in fact a MitM attack is in action.
要知道特定的安全机制是否真的对SIP对等实体不可用，或者事实上是否存在MitM攻击，也很难，有时甚至不可能。
In certain small networks these issues are not very relevant, as the administrators of such networks can deploy appropriate software versions and set up policies for using exactly the right type of
在某些小型网络中，这些问题不是很重要，因为此类网络的管理员可以部署适当的软件版本，并设置策略以使用正确类型的软件
security. However, SIP is also expected to be deployed to hundreds of millions of small devices with little or no possibilities for coordinated security policies, let alone software upgrades, which necessitates the need for the negotiation functionality to be available from the very beginning of deployment (e.g., see [11]).
安全然而，SIP预计也将部署到数以亿计的小型设备上，几乎没有或根本没有协调安全策略的可能性，更不用说软件升级了，这就需要从部署一开始就提供协商功能（例如，见[11]）。
1. The entities involved in the security agreement process need to find out exactly which security mechanisms to apply, preferably without excessive additional roundtrips.
1. 参与担保协议过程的实体需要准确地找出要应用哪些担保机制，最好不要有过多的额外往返。
2. The selection of security mechanisms itself needs to be secure. Traditionally, all security protocols use a secure form of negotiation. For instance, after establishing mutual keys through Diffie-Hellman, IKE sends hashes of the previously sent data including the offered crypto mechanisms [8]. This allows the peers to detect if the initial, unprotected offers were tampered with.
2. 安全机制本身的选择需要是安全的。传统上，所有安全协议都使用一种安全的协商形式。例如，在通过Diffie Hellman建立互密钥后，IKE发送先前发送的数据的散列，包括提供的加密机制[8]。这允许对等方检测初始的、未受保护的报价是否被篡改。
3. The entities involved in the security agreement process need to be able to indicate success or failure of the security agreement process.
3. 参与担保协议过程的实体需要能够表明担保协议过程的成功或失败。
4. The security agreement process should not introduce any additional state to be maintained by the involved entities.
4. 担保协议程序不应引入由相关实体维持的任何其他状态。
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 [9].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[9]中的描述进行解释。
The message flow below illustrates how the mechanism defined in this document works:
下面的消息流说明了本文档中定义的机制是如何工作的：
1. Client ----------client list---------> Server 2. Client <---------server list---------- Server 3. Client ------(turn on security)------- Server 4. Client ----------server list---------> Server 5. Client <---------ok or error---------- Server
1. 客户端----------客户端列表--------->服务器2。客户端<------服务器列表-------服务器3。客户端------（打开安全性）--服务器4。客户端----------服务器列表--------->服务器5。客户端<-----------正常或错误----------服务器
Figure 1: Security agreement message flow.
图1：安全协议消息流。
Step 1: Clients wishing to use this specification can send a list of their supported security mechanisms along the first request to the server.
步骤1：希望使用此规范的客户端可以在第一个请求中向服务器发送其支持的安全机制列表。
Step 2: Servers wishing to use this specification can challenge the client to perform the security agreement procedure. The security mechanisms and parameters supported by the server are sent along in this challenge.
步骤2：希望使用此规范的服务器可以质询客户端执行安全协议过程。服务器支持的安全机制和参数将在此挑战中发送。
Step 3: The client then proceeds to select the highest-preference security mechanism they have in common and to turn on the selected security.
步骤3：然后，客户机继续选择他们共同拥有的最高偏好安全机制，并打开所选安全机制。
Step 4: The client contacts the server again, now using the selected security mechanism. The server's list of supported security mechanisms is returned as a response to the challenge.
步骤4：客户端再次联系服务器，现在使用所选的安全机制。服务器支持的安全机制列表作为对质询的响应返回。
Step 5: The server verifies its own list of security mechanisms in order to ensure that the original list had not been modified.
步骤5：服务器验证自己的安全机制列表，以确保原始列表未被修改。
This procedure is stateless for servers (unless the used security mechanisms require the server to keep some state).
对于服务器，此过程是无状态的（除非使用的安全机制要求服务器保持某些状态）。
The client and the server lists are both static (i.e., they do not and cannot change based on the input from the other side). Nodes may, however, maintain several static lists, one for each interface, for example.
客户端和服务器列表都是静态的（即，它们不会也不能根据另一端的输入进行更改）。然而，节点可以维护多个静态列表，例如，每个接口一个。
Between Steps 1 and 2, the server may set up a non-self-describing security mechanism if necessary. Note that with this type of security mechanisms, the server is necessarily stateful. The client would set up the non-self-describing security mechanism between Steps 2 and 4.
在步骤1和步骤2之间，如果需要，服务器可以设置非自描述安全机制。注意，使用这种类型的安全机制，服务器必须是有状态的。客户端将在步骤2和步骤4之间设置非自描述安全机制。
We define three new SIP header fields, namely Security-Client, Security-Server and Security-Verify. The notation used in the Augmented BNF definitions for the syntax elements in this section is as used in SIP [1], and any elements not defined in this section are as defined in SIP and the documents to which it refers:
我们定义了三个新的SIP头字段，即安全客户端、安全服务器和安全验证。本节语法元素的扩充BNF定义中使用的符号与SIP[1]中使用的符号相同，本节中未定义的任何元素均与SIP及其引用的文件中的定义相同：
security-client = "Security-Client" HCOLON sec-mechanism *(COMMA sec-mechanism) security-server = "Security-Server" HCOLON sec-mechanism *(COMMA sec-mechanism) security-verify = "Security-Verify" HCOLON sec-mechanism *(COMMA sec-mechanism)
security client=“security client”HCOLON sec mechanism*（逗号sec mechanism）security server=“security server”HCOLON sec mechanism*（逗号sec mechanism）security verify=“security verify”HCOLON sec mechanism*（逗号sec mechanism）
sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest" / "tls" / "ipsec-ike" /
"ipsec-man" / token )
mech-parameters = ( preference / digest-algorithm /
digest-qop / digest-verify / extension )
preference = "q" EQUAL qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
digest-algorithm = "d-alg" EQUAL token
digest-qop = "d-qop" EQUAL token
digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT
extension = generic-param
sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest" / "tls" / "ipsec-ike" /
"ipsec-man" / token )
mech-parameters = ( preference / digest-algorithm /
digest-qop / digest-verify / extension )
preference = "q" EQUAL qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
digest-algorithm = "d-alg" EQUAL token
digest-qop = "d-qop" EQUAL token
digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT
extension = generic-param
Note that qvalue is already defined in the SIP BNF [1]. We have copied its definitions here for completeness.
请注意，qvalue已在SIP BNF[1]中定义。为了完整起见，我们在这里复制了它的定义。
The parameters described by the BNF above have the following semantics:
上述BNF描述的参数具有以下语义：
Mechanism-name This token identifies the security mechanism supported by the client, when it appears in a Security-Client header field; or by the server, when it appears in a Security-Server or in a Security-Verify header field. The mechanism-name tokens are registered with the IANA. This specification defines four values:
机制名称当它出现在安全客户端头字段中时，此令牌标识客户端支持的安全机制；或者，当它出现在安全服务器或安全验证标头字段中时，由服务器执行。机制名称令牌在IANA中注册。本规范定义了四个值：
* "tls" for TLS [3].
* “tls”表示tls[3]。
* "digest" for HTTP Digest [4].
* HTTP摘要的“摘要”[4]。
* "ipsec-ike" for IPsec with IKE [2].
* “ipsec ike”用于具有ike的ipsec[2]。
* "ipsec-man" for manually keyed IPsec without IKE.
* “ipsec人”用于无IKE的手动密钥ipsec。
Preference The "q" value indicates a relative preference for the particular mechanism. The higher the value the more preferred the mechanism is. All the security mechanisms MUST have different "q" values. It is an error to provide two mechanisms with the same "q" value.
偏好“q”值表示特定机构的相对偏好。值越高，机构越受欢迎。所有安全机制必须具有不同的“q”值。提供两个具有相同“q”值的机制是错误的。
Digest-algorithm This optional parameter is defined here only for HTTP Digest [4] in order to prevent the bidding-down attack for the HTTP Digest algorithm parameter. The content of the field may have same values as defined in [4] for the "algorithm" field.
Digest algorithm此可选参数在此处仅为HTTP Digest[4]定义，以防止对HTTP Digest algorithm参数的向下竞价攻击。字段的内容可能具有与[4]中为“算法”字段定义的相同值。
Digest-qop This optional parameter is defined here only for HTTP Digest [4] in order to prevent the bidding-down attack for the HTTP Digest qop parameter. The content of the field may have same values as defined in [4] for the "qop" field.
Digest qop此可选参数在此处仅为HTTP Digest[4]定义，以防止HTTP Digest qop参数的下标攻击。字段的内容可以具有与[4]中定义的“qop”字段相同的值。
Digest-verify This optional parameter is defined here only for HTTP Digest [4] in order to prevent the bidding-down attack for the SIP security mechanism agreement (this document). The content of the field is counted exactly the same way as "request-digest" in [4] except that the Security-Server header field is included in the A2 parameter. If the "qop" directive's value is "auth" or is unspecified, then A2 is:
摘要验证此处仅为HTTP摘要[4]定义此可选参数，以防止SIP安全机制协议（本文档）的竞价拒绝攻击。字段内容的计数方式与[4]中的“请求摘要”完全相同，只是安全服务器头字段包含在A2参数中。如果“qop”指令的值为“auth”或未指定，则A2为：
A2 = Method ":" digest-uri-value ":" security-server
A2 = Method ":" digest-uri-value ":" security-server
If the "qop" value is "auth-int", then A2 is:
如果“qop”值为“auth int”，则A2为：
A2 = Method ":" digest-uri-value ":" H(entity-body) ":"
security-server
A2 = Method ":" digest-uri-value ":" H(entity-body) ":"
security-server
All linear white spaces in the Security-Server header field MUST be replaced by a single SP before calculating or interpreting the digest-verify parameter. Method, digest-uri-value, entity-body, and any other HTTP Digest parameter are as specified in [4].
在计算或解释摘要验证参数之前，必须将Security Server标头字段中的所有线性空格替换为单个SP。方法、摘要uri值、实体正文和任何其他HTTP摘要参数如[4]中所述。
Note that this specification does not introduce any extension or change to HTTP Digest [4]. This specification only re-uses the existing HTTP Digest mechanisms to protect the negotiation of security mechanisms between SIP entities.
请注意，本规范没有对HTTP摘要[4]引入任何扩展或更改。本规范仅重新使用现有HTTP摘要机制来保护SIP实体之间的安全机制协商。
This section deals with the protocol details involved in the negotiation between a SIP UA and its next-hop SIP entity. Throughout the text the next-hop SIP entity is referred to as the first-hop proxy or outbound proxy. However, the reader should bear in mind that a user agent server can also be the next-hop for a user agent client.
本节讨论SIP UA与其下一跳SIP实体之间的协商中涉及的协议细节。在全文中，下一跳SIP实体称为第一跳代理或出站代理。然而，读者应该记住，用户代理服务器也可以是用户代理客户端的下一个跃点。
If a client ends up using TLS to contact the server because it has followed the rules specified in [5], the client MUST NOT use the security agreement procedure of this specification. If a client ends
如果客户端由于遵守了[5]中指定的规则而最终使用TLS与服务器联系，则客户端不得使用本规范中的安全协议过程。如果客户端结束
up using non-TLS connections because of the rules in [5], the client MAY use the security agreement of this specification to detect DNS spoofing, or to negotiate some other security than TLS.
由于[5]中的规则，在使用非TLS连接时，客户端可以使用本规范的安全协议来检测DNS欺骗，或协商TLS以外的其他安全性。
A client wishing to use the security agreement of this specification MUST add a Security-Client header field to a request addressed to its first-hop proxy (i.e., the destination of the request is the first-hop proxy). This header field contains a list of all the security mechanisms that the client supports. The client SHOULD NOT add preference parameters to this list. The client MUST add both a Require and Proxy-Require header field with the value "sec-agree" to its request.
希望使用本规范安全协议的客户机必须将安全客户机头字段添加到发送至其第一跳代理的请求中（即，请求的目的地是第一跳代理）。此标头字段包含客户端支持的所有安全机制的列表。客户端不应将首选项参数添加到此列表中。客户端必须在其请求中添加值为“sec agree”的Require和Proxy Require标头字段。
The contents of the Security-Client header field may be used by the server to include any necessary information in its response.
服务器可以使用安全客户端头字段的内容在其响应中包括任何必要的信息。
A server receiving an unprotected request that contains a Require or Proxy-Require header field with the value "sec-agree" MUST respond to the client with a 494 (Security Agreement Required) response. The server MUST add a Security-Server header field to this response listing the security mechanisms that the server supports. The server MUST add its list to the response even if there are no common security mechanisms in the client's and server's lists. The server's list MUST NOT depend on the contents of the client's list.
接收到包含值为“sec agree”的Require或Proxy Require标头字段的未受保护请求的服务器必须以494（需要安全协议）响应响应客户端。服务器必须在此响应中添加安全服务器头字段，列出服务器支持的安全机制。即使客户端和服务器的列表中没有公共安全机制，服务器也必须将其列表添加到响应中。服务器列表不能依赖于客户端列表的内容。
The server MUST compare the list received in the Security-Client header field with the list to be sent in the Security-Server header field. When the client receives this response, it will choose the common security mechanism with the highest "q" value. Therefore, the server MUST add the necessary information so that the client can initiate that mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest).
服务器必须将安全客户端标题字段中接收的列表与安全服务器标题字段中要发送的列表进行比较。当客户端收到此响应时，它将选择具有最高“q”值的公共安全机制。因此，服务器必须添加必要的信息，以便客户端可以启动该机制（例如，HTTP摘要的代理身份验证标头字段）。
When the client receives a response with a Security-Server header field, it MUST choose the security mechanism in the server's list with the highest "q" value among all the mechanisms that are known to the client. Then, it MUST initiate that particular security mechanism as described in Section 3.5. This initiation may be carried out without involving any SIP message exchange (e.g., establishing a TLS connection).
当客户端接收到带有安全服务器头字段的响应时，它必须在服务器列表中选择客户端已知的所有机制中具有最高“q”值的安全机制。然后，它必须启动第3.5节所述的特定安全机制。可在不涉及任何SIP消息交换（例如，建立TLS连接）的情况下执行该启动。
If an attacker modified the Security-Client header field in the request, the server may not include in its response the information needed to establish the common security mechanism with the highest preference value (e.g., the Proxy-Authenticate header field is missing). A client detecting such a lack of information in the
If an attacker modified the Security-Client header field in the request, the server may not include in its response the information needed to establish the common security mechanism with the highest preference value (e.g., the Proxy-Authenticate header field is missing). A client detecting such a lack of information in thetranslate error, please retry
response MUST consider the current security agreement process aborted, and MAY try to start it again by sending a new request with a Security-Client header field as described above.
响应必须考虑当前的安全协议进程中止，并可能尝试通过再次发送一个新的请求与安全客户端头字段如上所述。
All the subsequent SIP requests sent by the client to that server SHOULD make use of the security mechanism initiated in the previous step. These requests MUST contain a Security-Verify header field that mirrors the server's list received previously in the Security-Server header field. These requests MUST also have both a Require and Proxy-Require header fields with the value "sec-agree".
客户端向该服务器发送的所有后续SIP请求都应使用在上一步中启动的安全机制。这些请求必须包含一个安全验证标头字段，该字段反映以前在安全服务器标头字段中收到的服务器列表。这些请求还必须具有值为“sec agree”的Require和Proxy Require标头字段。
The server MUST check that the security mechanisms listed in the Security-Verify header field of incoming requests correspond to its static list of supported security mechanisms.
服务器必须检查传入请求的security Verify header字段中列出的安全机制是否与其支持的安全机制的静态列表相对应。
Note that, following the standard SIP header field comparison rules defined in [1], both lists have to contain the same security mechanisms in the same order to be considered equivalent. In addition, for each particular security mechanism, its parameters in both lists need to have the same values.
注意，按照[1]中定义的标准SIP头字段比较规则，两个列表必须以相同的顺序包含相同的安全机制，才能被视为等效。此外，对于每个特定的安全机制，其在两个列表中的参数需要具有相同的值。
The server can proceed processing a particular request if, and only if, the list was not modified. If modification of the list is detected, the server MUST respond to the client with a 494 (Security Agreement Required) response. This response MUST include the server's unmodified list of supported security mechanisms. If the list was not modified, and the server is a proxy, it MUST remove the "sec-agree" value from both the Require and Proxy-Require header fields, and then remove the header fields if no values remain.
如果且仅当列表未修改时，服务器才能继续处理特定请求。如果检测到列表的修改，服务器必须用494（需要安全协议）响应客户端。此响应必须包括服务器未修改的受支持安全机制列表。如果未修改列表，并且服务器是一个代理，则必须从Require和proxy Require头字段中删除“sec agree”值，然后在没有保留值的情况下删除头字段。
Once the security has been negotiated between two SIP entities, the same SIP entities MAY use the same security when communicating with each other in different SIP roles. For example, if a UAC and its outbound proxy negotiate some security, they may try to use the same security for incoming requests (i.e., the UA will be acting as a UAS).
一旦在两个SIP实体之间协商了安全性，相同的SIP实体在以不同的SIP角色彼此通信时可以使用相同的安全性。例如，如果UAC及其出站代理协商某些安全性，它们可能会尝试对传入请求使用相同的安全性（即，UA将充当UAS）。
The user of a UA SHOULD be informed about the results of the security mechanism agreement. The user MAY decline to accept a particular security mechanism, and abort further SIP communications with the peer.
UA的用户应了解安全机制协议的结果。用户可拒绝接受特定安全机制，并中止与对等方的进一步SIP通信。
A server decides to use the security agreement described in this document based on local policy. If a server receives a request from the network interface that is configured to use this mechanism, it must check that the request has only one Via entry. If there are
服务器根据本地策略决定使用本文档中描述的安全协议。如果服务器从配置为使用此机制的网络接口接收到请求，则必须检查该请求是否只有一个Via条目。如果有
several Via entries, the server is not the first-hop SIP entity, and it MUST NOT use this mechanism. For such a request, the server must return a 502 (Bad Gateway) response.
在多个Via条目中，服务器不是第一跳SIP实体，并且不能使用此机制。对于这样的请求，服务器必须返回502（坏网关）响应。
A server that decides to use this agreement mechanism MUST challenge unprotected requests with one Via entry regardless of the presence or the absence of any Require, Proxy-Require or Supported header fields in incoming requests.
决定使用此协议机制的服务器必须使用一个Via条目质询未受保护的请求，而不管传入请求中是否存在任何Require、Proxy Require或Supported头字段。
A server that by policy requires the use of this specification and receives a request that does not have the sec-agree option tag in a Require, Proxy-Require or Supported header field MUST return a 421 (Extension Required) response. If the request had the sec-agree option tag in a Supported header field, it MUST return a 494 (Security Agreement Required) response. In both situation the server MUST also include in the response a Security-Server header field listing its capabilities and a Require header field with an option-tag "sec-agree" in it. The server MUST also add necessary information so that the client can initiate the preferred security mechanism (e.g., a Proxy-Authenticate header field for HTTP Digest).
根据策略要求使用此规范并在Require、Proxy Require或Supported标头字段中接收到没有sec agree选项标记的请求的服务器必须返回421（需要扩展名）响应。如果请求在支持的标头字段中有sec agree选项标记，则必须返回494（需要安全协议）响应。在这两种情况下，服务器还必须在响应中包含一个列出其功能的安全服务器标头字段和一个带有选项标记“sec agree”的Require标头字段。服务器还必须添加必要的信息，以便客户端可以启动首选安全机制（例如，HTTP摘要的代理身份验证标头字段）。
Clients that support the extension defined in this document SHOULD add a Supported header field with a value of "sec-agree".
支持本文档中定义的扩展的客户端应添加一个值为“sec agree”的受支持的标题字段。
Once the client chooses a security mechanism from the list received in the Security-Server header field from the server, it initiates that mechanism. Different mechanisms require different initiation procedures.
一旦客户机从服务器的security Server header字段中收到的列表中选择了安全机制，它就会启动该机制。不同的机制需要不同的启动程序。
If "tls" is chosen, the client uses the procedures of Section 8.1.2 of [1] to determine the URI to be used as an input to the DNS procedures of [5]. However, if the URI is a SIP URI, it MUST treat the scheme as if it were sips, not sip. If the URI scheme is not sip, the request MUST be sent using TLS.
如果选择了“tls”，则客户端使用[1]第8.1.2节中的程序来确定要用作[5]中DNS程序输入的URI。但是，如果URI是SIP URI，则它必须将方案视为sips，而不是SIP。如果URI方案不是sip，则必须使用TLS发送请求。
If "digest" is chosen, the 494 (Security Agreement Required) response will contain an HTTP Digest authentication challenge. The client MUST use the algorithm and qop parameters in the Security-Server header field to replace the same parameters in the HTTP Digest challenge. The client MUST also use the digest-verify parameter in the Security-Verify header field to protect the Security-Server header field as specified in 2.2.
如果选择“摘要”，494（需要安全协议）响应将包含HTTP摘要身份验证质询。客户端必须使用Security Server标头字段中的算法和qop参数来替换HTTP摘要质询中的相同参数。客户端还必须使用Security verify header字段中的digest verify参数来保护Security Server header字段，如2.2所述。
To use "ipsec-ike", the client attempts to establish an IKE connection to the host part of the Request-URI in the first request to the server. If the IKE connection attempt fails, the agreement procedure MUST be considered to have failed, and MUST be terminated.
要使用“ipsec ike”，客户机尝试在对服务器的第一个请求中建立到请求URI的主机部分的ike连接。如果IKE连接尝试失败，则协议过程必须视为失败，并且必须终止。
Note that "ipsec-man" will only work if the communicating SIP entities know which keys and other parameters to use. It is outside the scope of this specification to describe how this information can be made known to the peers. All rules for minimum implementations, such as mandatory-to-implement algorithms, apply as defined in [2], [6], and [7].
请注意，“IPSecMan”仅在通信SIP实体知道要使用哪些密钥和其他参数时才起作用。描述如何将该信息告知同行不属于本规范的范围。所有最小实现的规则（如强制实现算法）适用于[2]、[6]和[7]中的定义。
In both IPsec-based mechanisms, it is expected that appropriate policy entries for protecting SIP have been configured or will be created before attempting to use the security agreement procedure, and that SIP communications use port numbers and addresses according to these policy entries. It is outside the scope of this specification to describe how this information can be made known to the peers, but it would typically be configured at the same time as the IKE credentials or manual SAs have been entered.
在这两种基于IPsec的机制中，预期在尝试使用安全协议过程之前已配置或将创建用于保护SIP的适当策略项，并且SIP通信根据这些策略项使用端口号和地址。描述如何让对等方知道此信息不在本规范的范围内，但通常在输入IKE凭据或手动SA的同时对其进行配置。
Once a security mechanism has been negotiated, both the server and the client need to know until when it can be used. All the mechanisms described in this document have a different way of signaling the end of a security association. When TLS is used, the termination of the connection indicates that a new negotiation is needed. IKE negotiates the duration of a security association. If the credentials provided by a client using digest are no longer valid, the server will re-challenge the client. It is assumed that when IPsec-man is used, the same out-of-band mechanism used to distribute keys is used to define the duration of the security association.
一旦协商了安全机制，服务器和客户端都需要知道何时可以使用它。本文档中描述的所有机制都有一种不同的方式来表示安全关联的结束。使用TLS时，连接的终止表示需要新的协商。IKE协商安全关联的持续时间。如果使用摘要的客户端提供的凭据不再有效，服务器将重新质询该客户端。假设在使用IPsec man时，使用与分发密钥相同的带外机制来定义安全关联的持续时间。
The header fields defined in this document may be used to negotiate the security mechanisms between a UAC and other SIP entities including UAS, proxy, and registrar. Information about the use of headers in relation to SIP methods and proxy processing is summarized in Table 1.
本文档中定义的头字段可用于协商UAC和其他SIP实体（包括UAS、代理和注册机构）之间的安全机制。表1总结了与SIP方法和代理处理相关的头的使用信息。
Header field where proxy ACK BYE CAN INV OPT REG
_________________________________________________________________
Security-Client R ard - o - o o o
Security-Server 421,494 - o - o o o
Security-Verify R ard - o - o o o
Header field where proxy ACK BYE CAN INV OPT REG
_________________________________________________________________
Security-Client R ard - o - o o o
Security-Server 421,494 - o - o o o
Security-Verify R ard - o - o o o
Header field where proxy SUB NOT PRK IFO UPD MSG
_________________________________________________________________
Security-Client R ard o o - o o o
Security-Server 421,494 o o - o o o
Security-Verify R ard o o - o o o
Header field where proxy SUB NOT PRK IFO UPD MSG
_________________________________________________________________
Security-Client R ard o o - o o o
Security-Server 421,494 o o - o o o
Security-Verify R ard o o - o o o
Table 1: Summary of Header Usage.
表1：标题使用摘要。
The "where" column describes the request and response types in which the header field may be used. The header may not appear in other types of SIP messages. Values in the where column are:
“where”列描述了可以使用header字段的请求和响应类型。标头可能不会出现在其他类型的SIP消息中。where列中的值为：
* R: Header field may appear in requests.
* R：请求中可能会出现标题字段。
* 421, 494: A numerical value indicates response codes with which the header field can be used.
* 421494：数字值表示可以使用标题字段的响应代码。
The "proxy" column describes the operations a proxy may perform on a header field:
“代理”列描述代理可以对标题字段执行的操作：
* a: A proxy can add or concatenate the header field if not present.
* 答：代理可以添加或连接标题字段（如果不存在）。
* r: A proxy must be able to read the header field, and thus this header field cannot be encrypted.
* r：代理必须能够读取头字段，因此此头字段不能加密。
* d: A proxy can delete a header field value.
* d：代理可以删除标题字段值。
The next six columns relate to the presence of a header field in a method:
接下来的六列与方法中是否存在标题字段有关：
* o: The header field is optional.
* o：标题字段是可选的。
The use of this extension in a network interface is a matter of local policy. Different network interfaces may follow different policies, and consequently the use of this extension may be situational by nature. UA and server implementations MUST be configurable to operate with or without this extension.
在网络接口中使用此扩展是本地策略的问题。不同的网络接口可能遵循不同的策略，因此此扩展的使用本质上可能是情境性的。UA和服务器实现必须可配置，以便在有或没有此扩展的情况下运行。
A server that is configured to use this mechanism, may also accept requests from clients that use TLS based on the rules defined in [5]. Requests from clients that do not support this extension, and do not support TLS, can not be accepted. This obviously breaks interoperability with some SIP clients. Therefore, this extension should be used in environments where it is somehow ensured that every client implements this extension or is able to use TLS. This extension may also be used in environments where insecure communication is not acceptable if the option of not being able to communicate is also accepted.
配置为使用此机制的服务器也可以根据[5]中定义的规则接受来自使用TLS的客户端的请求。无法接受来自不支持此扩展和不支持TLS的客户端的请求。这显然破坏了与某些SIP客户端的互操作性。因此，应该在某种程度上确保每个客户机实现此扩展或能够使用TLS的环境中使用此扩展。如果不能够通信的选项也被接受，则此扩展还可用于不可接受不安全通信的环境中。
The following examples illustrate the use of the mechanism defined above.
以下示例说明了上述机制的使用。
A UA negotiates the security mechanism to be used with its outbound proxy without knowing beforehand which mechanisms the proxy supports. The OPTIONS method can be used here to request the security capabilities of the proxy. In this way, the security can be initiated even before the first INVITE is sent via the proxy.
UA协商要与其出站代理一起使用的安全机制，而事先不知道代理支持哪些机制。这里可以使用OPTIONS方法来请求代理的安全功能。这样，即使在通过代理发送第一个邀请之前，也可以启动安全性。
UAC Proxy UAS
| | |
|----(1) OPTIONS---->| |
| | |
|<-----(2) 494-------| |
| | |
|<=======TLS========>| |
| | |
|----(3) INVITE----->| |
| |----(4) INVITE--->|
| | |
| |<---(5) 200 OK----|
|<---(6) 200 OK------| |
| | |
|------(7) ACK------>| |
| |-----(8) ACK----->|
| | |
| | |
| | |
| | |
UAC Proxy UAS
| | |
|----(1) OPTIONS---->| |
| | |
|<-----(2) 494-------| |
| | |
|<=======TLS========>| |
| | |
|----(3) INVITE----->| |
| |----(4) INVITE--->|
| | |
| |<---(5) 200 OK----|
|<---(6) 200 OK------| |
| | |
|------(7) ACK------>| |
| |-----(8) ACK----->|
| | |
| | |
| | |
| | |
Figure 2: Negotiation Initiated by the Client.
图2：客户发起的协商。
The UAC sends an OPTIONS request to its outbound proxy, indicating at the same time that it is able to negotiate security mechanisms and that it supports TLS and HTTP Digest (1).
UAC向其出站代理发送一个选项请求，同时表明它能够协商安全机制，并且支持TLS和HTTP摘要（1）。
The outbound proxy responds to the UAC with its own list of security mechanisms - IPsec and TLS (2). The only common security mechanism is TLS, so they establish a TLS connection between them. When the connection is successfully established, the UAC sends an INVITE request over the TLS connection just established (3). This INVITE contains the server's security list. The server verifies it, and since it matches its static list, it processes the INVITE and forwards it to the next hop.
出站代理使用自己的安全机制列表（IPsec和TLS）响应UAC（2）。唯一常见的安全机制是TLS，因此它们在它们之间建立TLS连接。成功建立连接后，UAC通过刚刚建立的TLS连接发送INVITE请求（3）。此邀请包含服务器的安全列表。服务器验证它，因为它匹配它的静态列表，所以它处理邀请并将其转发到下一个跃点。
If this example was run without Security-Server header in Step 2, the UAC would not know what kind of security the other one supports, and would be forced to error-prone trials.
如果此示例在步骤2中没有安全服务器头的情况下运行，UAC将不知道另一个支持哪种安全性，并且将被迫进行容易出错的测试。
More seriously, if the Security-Verify was omitted in Step 3, the whole process would be prone for MitM attacks. An attacker could spoof "ICMP Port Unreachable" message on the trials, or remove the stronger security option from the header in Step 1, therefore substantially reducing the security.
更严重的是，如果在步骤3中省略了安全验证，那么整个过程将容易受到MitM攻击。攻击者可以在试用中伪造“ICMP端口不可访问”消息，或在步骤1中从标头中删除更强大的安全选项，从而大大降低安全性。
(1) OPTIONS sip:proxy.example.com SIP/2.0 Security-Client: tls Security-Client: digest Require: sec-agree Proxy-Require: sec-agree
(1) 选项sip:proxy.example.com sip/2.0安全客户端：tls安全客户端：摘要要求：sec同意代理要求：sec同意
(2) SIP/2.0 494 Security Agreement Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(2) SIP/2.0 494 Security Agreement Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(3) INVITE sip:proxy.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
Route: sip:callee@domain.com
Require: sec-agree
Proxy-Require: sec-agree
(3) INVITE sip:proxy.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
Route: sip:callee@domain.com
Require: sec-agree
Proxy-Require: sec-agree
The 200 OK response (6) for the INVITE and the ACK (7) are also sent over the TLS connection. The ACK will contain the same Security-Verify header field as the INVITE (3).
INVITE的200 OK响应（6）和ACK（7）也通过TLS连接发送。ACK将包含与INVITE（3）相同的安全验证标头字段。
In this example of Figure 3 the client sends an INVITE towards the callee using an outbound proxy. This INVITE does not contain any Require header field.
在图3的示例中，客户端使用出站代理向被调用方发送一个INVITE。此邀请不包含任何Require标头字段。
UAC Proxy UAS
| | |
|-----(1) INVITE---->| |
| | |
|<-----(2) 421-------| |
| | |
|------(3) ACK------>| |
| | |
|<=======IKE========>| |
| | |
|-----(4) INVITE---->| |
| |----(5) INVITE--->|
| | |
| |<---(6) 200 OK----|
|<----(7) 200 OK-----| |
| | |
|------(8) ACK------>| |
| |-----(9) ACK----->|
| | |
| | |
UAC Proxy UAS
| | |
|-----(1) INVITE---->| |
| | |
|<-----(2) 421-------| |
| | |
|------(3) ACK------>| |
| | |
|<=======IKE========>| |
| | |
|-----(4) INVITE---->| |
| |----(5) INVITE--->|
| | |
| |<---(6) 200 OK----|
|<----(7) 200 OK-----| |
| | |
|------(8) ACK------>| |
| |-----(9) ACK----->|
| | |
| | |
Figure 3: Server Initiated Security Negotiation.
图3：服务器启动的安全协商。
The proxy, following its local policy, does not accept the INVITE. It returns a 421 (Extension Required) with a Security-Server header field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE it performs the key exchange and establishes a security association with the proxy.
代理按照其本地策略不接受邀请。它返回一个421（需要扩展名），其中包含列出IPsec IKE和TLS的安全服务器头字段。由于UAC支持IPsec IKE，它执行密钥交换并与代理建立安全关联。
The second INVITE (4) and the ACK (8) contain a Security-Verify header field that mirrors the Security-Server header field received in the 421. The INVITE (4), the 200 OK (7) and the ACK (8) are sent using the security association that has been established.
第二个INVITE（4）和ACK（8）包含一个Security Verify头字段，该字段镜像421中接收到的Security Server头字段。使用已建立的安全关联发送INVITE（4）、200 OK（7）和ACK（8）。
(1) INVITE sip:uas.example.com SIP/2.0
(1) 邀请sip:uas.example.com sip/2.0
(2) SIP/2.0 421 Extension Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(2) SIP/2.0 421 Extension Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(4) INVITE sip:uas.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
(4) INVITE sip:uas.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
This specification is about making it possible to select between various SIP security mechanisms in a secure manner. In particular, the method presented herein allow current networks using, for instance, HTTP Digest, to be securely upgraded to, for instance, IPsec without requiring a simultaneous modification in all equipment. The method presented in this specification is secure only if the weakest proposed mechanism offers at least integrity and replay protection for the Security-Verify header field.
本规范旨在以安全的方式在各种SIP安全机制之间进行选择。具体地说，本文提出的方法允许使用例如HTTP摘要的当前网络安全地升级到例如IPsec，而不需要在所有设备中同时修改。本规范中提出的方法只有在最薄弱的提议机制至少为安全验证报头字段提供完整性和重播保护时才是安全的。
The security implications of this are subtle, but do have a fundamental importance in building large networks that change over time. Given that the hashes are produced also using algorithms agreed in the first unprotected messages, one could ask what the difference in security really is. Assuming integrity protection is mandatory and only secure algorithms are used, we still need to prevent MitM attackers from modifying other parameters, such as whether encryption is provided or not. Let us first assume two peers capable of using both strong and weak security. If the initial offers are not protected in any way, any attacker can easily "downgrade" the offers by removing the strong options. This would force the two peers to use weak security between them. But if the offers are protected in some way -- such as by hashing, or repeating them later when the selected security is really on -- the situation is different. It would not be sufficient for the attacker to modify a single message. Instead, the attacker would have to modify both the offer message, as well as the message that contains the hash/ repetition. More importantly, the attacker would have to forge the weak security that is present in the second message, and would have to do so in real time between the sent offers and the later messages. Otherwise, the peers would notice that the hash is incorrect. If the attacker is able to break the weak security, the security method and/or the algorithm should not be used.
这对安全的影响是微妙的，但在构建随时间变化的大型网络方面确实具有根本重要性。考虑到散列也是使用在第一条未受保护的消息中约定的算法生成的，人们可能会问，安全性的区别到底是什么。假设完整性保护是强制性的，并且只使用安全算法，我们仍然需要防止MitM攻击者修改其他参数，例如是否提供加密。让我们首先假设两个对等点能够同时使用强安全性和弱安全性。如果初始报价未受到任何保护，任何攻击者都可以通过删除强选项轻松“降级”报价。这将迫使两个对等方在它们之间使用弱安全性。但是，如果提供以某种方式受到保护——比如通过哈希，或者在选定的安全性真正启用时重复它们——情况就不同了。攻击者仅修改一条消息是不够的。相反，攻击者必须修改提供消息以及包含哈希/重复的消息。更重要的是，攻击者必须伪造第二条消息中存在的弱安全性，并且必须在发送的要约和以后的消息之间实时伪造。否则，对等方会注意到散列不正确。如果攻击者能够破坏弱安全性，则不应使用安全方法和/或算法。
In conclusion, the security difference is making a trivial attack possible versus demanding the attacker to break algorithms. An example of where this has a serious consequence is when a network is first deployed with integrity protection (such as HTTP Digest [4]), and then later new devices are added that support also encryption (such as TLS [3]). In this situation, an insecure negotiation procedure allows attackers to trivially force even new devices to use only integrity protection.
综上所述，安全性的区别在于使一次微不足道的攻击成为可能，而不是要求攻击者破坏算法。这会产生严重后果的一个例子是，首先部署具有完整性保护的网络（如HTTP摘要[4]），然后添加支持加密的新设备（如TLS[3]）。在这种情况下，不安全的协商过程允许攻击者轻松地强制新设备仅使用完整性保护。
Possible attacks against the security agreement include:
对安全协议的可能攻击包括：
1. Attackers could try to modify the server's list of security mechanisms in the first response. This would be revealed to the server when the client returns the received list using the security.
1. 攻击者可以尝试在第一个响应中修改服务器的安全机制列表。当客户端使用安全机制返回接收到的列表时，这将显示给服务器。
2. Attackers could also try to modify the repeated list in the second request from the client. However, if the selected security mechanism uses encryption this may not be possible, and if it uses integrity protection any modifications will be detected by the server.
2. 攻击者还可以尝试在客户端的第二个请求中修改重复列表。但是，如果选定的安全机制使用加密，这可能不可能，如果使用完整性保护，服务器将检测到任何修改。
3. Attackers could try to modify the client's list of security mechanisms in the first message. The client selects the security mechanism based on its own knowledge of its own capabilities and the server's list, hence the client's choice would be unaffected by any such modification. However, the server's choice could still be affected as described below:
3. 攻击者可以尝试在第一条消息中修改客户端的安全机制列表。客户机根据自己对自身功能和服务器列表的了解来选择安全机制，因此客户机的选择不受任何此类修改的影响。但是，服务器的选择仍可能受到影响，如下所述：
* If the modification affected the server's choice, the server and client would end up choosing different security mechanisms in Step 3 or 4 of Figure 1. Since they would be unable to communicate to each other, this would be detected as a potential attack. The client would either retry or give up in this situation.
* 如果修改影响了服务器的选择，那么在图1的步骤3或4中，服务器和客户端最终将选择不同的安全机制。由于它们将无法相互通信，因此这将被检测为潜在的攻击。在这种情况下，客户端将重试或放弃。
* If the modification did not affect the server's choice, there's no effect.
* 如果修改没有影响服务器的选择，则不会产生任何影响。
4. Finally, attackers may also try to reply old security agreement messages. Each security mechanism must provide replay protection. In particular, HTTP Digest implementations should carefully utilize existing reply protection options such as including a time-stamp to the nonce parameter, and using nonce counters [4].
4. 最后，攻击者还可能尝试回复旧的安全协议消息。每个安全机制必须提供重播保护。特别是，HTTP摘要实现应该仔细利用现有的回复保护选项，例如在nonce参数中包含时间戳，以及使用nonce计数器[4]。
All clients that implement this specification MUST select HTTP Digest, TLS, IPsec, or any stronger method for the protection of the second request.
实现此规范的所有客户端都必须选择HTTP摘要、TLS、IPsec或任何更强的方法来保护第二个请求。
This specification defines a new mechanism-name namespace in Section 2.2 which requires a central coordinating body. The body responsible for this coordination is the Internet Assigned Numbers Authority (IANA).
本规范在第2.2节中定义了一个新的机制名称命名空间，它需要一个中央协调机构。负责协调的机构是互联网分配号码管理局（IANA）。
This document defines four mechanism-names to be initially registered, namely "digest", "tls", "ipsec-ike", and "ipsec-man". In addition to these mechanism-names, "ipsec-3gpp" mechanism-name is also registered (see Appendix A). Following the policies outlined in [10], further mechanism-names are allocated based on IETF Consensus.
本文档定义了初始注册的四个机制名称，即“摘要”、“tls”、“ipsec ike”和“ipsec man”。除了这些机制名称外，还注册了“ipsec-3gpp”机制名称（见附录A）。按照[10]中概述的政策，根据IETF共识分配更多的机制名称。
Registrations with the IANA MUST include the mechanism-name token being registered, and a pointer to a published RFC describing the details of the corresponding security mechanism.
IANA注册必须包括正在注册的机制名称令牌，以及一个指向已发布RFC的指针，该RFC描述了相应安全机制的详细信息。
IANA registers new mechanism-names at http://www.iana.org/assignments/sip-parameters under "Security Mechanism Names". As this document specifies five mechanism-names, the initial IANA registration for mechanism-names will contain the information shown in Table 2. It also demonstrates the type of information maintained by the IANA.
IANA在http://www.iana.org/assignments/sip-parameters 在“安全机制名称”下。由于本文件指定了五个机构名称，机构名称的初始IANA注册将包含表2中所示的信息。它还演示了IANA维护的信息类型。
Mechanism Name Reference
-------------- ---------
digest [RFC3329]
tls [RFC3329]
ipsec-ike [RFC3329]
ipsec-man [RFC3329]
ipsec-3gpp [RFC3329]
Mechanism Name Reference
-------------- ---------
digest [RFC3329]
tls [RFC3329]
ipsec-ike [RFC3329]
ipsec-man [RFC3329]
ipsec-3gpp [RFC3329]
Table 2: Initial IANA registration.
表2：初始IANA注册。
To: ietf-sip-sec-agree-mechanism-name@iana.org Subject: Registration of a new SIP Security Agreement mechanism
致：ietf sip sec同意机制-name@iana.org主题：注册新的SIP安全协议机制
Mechanism Name:
机构名称：
(Token value conforming to the syntax described in Section 2.2.)
（符合第2.2节所述语法的标记值。）
Published Specification(s):
已发布的规范：
(Descriptions of new SIP Security Agreement mechanisms require a published RFC.)
（新SIP安全协议机制的描述需要发布RFC。）
This specification registers three new header fields, namely Security-Client, Security-Server and Security-Verify. These headers are defined by the following information, which has been included in the sub-registry for SIP headers under http://www.iana.org/assignments/sip-parameters.
该规范注册了三个新的头字段，即安全客户端、安全服务器和安全验证。这些头由以下信息定义，这些信息已包含在下的SIP头的子注册表中http://www.iana.org/assignments/sip-parameters.
Header Name: Security-Client Compact Form: (none)
标题名称：安全客户端压缩表单：（无）
Header Name: Security-Server Compact Form: (none)
标题名称：安全服务器压缩表单：（无）
Header Name: Security-Verify Compact Form: (none)
标题名称：安全验证压缩表单：（无）
This specification registers a new response code, namely 494 (Security Agreement Required). The response code is defined by the following information, which has been included to the sub-registry for SIP methods and response-codes under http://www.iana.org/assignments/sip-parameters.
本规范注册了一个新的响应代码，即494（需要安全协议）。响应代码由以下信息定义，这些信息已包含在SIP方法和响应代码的子注册表中http://www.iana.org/assignments/sip-parameters.
Response Code Number: 494 Default Reason Phrase: Security Agreement Required
响应代码：494默认原因短语：需要安全协议
This specification defines a new option tag, namely sec-agree. The option tag is defined by the following information, which has been included in the sub-registry for option tags under http://www.iana.org/assignments/sip-parameters.
本规范定义了一个新的选项标签，即sec agree。选项标记由以下信息定义，这些信息已包含在下选项标记的子注册表中http://www.iana.org/assignments/sip-parameters.
Name: sec-agree Description: This option tag indicates support for the Security Agreement mechanism. When used in the Require, or Proxy-Require headers, it indicates that proxy servers are required to use the Security Agreement mechanism. When used in the Supported header, it indicates that the User Agent Client supports the Security Agreement mechanism. When used in the Require header in the 494 (Security Agreement Required) or 421 (Extension Required) responses, it indicates that the User Agent Client must use the Security Agreement Mechanism.
名称：sec agree说明：此选项标记表示支持安全协议机制。当在Require或Proxy Require头中使用时，它表示需要代理服务器使用安全协议机制。当在支持的标头中使用时，它表示用户代理客户端支持安全协议机制。当在494（需要安全协议）或421（需要扩展）响应的Require头中使用时，它表示用户代理客户端必须使用安全协议机制。
Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to the document.
北电网络公司的桑乔·森和李·瓦莱里乌斯为该文件做出了贡献。
In addition to the contributors, the authors wish to thank Allison Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia, Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP SA3 group for interesting discussions in this problem space.
除了撰稿人之外，作者还要感谢Allison Mankin、Rolf Blom、James Undy、Jonathan Rosenberg、Hugh Shieh、Gunther Horn、Krister Boman、David Castellanos Zamora、Miguel Garcia、Valtteri Niemi、Martin Euchner、Eric Rescorla和3GPP SA3小组的成员在此问题空间进行了有趣的讨论。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[3] Dierks, T. and C. Allen, P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks，T.和C.Allen，P.Kocher，“TLS协议版本1.0”，RFC 2246，1999年1月。
[4] 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.
[4] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[6] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[7] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[11] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress.
[11] Garcia Martin，M.，“第三代合作伙伴关系项目（3GPP）发布5对会话启动协议（SIP）的要求”，正在进行中。
[12] 3rd Generation Partnership Project, "Access security for IP-based services, Release 5", TS 33.203 v5.3.0, September 2002.
[12] 第三代合作伙伴项目，“基于IP的服务的访问安全，第5版”，TS 33.203 v5.3.0，2002年9月。
[13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[13] Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[14] Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[15] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[15] Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
This appendix extends the security agreement framework described in this document with a new security mechanism: "ipsec-3gpp". This security mechanism and its associated parameters are used in the 3GPP IP Multimedia Subsystem [12]. The Augmented BNF definitions below follow the syntax of SIP [1].
本附录使用新的安全机制“ipsec-3gpp”扩展了本文档中描述的安全协议框架。此安全机制及其相关参数用于3GPP IP多媒体子系统[12]。下面的扩展BNF定义遵循SIP[1]的语法。
mechanism-name = ( "ipsec-3gpp" )
mech-parameters = ( algorithm / protocol /mode /
encrypt-algorithm / spi /
port1 / port2 )
algorithm = "alg" EQUAL ( "hmac-md5-96" /
"hmac-sha-1-96" )
protocol = "prot" EQUAL ( "ah" / "esp" )
mode = "mod" EQUAL ( "trans" / "tun" )
encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
spi = "spi" EQUAL spivalue
spivalue = 10DIGIT; 0 to 4294967295
port1 = "port1" EQUAL port
port2 = "port2" EQUAL port
port = 1*DIGIT
mechanism-name = ( "ipsec-3gpp" )
mech-parameters = ( algorithm / protocol /mode /
encrypt-algorithm / spi /
port1 / port2 )
algorithm = "alg" EQUAL ( "hmac-md5-96" /
"hmac-sha-1-96" )
protocol = "prot" EQUAL ( "ah" / "esp" )
mode = "mod" EQUAL ( "trans" / "tun" )
encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
spi = "spi" EQUAL spivalue
spivalue = 10DIGIT; 0 to 4294967295
port1 = "port1" EQUAL port
port2 = "port2" EQUAL port
port = 1*DIGIT
The parameters described by the BNF above have the following semantics:
上述BNF描述的参数具有以下语义：
Algorithm This parameter defines the used authentication algorithm. It may have a value of "hmac-md5-96" for HMAC-MD5-96 [13], or "hmac-sha-1-96" for HMAC-SHA-1-96 [14]. The algorithm parameter is mandatory.
算法此参数定义使用的身份验证算法。对于hmac-md5-96[13]，其值可能为“hmac-md5-96”；对于hmac-sha-1-96[14]，其值可能为“hmac-sha-1-96”。算法参数是必需的。
Protocol This parameter defines the IPsec protocol. It may have a value of "ah" for AH [6], or "esp" for ESP [7]. If no Protocol parameter is present, the protocol will be ESP by default.
协议此参数定义IPsec协议。ah[6]的值可能为“ah”，esp[7]的值可能为“esp”。如果不存在协议参数，则默认情况下该协议为ESP。
Mode This parameter defines the mode in which the IPsec protocol is used. It may have a value of "trans" for transport mode, or a value of "tun" for tunneling mode. If no Mode parameter is present the IPsec protocol is used in transport mode.
模式此参数定义使用IPsec协议的模式。对于传输模式，其值可能为“trans”，对于隧道模式，其值可能为“tun”。如果没有模式参数，则在传输模式下使用IPsec协议。
Encrypt-algorithm This parameter defines the used encryption algorithm. It may have a value of "des-ede3-cbc" for 3DES [15], or "null" for no encryption. If no Encrypt-algorithm parameter is present, encryption is not used.
加密算法此参数定义使用的加密算法。对于3DES[15]，其值可能为“des-ede3-cbc”，对于无加密，其值可能为“null”。如果不存在加密算法参数，则不使用加密。
Spi Defines the SPI number used for inbound messages.
Spi定义用于入站消息的Spi编号。
Port1 Defines the destination port number for inbound messages that are protected.
Port1定义受保护的入站邮件的目标端口号。
Port2 Defines the source port number for outbound messages that are protected. Port 2 is optional.
Port2定义受保护的出站消息的源端口号。端口2是可选的。
The communicating SIP entities need to know beforehand which keys to use. It is also assumed that the underlying IPsec implementation supports selectors that allow all transport protocols supported by SIP to be protected with a single SA. The duration of security association is the same as in the expiration interval of the corresponding registration binding.
进行通信的SIP实体需要事先知道要使用哪些密钥。还假设底层IPsec实现支持选择器，允许SIP支持的所有传输协议都使用单个SA进行保护。安全关联的持续时间与相应注册绑定的过期时间间隔相同。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas, FIN 02420 Finland
芬兰芬兰雅丽阿尔科爱立信公司，邮编02420
Phone: +358 40 507 9256
EMail: jari.arkko@ericsson.com
Phone: +358 40 507 9256
EMail: jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
芬兰芬兰图尔库1号爱立信酒店20520
Phone: +358 40 723 0822
EMail: vesa.torvinen@ericsson.fi
Phone: +358 40 723 0822
EMail: vesa.torvinen@ericsson.fi
Gonzalo Camarillo Advanced Signalling Research Lab. Ericsson FIN-02420 Jorvas Finland
冈萨洛·卡马里洛高级信号研究实验室，爱立信FIN-02420约瓦斯芬兰
Phone: +358 40 702 3535
EMail: Gonzalo.Camarillo@ericsson.com
Phone: +358 40 702 3535
EMail: Gonzalo.Camarillo@ericsson.com
Aki Niemi NOKIA Corporation P.O.Box 321, FIN 00380 Finland
芬兰芬兰芬兰芬兰诺基亚公司Aki Niemi邮政信箱321号，邮编00380
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Tao Haukka Nokia Corporation P.O. Box 50 FIN - 90570 Oulu Finland
Tao Haukka诺基亚公司邮政信箱50 FIN-芬兰奥卢90570
Phone: +358 40 517 0079
EMail: tao.haukka@nokia.com
Phone: +358 40 517 0079
EMail: tao.haukka@nokia.com
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编辑功能的资金目前由互联网协会提供。