[要約] RFC 8946は、転送された通話に関する情報を含むためのPersonal Assertion Token (PASSporT) 拡張を定義します。この文書の目的は、通話の転送が行われた際に、その事実と転送の経路を証明するための手段を提供することです。利用場面としては、通話の認証と承認、転送された通話の追跡、および通話転送に関連する詐欺や誤解を防ぐことが挙げられます。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8946 Neustar
Updates: 8224 February 2021
Category: Standards Track
ISSN: 2070-1721
Personal Assertion Token (PASSporT) Extension for Diverted Calls
Diperted呼び出しのための個人的なアサーショントークン（Passport）拡張子
Abstract
概要
The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios.
個人的なアサーショントークン（パスポート）は、個人的な通信に関わる人々に関する暗号的に署名された情報を伝えるためにRFC 8225で指定されています。このドキュメントはパスポートを拡張して、通話が元の宛先から新しい宛先に転用されたことを示しています。この情報は、呼転送シナリオで検証サービスによって行われた決定を大幅に向上させることができます。ここで指定されているとおりに指定されています。
This document updates RFC 8224.
この文書はRFC 8224を更新します。
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/rfc8946.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8946で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. The "div" PASSporT Type and Claim
4. Using "div" in SIP
4.1. Authentication Service Behavior
4.2. Verification Service Behavior
5. The "div-o" PASSporT Type
5.1. Processing "div-o" PASSporTs
6. Definition of "opt"
7. "div" and Redirection
8. Extending "div" to Work with Service Logic Tracking
9. IANA Considerations
9.1. JSON Web Token Claims Registrations
9.1.1. "div" registration
9.1.2. "opt" registration
9.2. PASSporT Type Registrations
10. Privacy Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Keys for Examples
Acknowledgments
Author's Address
A Personal Assertion Token (PASSporT) [RFC8225] is a token format based on the JSON Web Token (JWT) [RFC7519] for conveying cryptographically signed information about the people involved in personal communications; it is used by the Secure Telephone Identity Revisited (STIR) protocol [RFC8224] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to include an indication that a call has been diverted from its original destination to a new one.
個人的なアサーショントークン（Passport）[RFC8225]は、個人通信に関与する人々に関する暗号的に署名された情報を伝達するためのJSON Webトークン（JWT）[RFC7519]に基づくトークン形式です。SIPのようなプロトコルを介して確立されたリアルタイム通信における参加者の識別情報の符号付きアサーションを伝えるために、安全な電話アイデンティティの再検討（STIL）プロトコルで使用されます。この仕様はパスポートを拡張して、コールが元の宛先から新しい宛先に転用されたことを示すことを含めます。
Although the STIR problem statement [RFC7340] is focused on preventing the impersonation of the caller's identity, which is a common enabler for threats such as robocalling and voicemail hacking on the telephone network today, it also provides a signature over the called number at the time that the authentication service sees it. As [RFC8224], Section 12.1 describes, this protection over the contents of the To header field is intended to prevent a class of cut-and-paste attacks. If Alice calls Bob, for example, Bob might attempt to cut and paste the Identity header field in Alice's INVITE into a new INVITE that Bob sends to Carol, and thus be able to fool Carol into thinking the call came from Alice and not Bob. With the signature over the To header field value, the INVITE Carol sees will clearly have been destined originally for Bob, and thus Carol can view the INVITE as suspect.
攪拌問題ステートメント[RFC7340]は、ロボカールや電話網でのボイスメールのハッキングなどの脅威の一般的なイネーブラである発信者のアイデンティティの偽装を防ぐことに焦点を当てていますが、当時の着信番号の上に署名も提供します。認証サービスがそれを見ること。[RFC8224]として、セクション12.1は説明していますが、この保護は、Cut-Pasteのクラスの攻撃を防ぐことを目的としています。たとえば、AliceがBOBを呼び出す場合、BOBはAliceのInviteのIdentityヘッダーフィールドをBobがキャロルに送信する新しいINVITEにカットアンドペーストしようとする可能性があります。宛先宛先視野値の上に署名があると、Invite Carol Seesは明らかにボブ用に運ばれ、キャロールは疑問を疑わしいものとして見ることができます。
However, as [RFC8224], Section 12.1.1 points out, it is difficult for Carol to confirm or reject these suspicions based on the information she receives from the baseline PASSporT object. The common "call forwarding" service serves as a good example of the reality that the original called party number is not always the number to which a call is delivered. There are a number of potential ways for intermediaries to indicate that such a forwarding operating has taken place. The address in the To header field value of SIP requests is not supposed to change, according to baseline SIP behavior [RFC3261]; instead, it is the Request-URI that is supposed to be updated when a call is retargeted. Practically speaking, however, many operational environments do alter the To header field. The History-Info header field [RFC7044] was created to store the Request-URIs that are discarded by a call in transit. The SIP Diversion header field [RFC5806], though historic, is still used for this purpose by some operators today. Neither of these header fields provide any cryptographic assurance of secure redirection, and they both record entries for minor syntactical changes in URIs that do not reflect a change to the actual target of a call.
ただし、[RFC8224]は、セクション12.1.1が指摘しているので、ベースラインパスポートオブジェクトから受信した情報に基づいて、キャロールがこれらの疑いを確認または拒否することは困難です。一般的な「呼転送」サービスは、元の呼び出し側番号が常に通話が配信される番号ではないという現実の良い例として機能します。そのような転送運転が行われたことを仲介者にとっては多くの潜在的な方法がある。ベースラインSIP動作[RFC3261]によると、SIP要求のTOヘッダーフィールド値のアドレスは変更することを想定していません。代わりに、通話が遅られたときに更新されることになっている要求URIです。しかし実際に話すと、多くの運用環境は、TOヘッダフィールドを変更します。履歴情報ヘッダーフィールド[RFC7044]は、通話中の通話によって破棄された要求 - URIを格納するように作成されました。 SIP転送ヘッダフィールド[RFC5806]は、歴史的な歴史的ですが、今日のいくつかのオペレーターによってまだこの目的のために使用されています。これらのヘッダーフィールドのどちらもセキュアリダイレクトの暗号化保証を提供していないため、両方とも、呼の実際のターゲットへの変更を反映していないURIのマイナー構文変更のエントリを記録します。
Therefore, this specification extends PASSporT with an explicit indication that the original called number in PASSporT no longer reflects the destination to which a call is intended to be delivered. For this purpose, it specifies a Divert PASSporT type ("div") for use in common SIP retargeting cases; it is expected that in this case, SIP INVITE requests will carry multiple Identity header fields, each containing its own PASSporT. Throughout this document, PASSporTs that contain a "div" element will be referred to as "div" PASSporTs. Verification services and the relying parties who make authorization decisions about communications may use this diversion indication to confirm that a legitimate retargeting of the call has taken place, rather than a cut-and-paste attack. For out-of-band use cases [RFC8816] and other non-SIP applications of PASSporT, a separate "div-o" PASSporT type is also specified, which defines an "opt" PASSporT element for carrying nested PASSporTs within a PASSporT. These shall in turn be referred to in this document as "div-o" PASSporTs.
したがって、この仕様は、パスポートの呼び出された番号が呼が配信されることを意図している宛先を反映していないことを明示的な指示でパスポートを拡張します。この目的のために、共通のSIPリタータイグケースで使用するためのDivert Passple（ "DIV"）を指定します。この場合、SIP INVITEリクエストはそれぞれ独自のパスポートを含む複数のIDヘッダーフィールドを持ちます。この文書を通して、「DIV」要素を含むパスポートは「DIV」パスポートと呼ばれます。検証サービスと通信についての許可の決定を下す頼り当事者は、この転換指示を使用して、カットアンドペースト攻撃ではなく、通話の正当な復旧が行われたことを確認することができます。帯域外ユースケース[RFC8816]およびPassportの他の非SIPアプリケーションの場合も、パスポート内のネストしたパスポートを運ぶための「Opt」Passport要素を定義しています。これらはこの文書では「DIV-O」パスポートと呼ばれます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This specification defines a PASSporT [RFC8225] type called "div", which may be employed by authentication services located at retargeting entities. All "div" PASSporTs MUST contain a new JSON Web Token "div" claim, also specified in this document, which indicates a previous destination for a call during its routing process. When a retargeting entity receives a call signed with a PASSporT, it may act as an authentication service and create a new PASSporT containing the "div" claim to attach to the call.
この仕様は、「DIV」と呼ばれるPASSPORT [RFC8225]タイプを定義しています。これは、retargetingエンティティにある認証サービスによって採用される可能性があります。すべての "DIV"パスポートには、このドキュメントでも指定されている新しいJSON Webトークン "DIV"クレームが含まれていなければなりません。これは、ルーティングプロセス中の通話の前の宛先を示しています。リタルゲット企業がパスポートを登録する通話を受け取ると、認証サービスとして機能し、「DIV」クレームを含む新しいパスポートを作成して通話に添付することができます。
Note that a new PASSporT is only necessary when the canonical form of the "dest" identifier (per the canonicalization procedures in [RFC8224], Section 8.3) changes due to this retargeting. If the canonical form of the "dest" identifier is not changed during retargeting, then a new PASSporT with a "div" claim MUST NOT be produced.
新しいパスポートは、「DEST」識別子（[RFC8224]の正規化手順、セクション8.3）の標準形式の場合にのみ必要であることに注意してください。「DEST」識別子の標準形式がリタージャット中に変更されていない場合、「DIV」クレームを持つ新しいパスポートを作成してはいけません。
The headers of the new PASSporTs generated by retargeting entities MUST include the "div" PASSporT type and an "x5u" field pointing to a credential that the retargeting entity controls. "div" PASSporTs MUST use full form instead of compact form. The new PASSporT header will look as follows:
retargetingエンティティによって生成された新しいパスポートのヘッダーには、「DIV」パスポートタイプと、Retargetingエンティティがコントロールする資格情報を指す「X5U」フィールドを含める必要があります。「DIV」パスポートは、コンパクトフォームの代わりにフルフォームを使用する必要があります。新しいパスポートヘッダーは次のようになります。
{ "typ":"passport",
"ppt":"div",
"alg":"ES256",
"x5u":"https://www.example.com/cert.cer" }
A "div" PASSporT claims set is populated with elements drawn from the PASSporT(s) received for a call by the retargeting entity; at a high level, the original identifier for the called party in the "dest" object will become the "div" claim in the new PASSporT. If the "dest" object of the original PASSporT contains multiple identifiers, because it contains one or more name/value pairs with an array as its value, the retargeting entity MUST select only one identifier from the value(s) of the "dest" object to occupy the value of the "div" field in the new PASSporT. Moreover, it MUST select an identifier that is within the scope of the credential that the retargeting entity will specify in the "x5u" of the PASSporT header (as described below).
「DIV」パスポートのクレームセットには、リタータイティングエンティティによる通話のために受信されたパスポートから描かれた要素が含まれています。ハイレベルでは、 "dest"オブジェクトの着信側の元の識別子は、新しいパスポートの「DIV」クレームになります。元のパスポートの「DEST」オブジェクトに複数の識別子が含まれている場合、その値として配列を持つ1つまたは複数の名前/値のペアが含まれているため、Retargetingエンティティは "dest"の値から1つの識別子のみを選択する必要があります。オブジェクト新しいパスポートの「DIV」フィールドの値を占有する。さらに、リタルゲットエンティティがパスポートヘッダの「x5u」で指定する信用証明書の範囲内にある識別子を選択する必要があります（後述）。
The new target for the call selected by the retargeting entity becomes the value of the "dest" object of the new PASSporT. The "orig" object MUST be copied into the new PASSporT from the original PASSporT received by the retargeting entity. The retargeting entity SHOULD retain the "iat" object from the original PASSporT, though if in the underlying signaling protocol (e.g., SIP) the retargeting entity changes the date and time information in the retargeted request, the new PASSporT should instead reflect that date and time. No other claims or extensions are to be copied from the original PASSporT to the "div" PASSporT.
Retargetingエンティティによって選択された呼び出しの新しいターゲットは、新しいパスポートの "dest"オブジェクトの値になります。"orig"オブジェクトは、Retargetingエンティティが受信したオリジナルのパスポートから新しいパスポートにコピーする必要があります。retargetingエンティティは元のパスポートから「IAT」オブジェクトを保持する必要があります。時間。元のパスポートから「DIV」のパスポートに、他のクレームまたは拡張機能はコピーされません。
So, for an original PASSporT claims set of the form:
それで、元のパスポートのためにフォームのセットのセットのために：
{ "dest":{"tn":["12155551213"]},
"iat":1443208345,
"orig":{"tn":"12155551212"} }
If the retargeting entity is changing the target from 12155551213 to 12155551214, the claims set of a "div" PASSporT generated by the retargeting entity would look as follows:
retargetingエンティティが12155551213から12155551214のターゲットを変更している場合、リタルゲートエンティティによって生成された「DIV」パスポートのクレームセットは次のようになります。
{ "dest":{"tn":["12155551214"]},
"div":{"tn":"121555551213"},
"iat":1443208345,
"orig":{"tn":"12155551212"} }
The combined full form PASSporT (with a signature covered by the ES256 keys given in Appendix A) would look as follows:
組み合わされたフルフォームパスポート（付録Aに記載されているES256キーで覆われた署名付き）は次のようになります。
eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ SqIlk3yCNkg
eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij\oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI\jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF\0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE\J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT\SqIlk3yCNkg
The same "div" PASSporT would result if the "dest" object of the original PASSporT contained an array value, such as {"tn":["12155551213","19995551234"]}, and the retargeting entity chose to retarget from the first telephone number in the array. Every "div" PASSporT is diverting from only one identifier.
元のパスポートの「DEST」オブジェクトが{"tn"： "tn"： "1215555123"、 "19995551234"]などの配列値を含んでいれば、同じ "DIV"パスポートが生じるでしょう。アレイ内の最初の電話番号すべての「DIV」パスポートは1つの識別子のみから転送されます。
Note that the "div" element may contain other name/value pairs than just a destination, including a History-Info indicator (see Section 8). After the PASSporT header and claims have been constructed, their signature is generated per the guidance in [RFC8225] -- except for the credential required to sign it. While in the ordinary construction of a PASSporT, the credential used to sign will have authority over the identity in the "orig" claim (for example, a certificate with authority over the telephone number in "orig" per [RFC8226]), for all PASSporTs using the "div" type the signature MUST be created with a credential with authority over the identity present in the "div" claim. So for the example above, where the original "dest" is "12155551213", the signer of the new PASSporT object MUST have authority over that telephone number and need not have any authority over the telephone number present in the "orig" claim.
「div」要素は、履歴情報インジケータを含む単なる宛先よりも他の名前/値のペアを含めることができることに注意してください（セクション8を参照）。パスポートヘッダーとクレームが構築された後、署名に必要な信任状を除き、[RFC8225]のガイダンスごとにそれらの署名が生成されます。パスポートの普通の建設では、署名に使用される資格情報は、「orig」請求書（例えば、rfc8226）の「orig "の権限を持つ証明書（RFC8226]）の身分証明書を持っています。「DIV」タイプを使用したパスポート署名は、「DIV」クレームに存在する身元に対する権限を持つ信任状で作成する必要があります。そのため、元の "dest"が "12155551213"である上記の例では、新しいパスポートオブジェクトの署名者はその電話番号に対する権限を持っており、「Orig」クレームに存在する電話番号に対する権限を持たない必要はありません。
Note that Identity header fields are not ordered in a SIP request, and in a case where there is a multiplicity of Identity header fields in a request, some sorting may be required to match "div" PASSporTs to their originals.
識別ヘッダフィールドはSIP要求で順序付けられていないので、要求に多数のIDヘッダフィールドが多数ある場合には、「DIV」パスポートと原稿と一致させるために何らかの並べ替えが必要になる場合があります。
PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6) element in their payload.
"div"のパスポートには、ペイロード内の "opt"（セクション6）要素を含まないでください。
This section specifies SIP-specific usage for the "div" PASSporT type and its handling in the SIP Identity header field "ppt" parameter value. Other protocols using PASSporT may define behavior specific to their use of the "div" claim.
このセクションでは、「DIV」パスポートタイプとSIP IDヘッダフィールドの「PPT」パラメータ値でのSIP固有の使用法を指定します。Passportを使用した他のプロトコルは、「DIV」請求の使用に特有の行動を定義することができます。
An authentication service only adds an Identity header field value containing the "div" PASSporT type to a SIP request that already contains at least one Identity header field value; it MUST NOT add a "div" PASSporT to an INVITE that contains no Identity header field. The retargeting entity SHOULD act as a verification service and validate the existing Identity header field value(s) in the request before proceeding; in some high-volume environments, it may instead put that burden of validating the chain entirely on the terminating verification service. As the authentication service will be adding a new PASSporT that refers to an original, it MUST NOT remove the original request's Identity header field value before forwarding.
認証サービスは、すでに少なくとも1つのIDヘッダフィールド値を含むSIP要求に「DIV」パスポートタイプを含むIDヘッダフィールド値を追加する。IDENTITYヘッダーフィールドを含まないINVITEに「DIV」パスポートを追加しないでください。Retargetingエンティティは検証サービスとして機能し、続行する前に要求に既存のIDヘッダーフィールド値を検証する必要があります。いくつかの大量の環境では、代わりにチェーンを検証するという負担を完全に終端検証サービスに満たすことができます。認証サービスがオリジナルを指す新しいパスポートを追加するので、転送前に元の要求の識別ヘッダーフィールド値を削除しないでください。
As was stated in Section 3, the authentication service MUST sign any "div" PASSporT with a credential that has a scope of authority covering the identity it populates in the "div" element value. Note that this is a significant departure from baseline STIR authentication service behavior, in which the PASSporT is signed by a credential with authority over the "orig" field. The "div" value reflects the URI that caused the call to be routed to the retargeting entity, so in ordinary operations, it would already be the STIR entity holding the appropriate private keying material for calls originating from that identity.
セクション3に記載されているように、認証サービスは、「DIV」要素値に入力した身元をカバーする権限の範囲を持つ信任状を持つ「DIV」パスポートに署名する必要があります。これはベースライン撹拌認証サービスの行動からの大きな逸脱であり、その上でパスポートは「orig」フィールドを超える権限を持つ資格情報によって署名されています。「div」値は、呼び出しをリタルゲートエンティティにルーティングする原因となったURIを反映しています。そのため、通常の操作では、そのアイデンティティから発信されたコールの適切な秘密キーイングマテリアルを保持しているかき混ぜます。
A SIP authentication service typically will derive the "dest" element value of a "div" PASSporT from a new Request-URI that is set for the SIP request before it is forwarded. Older values of the Request-URI may appear in header fields like Diversion or History-Info; this document specifies an optional interaction with History-Info below in Section 8. Note as well that because PASSporT operates on canonicalized telephone numbers and normalized URIs, many smaller changes to the syntax of identifiers that might be captured by other mechanisms that record retargeting (like History-Info) will likely not require a "div" PASSporT.
SIP認証サービスは、通常、SIP要求に設定されている新しい要求URIからの「DEST」要素値を転送する前にSIP要求に設定されている「DEST」要素値を導出します。request-uriの古い値は、転送または履歴情報のようなヘッダーフィールドに表示されることがあります。このドキュメントでは、以下の履歴情報とのオプションのインタラクションを指定します。履歴情報）は「DIV」のパスポートを必要としないでしょう。
When adding an Identity header field with a PASSporT claims set containing a "div" claim, SIP authentication services MUST also add a "ppt" parameter to that Identity header with a value of "div". For the example PASSporT given in Section 3, the new Identity header added after retargeting might look as follows:
「DIV」クレームを含むPassportクレーム・フィールドを持つIDヘッダーフィールドを追加する場合、SIP認証サービスは、そのIDENTITYヘッダーに「DIV」の値を持つ「PPT」パラメーターを追加する必要があります。セクション3で指定されたパスポートの例では、リタルゲット後に追加された新しいIDヘッダーが次のようになります。
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \
iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \
Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \
MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \
xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \
ChHhVIiMTSqIlk3yCNkg; \
info=<https://www.example.com/cert.cer>;ppt="div"
Note that in some deployments, an authentication service will need to generate "div" PASSporTs for a request that contains multiple non-"div" Identity header field values. For example, a request arriving at a retargeting entity might contain, in different Identity header fields, a baseline [RFC8224] PASSporT and a PASSporT of type "rph" [RFC8443] signed by a separate authority. Provided that these PASSporTs share the same "orig" and "dest" values, the retargeting entity's authentication service SHOULD generate only one "div" PASSporT. If the "orig" or "dest" of these PASSporTs differ, however, one "div" PASSporT SHOULD be generated for each non-"div" PASSporT. Note that this effectively creates multiple chains of "div" PASSporTs in a single request, which complicates the procedures that need to be performed at verification services.
一部の展開では、認証サービスは、複数の非「DIV」識別ヘッダーフィールド値を含む要求に対して「DIV」パスポートを生成する必要があります。たとえば、リタルゲット企業に到着するリクエストには、さまざまなIDヘッダーフィールド、ベースライン[RFC8224]パスポートと「RPH」タイプのパスポートが含まれている場合があります。これらのパスポートが同じ「orig」と「dest」の値を共有する場合、リタータイグ化エンティティの認証サービスは1つの「DIV」パスポートしか生成するはずです。ただし、これらのパスポートの「ORIM」または「DEST」が異なる場合は、「DIV」パスポートごとに1つの「DIV」パスポートを生成する必要があります。これにより、単一の要求で「DIV」パスポートの複数のチェーンを効果的に作成します。これにより、検証サービスで実行する必要がある手順を複雑にします。
Furthermore, a request may also be retargeted a second time, at which point the subsequent retargeting entity SHOULD generate one "div" PASSporT for each previous "div" PASSporT in the request that contains a "dest" object with the value of the current target -- but not for "div" PASSporTs with earlier targets. Ordinarily, the current target will be readily identifiable, as it will be in the last "div" PASSporT in each chain, and in SIP cases, it will correspond to the Request-URI received by the retargeting entity. Moreover, the current target will be an identifier that the retargeting entity possesses a credential to sign for, which may not be true for earlier targets. Ultimately, on each retargeting, the number of PASSporTs added to a request will be equal to the number of non-"div" PASSporTs that do not share the same "orig" and "dest" object values.
さらに、要求は2回目に遅延させることができ、その時点で、現在のターゲットの値を持つ「DEST」オブジェクトを含む要求に、以前のレターゲットエンティティは、前の「DIV」パスポートごとに1つの「DIV」パスポートを生成する必要があります。 - 以前のターゲットを持つ "DIV"パスポートの場合はありません。通常、現在のターゲットは、各チェーン内の最後の「DIV」パスポートになり、SIPケースでは、リタータイグエンティティによって受信された要求-URIに対応します。さらに、現在のターゲットは、リタルゲット企業が署名する資格情報を持つ識別子になり、これは以前のターゲットには当てはまりません。最終的には、各リタージャッグリングでは、要求に追加されたパスポートの数は、同じ「orig」と「dest」オブジェクト値を共有しない非「DIV」のパスポートの数に等しくなります。
[RFC8224], Section 6.2, Step 5 requires that specifications defining "ppt" values describe any additional or alternative verifier behavior. The job of a SIP verification service handling one or more "div" PASSporTs is very different from that of a traditional verification service. At a high level, the immediate responsibility of the verification service is to extract all PASSporTs from the two or more Identity header fields in a request, identify which are "div" PASSporTs and which are not, and then order and link the "div" PASSporTs to the original PASSporT(s) in order to build one or more chains of retargeting.
[RFC8224]、セクション6.2、ステップ5には、「PPT」値を定義する仕様が追加または代替の検証策の動作を記述する必要があります。1つ以上の「DIV」パスポートを処理するSIP検証サービスのジョブは、従来の検証サービスのそれとは非常に異なります。高レベルでは、検証サービスの即時の責任は、要求内の2つ以上のIDヘッダーフィールドからすべてのパスポートを抽出し、それが「DIV」パスポートであり、その後「DIV」を注文してリンクすることです。リタータイクルの1つ以上のチェーンを構築するために、元のパスポートへのパスポート。
In order to validate a SIP request using the "div" PASSporT type, a verification service needs to inspect all of the valid Identity header field values associated with a request, as an Identity header field value containing "div" necessarily refers to an earlier PASSporT already in the message. For each "div" PASSporT, the verification service MUST find an earlier PASSporT that contains a "dest" claim with a value equivalent to the "div" claim in each "div" PASSporT. It is possible that this earlier PASSporT will also contain a "div" and that it will in turn chain to a still earlier PASSporT stored in a different Identity header field value. If a complete chain cannot be constructed, the verification service cannot complete "div" validation; it MAY still validate any non-"div" PASSporTs in the request per the normal procedures in [RFC8224]. If a chain has been successfully constructed, the verification service extracts from the outermost (that is, the most recent) PASSporT in the chain a "dest" field; this will be a "div" PASSporT that no other "div" PASSporT in the SIP request refers to. Its "dest" element value will be referred to in the procedures that follow as the value of the "outermost "dest" field".
「DIV」パスポートタイプを使用してSIPリクエストを検証するためには、「DIV」を含むIDヘッダフィールド値が必ず前のパスポートを参照する識別ヘッダーフィールド値として、要求に関連付けられた有効なIDヘッダフィールド値のすべてを検査する必要があります。すでにメッセージ内にあります。各「DIV」パスポートについて、検証サービスは、各「DIV」パスポートの「DIV」クレームと同等の値を含む「DEST」クレームを含む以前のパスポートを見つける必要があります。この以前のパスポートには「DIV」を含み、それが異なる識別ヘッダーフィールド値に保存されている静止したパスポートにチェーンチェーンを含む可能性があります。完全チェーンを構築できない場合、検証サービスは「DIV」検証を完了できません。 [RFC8224]の通常の手順に従って、リクエストでは、「DIV」パスポートを検証することがあります。チェーンがうまく構築された場合、検証サービスは、チェーン内の最も外側の（つまり、最新の）パスポートから「DEST」フィールドに抽出します。これは、SIPリクエストの他の「DIV」パスポートが参照されていない「DIV」パスポートになります。その「dest」要素の値は、「最も外側の「最も外側」DEST「フィールド」の値として続く手順で参照されます。
Ultimately, by looking at this chain of transformations and validating the associated signatures, the verification service will be able to ascertain that the appropriate parties were responsible for the retargeting of the call to its current destination. This can help the verification service to determine that the original PASSporT in the call was not simply used in a cut-and-paste attack and inform any associated authorization decisions in terms of how the call will be treated -- though, per [RFC8224], Section 6.2.1, that decision is a matter of local policy and is thus outside the scope of this specification.
最終的には、この変換のチェーンを見ることによって、関連するシグネチャの検証を検証することによって、検証サービスは適切な締約国がその現在の宛先への呼び出しの遅延を担当することを確認することができます。これは、呼び出し中のオリジナルのパスポートがカットアンドペースト攻撃で単に使用されていないことを確認するのに役立ち、コールの扱い方の観点から関連する許可の決定に通知することを確認することができます - しかし、[RFC8224]第6.2.1項、その決定は地域の方針の問題であり、この仕様の範囲外です。
A verification service parses a chain of PASSporTs as follows:
検証サービスは以下のようにパスポートのチェーンを解析します。
1. The verification service MUST compare the value in the outermost "dest" field to the target of the call. As it is anticipated that SIP authentication services that create "div" PASSporTs will populate the "dest" header from the retargeted Request-URI (see Section 4.1), in ordinary SIP operations, the Request-URI is where verification services will find the latest call target. Note, however, that after a "div" PASSporT has been added to a SIP request, the Request-URI may have been updated during normal call processing to an identifier that no longer contains the logical destination of a call; in this case, the verification service MAY compare the "dest" field to a provisioned telephone number for the recipient.
1. 検証サービスは、最も外側の "dest"フィールドの値を呼び出しのターゲットに比較する必要があります。「DIV」パスポートを作成するSIP認証サービスがrequigeed要求URI（セクション4.1を参照）から「DEST」ヘッダを入力すると予想されるので、通常のSIP操作では、Request-URIは検証サービスが最新のものを見つけるところです。ターゲットを呼び出します。ただし、「DIV」パスポートがSIP要求に追加された後、通常の呼処理中に要求URIが更新され、呼の論理宛先が含まれなくなった識別子に更新されている可能性があります。この場合、検証サービスは、受信者の「DEST」フィールドをプロビジョニングされた電話番号と比較することができる。
2. The verification service MUST validate the signature over the outermost "div" PASSporT and establish that the credential that signed the "div" PASSporT has the authority to attest for the identifier in the "div" element of the PASSporT (per [RFC8224], Section 6.2, Step 3).
2. 検証サービスは、最も外側の「DIV」パスポートを介して署名を検証し、「DIV」パスポートに署名された資格情報に、パスポートの「DIV」要素（RFC8224]、セクションごとに）6.2、ステップ3）。
3. The verification service MUST validate that the "orig" field of the innermost PASSporT of the chain (the only PASSporT in the chain that will not be of PASSporT type "div") is equivalent to the "orig" field of the outermost "div" PASSporT; in other words, that the original calling identifier has not been altered by retargeting authentication services. If the "orig" value has changed, the verification service MUST treat the entire PASSporT chain as invalid. The verification service MUST also verify that all other "div" PASSporTs in the chain share the same "orig" value. Then, the verification service validates the relationship of the "orig" field to the SIP-level call signaling per the guidance in [RFC8224], Section 6.2, Step 2.
3. 検証サービスは、チェーンの最も内側のパスポートの「orig」フィールド（パスポートタイプの「DIV」ではないチェーンの唯一のパスポート）であることを検証する必要があります。パスポート;言い換えれば、元の呼び出し側識別子は、認証サービスをリタルゲートすることによって変更されていない。「orig」の値が変更された場合、検証サービスはパスポートチェーン全体を無効として扱う必要があります。検証サービスはまた、チェーン内の他のすべての「DIV」パスポートが同じ「orig」値を共有することを確認する必要があります。その後、検証サービスは、[RFC8224]、6.2、ステップ2のガイダンスごとの「orig」フィールドの関係を検証します。
4. The verification service MUST check the date freshness in the outermost "div" PASSporT, per [RFC8224], Section 6.2, Step 4. Furthermore, it is RECOMMENDED that the verification service check that the "iat" field of the innermost PASSporT is also within the date freshness interval; otherwise, the verification service could allow attackers to replay an old, stale PASSporT embedded in a fresh "div". However, note that in some use cases, including certain ways that call transfers are implemented, it is possible that an established call will be retargeted long after it has originally been placed, and verification services may want to allow a longer window for the freshness of the innermost PASSporT if the call is transferred from a trusted party (as an upper bound, a freshness window on the order of three hours might suffice).
4. 検証サービスは、[RFC8224]、セクション6.2、ステップ4で、最外部の「DIV」パスポートの日付の新鮮さをチェックする必要があります。日付の鮮度間隔。そうでなければ、検証サービスは、攻撃者が新鮮な「DIV」に埋め込まれた古い古いパスポートを再生することを可能にし得る。ただし、コール転送が実装されている特定の方法を含むいくつかの使用例では、最初に配置された後に確立された通話が長く復旧される可能性があり、検証サービスはの鮮度のために長いウィンドウを許可することができます。コールが信頼されたパーティーから（上限として、3時間程度の鮮度の順番で十分な場合に十分な場合が多い場合があります）。
5. The verification service MUST inspect and validate the signatures on each and every PASSporT object in the chain between the outermost "div" PASSporT and the innermost PASSporT. Note that (per Section 4.1) a chain may terminate at more than one innermost PASSporT, in cases where a single "div" is used to retarget from multiple innermost PASSporTs. Also note that [RFC8224], Section 6.2, Step 1 applies to the chain validation process; if the innermost PASSporT contains an unsupported "ppt", its chain MUST be ignored.
5. 検証サービスは、最も外側の「DIV」パスポートと最も内側のパスポートの間のチェーン内の各パスポートオブジェクトの署名を検査して検証する必要があります。（セクション4.1）は、単一の「DIV」が複数の最も内側のパスポートからのリダルゲットに使用されている場合、チェーンが複数の最も内側のパスポートで終了することができることに注意してください。また、[RFC8224]、セクション6.2、ステップ1はチェーン検証プロセスに適用されます。最も内側のパスポートにサポートされていない「PPT」が含まれている場合、そのチェーンは無視されなければなりません。
Note that the To header field is not used in the first step above. Optionally, the verification service MAY verify that the To header field value of the received SIP signaling is equal to the "dest" value in the innermost PASSporT; however, as has been observed in some deployments, the original To header field value may be altered by intermediaries to reflect changes of target. Deployments that change the original To header field value to conceal the original destination of the call from the ultimate recipient should note that the original destination of a call may be preserved in the innermost PASSporT. Future work on "div" might explore methods to implement that sort of policy while retaining a secure chain of redirection.
上記の最初のステップでは、TOヘッダーフィールドは使用されていません。任意選択で、検証サービスは、受信したSIPシグナリングのTOヘッダフィールド値が最も内側のパスポート内の「DEST」値に等しいことを検証することができる。ただし、一部の展開で観察されたように、元の宛先のヘッダーフィールド値は、ターゲットの変更を反映するために仲介者によって変更されてもよい。究極の受信者からのコールの元の宛先を隠すために元の宛先フィールド値を変更する展開は、コールの元の宛先が最も内側のパスポートに保存される可能性があることに注意してください。「DIV」の将来の作業は、安全なリダイレクトチェーンを保持しながら、そのようなポリシーを実装するためのメソッドを探るかもしれません。
This specification defines a "div-o" PASSporT type that uses the "div" claim element in conjunction with the "opt" (Section 6) claim element. As is the case with "div" PASSporT type, a "div-o" PASSporT is created by an authentication service acting for a retargeting entity, but instead of generating a separate "div" PASSporT to be conveyed alongside an original PASSporT, the authentication service in this case embeds the original PASSporT inside the "opt" element of the "div-o" PASSporT. The "div-o" extension is designed for use in non-SIP or gatewayed SIP environments where the conveyance of PASSporTs in separate Identity header fields in impossible, such as out-of-band STIR scenarios [RFC8816].
この仕様は、「DIV」クレーム要素を「OPT」と組み合わせて使用する「DIV-O」パスポートタイプを定義しています（セクション6）。「DIV」パスポートタイプの場合と同様に、「DIV-O」パスポートは、リタータイグエンティティのために行動する認証サービスによって作成されますが、オリジナルのパスポート、認証、認証を介して運ばれる代わりに別の「DIV」パスポートを生成するのではなく、この場合のサービスは、「Div-O」パスポートの「OPT」要素の中にオリジナルのパスポートを埋め込む。「Div-O」拡張子は、帯域外の攪拌シナリオなど、不可能なPASSPORTSの搬送が不可能である[RFC8816]など、非SIPまたはゲートウェイSIP環境で使用するように設計されています。
The syntax of "div-o" PASSporTs is very similar to "div". A "div-o" PASSporT header object might look as follows:
「DIV-O」パスポートの構文は「DIV」と非常によく似ています。「DIV-O」パスポートヘッダーオブジェクトは次のようになります。
{ "typ":"passport",
"ppt":"div-o",
"alg":"ES256",
"x5u":"https://www.example.com/cert.cer" }
Whereas a "div" PASSporT claims set contains only the "orig", "dest", "iat", and "div" elements, the "div-o" additionally MUST contain an "opt" element (see Section 6), which encapsulates the full form of the previous PASSporT from which the call was retargeted, triggering the generation of this "div-o". The format of the "opt" element is identical to the encoded PASSporT format given in Appendix A of [RFC8225].
「DIV」パスポートクレームセットには、「orig」、「dest」、「IAT」、および「DIV」要素のみが含まれていますが、「DIV-O」には「OPT」要素が含まれています（セクション6を参照）。呼び出し元のパスポートのフルフォームをカプセル化し、この「DIV-O」の生成を開始します。「opt」要素のフォーマットは、[RFC8225]の付録Aに記載されているエンコードパスポートフォーマットと同じです。
So, for an original PASSporT claims set of the form:
それで、元のパスポートのためにフォームのセットのセットのために：
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]},
"iat":1443208345 }
If the retargeting entity is changing the target from 12155551213 to 12155551214, the new PASSporT claims set for "div-o" would look as follows:
Retargetingエンティティが12155551213から12155551214のターゲットを変更している場合、「Div-O」に設定されている新しいパスポートクレームは次のようになります。
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]},
"iat":1443208345,
"div":{"tn":"121555551213"},
"opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \
HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \
EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \
E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \
RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw" }
While in ordinary operations, it is not expected that SIP would carry a "div-o" PASSporT, it might be possible in some gatewaying scenarios. The resulting full form Identity header field with a "div-o" PASSporT would look as follows:
通常の操作では、SIPが「DIV-O」のパスポートを運ぶことが期待されていませんが、一部のゲートウェイシナリオでは可能かもしれません。「Div-O」パスポートを含む結果の完全な形式IDヘッダーフィールドは次のようになります。
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \ nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \ N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \ In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \ I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \ YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \ V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \ T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \ BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \ VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \ HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \ LaDV2y2VtHTLIEgmHig; \ info=<https://www.example.com/cert.cer>;ppt="div-o"
アイデンティティ：eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc\nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX\N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz\In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl\I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho\YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak\V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np\T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD\BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq\VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C\HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI\LaDV2y2VtHTLIEgmHig。\ info = <https://www.example.com/cert.cer>; ppt = "div-o"
The authentication and verification service procedures required for "div-o" closely follow the guidance given in Sections 4.1 and 4.2, with the major caveats being, first, that they do store or retrieve PASSporTs via the Identity header field values of SIP requests and, second, that they process nested PASSporTs in the "opt" claim element. But transposing the rest of the behaviors described above to creating and validating "div-o" PASSporTs is straightforward.
「DIV-O」に必要な認証および検証サービス手順は、セクション4.1および4.2に記載されているガイダンスに密接に従います。これは、まず、SIP要求のIDヘッダーフィールド値を介してパスポートを保存または検索することを目的としています。第二に、彼らは「opt」クレーム要素にネストしたパスポートを処理すること。しかし、「Div-O」パスポートの作成と検証に上記の残りの行動を転置することは簡単です。
For the "div-o" PASSporT type, retargeting authentication services that handle calls with one or more existing PASSporTs will create a corresponding "div-o" PASSporT for each received PASSporT. Each "div-o" PASSporT MUST contain an "opt" claim set element with the value of the original PASSporT from which the "div-o" was created; as specified in Section 4.1, the authentication service MUST populate the "div" claim set element of the "div-o" PASSporT with the "dest" field of the original PASSporT. Each received PASSporT may in turn contain its own "opt" claim set element if the retargeting authentication service is not the first in its chain. Note that if the retargeting authentication service is handling a call with multiple PASSporTs, which in ordinary SIP operation would result in the construction of multiple "div" chains, it will in effect be generating one "div-o" PASSporT per chain.
「Div-O」パスポートタイプの場合、1つ以上の既存のパスポートを使用して呼び出しを処理するレタルゲット認証サービスは、受信したパスポートごとに対応する「DIV-O」パスポートを作成します。「DIV-O」パスポートには、「Div-O」が作成されたオリジナルのパスポートの値を持つ「OPT」請求セット要素を含める必要があります。セクション4.1で指定されているように、認証サービスは、オリジナルのパスポートの「DEST」フィールドの「DIV-O」パスポートの「DIV」クレームセット要素を入力する必要があります。Retargeting認証サービスがそのチェーンの最初のチェーンではない場合、受信した各パスポートには、独自の「OPT」クレーム・セット要素が含まれている場合があります。通常のSIP操作では、Retargeting Authentication Serviceが複数のパスポートを含む通話を処理している場合、通常のSIP操作では複数の「DIV」チェーンの構築が可能になります。
The job of a verification service is in many ways easier for "div-o" than for "div", as the verification service has no need to correlate the PASSporTs it receives and assemble them into chains, as any chains in "div-o" will be nested through the "opt" element. Nonetheless, the verification services MUST perform the same chain validation described in Section 4.2 to validate that each nested PASSporT shares the same "orig" field as its enclosing PASSporT and that the "dest" field of each nested PASSporT corresponds to the "div" field of its enclosing PASSporT. The same checks MUST also be performed for freshness, signature validation, and so on. It is similarly OPTIONAL for the verification service to determine that the "dest" claims element of the outermost PASSporT corresponds to the called party indication of receive telephone signaling, where such indication would vary depending on the using protocol.
検証サービスのジョブは、「Div-O」の任意のチェーンとして、検証サービスは「DIV」よりも「DIV-O」が「DIV-O」にとって簡単になります。「opt」要素を通してネストされます。それにもかかわらず、検証サービスはセクション4.2で説明されているのと同じチェーン検証を実行して、各ネストしたパスポートが同じ「オリジナル」フィールドをその囲みパスポートとして共有し、各入れ子パスポートの「DEST」フィールドが「DIV」フィールドに対応することを検証する必要があります。その囲まれたパスポートの。鮮度、署名検証などのためにも同じチェックを実行する必要があります。検証サービスのために同様にオプションは、最も外側のパスポートの「Dest」クレーム要素が受信電話シグナリングの着信側の指示に対応すると判断し、そのような指示は使用プロトコルによって異なるであろう。
How authentication services or verification services receive or transport PASSporTs for "div-o" is outside the scope of this document and dependent on the using protocol.
認証サービスや検証サービスの受信または「Div-O」のパスポートを受信する方法は、この文書の範囲外で、使用プロトコルに依存しています。
The presence of an "Original PASSporT" ("opt") claims set element signifies that a PASSporT encapsulates another entire PASSporT within it, typically a PASSporT that was transformed in some way to create the current PASSporT. Relying parties may need to consult the encapsulated PASSporT in order to validate the identity of a caller. "opt", as defined in this specification, may be used by future PASSporT extensions as well as in conjunction with "div-o".
「オリジナルのパスポート」（「OPT」）の存在は、Passportがその中に別のパスポート全体をカプセル化していること、典型的には現在のパスポートを作成するために何らかの方法で変換されたパスポートを認識することを意味します。呼び出し側の身元を検証するために、依拠当事者はカプセル化されたパスポートを調べる必要があるかもしれません。「OPT」は、本明細書で定義されているように、将来のパスポート拡張、ならびに「DIV-O」と組み合わせて使用することができる。
"opt" MUST contain a quoted full-form PASSporT, as specified by [RFC8225], Appendix A; it MUST NOT contain a compact form PASSporT. For an example of a "div-o" PASSporT containing "opt", see Section 5.
「opt」は、[RFC8225]、付録Aで指定されているように、引用符で囲まれたフルフォームパスポートを含める必要があります。それはコンパクトなフォームパスポートを含んではいけません。「オプト」を含む「DIV-O」パスポートの例については、セクション5を参照してください。
The "div" mechanism exists primarily to prevent false negatives at verification services when an arriving SIP request, due to intermediary retargeting, does not appear to be intended for its eventual recipient, because the original PASSporT "dest" value designates a different destination.
「DIV」メカニズムは主に、仲介者の復元のために到着したSIP要求がその最終的な受信者を対象としているようには見えない場合は、検証サービスでの誤ったネガティブを防ぐことができます。
Any intermediary that assigns a new target to a request can, instead of retargeting and forwarding the request, redirect with a 3xx response code. In ordinary operations, a redirection poses no difficulties for the operations of baseline STIR: when the user agent client (UAC) receives the 3xx response, it will initiate a new request to the new target (typically the target carried in the Contact header field value of the 3xx), and the "dest" of the PASSporT created for the new request will match that new target. As no impersonation attack can arise from this case, it creates no new requirements for STIR.
リレーションをリタータ処理して転送するのではなく、リクエストをリクエストに割り当てることができ、3xxの応答コードとリダイレクトすることができます。通常の操作では、リダイレクトはベースラインをかき混ぜる操作に困難を維持しません。ユーザーエージェントクライアント（UAC）が3xx応答を受け取ると、新しいターゲットへの新しい要求を開始します（通常は連絡先ヘッダーフィールド値で搬送されるターゲットです。3xx）、および新しい要求のために作成されたパスポートの "dest"はその新しいターゲットと一致します。この場合から偽装攻撃が発生しないように、それはかき混ぜるための新しい要求を生じさせません。
However, some UACs record the original target of a call with mechanisms like History-Info [RFC7044] or Diversion [RFC5806] and may want to leverage STIR to demonstrate to the ultimate recipient that the call has been redirected securely, that is, that the original destination was the one that sent the redirection message that led to the recipient receiving the request. The semantics of the PASSporT necessary for that assertion are the same as those for the "div" retargeting cases above. The only wrinkle is that the PASSporT needs to be generated by the redirecting entity and sent back to the originating user agent client within the 3xx response.
ただし、UACSの中には、履歴情報[RFC7044]またはCerswers [RFC5806]のようなメカニズムを使用したコールの元のターゲットを記録し、コールが安全にリダイレクトされたこと、つまり、そのことです。元の宛先は、受信者にリクエストを受信したリダイレクトメッセージを送信したものでした。そのアサーションに必要なパスポートのセマンティクスは、上記の「DIV」の復元ケースの場合と同じです。唯一のしわは、パスポートがリダイレクトエンティティによって生成され、3xx応答内で発信元のユーザーエージェントクライアントに送信される必要があることです。
This introduces more complexity than might immediately be apparent. In the first place, a 3xx response can convey multiple targets through the Contact header field value; to accommodate this, the "div" PASSporT MAY include one "dest" object array value per Contact, but if the retargeting entity wants to keep the Contact list private from targets, it may need to generate one PASSporT per Contact. Bear in mind as well that the original SIP request could have carried multiple Identity header field values that had been added by different authentication services in the request path, so a redirecting entity might need to generate one "div" PASSporT for each PASSporT in the original request. Often, this will mean just one "div" PASSporT, but for some deployment scenarios, it could require an impractical number of combinations. But in very complex call routing scenarios, attestation of source identity would only add limited value anyway.
これはすぐに明らかになるかもしれないより複雑さをもたらします。そもそも、3xx応答は、コンタクトヘッダフィールド値を介して複数のターゲットを伝達することができる。これに対応するために、「DIV」パスポートは連絡先ごとに1つの「DEST」オブジェクト配列値を含めることができますが、ターゲットリストが連絡先リストをターゲットから非公開にしたい場合は、連絡先ごとに1つのパスポートを生成する必要があります。元のSIP要求が要求パス内のさまざまな認証サービスによって追加された複数のIDヘッダーフィールド値を搭載している可能性があるため、リダイレクトエンティティは元のパスポートごとに1つの「DIV」パスポートを生成する必要がある可能性があるため、リクエスト。多くの場合、これは1つだけの「DIV」パスポートを意味しますが、いくつかの展開シナリオでは、非実用的な組み合わせが必要になる可能性があります。しかし、非常に複雑なコールルーティングシナリオでは、Source Identityの認証はとにかく限られた値のみを追加します。
Therefore, STIR-aware SIP intermediaries that redirect requests MAY convey one or more PASSporTs in the backwards direction within Identity header fields. These redirecting entities will act as authentication services for "div" as described in Section 4.1. This document consequently updates [RFC8224] to permit carrying Identity header fields in SIP 300-class responses. It is left to the originating user agent to determine which Identity header fields should be copied from the 3xx into any new requests resulting from the redirection, if any; use of these Identity header fields by entities receiving a 3xx response is OPTIONAL.
したがって、要求をリダイレクトする攪拌対応SIP仲介者は、IDヘッダフィールド内で逆方向に1つまたは複数のパスポートを伝達することができる。これらのリダイレクトエンティティは、セクション4.1で説明されているように「DIV」の認証サービスとして機能します。その結果、この文書はSIP 300クラスの応答でIdentityヘッダーフィールドを搬送することを許可するために[RFC8224]を更新します。どのIDのヘッダーフィールドを3xxからコピーする必要があるかを判断するには、リダイレクションからリダイレクトされた新しい要求にどのIDをコピーするかを判断します。3xx応答を受信したエンティティによるこれらのIDヘッダーフィールドの使用はオプションです。
Finally, note that if an intermediary in the response path consumes the 3xx and explores new targets itself while performing sequential forking, it will effectively retarget the call on behalf of the redirecting server, and this will create the same need for "div" PASSporTs as any other retargeted call. These intermediaries MAY also copy PASSporTs from the 3xx response and insert them into sequential forking requests, if appropriate.
最後に、応答パスの中間機が3xxを消費し、シーケンシャルフォークを実行しながら新しいターゲット自体を探索しても、リダイレクトサーバーに代わって呼び出しを効果的に戻します。他の遅延コール。これらの仲介者はまた、3xx応答からパスポートをコピーし、必要に応じてそれらを順次のフォーキング要求に挿入することもできます。
It is anticipated that "div" may be used in concert with History-Info [RFC7044] in some deployments. It may not be clear from the "orig" and "dest" values which History-Info header a given PASSporT correlates to, especially because some of the target changes tracked by History-Info will not be reflected in a "div" PASSporT (see Section 1). Therefore, an "hi" element as defined here may appear in "div" corresponding to the History-Info header field index parameter value. So for a History-Info header field with an index value of "1.2.1", the claims set of the corresponding PASSporT with "div" might look like:
いくつかの展開では、「DIV」を履歴情報と協会的に使用することができると予想されます。特に履歴情報によって追跡されたターゲット変更の一部が「DIV」パスポートに反映されないため、履歴情報ヘッダーAが相関する「org」と「DEST」の値から明確ではないかもしれません。セクション1）。したがって、ここで定義されている「Hi」要素は、履歴情報ヘッダフィールドインデックスパラメータ値に対応する「DIV」に現れることがある。そのため、インデックス値が「1.2.1」の履歴情報ヘッダーフィールドの場合、「DIV」の対応するパスポートのクレーム・セットは次のようになります。
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]},
"iat":1443208345,
"div":{"tn":"121555551213",
"hi":"1.2.1"} }
Past experience has shown that there may be additional information about the motivation for retargeting, which relying parties might consider when making authorization decisions about a call; see, for example, the "reason" associated with the SIP Diversion header field [RFC5806]. Future extensions to this specification might incorporate reasons into "div".
過去の経験は、承認の決定を下すときに頼りに団体が考慮されるかもしれないリタージャッキリングのための追加情報があるかもしれないことを示しました。たとえば、SIP転送ヘッダーフィールド[RFC5806]に関連付けられている「理由」を参照してください。この仕様への将来の拡張は、理由を「DIV」に組み込むことができます。
Per this specification, IANA has added two new claims to the "JSON Web Token Claims" registry as defined in [RFC7519].
この仕様ごとに、IANAは[RFC7519]で定義されている「JSON Webトークンクレーム・クレーム・クレーム」レジストリに2つの新しい請求を追加しました。
Claim Name: div
クレーム名：DIV
Claim Description: Diverted Target of a Call
クレーム説明：呼び出しのターゲットを転送しました
Change Controller: IESG
変更コントローラー：IESG
Reference: RFC 8946
参照：RFC 8946
Claim Name: opt
クレーム名：opt.
Claim Description: Original PASSporT (in Full Form)
クレーム説明：オリジナルパスポート（全面形式）
Change Controller: IESG
変更コントローラー：IESG
Reference: RFC 8946
参照：RFC 8946
This specification defines two new PASSporT types for the "Personal Assertion Token (PASSporT) Extensions" registry defined in [RFC8225], which resides at <https://www.iana.org/assignments/passport>. They are:
この仕様は、[RFC8225]で定義されている[Personal Assertion Token（Passport）拡張機能 "の2つの新しいパスポートタイプを定義しています。彼らです：
* "div", as defined in Section 3.
* セクション3で定義されているように、 "div"。
* "div-o", as defined in Section 5.
* セクション5で定義されているように、「div-o」。
There is an inherent trade-off in any mechanism that tracks, in SIP signaling, how calls are routed through a network, as routing decisions may expose policies set by users for how calls are forwarded, potentially revealing relationships between different identifiers representing the same user. Note, however, that in ordinary operations, this information is revealed to the user agent service of the called party, not the calling party. It is usually the called party who establishes these forwarding relationships, and if indeed some other party is responsible for calls being forwarded to the called party, many times the called party should likely be entitled to information about why they are receiving these calls. Similarly, a redirecting entity who sends a 3xx in the backwards direction knowingly shares information about service logic with the caller's network. However, as there may be unforeseen circumstances where the revelation of service logic to the called party poses a privacy risk, implementers and users of this or similar diversion-tracking techniques should understand the trade-off.
ルーティングの決定は、通話の転送方法のためにユーザによって設定されたポリシーを公開することができるため、SIPシグナリングではネットワークを介してルーティングされる方法を追跡するメカニズムに固有のトレードオフがあります。 。ただし、通常の操作では、発信者ではなく着信側のユーザーエージェントサービスにこの情報が明らかにされています。それは通常これらの転送関係を確立する着信締約国です。同様に、後方方向に3xxを送信するリダイレクトエンティティは、サービスロジックに関する情報を呼び出し側のネットワークと故意に共有します。しかしながら、着呼当事者へのサービスロジックの啓示がプライバシーリスクを提起する予定の予測があるかもしれないので、このまたは同様の転換追跡技術の実装者およびユーザはトレードオフを理解するべきである。
Furthermore, it is a general privacy risk of identity mechanisms overall that they do not interface well with anonymization services; the interaction of STIR with anonymization services is detailed in [RFC8224], Section 11. Any forwarding service that acts as an anonymizing proxy may not be able to provide a secure chain of retargeting due to the obfuscation of the originating identity.
さらに、それは、それらが匿名化サービスとうまく取り込まれていない識別メカニズムの一般的なプライバシーリスクです。匿名化サービスとのかき混ぜの相互作用は、[RFC8224]、セクション11に詳述されています。
Also see [RFC8224], Section 11 for further considerations on the privacy of using PASSporTs in SIP.
SIPでパスポートを使用するプライバシーに関するさらなる考慮事項については、[RFC8224]も参照してください。
This specification describes a security feature and is primarily concerned with increasing security when calls are forwarded. Including information about how calls were retargeted during the routing process can allow downstream entities to infer particulars of the policies used to route calls through the network. However, including this information about forwarding is at the discretion of the retargeting entity, so if there is a requirement to keep an intermediate called number confidential, no PASSporT should be created for that retargeting -- the only consequence will be that downstream entities will be unable to correlate an incoming call with the original PASSporT without access to some prior knowledge of the policies that could have caused the retargeting.
この仕様はセキュリティ機能について説明し、通話が転送されたときにセキュリティの向上に主に関係しています。ルーティングプロセス中に呼び出しがどのように復旧したかについての情報を含めることで、ダウンストリームエンティティがネットワークを介したコールをルーティングするために使用されるポリシーの詳細を推測できることを含みます。ただし、転送に関するこの情報を含むことは、リタータイグ企業の裁量であるため、中間機器を維持する必要がある場合は、そのリタータイグのためにパスポートを作成する必要があります。リタータイティングを引き起こした可能性があるポリシーについての事前の知識にアクセスすることなく、着信通話を元のパスポートと相関させることができません。
Any extension that makes PASSporTs larger creates a potential amplification mechanism for SIP-based DDoS attacks. Since diversion PASSporTs are created as a part of normal forwarding activity, this risk arises at the discretion of the retargeting domain; simply using 3xx response redirections rather than retargeting (by supplying a "div" per Section 7) mitigates the potential impact. Under unusual traffic loads, even domains that might ordinarily retarget requests can switch to redirection.
パスポートを大きくする拡張機能は、SIPベースのDDOS攻撃のための潜在的な増幅メカニズムを作成します。転換パスポートは通常の転送活動の一部として作成されているので、このリスクは遅延ドメインの裁量により発生します。リタルゲットではなく3xx応答リダイレクトを使用するだけ（セクション7ごとに "DIV"を入力することによって）潜在的な影響を軽減します。異常なトラフィック負荷の下では、通常リクエストを再送する可能性があるドメインでもリダイレクトに切り替えることができます。
SIP has an inherent capability to redirect requests, including forking them to multiple parties -- potentially, a very large number of parties. The use of the "div" PASSporT type does not grant any additional powers to attackers who hope to place bulk calls; if present, the "div" PASSporT instead identifies the party responsible for the forwarding. As such, senders of bulk unsolicited traffic are unlikely to find the use of "div" attractive.
SIPには、複数のパーティーへのフォークなどを含む、要求をリダイレクトする機能があります - 潜在的に非常に多数の当事者です。「DIV」パスポートタイプの使用は、バルクコールを配置したい攻撃者に追加の権限を与えません。存在する場合、「DIV」パスポートは、転送の責任者を識別します。そのように、バルク求められていないトラフィックの送付者は、「DIV」の使用を魅力的に見つけることはほとんどありません。
[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、「RFCSで使用するためのキーワード」、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>。
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <https://www.rfc-editor.org/info/rfc7044>.
[RFC7044] Barnes、M.、Audet、F.、Schubert、S.、Van Elburg、J.、C. Holmberg、「リクエスト履歴情報のセッション開始プロトコルへの拡張」、RFC 7044、DOI10.17487 / RFC7044、2014年2月、<https://www.rfc-editor.org/info/rfc7044>。
[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.、およびSAKIMURA、「JSON Webトークン（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 / RFC8224、2018年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、 "Passport：Personal Assertion Token"、RFC 8225、DOI 10.17487 / RFC8225、2018年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、「Secure Phereth Identity Credentials：証明書」、RFC 8226、DOI 10.17487 / RFC8226、2018年2月、<https：//www.rfc-editor.org/info/rfc8226>。
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, <https://www.rfc-editor.org/info/rfc5806>.
[RFC5806] Levy、S.およびM.Mohali、ED。、「SIPの転換表示」、RFC 5806、DOI 10.17487 / RFC5806、2010年3月、<https：//www.rfc-editor.org/info/rfc5806>。
[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-編集者。org / info / rfc7340>。
[RFC8443] Singh, R., Dolly, M., Das, S., and A. Nguyen, "Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization", RFC 8443, DOI 10.17487/RFC8443, August 2018, <https://www.rfc-editor.org/info/rfc8443>.
[RFC8443] Singh、R.、Dolly、M.、Das、S.、およびA. NGUYEN、「リソース優先承認のための個人的なアサーショントークン（パスポート）拡張」、RFC 8443、DOI 10.17487 / RFC8443、2018年8月、<HTTPS//www.rfc-editor.org/info/rfc8443>。
[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases", RFC 8816, DOI 10.17487/RFC8816, February 2021, <https://www.rfc-editor.org/info/rfc8816>.
[RFC8816] RESCORLA、E.およびJ.PETERSON、「安全な電話アイデンティティは、帯域外のアーキテクチャとユースケースを再表示」、RFC 8816、DOI 10.17487 / RFC8816、2021年2月、<https：//www.rfc-editor.org/info/rfc8816>。
The following EC256 keys are used in the signing examples given in this document. WARNING: Do not use this key pair in production systems.
この文書に記載されている署名例では、次のEC256キーが使用されています。警告：本番システムでこのキーペアを使用しないでください。
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4
hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END PUBLIC KEY-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49
AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4
+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END EC PRIVATE KEY-----
Acknowledgments
謝辞
We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Sean Turner, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks for contributions to this document.
Zhang、Dave Hancock、Chris Wendt、Sean Turner、Russ House、Ben Campbell、Eric Burger、Robert Sparksがこの文書への貢献を感謝します。
Author's Address
著者の住所
Jon Peterson Neustar, Inc. 1800 Sutter St., Suite 570 Concord, CA 94520 United States of America
Jon Peterson Neustar、Inc。1800 Stuter St.、Suite 570 Concord、CA 94520アメリカ合衆国
Email: jon.peterson@team.neustar