Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8224 NeuStar
Obsoletes: 4474 C. Jennings
Category: Standards Track Cisco
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
C. Wendt
Comcast
February 2018
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8224 NeuStar
Obsoletes: 4474 C. Jennings
Category: Standards Track Cisco
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
C. Wendt
Comcast
February 2018
Authenticated Identity Management in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中的身份验证管理
Abstract
摘要
The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.
会话发起协议（SIP）中的基线安全机制不足以以加密方式确保发起SIP请求的最终用户的身份，尤其是在域间上下文中。本文档定义了一种安全识别SIP请求发起人的机制。它通过定义SIP报头字段来实现，该字段用于传递用于验证身份和传递对签名者凭证的引用的签名。
This document obsoletes RFC 4474.
本文件淘汰了RFC 4474。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8224.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8224.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Architectural Overview ..........................................5
4. Identity Header Field Syntax ....................................7
4.1. PASSporT Construction ......................................8
4.1.1. Example Full and Compact Forms of PASSporT
in Identity ........................................10
5. Example of Operations ..........................................11
5.1. Example Identity Header Construction ......................13
6. Signature Generation and Validation ............................14
6.1. Authentication Service Behavior ...........................14
6.1.1. Handling Repairable Errors .........................16
6.2. Verifier Behavior .........................................17
6.2.1. Authorization of Requests ..........................19
6.2.2. Failure Response Codes Sent by a
Verification Service ...............................19
6.2.3. Handling Retried Requests ..........................21
6.2.4. Handling the Full Form of PASSporT .................21
7. Credentials ....................................................22
7.1. Credential Use by the Authentication Service ..............22
7.2. Credential Use by the Verification Service ................23
7.3. "info" Parameter URIs .....................................24
7.4. Credential System Requirements ............................25
8. Identity Types .................................................26
8.1. Differentiating Telephone Numbers from URIs ...............26
8.2. Authority for Telephone Numbers ...........................27
8.3. Telephone Number Canonicalization Procedures ..............28
8.4. Authority for Domain Names ................................29
8.5. URI Normalization .........................................30
9. Extensibility ..................................................31
10. Backwards Compatibility with RFC 4474 .........................32
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Architectural Overview ..........................................5
4. Identity Header Field Syntax ....................................7
4.1. PASSporT Construction ......................................8
4.1.1. Example Full and Compact Forms of PASSporT
in Identity ........................................10
5. Example of Operations ..........................................11
5.1. Example Identity Header Construction ......................13
6. Signature Generation and Validation ............................14
6.1. Authentication Service Behavior ...........................14
6.1.1. Handling Repairable Errors .........................16
6.2. Verifier Behavior .........................................17
6.2.1. Authorization of Requests ..........................19
6.2.2. Failure Response Codes Sent by a
Verification Service ...............................19
6.2.3. Handling Retried Requests ..........................21
6.2.4. Handling the Full Form of PASSporT .................21
7. Credentials ....................................................22
7.1. Credential Use by the Authentication Service ..............22
7.2. Credential Use by the Verification Service ................23
7.3. "info" Parameter URIs .....................................24
7.4. Credential System Requirements ............................25
8. Identity Types .................................................26
8.1. Differentiating Telephone Numbers from URIs ...............26
8.2. Authority for Telephone Numbers ...........................27
8.3. Telephone Number Canonicalization Procedures ..............28
8.4. Authority for Domain Names ................................29
8.5. URI Normalization .........................................30
9. Extensibility ..................................................31
10. Backwards Compatibility with RFC 4474 .........................32
11. Privacy Considerations ........................................32
12. Security Considerations .......................................34
12.1. Protected Request Fields .................................34
12.1.1. Protection of the To Header and Retargeting .......36
12.2. Unprotected Request Fields ...............................37
12.3. Malicious Removal of Identity Headers ....................37
12.4. Securing the Connection to the Authentication Service ....38
12.5. Authorization and Transitional Strategies ................39
12.6. Display-Names and Identity ...............................40
13. IANA Considerations ...........................................40
13.1. SIP Header Fields ........................................40
13.2. SIP Response Codes .......................................41
13.3. Identity-Info Parameters .................................41
13.4. Identity-Info Algorithm Parameter Values .................41
14. Changes from RFC 4474 .........................................41
15. References ....................................................42
15.1. Normative References .....................................42
15.2. Informative References ...................................43
Acknowledgments ...................................................46
Authors' Addresses ................................................46
11. Privacy Considerations ........................................32
12. Security Considerations .......................................34
12.1. Protected Request Fields .................................34
12.1.1. Protection of the To Header and Retargeting .......36
12.2. Unprotected Request Fields ...............................37
12.3. Malicious Removal of Identity Headers ....................37
12.4. Securing the Connection to the Authentication Service ....38
12.5. Authorization and Transitional Strategies ................39
12.6. Display-Names and Identity ...............................40
13. IANA Considerations ...........................................40
13.1. SIP Header Fields ........................................40
13.2. SIP Response Codes .......................................41
13.3. Identity-Info Parameters .................................41
13.4. Identity-Info Algorithm Parameter Values .................41
14. Changes from RFC 4474 .........................................41
15. References ....................................................42
15.1. Normative References .....................................42
15.2. Informative References ...................................43
Acknowledgments ...................................................46
Authors' Addresses ................................................46
This document provides enhancements to the existing mechanisms for authenticated identity management in the Session Initiation Protocol (SIP) [RFC3261]. An identity, for the purposes of this document, is defined as either
本文档增强了会话启动协议（SIP）[RFC3261]中现有的身份验证管理机制。就本文件而言，身份定义为：
o a canonical address-of-record (AoR) SIP URI employed to reach a user (such as "sip:alice@atlanta.example.com") or
o 用于到达用户的规范记录地址（AoR）SIPURI（如“SIP:alice@atlanta.example.com）或
o a telephone number, which commonly appears either in a tel URI [RFC3966] or as the user portion of a SIP URI.
o 一种电话号码，通常出现在电话URI[RFC3966]中或作为SIP URI的用户部分。
[RFC3261] specifies several places within a SIP request where users can express an identity for themselves, most prominently the user-populated From header field. However, in the absence of some sort of cryptographic authentication mechanism, the recipient of a SIP request has no way to verify that the From header field has been populated appropriately. This leaves SIP vulnerable to a category of abuses such as impersonation attacks that facilitate or enable robocalling, voicemail hacking, swatting, and related problems as described in [RFC7340]. Ideally, a cryptographic approach to identity can provide a much stronger assurance of identity than the Caller ID services that the telephone network provides today, and one less vulnerable to spoofing.
[RFC3261]指定SIP请求中的几个位置，用户可以在这些位置为自己表达身份，最突出的是从标头字段填充的用户。但是，在缺少某种加密身份验证机制的情况下，SIP请求的接收者无法验证From标头字段是否已正确填充。这使得SIP容易受到一类滥用行为的攻击，例如模拟攻击，这些攻击会促进或导致机器人定位、语音邮件黑客、打击和[RFC7340]中所述的相关问题。理想情况下，与电话网络目前提供的来电显示服务相比，身份加密方法可以提供更强的身份保证，并且不易受到欺骗。
[RFC3261] encourages user agents (UAs) to implement a number of potential authentication mechanisms, including Digest authentication, Transport Layer Security (TLS), and S/MIME (implementations may support other security schemes as well). However, few SIP UAs today support the end-user certificates necessary to authenticate themselves (via S/MIME, for example), and for its part Digest authentication is limited by the fact that the originator and destination must share a prearranged secret. Practically speaking, originating UAs need to be able to securely communicate their users' identities to destinations with which they have no previous association.
[RFC3261]鼓励用户代理（UAs）实现许多潜在的身份验证机制，包括摘要身份验证、传输层安全性（TLS）和S/MIME（实现也可能支持其他安全方案）。然而，目前很少有SIP UA支持对自身进行身份验证所需的最终用户证书（例如，通过S/MIME），而摘要身份验证则受到以下事实的限制：发起者和目的地必须共享预先安排的秘密。实际上，始发UAs需要能够安全地将其用户的身份传达给他们之前没有关联的目的地。
As an initial attempt to address this gap, [RFC4474] specified a means of signing portions of SIP requests in order to provide an identity assurance. However, [RFC4474] was in several ways misaligned with deployment realities (see [SIP-RFC4474-CONCERNS]). Most significantly, [RFC4474] did not deal well with telephone numbers as identifiers, despite their enduring use in SIP deployments. [RFC4474] also provided a signature over material that intermediaries in existing deployments commonly altered. This specification therefore deprecates the syntax and behavior specified by [RFC4474], reconsidering the problem space in light of the threat model in [RFC7375] and aligning the signature format with PASSporT (Personal Assertion Token) [RFC8225]. Backwards-compatibility considerations are given in Section 10.
作为解决这一差距的初始尝试，[RFC4474]指定了对SIP请求的部分进行签名的方法，以提供身份保证。然而，[RFC4474]在若干方面与部署现实不符（请参见[SIP-RFC4474-1]）。最重要的是，[RFC4474]没有很好地处理电话号码作为标识符，尽管它们在SIP部署中长期使用。[RFC4474]还提供了对现有部署中的中介机构通常更改的材料的签名。因此，本规范反对[RFC4474]规定的语法和行为，根据[RFC7375]中的威胁模型重新考虑问题空间，并将签名格式与PASSporT（个人断言令牌）[RFC8225]对齐。第10节给出了向后兼容性注意事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14[RFC2119]中的说明进行解释。
In addition, this document uses three terms specific to the mechanism:
此外，本文件使用了机制特有的三个术语：
o Identity: An identifier for the user of a communications service; for the purposes of SIP, either a SIP URI or a telephone number. Identities are derived from an "identity field" in a SIP request such as the From header field.
o 标识：通信服务用户的标识符；对于SIP，可以是SIP URI或电话号码。标识来自SIP请求中的“标识字段”，如from标头字段。
o Authentication Service: A logical role played by a SIP entity that adds Identity headers to SIP requests.
o 身份验证服务：由SIP实体扮演的逻辑角色，它向SIP请求添加标识头。
o Verification Service (or "Verifier"): A logical role played by a SIP entity that validates Identity headers in a SIP request.
o 验证服务（或“验证器”）：由SIP实体扮演的逻辑角色，用于验证SIP请求中的标识头。
The identity architecture for SIP defined in this specification depends on a logical "authentication service" that validates outgoing requests. An authentication service may be implemented either as part of a UA or as a proxy server; typically, it is a component of a network intermediary like a proxy to which originating UAs send unsigned requests. Once the originator of the message has been authenticated, through prearranged means with the authentication service, the authentication service then creates and adds an Identity header field to the request. This requires computing cryptographic information -- including a digital signature over some components of messages -- that lets other SIP entities verify that the sending user has been authenticated and its claim of a particular identity has been authorized. These "verification services" validate the signature and enable policy decisions to be made based on the results of the validation.
本规范中定义的SIP标识体系结构依赖于验证传出请求的逻辑“身份验证服务”。认证服务可以作为UA的一部分或作为代理服务器来实现；通常，它是网络中介的一个组件，类似于原始UAs向其发送未签名请求的代理。一旦消息的发起人通过预先安排的方式通过身份验证服务进行了身份验证，身份验证服务就会创建一个标识头字段并将其添加到请求中。这需要计算加密信息——包括消息某些组件上的数字签名——让其他SIP实体验证发送用户是否已通过身份验证，其特定身份的声明是否已获得授权。这些“验证服务”验证签名，并根据验证结果做出策略决策。
Policy decisions made after validation depend heavily on the verification service's trust for the credentials that the authentication service uses to sign requests. As robocalling, voicemail hacking, and swatting usually involve impersonation of telephone numbers, credentials that will be trusted by relying parties to sign for telephone numbers are a key component of the architecture. Authority over telephone numbers is, however, not as easy to establish on the Internet as authority over traditional domain names. This document assumes the existence of credentials for establishing authority over telephone numbers for cases where the telephone number is the identity of the user, but does not mandate or specify a credential system; [RFC8226] describes a credential system compatible with this architecture.
验证后做出的策略决策在很大程度上取决于验证服务对身份验证服务用于签署请求的凭据的信任。由于机器人呼叫、语音邮件黑客攻击和打击通常涉及电话号码的模拟，信任方可以信任的凭证来签署电话号码是该体系结构的关键组成部分。然而，在互联网上建立对电话号码的权威并不像建立对传统域名的权威那样容易。本文件假设在电话号码是用户身份的情况下，存在建立电话号码权限的凭证，但未授权或指定凭证系统；[RFC8226]描述了与此体系结构兼容的凭证系统。
Although addressing the vulnerabilities in the Secure Telephone Identity Revisited (STIR) problem statement [RFC7340] and threat model mostly requires dealing with telephone number as identities, SIP must also handle signing for SIP URIs as identities. This is typically easier to deal with, as these identities are issued by organizations that have authority over Internet domains. When a new user becomes associated with example.com, for example, the administrator of the SIP service for that domain can issue them an identity in that namespace, such as sip:alice@example.com. Alice may then send REGISTER requests to example.com that make her UAs eligible to receive requests for sip:alice@example.com. In other cases, Alice may herself be the owner of her own domain and may issue herself identities as she chooses. But ultimately, it is the controller of the SIP service at example.com that must be responsible for authorizing the use of names in the example.com domain. Therefore, for the purposes of SIP as defined in [RFC3261], the necessary
尽管解决安全电话身份重访（STIR）问题声明[RFC7340]和威胁模型中的漏洞主要需要将电话号码作为身份进行处理，但SIP还必须将SIP URI作为身份进行签名。这通常更容易处理，因为这些身份是由拥有Internet域权限的组织发布的。例如，当新用户与example.com关联时，该域的SIP服务的管理员可以在该命名空间中向他们颁发一个标识，例如SIP:alice@example.com. Alice随后可能会向example.com发送注册请求，使其UAs有资格接收sip请求：alice@example.com. 在其他情况下，Alice自己可能是自己域名的所有者，并且可以根据自己的选择发布自己的身份。但最终，example.com上SIP服务的控制器必须负责授权example.com域中名称的使用。因此，对于[RFC3261]中定义的SIP，必要的
credentials needed to prove that a user is authorized to use a particular From header field must ultimately derive from the domain owner: either (1) a UA gives requests to the domain name owner in order for them to be signed by the domain owner's credentials or (2) the UA must possess credentials that prove that the domain owner has given the UA the right to a name.
证明用户有权使用特定From标头字段所需的凭据最终必须来自域所有者：要么（1）UA向域名所有者发出请求，以便由域所有者的凭据签名，要么（2）UA必须拥有证明域所有者已授予UA名称权的凭据。
In order to share a cryptographic assurance of end-user SIP identity in an interdomain or intradomain context, an authentication service constructs tokens based on the PASSporT format [RFC8225], which is special encoding of a JSON [RFC8259] object comprising values derived from certain header field values in the SIP request. The authentication service computes a signature over those JSON elements as PASSporT specifies. An encoding of the resulting PASSporT is then placed in the SIP Identity header field. In order to assist in the validation of the Identity header field, this specification also describes a parameter of the Identity header field that can be used by the recipient of a request to recover the credentials of the signer.
为了在域间或域内上下文中共享最终用户SIP身份的加密保证，身份验证服务基于PASSporT格式[RFC8225]构造令牌，PASSporT格式[RFC8225]是JSON[RFC8259]对象的特殊编码，包括从SIP请求中的某些头字段值派生的值。身份验证服务按照PASSporT指定的方式在这些JSON元素上计算签名。然后将生成的PASSporT的编码放在SIP标识头字段中。为了帮助验证标识头字段，本规范还描述了标识头字段的一个参数，请求的接收者可以使用该参数来恢复签名者的凭据。
Note that the scope of this document is limited to providing an identity assurance for SIP requests; solving this problem for SIP responses is outside the scope of this work (see [RFC4916]). Future work might specify ways that a SIP implementation could gateway PASSporTs to other protocols.
注意，本文件的范围仅限于为SIP请求提供身份保证；为SIP响应解决此问题不在本工作范围内（请参阅[RFC4916]）。未来的工作可能会指定SIP实现将护照网关到其他协议的方式。
The Identity and Identity-Info header fields that were previously defined in [RFC4474] are deprecated by this document. This revised specification collapses the grammar of Identity-Info into the Identity header field via the "info" parameter. Note that unlike the prior specification in [RFC4474], the Identity header field is now allowed to appear more than one time in a SIP request. The revised grammar for the Identity header field builds on the ABNF [RFC5234] in [RFC3261], Section 25. It is as follows:
本文档不推荐以前在[RFC4474]中定义的标识和标识信息标题字段。此修订规范通过“Info”参数将Identity Info的语法折叠到Identity header字段中。请注意，与[RFC4474]中先前的规范不同，现在允许标识头字段在SIP请求中出现多次。修改后的标识头字段语法以[RFC3261]第25节中的ABNF[RFC5234]为基础。详情如下:
Identity = "Identity" HCOLON signed-identity-digest SEMI
ident-info *( SEMI ident-info-params )
signed-identity-digest = 1*(base64-char / ".")
ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-type /
ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-type = "ppt" EQUAL token
ident-info-extension = generic-param
Identity = "Identity" HCOLON signed-identity-digest SEMI
ident-info *( SEMI ident-info-params )
signed-identity-digest = 1*(base64-char / ".")
ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-type /
ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-type = "ppt" EQUAL token
ident-info-extension = generic-param
base64-char = ALPHA / DIGIT / "/" / "+"
base64-char = ALPHA / DIGIT / "/" / "+"
In addition to the "info" parameter, and the "alg" parameter previously defined in [RFC4474], this specification defines the optional "ppt" parameter (PASSporT Type). The "absoluteURI" portion of ident-info-uri MUST contain a URI; see Section 7.3 for more on choosing how to advertise credentials through this parameter.
除了[RFC4474]中先前定义的“info”参数和“alg”参数外，本规范还定义了可选的“ppt”参数（护照类型）。标识信息uri的“绝对uri”部分必须包含一个uri；有关如何通过此参数播发凭据的更多信息，请参见第7.3节。
The signed-identity-digest contains a base64 encoding of a PASSporT [RFC8225], which secures the request with a signature that PASSporT generates over the JSON header and payload objects; some of those header and claim element values will mirror values of the SIP request.
签名的身份摘要包含PASSporT[RFC8225]的base64编码，它使用PASSporT在JSON头和有效负载对象上生成的签名来保护请求；其中一些头元素和声明元素值将镜像SIP请求的值。
For SIP implementations to populate the PASSporT header JSON object with fields from a SIP request, the following elements MUST be placed as the values corresponding to the designated JSON keys:
对于要使用SIP请求中的字段填充PASSporT头JSON对象的SIP实现，必须将以下元素作为与指定JSON键对应的值：
o First, per the baseline PASSporT specification [RFC8225], the JSON "typ" key MUST have the value "passport".
o 首先，根据基线PASSporT规范[RFC8225]，JSON“typ”键必须具有值“PASSporT”。
o Second, the JSON key "alg" MUST mirror the value of the optional "alg" parameter in the SIP Identity header field. Note that if the "alg" parameter is absent from the Identity header, the default value is "ES256".
o 其次，JSON密钥“alg”必须镜像SIP标识头字段中可选的“alg”参数的值。请注意，如果标识标头中没有“alg”参数，则默认值为“ES256”。
o Third, the JSON key "x5u" MUST have a value equivalent to the quoted URI in the "info" parameter, per the simple string comparison rules of [RFC3986], Section 6.2.1.
o 第三，根据[RFC3986]第6.2.1节的简单字符串比较规则，JSON键“x5u”必须具有一个与“info”参数中引用的URI相等的值。
o Fourth, if a PASSporT extension is in use, then the optional JSON key "ppt" MUST be present and have a value equivalent to the quoted value of the "ppt" parameter of the Identity header field.
o 第四，如果正在使用PASSporT扩展，那么可选的JSON键“ppt”必须存在，并且具有与Identity header字段的“ppt”参数的引用值相等的值。
An example of the PASSporT header JSON object without any extension is:
无任何扩展名的PASSporT头JSON对象示例如下：
{ "typ":"passport",
"alg":"ES256",
"x5u":"https://www.example.com/cert.cer" }
{ "typ":"passport",
"alg":"ES256",
"x5u":"https://www.example.com/cert.cer" }
To populate the PASSporT payload JSON object from a SIP request, the following elements MUST be placed as values corresponding to the designated JSON keys:
要从SIP请求填充PASSporT payload JSON对象，必须将以下元素作为与指定JSON键对应的值放置：
o First, the JSON "orig" object MUST be populated. If the originating identity is a telephone number, then the array MUST be populated with a JSON object containing a "tn" element with a value set to the value of the quoted originating identity, a canonicalized telephone number (see Section 8.3). Otherwise, the object MUST be populated with a JSON object containing a "uri" element, set to the value of the AoR of the UA sending the message as taken from the addr-spec of the From header field, per the procedures in Section 8.5.
o 首先，必须填充JSON“orig”对象。如果始发标识是电话号码，则必须使用JSON对象填充数组，该对象包含一个“tn”元素，该元素的值设置为引用的始发标识（规范化电话号码）的值（见第8.3节）。否则，必须使用包含“uri”元素的JSON对象填充该对象，根据第8.5节中的过程，该元素设置为UA发送消息的AoR值，该值取自from头字段的addr规范。
o Second, the JSON "dest" array MUST be populated. If the destination identity is a telephone number, then the array MUST be populated with a JSON object containing a "tn" element with a value set to the value of the quoted destination identity, a canonicalized telephone number (see Section 8.3). Otherwise, the
o 其次，必须填充JSON“dest”数组。如果目的地标识是电话号码，则必须使用JSON对象填充数组，该对象包含一个“tn”元素，该元素的值设置为引用的目的地标识（规范化电话号码）的值（参见第8.3节）。否则
array MUST be populated with a JSON object containing a "uri" element, set to the value of the addr-spec component of the To header field, which is the AoR to which the request is being sent, per the procedures in Section 8.5. Multiple JSON objects are permitted in "dest" for future compatibility reasons.
数组必须填充一个JSON对象，该对象包含一个“uri”元素，该元素设置为to标头字段的addr spec组件的值，根据第8.5节中的过程，该字段是请求发送到的AoR。出于将来的兼容性原因，“dest”中允许多个JSON对象。
o Third, the JSON key "iat" MUST appear. The authentication service SHOULD set the value of "iat" to an encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519], Section 2), though an authentication service MAY set the value of "iat" to its own current clock time. If the authentication service uses its own clock time, then the use of the full form of PASSporT is REQUIRED. In either case, the authentication service MUST NOT generate a PASSporT for a SIP request if the Date header is outside of its local policy for freshness (sixty seconds is RECOMMENDED).
o 第三，必须出现JSON键“iat”。认证服务应将“iat”的值设置为SIP Date头字段的值编码为JSON NumericDate（按照[RFC7519]第2节，作为UNIX时间），尽管认证服务可将“iat”的值设置为其自己的当前时钟时间。如果认证服务使用自己的时钟时间，则需要使用完整形式的PASSporT。在这两种情况下，如果日期头超出其本地新鲜度策略（建议60秒），则身份验证服务不得为SIP请求生成PASSporT。
o Fourth, if the request contains a Session Description Protocol (SDP) message body and if that SDP contains one or more "a=fingerprint" attributes, then the JSON key "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [RFC8225], Section 5.2.2.
o 第四，如果请求包含会话描述协议（SDP）消息体，并且该SDP包含一个或多个“a=fingerprint”属性，则JSON密钥“mky”必须与指纹属性的算法和值（如果它们不同）一起出现，格式遵循[RFC8225]第5.2.2节中给出的格式。
For example:
例如：
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]},
"iat":1443208345 }
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]},
"iat":1443208345 }
For information on the security properties of these SIP message elements and why their inclusion mitigates replay attacks, see Section 12. Note that future extensions to PASSporT could introduce new claims and that further SIP procedures could be required to extract information from the SIP request to populate the values of those claims; see Section 9 of this document.
有关这些SIP消息元素的安全属性的信息，以及包含这些元素可减轻重播攻击的原因，请参阅第12节。请注意，未来对PASSporT的扩展可能会引入新的索赔，可能需要进一步的SIP程序从SIP请求中提取信息，以填充这些索赔的价值；见本文件第9节。
The "orig" and "dest" arrays may contain identifiers of heterogeneous type; for example, the "orig" array might contain a "tn" claim, while the "dest" contains a "uri" claim. Also note that in some cases, the "dest" array may be populated with more than one value. This could, for example, occur when multiple "dest" identities are specified in a meshed conference. Defining how a SIP implementation would align multiple destination identities in PASSporT with such systems is left as a subject for future specifications.
“orig”和“dest”数组可能包含异构类型的标识符；例如，“orig”数组可能包含“tn”声明，而“dest”包含“uri”声明。还要注意，在某些情况下，“dest”数组可能会填充多个值。例如，在网状会议中指定多个“dest”标识时，可能会发生这种情况。定义SIP实现如何将PASSporT中的多个目的地标识与此类系统对齐，这将留待将来的规范讨论。
After these two JSON objects, the header and the payload, have been constructed and base64-encoded, they must each be hashed and signed per [RFC8225], Section 6. The header, payload, and signature components comprise a full PASSporT object. The resulting PASSporT may be carried in SIP in either (1) a full form, which includes the header and payload as well as the signature or (2) a compact form, which only carries the signature per [RFC8225], Section 7. The hashing and signing algorithm is specified by the "alg" parameter of the Identity header field and the mirrored "alg" parameter of PASSporT. All implementations of this specification MUST support the required signing algorithms of PASSporT. At present, there is one mandatory-to-support value for the "alg" parameter: "ES256", as defined in [RFC7519], which connotes an Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 digital signature.
在构建了这两个JSON对象（标头和有效负载）并对其进行base64编码后，必须根据[RFC8225]第6节对它们进行哈希和签名。标头、有效负载和签名组件组成完整的PASSporT对象。产生的护照可以在SIP中以（1）完整形式携带，包括标题和有效载荷以及签名，或者（2）紧凑形式携带，仅根据[RFC8225]第7节携带签名。哈希和签名算法由Identity header字段的“alg”参数和PASSporT的镜像“alg”参数指定。本规范的所有实现必须支持PASSporT所需的签名算法。目前，必须支持[RFC7519]中定义的“alg”参数值：“ES256”，这意味着椭圆曲线数字签名算法（ECDSA）P-256数字签名。
As Appendix F of the JSON Web Signature (JWS) specification [RFC7515] notes, there are cases where "it is useful to integrity-protect content that is not itself contained in a JWS." Since the fields that make up the majority of the PASSporT header and payload have values replicated in the SIP request, the SIP usage of PASSporT may exclude the base64-encoded version of the header and payload JSON objects from the Identity header field and instead present a detached signature: what PASSporT calls its compact form; see [RFC8225], Section 7.
正如JSON Web签名（JWS）规范[RFC7515]的附录F所述，在某些情况下，“完整性保护JWS中不包含的内容非常有用。”因为构成PASSporT头和有效负载大部分的字段在SIP请求中复制了值，PASSporT的SIP使用可能会从Identity header字段中排除标头和有效负载JSON对象的base64编码版本，而是呈现分离的签名：PASSporT称之为其压缩形式；见[RFC8225]，第7节。
When an authentication service constructs an Identity header, the contents of the signed-identity-digest field MUST contain either a full or compact PASSporT. Use of the compact form is RECOMMENDED in order to reduce message size, but note that extensions often require the full form (see Section 9).
当身份验证服务构造身份标头时，签名身份摘要字段的内容必须包含完整或紧凑的PASSporT。建议使用压缩表单以减少消息大小，但请注意，扩展通常需要完整表单（请参阅第9节）。
For example, a full form of PASSporT in an Identity header might look as follows (backslashes shown for line folding only):
例如，身份标头中的完整形式的PASSporT可能如下所示（反斜杠仅用于折线）：
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \
/biloxi.cert>
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \
/biloxi.cert>
The compact form of the same PASSporT object would appear in the Identity header as:
相同PASSporT对象的压缩形式将显示在标识标头中，如下所示：
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \
pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.cert>
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \
pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.cert>
This section provides an informative (non-normative) high-level example of the operation of the mechanisms described in this document.
本节提供了本文件所述机制运行的信息性（非规范性）高级示例。
Imagine a case where Bob, who has the home proxy of example.com and the AoR sip:12155551212@example.com;user=phone, wants to communicate with Alice at sip:alice@example.com. They have no prior relationship, and Alice implements best practices to prevent impersonation attacks.
假设Bob拥有example.com的主代理和AoR sip：12155551212@example.com;用户=电话，希望通过sip与Alice通信：alice@example.com. 它们之间没有优先关系，并且Alice实现了防止模拟攻击的最佳实践。
Bob's UA generates an INVITE and places his AoR in the From header field of the request. He then sends an INVITE to an authentication service proxy for his domain.
Bob的UA生成一个INVITE，并将其AoR放在请求的From头字段中。然后，他向其域的身份验证服务代理发送邀请。
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. Signs for | | . Signed . | | .
. 12125551xxx| Auth |------------> | Verif | .
. | Svc | . INVITE . | Svc | .
. | Proxy | . . | Proxy | .
. > +-------+ . . +-------+ \ .
. / | . -> \ .
. / | . --. \ .
. / | . -- . \ .
. / | . -- . \ .
. / +-------+. -- . \ .
. / | |.<- . \ .
. / | Cert |. . > .
. +-------+ | Store |. . +-------+ .
. | | | |. . | | .
. | Bob | +-------+. . | Alice | .
. | UA | . . | UA | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. Signs for | | . Signed . | | .
. 12125551xxx| Auth |------------> | Verif | .
. | Svc | . INVITE . | Svc | .
. | Proxy | . . | Proxy | .
. > +-------+ . . +-------+ \ .
. / | . -> \ .
. / | . --. \ .
. / | . -- . \ .
. / | . -- . \ .
. / +-------+. -- . \ .
. / | |.<- . \ .
. / | Cert |. . > .
. +-------+ | Store |. . +-------+ .
. | | | |. . | | .
. | Bob | +-------+. . | Alice | .
. | UA | . . | UA | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
The proxy authenticates Bob and validates that he is authorized to assert the identity that he populated in the From header field. The proxy authentication service then constructs a PASSporT that contains a JSON representation of values that mirror certain parts of the SIP request, including the identity in the From header field value. As a part of generating the PASSporT, the authentication service signs a hash of that JSON header and payload with the private key associated with the appropriate credential for the identity (in this example, a certificate with authority to sign for numbers in a range from 12155551000 to 12155551999), and the signature is inserted by the proxy server into the Identity header field value of the request as a compact form of PASSporT. Alternatively, the JSON header and payload themselves might also have been included in the object when using the full form of PASSporT.
代理对Bob进行身份验证，并验证他是否有权断言他在From标头字段中填充的身份。然后，代理身份验证服务构造一个PASSporT，该PASSporT包含反映SIP请求某些部分的值的JSON表示，包括From头字段值中的标识。作为生成PASSporT的一部分，身份验证服务使用与身份的适当凭证相关联的私钥对JSON头和有效负载的哈希进行签名（在本例中，是一个有权对121551000到12155551999范围内的数字进行签名的证书），代理服务器将签名作为紧凑形式的PASSporT插入到请求的Identity header字段值中。或者，当使用完整形式的PASSporT时，JSON头和负载本身也可能包含在对象中。
The proxy authentication service, as the holder of a private key with authority over Bob's telephone number, is asserting that the originator of this request has been authenticated and that he is authorized to claim the identity that appears in the From header field. The proxy inserts an "info" parameter into the Identity header field that tells Alice how to acquire keying material necessary to validate its credentials (a public key), in case she doesn't already have it.
代理身份验证服务作为拥有Bob电话号码权限的私钥持有人，声明此请求的发起人已通过身份验证，并且有权声明“发件人”标题字段中显示的身份。代理在标识头字段中插入一个“info”参数，该参数告诉Alice如何获取验证其凭据（公钥）所需的密钥材料，以防她还没有。
When Alice's domain receives the request, a proxy verification service validates the signature provided in the Identity header field and then determines that the authentication service credentials demonstrate authority over the identity in the From header field. This same validation operation might be performed by a verification service in Alice's UA server (UAS). Ultimately, this valid request is rendered to Alice. If the validation were unsuccessful, some other treatment could be applied by the receiving domain or Alice's UA.
当Alice的域收到请求时，代理验证服务将验证在“标识头”字段中提供的签名，然后确定身份验证服务凭据在“发件人头”字段中显示对标识的权限。同样的验证操作也可以由Alice的UA服务器（UAS）中的验证服务执行。最终，这个有效的请求被提交给Alice。如果验证失败，接收域或Alice的UA可以应用其他一些处理。
For the following SIP request:
对于以下SIP请求：
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551212@gateway.example.com>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551212@gateway.example.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
An authentication service will create a corresponding PASSporT object. The properly serialized PASSporT header and payload JSON objects would look as follows. For the header, the values chosen by the authentication service at "example.com" might read:
身份验证服务将创建相应的PASSporT对象。正确序列化的PASSporT头和负载JSON对象如下所示。对于标头，“example.com”上的身份验证服务选择的值可能为：
{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/
passport.cer"}
{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/
passport.cer"}
The serialized payload will derive values from the SIP request (the From, To, and Date header field values) as follows:
序列化有效负载将从SIP请求中派生值（from、To和Date标头字段值），如下所示：
{"dest":{"uri":["sip:alice@example.com"]},"iat":1443208345,
"orig":{"tn":"12155551212"}}
{"dest":{"uri":["sip:alice@example.com"]},"iat":1443208345,
"orig":{"tn":"12155551212"}}
The authentication service would then generate the signature over the object, following the procedures in [RFC8225], Section 6. That signature would look as follows:
然后，身份验证服务将按照[RFC8225]第6节中的步骤在对象上生成签名。该签名如下：
rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ ojNCpTzO3QfPOlckGaS6hEck7w
RQ3PJT1HORWAKEGJHCNWSWUNSD0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs\ojNCpTzO3QfPOlckGaS6hEck7w
An authentication service signing this request and using the compact form of PASSporT would thus generate and add to the request an Identity header field of the following form:
因此，对该请求进行签名并使用紧凑形式的PASSporT的身份验证服务将生成并向请求中添加以下形式的身份标头字段：
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://cert.example.org/passport.cer>
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://cert.example.org/passport.cer>
SIP entities that instantiate the authentication service and verification service roles will, respectively, generate and validate the Identity header and the signature it contains.
实例化身份验证服务和验证服务角色的SIP实体将分别生成并验证标识头及其包含的签名。
Any entity that instantiates the authentication service role MUST possess the private key of one or more credentials that can be used to sign for a domain or a telephone number (see Section 7.1). The authentication service role can be instantiated, for example, by an intermediary such as a proxy server or by a UA. Intermediaries that instantiate this role MUST be capable of authenticating one or more SIP users who can register for that identity. Commonly, this role will be instantiated by a proxy server, since proxy servers are more likely to have a static hostname, hold corresponding credentials, and have access to SIP registrar capabilities that allow them to authenticate users. It is also possible that the authentication service role might be instantiated by an entity that acts as a redirect server, but that is left as a topic for future work.
任何实例化身份验证服务角色的实体都必须拥有一个或多个凭据的私钥，这些凭据可用于对域或电话号码进行签名（请参见第7.1节）。例如，可以通过诸如代理服务器之类的中介或UA来实例化认证服务角色。实例化此角色的中介体必须能够对一个或多个可以注册该身份的SIP用户进行身份验证。通常，此角色将由代理服务器实例化，因为代理服务器更有可能具有静态主机名、持有相应的凭据，并有权访问允许其对用户进行身份验证的SIP注册器功能。身份验证服务角色也可能由充当重定向服务器的实体实例化，但这将作为未来工作的主题。
An authentication service adds the Identity header field to SIP requests. The procedures below define the steps that must be taken when each Identity header field is added. More than one Identity header field may appear in a single request, and an authentication service may add an Identity header field to a request that already contains one or more Identity header fields.
身份验证服务将标识头字段添加到SIP请求中。下面的过程定义了添加每个标识标头字段时必须采取的步骤。单个请求中可能会出现多个标识头字段，身份验证服务可能会将标识头字段添加到已包含一个或多个标识头字段的请求中。
Entities instantiating the authentication service role perform the following steps, in order, to generate an Identity header field for a SIP request:
实例化身份验证服务角色的实体执行以下步骤，以便为SIP请求生成标识头字段：
Step 1: Check Authority for the Identity
步骤1：检查身份的权限
First, the authentication service must determine whether it is authoritative for the identity of the originator of the request. The authentication service extracts the identity from the URI value from the "identity field"; in ordinary operations, that is the addr-spec component of the From header field. In order to determine whether
首先，身份验证服务必须确定它是否对请求发起人的身份具有权威性。认证服务从“标识字段”的URI值中提取标识；在普通操作中，这是From标头字段的addr spec组件。为了确定
the signature for the identity field should be over the entire identity field URI or just a telephone number, the authentication service MUST follow the process described in Section 8.1. The information in that section will lead to either the telephone number canonicalization procedures in Section 8.3 for telephone numbers or the URI normalization procedures described in Section 8.5 for domain names. Whichever the result, if the authentication service is not authoritative for the identity in question, it SHOULD process and forward the request normally unless the local policy is to block such requests. The authentication service MUST NOT add an Identity header field if the authentication service does not have the authority to make the claim it asserts.
身份字段的签名应覆盖整个身份字段URI或一个电话号码，身份验证服务必须遵循第8.1节中描述的流程。该节中的信息将导致第8.3节中关于电话号码的电话号码规范化程序或第8.5节中关于域名的URI规范化程序。无论结果如何，如果身份验证服务对所讨论的身份不具有权威性，它应该正常处理和转发请求，除非本地策略阻止此类请求。如果身份验证服务没有进行声明的权限，则身份验证服务不得添加标识头字段。
Step 2: Authenticate the Originator
步骤2：验证发起人的身份
The authentication service MUST then determine whether or not the originator of the request is authorized to claim the identity given in the identity field. In order to do so, the authentication service MUST authenticate the originator of the message. Some possible ways in which this authentication might be performed include the following:
然后，身份验证服务必须确定请求的发起人是否有权声明标识字段中给出的标识。为此，身份验证服务必须对消息的原始发件人进行身份验证。执行此身份验证的一些可能方式包括：
o If the authentication service is instantiated by a SIP intermediary (proxy server), it may authenticate the request with the authentication scheme used for registration in its domain (e.g., Digest authentication).
o 如果认证服务由SIP中介（代理服务器）实例化，则它可以使用用于在其域中注册的认证方案（例如，摘要认证）对请求进行认证。
o If the authentication service is instantiated by a SIP UA, a UA may authenticate its own user through any system-specific means, perhaps simply by virtue of having physical access to the UA.
o 如果认证服务由SIP-UA实例化，则UA可以通过任何特定于系统的方式认证其自己的用户，可能仅仅凭借对UA的物理访问。
Authorization of the use of a particular username or telephone number in the user part of the From header field is a matter of local policy for the authentication service; see Section 7.1 for more information.
授权在发件人报头字段的用户部分使用特定用户名或电话号码是认证服务的本地策略问题；更多信息请参见第7.1节。
Note that this check is performed only on the addr-spec in the identity field (e.g., the URI of the originator, like "sip:alice@atlanta.example.com"); it does not cover the display-name portion of the From header field (e.g., "Alice Atlanta"). For more information, see Section 12.6.
请注意，此检查仅在标识字段中的addr规范上执行（例如，发起人的URI，如“sip:alice@atlanta.example.com"); 它不包括From标头字段的显示名称部分（例如，“Alice Atlanta”）。有关更多信息，请参见第12.6节。
Step 3: Verify Date is Present and Valid
步骤3：验证日期是否存在且有效
An authentication service MUST add a Date header field to SIP requests that do not have one. The authentication service MUST ensure that any preexisting Date header field in the request is accurate. Local policy can dictate precisely how accurate the Date must be; a RECOMMENDED maximum discrepancy of sixty seconds will
身份验证服务必须向没有日期头字段的SIP请求添加日期头字段。身份验证服务必须确保请求中任何先前存在的日期头字段都是准确的。当地政策可以精确规定日期的准确性；建议的最大偏差为60秒
ensure that the request is unlikely to upset any verifiers. If the Date header field value contains a time different by more than one minute from the current time noted by the authentication service, the authentication service SHOULD reject the request. Finally, the authentication service MUST verify that both the Date header field and the current time fall within the validity period of its credential.
确保请求不太可能打乱任何验证者。如果日期标头字段值包含的时间与身份验证服务记录的当前时间相差超过一分钟，则身份验证服务应拒绝该请求。最后，身份验证服务必须验证日期标头字段和当前时间是否都在其凭据的有效期内。
See Section 12.1 for information on how the Date header field assists verifiers.
有关日期标题字段如何协助验证者的信息，请参见第12.1节。
Step 4: Populate and Add the Identity Header
步骤4：填充并添加标识标头
Subsequently, the authentication service MUST form a PASSporT object and add a corresponding Identity header field to the request containing either the full or compact form of PASSporT. For the baseline PASSporT header (headers containing no "ppt" parameter), this follows the procedures in Section 4; if the authentication service is using an alternative "ppt" format, it MUST add an appropriate "ppt" parameter and follow the procedures associated with that extension (see Section 9). After the Identity header field has been added to the request, the authentication service MUST also add an "info" parameter to the Identity header field. The "info" parameter contains a URI from which the authentication service's credential can be acquired; see Section 7.3 for more on credential acquisition.
随后，身份验证服务必须形成一个PASSporT对象，并向包含完整或紧凑形式PASSporT的请求添加相应的标识头字段。对于基线PASSporT标头（标头不包含“ppt”参数），这遵循第4节中的程序；如果身份验证服务使用的是替代“ppt”格式，则必须添加适当的“ppt”参数，并遵循与该扩展相关的过程（参见第9节）。在将标识标头字段添加到请求后，身份验证服务还必须向标识标头字段添加“info”参数。“info”参数包含可以从中获取认证服务的凭证的URI；有关凭证获取的更多信息，请参见第7.3节。
An authentication service MAY use the full form of the PASSporT in the Identity header field. The presence of the full form is OPTIONAL because the information carried in the baseline PASSporT headers and claims is usually redundant with information already carried elsewhere in the SIP request. Using the compact form can significantly reduce SIP message size, especially when the PASSporT payload contains media keys. The syntax of the compact form is given in [RFC8225], Section 7; essentially, it contains only the signature component of the PASSporT.
身份验证服务可以在标识标头字段中使用完整形式的PASSporT。完整表单的存在是可选的，因为基线PASSporT头和声明中包含的信息通常与SIP请求中其他地方已经包含的信息是冗余的。使用压缩表单可以显著减少SIP消息大小，特别是当PASSporT负载包含媒体密钥时。[RFC8225]第7节给出了紧凑形式的语法；本质上，它只包含护照的签名部分。
Note that per the behavior specified in [RFC8225], use of the full form is mandatory when optional extensions are included. See Section 9.
请注意，根据[RFC8225]中指定的行为，当包含可选扩展时，必须使用完整表单。见第9节。
Also, in some cases, a request signed by an authentication service will be rejected by the verification service on the receiving side, and the authentication service will receive a SIP 4xx status code in the backwards direction, such as a 438 ("Invalid Identity Header") response indicating a verification failure. If the authentication
此外，在某些情况下，由认证服务签名的请求将被接收方的验证服务拒绝，并且认证服务将接收反向的SIP 4xx状态码，例如438（“无效标识头”）响应，指示验证失败。如果验证失败
service did not originally send the full form of the PASSporT object in the Identity header field, it SHOULD retry the request with the full form after receiving a 438 response; however, implementations SHOULD NOT retry the request more than once. Authentication services implemented at proxy servers would retry such a request as a sequential fork, by reprocessing the destination as a new target and handling it serially as described in Section 16.6 of [RFC3261].
服务最初没有在Identity header字段中发送PASSporT对象的完整表单，它应该在收到438响应后使用完整表单重试请求；但是，实现不应多次重试该请求。在代理服务器上实现的身份验证服务将通过将目标重新处理为新目标并按[RFC3261]第16.6节所述顺序对其进行处理，以顺序分叉的方式重试此类请求。
The information in the full form is useful on the verification side for debugging errors, and there are some known causes of verification failures (such as the Date header field value changing in transit; see Section 12.1 for more information) that can be resolved by the inclusion of the full form of PASSporT.
完整形式的信息在验证方面对调试错误很有用，并且存在一些已知的验证失败原因（例如日期标题字段值在传输过程中发生变化；更多信息，请参见第12.1节），可以通过包含完整形式的PASSporT来解决。
Finally, the authentication service forwards the message normally.
最后，身份验证服务正常转发消息。
This document specifies a logical role for SIP entities; this role is called a verification service, or verifier. When a verifier receives a SIP message containing one or more Identity header fields, it inspects the signature(s) to verify the identity of the originator of the message. The results of a verification are provided as input to an authorization process that is outside the scope of this document.
本文件规定了SIP实体的逻辑角色；此角色称为验证服务或验证器。当验证器接收到包含一个或多个标识头字段的SIP消息时，它会检查签名，以验证消息发起人的标识。验证结果作为输入提供给本文件范围之外的授权流程。
A SIP request may contain zero, one, or more Identity header fields. A verification service performs the steps below on each Identity header field that appears in a request. If a verification service cannot use any Identity header in a request, due to the absence of Identity headers or unsupported "ppt" parameters, and the presence of an Identity header field is required by local policy (for example, based on a per-sending-domain policy or a per-sending-user policy), then a 428 "Use Identity Header" response MUST be sent in the backwards direction. For more on this and other verifier responses, see Section 6.2.2.
SIP请求可以包含零个、一个或多个标识头字段。验证服务对请求中出现的每个标识标头字段执行以下步骤。如果由于缺少标识标头或不支持的“ppt”参数，验证服务无法在请求中使用任何标识标头，并且本地策略要求存在标识标头字段（例如，基于每发送域策略或每发送用户策略），则428“使用标识标头”响应必须反向发送。有关此和其他验证者响应的更多信息，请参见第6.2.2节。
In order to verify an Identity header field in a message, an entity acting as a verifier MUST perform the following steps, in the order specified below. Note that when an Identity header field contains a full-form PASSporT object, the verifier MUST follow the additional procedures in Section 6.2.4.
为了验证消息中的标识标头字段，充当验证器的实体必须按照下面指定的顺序执行以下步骤。请注意，当标识标头字段包含完整形式的PASSporT对象时，验证者必须遵循第6.2.4节中的附加程序。
Step 1: Check for an Unsupported "ppt"
步骤1：检查不支持的“ppt”
The verifier MUST inspect any optional "ppt" parameter appearing in the Identity header. If no "ppt" parameter is present, then the verifier proceeds normally with Steps 2 through 5. If a "ppt" parameter value is present and the verifier does not support it,
验证器必须检查标识标头中出现的任何可选“ppt”参数。如果不存在“ppt”参数，则验证器正常进行步骤2至5。如果存在“ppt”参数值且验证者不支持该值，
it MUST ignore the Identity header field. If a supported "ppt" parameter value is present, the verifier proceeds with Step 2 and will ultimately follow the "ppt" variations described in Step 5.
它必须忽略标识标头字段。如果存在支持的“ppt”参数值，则验证器继续执行步骤2，并最终遵循步骤5中描述的“ppt”变化。
Step 2: Determine the Originator's Identity
步骤2：确定发起人的身份
In order to determine whether the signature for the identity field should be over the entire identity field URI or just a telephone number, the verification service MUST follow the process described in Section 8.1. The information in that section will lead to either the telephone number canonicalization procedures in Section 8.3 for telephone numbers or the URI normalization procedures described in Section 8.5 for domain names.
为了确定标识字段的签名是应覆盖整个标识字段URI还是仅覆盖一个电话号码，验证服务必须遵循第8.1节中描述的流程。该节中的信息将导致第8.3节中关于电话号码的电话号码规范化程序或第8.5节中关于域名的URI规范化程序。
Step 3: Identify Credential for Validation
步骤3：识别用于验证的凭证
The verifier must ensure that it has access to the proper keying material to validate the signature in the Identity header field; this usually involves dereferencing a URI in the "info" parameter of the Identity header field. See Section 7.2 for more information on these procedures. If the verifier does not support the credential described in the "info" parameter, then it treats the credential for this header field as unsupported.
验证者必须确保其能够访问适当的密钥材料，以验证身份标头字段中的签名；这通常涉及取消对标识标头字段的“info”参数中的URI的引用。有关这些程序的更多信息，请参见第7.2节。如果验证器不支持“info”参数中描述的凭证，则它将此标头字段的凭证视为不受支持。
Step 4: Check the Freshness of Date
第四步：检查日期的新鲜度
The verifier furthermore ensures that the value of the Date header field of the request meets local policy for freshness (sixty seconds is RECOMMENDED) and that it falls within the validity period of the credential used to sign the Identity header field. For more on the attacks this prevents, see Section 12.1. If the full form of the PASSporT is present, the verifier SHOULD compare the "iat" value in the PASSporT to the Date header field value in the request. If the two are different, and the "iat" value differs from the Date header field value but remains within verification service policy for freshness, the verification service SHOULD perform the computation required by Step 5, using the "iat" value instead of the Date header field value.
验证器进一步确保请求的日期头字段的值符合本地新鲜度策略（建议为60秒），并且它在用于签名标识头字段的凭证的有效期内。有关这可以防止的攻击的更多信息，请参见第12.1节。如果有完整的护照格式，验证者应将护照中的“iat”值与请求中的日期标题字段值进行比较。如果两者不同，“iat”值与日期标题字段值不同，但仍在验证服务新鲜度政策范围内，则验证服务应使用“iat”值而不是日期标题字段值执行步骤5所需的计算。
Step 5: Validate the Signature
步骤5：验证签名
The verifier MUST validate the signature in the Identity header field over the PASSporT object. For baseline PASSporT objects (with no Identity header field "ppt" parameter), the verifier MUST follow the procedures for generating the signature over a PASSporT object as described in Section 4. If a "ppt" parameter is present (and, per Step 1, is supported), the verifier follows the procedures for that "ppt" (see Section 9). If a verifier determines that the signature
验证者必须在PASSporT对象上验证Identity header字段中的签名。对于基线PASSporT对象（没有标识头字段“ppt”参数），验证者必须遵循第4节中描述的在PASSporT对象上生成签名的过程。如果存在“ppt”参数（并且根据步骤1，受支持），验证者遵循该“ppt”的程序（见第9节）。如果验证器确定签名
in the Identity header field does not correspond to the reconstructed signed-identity-digest, then the Identity header field should be considered invalid.
如果标识头字段与重建的签名标识摘要不对应，则标识头字段应视为无效。
The verification of an Identity header field does not entail any particular treatment of the request. The handling of the message after the verification process depends on how the verification service is implemented and on local policy. This specification does not propose any authorization policy for UAs or proxy servers to follow based on the presence of a valid Identity header field, the presence of an invalid Identity header field, the absence of an Identity header field, or the presence of a stale Date header field value. However, it is anticipated that local policies could involve making different forwarding decisions in intermediary implementations, or changing how the user is alerted or how identity is rendered in UA implementations.
身份标头字段的验证不需要对请求进行任何特殊处理。验证过程后对消息的处理取决于验证服务的实现方式和本地策略。本规范不建议UAs或代理服务器根据存在有效标识标头字段、存在无效标识标头字段、不存在标识标头字段或存在过时日期标头字段值而遵循任何授权策略。然而，预计本地策略可能涉及在中间实现中做出不同的转发决策，或者更改用户收到警报的方式或UA实现中呈现身份的方式。
The presence of multiple Identity header fields within a message raises the prospect that a verification service could receive a message containing both valid and invalid Identity header fields. As a guideline, this specification recommends that only if a verifier determines that all Identity header fields within a message are invalid should the request be considered to have an invalid identity. If at least one Identity header field value is valid and from a trusted source, then relying parties can use that header for authorization decisions regardless of whether other untrusted or invalid Identity headers appear in a request.
消息中存在多个标识头字段可能会导致验证服务接收到同时包含有效和无效标识头字段的消息。作为指导原则，本规范建议仅当验证器确定消息中的所有标识头字段无效时，才应将请求视为具有无效标识。如果至少有一个标识头字段值有效且来自受信任的源，则依赖方可以使用该头进行授权决策，而不管请求中是否出现其他不受信任或无效的标识头。
[RFC4474] originally defined four response codes for failure conditions specific to the Identity header field and its original mechanism. These status codes are retained in this specification, with some slight modifications. Also, this specification details responding with a 403 "Forbidden" response when a stale Date header field value is received; see below.
[RFC4474]最初为特定于标识标头字段及其原始机制的故障条件定义了四个响应代码。这些状态代码保留在本规范中，但作了一些轻微修改。此外，本规范详细说明了当接收到过时的日期头字段值时，使用403“禁止”响应进行响应；见下文。
A 428 response will be sent (per Section 6.2) when an Identity header field is required but no Identity header field without a "ppt" parameter or with a supported "ppt" value has been received. In the case where one or more Identity header fields with unsupported "ppt" values have been received, then a verification service may send a 428 with a human-readable reason phrase like "Use Supported PASSporT Format". Note, however, that this specification gives no guidance on
当需要标识标头字段，但未收到不带“ppt”参数或支持的“ppt”值的标识标头字段时，将发送428响应（根据第6.2节）。在接收到一个或多个带有不受支持的“ppt”值的标识标头字段的情况下，验证服务可发送带有人类可读原因短语（如“使用受支持的PASSporT格式”）的428。但是，请注意，本规范未对以下内容提供指导：
how a verification service might decide to require an Identity header field for a particular SIP request. Such authorization policies are outside the scope of this specification.
验证服务如何决定为特定SIP请求要求标识头字段。此类授权策略不在本规范的范围内。
The 436 "Bad Identity Info" response code indicates an inability to acquire the credentials needed by the verification service for validating the signature in an Identity header field. Again, given the potential presence of multiple Identity header fields, this response code should only be sent when the verification service is unable to dereference the URIs and/or acquire the credentials associated with all Identity header fields in the request. This failure code could be repairable if the authentication service resends the request with an "info" parameter pointing to a credential that the verification service can access.
436“错误标识信息”响应代码表示无法获取验证服务验证标识标头字段中的签名所需的凭据。同样，考虑到可能存在多个标识头字段，仅当验证服务无法取消对URI的引用和/或获取与请求中所有标识头字段相关联的凭据时，才应发送此响应代码。如果身份验证服务使用指向验证服务可以访问的凭据的“info”参数重新发送请求，则此故障代码可以修复。
The 437 "Unsupported Credential" response (previously "Unsupported Certificate"; see Section 13.2) is sent when a verification service can acquire, or already holds, the credential represented by the "info" parameter of at least one Identity header field in the request but does not support said credential(s), for reasons such as failing to trust the issuing certification authority (CA) or failing to support the algorithm with which the credential was signed.
当验证服务可以获取或已经持有由请求中至少一个标识头字段的“info”参数表示的凭证，但不支持所述凭证时，发送437“Unsupported Credential”响应（以前为“Unsupported Certificate”；参见第13.2节），原因包括无法信任颁发证书颁发机构（CA）或无法支持用于签名凭据的算法。
The 438 "Invalid Identity Header" response indicates that of the set of Identity header fields in a request, no header field with a valid and supported PASSporT object has been received. Like the 428 response, this is sent by a verification service when its local policy dictates that a broken signature in an Identity header field is grounds for rejecting a request. Note that in some cases, an Identity header field may be broken for other reasons than that an originator is attempting to spoof an identity: for example, when a transit network alters the Date header field of the request. Sending a full-form PASSporT can repair some of these conditions (see Section 6.2.4), so the recommended way to attempt to repair this failure is to retry the request with the full form of PASSporT if it had originally been sent with the compact form. The alternative reason phrase "Invalid PASSporT" can be used when an extended full-form PASSporT lacks required headers or claims, or when an extended full-form PASSporT signaled with the "ppt" parameter lacks required claims for that extension. Sending a string along these lines will help humans debugging the sending system.
438“Invalid Identity Header”响应表示，在请求中的一组标识标头字段中，没有收到包含有效且受支持的PASSporT对象的标头字段。与428响应一样，当验证服务的本地策略规定身份标头字段中的损坏签名是拒绝请求的理由时，该响应由验证服务发送。请注意，在某些情况下，身份标头字段可能会因发起人试图伪造身份以外的其他原因而被破坏：例如，当公交网络更改请求的日期标头字段时。发送完整形式的PASSporT可以修复其中一些情况（请参见第6.2.4节），因此，尝试修复此故障的建议方法是，如果原始发送的是紧凑形式的PASSporT，则使用完整形式的PASSporT重试请求。当扩展完整格式PASSporT缺少所需的标题或声明时，或者当用“ppt”参数表示的扩展完整格式PASSporT缺少该扩展所需的声明时，可以使用替代原因短语“Invalid PASSporT”。沿着这些线发送字符串将有助于调试发送系统。
Finally, a 403 response may be sent when the verification service receives a request with a Date header field value that is older than the local policy for freshness permits. The same response may be used when the "iat" in the full form of a PASSporT has a value older than the local policy for freshness permits. The reason phrase "Stale Date" can be sent to help humans debug the failure.
最后，当验证服务接收到日期头字段值早于新鲜度许可本地策略的请求时，可以发送403响应。如果完整护照形式的“iat”的值早于当地新鲜度许可政策，则可以使用相同的回答。可以发送原因短语“过时日期”来帮助人类调试故障。
Future specifications may explore ways, including Reason codes or Warning headers, to communicate further information that could be used to disambiguate the source of errors in cases with multiple Identity headers in a single request or to provide similar detailed feedback for debugging purposes.
未来的规范可能会探索各种方法，包括原因码或警告标头，以传达进一步的信息，这些信息可用于在单个请求中具有多个标识标头的情况下消除错误源的歧义，或为调试目的提供类似的详细反馈。
If a verification service sends a failure response in the backwards direction, the authentication service may retry the request as described in Section 6.1.1. If the authentication service is instantiated at a proxy server, then it will retry the request as a sequential fork. Verification services implemented at a proxy server will recognize this request as a spiral rather than a loop due to the proxy behavior fix documented in [RFC5393], Section 4.2. However, if the verification service is implemented in an endpoint, the endpoint will need to override the default UAS behavior (in particular, the SHOULD in [RFC3261], Section 8.2.2.2) to accept this request as a spiral rather than a loop.
如果验证服务向后发送失败响应，则验证服务可按照第6.1.1节所述重试请求。如果身份验证服务是在代理服务器上实例化的，那么它将作为顺序叉重试该请求。由于[RFC5393]第4.2节中记录的代理行为修复，在代理服务器上实现的验证服务将该请求识别为螺旋而不是循环。但是，如果验证服务在端点中实现，端点将需要覆盖默认UAS行为（特别是[RFC3261]第8.2.2.2节中的“应”），以将此请求作为螺旋而不是循环接受。
If the full form of PASSporT is present in an Identity header, this permits the use of optional extensions as described in [RFC8225], Section 8.3. Furthermore, the verification service can extract from the "orig" and "dest" elements of the PASSporT full form the canonical telephone numbers created by the authentication service, as well as an "iat" claim corresponding to the Date header field that the authentication service used. These values may be used to debug canonicalization problems or to avoid unnecessary signature breakage caused by intermediaries that alter certain SIP header field values in transit.
如果完整形式的PASSporT出现在身份标头中，则允许使用[RFC8225]第8.3节中所述的可选扩展名。此外，验证服务可以从PASSporT full form的“orig”和“dest”元素中提取由验证服务创建的规范电话号码，以及与验证服务使用的日期头字段相对应的“iat”声明。这些值可用于调试规范化问题，或避免中间人在传输过程中更改某些SIP头字段值而导致不必要的签名破坏。
However, the verification service MUST NOT treat the value in the "orig" of a full-form PASSporT as the originating identity of the call: the originating identity of the call is always derived from the SIP signaling, and it is that value, per the procedures above in Section 6.2 Step 2, that is used to recompute the signature at the verification service. That value, rather than the value inside the PASSporT object, is rendered to an end user in ordinary SIP operations, and if a verification service were to simply trust that
但是，验证服务不得将完整形式的PASSporT“orig”中的值视为呼叫的始发标识：呼叫的始发标识始终来自SIP信令，根据上述第6.2节步骤2中的程序，该值就是该值，用于在验证服务处重新计算签名。在普通SIP操作中，如果验证服务只是信任该值，则会将该值而不是PASSporT对象中的值呈现给最终用户
the value in the "orig" corresponded to the call that it received without comparing it to the call signaling, this would enable various cut-and-paste attacks. As an optimization, when the full form is present, the verification service MAY delay performing that cryptographic operation and first compute its own canonicalization of an originating telephone number to compare it to the values in the "orig" element of PASSporT. This would allow the verification service to ascertain whether or not the two ends agree on the canonical number form; if they do not, then surely the signature validation would fail.
“orig”中的值对应于它接收到的呼叫，而不将其与呼叫信令进行比较，这将启用各种剪切和粘贴攻击。作为优化，当存在完整形式时，验证服务可延迟执行该加密操作，并首先计算其自身的原始电话号码规范化，以将其与PASSporT的“orig”元素中的值进行比较。这将使核查机构能够确定双方是否同意标准数字形式；如果他们不这样做，那么签名验证肯定会失败。
This section gives general guidance on the use of credential systems by authentication and verification services, as well as requirements that must be met by credential systems that conform with this architecture. It does not mandate any specific credential system.
本节给出了认证和验证服务使用凭证系统的一般指导，以及符合此体系结构的凭证系统必须满足的要求。它不强制要求任何特定的凭证系统。
Furthermore, this specification allows either a UA or a proxy server to provide the authentication service function and/or the verification service function. For the purposes of end-to-end security, it is obviously preferable for end systems to acquire their own credentials; in this case, UAs can act as authentication services. However, for some deployments, end-user credentials may be neither practical nor affordable, given the potentially large number of SIP UAs (phones, PCs, laptops, PDAs, gaming devices) that may be employed by a single user. Synchronizing keying material across multiple devices may be prohibitively complex and require quite a good deal of additional endpoint behavior. Managing several credentials for the various devices could also be burdensome. Thus, for reasons of credential management alone, implementing the authentication service at an intermediary may be more practical. This trade-off needs to be understood by implementers of this specification.
此外，该规范允许UA或代理服务器提供认证服务功能和/或验证服务功能。出于端到端安全的目的，端系统显然最好获得自己的凭证；在这种情况下，UAs可以充当身份验证服务。但是，对于某些部署，由于单个用户可能使用大量SIP UAs（电话、PC、笔记本电脑、PDA、游戏设备），最终用户凭据可能既不实用也不经济。跨多个设备同步键控材料可能非常复杂，需要大量额外的端点行为。管理各种设备的多个凭据也可能是一项负担。因此，仅出于凭证管理的原因，在中介实现认证服务可能更为实际。这个权衡需要本规范的实现者理解。
In order to act as an authentication service, a SIP entity must possess the private keying material of one or more credentials that cover domain names or telephone numbers. These credentials may represent authority over one domain (such as example.com) or a set of domains enumerated by the credential. Similarly, a credential may represent authority over a single telephone number or a range of telephone numbers. The way that the scope of a credential's authority is expressed is specific to the credential mechanism.
为了充当身份验证服务，SIP实体必须拥有包含域名或电话号码的一个或多个凭证的私钥材料。这些凭据可以表示对一个域（例如example.com）或凭据枚举的一组域的权限。类似地，凭证可以表示对单个电话号码或一系列电话号码的权限。凭证权限范围的表示方式特定于凭证机制。
Authorization of the use of a particular username or telephone number in the From header field value is a matter of local policy for the authentication service, one that depends greatly on the manner in which authentication is performed. For non-telephone number user parts, one policy might be as follows: the username given in the "username" parameter of the Proxy-Authorization header field must correspond exactly to the username in the From header field of the SIP message. However, there are many cases in which this is too limiting or inappropriate; a realm might use "username" parameters in the Proxy-Authorization header field that do not correspond to the user portion of From header fields, or a user might manage multiple accounts in the same administrative domain. In this latter case, a domain might maintain a mapping between the values in the "username" parameter of the Proxy-Authorization header field and a set of one or more SIP URIs that might legitimately be asserted for that "username". For example, the username can correspond to the "private identity" as defined by the Third Generation Partnership Project (3GPP) [TS-3GPP.23.228], in which case the From header field can contain any one of the public identities associated with this private identity. In this instance, another policy might be as follows: the URI in the From header field must correspond exactly to one of the mapped URIs associated with the "username" given in the Proxy-Authorization header field. This is a suitable approach for telephone numbers in particular.
授权使用From标头字段值中的特定用户名或电话号码是身份验证服务的本地策略问题，这在很大程度上取决于执行身份验证的方式。对于非电话号码用户部分，一个策略可能如下：代理授权标头字段的“username”参数中给出的用户名必须与SIP消息的From标头字段中的用户名完全对应。然而，在许多情况下，这是过于有限或不适当的；域可能会在代理授权标头字段中使用与From标头字段的用户部分不对应的“用户名”参数，或者用户可能会在同一管理域中管理多个帐户。在后一种情况下，域可能会维护代理授权标头字段的“username”参数中的值与一组可合法为该“username”断言的一个或多个SIP URI之间的映射。例如，用户名可以对应于第三代合作伙伴关系项目（3GPP）[TS-3GPP.23.228]定义的“私有身份”，在这种情况下，From header字段可以包含与该私有身份相关联的任何一个公共身份。在本例中，另一个策略可能如下所示：From头字段中的URI必须与代理授权头字段中给定的“username”关联的一个映射URI完全对应。这尤其适用于电话号码。
This specification could also be used with credentials that cover a single name or URI, such as alice@example.com or sip:alice@example.com. This would require a modification to authentication service behavior to operate on a whole URI rather than a domain name. Because this is not believed to be a pressing use case, this is deferred to future work, but implementers should note this as a possible future direction.
此规范还可以用于包含单个名称或URI的凭据，例如alice@example.com或sip：alice@example.com. 这将需要修改身份验证服务行为，以操作整个URI，而不是域名。因为这不被认为是一个紧迫的用例，所以这被推迟到未来的工作中，但是实现者应该注意这是一个可能的未来方向。
Exceptions to such authentication service policies arise for cases like anonymity; if the AoR asserted in the From header field uses a form like "sip:anonymous@example.com" (see [RFC3323]), then the "example.com" proxy might authenticate only that the user is a valid user in the domain and insert the signature over the From header field as usual.
此类认证服务策略的例外情况出现在匿名等情况下；如果在From头字段中断言的AoR使用类似“sip:anonymous@example.com“（请参见[RFC3323]），则“example.com”代理可能仅验证该用户是域中的有效用户，并像往常一样在From头字段上插入签名。
In order to act as a verification service, a SIP entity must have a way to acquire credentials for authorities over particular domain names, telephone numbers, and/or number ranges. Dereferencing the URI found in the "info" parameter of the Identity header field (as described in Section 7.3) MUST be supported by all verification service implementations to create a baseline means of credential
为了充当验证服务，SIP实体必须能够获取特定域名、电话号码和/或号码范围上的权限凭证。所有验证服务实现都必须支持取消对标识头字段“info”参数中的URI的引用（如第7.3节所述），以创建基准凭证方式
acquisition. Provided that the credential used to sign a message is not previously known to the verifier, SIP entities SHOULD discover this credential by dereferencing the "info" parameter, unless they have some implementation-specific way of acquiring the needed keying material, such as an offline store of periodically updated credentials. The 436 "Bad Identity Info" response exists for cases where the verification service cannot dereference the URI in the "info" parameter.
获得假设验证器之前不知道用于签署消息的凭证，SIP实体应通过取消引用“info”参数来发现该凭证，除非它们具有某种特定于实现的获取所需密钥材料的方法，例如定期更新凭证的离线存储。对于验证服务无法取消引用“Info”参数中的URI的情况，存在436“Bad Identity Info”响应。
This specification does not propose any particular policy for a verification service to determine whether or not the holder of a credential is the appropriate party to sign for a given SIP identity. Guidance on this is deferred to credential mechanism specifications.
本规范没有针对验证服务提出任何特定策略，以确定凭证持有人是否是为给定SIP身份签名的适当方。关于这一点的指导将推迟到凭证机制规范。
Verification service implementations supporting this specification may wish to have some means of retaining credentials (in accordance with normal practices for credential lifetimes and revocation) in order to prevent themselves from needlessly downloading the same credential every time a request from the same identity is received. Credentials cached in this manner may be indexed in accordance with local policy: for example, by their scope of authority or by the URI given in the "info" parameter value. Further consideration of how to cache credentials is deferred to the credential mechanism specifications.
支持此规范的验证服务实现可能希望有一些保留凭据的方法（根据凭据生存期和吊销的正常实践），以防止每次收到来自相同身份的请求时自己不必要地下载相同的凭据。以这种方式缓存的凭据可以根据本地策略进行索引：例如，根据其权限范围或“info”参数值中给定的URI进行索引。如何缓存凭据的进一步考虑取决于凭据机制规范。
An "info" parameter MUST contain a URI that dereferences to a resource that contains the public key components of the credential used by the authentication service to sign a request. It is essential that a URI in the "info" parameter be dereferencable by any entity that could plausibly receive the request. For common cases, this means that the URI SHOULD be dereferencable by any entity on the public Internet. In constrained deployment environments, a service private to the environment MAY be used instead.
“info”参数必须包含一个URI，该URI取消对资源的引用，该资源包含身份验证服务用于签署请求的凭据的公钥组件。“info”参数中的URI必须能够被任何可能接收请求的实体取消引用。对于常见情况，这意味着URI应该可以被公共Internet上的任何实体取消引用。在受限部署环境中，可以使用环境专用的服务。
Beyond providing a means of accessing credentials for an identity, the "info" parameter further serves as a means of differentiating which particular credential was used to sign a request, when there are potentially multiple authorities eligible to sign. For example, imagine a case where a domain implements the authentication service role for a range of telephone numbers and a UA belonging to Alice has acquired a credential for a single telephone number within that range. Either would be eligible to sign a SIP request for the number in question. Verification services, however, need a means to differentiate which one performed the signature. The "info" parameter performs that function.
除了为身份提供访问凭据的方法外，“info”参数还可以作为一种方法，在可能有多个授权机构有资格签署请求时，区分使用哪个特定凭据签署请求。例如，假设一个域为一系列电话号码实现身份验证服务角色，并且属于Alice的UA已获得该范围内单个电话号码的凭证。任何一方都有资格签署有关号码的SIP请求。然而，验证服务需要一种方法来区分是哪一个执行了签名。“info”参数执行该功能。
This document makes no recommendation for the use of any specific credential system. Today, there are two primary credential systems in place for proving ownership of domain names: certificates (e.g., X.509 v3; see [RFC5280]) and the domain name system itself (e.g., DNS-Based Authentication of Named Entities (DANE); see [RFC6698]). It is envisioned that either could be used in the SIP identity context: an "info" parameter could, for example, give an HTTP URL of the Content-Type "application/pkix-cert" pointing to a certificate (following the conventions of [RFC2585]). The "info" parameter might use the DNS URL scheme (see [RFC4501]) to designate keys in the DNS.
本文件不建议使用任何特定的凭证系统。目前，有两种主要的凭证系统用于证明域名所有权：证书（如X.509 v3；参见[RFC5280]）和域名系统本身（如基于DNS的命名实体认证（DANE）；参见[RFC6698]）。可以设想，两者都可以在SIP标识上下文中使用：例如，“info”参数可以给出指向证书的内容类型为“application/pkix cert”的HTTP URL（遵循[RFC2585]的约定）。“info”参数可能使用DNS URL方案（请参见[RFC4501]）来指定DNS中的密钥。
While no comparable public credentials exist for telephone numbers, either approach could be applied to telephone numbers. A credential system based on certificates is given in [RFC8226], but this specification can work with other credential systems; for example, using the DNS was proposed in [CIDER].
虽然电话号码没有可比的公共凭证，但这两种方法都可以应用于电话号码。[RFC8226]中给出了基于证书的凭证系统，但该规范可以与其他凭证系统一起使用；例如，在[CIDER]中建议使用DNS。
In order for a credential system to work with this mechanism, its specification must detail:
为了使凭证系统能够使用此机制，其规范必须详细说明：
o which URI schemes the credential will use in the "info" parameter, and any special procedures required to dereference the URIs,
o 凭证将在“info”参数中使用哪些URI方案，以及取消引用URI所需的任何特殊过程，
o how the verifier can learn the scope of the credential,
o 验证者如何了解凭证的范围，
o any special procedures required to extract keying material from the resources designated by the URI,
o 从URI指定的资源中提取密钥材料所需的任何特殊程序，
o any algorithms required to validate the credentials (e.g., for certificates, any algorithms used by certificate authorities to sign certificates themselves), and
o 验证凭证所需的任何算法（例如，对于证书，证书颁发机构用于签署证书本身的任何算法），以及
o how the associated credentials will support the mandatory signing algorithm(s) required by PASSporT [RFC8225].
o 相关凭证如何支持PASSporT[RFC8225]所需的强制签名算法。
SIP entities cannot reliably predict where SIP requests will terminate. When choosing a credential scheme for deployments of this specification, it is therefore essential that the trust anchor(s) for credentials be widely trusted or that deployments restrict the use of this mechanism to environments where the reliance on particular trust anchors is assured by business arrangements or similar constraints.
SIP实体无法可靠地预测SIP请求将在何处终止。因此，在为本规范的部署选择凭据方案时，必须广泛信任凭据的信任锚，或者部署将此机制的使用限制在业务安排或类似约束可确保依赖特定信任锚的环境中。
Note that credential systems must address key lifecycle management concerns: were a domain to change the credential available at the Identity header field "info" parameter URI before a verifier evaluates a request signed by an authentication service, this would
请注意，凭据系统必须解决关键的生命周期管理问题：如果域要在验证器评估由身份验证服务签名的请求之前更改标识标头字段“info”参数URI处可用的凭据，则
cause obvious verifier failures. When a rollover occurs, authentication services SHOULD thus provide new "info" URIs for each new credential and SHOULD continue to make older key acquisition URIs available for a duration longer than the plausible lifetime of a SIP transaction (a minute would most likely suffice).
导致明显的验证器故障。当发生翻滚时，身份验证服务应为每个新凭证提供新的“信息”URI，并应继续使旧的密钥获取URI在比SIP事务的合理生存期更长的时间内可用（一分钟很可能就足够了）。
The STIR problem statement [RFC7340] focuses primarily on cases where the called and calling parties identified in the To and From header field values use telephone numbers, as this remains the dominant use case in the deployment of SIP. However, the Identity header mechanism also works with SIP URIs without telephone numbers (of the form "sip:user@host") and, potentially, other identifiers when SIP interworks with other protocols.
STIR问题声明[RFC7340]主要关注在To和From报头字段值中标识的被叫方和主叫方使用电话号码的情况，因为这仍然是SIP部署中的主要用例。但是，标识头机制也适用于没有电话号码的SIP URI（形式为“SIP:user@host）以及SIP与其他协议交互时的其他标识符。
Authentication services confirm the identity of the originator of a call, which is typically found in the From header field value. The guidance in this specification also applies to extracting the URI containing the originator's identity from the P-Asserted-Identity header field value instead of the From header field value. In some trusted environments, the P-Asserted-Identity header field is used in lieu of the From header field to convey the AoR or telephone number of the originator of a request; where it does, local policy might therefore dictate that the canonical identity derives from the P-Asserted-Identity header field rather than the From header field.
身份验证服务确认呼叫发起人的身份，该身份通常位于From header字段值中。本规范中的指南也适用于从P-Asserted-identity头字段值而不是从头字段值中提取包含发起者身份的URI。在一些受信任的环境中，P-Asserted-Identity报头字段代替From报头字段用于传递请求发起人的AoR或电话号码；在这种情况下，本地策略可能因此规定规范标识从P-Asserted-identity头字段而不是从头字段派生。
Ultimately, in any case where local policy canonicalizes the identity into a form different from how it appears in the From header field, the use of the full form of PASSporT by authentication services is RECOMMENDED, but because the "orig" claim of PASSporT itself could then divulge information about users or networks, implementers should be mindful of the guidelines in Section 11.
最终，在任何情况下，如果本地策略将身份规范化为不同于其在“发件人”标题字段中显示的形式，则建议通过身份验证服务使用完整形式的PASSporT，但因为PASSporT本身的“原始”声明可能会泄露有关用户或网络的信息，实施者应注意第11节中的指南。
In order to determine whether or not the user portion of a SIP URI is a telephone number, authentication services and verification services MUST perform the following procedure on any SIP URI they inspect that contains a numeric user part. Note that the same procedures are followed for creating the canonical form of a URI found in the From header field as the procedures used for a URI found in the To header field or the P-Asserted-Identity header field.
为了确定SIP URI的用户部分是否是电话号码，身份验证服务和验证服务必须对其检查的任何包含数字用户部分的SIP URI执行以下过程。请注意，创建在From头字段中找到的URI的规范形式所遵循的过程与在To头字段或P-Asserted-Identity头字段中找到的URI所使用的过程相同。
First, implementations will ascertain if the user portion of the URI constitutes a telephone number. Telephone numbers most commonly appear in SIP header field values in the username portion of a SIP URI (e.g., "sip:+17005551008@chicago.example.com;user=phone"). The
首先，实现将确定URI的用户部分是否构成电话号码。电话号码通常出现在SIP URI的用户名部分的SIP头字段值中（例如，“SIP:+17005551008@chicago.example.com；用户=电话”）。这个
user part of SIP URIs with the "user=phone" parameter conforms to the syntax of the tel URI scheme [RFC3966]. It is also possible for a tel URI to appear in SIP header fields outside the context of a SIP or Session Initiation Protocol Secure (SIPS) URI (e.g., "tel:+17005551008"). Thus, in standards-compliant environments, numbers will be explicitly labeled by the use of tel URIs or the "user=phone" parameter.
带有“user=phone”参数的SIPURI的用户部分符合tel URI方案[RFC3966]的语法。tel URI也可能出现在SIP或会话启动协议安全（SIPS）URI上下文之外的SIP头字段中（例如，“tel:+17005551008”）。因此，在符合标准的环境中，数字将通过使用tel-uri或“user=phone”参数进行显式标记。
Alternatively, implementations in environments that do not conform to those standards MAY follow local policies for identifying telephone numbers. For example, implementations could infer that the user part is a telephone number due to the presence of the "+" indicator at the start of the user portion. Absent even that indication, if there are numbers present in the user portion, implementations might conceivably also detect that the user portion of the URI contains a telephone number by determining whether or not those numbers would be dialable or routable in the local environment -- bearing in mind that the telephone number may be a valid E.164 number [E.164], a nationally specific number, or even a private branch exchange number. Implementations could also rely on external hints: for example, a verification service implementation could infer from the type of credential that signed a request that the signature must be over a telephone number.
或者，在不符合这些标准的环境中的实现可能会遵循用于识别电话号码的本地策略。例如，由于在用户部分的开始处存在“+”指示符，实现可以推断用户部分是电话号码。即使没有该指示，如果用户部分中存在数字，可以想象，实现还可以通过确定这些号码在本地环境中是可拨打的还是可路由的来检测URI的用户部分包含电话号码——记住电话号码可以是有效的E.164号码[E.164]，一个国家特定的号码，甚至是一个私人分支交换号码。实现还可以依赖于外部提示：例如，验证服务实现可以从签署请求的凭据类型推断签名必须通过电话号码。
Regardless of how the implementation detects telephone numbers, once a telephone number has been detected, implementations SHOULD follow the procedures in Section 8.3. If the URI field does not contain a telephone number or if the result of the canonicalization of the From header field value does not form a valid E.164 telephone number, the authentication service and/or verification service SHOULD treat the entire URI as a SIP URI and apply the procedures in Section 8.5. These URI normalization procedures are invoked to canonicalize the URI before it is included in a PASSporT object in, for example, a "uri" claim. See Section 8.5 for that behavior.
无论实施如何检测电话号码，一旦检测到电话号码，实施应遵循第8.3节中的程序。如果URI字段不包含电话号码，或者如果From标头字段值的规范化结果未形成有效的E.164电话号码，则认证服务和/或验证服务应将整个URI视为SIP URI，并应用第8.5节中的程序。调用这些URI规范化过程来规范化URI，然后再将其包含在PASSporT对象（例如“URI”声明）中。有关该行为，请参见第8.5节。
In order for telephone numbers to be used with the mechanism described in this document, authentication services must receive credentials from an authority for telephone numbers or telephone number ranges, and verification services must trust the authority employed by the authentication service that signs a request. Per Section 7.4, enrollment procedures and credential management are outside the scope of this document; approaches to credential management for telephone numbers are discussed in [RFC8226].
为了使电话号码与本文档中描述的机制一起使用，身份验证服务必须从授权机构接收电话号码或电话号码范围的凭据，并且验证服务必须信任身份验证服务所使用的对请求进行签名的授权机构。根据第7.4节，注册程序和凭证管理不在本文件范围内；[RFC8226]中讨论了电话号码的凭证管理方法。
Once an implementation has identified a telephone number, it must construct a number string. That requires performing the following steps:
一旦实现识别了电话号码，它就必须构造一个数字字符串。这需要执行以下步骤：
o Implementations MUST drop any "+"s, internal dashes, parentheses, or other non-numeric characters, except for the "#" or "*" keys used in some special service numbers (typically, these will appear only in the To header field value). This MUST result in an ASCII string limited to "#", "*", and digits without whitespace or visual separators.
o 实现必须删除任何“+”号、内部破折号、括号或其他非数字字符，但某些特殊服务编号中使用的“#”或“*”键除外（通常，这些键仅出现在“收件人”标题字段值中）。这必须导致ASCII字符串限制为“#”、“*”和不带空格或可视分隔符的数字。
o Next, an implementation must assess if the number string is a valid, globally routable number with a leading country code.
o 接下来，一个实现必须评估数字字符串是否是一个有效的、具有前导国家代码的全局可路由数字。
If not, implementations SHOULD convert the number into E.164 format, adding a country code if necessary; this may involve transforming the number from a dial string (see [RFC3966]), removing any national or international dialing prefixes or performing similar procedures. It is only in the case that an implementation cannot determine how to convert the number to a globally routable format that this step may be skipped. This will be the case, for example, for nationally specific service numbers (e.g., 911, 112); however, calls to those numbers are routed in a very strict fashion, which ordinarily prevents them from reaching entities that don't understand the numbers.
如果没有，则应将数字转换为E.164格式，必要时添加国家代码；这可能涉及从拨号字符串转换号码（参见[RFC3966]），删除任何国家或国际拨号前缀或执行类似程序。只有在实现无法确定如何将数字转换为全局可路由格式的情况下，才可以跳过此步骤。例如，国家特定的服务号码（如911、112）就是这种情况；但是，对这些号码的调用是以非常严格的方式进行路由的，这通常会阻止它们到达不了解号码的实体。
o Some domains may need to take unique steps to convert their numbers into a global format, and such transformations during canonicalization can also be made in accordance with specific policies used within a local domain. For example, one domain may only use local number formatting and need to convert all To/From header field user portions to E.164 by prepending country-code and region-code digits; another domain might have prefixed usernames with trunk-routing codes, in which case the canonicalization will need to remove the prefix. This specification cannot anticipate all of the potential transformations that might be useful.
o 某些域可能需要采取独特的步骤将其编号转换为全局格式，并且在规范化过程中也可以根据本地域中使用的特定策略进行此类转换。例如，一个域可能只使用本地号码格式，并且需要通过在国家代码和地区代码数字前加前缀，将所有转出/转出标题字段的用户部分转换为E.164；另一个域可能有带有中继路由代码的前缀用户名，在这种情况下，规范化需要删除前缀。该规范无法预测所有可能有用的潜在转换。
o The resulting canonical number string will be used as input to the hash calculation during signing and verifying processes.
o 在签名和验证过程中，生成的规范数字字符串将用作哈希计算的输入。
The ABNF of this number string is:
此数字字符串的ABNF为：
tn-spec = 1*tn-char
tn-char = "#" / "*" / DIGIT
tn-spec = 1*tn-char
tn-char = "#" / "*" / DIGIT
The resulting number string is used in the construction of the telephone number field(s) in a PASSporT object.
生成的数字字符串用于PASSporT对象中电话号码字段的构造。
To use a SIP URI as an identity in this mechanism requires authentication and verification systems to support standard mechanisms for proving authority over a domain name: that is, the domain name in the host portion of the SIP URI.
要在该机制中使用SIP URI作为身份，需要身份验证和验证系统支持标准机制来证明对域名的权限：即SIP URI的主机部分中的域名。
A verifier MUST evaluate the correspondence between the user's identity and the signing credential by following the procedures defined in [RFC5922], Section 7.2. While [RFC5922] deals with the use of TLS and is specific to certificates, the procedures described are applicable to verifying identity if one substitutes the "hostname of the server" for the domain portion of the user's identity in the From header field of a SIP request with an Identity header field.
验证者必须按照[RFC5922]第7.2节规定的程序评估用户身份和签名凭证之间的对应关系。虽然[RFC5922]涉及TLS的使用，并且特定于证书，但如果将SIP请求的From标头字段中用户标识的域部分替换为“服务器主机名”，则所述过程适用于验证标识。
This process is complicated by two deployment realities. In the first place, credentials have varying ways of describing their subjects and may indeed have multiple subjects, especially in "virtual hosting" cases where multiple domains are managed by a single application (see [RFC5922], Section 7.8). Secondly, some SIP services may delegate SIP functions to a subordinate domain and utilize the procedures in [RFC3263] that allow requests for, say, "example.com" to be routed to "sip.example.com". As a result, a user with the AoR "sip:alice@example.com" may process requests through a host like "sip.example.com", and it may be that latter host that acts as an authentication service.
这一过程因两个部署现实而变得复杂。首先，凭证有不同的方式描述其主题，并且可能确实有多个主题，特别是在“虚拟主机”的情况下，其中多个域由单个应用程序管理（请参见[RFC5922]，第7.8节）。其次，一些SIP服务可以将SIP功能委托给从属域，并利用[RFC3263]中的过程，允许将例如“example.com”的请求路由到“SIP.example.com”。因此，具有AoR“sip”的用户：alice@example.com可以通过“sip.example.com”这样的主机处理请求，并且可能是后一个主机充当身份验证服务。
To address the second of these problems, a domain that deploys an authentication service on a subordinate host might supply that host with the private keying material associated with a credential whose subject is a domain name that corresponds to the domain portion of the AoRs that the domain distributes to users. Note that this corresponds to the comparable case of routing inbound SIP requests to a domain. When the NAPTR and SRV procedures of [RFC3263] are used to direct requests to a domain name other than the domain in the original Request-URI (e.g., for "sip:alice@example.com", the corresponding SRV records point to the service "sip1.example.org"), the client expects that the certificate passed back in any TLS exchange with that host will correspond exactly with the domain of the original Request-URI, not the domain name of the host.
为了解决第二个问题，在从属主机上部署身份验证服务的域可能会向该主机提供与凭据相关联的私钥材料，该凭据的主题是与域分发给用户的AOR的域部分相对应的域名。注意，这对应于将入站SIP请求路由到域的类似情况。当[RFC3263]的NAPTR和SRV过程用于将请求定向到原始请求URI中的域以外的域名时（例如，对于“sip:alice@example.com，相应的SRV记录指向服务“sip1.example.org”），客户端希望在与该主机的任何TLS交换中传回的证书将与原始请求URI的域完全对应，而不是主机的域名。
Consequently, in order to make inbound routing to such SIP services work, a domain administrator must similarly be willing to share the domain's private key with the service. This design decision was made to compensate for the insecurity of the DNS, and it makes certain potential approaches to DNS-based "virtual hosting" unsecurable for SIP in environments where domain administrators are unwilling to share keys with hosting services.
因此，为了使到此类SIP服务的入站路由工作，域管理员必须同样愿意与服务共享域的私钥。这一设计决策是为了补偿DNS的不安全性，并且在域管理员不愿意与托管服务共享密钥的环境中，它使得基于DNS的“虚拟主机”的某些潜在方法对于SIP是不可治愈的。
Just as telephone numbers may undergo a number of syntactic transformations during transit, the same can happen to SIP and SIPS URIs without telephone numbers as they traverse certain intermediaries. Therefore, when generating a PASSporT object based on a SIP request, any SIP and SIPS URIs must be transformed into a canonical form that captures the AoR represented by the URI before they are provisioned in PASSporT claims such as "uri". The URI normalization procedures required are as follows.
正如电话号码在传输过程中可能会经历许多语法转换一样，没有电话号码的SIP和SIPS URI在穿越某些中介时也会发生同样的情况。因此，当基于SIP请求生成PASSporT对象时，任何SIP和SIPS URI都必须转换为捕获URI表示的AoR的规范形式，然后才能在PASSporT声明（如“URI”）中提供它们。所需的URI规范化过程如下所示。
Following the ABNF of [RFC3261], the SIP or SIPS URI in question MUST discard all elements after the "hostport" of the URI, including all uri-parameters and escaped headers, from its syntax. Of the userinfo component of the SIP URI, only the user element will be retained: any password (and any leading ":" before the password) MUST be removed, and since this userinfo necessarily does not contain a telephone-subscriber component, no further parameters can appear in the user portion.
在[RFC3261]的ABNF之后，所讨论的SIP或SIPS URI必须从其语法中丢弃URI的“hostport”之后的所有元素，包括所有URI参数和转义头。在SIP URI的userinfo组件中，只保留用户元素：必须删除任何密码（以及密码前的任何前导“：”），并且由于此userinfo不一定包含电话用户组件，因此用户部分中不能出现其他参数。
The hostport portion of the SIP or SIPS URI MUST similarly be stripped of any trailing port along with the ":" that proceeds the port, leaving only the host.
SIP或SIPS URI的hostport部分必须类似地从任何后续端口中剥离，并使用“：”进行端口处理，只留下主机。
The ABNF of this canonical URI form (following the syntax defined in [RFC3261]) is:
此规范URI形式的ABNF（遵循[RFC3261]中定义的语法）为：
canon-uri = ( "sip" / "sips" ) ":" user "@" host
canon-uri = ( "sip" / "sips" ) ":" user "@" host
Finally, the URI will be subject to the syntax-based URI normalization procedures of [RFC3986], Section 6.2.2. Implementations MUST perform case normalization (rendering the scheme, user, and host all lowercase) and percent-encoding normalization (decoding any percent-encoded octet that corresponds to an unreserved character, per [RFC3986], Section 2.3). However, note that normalization procedures face known challenges in some internationalized environments (see [IRI-COMPARISON]) and that perfect normalization of URIs may not be possible in those environments.
最后，URI将遵循[RFC3986]第6.2.2节中基于语法的URI规范化程序。实现必须执行大小写规范化（使方案、用户和主机全部小写）和百分比编码规范化（根据[RFC3986]第2.3节，解码与无保留字符对应的任何百分比编码八位字节）。但是，请注意，规范化过程在一些国际化环境中面临已知的挑战（请参见[IRI-COMPARISON]），在这些环境中可能不可能实现URI的完美规范化。
For future PASSporT applications, it may be desirable to provide an identifier without an attached protocol scheme. Future specifications that define PASSporT claims for SIP as a using protocol could use these basic procedures but could eliminate the scheme component. A more exact definition is left to future specifications.
对于未来的护照申请，可能需要提供一个没有附加协议方案的标识符。将SIP的PASSporT声明定义为使用协议的未来规范可以使用这些基本过程，但可以消除方案组件。更准确的定义留给未来的规范。
As future requirements may warrant increasing the scope of the Identity mechanism, this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT. The "ppt" parameter value MUST consist of a token containing an extension specification, which denotes an extended set of one or more signed claims per the type extensibility mechanism specified in [RFC8225], Section 8. Note that per the guidance in that section, "ppt" is used only to enforce a mandatory extension: optional claims may be added to any PASSporT object without requiring the use of "ppt", but the compact form of PASSporT MUST NOT be used when optional claims are present in the PASSporT payload.
由于未来的需求可能需要增加身份机制的范围，本规范规定了身份标头字段的可选“ppt”参数，该参数反映了PASSporT中的“ppt”标头。“ppt”参数值必须由包含扩展规范的令牌组成，该扩展规范表示根据[RFC8225]第8节中指定的类型扩展机制的一个或多个签名声明的扩展集。请注意，根据该节中的指导，“ppt”仅用于强制扩展：可选声明可以添加到任何PASSporT对象中，而无需使用“ppt”，但当PASSporT有效载荷中存在可选声明时，不得使用紧凑形式的PASSporT。
The potential for extensions is one of the primary motivations for allowing the presence of multiple Identity header fields in the same SIP request. It is envisioned that future extensions might allow for alternate information to be signed or explicitly allow different parties to provide the signatures than the authorities envisioned by baseline STIR. A request might, for example, have one Identity added by an authentication service at the originating administrative domain and then another Identity header field added by some further intermediary using a PASSporT extension. While this specification does not define any such specific purpose for multiple Identity header fields, implementations MUST support receiving multiple header fields for reasons of future compatibility.
扩展的可能性是允许在同一SIP请求中存在多个标识头字段的主要动机之一。可以预见，未来的扩展可能允许签署替代信息，或者明确允许不同的当事方提供基线STIR所设想的权限以外的签名。例如，一个请求可能有一个身份由发起管理域的身份验证服务添加，然后由另一个中介使用PASSporT扩展添加另一个身份头字段。虽然本规范没有为多个标识头字段定义任何此类特定用途，但出于未来兼容性的考虑，实现必须支持接收多个头字段。
An authentication service cannot assume that verifiers will understand any given extension. Verifiers that do support an extension may then trigger appropriate application-level behavior in the presence of an extension; authors of extensions should provide appropriate extension-specific guidance to application developers on this point.
身份验证服务不能假定验证器将理解任何给定的扩展。确实支持扩展的验证器随后可能在存在扩展时触发适当的应用程序级行为；在这一点上，扩展的作者应该为应用程序开发人员提供适当的特定于扩展的指导。
This specification introduces several significant changes from the version of the Identity header field defined by [RFC4474]. However, due to the problems enumerated in [SIP-RFC4474-CONCERNS], it is not believed that the original Identity header field has seen any deployment, or even implementation in deployed products.
本规范对[RFC4474]定义的标识头字段版本进行了几项重大更改。但是，由于[SIP-RFC4474-CONNECTS]中列举的问题，不认为原始标识头字段在已部署的产品中有任何部署，甚至没有实现。
As such, this mechanism contains no provisions for signatures generated with this specification to work with implementations compliant with [RFC4474], nor does it contain any related backwards-compatibility provisions. Hypothetically, were an implementation compliant with [RFC4474] to receive messages containing this revised version of the Identity header field, it would likely fail the request with a 436 response code due to the absence of an Identity-Info header field (Section 4). Implementations of this specification, for debugging purposes, might interpret a 436 with a reason phrase of "Bad Identity Info" (previously "Bad Identity-Info"; see Section 13.2) as an indication that the request has failed because it reached a (hypothetical) verification service that is compliant with [RFC4474].
因此，该机制不包含使用本规范生成的签名用于符合[RFC4474]的实现的规定，也不包含任何相关的向后兼容性规定。假设，如果实现符合[RFC4474]以接收包含此修改版本的标识标头字段的消息，则由于缺少标识信息标头字段（第4节），它可能会使用436响应代码使请求失败。出于调试目的，本规范的实现可能会将带有“错误标识信息”原因短语（以前为“错误标识信息”；请参见第13.2节）的436解释为请求失败的指示，因为它到达了符合[RFC4474]的（假设的）验证服务。
The purpose of this mechanism is to provide a reliable identification of the originator of a SIP request, specifically a cryptographic assurance that an authority asserts the originator can claim the URI the identity stipulated in the request. This URI may contain or imply a variety of personally identifying information, including the name of a human being, their place of work or service provider, and, possibly, further details. The intrinsic privacy risks associated with that URI are, however, no different from those of baseline SIP. Per the guidance in [RFC6973], implementers should make users aware of the privacy trade-off of providing secure identity.
该机制的目的是为SIP请求的发起人提供可靠的标识，特别是一种加密保证，即授权机构断言发起人可以根据请求中规定的标识声明URI。此URI可能包含或暗示各种个人识别信息，包括人的姓名、工作地点或服务提供商，以及可能的进一步详细信息。然而，与该URI相关的内在隐私风险与基线SIP的风险没有什么不同。根据[RFC6973]中的指导，实施者应让用户意识到提供安全身份的隐私权衡。
The identity mechanism presented in this document is compatible with the standard SIP practices for privacy described in [RFC3323]. A SIP proxy server can act as both a privacy service as described in [RFC3323] and an authentication service. Since a UA can provide any From header field value that the authentication service is willing to authorize, there is no reason why private SIP URIs that contain legitimate domains (e.g., sip:anonymous@example.com) cannot be signed by an authentication service. The construction of the Identity header field is the same for private URIs as it is for any other sort of URIs. Similar practices could be used to support opportunistic signing of SIP requests for UA-integrated authentication services with self-signed certificates, though that is outside the scope of this specification and is left as a matter for future investigation.
本文档中介绍的身份机制与[RFC3323]中描述的隐私标准SIP实践兼容。SIP代理服务器既可以充当[RFC3323]中所述的隐私服务，也可以充当身份验证服务。由于UA可以提供认证服务愿意授权的任何From header字段值，因此没有理由使用包含合法域的私有SIP URI（例如，SIP：anonymous@example.com)无法由身份验证服务签名。对于私有URI，标识头字段的构造与任何其他类型的URI相同。类似的实践可用于支持使用自签名证书对UA集成认证服务的SIP请求进行机会签名，但这不在本规范的范围内，留待将来调查。
Note, however, that even when using anonymous SIP URIs, an authentication service must possess a certificate corresponding to the host portion of the addr-spec of the From header field value of the request; accordingly, using domains like "anonymous.invalid" will not be usable by privacy services that simultaneously act as authentication services. The assurance offered by the usage of anonymous URIs with a valid domain portion is "this is a known user in my domain that I have authenticated, but I am keeping its identity private."
然而，请注意，即使在使用匿名SIPURI时，身份验证服务也必须拥有与请求的From头字段值的addr规范的主机部分相对应的证书；因此，同时充当身份验证服务的隐私服务将无法使用“anonymous.invalid”之类的域。使用具有有效域部分的匿名URI所提供的保证是“这是我的域中的已知用户，我已对其进行了身份验证，但我将其身份保密。”
It is worth noting two features of this more anonymous form of identity. One can eliminate any identifying information in a domain through the use of the domain "anonymous.invalid", but we must then acknowledge that it is difficult for a domain to be both anonymous and authenticated. The use of the domain "anonymous.invalid" entails that no corresponding authority for the domain can exist, and as a consequence, authentication service functions for that domain are meaningless. The second feature is more germane to the threats this document mitigates [RFC7375]. None of the relevant attacks, all of which rely on the attacker taking on the identity of a victim or hiding their identity using someone else's identity, are enabled by an anonymous identity. As such, the inability to assert an authority over an anonymous domain is irrelevant to our threat model.
值得注意的是，这种更匿名的身份形式有两个特点。通过使用域“anonymous.invalid”可以消除域中的任何标识信息，但我们必须承认，域很难同时具有匿名性和身份验证性。使用域“anonymous.invalid”意味着该域不存在相应的权限，因此，该域的身份验证服务功能毫无意义。第二个特性与本文档缓解的威胁更为密切相关[RFC7375]。所有相关的攻击都依赖于攻击者获取受害者身份或使用其他人的身份隐藏其身份，这些攻击都不是由匿名身份启用的。因此，无法在匿名域上维护权限与我们的威胁模型无关。
[RFC3325] defines the "id" priv-value token, which is specific to the P-Asserted-Identity header field. The sort of assertion provided by the P-Asserted-Identity header field is very different from the Identity header field presented in this document. It contains additional information about the originator of a message that may go beyond what appears in the From header field; P-Asserted-Identity holds a definitive identity for the originator that is somehow known to a closed network of intermediaries. Presumably, that network will use this identity for billing or security purposes. The danger of this network-specific information leaking outside of the closed network motivated the "id" priv-value token. The "id" priv-value token has no implications for the Identity header field, and privacy services MUST NOT remove the Identity header field when a priv-value of "id" appears in a Privacy header field.
[RFC3325]定义特定于P-Asserted-Identity标头字段的“id”priv value标记。P-Asserted-Identity头字段提供的断言类型与本文档中的Identity头字段非常不同。它包含有关消息发起者的附加信息，这些信息可能超出“发件人”标题字段中显示的信息；P-Asserted-Identity为发起人持有一个最终身份，该身份在某种程度上为封闭的中介网络所知。据推测，该网络将使用该身份进行计费或安全目的。这种特定于网络的信息泄漏到封闭网络之外的危险激发了“id”priv-value令牌。“id”priv value令牌对标识标头字段没有影响，并且当隐私标头字段中出现“id”priv值时，隐私服务不得删除标识标头字段。
The full form of the PASSporT object provides the complete JSON objects used to generate the signed-identity-digest of the Identity header field value, including the canonicalized form of the telephone number of the originator of a call if the signature is over a telephone number. In some contexts, local policy may require a canonicalization that differs substantially from the original From header field. Depending on those policies, potentially the full form of PASSporT might divulge information about the originating network or user that might not appear elsewhere in the SIP request. Were it
PASSporT对象的完整形式提供了用于生成标识头字段值的签名标识摘要的完整JSON对象，包括呼叫发起人的电话号码的规范化形式（如果签名是通过电话号码）。在某些上下文中，本地策略可能需要规范化，该规范化与原始的from头字段有很大不同。根据这些策略，完整形式的PASSporT可能会泄露SIP请求中其他地方可能不会出现的有关发起网络或用户的信息。是吗
to be used to reflect the contents of the P-Asserted-Identity header field, for example, then the object would need to be converted to the compact form when the P-Asserted-Identity header is removed to avoid any such leakage outside of a trust domain. Since, in those contexts, the canonical form of the originator's identity could not be reassembled by a verifier and thus the Identity signature validation process would fail, using P-Asserted-Identity with the full form of PASSporT in this fashion is NOT RECOMMENDED outside of environments where SIP requests will never leave the trust domain. As a side note, history shows that closed networks never stay closed and one should design their implementation assuming connectivity to the broader Internet.
例如，要用于反映P-Asserted-Identity报头字段的内容，则当P-Asserted-Identity报头被移除时，需要将对象转换为压缩形式，以避免在信任域之外发生任何此类泄漏。由于在这些情况下，验证人无法重新组合发端人身份的标准形式，因此身份签名验证过程将失败，因此，在SIP请求永远不会离开信任域的环境之外，不建议以这种方式将P-Asserted-identity与完整形式的PASSporT一起使用。作为旁注，历史表明，封闭的网络永远不会保持封闭状态，人们应该在设计其实现时假设连接到更广泛的互联网。
Finally, note that unlike [RFC3325], the mechanism described in this specification adds no information to SIP requests that has privacy implications -- apart from disclosing that an authentication service is willing to sign for an originator.
最后，请注意，与[RFC3325]不同，本规范中描述的机制没有向SIP请求添加任何涉及隐私的信息——除了披露身份验证服务愿意为发起人签名。
This document describes a mechanism that provides a signature over the Date header field of SIP requests, parts of the To and From header fields, and (when present) any media keying material in the message body. In general, the considerations related to the security of these header fields are the same as those given in [RFC3261] for including header fields in tunneled "message/sip" MIME bodies (see Section 23 of [RFC3261] in particular). This section details the individual security properties obtained by including each of these header fields within the signature; collectively, this set of header fields provides the necessary properties to prevent impersonation. It addresses the solution-specific attacks against in-band solutions enumerated in [RFC7375], Section 4.1.
本文档描述了一种机制，该机制在SIP请求的日期标头字段、部分“往返”标头字段以及（如果存在）消息体中的任何媒体密钥材料上提供签名。通常，与这些头字段的安全性相关的注意事项与[RFC3261]中给出的在隧道“消息/sip”MIME主体中包含头字段的注意事项相同（具体参见[RFC3261]第23节）。本节详细介绍了通过在签名中包含这些头字段而获得的各个安全属性；总的来说，这组标题字段提供了防止模拟的必要属性。它解决了针对[RFC7375]第4.1节中列举的带内解决方案的特定于解决方案的攻击。
The From header field value (in ordinary operations) indicates the identity of the originator of the message; for the purposes of this document, either the SIP AoR URI or an embedded telephone number provides the identity of a SIP user. Note that in some deployments the identity of the originator may reside in P-Asserted-Identity instead. The originator's identity is the key piece of information that this mechanism secures; the remainder of the signed parts of a SIP request are present to provide reference integrity and to prevent certain types of cut-and-paste attacks.
From header字段值（在普通操作中）表示消息发起人的身份；在本文档中，SIP AoR URI或嵌入式电话号码提供SIP用户的身份。请注意，在某些部署中，发起者的身份可能位于P-Asserted-identity中。发起人的身份是该机制保护的关键信息；SIP请求的其余签名部分用于提供引用完整性并防止某些类型的剪切和粘贴攻击。
The Date header field value protects against cut-and-paste attacks, as described in [RFC3261], Section 23.4.2. That specification recommends that implementations notify the user of a potential
日期标头字段值可防止剪切和粘贴攻击，如[RFC3261]第23.4.2节所述。该规范建议实现通知用户潜在的错误
security issue if the signed Date header field value is stale by an hour or more. To prevent cut-and-paste of recently observed messages, this specification instead RECOMMENDS a shorter interval of sixty seconds. Implementations of this specification MUST NOT deem valid a request with an outdated Date header field. Note that per the behavior described in [RFC3893], Section 10, servers can keep state of recently received requests, and thus if an Identity header field is replayed by an attacker within the Date interval, verifiers can detect that it is spoofed because a message with an identical Date from the same source had recently been received.
如果签名日期标头字段值过期一小时或更长时间，则会出现安全问题。为了防止剪切和粘贴最近观察到的消息，本规范建议缩短60秒的间隔。此规范的实现不得将具有过期日期标头字段的请求视为有效。请注意，根据[RFC3893]第10节中描述的行为，服务器可以保持最近接收到的请求的状态，因此，如果攻击者在日期间隔内重播了标识头字段，则验证器可以检测到该字段是伪造的，因为最近收到了来自同一来源的具有相同日期的消息。
It has been observed in the wild that some networks change the Date header field value of SIP requests in transit; to accommodate that type of scenario, alternative behavior might be necessary. Verification services that observe a signature validation failure MAY therefore reconstruct the Date header field component of the signature from the "iat" carried in the full form of PASSporT: provided that time recorded by "iat" falls within the local policy for freshness that would ordinarily apply to the Date header, the verification service MAY treat the signature as valid, provided it keeps adequate state to detect recent replays. Note that this will require the inclusion of the full form of the PASSporT object by authentication services in networks where such failures are observed.
在野外观察到，一些网络在传输过程中更改SIP请求的日期头字段值；为了适应这种情况，可能需要其他行为。因此，观察到签名验证失败的验证服务机构可根据完整护照格式中的“iat”重构签名的日期标题字段组件：前提是“iat”记录的时间在通常适用于日期标题的当地新鲜度政策范围内，验证服务可以将签名视为有效，前提是它保持足够的状态以检测最近的重播。请注意，这将需要在观察到此类故障的网络中通过身份验证服务包含PASSporT对象的完整形式。
The To header field value provides the identity of the SIP user that this request originally targeted. Covering the identity in the To header field with the Identity signature serves two purposes. First, it prevents cut-and-paste attacks in which an Identity header field from a legitimate request for one user is cut-and-pasted into a request for a different user. Second, it preserves the starting URI scheme of the request; this helps prevent downgrade attacks against the use of SIPS. The To identity offers additional protection against cut-and-paste attacks beyond the Date header field. For example, without a signature over the To identity, an attacker who receives a call from a target could immediately cut-and-paste the Identity and From header field value from that INVITE into a new request to the target's voicemail service within the Date interval, and the voicemail service would have no way of knowing that the Identity header field it received had been originally signed for a call intended for a different number. However, note the caveats below in Section 12.1.1.
To header字段值提供此请求最初针对的SIP用户的标识。用身份签名覆盖“收件人”标题字段中的身份有两个目的。首先，它可以防止剪切粘贴攻击，在这种攻击中，一个用户的合法请求中的标识头字段被剪切粘贴到另一个用户的请求中。其次，它保留请求的起始URI方案；这有助于防止针对SIP使用的降级攻击。To标识提供了额外的保护，以防止日期标头字段之外的剪切和粘贴攻击。例如，如果没有对To标识的签名，则收到目标呼叫的攻击者可以在日期间隔内立即将来自该邀请的标识和from header字段值剪切并粘贴到目标语音邮件服务的新请求中，语音邮件服务也无法知道它收到的标识头字段最初是为另一个号码的呼叫签名的。但是，请注意以下第12.1.1节中的注意事项。
When signing a request that contains a fingerprint of keying material in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a signature over that fingerprint. This signature prevents certain classes of impersonation attacks in which an attacker forwards or cut-and-pastes a legitimate request. Although the target of the attack may accept the request, the attacker will be unable to
对包含DTLS-SRTP[RFC5763]SDP中密钥材料指纹的请求进行签名时，此机制始终在该指纹上提供签名。此签名可防止攻击者转发或剪切并粘贴合法请求的某些模拟攻击。尽管攻击目标可以接受请求，但攻击者将无法
exchange media with the target, as they will not possess a key corresponding to the fingerprint. For example, there are some baiting attacks, launched with the REFER method or through social engineering, where the attacker receives a request from the target and reoriginates it to a third party. These might not be prevented by only a signature over the From, To, and Date, but they could be prevented by securing a fingerprint for DTLS-SRTP. While this is a different form of impersonation than is commonly used for robocalling, ultimately there is little purpose in establishing the identity of the user that originated a SIP request if this assurance is not coupled with a comparable assurance over the contents of the subsequent media communication. This signature also reduces the potential for active eavesdropping attacks against the SIP media. In environments where DTLS-SRTP is unsupported, however, no field is signed and no protections are provided.
与目标交换媒体，因为他们不会拥有与指纹对应的密钥。例如，有一些诱饵攻击，使用REFER方法或通过社会工程发起，攻击者从目标接收请求并将其重新排序给第三方。这些可能不会仅通过从、到和日期的签名来防止，但可以通过保护DTLS-SRTP的指纹来防止。虽然这是一种不同于通常用于机器人定位的模拟形式，但如果该保证不与对后续媒体通信内容的可比保证相结合，则最终在建立发起SIP请求的用户的身份方面没有什么目的。此签名还降低了针对SIP媒体的主动窃听攻击的可能性。但是，在不支持DTLS-SRTP的环境中，不会签署任何字段，也不会提供任何保护。
Armed with the original value of the To header field, the recipient of a request may be tempted to compare it to their own identity in order to determine whether or not the identity information in this call might have been replayed. However, any request may be legitimately retargeted as well, and as a result legitimate requests may reach a SIP endpoint whose user is not identified by the URI designated in the To header field value. It is therefore difficult for any verifier to decide whether or not some prior retargeting was "legitimate". Retargeting can also cause confusion when identity information is provided for requests sent in the backwards direction in a dialog, as the dialog identifiers may not match credentials held by the ultimate target of the dialog. For further information on the problems of response identity, see [SIP-RETARGET].
使用To header字段的原始值，请求的接收者可能会尝试将其与自己的身份进行比较，以确定此调用中的身份信息是否可能已被重播。然而，任何请求也可以被合法地重定目标，并且作为结果，合法请求可以到达SIP端点，该SIP端点的用户不由To header字段值中指定的URI标识。因此，任何验证者都很难决定之前的某个重定目标是否“合法”。当为对话框中向后发送的请求提供标识信息时，重定目标也会导致混淆，因为对话框标识符可能与对话框最终目标持有的凭据不匹配。有关响应标识问题的更多信息，请参阅[SIP-RETARGET]。
Any means for authentication services or verifiers to anticipate retargeting is outside the scope of this document and is likely to have the same applicability to response identity as it does to requests in the backwards direction within a dialog. Consequently, no special guidance is given for implementers here regarding the "connected party" problem (see [RFC4916]); authentication service behavior is unchanged if retargeting has occurred for a dialog-forming request. Ultimately, the authentication service provides an Identity header field for requests in the dialog only when the user is authorized to assert the identity given in the From header field, and if they are not, an Identity header field is not provided. And per the threat model of [RFC7375], resolving problems with "connected" identity has little bearing on detecting robocalling or related impersonation attacks.
身份验证服务或验证器预期重定目标的任何方法都不在本文档的范围内，并且可能对响应标识具有与对对话框中反向请求相同的适用性。因此，此处没有针对“关联方”问题为实施者提供特别指导（参见[RFC4916]）；如果对形成对话框的请求进行了重定目标，则身份验证服务行为将保持不变。最终，身份验证服务仅在用户有权断言“发件人”标头字段中给出的标识时，才为对话框中的请求提供标识标头字段，如果没有，则不提供标识标头字段。根据[RFC7375]的威胁模型，解决“连接”身份的问题对检测机器人定位或相关模拟攻击几乎没有影响。
[RFC4474] originally provided protections for Contact, Call-ID, and CSeq. This document removes protection for these fields. The absence of these header field values creates some opportunities for determined attackers to impersonate based on cut-and-paste attacks; however, the absence of these header field values does not seem impactful to the primary focus of this document, which is the prevention of the simple unauthorized claiming of an identity for the purposes of robocalling, voicemail hacking, or swatting.
[RFC4474]最初为联系人、呼叫ID和CSeq提供保护。此文档将删除对这些字段的保护。缺少这些头字段值会为已确定的攻击者创造一些机会，使其能够基于剪切和粘贴攻击进行模拟；但是，缺少这些标题字段值似乎对本文档的主要重点没有影响，这是为了防止简单的未经授权的身份声明，用于机器人定位、语音邮件攻击或打拍。
It might seem attractive to provide a signature over some of the information present in the Via header field value(s). For example, without a signature over the sent-by field of the topmost Via header field, an attacker could remove that Via header field and insert its own in a cut-and-paste attack, which would cause all responses to the request to be routed to a host of the attacker's choosing. However, a signature over the topmost Via header field does not prevent attacks of this nature, since the attacker could leave the topmost Via intact and merely insert a new Via header field directly after it, which would cause responses to be routed to the attacker's host "on their way" to the valid host; the end result would be exactly the same. Although it is possible that an intermediary-based authentication service could guarantee that no Via hops are inserted between the sending UA and the authentication service, it could not prevent an attacker from adding a Via hop after the authentication service and thereby preempting responses. It is necessary for the proper operation of SIP for subsequent intermediaries to be capable of inserting such Via header fields, and thus it cannot be prevented. As such, though it is desirable, securing Via is not possible through the sort of identity mechanism described in this document; the best known practice for securing Via is the use of SIPS.
在Via头字段值中存在的一些信息上提供签名似乎很有吸引力。例如，在最顶端的Via标头字段的sent by字段上没有签名的情况下，攻击者可以删除该Via标头字段并在剪切粘贴攻击中插入自己的签名，这将导致对请求的所有响应路由到攻击者选择的主机。但是，最顶端的Via头字段上的签名并不能阻止这种性质的攻击，因为攻击者可以保持最顶端的Via原封不动，只在其后面直接插入一个新的Via头字段，这将导致响应被路由到攻击者的主机“途中”到有效主机；最终结果将完全相同。尽管基于中间层的认证服务可能会保证在发送UA和认证服务之间不会插入任何过孔跃点，但它无法阻止攻击者在认证服务之后添加过孔跃点，从而抢占响应。为了使后续中介能够插入这样的Via头字段，SIP的正确操作是必要的，因此不能阻止。因此，尽管需要，但不可能通过本文件中描述的身份机制来保护Via；保护通孔的最佳实践是使用SIP。
In the end analysis, the Identity header field cannot protect itself. Any attacker could remove the header field from a SIP request and modify the request arbitrarily afterwards. However, this mechanism is not intended to protect requests from men-in-the-middle who interfere with SIP messages; it is intended only to provide a way that the originators of SIP requests can prove that they are who they claim to be. At best, by stripping identity information from a request, a man-in-the-middle could make it impossible to distinguish any illegitimate messages he would like to send from those messages sent by an authorized user. However, it requires a considerably greater amount of energy to mount such an attack than it does to mount trivial impersonations by just copying someone else's
在最终分析中，标识头字段无法保护自身。任何攻击者都可以从SIP请求中删除header字段，然后任意修改该请求。然而，该机制并不打算保护来自中间人的请求，中间人干扰SIP消息；其目的仅在于提供一种方式，使SIP请求的发起人能够证明他们是他们所声称的人。充其量，通过从请求中剥离身份信息，中间人可能无法区分他想要发送的任何非法消息和授权用户发送的消息。然而，发动这样的攻击需要相当大的能量，而不是仅仅通过复制别人的攻击来发动微不足道的模拟
From header field. This mechanism provides a way that an authorized user can provide a definitive assurance of his identity that an unauthorized user, an impersonator, cannot.
从标题字段。这种机制提供了一种方式，授权用户可以提供其身份的最终保证，而未经授权的用户（冒名顶替者）不能。
In the absence of UA-based authentication services, the assurance provided by this mechanism is strongest when a UA forms a direct connection, preferably one secured by TLS, to an intermediary-based authentication service. The reasons for this are twofold:
在缺乏基于UA的认证服务的情况下，当UA与基于中介的认证服务形成直接连接（优选由TLS保护的连接）时，该机制提供的保证最强。原因有两方面：
o If a user does not receive a certificate from the authentication service over the TLS connection that corresponds to the expected domain (especially when the user receives a challenge via a mechanism such as Digest), then it is possible that a rogue server is attempting to pose as an authentication service for a domain that it does not control, possibly in an attempt to collect shared secrets for that domain. A similar practice could be used for telephone numbers, though the application of certificates for telephone numbers to TLS is left as a matter for future study.
o 如果用户没有通过与预期域对应的TLS连接从身份验证服务接收到证书（特别是当用户通过诸如摘要之类的机制接收质询时），则流氓服务器可能正试图充当其不控制的域的身份验证服务，可能是为了收集该域的共享机密。电话号码也可以采用类似的做法，但电话号码证书在TLS中的应用将留待将来研究。
o Without TLS, the various header field values and the body of the request will not have integrity protection when the request arrives at an authentication service. Accordingly, a prior legitimate or illegitimate intermediary could modify the message arbitrarily.
o 如果没有TLS，当请求到达身份验证服务时，各种头字段值和请求主体将没有完整性保护。因此，先前合法或非法的中间人可以任意修改电文。
Of these two concerns, the first is most material to the intended scope of this mechanism. This mechanism is intended to prevent impersonation attacks, not man-in-the-middle attacks; integrity over parts of the header and body is provided by this mechanism only to prevent replay attacks. However, it is possible that applications relying on the presence of the Identity header field could leverage this integrity protection for services other than replay protection.
在这两个问题中，第一个问题对这一机制的预期范围最为重要。此机制旨在防止模拟攻击，而不是中间人攻击；此机制仅为防止重播攻击而提供头部和主体部分的完整性。但是，依赖于Identity header字段存在的应用程序可能会将此完整性保护用于重播保护以外的服务。
Accordingly, direct TLS connections SHOULD be used between the UA client (UAC) and the authentication service whenever possible. The opportunistic nature of this mechanism, however, makes it very difficult to constrain UAC behavior, and moreover there will be some deployment architectures where a direct connection is simply infeasible and the UAC cannot act as an authentication service itself. Accordingly, when a direct connection and TLS are not possible, a UAC should use the SIPS mechanism, Digest "auth-int" for body integrity, or both when it can. The ultimate decision to add an Identity header field to a request lies with the authentication service, of course; domain policy must identify those cases where the UAC's security association with the authentication service is too weak.
因此，UA客户端（UAC）和身份验证服务之间应尽可能使用直接TLS连接。然而，这种机制的机会主义性质使得很难约束UAC行为，而且会有一些部署架构，其中直接连接根本不可行，UAC本身不能充当身份验证服务。因此，当无法实现直接连接和TLS时，UAC应使用SIPS机制，或在可能的情况下使用“auth int”来实现身体完整性，或同时使用两者。当然，向请求添加标识头字段的最终决定取决于身份验证服务；域策略必须识别UAC与身份验证服务的安全关联太弱的情况。
Ultimately, the worth of an assurance provided by an Identity header field is limited by the security practices of the authentication service that issues the assurance. Relying on an Identity header field generated by a remote administrative domain assumes that the issuing domain uses recommended administrative practices to authenticate its users. However, it is possible that some authentication services will implement policies that effectively make users unaccountable (e.g., ones that accept unauthenticated registrations from arbitrary users). The value of an Identity header field from such authentication services is questionable. While there is no magic way for a verifier to distinguish "good" from "bad" signers by inspecting a SIP request, it is expected that further work in authorization practices could be built on top of this identity solution; without such an identity solution, many promising approaches to authorization policy are impossible. That much said, it is RECOMMENDED that authentication services based on proxy servers employ strong authentication practices.
最终，由标识头字段提供的保证的价值受到发布保证的身份验证服务的安全实践的限制。依赖于远程管理域生成的标识头字段，假定颁发域使用推荐的管理实践对其用户进行身份验证。但是，某些身份验证服务可能会实施有效地使用户不负责任的策略（例如，接受任意用户未经身份验证的注册的服务）。来自此类身份验证服务的标识头字段的值值得怀疑。虽然验证者没有神奇的方法通过检查SIP请求来区分“好”和“坏”签名者，但预计可以在此身份解决方案的基础上进一步开展授权实践工作；没有这样的身份解决方案，许多有前途的授权策略方法是不可能的。话虽如此，建议基于代理服务器的身份验证服务采用强大的身份验证实践。
One cannot expect the Identity header field to be supported by every SIP entity overnight. This leaves the verifier in a difficult position; when it receives a request from a given SIP user, how can it know whether or not the originator's domain supports Identity? In the absence of ubiquitous support for Identity, some transitional strategies are necessary.
不能期望每个SIP实体一夜之间都支持标识头字段。这使得验证者处于困难的境地；当它收到来自给定SIP用户的请求时，如何知道发端人的域是否支持标识？在缺乏对身份的普遍支持的情况下，一些过渡策略是必要的。
o A verifier could remember when it receives a request from a domain or telephone number that uses Identity and, in the future, view messages received from that source without an Identity header field with skepticism.
o 验证器可以记住何时收到来自使用标识的域或电话号码的请求，并在将来以怀疑的态度查看从该源收到的消息，而不使用标识头字段。
o A verifier could consult some sort of directory that indicates whether a given caller should have a signed identity. There are a number of potential ways in which this could be implemented. This is left as a subject for future work.
o 验证器可以查询某种目录，该目录指示给定的调用方是否应该具有签名标识。有许多可能的方法可以实现这一点。这是留给今后工作的一个主题。
In the long term, some sort of identity mechanism, either the one documented in this specification or a successor, must become mandatory-to-use for SIP; that is the only way to guarantee that this protection can always be expected by verifiers.
从长远来看，某种身份机制（本规范中记录的身份机制或后续身份机制）必须强制用于SIP；这是确保验证者始终可以期望这种保护的唯一方法。
Finally, it is worth noting that the presence or absence of the Identity header fields cannot be the sole factor in making an authorization decision. Permissions might be granted to a message on the basis of the specific verified Identity or really on any other aspect of a SIP request. Authorization policies are outside the
最后，值得注意的是，标识头字段的存在与否不能成为做出授权决策的唯一因素。可以根据特定的已验证身份或SIP请求的任何其他方面向消息授予权限。授权策略不在
scope of this specification, but this specification advises any future authorization work not to assume that messages with valid Identity header fields are always good.
本规范的范围，但本规范建议任何未来的授权工作不要假设具有有效标识头字段的消息总是好的。
As a matter of interface design, SIP UAs might render the display-name portion of the From header field of a caller as the identity of the caller; there is a significant precedent in email user interfaces for this practice. Securing the display-name component of the From header field value is outside the scope of this document but may be the subject of future work, such as through the "ppt" name mechanism.
作为接口设计的问题，SIP UAs可能将呼叫者的From报头字段的显示名称部分呈现为呼叫者的身份；这种做法在电子邮件用户界面中有一个重要的先例。保护From header字段值的显示名称组件不在本文档范围内，但可能是未来工作的主题，例如通过“ppt”名称机制。
In the absence of signing the display-name, authentication services might check and validate it, and compare it to a list of acceptable display-names that may be used by the originator; if the display-name does not meet policy constraints, the authentication service could return a 403 response code. In this case, the reason phrase should indicate the nature of the problem: for example, "Inappropriate Display Name". However, the display-name is not always present, and in many environments the requisite operational procedures for display-name validation may not exist, so no normative guidance is given here.
在没有对显示名称进行签名的情况下，身份验证服务可能会对其进行检查和验证，并将其与发端人可能使用的可接受显示名称列表进行比较；如果显示名称不符合策略约束，则身份验证服务可能返回403响应代码。在这种情况下，原因短语应表明问题的性质：例如，“不适当的显示名称”。但是，显示名称并不总是存在，而且在许多环境中，可能不存在显示名称验证所需的操作程序，因此此处未给出规范性指导。
IANA has completed a number of actions described in this document. Primarily, the previous references to [RFC4474] in the "Session Initiation Protocol (SIP) Parameters" registry have been updated to point to this document, unless specified otherwise below.
IANA已完成本文件中描述的多项行动。首先，除非下文另有规定，否则“会话启动协议（SIP）参数”注册表中先前对[RFC4474]的引用已更新为指向本文档。
The Identity-Info header in the SIP "Header Fields" registry has been marked as deprecated by this document.
此文档已将SIP“header Fields”注册表中的Identity Info标头标记为已弃用。
Also, the Identity-Info header reserved the compact form "n" at its time of registration. That compact form has been removed from the registry. The Identity header, however, retains the compact form "y" reserved by [RFC4474].
此外，Identity Info报头在注册时保留了压缩格式“n”。该压缩表格已从注册表中删除。但是，标识标头保留[RFC4474]保留的紧凑形式“y”。
The 436 "Bad Identity-Info" default reason phrase has been changed to "Bad Identity Info" in the SIP "Response Codes" registry.
在SIP“响应代码”注册表中，436“错误标识信息”默认原因短语已更改为“错误标识信息”。
The 437 "Unsupported Certificate" default reason phrase has been changed to "Unsupported Credential".
437“不支持的证书”默认原因短语已更改为“不支持的凭据”。
IANA manages a registry for Identity-Info parameters. Per this specification, IANA has changed the name of this registry to "Identity Parameters".
IANA管理标识信息参数的注册表。根据此规范，IANA已将此注册表的名称更改为“标识参数”。
This specification defines one new value for the registry: "info" as defined in Section 7.3.
本规范为注册表定义了一个新值：第7.3节中定义的“info”。
IANA managed an "Identity-Info Algorithm Parameter Values" registry; per this specification, IANA has deprecated and closed this registry. Since the algorithms for signing PASSporTs are defined in [RFC8225] rather than in this specification, there is no longer a need for an algorithm parameter registry for the Identity header field.
IANA管理“身份信息算法参数值”注册表；根据此规范，IANA已弃用并关闭此注册表。由于签署护照的算法在[RFC8225]中定义，而不是在本规范中定义，因此不再需要为标识标头字段提供算法参数注册表。
The following are salient changes from the original RFC 4474:
以下是原始RFC 4474的显著变化：
o The credential mechanism has been generalized; credential enrollment, acquisition, and trust are now outside the scope of this document.
o 证书机制已被推广；凭证注册、获取和信任现在不在本文档的范围内。
o This document reduces the scope of the Identity signature to remove CSeq, Call-ID, Contact, and the message body; signing of key fingerprints in SDP is now included.
o 本文档缩小了身份签名的范围，以删除CSeq、呼叫ID、联系人和消息正文；SDP中的密钥指纹签名现在包括在内。
o The Identity-Info header field has been deprecated, and its components have been relocated into parameters of the Identity header field (which obsoletes the previous version of the header field).
o Identity Info header字段已被弃用，其组件已重新定位到Identity header字段的参数中（这将淘汰先前版本的header字段）。
o The Identity header field can now appear multiple times in one request.
o Identity header字段现在可以在一个请求中出现多次。
o The previous signed-identity-digest format has been replaced with PASSporT (signing algorithms are now defined in a separate specification).
o 以前的签名身份摘要格式已替换为PASSporT（签名算法现在在单独的规范中定义）。
o Status code descriptions have been revised.
o 状态代码说明已修订。
[E.164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164/en>.
[E.164]国际电信联盟，“国际公共电信编号计划”，ITU-T建议E.164，2010年11月<https://www.itu.int/rec/T-REC-E.164/en>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，DOI 10.17487/RFC3263，2002年6月<https://www.rfc-editor.org/info/rfc3263>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <https://www.rfc-editor.org/info/rfc3966>.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，DOI 10.17487/RFC3966，2004年12月<https://www.rfc-editor.org/info/rfc3966>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, DOI 10.17487/RFC5922, June 2010, <https://www.rfc-editor.org/info/rfc5922>.
[RFC5922]Gurbani，V.，Lawrence，S.，和A.Jeffrey，“会话启动协议（SIP）中的域证书”，RFC 5922，DOI 10.17487/RFC5922，2010年6月<https://www.rfc-editor.org/info/rfc5922>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[RFC8225]Wendt，C.和J.Peterson，“护照：个人主张令牌”，RFC 8225，DOI 10.17487/RFC82252018年2月<https://www.rfc-editor.org/info/rfc8225>.
[CIDER] Kaplan, H., "A proposal for Caller Identity in a DNS-based Entrusted Registry (CIDER)", Work in Progress, draft-kaplan-stir-cider-00, July 2013.
[CIDER]Kaplan，H.，“基于DNS的委托注册（CIDER）中呼叫方身份的建议”，正在进行的工作，草稿-Kaplan-stir-CIDER-00，2013年7月。
[IRI-COMPARISON] Masinter, L. and M. Duerst, "Comparison, Equivalence and Canonicalization of Internationalized Resource Identifiers", Work in Progress, draft-ietf-iri-comparison-02, October 2012.
[IRI-COMPARISON]Masinter，L.和M.Duerst，“国际化资源标识符的比较、等效和规范化”，正在进行的工作，草案-ietf-IRI-COMPARISON-022012年10月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC2585]Housley，R.和P.Hoffman，“互联网X.509公钥基础设施操作协议：FTP和HTTP”，RFC 2585，DOI 10.17487/RFC2585，1999年5月<https://www.rfc-editor.org/info/rfc2585>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC 3323，DOI 10.17487/RFC3323，2002年11月<https://www.rfc-editor.org/info/rfc3323>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<https://www.rfc-editor.org/info/rfc3325>.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, DOI 10.17487/RFC3893, September 2004, <https://www.rfc-editor.org/info/rfc3893>.
[RFC3893]Peterson，J.，“会话启动协议（SIP）认证身份主体（AIB）格式”，RFC 3893，DOI 10.17487/RFC3893，2004年9月<https://www.rfc-editor.org/info/rfc3893>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-editor.org/info/rfc4474>.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，DOI 10.17487/RFC4474，2006年8月<https://www.rfc-editor.org/info/rfc4474>.
[RFC4501] Josefsson, S., "Domain Name System Uniform Resource Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, <https://www.rfc-editor.org/info/rfc4501>.
[RFC4501]Josefsson，S.，“域名系统统一资源标识符”，RFC 4501，DOI 10.17487/RFC4501，2006年5月<https://www.rfc-editor.org/info/rfc4501>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, <https://www.rfc-editor.org/info/rfc4916>.
[RFC4916]Elwell，J.“会话启动协议（SIP）中的连接标识”，RFC 4916，DOI 10.17487/RFC4916，2007年6月<https://www.rfc-editor.org/info/rfc4916>.
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, DOI 10.17487/RFC5393, December 2008, <https://www.rfc-editor.org/info/rfc5393>.
[RFC5393]Sparks，R.，Ed.，Lawrence，S.，Hawrylyshen，A.，和B.Campen，“解决会话启动协议（SIP）分叉代理中的放大漏洞”，RFC 5393，DOI 10.17487/RFC5393，2008年12月<https://www.rfc-editor.org/info/rfc5393>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5763]Fischl，J.，Tschofenig，H.，和E.Rescorla，“使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”，RFC 5763，DOI 10.17487/RFC5763，2010年5月<https://www.rfc-editor.org/info/rfc5763>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<https://www.rfc-editor.org/info/rfc6698>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<https://www.rfc-editor.org/info/rfc6973>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, <https://www.rfc-editor.org/info/rfc7340>.
[RFC7340]Peterson，J.，Schulzrinne，H.和H.Tschofenig，“安全电话身份问题声明和要求”，RFC 7340，DOI 10.17487/RFC7340，2014年9月<https://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, DOI 10.17487/RFC7375, October 2014, <https://www.rfc-editor.org/info/rfc7375>.
[RFC7375]Peterson，J.，“安全电话身份威胁模型”，RFC 7375，DOI 10.17487/RFC7375，2014年10月<https://www.rfc-editor.org/info/rfc7375>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<https://www.rfc-editor.org/info/rfc7519>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>.
[RFC8226]Peterson，J.和S.Turner，“安全电话身份凭证：证书”，RFC 8226，DOI 10.17487/RFC8226，2018年2月<https://www.rfc-editor.org/info/rfc8226>.
[SIP-RETARGET] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, draft-peterson-sipping-retarget-00, February 2005.
[SIP-RETARGET]Peterson，J.，“SIP中的重定目标和安全：框架和要求”，正在进行的工作，草稿-Peterson-sipping-RETARGET-00，2005年2月。
[SIP-RFC4474-CONCERNS] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, draft-rosenberg-sip-rfc4474- concerns-00, February 2008.
[SIP-RFC4474-关注点]Rosenberg，J.，“关于RFC 4474适用性的关注点”，正在进行的工作，草稿-Rosenberg-SIP-RFC4474-关注点-00，2008年2月。
[TS-3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 7.7.0, March 2007, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[TS-3GPP.23.228]3GPP，“IP多媒体子系统（IMS）；第2阶段”，3GPP TS 23.228 7.7.012007年3月<http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
Acknowledgments
致谢
The authors would like to thank Adam Roach, Jim Schaad, Ning Zhang, Syed Ali, Olle Jacobson, Dave Frankel, Robert Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex Bobotek, Paul Kyzivat, Jonathan Lennox, Richard Shockey, Martin Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for their comments.
作者要感谢亚当·罗奇、吉姆·沙德、张宁、赛义德·阿里、奥利·雅各布森、戴夫·弗兰克尔、罗伯特·斯帕克斯、戴夫·克罗克、斯蒂芬·肯特、布赖恩·罗森、亚历克斯·博博博泰克、保罗·基齐瓦特、乔纳森·伦诺克斯、理查德·肖基、马丁·多利、安德鲁·艾伦、哈德里尔·卡普兰、桑杰·米什拉、安东·巴斯科夫、皮尔斯·戈尔曼、大卫·施瓦茨、埃里克·伯格、，艾伦·福特、克里斯特·霍姆伯格、菲利普·福夸特、迈克尔·哈默、亨宁·舒尔兹林纳和理查德·巴恩斯感谢他们的评论。
Authors' Addresses
作者地址
Jon Peterson Neustar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America
Jon Peterson Neustar，Inc.美国加利福尼亚州康科德市萨特街1800号570室，邮编：94520
Email: jon.peterson@neustar.biz
Email: jon.peterson@neustar.biz
Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada
Cullen Jennings Cisco 400加拿大卡尔加里第三大道西南350号套房T2P 4H2
Email: fluffy@cisco.com
Email: fluffy@cisco.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 United States of America
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
Email: ekr@rtfm.com
Email: ekr@rtfm.com
Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 United States of America
Chris Wendt Comcast美国宾夕法尼亚州费城Comcast中心一号，邮编：19103
Email: chris-ietf@chriswendt.net
Email: chris-ietf@chriswendt.net