Internet Engineering Task Force (IETF)                          C. Wendt
Request for Comments: 8588                                       Comcast
Category: Standards Track                                      M. Barnes
ISSN: 2070-1721                                                iconectiv
                                                                May 2019
        
Internet Engineering Task Force (IETF)                          C. Wendt
Request for Comments: 8588                                       Comcast
Category: Standards Track                                      M. Barnes
ISSN: 2070-1721                                                iconectiv
                                                                May 2019
        

Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)

个人断言令牌(PaSSporT)扩展,用于使用令牌(SHAKEN)对断言信息进行基于签名的处理

Abstract

摘要

This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network.

本文档扩展了Personal Assertion Token(PASSporT),它是一个令牌对象,用于传递有关通信参与者的加密签名信息。该扩展是根据ATIS/SIP Forum IP-NNI任务组的“使用令牌(SHAKEN)对断言信息进行基于签名的处理”规范定义的。它提供了(1)对基于SIP的电话网络中发起的呼叫的发起标识的正确性的特定置信度集,以及(2)允许服务提供商(SP)在其网络中唯一标识呼叫的发起的标识符。

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/rfc8588.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问https://www.rfc-editor.org/info/rfc8588.

Copyright Notice

版权公告

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

版权(c)2019 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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of   "shaken" PASSporT Extension . . . . . . . . . .   4
   4.  PASSporT "attest" Claim . . . . . . . . . . . . . . . . . . .   4
   5.  PASSporT "origid" Claim . . . . . . . . . . . . . . . . . . .   4
   6.  Example "shaken" PASSporT . . . . . . . . . . . . . . . . . .   5
   7.  Using "shaken" in SIP . . . . . . . . . . . . . . . . . . . .   5
   8.  Order of Claim Keys . . . . . . . . . . . . . . . . . . . . .   5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  JSON Web Token claims  . . . . . . . . . . . . . . . . .   7
     11.2.  PASSporT Types . . . . . . . . . . . . . . . . . . . . .   7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     12.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of   "shaken" PASSporT Extension . . . . . . . . . .   4
   4.  PASSporT "attest" Claim . . . . . . . . . . . . . . . . . . .   4
   5.  PASSporT "origid" Claim . . . . . . . . . . . . . . . . . . .   4
   6.  Example "shaken" PASSporT . . . . . . . . . . . . . . . . . .   5
   7.  Using "shaken" in SIP . . . . . . . . . . . . . . . . . . . .   5
   8.  Order of Claim Keys . . . . . . . . . . . . . . . . . . . . .   5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  JSON Web Token claims  . . . . . . . . . . . . . . . . .   7
     11.2.  PASSporT Types . . . . . . . . . . . . . . . . . . . . .   7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     12.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
        
1. Introduction
1. 介绍

The Signature-based Handling of Asserted information using toKENs (SHAKEN) [ATIS-1000074] specification defines a framework for using Secure Telephone Identity Revisited (STIR) protocols including the Personal Assertion Token (PASSporT) [RFC8225], SIP Authenticated Identity Management [RFC8224], and the STIR certificate framework [RFC8226] for implementing the cryptographic validation of an authorized originator of telephone calls using SIP. Because the current telephone network contains traffic originated from both VoIP and TDM/SS7 (Time Division Multiplexing / Signaling System 7), there are many scenarios that need to be accounted for where PASSporT signatures may represent either direct or indirect call origination scenarios. The SHAKEN [ATIS-1000074] specification defines levels of attestation of the origination of the call as well as an origination identifier that can help create a unique association between the origin of a particular call to the point in the VoIP or TDM telephone network the call came from to identify, for example, either a customer or class of service that call represents. This document specifies these values as claims to extend the base set of PASSporT claims.

使用令牌(shaked)[ATIS-1000074]规范对断言信息的基于签名的处理定义了使用安全电话身份重访(STIR)协议的框架,包括个人断言令牌(PASSporT)[RFC8225]、SIP认证身份管理[RFC8224]和STIR证书框架[RFC8226]用于使用SIP实现电话呼叫授权发起人的密码验证。由于当前电话网络包含来自VoIP和TDM/SS7(时分多路复用/信令系统7)的流量,因此需要考虑许多场景,其中PASSporT签名可能代表直接或间接呼叫发起场景。SHAKEN[ATIS-1000074]规范定义了呼叫发起的认证级别以及发起标识符,可帮助在特定呼叫的发起与VoIP或TDM电话网络中呼叫来源点之间创建唯一关联,以识别呼叫,例如,呼叫所代表的客户或服务类别。本文档将这些值指定为声明,以扩展PASSporT声明的基本集。

2. Terminology
2. 术语

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] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时(如图所示)应按照BCP 14[RFC2119][RFC8174]所述进行解释。

In addition, the following terms are used in this document:

此外,本文件中使用了以下术语:

o Verified association: Typically defined as an authenticated relationship between a customer and a device that initiated a call on behalf of that customer, for example, a subscriber account with a specific SIM card or set of SIP credentials.

o 验证关联:通常定义为客户和代表该客户发起呼叫的设备之间的验证关系,例如,具有特定SIM卡或SIP凭据集的用户帐户。

o PASSporT: Defined in [RFC8225] is a JSON Web Token [RFC7519] defined specifically for securing the identity of an initiator of personal communication. This document defines a specific extension to PASSporT.

o PASSporT:[RFC8225]中定义的是一个JSON Web令牌[RFC7519],专门用于保护个人通信发起人的身份。本文档定义了PASSporT的特定扩展。

3. Overview of "shaken" PASSporT Extension
3. “动摇”护照延期概述

The SHAKEN framework is designed to use PASSporT [RFC8225] as a method of asserting the caller's telephone identity. In addition to the PASSporT base claims, there are two additional claims that have been defined for the needs of a service provider to signal information beyond just the telephone identity. First, in order to help bridge the transition of the state of the current telephone network (which has calls with no authentication and non-SIP [RFC3261] signaling not compatible with the use of PASSporT and Secure Telephone Identity (STI) in general), there is an attestation claim. This provides three levels of attestation: a full attestation when the service provider can fully attest to the calling identity, a partial attestation when the service provider originated a telephone call but cannot fully attest to the calling identity, and a gateway attestation, which is the lowest level of attestation and represents the service provider receiving a call from a telephone gateway that does not support PASSporT or STI.

SHAKEN框架旨在使用PASSporT[RFC8225]作为断言呼叫方电话身份的方法。除了PASSporT基本权利要求外,还有两项附加权利要求是为了满足服务提供商发送电话身份以外的信息的需要而定义的。首先,为了帮助弥合当前电话网络状态的转变(其呼叫没有身份验证,且非SIP[RFC3261]信令与PASSporT和Secure telephone Identity(STI)的使用不兼容),存在一个认证声明。这提供了三个级别的认证:当服务提供商可以完全认证主叫身份时的完全认证,当服务提供商发起电话呼叫但不能完全认证主叫身份时的部分认证,以及网关认证,这是最低级别的认证,代表服务提供商从不支持PASSporT或STI的电话网关接收呼叫。

The second claim is a unique origination identifier that should be used by the service provider to identify different sources of telephone calls to support a traceback mechanism that can be used for enforcement and identification of a source of illegitimate calls.

第二项权利要求是唯一的发起标识符,服务提供商应使用该标识符识别不同的电话呼叫源,以支持可用于强制执行和识别非法呼叫源的回溯机制。

The use of the compact form of PASSporT is not specified in this document and is not specified for use in SHAKEN [ATIS-1000074].

本文件中未规定使用紧凑型护照,也未规定在SHAKEN[ATIS-1000074]中使用。

The next two sections define these new claims.

接下来的两个部分定义了这些新的权利要求。

4. PASSporT "attest" Claim
4. 护照“证明”索赔

This indicator allows for both identifying the service provider that is vouching for the call as well as clearly indicating what information the service provider is attesting to. The "attest" claim can be one of the following three values: 'A', 'B', or 'C'. These values correspond to 'Full Attestation', 'Partial Attestation', and 'Gateway Attestation', respectively. See [ATIS-1000074] for the definitions of these three levels of attestation.

此指示器既可以识别为呼叫提供担保的服务提供商,也可以清楚地指示服务提供商正在证明的信息。“证明”声明可以是以下三个值之一:“A”、“B”或“C”。这些值分别对应于“完全认证”、“部分认证”和“网关认证”。有关这三个认证级别的定义,请参见[ATIS-1000074]。

5. PASSporT "origid" Claim
5. 护照“origid”索赔

The purpose of the "origid" claim is described in [ATIS-1000074]. The value of "origid" claim is a Universally Unique Identifier (UUID) as defined in [RFC4122]. Please refer to Section 10 for a discussion of the privacy considerations around the use of this value.

[ATIS-1000074]中描述了“origid”索赔的目的。“origid”声明的值是[RFC4122]中定义的通用唯一标识符(UUID)。请参阅第10节,了解有关使用此值的隐私注意事项的讨论。

6. Example "shaken" PASSporT
6. “摇晃”护照示例
   Protected Header
   {
      "alg":"ES256",
      "typ":"passport",
      "ppt":"shaken",
      "x5u":"https://cert.example.org/passport.cer"
   }
   Payload
   {
      "attest":"A"
      "dest":{"tn":["12155550131"]}
      "iat":"1443208345",
      "orig":{"tn":"12155550121"},
      "origid":"123e4567-e89b-12d3-a456-426655440000"
   }
        
   Protected Header
   {
      "alg":"ES256",
      "typ":"passport",
      "ppt":"shaken",
      "x5u":"https://cert.example.org/passport.cer"
   }
   Payload
   {
      "attest":"A"
      "dest":{"tn":["12155550131"]}
      "iat":"1443208345",
      "orig":{"tn":"12155550121"},
      "origid":"123e4567-e89b-12d3-a456-426655440000"
   }
        
7. Using "shaken" in SIP
7. 在SIP中使用shaken

The use of the "shaken" PASSporT type and the "attest" and "origid" claims for SIP is formally defined in [ATIS-1000074] using the SIP [RFC3261] Identity header field defined in [RFC8224].

[ATIS-1000074]使用[RFC8224]中定义的SIP[RFC3261]标识头字段,对SIP使用“摇晃”护照类型以及“认证”和“origid”声明进行了正式定义。

8. Order of Claim Keys
8. 领取钥匙的次序

The order of the claim keys MUST follow the rules of Section 9 of [RFC8225]; the claim keys MUST appear in lexicographic order. Therefore, the claim keys discussed in this document appear in the PASSporT Payload in the following order:

索赔钥匙的顺序必须遵循[RFC8225]第9节的规则;声明密钥必须按字典顺序出现。因此,本文档中讨论的索赔密钥按以下顺序出现在PASSporT有效载荷中:

o attest

o 证明

o dest

o 目的地

o iat

o iat

o orig

o 原

o origid

o 奥里吉德

9. Security Considerations
9. 安全考虑

This document defines a new PASSporT [RFC8225] extension. The considerations related to the security of the PASSporT object itself are the same as those described in [RFC8225].

本文档定义了一个新的PASSporT[RFC8225]扩展名。与PASSporT对象本身的安全性相关的注意事项与[RFC8225]中所述的注意事项相同。

[RFC8224] defines how to compare the values of the "dest", "orig", and "iat" claims against fields in a SIP message containing a PASSporT as part of validating that request. The values of the new "attest" and "origid" claims added by this extension are not used in such a validation step. They are not compared to fields in the SIP message. Instead, they simply carry additional information from the signer to the consumer of the PASSporT. This new information shares the same integrity protection and non-repudiation properties as the base claims in the PASSporT.

[RFC8224]定义了如何将“dest”、“orig”和“iat”声明的值与包含PASSporT的SIP消息中的字段进行比较,作为验证该请求的一部分。由该扩展添加的新“认证”和“origid”声明的值不用于此类验证步骤。它们不会与SIP消息中的字段进行比较。相反,它们只是将附加信息从签名者传递给护照的消费者。此新信息与PASSporT中的基本声明具有相同的完整性保护和不可否认性属性。

10. Privacy Considerations
10. 隐私考虑

As detailed in Section 26 of [RFC3261], SIP messages inherently carry identifying information of the caller and callee. The addition of STIR cryptographically attests that the signing party vouches for the information given about the callee, as is discussed in the Privacy Considerations of [RFC8224].

如[RFC3261]第26节所述,SIP消息固有地携带呼叫者和被呼叫者的识别信息。STIR加密的增加证明签名方为被呼叫者的信息提供担保,如[RFC8224]隐私注意事项中所述。

SHAKEN [ATIS-1000074] furthermore adds an "origid" value to the STIR PASSporT, which is an opaque unique identifier representing an element on the path of a given SIP request. This identifier is generated by an originating telephone service provider to identify where within their network (e.g. a gateway or particular service element) a call was initiated; "origid" can facilitate forensic analysis of call origins when identifying and stopping bad actors trying to spoof identities or make fraudulent calls.

SHAKEN[ATIS-1000074]还向STIR PASSporT添加了一个“origid”值,这是一个不透明的唯一标识符,表示给定SIP请求路径上的元素。该标识符由始发电话服务提供商生成,以识别在其网络内(例如网关或特定服务元件)发起呼叫的位置;“origid”可以在识别和阻止试图伪造身份或拨打欺诈电话的不良行为者时,方便对呼叫来源进行法医分析。

The opacity of the "origid" claim value is intended to minimize exposure of information about the origination of calls labeled with an "origid" value. It is therefore RECOMMENDED that implementations generate a unique "origid" value per call in such a way that only the generator of the "origid" can determine when two "origid" values represent the same or different elements. If deployed systems instead use a common or related "origid" for service elements in their network, the potential for discovering patterns through correlation of those calls exists. This could allow a recipient of calls to, for instance, learn that a set of callers are using a particular service or coming through a common gateway. It is expected that SHAKEN PASSporTs are shared only within an [RFC3324] trust domain and will be stripped before calls exit that trust domain, but this information still could be used by analytics on

“origid”索赔值的不透明性旨在最大限度地减少有关标有“origid”值的呼叫发起信息的暴露。因此,建议实现在每次调用时生成唯一的“origid”值,以便只有“origid”的生成器才能确定两个“origid”值何时表示相同或不同的元素。如果部署的系统对其网络中的服务元素使用公共或相关的“origid”,则存在通过这些调用的关联发现模式的可能性。例如,这可以使呼叫接收者了解到一组呼叫者正在使用特定服务或通过公共网关。预计抖动的护照仅在[RFC3324]信任域内共享,并将在呼叫退出该信任域之前被剥离,但此信息仍可供上的分析使用

intermediary and terminating systems to reveal information that could include geographic location and even device-level information, depending on how the "origid" is generated.

中介和终端系统,根据“origid”的生成方式,显示可能包括地理位置甚至设备级信息的信息。

11. IANA Considerations
11. IANA考虑
11.1. JSON Web Token claims
11.1. JSON Web令牌声明

IANA has added two new claims to the "JSON Web Token Claims" registry as defined in [RFC7519].

IANA向[RFC7519]中定义的“JSON Web令牌声明”注册表添加了两个新声明。

Claim Name: attest Claim Description: Attestation level as defined in SHAKEN framework Change Controller: IESG Specification Document(s): RFC 8588

索赔名称:证明索赔描述:SHAKEN framework Change Controller中定义的证明级别:IESG规范文档:RFC 8588

Claim Name: origid Claim Description: Originating Identifier as defined in SHAKEN framework Change Controller: IESG Specification Document(s): RFC 8588

索赔名称:origid索赔描述:SHAKEN framework Change Controller中定义的原始标识符:IESG规范文档:RFC 8588

11.2. PASSporT Types
11.2. 护照类型

IANA has added a new entry in the "Personal Assertion Token (PASSporT) Extensions" registry for the type "shaken", which is specified in this document.

IANA在“个人断言令牌(PASSporT)扩展”注册表中为本文档中指定的类型“shaken”添加了一个新条目。

12. References
12. 工具书类
12.1. Normative References
12.1. 规范性引用文件

[ATIS-1000074] ATIS/SIP Forum IP-NNI Task Group, "Signature-based Handling of Asserted information using toKENs (SHAKEN)", January 2017, <https://access.atis.org/apps/group_public/ download.php/32237/ATIS-1000074.pdf>.

[ATIS-1000074]ATIS/SIP论坛IP-NNI任务组,“使用令牌(SHAKEN)对断言信息进行基于签名的处理”,2017年1月<https://access.atis.org/apps/group_public/ 下载:php/32237/ATIS-1000074.pdf>。

[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>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.

[RFC4122]Leach,P.,Mealling,M.和R.Salz,“通用唯一标识符(UUID)URN名称空间”,RFC 4122,DOI 10.17487/RFC4122,2005年7月<https://www.rfc-editor.org/info/rfc4122>.

[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>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174]Leiba,B.,“RFC 2119关键词中大写与小写的歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月<https://www.rfc-editor.org/info/rfc8174>.

[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.

[RFC8224]Peterson,J.,Jennings,C.,Rescorla,E.,和C.Wendt,“会话启动协议(SIP)中的身份验证管理”,RFC 8224,DOI 10.17487/RFC82242018年2月<https://www.rfc-editor.org/info/rfc8224>.

[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>.

[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>.

12.2. Informative References
12.2. 资料性引用

[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>.

[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, <https://www.rfc-editor.org/info/rfc3324>.

[RFC3324]Watson,M.,“网络断言身份的短期要求”,RFC 3324,DOI 10.17487/RFC3324,2002年11月<https://www.rfc-editor.org/info/rfc3324>.

Acknowledgements

致谢

The authors would like to thank those that helped review and contribute to this document including specific contributions from Jon Peterson, Russ Housley, Robert Sparks, and Andrew Jurczak. The authors would like to acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to develop the concepts behind this document.

作者要感谢帮助审查和贡献本文件的人,包括Jon Peterson、Russ Housley、Robert Sparks和Andrew Jurczak的具体贡献。作者希望感谢ATIS/SIP论坛IP-NNI工作组为开发本文件背后的概念所做的工作。

Authors' Addresses

作者地址

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
        

Mary Barnes iconectiv

玛丽·巴恩斯

   Email: mary.ietf.barnes@gmail.com
        
   Email: mary.ietf.barnes@gmail.com