Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 9970 TransUnion
Category: Standards Track C. Wendt
ISSN: 2070-1721 Somos
June 2026
The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. However, the Secure Telephone Identity Revisited (STIR) framework provides no means for determining the identity of the called party in a conventional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP identity that accompanied STIR. It also considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination and preventing the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties.
Session Initiation Protocol (SIP) Identity ヘッダー フィールドは、SIP リクエストの発信者に関する暗号化された ID 情報を伝えます。ただし、Secure Telephone Identity Revisited (STIR) フレームワークには、従来の電話通話シナリオで着信者の身元を確認する手段がありません。この文書は、STIR に伴う SIP ID への変更を反映するために、「接続された ID」問題に関する以前のガイダンスを更新します。また、意図された宛先を偽装する当事者に再ターゲットされた通話を検出し、仲介者や第三者による対話中または対話終了イベントのなりすましを防止する手段として、コネクテッド アイデンティティの問題空間の改訂も考慮されています。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9970.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9970 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Connected Identity Problem Statement for STIR
4. Connected Identity without Diversion
5. Connected Identity with Diversion
6. Connected Identity in Mid-Dialog and Dialog-Terminating
Requests
7. Authorization Policy for Callers
8. Creating Pre-Association with Destinations
9. The "rsp" PASSporT Type
10. UPDATE Procedures for Provisional Dialogs
11. IANA Considerations
12. Privacy Considerations
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Acknowledgments
Authors' Addresses
The Session Initiation Protocol (SIP) [RFC3261] initiates sessions, and as a step in establishing sessions, it exchanges information about the parties at both ends. Called users review information about the calling party, for example, to determine whether to accept communications initiated by SIP), in the same way that users of the telephone network assess "Caller ID" information before picking up calls. This information may sometimes be consumed by automated systems to make authorization decisions. STIR [RFC8224] provides a cryptographic assurance of the identity of calling parties in order to prevent impersonation, which is a key enabler of unwanted robocalls, swatting, vishing, voicemail hacking, and similar attacks (see [RFC7375]).
セッション開始プロトコル (SIP) [RFC3261] はセッションを開始し、セッションを確立するステップとして、両端の当事者に関する情報を交換します。着信側ユーザーは、電話ネットワークのユーザーが電話に出る前に「発信者 ID」情報を評価するのと同じ方法で、発信者に関する情報を確認して、たとえば SIP によって開始された通信を受け入れるかどうかを決定します。この情報は、承認の決定を行うために自動システムによって使用される場合があります。STIR [RFC8224] は、望ましくないロボコール、スワッティング、ビッシング、ボイスメール ハッキング、および同様の攻撃の主要な要因であるなりすましを防止するために、発信者の身元を暗号化して保証します ([RFC7375] を参照)。
A related problem also exists: The identity of the party who answers a call can differ from that of the initial called party for various innocuous reasons such as call forwarding. In certain network environments, however, it is possible for attackers to hijack the route of a called number and direct it to a resource controlled by the attacker. It can potentially be difficult to determine why a call reached a target other than the one originally intended and whether the party ultimately reached by the call is one that the caller should trust. Moreover, the lack of mutual authentication of parties makes it possible for outside attackers to inject forged messages (e.g., BYE) into a SIP session.
関連する問題も存在します。通話に応答する側の ID が、通話の転送などの無害なさまざまな理由により、最初の着信側の ID と異なる場合があります。ただし、特定のネットワーク環境では、攻撃者が着信番号のルートをハイジャックし、その番号を攻撃者が制御するリソースに誘導する可能性があります。通話が当初の目的以外のターゲットに到達した理由や、通話によって最終的に到達した相手が発信者が信頼すべき相手であるかどうかを判断するのは、潜在的に難しい場合があります。さらに、関係者の相互認証が欠如しているため、外部の攻撃者が偽造メッセージ (BYE など) を SIP セッションに挿入することが可能になります。
The property of providing the identity of the called party to the calling party is called "connected identity". Previous work on connected identity focused on fixing the core semantics of SIP. [RFC4916] allows a mid-dialog request, such as an UPDATE [RFC3311], to convey identity in either direction within the context of an existing INVITE-initiated dialog. [RFC4916] also allows that UPDATE to alter the From header field value for requests in the backwards direction; this is an update to the behavior described in [RFC3261], which requires that the From header field values sent in requests in the backwards direction reflect the To header field value of the dialog-forming request. Under the original rules in [RFC3261], if Alice sent a dialog-forming request to Bob, then even if Bob's SIP service forwarded that dialog-forming request to Carol, Carol would still be required to put Bob's identity in the From header field value in any mid-dialog requests in the backwards direction.
着信側の ID を発信側に提供する特性は、「接続 ID」と呼ばれます。コネクテッド アイデンティティに関するこれまでの取り組みは、SIP のコア セマンティクスの修正に焦点を当てていました。[RFC4916] では、UPDATE [RFC3311] などのダイアログ中のリクエストが、既存の INVITE で開始されたダイアログのコンテキスト内でどちらの方向にも ID を伝達できるようにします。[RFC4916] では、UPDATE がリクエストの From ヘッダフィールド値を逆方向に変更することも許可しています。これは、[RFC3261] で説明されている動作の更新であり、リクエストで逆方向に送信される From ヘッダー フィールドの値が、ダイアログ形成リクエストの To ヘッダー フィールドの値を反映することを要求します。[RFC3261] の元のルールでは、アリスがダイアログ形成リクエストをボブに送信した場合、ボブの SIP サービスがそのダイアログ形成リクエストをキャロルに転送したとしても、キャロルは依然として、ダイアログ中のリクエストの From ヘッダフィールド値にボブの ID を逆方向に入れる必要があります。
One of the original motivating use cases for [RFC4916] was the use of connected identity with the SIP Identity header field [RFC4474]. While a mid-dialog request in the backwards direction (e.g., UPDATE) can be signed with identity like any other SIP request, forwarded requests would not be properly signed without the ability to change the mid-dialog From header field value. Thus, Carol would not be able to furnish a key to sign for Bob's identity if Carol wanted to sign requests in the backwards direction. Carol would, however, be able to sign for her own identity in the From header field value if mid-dialog requests in the backwards direction were permitted to vary from the original To header field value.
[RFC4916] の元々の動機となったユースケースの 1 つは、SIP Identity ヘッダー フィールド [RFC4474] を使用した接続された ID の使用でした。逆方向のダイアログ中のリクエスト (UPDATE など) は、他の SIP リクエストと同様に ID で署名できますが、ダイアログ中の From ヘッダー フィールドの値を変更する機能がなければ、転送されたリクエストは適切に署名されません。したがって、キャロルが逆方向のリクエストに署名したい場合、キャロルはボブの身元に署名するための鍵を提供することができません。ただし、ダイアログ中の逆方向リクエストが元の To ヘッダー フィールド値から変更されることが許可されている場合、キャロルは From ヘッダー フィールド値で自分の ID に署名できます。
With the obsolescence of [RFC4474] by [RFC8224], this specification adapts the connected identity concepts of [RFC4916] to STIR, reflecting the changes to the SIP Identity header field and the revised problem space that STIR introduces. It also explores some new features that would be enabled by connected identity for STIR, including the use of connected identity to prevent route hijacking and to notify callers when an expected called party has successfully been reached. This document also addresses concerns about applying connected identity [RFC4916] to STIR discussed in the SIPBRANDY framework [RFC8862].
[RFC8224] による [RFC4474] の廃止に伴い、この仕様は [RFC4916] の接続アイデンティティ概念を STIR に適応させ、SIP Identity ヘッダフィールドの変更と STIR によって導入された改訂された問題空間を反映しています。また、ルート ハイジャックを防止するための接続 ID の使用や、予想される着信側に正常に到達したときに発信者に通知するための接続 ID の使用など、STIR の接続 ID によって可能になるいくつかの新機能についても検討します。この文書は、SIPBRANDY フレームワーク [RFC8862] で議論されている STIR に接続されたアイデンティティ [RFC4916] を適用することに関する懸念にも対処します。
One area of connected identity that is not explored in this document is the implications for conferencing, especially meshed conferencing systems. The scope of this mechanism is solely two-party communications; multiparty sharing of connected identity is left for future work.
このドキュメントでは説明されていないコネクテッド アイデンティティの領域の 1 つは、会議、特にメッシュ会議システムへの影響です。このメカニズムの範囲は、二者間通信のみです。接続された ID のマルチパーティ共有は将来の作業に残されています。
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] で説明されているように解釈されます。
This document assumes familiarity with common messages, response codes, and header fields used in SIP [RFC3261] and the elements present in the Personal Assertion Token (PASSporT) [RFC8225] format.
この文書は、SIP [RFC3261] で使用される一般的なメッセージ、応答コード、およびヘッダー フィールド、およびパーソナル アサーション トークン (PASSporT) [RFC8225] 形式に存在する要素に精通していることを前提としています。
The STIR problem statement [RFC7340] enumerates robocalling, voicemail hacking, vishing, and swatting as problems with the modern telephone network that are enabled, or abetted, by impersonation, i.e., the ability of a calling party to arbitrarily set the telephone number that will be rendered to end users to identify the caller.
STIR 問題声明 [RFC7340] では、現代の電話ネットワークの問題として、ロボコール、ボイスメール ハッキング、ビッシング、およびスワッティングが挙げられています。これらは、なりすまし、つまり、発信者が発信者を識別するためにエンド ユーザーに表示される電話番号を任意に設定できる電話番号を、発信者が任意に設定できることによって可能になる、または誘発されます。
Today, sophisticated adversaries can redirect calls on the Public Switched Telephone Network (PSTN) to destinations other than the intended called party. For some call centers, like those associated with financial institutions, healthcare, and emergency services, an attacker could hope to gain valuable information about people or to prevent some classes of important services. Moreover, on the Internet, the lack of any centralized or even federated routing system for telephone numbers has resulted in deployments where the routing of calls is arbitrary: Calls to telephone numbers might be dumped on a PSTN gateway, they might be sent to a default intermediary that makes forwarding decisions based on a local configuration file, potentially using various mechanisms such as consulting a private ENUM [RFC6116], or routing might be determined in some other, domain-specific way. In short, there are numerous attack surfaces that an adversary could explore to attempt to redirect calls for a particular number to someplace other than the intended destination.
現在、巧妙な攻撃者は、公衆交換電話網 (PSTN) 上の通話を、意図した着信者以外の宛先にリダイレクトすることができます。金融機関、医療、緊急サービスに関連するコールセンターなど、一部のコールセンターでは、攻撃者が人々に関する貴重な情報を取得したり、一部のクラスの重要なサービスを妨害したりすることを狙う可能性があります。さらに、インターネットでは、電話番号に対する集中ルーティング システムや統合ルーティング システムさえ欠如しているため、通話のルーティングが恣意的になる展開が生じています。電話番号への通話は PSTN ゲートウェイにダンプされる可能性があり、プライベート ENUM [RFC6116] を参照するなどのさまざまなメカニズムが使用される可能性があり、ローカル構成ファイルに基づいて転送決定を行うデフォルトの仲介者に送信される場合や、他のドメイン固有のルーティングで決定される場合があります。方法。つまり、攻撃者が特定の番号への通話を意図した宛先以外の場所にリダイレクトしようとする攻撃対象領域が多数存在します。
Another motivating use case for connected identity is mid-dialog requests, including BYE. The potential for an intermediary to generate a forged BYE in the backwards direction has always been built in to the stateful dialog management of SIP. For example, there is a class of mobile fraud attacks ("call stretching") that rely on intermediary networks making it appear to one side as if a call has terminated, while maintaining that the call is still active to the other side, in order to create a billing discrepancy that could be pocketed by the intermediary. If BYE requests in both directions of a SIP dialog could be authenticated with STIR, in the same way as dialog-forming requests, then another impersonation vector leading to fraud in the telephone network could be shut down.
接続された ID のもう 1 つの動機となるユースケースは、BYE を含むダイアログ中のリクエストです。SIP のステートフル ダイアログ管理には、仲介者が逆方向に偽の BYE を生成する可能性が常に組み込まれています。たとえば、ある種のモバイル詐欺攻撃 (「コール ストレッチング」) は、仲介ネットワークに依存して、一方の側には通話が終了したように見せながら、もう一方の側には通話がまだアクティブな状態を維持し、仲介者が巻き上げる可能性のある請求額の不一致を生み出します。SIP ダイアログの両方向の BYE リクエストを、ダイアログ形成リクエストと同じ方法で STIR で認証できれば、電話ネットワークでの不正行為につながる別のなりすましベクトルを遮断できる可能性があります。
Finally, telephone numbers are widely used today for two-factor authentication (TFA) prior to accessing web resources, which typically rely on sharing some sort of one-time password or similar unique link to validate control of a telephone number. These systems are often capable of using either telephone calls or messages for TFA. Connected identity is very valuable for these use cases because it gives a strong assurance to the calling party that they have in fact reached the telephone for the called telephone number.
最後に、電話番号は現在、Web リソースにアクセスする前の 2 要素認証 (TFA) に広く使用されています。これは通常、電話番号の制御を検証するために、ある種のワンタイム パスワードまたは同様の一意のリンクを共有することに依存しています。これらのシステムは多くの場合、TFA に電話またはメッセージを使用できます。コネクテッド ID は、発呼者に、実際に着信先の電話番号の電話に到達したという強い保証を与えるため、このようなユースケースでは非常に価値があります。
However, there are practical limits to what securing the signaling can achieve. [RFC4916] rightly observes that once a SIP call has been answered, the called party can be replaced by a different party (with a different identity) due to call transfer, call park and retrieval, and so on. In some cases, due to the presence of a back-to-back user agent, it can be effectively impossible for the calling party to know that this has happened. The problem statement considered for STIR focuses solely on signaling, not whether media from the connected party should be rendered to the caller when a dialog has been established. This specification does not consider further any threats that arise from a substitution of media, though [RFC8862] contains related guidance.
ただし、シグナリングのセキュリティ保護で達成できることには実際的な制限があります。[RFC4916] は、SIP コールが応答されると、コール転送、コール パーク、コール取得などにより、着信側が (異なる ID を持つ) 別の相手に置き換えられる可能性があることを正しく観察しています。場合によっては、バックツーバック ユーザー エージェントの存在により、発呼者がこれが起こったことを知ることが事実上不可能になることがあります。STIR に関して考慮された問題ステートメントは、ダイアログが確立されたときに接続側からのメディアを発信者にレンダリングする必要があるかどうかではなく、シグナリングのみに焦点を当てています。[RFC8862] には関連するガイダンスが含まれていますが、この仕様ではメディアの代替から生じる脅威についてはさらに考慮していません。
In straightforward call setup, the address-of-record (AoR) of the party reached by an INVITE corresponds to the "dest" field of the PASSporT in the INVITE's Identity header field value. The calling party will, however, have no secure assurance that they have reached the proper party if an Identity header field cannot be sent to them in the backwards direction. Provided that the terminating side of the dialog is STIR-capable, they should have the capacity to sign a PASSporT for the AoR of the called party.
単純なコール セットアップでは、INVITE が到達する相手のアドレス オブ レコード (AoR) は、INVITE の Identity ヘッダー フィールド値の PASSporT の「dest」フィールドに対応します。ただし、Identity ヘッダー フィールドを逆方向に送信できない場合、発呼者は適切な相手に到達したという安全な保証がありません。ダイアログの終了側が STIR 対応であれば、着信側の AoR の PASSporT に署名できる必要があります。
This specification therefore adds provisional and final SIP responses, including the 100, 180, 183, and 200 responses, to the set of messages that may contain an Identity header field. PASSporTs that appear in SIP responses SHOULD use a "ppt" of "rsp", which is defined in Section 9 (although "div" [RFC8946] may additionally appear in responses, per Section 5). PASSporTs of the "rsp" type will be referred to throughout this specification as "rsp" PASSporTs. At a high level, an "rsp" PASSporT is signed similarly to the "div" PASSporT [RFC8946], insofar as the certificate that signs an "rsp" PASSporT is signing the "dest" field rather than the "orig" field. If the terminating side does not possess an appropriate credential to sign for the value of the "dest" element value in the PASSporT, it MUST NOT sign and send an "rsp" PASSporT in the backwards direction.
したがって、この仕様では、Identity ヘッダー フィールドを含む可能性のあるメッセージのセットに、100、180、183、および 200 応答を含む暫定および最終の SIP 応答を追加します。SIP 応答に現れる PASSporT は、セクション 9 で定義されている「rsp」の「ppt」を使用すべきです (ただし、セクション 5 に従って、「div」[RFC8946] は追加で応答に現れる可能性があります)。「rsp」タイプの PASSporT は、本明細書全体を通じて「rsp」PASSporT と呼ばれます。高いレベルでは、「rsp」PASSporT は、「rsp」PASSporT に署名する証明書が「orig」フィールドではなく「dest」フィールドに署名している限り、「div」PASSporT [RFC8946]と同様に署名されます。着信側が PASSporT の "dest" 要素の値に署名するための適切な資格情報を所有していない場合は、署名して "rsp" PASSporT を逆方向に送信してはなりません (MUST NOT)。
While it might seem attractive to provide identity for SIP failure response codes (4XX, 5XX, 6XX), those explicitly do not form dialogs or connections and are thus outside the scope of this specification. The same applies to SIP redirect (3XX) response codes, though see Section 7 of [RFC8946] for guidance on authentication redirection.
SIP 障害応答コード (4XX、5XX、6XX) の ID を提供することは魅力的に見えるかもしれませんが、これらは明示的にダイアログや接続を形成しないため、この仕様の範囲外です。同じことが SIP リダイレクト (3XX) 応答コードにも当てはまりますが、認証リダイレクトに関するガイダンスについては [RFC8946] のセクション 7 を参照してください。
It is worth noting that at the time [RFC4916] was written, the identity mechanism was far stricter about what counted as retargeting than is described in [RFC8224], which has canonicalization processes that eliminate minor changes to the URIs, especially when telephone numbers are the identifiers used by the caller and callee. For basic use cases, a PASSporT in a 183 or 200 OK should be sufficient to secure media keys for the purposes of SIPBRANDY [RFC8862].
[RFC4916] が書かれた時点では、ID メカニズムは、リターゲティングとしてカウントされるものに関して、[RFC8224] で説明されているものよりもはるかに厳密であったことは注目に値します。RFC8224 には、特に電話番号が発信者と着信者が使用する識別子である場合に、URI への軽微な変更を排除する正規化プロセスがあります。基本的な使用例では、SIPBRANDY [RFC8862] の目的でメディアキーを保護するには、183 または 200 OK の PASSporT で十分です。
The handling of an "rsp" PASSporT differs from the handling of a PASSporT received in a SIP request. Most importantly, note that SIP responses cannot be rejected, unlike SIP requests -- there is no way for the recipient of a response to report errors to the sender. The only protocol action that the calling party could take upon receiving a response carrying a problem PASSporT is to issue a CANCEL (for provisional dialogs) or BYE request in order to tear down the dialog (see Section 7). Moreover, provisional responses are not reliably delivered without using 100rel and Provisional Response Acknowledgement (PRACK) [RFC3262], and provisional responses may be consumed (without forwarding) by intermediaries under a variety of conditions. In short, their delivery is not guaranteed.
「rsp」PASSporT の処理は、SIP リクエストで受信した PASSporT の処理とは異なります。最も重要なことは、SIP 要求とは異なり、SIP 応答は拒否できないことに注意してください。応答の受信者が送信者にエラーを報告する方法はありません。問題のある PASSporT を含む応答を受信したときに発呼者が実行できる唯一のプロトコル アクションは、ダイアログを破棄するために CANCEL (暫定的なダイアログの場合) または BYE リクエストを発行することです (セクション 7 を参照)。さらに、暫定応答は 100rel および暫定応答確認 (PRACK) [RFC3262] を使用しないと確実に配信されず、暫定応答はさまざまな条件下で仲介者によって (転送されずに) 消費される可能性があります。つまり、配信は保証されていません。
Use cases involving authorized retargeting motivate connected identity. When a call acquires a new target (in its Request-URI) during transit, then the destination will no longer correspond to the target, the "dest" specified by the PASSporT in the dialog-forming request. If a PASSporT in a response came signed by a different destination than the caller intended, why should the caller trust it?
承認されたリターゲティングを含むユースケースは、接続された ID を動機付けます。呼び出しが転送中に新しいターゲット (Request-URI 内) を取得すると、宛先はターゲット、つまりダイアログ形成リクエストの PASSporT で指定された「dest」に対応しなくなります。応答内の PASSporT が呼び出し元が意図したものとは異なる宛先によって署名された場合、呼び出し元はなぜそれを信頼する必要があるのでしょうか?
In STIR, the "div" PASSporT type [RFC8946] was created to securely record when a call was retargeted from one destination to another. Those "div" PASSporTs can be consumed on the terminating side by verification services to determine that a call has reached its eventual destination for the right reasons. As [RFC8946] explains the situation, the only way those diversion PASSporTs will be seen by the calling party is if redirection is used (SIP 3XX responses) instead of retargeting. Because some network policies aim to conceal service logic from the originating party, sending redirections in the backwards direction is the only currently defined way for secure indications of redirection to be revealed to the calling party. That in turn would allow the calling user agent to have a strong assurance that legitimate entities in the call path caused the request to reach a party that the caller did not anticipate.
STIR では、通話がある宛先から別の宛先に再ターゲットされたときを安全に記録するために、「div」PASSporT タイプ [RFC8946] が作成されました。これらの「div」PASSporT は、通話が正しい理由で最終的な宛先に到達したかどうかを判断するために、検証サービスによって着信側で使用できます。[RFC8946] が状況を説明しているように、これらの転送 PASSporT が発呼者に表示される唯一の方法は、リターゲティングの代わりにリダイレクション (SIP 3XX 応答) が使用される場合です。一部のネットワーク ポリシーはサービス ロジックを発信側から隠すことを目的としているため、逆方向にリダイレクトを送信することが、現在定義されている、リダイレクトの安全な表示を発信側に明らかにする唯一の方法です。これにより、呼び出し元のユーザー エージェントは、呼び出しパス内の正当なエンティティによって、呼び出し元が予期していなかった相手にリクエストが到達したという強い確信を持つことができます。
This specification introduces another alternative. When sending an "rsp" PASSporT type in a SIP response, a User Agent Server (UAS) MAY also include (in Identity header field values) any "div" PASSporTs it received in the INVITE that initiated this dialog. Thus, PASSporTs of type "div" MAY also appear in SIP responses. These "div" PASSporTs can enable the originating side to receive a secure assurance that the call is being fielded by the proper recipient per the routing of the call. In this case, the "dest" signed in the "rsp" PASSporT MUST be the address-of-record of the party who was reached rather than the "dest" of the PASSporT received in the dialog-initiating INVITE.
この仕様では、別の代替手段を導入しています。SIP 応答で「rsp」PASSporT タイプを送信する場合、ユーザー エージェント サーバー (UAS) は、このダイアログを開始した INVITE で受信したすべての「div」PASSporT を (Identity ヘッダー フィールド値に) 含めることもできます (MAY)。したがって、タイプ「div」の PASSporT も SIP 応答に現れてもよい(MAY)。これらの「div」PASSporT により、発信側は、通話のルーティングごとに、通話が適切な受信者によって処理されているという安全な保証を受け取ることができます。この場合、「rsp」PASSporTで署名された「dest」は、ダイアログを開始するINVITEで受信したPASSporTの「dest」ではなく、到達した当事者のレコードのアドレスでなければなりません。
An "rsp" PASSporT that signs a different "dest" than the one that appeared in the PASSporT of the dialog-forming request MUST send at least one "div" PASSporT with it. If no "div" PASSporTs were received in a dialog-forming request with a different "dest" value than the original PASSporT claimed, then "rsp" PASSporTs MUST NOT be used in responses. "div" is not universally supported, so calls MAY be retargeted without generating a "div" PASSporT, in which case the use of "rsp" PASSporTs will not be possible. Note that the decision to trust any "div" or "rsp" PASSporT is, as always in STIR, a matter of local policy of the relying parties: Some stricter systems may not want to trust any "rsp" that differs from the "dest" in the PASSporT of the original request.
ダイアログ形成リクエストの PASSporT に現れたものとは異なる「dest」に署名する「rsp」PASSporT は、少なくとも 1 つの「div」PASSporT を一緒に送信しなければなりません (MUST)。元の PASSporT が要求したものとは異なる "dest" 値を持つダイアログ形成リクエストで "div" PASSporT が受信されなかった場合、応答で "rsp" PASSporT を使用してはなりません (MUST NOT)。"div" は普遍的にサポートされていないため、"div" PASSporT を生成せずに呼び出しを再ターゲットしてもよい(MAY)。その場合、"rsp" PASSporT は使用できなくなる。STIR では常にそうであるように、「div」または「rsp」PASSporT を信頼するかどうかの決定は、依存当事者のローカル ポリシーの問題であることに注意してください。一部のより厳密なシステムでは、元のリクエストの PASSporT の「dest」と異なる「rsp」を信頼したくない場合があります。
Note that sending "div" PASSporTs in the backwards direction will potentially reveal service logic to the called party. As presumably this service logic is enacted on behalf of the called party, the called party can make a policy determination about reflecting those "div" PASSporTs back to the caller; connected identity may not be compatible with some operator policies.
「div」PASSporT を逆方向に送信すると、サービス ロジックが着信側に明らかになる可能性があることに注意してください。おそらくこのサービス ロジックは着信側に代わって制定されるため、着信側はこれらの「div」PASSporT を発信者に反映することに関するポリシー決定を行うことができます。接続された ID は、一部の通信事業者のポリシーと互換性がない場合があります。
This mechanism does not require altering the value of the From header field value in requests or responses in the backwards direction. While this was a major concern of [RFC4916], in many operating environments, the From header field value does not even contain the identity of the caller that has been asserted by the network, which is instead conveyed by the P-Asserted-Identity (PAID) header field [RFC3325]. The contents of PAID were never used for dialog matching, and so in environments where PAID is used, it can be altered more dynamically than the From header field (moreover, by introducing tag parameters to the To and From header field values, [RFC3261] eliminates the need for stability in From values for dialog identification some time ago). For retargeting that utilizes the "from-change" option tag in [RFC4916], see Section 10. STIR is, in general, more flexible in constructing the "dest" than the Identity header field managed addresses-of-record at the time [RFC4916] was written.
このメカニズムでは、リクエストまたはレスポンスの From ヘッダー フィールドの値を逆方向に変更する必要はありません。これは [RFC4916] の主要な懸念事項でしたが、多くの動作環境では、From ヘッダー フィールドの値には、ネットワークによってアサートされた呼び出し元の ID さえ含まれず、代わりに P-Asserted-Identity (PAID) ヘッダー フィールド [RFC3325] によって伝えられます。PAID の内容はダイアログのマッチングには決して使用されないため、PAID が使用される環境では、From ヘッダー フィールドよりも動的に変更できます (さらに、[RFC3261] では、To および From ヘッダー フィールドの値にタグ パラメーターを導入することにより、少し前にダイアログ識別のための From 値の安定性の必要性がなくなりました)。[RFC4916] の "from-change" オプション タグを利用するリターゲットについては、セクション 10 を参照してください。 一般に、STIR は、[RFC4916] が書かれた時点での Identity ヘッダー フィールドで管理されるレコードのアドレスよりも、"dest" の構築においてより柔軟です。
The use of the connected identity mechanism specified in this document is not limited to provisional dialog requests. Once a dialog has been established with connected identity, any re-INVITEs from either the originating and terminating side, as well as any BYE requests, SHOULD contain Identity header fields with valid PASSporTs. If only the terminating side supports connected identity, obviously the originator cannot be expected to know that it needs to send PASSporTs for subsequent requests like BYE. Doing so prevents third parties from spoofing any mid-dialog requests in order to redirect media or similarly interfere with communications, and it also prevents denial-of-service teardowns by attackers.
この文書で指定されている接続された ID メカニズムの使用は、暫定的なダイアログ要求に限定されません。接続された ID でダイアログが確立されると、発信側と終了側のいずれかからの re-INVITE、および BYE リクエストには、有効な PASSporT を持つ Identity ヘッダー フィールドが含まれる必要があります (SHOULD)。接続された ID を終端側だけがサポートしている場合、発信者は BYE などの後続の要求に対して PASSporT を送信する必要があることを知ることはできません。そうすることで、第三者がメディアをリダイレクトしたり、同様に通信を妨害したりするために、ダイアログ中のリクエストをなりすますことがなくなり、攻撃者によるサービス妨害の破壊も防ぐことができます。
Theoretically, any SIP requests in a dialog could be signed in this fashion, though it is unclear how valuable it would be for some (e.g., OPTIONS). Requests with specialized payloads such as INFO or MESSAGE, however, would require additional specification for how integrity protection for their bodies could be implemented. Some work has been done toward that for MESSAGE (see [RFC9475]). This specification thus does not recommend PASSporTs for any requests sent in a dialog other than INVITE, UPDATE, and BYE.
理論的には、ダイアログ内のすべての SIP リクエストはこの方法で署名できますが、一部のもの (オプションなど) にとってそれがどれほど価値があるかは不明です。ただし、INFO や MESSAGE などの特殊なペイロードを含むリクエストでは、その本体の整合性保護を実装する方法について追加の仕様が必要になります。MESSAGE に関しては、それに向けていくつかの作業が行われています ([RFC9475] を参照)。したがって、この仕様では、INVITE、UPDATE、BYE 以外のダイアログで送信されるリクエストに対して PASSporT を推奨しません。
It might seem tempting to require that, if an INVITE has been sent with an Identity header field containing a PASSporT, any CANCEL request received for the dialog initiated by that INVITE must also contain an Identity header field with a PASSporT. However, CANCEL requests can also be sent by stateful proxy servers engaged in parallel forking, for example, when branches need to be canceled because a final response has been received from a UAS. This specification does not forbid a User Agent Client (UAC) from sending a CANCEL for its own PASSporT-protected INVITE requests, as there may be limited use cases where it would be useful to relying parties, but recipients of a CANCEL should not expect PASSporTs to be present in connected identity cases.
PASSporT を含む Identity ヘッダー フィールドを含む INVITE が送信された場合、その INVITE によって開始されたダイアログに対して受信される CANCEL リクエストには、PASSporT を含む Identity ヘッダー フィールドも含まれている必要があると要求したくなるかもしれません。ただし、CANCEL リクエストは、たとえば、UAS から最終応答を受信したためにブランチをキャンセルする必要がある場合など、並列フォークに関与しているステートフル プロキシ サーバーによって送信されることもあります。この仕様は、ユーザー エージェント クライアント (UAC) が、自身の PASSporT で保護された INVITE リクエストに対して CANCEL を送信することを禁止しません。これは、依存当事者にとって有用な使用例が限られている可能性があるためですが、CANCEL の受信者は、接続された ID ケースに PASSporT が存在することを期待すべきではありません。
Mid-dialog requests also require special handling in diversion cases. Relying parties who intended to trust an "rsp" PASSporT MUST validate any "div" chain back to the "rsp" PASSporT on any Identity header field values received in responses (per [RFC8946]). The dialog initiator can then treat the certificate that signed that "rsp" PASSporT as the appropriate certificate to sign any further mid-dialog or dialog-terminating requests received in the backwards direction. Furthermore, the "dest" element value in any requests or responses sent in the backwards direction during this dialog MUST be the same as the "dest" element value in the first response to the dialog-forming request that contains a PASSporT -- unless the "from-change" extension is used, per Section 10.
ダイアログ中のリクエストも、転送の場合に特別な処理を必要とします。"rsp" PASSporT を信頼するつもりだった依存者は、応答で受信した Identity ヘッダー フィールドの値について、"rsp" PASSporT に戻る "div" チェーンを検証しなければなりません ([RFC8946] に従って)。その後、ダイアログの開始者は、その「rsp」PASSporT に署名した証明書を、逆方向に受信したさらなるダイアログ中リクエストまたはダイアログ終了リクエストに署名するための適切な証明書として扱うことができます。さらに、このダイアログ中に逆方向に送信されるリクエストまたはレスポンスの「dest」要素値は、セクション 10 に従い、「from-change」拡張子が使用されない限り、PASSporT を含むダイアログ形成リクエストに対する最初のレスポンスの「dest」要素値と同じでなければなりません (MUST)。
In a conventional telephone call, the called party receives an alerting signal and can make a decision about whether or not to pick up a phone. They may have access to displayed information, like "Caller ID", to help them arrive at an authorization decision. However, the situation is more complicated for callers because they typically expect to be connected to the proper destination and are often holding telephones in a position that would not enable them to see displayed information if any were available for them to review. Moreover, their most direct response to a security breach would be to hang up the call they were in the middle of placing.
従来の電話通話では、着信側は警告信号を受信し、電話に出るかどうかを決定できます。ユーザーは、承認の決定に到達するために、「発信者番号」などの表示された情報にアクセスできる場合があります。ただし、発信者にとって状況はより複雑です。発信者は通常、適切な宛先に接続されることを期待しており、確認できる情報が表示されている場合でも表示されない位置に電話機を保持していることが多いためです。さらに、セキュリティ侵害に対する最も直接的な反応は、通話中の電話を切ることです。
While this specification does not prescribe any user experience associated with placing a call, it assumes that callers might have some way to a set an authorization posture that will result in the right thing happening when the connected identity is not as expected. This is analogous to a situation where Secure Real-time Transport Protocol (SRTP) negotiation fails because the keys exchanged at the media layer do not match the fingerprints exchanged at the signaling layer: When a user requests confidentiality services and they are unavailable, media should not be exchanged. Thus, we assume that users have a way in their interface to require this criticality, on a per-call basis or perhaps on a per-destination basis. Users will not always place calls where the connected identity is crucial, but when they do, they should have a way to tell their devices that the call should not be completed if it arrives at an unexpected or unauthenticated party.
この仕様では、通話に関連するユーザー エクスペリエンスについては規定していませんが、接続された ID が期待どおりでない場合に、発信者が承認ポスチャーを設定する何らかの方法を備えている可能性があることを前提としています。これは、メディア層で交換されたキーがシグナリング層で交換されたフィンガープリントと一致しないためにセキュア リアルタイム トランスポート プロトコル (SRTP) ネゴシエーションが失敗する状況に似ています。ユーザーが機密性サービスを要求し、それが利用できない場合、メディアは交換されるべきではありません。したがって、ユーザーは、通話ごと、またはおそらく宛先ごとに、この重要性を要求する方法をインターフェイスに持っていると想定します。ユーザーは、接続された ID が重要な場所で常に通話を行うわけではありませんが、その場合は、予期しない相手や認証されていない相手に通話が届いた場合には通話を終了してはならないことをデバイスに伝える方法が必要です。
Any connected identity mechanism will work best if the user knows before initiating a call that connected identity is supported by the destination side. Not every institution that a user wants to connect to securely will support STIR and connected identity out of the gate. Some sort of directory service might exist that advertises support for connected identity, which institutions then could use to inform potential callers that, if connected identity is not supported when reaching them with SIP, there is a potential security problem. Similarly, user devices might keep some sort of log recording that a destination previously supported connected identity, so that if support is unavailable later, calling users could be alerted to a potential security problem.
接続された ID メカニズムは、接続された ID が宛先側でサポートされていることを通話を開始する前にユーザーが知っている場合に最適に機能します。ユーザーが安全に接続したいすべての機関が、STIR と接続された ID をすぐにサポートしているわけではありません。接続された ID のサポートを宣伝するある種のディレクトリ サービスが存在する可能性があり、教育機関はこれを使用して、潜在的な発信者に、SIP で接続するときに接続された ID がサポートされていない場合、セキュリティ上の問題が発生する可能性があることを通知できます。同様に、ユーザー デバイスは、接続先が以前にサポートしていた接続 ID を記録する何らかのログを保持する場合があります。これにより、後でサポートが利用できなくなった場合に、発信ユーザーに潜在的なセキュリティ問題について警告を与えることができます。
The user interface of modern smartphones supports an address book from which users select telephone numbers to dial. Even when dialing a number manually, the interface frequently checks the address book, which will display to users any provisioned name for the target of the call if one exists. Similarly, when clicking on a telephone number viewed on a web page or similar service, smartphones often prompt users to approve the access to the outbound dialer. These sorts of decision points, when the user is still interacting with the user interface before a call is placed, provide an opportunity to probe what identity would be reached as a destination and potentially even to exchange STIR PASSporTs in order to validate whether or not the expected destination can be reached securely. Again, this is probably most meaningful for contacting financial, government, or emergency services, for cases where reaching an unintended destination may have serious consequences.
最新のスマートフォンのユーザー インターフェイスは、ユーザーがダイヤルする電話番号を選択するためのアドレス帳をサポートしています。手動で番号をダイヤルする場合でも、インターフェイスはアドレス帳を頻繁にチェックし、通話のターゲットにプロビジョニングされた名前が存在する場合はそれをユーザーに表示します。同様に、スマートフォンでは、Web ページまたは同様のサービスで表示された電話番号をクリックすると、発信ダイヤラへのアクセスを承認するようユーザーに求められることがよくあります。この種の決定ポイントは、通話を行う前にユーザーがまだユーザー インターフェイスを操作しているときに、宛先としてどのような ID に到達するかを調査する機会を提供し、場合によっては、予想される宛先に安全に到達できるかどうかを検証するために STIR PASSporT を交換する機会も提供します。繰り返しになりますが、これはおそらく、意図しない目的地に到達した場合に重大な結果が生じる可能性がある場合に、金融サービス、政府サービス、または緊急サービスに連絡する場合に最も意味があります。
The establishment of media-less dialogs has long been specified as a component of third-party call control in SIP [RFC3725], in which an INVITE is sent with no Session Description Protocol (SDP). Similar media-less dialogs have been proposed for certain automated systems per [RFC5552]. In the STIR context, a media-less dialog is established by sending an INVITE with an Identity header field but no SDP. When a STIR-aware UAS that supports this specification receives an INVITE that has no SDP, carries a PASSporT, and includes a 100rel in the Require header field value, it SHOULD follow the mechanism described in Section 4 to send a provisional response carrying a PASSporT in the backwards direction. The PASSporT received in the backwards direction could be rendered to the originating user to help them decide if they want to place the call.
メディアレス ダイアログの確立は、SIP [RFC3725] のサードパーティ通話制御のコンポーネントとして長い間指定されており、セッション記述プロトコル (SDP) なしで INVITE が送信されます。同様のメディアレスダイアログは、[RFC5552] に従って特定の自動化システムに対して提案されています。STIR コンテキストでは、メディアレス ダイアログは、Identity ヘッダー フィールドを含むが SDP を含まない INVITE を送信することによって確立されます。この仕様をサポートする STIR 認識 UAS が、SDP を持たず、PASSporT を伝送し、Require ヘッダーフィールド値に 100rel を含む INVITE を受信した場合、セクション 4 で説明されているメカニズムに従って、PASSporT を伝送する暫定応答を逆方向に送信する必要があります (SHOULD)。逆方向に受信した PASSporT は、発信元のユーザーに表示され、通話を発信するかどうかを決定するのに役立ちます。
This specification defines an "rsp" PASSporT type that is sent only in SIP responses; it MUST NOT be sent in SIP requests. Any "rsp" PASSporTs received in requests MUST be ignored.
この仕様では、SIP 応答でのみ送信される「rsp」PASSporT タイプを定義します。SIP リクエストで送信してはなりません。リクエストで受信した「rsp」PASSporT はすべて無視しなければなりません (MUST)。
The header of an "rsp" PASSporT shows a "ppt" of "rsp":
「rsp」PASSporT のヘッダーには、「rsp」の「ppt」が表示されます。
{ "typ":"passport",
"ppt":"rsp",
"alg":"ES256",
"x5u":"https://www.example.com/cert.pem" }
The payload of an "rsp" PASSporT looks entirely like a normal PASSporT -- the only difference is in semantics, as the PASSporT is signed to authenticate the "dest" claim value rather than the "orig".
「rsp」PASSporT のペイロードは通常の PASSporT とまったく同じように見えます。PASSporT は「orig」ではなく「dest」クレーム値を認証するために署名されているため、唯一の違いはセマンティクスにあります。
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]},
"iat":1443208345 }
No restrictions are placed here on additional elements appearing in the payload of an "rsp" type PASSporT.
ここでは、「rsp」タイプ PASSporT のペイロードに現れる追加要素には制限がありません。
[RFC4916] identifies a means of sending Identity header field values in the backwards direction before a final response to a dialog has been received by the UAC. It relies on negotiating support for "from-change" options tags on both sides, followed by the use of the UPDATE method to send the connected identity in the backwards direction. This can only happen after the UAS has received and responded to a PRACK [RFC3262] from the UAC, which would in turn have been triggered by a provisional 1xx response sent earlier by the UAC.
[RFC4916] は、ダイアログへの最終応答が UAC によって受信される前に、Identity ヘッダフィールド値を逆方向に送信する手段を特定しています。これは、両側での「from-change」オプション タグのサポートのネゴシエーションに依存し、その後 UPDATE メソッドを使用して接続された ID を逆方向に送信します。これは、UAS が UAC から PRACK [RFC3262] を受信して応答した後にのみ発生します。PRACK [RFC3262] は、UAC によって以前に送信された暫定 1xx 応答によってトリガーされます。
However, the complexity of this mechanism makes it impractical to deploy for both the primary use case and the diversion use case described above. It may still have utility for corner cases with legacy versions of SIP (that date before the addition of the To and From header field value tags) or more complex call parking scenarios. As such, this specification does not deprecate the "from-change" behavior in [RFC4916], nor does it provide an update for it for STIR -- that is left for future work.
ただし、このメカニズムは複雑であるため、上記の主なユースケースと転用ユースケースの両方に導入するのは非現実的です。従来のバージョンの SIP (To ヘッダー フィールドと From ヘッダー フィールドの値タグが追加される前の日付) や、より複雑なコール パーキング シナリオでの特殊なケースでは、依然として有用である可能性があります。そのため、この仕様は [RFC4916] の「from-change」動作を非推奨にするものではなく、STIR 用の更新も提供しません。これは将来の作業に残されています。
This specification defines a new PASSporT type for the "Personal Assertion Token (PASSporT) Extensions" registry [RFC8225], which resides at <https://www.iana.org/assignments/passport/>:
この仕様は、<https://www.iana.org/assignments/passport/> にある「Personal Assertion Token (PASSporT) Extensions」レジストリ [RFC8225] の新しい PASSporT タイプを定義します。
ppt value:
ppt値:
rsp
返信
Reference:
参照：
RFC 9970, Section 9
RFC 9970、セクション 9
Note that sending connected identity can reveal information about the called party. If a called party does not wish to be identified, it is especially important not to share rich call data (RCD) in the backwards direction, particular in business-to-consumer calling cases. From a user experience perspective, this would likely work similarly to current systems for sharing numbers, names, and even pictures from calling parties to called parties -- users have considerable control over that experience, and similarly for connected identity, this must be an opt-in choice for users. In general, RCD is more commonly used by enterprises than by individual users.
接続された ID を送信すると、着信側に関する情報が漏洩する可能性があることに注意してください。着信側が特定されることを望まない場合、特に企業から消費者への通話の場合、リッチ通話データ (RCD) を逆方向に共有しないことが特に重要です。ユーザー エクスペリエンスの観点から見ると、これは、発信者から着信者に番号、名前、さらには写真さえ共有する現在のシステムと同様に機能する可能性があります。ユーザーはそのエクスペリエンスをかなり制御できます。また、コネクテッド アイデンティティについても同様に、これはユーザーのオプトイン選択でなければなりません。一般に、RCD は個人ユーザーよりも企業でよく使用されます。
The security considerations of [RFC8224] and [RFC8225] apply to the use of the "rsp" PASSporT. In general, a PASSporT of type "rsp" has similar security properties to a diversion ("div") PASSporT [RFC8946]. Relying parties leverage an "rsp" PASSporT to determine the recipient of a request, and as with "div", the "dest" element of an "rsp" PASSporT is signed rather than the "orig" element.
[RFC8224] および [RFC8225] のセキュリティに関する考慮事項は、「rsp」PASSporT の使用に適用されます。一般に、「rsp」タイプの PASSporT は、転送 (「div」) PASSporT [RFC8946] と同様のセキュリティ特性を持っています。証明書利用者は、「rsp」PASSporT を利用してリクエストの受信者を決定します。「div」と同様に、「rsp」PASSporT の「dest」要素は、「orig」要素ではなく署名されます。
The major threat that "rsp" addresses is the impersonation of a SIP response or mid-dialog/dialog-terminating request. For the latter, this might include forging a BYE for a denial-of-service attack or, for example, forging a re-INVITE that negotiates media channels controlled by an attacker. For the former, some form of route hijacking or similar attack can be mounted by forging a dialog-forming response that appears to the caller to initiate a dialog with the intended destination. The "rsp" mechanism uses PASSporTs to provide a non-repudiable assurance of the signer of such responses and requests.
「rsp」が対処する主な脅威は、SIP 応答またはダイアログ中/ダイアログ終了リクエストのなりすましです。後者の場合、これには、サービス拒否攻撃に対する BYE の偽造や、攻撃者が制御するメディア チャネルをネゴシエートする re-INVITE の偽造などが含まれる可能性があります。前者の場合、目的の宛先とのダイアログを開始するために発信者に表示されるダイアログ形成応答を偽造することにより、何らかの形式のルート ハイジャックまたは同様の攻撃が仕掛けられる可能性があります。「rsp」メカニズムは PASSporT を使用して、そのような応答や要求の署名者の否認不可能な保証を提供します。
The value of an "rsp" PASSporT to relying parties, as with all PASSporTs, depends on the relying party trusting the certificate that signs the PASSporT and having a reasonable assurance that the certificate in question is eligible to sign responses/requests for the number in the "dest" claim of the "rsp" PASSporT. For STIR certificates that use Service Provider Codes (SPCs), effectively the relying party knows the network operator who is vouching for that "rsp". This in turn enables traceback and similar mitigations.
すべての PASSporT と同様に、信頼当事者にとっての「rsp」PASSporT の価値は、信頼当事者が PASSporT に署名する証明書を信頼し、問題の証明書が「rsp」PASSporT の「dest」クレーム内の番号に対する応答/要求に署名する資格があるという合理的な保証を持っているかどうかによって決まります。サービス プロバイダー コード (SPC) を使用する STIR 証明書の場合、証明書利用者は事実上、その「rsp」を保証しているネットワーク オペレーターを知っています。これにより、トレースバックや同様の軽減策が可能になります。
As mentioned in Section 5, the use of "div" along with "rsp" in responses may reveal the service logic of diversions to calling parties. However, since the called party ultimately invokes the "rsp" mechanism, any necessary policy controls can prevent the sending of "rsp" when that service logic must be protected.
セクション 5 で述べたように、応答で「rsp」とともに「div」を使用すると、発信者への迂回のサービス ロジックが明らかになる可能性があります。ただし、着信側が最終的に「rsp」メカニズムを呼び出すため、そのサービス ロジックを保護する必要がある場合、必要なポリシー制御によって「rsp」の送信が阻止される可能性があります。
The use of PASSporTs within responses creates a novel potential vector for amplification attacks, as many responses may be sent in response to a single SIP request, and the presence of a PASSporT meaningfully increases the size of SIP responses. However, given that PASSporTs can only be present in responses to requests carrying a PASSporT, and thus requests with strong sender authentication, called parties have adequate means to authorize the source of requests and disregard spoofs intended to trigger amplification attacks.
応答内で PASSporT を使用すると、単一の SIP 要求に応答して多数の応答が送信される可能性があり、PASSporT の存在により SIP 応答のサイズが大幅に増加するため、増幅攻撃の新たな潜在的なベクトルが作成されます。ただし、PASSporT は、PASSporT を含むリクエスト、つまり強力な送信者認証を伴うリクエストへの応答でのみ存在できることを考慮すると、着信側にはリクエストの送信元を認証し、増幅攻撃を引き起こすことを目的としたスプーフィングを無視する適切な手段があります。
[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>.
[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, July 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, DOI 10.17487/RFC3262, July 2002,
<https://www.rfc-editor.org/info/rfc3262>.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
2002, <https://www.rfc-editor.org/info/rfc3311>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, December 2002,
<https://www.rfc-editor.org/info/rfc3325>.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<https://www.rfc-editor.org/info/rfc3725>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <https://www.rfc-editor.org/info/rfc4916>.
[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>.
[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>.
[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>.
[RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices
for Securing RTP Media Signaled with SIP", BCP 228,
RFC 8862, DOI 10.17487/RFC8862, January 2021,
<https://www.rfc-editor.org/info/rfc8862>.
[RFC8946] Peterson, J., "Personal Assertion Token (PASSporT)
Extension for Diverted Calls", RFC 8946,
DOI 10.17487/RFC8946, February 2021,
<https://www.rfc-editor.org/info/rfc8946>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media
Services", RFC 5552, DOI 10.17487/RFC5552, May 2009,
<https://www.rfc-editor.org/info/rfc5552>.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011,
<https://www.rfc-editor.org/info/rfc6116>.
[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>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
RFC 7375, DOI 10.17487/RFC7375, October 2014,
<https://www.rfc-editor.org/info/rfc7375>.
[RFC9475] Peterson, J. and C. Wendt, "Messaging Use Cases and
Extensions for Secure Telephone Identity Revisited
(STIR)", RFC 9475, DOI 10.17487/RFC9475, December 2023,
<https://www.rfc-editor.org/info/rfc9475>.
We would like to thank Russ Housley, Jonathan Rosenberg, and Orie Steele for their contributions to this specification.
この仕様への貢献に対し、Russ Housley、Jonathan Rosenberg、Orie Steele に感謝いたします。
Jon Peterson
TransUnion
Email: jon.peterson@transunion.com
Chris Wendt
Somos
Email: chris@appliedbits.com