Network Working Group J. Peterson
Request for Comments: 3893 NeuStar
Category: Standards Track September 2004
Network Working Group J. Peterson
Request for Comments: 3893 NeuStar
Category: Standards Track September 2004
Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format
会话启动协议（SIP）认证身份主体（AIB）格式
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given.
RFC3261引入了向会话发起协议（SIP）请求或响应添加S/MIME主体的概念，以便在其头上提供引用完整性。本文档提供了一种更具体的机制，用于从“经过身份验证的标识体”、数字签名的SIP消息或消息片段派生完整性和身份验证属性。本文件给出了此类机构（称为认证身份机构或AIB）的标准格式。本文还给出了SIP消息接收者处理AIB的一些注意事项。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation. . . . . . . . . . . . . . . . . . 3
2. AIB Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Example of a Request with AIB . . . . . . . . . . . . . . . . 5
4. AIBs for Identifying Third-Parties . . . . . . . . . . . . . . 6
5. Identity in non-INVITE Requests . . . . . . . . . . . . . . . 7
6. Identity in Responses . . . . . . . . . . . . . . . . . . . . 7
7. Receiving an AIB . . . . . . . . . . . . . . . . . . . . . . . 7
8. Encryption of Identity . . . . . . . . . . . . . . . . . . . . 8
9. Example of Encryption . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation. . . . . . . . . . . . . . . . . . 3
2. AIB Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Example of a Request with AIB . . . . . . . . . . . . . . . . 5
4. AIBs for Identifying Third-Parties . . . . . . . . . . . . . . 6
5. Identity in non-INVITE Requests . . . . . . . . . . . . . . . 7
6. Identity in Responses . . . . . . . . . . . . . . . . . . . . 7
7. Receiving an AIB . . . . . . . . . . . . . . . . . . . . . . . 7
8. Encryption of Identity . . . . . . . . . . . . . . . . . . . . 8
9. Example of Encryption . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
Section 23.4 of RFC 3261 [1] describes an integrity mechanism that relies on signing tunneled 'message/sip' MIME bodies within SIP requests. The purpose of this mechanism is to replicate the headers of a SIP request within a body carried in that request in order to provide a digital signature over these headers. The signature on this body also provides authentication.
RFC 3261[1]第23.4节描述了一种完整性机制，该机制依赖于对sip请求中的隧道“消息/sip”MIME体进行签名。该机制的目的是在SIP请求的主体内复制该请求的头，以便在这些头上提供数字签名。此主体上的签名还提供身份验证。
The core requirement that motivates the tunneled 'message/sip' mechanism is the problem of providing a cryptographically verifiable identity within a SIP request. The baseline SIP protocol allows a user agent to express the identity of its user in any of a number of headers. The primary place for identity information asserted by the sender of a request is the From header. The From header field contains a URI (like 'sip:alice@example.com') and an optional display-name (like "Alice") that identifies the originator of the request. A user may have many identities that are used in different contexts.
激励隧道“消息/sip”机制的核心需求是在sip请求中提供加密可验证身份的问题。基线SIP协议允许用户代理在多个报头中的任意一个头中表示其用户的身份。请求的发送方声明的标识信息的主要位置是From头。From标头字段包含URI（如“sip:alice@example.com）和一个可选的显示名称（如“Alice”），用于标识请求的发起人。一个用户可能有许多在不同上下文中使用的身份。
Typically, this URI is an address-of-record that can be de-referenced in order to contact the originator of the request; specifically, it is usually the same address-of-record under which a user registers their devices in order to receive incoming requests. This address-of-record is assigned and maintained by the administrator of the SIP service in the domain identified by the host portion of the address-of-record. However, the From field of a request can usually be set
通常，此URI是记录的地址，可以取消引用以联系请求的发起人；具体来说，它通常是用户注册其设备以接收传入请求的同一记录地址。该记录地址由SIP服务的管理员在记录地址的主机部分标识的域中分配和维护。但是，通常可以设置请求的“发件人”字段
arbitrarily by the user of a SIP user agent; the From header of a message provides no internal assurance that the originating user can legitimately claim the given identity. Nevertheless, many SIP user agents will obligingly display the contents of the From field as the identity of the originator of a received request (as a sort of caller identification function), much as email implementations display the From field as the sender's identity.
由SIP用户代理的用户任意地；消息的From标头不提供发起用户可以合法声明给定身份的内部保证。尽管如此，许多SIP用户代理将有义务将From字段的内容显示为所接收请求的发起人的身份（作为一种呼叫者身份识别功能），就像电子邮件实现将From字段显示为发送者的身份一样。
In order to provide the recipient of a SIP message with greater assurance of the identity of the sender, a cryptographic signature can be provided over the headers of the SIP request, which allows the signer to assert a verifiable identity. Unfortunately, a signature over the From header alone is insufficient because it could be cut-and-pasted into a replay or forwarding attack, and more headers are therefore needed to correlate a signature with a request. RFC 3261 therefore recommends copying all of the headers from the request into a signed MIME body; however, SIP messages can be large, and many of the headers in a SIP message would not be relevant in determining the identity of the sender or assuring reference integrity with the request, and moreover some headers may change in transit for perfectly valid reasons. Thus, this large tunneled 'message/sip' body will almost necessarily be at variance with the headers in a request when it is received by the UAS, and the burden in on the UAS to determine which header changes were legitimate, and which were security violations. It is therefore desirable to find a happy medium - to provide a way of signing just enough headers that the identity of the sender can be ascertained and correlated with the request. 'message/sipfrag' [4] provides a way for a subset of SIP headers to be included in a MIME body; the Authenticated Identity Body (AIB) format described in Section 2 is based on 'message/sipfrag'.
为了向SIP消息的接收者提供对发送者的身份的更大保证，可以在SIP请求的报头上提供密码签名，这允许签名者断言可验证的身份。不幸的是，仅通过From头的签名是不够的，因为它可能被剪切并粘贴到重播或转发攻击中，因此需要更多的头来将签名与请求关联起来。因此，RFC3261建议将请求中的所有头复制到签名的MIME正文中；然而，SIP消息可能很大，SIP消息中的许多报头与确定发送者的身份或确保请求的引用完整性无关，而且一些报头可能在传输过程中由于完全有效的原因而改变。因此，当UAS接收到这个大型隧道“消息/sip”主体时，它几乎必然与请求中的头不一致，并且UAS有责任确定哪些头更改是合法的，哪些是违反安全的。因此，我们希望找到一个令人满意的媒介——提供一种对足够多的头进行签名的方法，以便能够确定发送者的身份并将其与请求关联起来。”message/sipfrag'[4]提供了一种将SIP头的子集包括在MIME主体中的方法；第2节中描述的身份验证机构（AIB）格式基于“消息/sipfrag”。
For reasons of end-to-end privacy, it may also be desirable to encrypt AIBs; procedures for this encryption are given in Section 8.
出于端到端隐私的原因，加密aib也是可取的；第8节给出了这种加密的程序。
This document proposes that the AIB format should be used instead of the existing tunneled 'message/sip' mechanism described in RFC 3261, section 23.4, in order to provide the identity of the caller; if integrity over other, unrelated headers is required, then the 'message/sip' mechanism should be used.
本文件建议使用AIB格式代替RFC 3261第23.4节中描述的现有隧道“消息/sip”机制，以提供呼叫者的身份；如果需要在其他不相关的头上保持完整性，则应使用“消息/sip”机制。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
As a way of sharing authenticated identity among parties in the network, a special type of MIME body format, the Authenticated Identity Body (AIB) format, is defined in this section. AIBs allow a party in a SIP transaction to cryptographically sign the headers that assert the identity of the originator of a message, and provide some other headers necessary for reference integrity.
作为在网络各方之间共享经过身份验证的身份的一种方式，本节定义了一种特殊类型的MIME正文格式，即经过身份验证的身份正文（AIB）格式。AIB允许SIP事务中的一方对声明消息发起人身份的报头进行加密签名，并提供引用完整性所需的一些其他报头。
An AIB is a MIME body of type 'message/sipfrag' - for more information on constructing sipfrags, including examples, see [4]. This MIME body MUST have a Content-Disposition [3] disposition-type of 'aib', a new value defined in this document specifically for authenticated identity bodies. The Content-Disposition header SHOULD also contain a 'handling' parameter indicating that this MIME body is optional (i.e., if this mechanism is not supported by the user agent server, it can still attempt to process the request).
AIB是“message/sipfrag”类型的MIME主体，有关构造sipfrag的更多信息，包括示例，请参见[4]。此MIME正文的内容处置[3]处置类型必须为“aib”，这是本文档中专门为经过身份验证的标识正文定义的新值。Content Disposition标头还应包含一个“handling”参数，指示此MIME正文是可选的（即，如果用户代理服务器不支持此机制，它仍可以尝试处理请求）。
AIBs using the 'message/sipfrag' MIME type MUST contain the following headers when providing identity for an INVITE request: From, Date, Call-ID, and Contact; they SHOULD also contain the To and CSeq header. The security properties of these headers, and circumstances in which they should be used, are described in Section 10. AIBs MAY contain any other headers that help to uniquely identify the transaction or provide related reference integrity. An example of the AIB format for an INVITE is:
为邀请请求提供身份时，使用“message/sipfrag”MIME类型的AIB必须包含以下标题：发件人、日期、呼叫ID和联系人；它们还应包含To和CSeq标头。第10节介绍了这些标头的安全属性以及应在哪些情况下使用它们。AIB可能包含有助于唯一标识事务或提供相关引用完整性的任何其他标题。INVITE的AIB格式示例如下：
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.net>
Contact: <sip:alice@pc33.example.com>
Date: Thu, 21 Feb 2002 13:02:03 GMT
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.net>
Contact: <sip:alice@pc33.example.com>
Date: Thu, 21 Feb 2002 13:02:03 GMT
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Unsigned AIBs MUST be treated by any recipients according to the rules set out in Section 7 for AIBs that do not validate. After the AIB has been signed, it SHOULD be added to existing MIME bodies in the request (such as SDP), if necessary by transitioning the outermost MIME body to a 'multipart/mixed' format.
未签署的AIB必须由任何接收人根据第7节中针对未验证的AIB规定的规则进行处理。AIB签名后，如果需要，应将其添加到请求中的现有MIME正文（如SDP），方法是将最外层的MIME正文转换为“多部分/混合”格式。
The following shows a full SIP INVITE request with an AIB:
以下显示了带有AIB的完整SIP INVITE请求：
INVITE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.net>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.example.com>
Content-Type: multipart/mixed; boundary=unique-boundary-1
INVITE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.net>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.example.com>
Content-Type: multipart/mixed; boundary=unique-boundary-1
--unique-boundary-1
--唯一边界-1
Content-Type: application/sdp
Content-Length: 147
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 example.com
s=Session SDP
c=IN IP4 pc33.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 example.com
s=Session SDP
c=IN IP4 pc33.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 608
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 608
--boundary42
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
--boundary42
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.net>
Contact: <sip:alice@pc33.example.com>
Date: Thu, 21 Feb 2002 13:02:03 GMT
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.net>
Contact: <sip:alice@pc33.example.com>
Date: Thu, 21 Feb 2002 13:02:03 GMT
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
Ghyhhhhhhhhhhhhhhhhhhjhjh77n8hghtrfvbnj756tb9hg4vqpfyf467ghighfyt6 4vqpfyf467ghighfyt6jhhhhhhhhhhhhhhhhhhhhhjhjh756tb9hgtrffbnj n8hghtrfvhhhhhhhhhhhhhj776bb9hg4vqbnj7567ghigfyfyfyfyfyf4 7ghigff
--boundary42--
--边界42--
--unique-boundary-1--
--唯一边界-1--
There are special-case uses of the INVITE method in which some SIP messages are exchanged with a third party before an INVITE is sent, and in which the identity of the third party needs to be carried in the subsequent INVITE. The details of addressing identity in such contexts are outside the scope of this document. At a high level, it is possible that identity information for a third party might be carried in a supplemental AIB. The presence of a supplemental AIB within a message would not preclude the appearance of a 'regular' AIB as specified in this document.
INVITE方法有一些特殊情况，其中一些SIP消息在发送INVITE之前与第三方交换，并且在随后的INVITE中需要携带第三方的身份。在这种情况下处理身份的细节不在本文件的范围之内。在高层次上，第三方的身份信息可能会在补充AIB中携带。消息中存在补充AIB并不排除出现本文件中规定的“常规”AIB。
Example cases in which supplemental AIBs might appear include:
可能出现补充AIB的示例情况包括：
The use of the REFER [5] method, for example, has a requirement for the recipient of an INVITE to ascertain the identity of the referrer who caused the INVITE to be sent.
例如，使用REFER[5]方法要求邀请接收者确定导致发送邀请的推荐人的身份。
Third-party call control (3PCC [6]) has an even more complicated identity problem. A central controller INVITEs one party, gathers identity information (and session context) from that party, and then uses this information to INVITE another party. Ideally, the controller would also have a way to share a cryptographic identity signature given by the first party INVITEd by the controller to the second party invited by the controller.
第三方呼叫控制（3PCC[6]）有一个更复杂的身份问题。中央控制器邀请一方，从该方收集身份信息（和会话上下文），然后使用此信息邀请另一方。理想情况下，控制器还可以共享由控制器邀请的第一方提供给控制器邀请的第二方的加密身份签名。
In both of these cases, the Call-ID and CSeq of the original request (3PCC INVITE or REFER) would not correspond with that of the request in by the subsequent INVITE, nor would the To or From. In both the REFER case and the 3PCC case, the Call-ID and CSeq cannot be used to guarantee reference integrity, and it is therefore much harder to correlate an AIB to a subsequent INVITE request.
在这两种情况下，原始请求（3PCC INVITE或REFER）的呼叫ID和CSeq与后续INVITE中的请求ID和CSeq不一致，To或From也不一致。在REFER和3PCC两种情况下，调用ID和CSeq不能用于保证引用完整性，因此将AIB与后续INVITE请求关联起来要困难得多。
Thus, in these cases some other headers might be used to provide reference integrity between the headers in a supplemental AIB with the headers of a 3PCC or REFER-generated INVITE, but this usage is
因此，在这些情况下，可能会使用一些其他头来提供补充AIB中的头与3PCC或REFER生成的INVITE的头之间的引用完整性，但这种用法是不正确的
outside of the scope of this document. In order for AIBs to be used in these third-party contexts, further specification work is required to determine which additional headers, if any, need to be included in an AIB in a specific third-party case, and how to differentiate the primary AIB in a message from a third-party AIB.
不在本文件的范围内。为了在这些第三方上下文中使用AIB，需要进一步的规范工作来确定在特定的第三方情况下需要在AIB中包括哪些附加头（如果有），以及如何区分消息中的主AIB和第三方AIB。
The requirements for populating an AIB in requests within a dialog generally parallel those of the INVITE: From, Call-ID, Date, and Contact header fields are REQUIRED.
在对话框中的请求中填充AIB的要求通常与INVITE的要求类似：From、Call ID、Date和Contact header字段是必需的。
Some non-INVITE requests, however, may have different identity requirements. New SIP methods or extensions that leverage AIB security MUST identify any special identity requirements in the Security Considerations of their specification.
但是，某些非邀请请求可能具有不同的身份要求。利用AIB安全性的新SIP方法或扩展必须在其规范的安全考虑因素中确定任何特殊的身份要求。
Many of the practices described in the preceding sections can be applied to responses as well as requests. Note that a new set of headers must be generated to populate the AIB in a response. The From header field of the AIB in the response to an INVITE MUST correspond to the address-of-record of the responder, NOT to the From header field received in the request. The To header field of the request MUST NOT be included. A new Date header field and Contact header field should be generated for the AIB in a response. The Call-ID and CSeq should, however, be copied from the request.
前面章节中描述的许多实践可以应用于响应和请求。请注意，必须生成一组新的标头以在响应中填充AIB。在对INVITE的响应中，AIB的From header字段必须与响应者的记录地址相对应，而不是与请求中接收到的From header字段相对应。请求的To标头字段不能包含在内。应在响应中为AIB生成新的日期标题字段和联系人标题字段。但是，应该从请求中复制调用ID和CSeq。
Generally, the To header field of the request will correspond to the address-of-record of the responder. In some architectures where re-targeting is used, however, this need not be the case. Some recipients of response AIBs may consider it a cause for security concern if the To header field of the request is not the same as the address-of-record in the From header field of the AIB in a response.
通常，请求的To header字段将与响应者的记录地址相对应。然而，在某些使用重新定位的架构中，情况并非如此。如果响应的AI-Head字段与响应中的AIB的OFF报头字段中的记录地址不相同，则响应AIB的某些接收者可能认为这是安全关注的原因。
When a user agent receives a request containing an AIB, it MUST verify the signature, including validating the certificate of the signer, and compare the identity of the signer (the subjectAltName) with, in the INVITE case, the domain portion of the URI in the From header field of the request (for non-INVITE requests, other headers MAY be subject to this comparison). The two should correspond exactly; if they do not, the user agent MUST report this condition to its user before proceeding. User agents MAY distinguish between plausibly minor variations (the difference between 'example.com' and 'sip.example.com') and major variations ('example.com' vs.
当用户代理收到包含AIB的请求时，它必须验证签名，包括验证签名者的证书，并将签名者的身份（subjectAltName）与请求的From标头字段中URI的域部分进行比较（在INVITE情况下）（对于非INVITE请求，其他标头可能会进行此比较）。这两个标头应该完全对应；如果不对应，则用户代理必须在继续之前向其用户报告此情况。用户代理可以区分看似较小的变化（“example.com”和“sip.example.com”之间的差异）和较大的变化（'example.com'vs。
'example.org') when reporting these discrepancies in order to give the user some idea of how to handle this situation. Analysis and comparison of the Date, Call-ID, and Contact header fields as described in Section 10 MUST also be performed. Any discrepancies or violations MUST be reported to the user.
“example.org”）报告这些差异，以便让用户了解如何处理这种情况。还必须对第10节中所述的日期、呼叫ID和联系人标题字段进行分析和比较。必须向用户报告任何差异或违规情况。
When the originating user agent of a request receives a response containing an AIB, it SHOULD compare the identity in the From header field of the AIB of the response with the original value of the To header field in the request. If these represent different identities, the user agent SHOULD render the identity in the AIB of the response to its user. Note that a discrepancy in these identity fields is not necessarily an indication of a security breach; normal re-targeting may simply have directed the request to a different final destination. Implementors therefore may consider it unnecessary to alert the user of a security violation in this case.
当请求的原始用户代理收到包含AIB的响应时，它应该将响应的AIB的From头字段中的标识与请求中的To头字段的原始值进行比较。如果这些表示不同的标识，则用户代理应在响应的AIB中向其用户呈现标识。请注意，这些标识字段中的差异不一定表示存在安全漏洞；正常的重新定位可能只是将请求定向到不同的最终目的地。因此，在这种情况下，实现者可能认为不必要警告用户违反安全性。
Many SIP entities that support the use of S/MIME for signatures also support S/MIME encryption, as described in RFC 3261, Section 23.4.3.
许多支持将S/MIME用于签名的SIP实体也支持S/MIME加密，如RFC 3261第23.4.3节所述。
While encryption of AIBs entails that only the holder of a specific key can decrypt the body, that single key could be distributed throughout a network of hosts that exist under common policies. The security of the AIB is therefore predicated on the secure distribution of the key. However, for some networks (in which there are federations of trusted hosts under a common policy), the widespread distribution of a decryption key could be appropriate. Some telephone networks, for example, might require this model.
虽然AIB的加密要求只有特定密钥的持有者才能解密主体，但单个密钥可以分布在公共策略下存在的主机网络中。因此，AIB的安全性取决于密钥的安全分发。但是，对于某些网络（其中存在受信任主机的联合体，采用共同策略），解密密钥的广泛分发可能是合适的。例如，一些电话网络可能需要这种型号。
When an AIB is encrypted, the AIB SHOULD be encrypted before it is signed. Implementations MUST still accept AIBs that have been signed and then encrypted.
对AIB进行加密时，AIB应在签名之前进行加密。实现仍然必须接受已签名然后加密的AIB。
The following is an example of an encrypted and signed AIB (without any of the preceding SIP headers). In a rendition of this body sent over the wire, the text wrapped in asterisks would be in ciphertext.
以下是加密和签名AIB的示例（没有任何前面的SIP头）。在通过电线发送的该主体的格式副本中，用星号包裹的文本将是密文。
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
Content-Disposition: aib; handling=optional
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
Content-Disposition: aib; handling=optional
--boundary42
--边界42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
handling=required
Content-Length: 231
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
handling=required
Content-Length: 231
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* From: sip:alice@example.com *
* Call-ID: a84b4c76e66710 *
* Contact: sip:alice@device21.example.com *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
***********************************************************
***********************************************************
* Content-Type: message/sipfrag *
* Content-Disposition: aib; handling=optional *
* *
* From: sip:alice@example.com *
* Call-ID: a84b4c76e66710 *
* Contact: sip:alice@device21.example.com *
* Date: Thu, 21 Feb 2002 13:02:03 GMT *
***********************************************************
--boundary42
--边界42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
Ghyhhhhhhhhhhhhhhhhhhjhjh77n8hghtrfvbnj756tb9hg4vqpfyf467ghighfyt6 4vqpfyf467ghighfyt6jhhhhhhhhhhhhhhhhhhhhhjhjh756tb9hgtrffbnj n8hghtrfvhhhhhhhhhhhhhj776bb9hg4vqbnj7567ghigfyfyfyfyfyf4 7ghigff
--boundary42--
--边界42--
The purpose of an AIB is to provide an identity for the sender of a SIP message. This identity is held in the From header field of an AIB. While other headers are also included, they are provided solely to assist in detection of replays and cut-and-paste attacks leveraged to impersonate the caller. The contents of the From header field of a valid AIB are suitable for display as a "Caller ID" for the sender of the SIP message.
AIB的目的是为SIP消息的发送者提供身份。此标识保存在AIB的From标头字段中。虽然还包括其他头文件，但提供这些头文件的唯一目的是帮助检测重播和利用剪切粘贴攻击来模拟调用者。有效AIB的From头字段的内容适合作为SIP消息发送方的“呼叫者ID”显示。
This document mandates the inclusion of the Contact, Date, Call-ID, and From header fields within an AIB, and recommends the inclusion of CSeq and To header fields, when 'message/sipfrag' is used to represent the identity of a request's sender. If these headers are omitted, some important security properties of AIB are lost. In general, the considerations related to the inclusion of various headers in an AIB are the same as those given in RFC 3261 for
本文件要求在AIB中包含联系人、日期、呼叫ID和发件人标头字段，并建议在使用“message/sipfrag”表示请求发件人身份时，包含CSeq和To标头字段。如果省略这些头，AIB的一些重要安全属性将丢失。一般来说，与AIB中包含各种头相关的注意事项与RFC 3261中针对AIB给出的注意事项相同
including headers in tunneled 'message/sip' MIME bodies (see Section 23 in particular).
包括隧道“消息/sip”MIME主体中的头（具体参见第23节）。
The From header field indicates the identity of the sender of the message; were this header to be excluded, the creator of the AIB essentially would not be asserting an identity at all. The Date and Contact headers provide reference integrity and replay protection, as described in RFC 3261, Section 23.4.2. Implementations of this specification MUST follow the rules for acceptance of the Date header field in tunneled 'message/sip' requests described in RFC 3261, Section 23.4.2; this ensures that outdated AIBs will not be replayed (the suggested interval is that the Date header must indicate a time within 3600 seconds of the receipt of a message). Implementations MUST also record Call-IDs received in AIBs, and MUST remember those Call-IDs for at least the duration of a single Date interval (i.e., 3600 seconds). Accordingly, if an AIB is replayed within the Date interval, receivers will recognize that it is invalid because of a Call-ID duplication; if an AIB is replayed after the Date interval, receivers will recognize that it is invalid because the Date is stale. The Contact header field is included to tie the AIB to a particular device instance that generated the request. Were an active attacker to intercept a request containing an AIB, and cut-and-paste the AIB into their own request (reusing the From, Contact, Date, and Call-ID fields that appear in the AIB), they would not be eligible to receive SIP requests from the called user agent, since those requests are routed to the URI identified in the Contact header field.
发件人标头字段指示消息发件人的身份；如果排除此头，AIB的创建者基本上不会声明任何身份。日期和联系人标头提供参考完整性和重播保护，如RFC 3261第23.4.2节所述。本规范的实施必须遵循RFC 3261第23.4.2节中所述的隧道“消息/sip”请求中日期标头字段的接受规则；这可确保过时的AIB不会被重播（建议的间隔是日期标头必须指示收到消息后3600秒内的时间）。实现还必须记录AIB中接收到的调用ID，并且必须至少在单个日期间隔（即3600秒）内记住这些调用ID。因此，如果在该日期间隔内重播AIB，则接收机将识别出它由于呼叫ID重复而无效；如果在日期间隔后重播AIB，则接收者将认识到该AIB无效，因为该日期已过时。Contact header字段用于将AIB绑定到生成请求的特定设备实例。如果主动攻击者拦截包含AIB的请求，并将AIB剪切并粘贴到他们自己的请求中（重用AIB中出现的From、Contact、Date和Call ID字段），他们将没有资格接收来自被叫用户代理的SIP请求，因为这些请求被路由到Contact header字段中标识的URI。
The To and CSeq header fields provide properties that are generally useful, but not for all possible applications of AIBs. If a new AIB is issued each time a new SIP transaction is initiated in a dialog, the CSeq header field provides a valuable property (replay protection for this particular transaction). If, however, one AIB is used for an entire dialog, subsequent transactions in the dialog would use the same AIB that appeared in the INVITE transaction. Using a single AIB for an entire dialog reduces the load on the generator of the AIB. The To header field usually designates the original URI that the caller intended to reach, and therefore it may vary from the Request-URI if re-targeting occurs at some point in the network. Accordingly, including the To header field in the AIB helps to identify cut-and-paste attacks in which an AIB sent to a particular destination is re-used to impersonate the sender to a different destination. However, the inclusion of the To header field probably would not make sense for many third-party AIB cases (as described in Section 4), nor is its inclusion necessary for responses.
To和CSeq头字段提供的属性通常很有用，但并不适用于AIB的所有可能应用。如果每次在对话框中启动新的SIP事务时都发出新的AIB，则CSeq头字段将提供有价值的属性（此特定事务的重播保护）。但是，如果一个AIB用于整个对话框，则对话框中的后续事务将使用INVITE事务中出现的相同AIB。对整个对话框使用单个AIB可以减少AIB生成器上的负载。To header字段通常指定调用者想要到达的原始URI，因此如果在网络中的某个点发生重新定位，则它可能与请求URI不同。因此，在AIB中包含To header字段有助于识别剪切粘贴攻击，其中发送到特定目的地的AIB被重新用于模拟发送到不同目的地的发送者。但是，对于许多第三方AIB案例（如第4节所述），包含“收件人”标题字段可能没有意义，也没有必要将其包含在响应中。
This document defines a new MIME Content-Disposition disposition-type value of 'aib'. This value is reserved for MIME bodies that contain an authenticated identity, as described in section Section 2.
此文档定义了一个新的MIME内容处置类型值“aib”。如第2节所述，此值保留给包含经过身份验证的标识的MIME主体。
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[3] Troost，R.，Dorner，S.，和K.Moore，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年8月。
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[4] Sparks，R.，“互联网媒体类型信息/sipfrag”，RFC 3420，2002年11月。
[5] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[5] Sparks，R.，“机制引用的会话启动协议（SIP）”，RFC 38922004年9月。
[6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[6] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
The author would like to thank Robert Sparks, Jonathan Rosenberg, Mary Watson, and Eric Rescorla for their comments. Rohan Mahy also provided some valuable guidance.
作者要感谢Robert Sparks、Jonathan Rosenberg、Mary Watson和Eric Rescorla的评论。Rohan Mahy也提供了一些有价值的指导。
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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/S HE 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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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编辑功能的资金目前由互联网协会提供。