RFC 8443 - Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8443
タイトル : RFC 8443 - リソースプライオリティ許可のための個人アサーショントークン（PASSporT）拡張
翻訳編集 : 自動生成

[要約] RFC 8443は、リソース優先度認証のためのPersonal Assertion Token（PASSporT）拡張に関するものであり、要約と目的は以下の通りです。要約：RFC 8443は、リソース優先度認証のためのPASSporT拡張に関するものです。目的：このRFCの目的は、リソース優先度認証に関するPASSporTの使用を可能にすることです。

Internet Engineering Task Force (IETF)                          R. Singh
Request for Comments: 8443                                  Vencore Labs
Category: Standards Track                                       M. Dolly
ISSN: 2070-1721                                                     AT&T
                                                                  S. Das
                                                            Vencore Labs
                                                               A. Nguyen
                                  Office of Emergency Communications/DHS
                                                             August 2018

Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization

リソースプライオリティ許可のための個人アサーショントークン（PASSporT）拡張

Abstract

概要

This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.

このドキュメントは、RFC 8225で定義されているPersonal Assertion Token（PASSporT）仕様を拡張して、通信に使用されるSession Initiation Protocol（SIP）の「Resource-Priority」ヘッダーフィールドに入力された値に対して、暗号で署名された承認のアサーションを含めることができるようにしますリソースの優先順位付け。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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/rfc8443.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8443で入手できます。

著作権表示

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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  PASSporT "rph" Claim  . . . . . . . . . . . . . . . . . . . .   4
   4.  "rph" in SIP  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Authentication Service Behavior . . . . . . . . . . . . .   5
     4.2.  Verification Service Behavior . . . . . . . . . . . . . .   6
   5.  Further Information Associated with the SIP
       'Resource-Priority' Header Field  . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  JSON Web Token Claims . . . . . . . . . . . . . . . . . .   7
     6.2.  PASSporT Types  . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     7.1.  Avoidance of Replay and Cut-and-Paste Attacks . . . . . .   8
     7.2.  Solution Considerations . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction

1. はじめに

PASSporT [RFC8225] is a token format based on JSON Web Token (JWT) [RFC7519] for conveying cryptographically signed information about the identities involved in personal communications. PASSporT with Secure Telephone Identity Revisited (STIR) [RFC8224] provides a mechanism by which an authority on the originating side of a call, using a protocol like SIP [RFC3261], can provide a cryptographic assurance of the validity of the calling party telephone number in order to prevent impersonation attacks.

PASSporT [RFC8225]は、JSON Web Token（JWT）[RFC7519]に基づくトークン形式であり、個人的な通信に関係するIDに関する暗号で署名された情報を伝達します。安全な電話IDの再検討（STIR）を備えたPASSporT（RFC8224）は、SIP [RFC3261]のようなプロトコルを使用して、呼び出しの発信側の権限が、発呼者の電話番号の有効性を暗号で保証できるメカニズムを提供します。なりすまし攻撃を防ぐため。

[RFC4412] defines a mechanism to prioritize access to SIP-signaled resources during periods of communications resource scarcity using the SIP 'Resource-Priority' header. As specified in [RFC4412], the SIP 'Resource-Priority' header field may be used by SIP user agents (UAs) [RFC3261] (including Public Switched Telephone Network (PSTN) gateways and SIP proxy servers) to influence prioritization afforded to communication sessions, including PSTN calls (e.g., to manage scarce network resources during network congestion scenarios). However, the SIP 'Resource-Priority' header field could be spoofed and abused by unauthorized entities, the threat models and use cases of which are described in [RFC7375] and [RFC7340], respectively.

[RFC4412]は、SIPの「Resource-Priority」ヘッダーを使用して、通信リソースが不足している期間に、SIPシグナリングのリソースへのアクセスに優先順位を付けるメカニズムを定義しています。 [RFC4412]で指定されているように、SIP 'Resource-Priority'ヘッダーフィールドは、SIPユーザーエージェント（UA）[RFC3261]（公衆交換電話網（PSTN）ゲートウェイおよびSIPプロキシサーバーを含む）が通信に提供される優先順位付けに影響を与えるために使用できます。 PSTNコールを含むセッション（たとえば、ネットワークの輻輳シナリオ中に不足しているネットワークリソースを管理するため）。ただし、SIPの「Resource-Priority」ヘッダーフィールドは、許可されていないエンティティによって偽装されたり悪用されたりする可能性があります。その脅威モデルと使用例は、それぞれ[RFC7375]と[RFC7340]で説明されています。

Compromise of the SIP 'Resource-Priority' header field [RFC4412] could lead to misuse of network resources (i.e., during congestion scenarios), impacting the application services supported using the SIP 'Resource-Priority' header field.

SIP 'Resource-Priority'ヘッダーフィールドの侵害[RFC4412]は、ネットワークリソースの誤用（つまり、輻輳シナリオ中）につながり、SIP 'Resource-Priority'ヘッダーフィールドを使用してサポートされるアプリケーションサービスに影響を与える可能性があります。

[RFC8225] allows extensions by which an authority on the originating side verifying the authorization of a particular communication for the SIP 'Resource-Priority' header field can use a PASSPorT claim to cryptographically sign the SIP 'Resource-Priority' header field and convey assertion of the authorization for the SIP 'Resource-Priority' header field. A signed SIP 'Resource-Priority' header field will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing the SIP 'Resource-Priority' header field and to act on the information with confidence that the information has not been spoofed or compromised.

[RFC8225] SIP 'Resource-Priority'ヘッダーフィールドの特定の通信の承認を検証する発信側の機関がPASSPorTクレームを使用してSIP 'Resource-Priority'ヘッダーフィールドに暗号で署名し、アサーションを伝える拡張機能を許可しますSIP 'Resource-Priority'ヘッダーフィールドの認証の例。署名されたSIP 'Resource-Priority'ヘッダーフィールドにより、受信エンティティ（異なるネットワークドメイン/境界にあるエンティティを含む）は、SIP 'Resource-Priority'ヘッダーフィールドを承認するアサーションの有効性を検証し、情報に自信を持って行動することができます情報が偽装または侵害されていないこと。

This specification documents an extension to PASSporT and the associated STIR mechanisms to provide a function to cryptographically sign the SIP 'Resource-Priority' header field. This PASSporT object is used to provide attestation of a calling-user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling-user telephone-number attestation. How this extension to PASSporT is used for real-time communications supported using the SIP 'Resource-Priority' header field is outside the scope of this document. In addition, the PASSPorT extension defined in this document is intended for use in environments where there are means to verify that the signer of the SIP 'Resource-Priority' header field is authoritative.

この仕様は、PASSporTへの拡張と、関連するSTIRメカニズムを文書化して、SIPの「Resource-Priority」ヘッダーフィールドに暗号で署名する機能を提供します。このPASSporTオブジェクトは、優先通信の呼び出し元ユーザー認証の証明を提供するために使用されます。これは、呼び出し元のユーザーの電話番号の認証に使用されるPASSporTオブジェクトに加えて必要です。このPASSporTの拡張機能が、SIPの「Resource-Priority」ヘッダーフィールドを使用してサポートされるリアルタイム通信にどのように使用されるかは、このドキュメントの範囲外です。さらに、このドキュメントで定義されているPASSPorT拡張は、SIPの「Resource-Priority」ヘッダーフィールドの署名者が信頼できることを確認する手段がある環境での使用を目的としています。

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.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. PASSporT "rph" Claim

3. PASSporT "rph"クレーム

This specification defines a new JSON Web Token claim for "rph" that provides an assertion for information in the SIP 'Resource-Priority' header field.

この仕様は、SIPの「Resource-Priority」ヘッダーフィールドの情報にアサーションを提供する「rph」の新しいJSON Web Tokenクレームを定義します。

The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a PASSporT object. The PASSporT claims MUST contain an "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows:

PASSporTオブジェクトの作成者は、PASSporTオブジェクトのヘッダーに「rph」の「ppt」値を追加します。 PASSporTクレームには「rph」クレームを含める必要があり、PASSporTオブジェクトを検証するエンティティは、問題のPASSporTを処理するために「ppt」拡張を理解する必要があります。「ppt」が含まれるPASSPorTヘッダーは次のようになります。

   {
   "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.example.org/cert.cer"
   }

The "rph" claim will provide an assertion of authorization, "auth", for information in the SIP 'Resource-Priority' header field based on [RFC4412]. The syntax is:

「rph」クレームは、[RFC4412]に基づいて、SIPの「Resource-Priority」ヘッダーフィールドの情報に承認「auth」のアサーションを提供します。構文は次のとおりです。

   {
   Resource-Priority = "Resource-Priority" : r-value,
   r-value = namespace  "."  r-priority
   }

Specifically, the "rph" claim includes an assertion of the priority level of the user to be used for a given communication session. The value of the "rph" claim is an object with one or more keys. Each key is associated with a JSON array. These arrays contain strings that correspond to the r-values indicated in the SIP 'Resource-Priority' header field.

具体的には、「rph」クレームには、特定の通信セッションに使用されるユーザーの優先度レベルのアサーションが含まれます。「rph」クレームの値は、1つ以上のキーを持つオブジェクトです。各キーはJSON配列に関連付けられています。これらの配列には、SIPの「Resource-Priority」ヘッダーフィールドに示されているr値に対応する文字列が含まれています。

The following is an example "rph" claim for a SIP 'Resource-Priority' header field with one r-value of "ets.0" and with another r-value of "wps.0":

以下は、1つのr値が "ets.0"で、別のr値が "wps.0"のSIP 'Resource-Priority'ヘッダーフィールドに対する「rph」クレームの例です。

    {
     "orig":{"tn":"12155550112"},
     "dest":{["tn":"12125550113"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0", "wps.0"]}
    }

After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [RFC8225] using the full form of PASSPorT. The credentials (i.e., Certificate) used to create the signature must have authority over the namespace of the "rph" claim, and there is only one authority per claim. The authority MUST use its credentials associated with the specific service supported by the resource priority namespace in the claim. If r-values are added or dropped by the intermediaries along the path, the intermediaries must generate a new "rph" header and sign the claim with their own authority.

ヘッダーとクレームPASSporTオブジェクトが構築された後、それらの署名は、[RFC8225]のガイダンスに従って、PASSPorTの完全な形式を使用して通常生成されます。署名の作成に使用される資格情報（つまり、証明書）は、「rph」クレームの名前空間に対する権限を持っている必要があり、クレームごとに1つの権限しかありません。機関は、クレーム内のリソース優先名前空間によってサポートされる特定のサービスに関連付けられた資格情報を使用する必要があります。パスに沿って仲介者がr値を追加または削除した場合、仲介者は新しい「rph」ヘッダーを生成し、独自の権限でクレームに署名する必要があります。

The use of the compact form of PASSporT is not specified in this document.

このドキュメントでは、PASSporTのコンパクト形式の使用は指定されていません。

4. "rph" in SIP

4. SIPの「rph」

This section specifies SIP-specific usage for the "rph" claim in PASSporT.

このセクションでは、PASSporTの「rph」クレームのSIP固有の使用法を指定します。

4.1. Authentication Service Behavior

4.1. 認証サービスの動作

The Authentication Service will create the "rph" claim using the values discussed in Section 3 of this document that are based on [RFC4412]. The construction of the "rph" claim follows the steps described in Section 4.1 of [RFC8224].

認証サービスは、このドキュメントのセクション3で説明されている[RFC4412]に基づく値を使用して、「rph」クレームを作成します。「rph」クレームの構成は、[RFC8224]のセクション4.1に記載されている手順に従います。

The resulting Identity header for "rph" might look as follows (backslashes shown for line folding only):

"rph"の結果のIdentityヘッダーは次のようになります（バックスラッシュは行の折りたたみのみを示しています）。

      Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0\
      IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZ\
      XN0Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3\
      JpZyI6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiw\
      id3BzLjAiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl\
      -n8MIhoCr18vYYFy3blXvs3fslM_oos2P2Dyw;info=<https://www.example.\
      org/cert.cer>;alg=ES256;ppt="rph"

A SIP authentication service will derive the value of "rph" from the SIP 'Resource-Priority' header field based on policy associated with service-specific use of r-values, defined as follows in [RFC4412]:

SIP認証サービスは、[RFC4412]で次のように定義されている、サービス固有のr値の使用に関連するポリシーに基づいて、SIPの「Resource-Priority」ヘッダーフィールドから「rph」の値を取得します。

r-value = namespace "." r-priority

r-value =名前空間 "。" r優先度

The authentication service derives the value of the PASSPorT claim by verifying the authorization for the SIP 'Resource-Priority' header field (i.e., verifying a calling-user privilege for the SIP 'Resource-Priority' header field based on its identity). The authorization might be derived from customer-profile data or access to external services.

認証サービスは、SIPの「Resource-Priority」ヘッダーフィールドの承認を確認することで（PASSPorTクレームの値を導出します（つまり、SIPの「Resource-Priority」のヘッダーフィールドの呼び出し元ユーザーの特権をそのIDに基づいて確認します）。承認は、顧客プロファイルデータまたは外部サービスへのアクセスから取得できます。

[RFC4412] allows multiple "namespace "." priority value" pairs, either in a single SIP 'Resource-Priority' header field or across multiple SIP 'Resource-Priority' header fields. An authority is responsible for signing all the content of a SIP 'Resource-Priority' header field for which it has the authority.

[RFC4412]は、単一のSIP 'Resource-Priority'ヘッダーフィールドまたは複数のSIP 'Resource-Priority'ヘッダーフィールド間で、複数の「名前空間 "。"優先値」ペアを許可します。機関は、その機関が権限を持つSIP 'Resource-Priority'ヘッダーフィールドのすべてのコンテンツに署名する責任があります。

4.2. Verification Service Behavior

4.2. 検証サービスの動作

[RFC8224], Section 6.2, Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "ppt" values of "rph" is as follows:

[RFC8224]、セクション6.2、ステップ5では、「ppt」値を定義する仕様で追加の検証動作を説明する必要があります。「rph」の「ppt」値に指定された動作は次のとおりです。

The verification service MUST extract the value associated with the "auth" key in a full-form PASSPorT with a "ppt" value of "rph". If the signature validates, then the verification service can use the value of the "rph" claim as validation that the calling party is authorized for SIP 'Resource-Priority' header fields as indicated in the claim. This value would, in turn, be used for priority treatment in accordance with local policy for the associated communication service. If the signature validation fails, the verification service should infer that the calling party is not authorized for SIP 'Resource-Priority' header fields as indicated in the claim. In such cases, the priority treatment for the associated communication service is handled as per the local policy of the verifier. In such scenarios, the SIP 'Resource-Priority' header field SHOULD be stripped from the SIP request, and the network entities should treat the call as an ordinary call.

検証サービスは、「auth」キーに関連付けられた値を、「rph」の「ppt」値を持つ完全な形式のPASSPorTで抽出する必要があります。署名が検証されると、検証サービスは、「rph」クレームの値を、クレームに示されているように、発呼者がSIP 'Resource-Priority'ヘッダーフィールドに対して許可されていることの検証として使用できます。この値は、関連する通信サービスのローカルポリシーに従って、優先順位の扱いに使用されます。署名の検証が失敗した場合、検証サービスは、クレームに示されているように、発呼者がSIP 'Resource-Priority'ヘッダーフィールドに対して許可されていないことを推測する必要があります。このような場合、関連する通信サービスの優先処理は、検証者のローカルポリシーに従って処理されます。そのようなシナリオでは、SIP 'Resource-Priority'ヘッダーフィールドをSIPリクエストから削除する必要があり（SHOULD）、ネットワークエンティティは通常の通話として通話を処理する必要があります。

In addition, [RFC8224], Section 6.2, Step 4 requires the "iat" value in "rph" claim to be verified.

さらに、[RFC8224]、セクション6.2、ステップ4では、「rph」クレームの「iat」値を確認する必要があります。

The behavior of a SIP UA upon receiving an INVITE containing a PASSporT object with an "rph" claim will largely remain a matter of implementation policy for the specific communication service. In most cases, implementations would act based on confidence in the veracity of this information.

「rph」クレームを持つPASSporTオブジェクトを含むINVITEを受信したときのSIP UAの動作は、特定の通信サービスの実装ポリシーの問題のままです。ほとんどの場合、実装はこの情報の信憑性への信頼に基づいて行動します。

5. Further Information Associated with the SIP 'Resource-Priority' Header Field

5. SIP 'Resource-Priority'ヘッダーフィールドに関連する詳細情報

There may be additional information about the calling party or the call that could be relevant to authorization for the SIP 'Resource-Priority' header field. This may include information related to the device subscription of the caller, to any institutions that the caller or device is associated with, or even to categories of institutions. All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. The specification of the "rph" claim could entail the optional presence of one or more such additional information fields applicable to the SIP 'Resource-Priority' header field.

SIP 'Resource-Priority'ヘッダーフィールドの認証に関連する可能性のある、発呼側またはコールに関する追加情報がある場合があります。これには、発信者のデバイスサブスクリプション、発信者またはデバイスが関連付けられている機関、または機関のカテゴリに関連する情報が含まれる場合があります。これらのデータ要素はすべて、STIRおよびPASSporTフレームワークによって提供される安全な証明から恩恵を受けるでしょう。「rph」クレームの仕様は、SIPの「Resource-Priority」ヘッダーフィールドに適用可能な1つ以上のそのような追加情報フィールドのオプションの存在を伴う場合があります。

A new IANA registry has been defined to hold potential values of the "rph" array; see Section 6.2. The definition of the "rph" claim may have one or more such additional information field(s). Details of how an "rph" claim encompasses other data elements are left for future specifications.

「rph」配列の潜在的な値を保持するために、新しいIANAレジストリが定義されました。セクション6.2を参照してください。「rph」クレームの定義には、1つ以上のそのような追加情報フィールドが含まれる場合があります。「rph」クレームが他のデータ要素をどのように包含するかの詳細は、将来の仕様に残されています。

6. IANA Considerations

6. IANAに関する考慮事項

6.1. JSON Web Token Claims

6.1. JSON Web Tokenクレーム

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

[RFC7519]で定義されているように、IANAは「JSON Web Token Claims」レジストリに新しいクレームを追加しました。

o Claim Name: "rph"

o クレーム名：「rph」

o Claim Description: Resource Priority Header Authorization

o クレームの説明：リソースプライオリティヘッダーの承認

o Change Controller: IESG

o コントローラーの変更：IESG

o Specification Document(s): Section 3 of RFC 8443

o 仕様書：RFC 8443のセクション3

6.2. PASSporT Types

6.2. PASSporTタイプ

IANA has created a new entry in the "Personal Assertion Token (PASSporT) Extensions" registry for the type "rph", which is specified in this document. In addition, the "PASSporT Resource Priority Header (rph) Types" registry has been created in which each entry must contain two fields: the name of the "rph" type and the specification in which the type is described. This registry has been initially populated with the single value for "auth", which is specified in this document. Registration of new "rph" types shall be under the Specification Required policy[RFC8126].

IANAは、 "Personal Assertion Token（PASSporT）Extensions"レジストリに、このドキュメントで指定されている "rph"タイプの新しいエントリを作成しました。さらに、「PASSporT Resource Priority Header（rph）Types」レジストリが作成され、各エントリには「rph」タイプの名前とタイプが記述されている仕様の2つのフィールドが含まれている必要があります。このレジストリには最初、このドキュメントで指定されている「auth」の単一の値が入力されています。新しい「rph」タイプの登録は、Specification Requiredポリシー[RFC8126]の下で行われます。

7. Security Considerations

7. セキュリティに関する考慮事項

The security considerations discussed in [RFC8224], Section 12, are applicable here.

[RFC8224]のセクション12で説明されているセキュリティの考慮事項がここに適用されます。

7.1. Avoidance of Replay and Cut-and-Paste Attacks

7.1. リプレイおよびカットアンドペースト攻撃の回避

The PASSporT extension with a "ppt" value of "rph" MUST only be sent with SIP INVITE when the SIP 'Resource-Priority' header field is used to convey the priority of the communication, as defined in [RFC4412]. To avoid replay and cut-and-paste attacks, the recommendations provided in Section 12.1 of [RFC8224] MUST be followed.

[rph]の「ppt」値を持つPASSporT拡張は、[RFC4412]で定義されているように、SIP 'Resource-Priority'ヘッダーフィールドが通信の優先度を伝えるために使用される場合にのみ、SIP INVITEで送信する必要があります。リプレイ攻撃とカットアンドペースト攻撃を回避するには、[RFC8224]のセクション12.1に記載されている推奨事項に従う必要があります。

7.2. Solution Considerations

7.2. ソリューションの考慮事項

Using extensions to PASSporT tokens with a "ppt" value of "rph" requires knowledge of the authentication, authorization, and reputation of the signer to attest to the identity being asserted, including validating the digital signature and the associated certificate chain to a trust anchor. The following considerations should be recognized when using PASSporT extensions with a "ppt" value of "rph":

「ppt」値が「rph」のPASSporTトークンの拡張機能を使用するには、デジタル署名およびトラストアンカーへの関連する証明書チェーンの検証を含む、アサートされるIDを証明するための署名者の認証、承認、および評判に関する知識が必要です。。「rph」の「ppt」値でPASSporT拡張を使用する場合は、次の考慮事項を認識する必要があります。

o A signer is only allowed to sign the content of a SIP 'Resource-Priority' header field for which it has the proper authorization. Before signing tokens, the signer MUST have a secure method for authentication of the end user or the device being granted a token.

o 署名者は、適切な権限を持つSIP 'Resource-Priority'ヘッダーフィールドのコンテンツにのみ署名できます。トークンに署名する前に、署名者はエンドユーザーまたはトークンを付与されているデバイスを認証するための安全な方法を持っている必要があります。

o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the resource priority namespace in the PASSporT.

o 署名の検証には、署名者がPASSporTのリソースプライオリティネームスペースの署名されたコンテンツに対して信頼できることを検証する手段を含める必要があります。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

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

[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, DOI 10.17487/RFC4412, February 2006, <https://www.rfc-editor.org/info/rfc4412>.

[RFC4412] Schulzrinne、H。およびJ. Polk、「Communications Resource Priority for the Session Initiation Protocol（SIP）」、RFC 4412、DOI 10.17487 / RFC4412、2006年2月、<https://www.rfc-editor.org/ info / rfc4412>。

[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]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Token（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、「Session Initiation Protocol（SIP）での認証済みID管理」、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>。

8.2. Informative References

8.2. 参考引用

[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、「Secure Telephone Identity Problem Statement and Requirements」、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。、「Secure Telephone Identity Threat Model」、RFC 7375、DOI 10.17487 / RFC7375、2014年10月、<https://www.rfc-editor.org/info/rfc7375>。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。

Acknowledgements

謝辞

We would like to thank STIR Working Group members, the ATIS/SIP Forum Task Force on IPNNI members, and the NS/EP Priority Services community for contributions to this problem statement and specification. We would also like to thank David Hancock and Ning Zhang for their valuable inputs.

STIRワーキンググループメンバー、IPNNIメンバーに関するATIS / SIPフォーラムタスクフォース、およびNS / EP優先サービスコミュニティに、この問題の説明と仕様への貢献に感謝します。また、貴重な情報を提供してくれたDavid HancockとNing Zhangにも感謝します。

Authors' Addresses

著者のアドレス

Ray P. Singh Vencore Labs 150 Mount Airy Road New Jersey, NJ 07920 United States of America

レイP.シンベンコアラボ150 Mount Airy Roadニュージャージー、ニュージャージー07920アメリカ合衆国

   Email: rsingh@vencorelabs.com

Martin Dolly AT&T 200 Laurel Avenue Middletown, NJ 07748 United States of America

マーティンドリーAT＆T 200ローレルアベニューミドルタウン、ニュージャージー州07748アメリカ合衆国

   Email: md3135@att.com

Subir Das Vencore Labs 150 Mount Airy Road New Jersey, NJ 07920 United States of America

Subir Das Vencore Labs 150 Mount Airy Road New Jersey、NJ 07920アメリカ合衆国

   Email: sdas@vencorelabs.com

An Nguyen Office of Emergency Communications Department of Homeland Security 245 Murray Lane, Building 410 Washington, DC 20528 United States of America

アングエン緊急通信国土安全保障省245 Murray Lane、Building 410 Washington、DC 20528 United States of America

   Email: an.p.nguyen@HQ.DHS.GOV