[要約] RFC 8844は、TLSとSDPの使用における未知のKey-Share攻撃に関する標準化ドキュメントです。このRFCの目的は、TLSとSDPの組み合わせにおけるセキュリティ上のリスクを識別し、対策を提供することです。TLSとSDPの組み合わせを使用する際に発生する潜在的な脆弱性に対処するためのガイドラインを提供しています。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8844 E. Rescorla
Updates: 8122 Mozilla
Category: Standards Track January 2021
ISSN: 2070-1721
Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)
セッション記述プロトコル（SDP）を使用したTLSの使用に対する不明なキーシェア攻撃
Abstract
概要
This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.
このドキュメントでは、セキュアリアルタイムトランスポートプロトコル（DTLS-SRTP）のデータグラムトランスポート層セキュリティの使用に関する不明な鍵共有式攻撃について説明します。Webリアルタイム通信（WEBRTC）およびSIP IDで使用されるIDバインディングを使用したDTLS-SRTPの使用についても同様の攻撃が記載されています。これらの攻撃はマウントするのが難しいですが、彼らは被害者を通信ピアの身元について誤解させます。この文書は、RFC 8122の実装が展開することを奨励される軽減技術を定義しています。
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/rfc8844.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8844で入手できます。
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. Unknown Key-Share Attack
2.1. Limits on Attack Feasibility
2.2. Interactions with Key Continuity
2.3. Third-Party Call Control
3. Unknown Key-Share Attack with Identity Bindings
3.1. Example
3.2. The "external_id_hash" TLS Extension
3.2.1. Calculating "external_id_hash" for WebRTC Identity
3.2.2. Calculating external_id_hash for PASSporT
4. Unknown Key-Share Attack with Fingerprints
4.1. Example
4.2. Unique Session Identity Solution
4.3. The external_session_id TLS Extension
5. Session Concatenation
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
The use of Transport Layer Security (TLS) [TLS13] with the Session Description Protocol (SDP) [SDP] is defined in [FINGERPRINT]. Further use with Datagram Transport Layer Security (DTLS) [DTLS] and the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as DTLS-SRTP [DTLS-SRTP].
セッション記述プロトコル（SDP）[SDP]を使用したトランスポートレイヤセキュリティ（TLS13]の使用は[指紋]で定義されています。データグラムトランスポートレイヤセキュリティ（DTLS）[DTLS]とセキュアリアルタイムトランスポートプロトコル（SRTP）[SRTP]を使用して使用すると、DTLS-SRTP [DTLS-SRTP]として定義されています。
In these specifications, key agreement is performed using TLS or DTLS, with authentication being tied back to the session description (or SDP) through the use of certificate fingerprints. Communication peers check that a hash, or fingerprint, provided in the SDP matches the certificate that is used in the TLS or DTLS handshake.
これらの仕様では、証明書の指紋を使用して認証がセッション記述（またはSDP）に接続されているTLSまたはDTLを使用して主な合意が実行されます。通信ピアSDPに提供されているハッシュ、またはフィンガープリントが、TLSまたはDTLSハンドシェイクで使用されている証明書と一致することを確認します。
WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity [SIP-ID] both provide a mechanism that binds an external identity to the certificate fingerprints from a session description. However, this binding is not integrity protected and is therefore vulnerable to an identity misbinding attack, also known as an unknown key-share (UKS) attack, where the attacker binds their identity to the fingerprint of another entity. A successful attack leads to the creation of sessions where peers are confused about the identity of the participants.
WebRTC ID（[WEBRTC-SEC]のセクション7を参照）およびSIP ID [SIP-ID]は、両方ともセッション記述からの証明書フィンガプリントに外部識別情報をバインドするメカニズムを提供します。しかしながら、この結合は完全性保護されておらず、したがって、攻撃者が他のエンティティの指紋にそれらのアイデンティティをバインドする未知のキーシェア（UKS）攻撃としても知られているアイデンティティ誤解攻撃に対して脆弱である。攻撃が成功すると、仲間が参加者の身元について混同されているセッションの創設につながります。
This document describes a TLS extension that can be used in combination with these identity bindings to prevent this attack.
この文書では、この攻撃を防ぐためにこれらのIDバインディングと組み合わせて使用できるTLS拡張機能について説明します。
A similar attack is possible with the use of certificate fingerprints alone. Though attacks in this setting are likely infeasible in existing deployments due to the narrow preconditions (see Section 2.1), this document also describes mitigations for this attack.
証明書の指紋を単独で使用することで、同様の攻撃が可能です。この設定での攻撃は、狭い前提条件のために既存の展開において実行不可能です（セクション2.1を参照）、この文書はこの攻撃の軽減についても説明しています。
The mechanisms defined in this document are intended to strengthen the protocol by preventing the use of unknown key-share attacks in combination with other protocol or implementation vulnerabilities. RFC 8122 [FINGERPRINT] is updated by this document to recommend the use of these mechanisms.
この文書で定義されているメカニズムは、他のプロトコルまたは実装の脆弱性と組み合わせて、未知の鍵共有攻撃の使用を防ぐことによってプロトコルを強化することを目的としています。RFC 8122 [指紋]はこの文書によって更新され、これらのメカニズムの使用を推奨します。
This document assumes that signaling is integrity protected. However, as Section 7 of [FINGERPRINT] explains, many deployments that use SDP do not guarantee integrity of session signaling and so are vulnerable to other attacks. [FINGERPRINT] offers key continuity mechanisms as a potential means of reducing exposure to attack in the absence of integrity protection. Section 2.2 provides some analysis of the effect of key continuity in relation to the described attacks.
この文書は、シグナリングが保護されていると仮定していると想定しています。ただし、[指紋]のセクション7は説明していますが、SDPを使用する多くの展開はセッションシグナリングの整合性を保証しないため、他の攻撃に対して脆弱です。[指紋]完全性保護がない場合の攻撃への曝露を減らす潜在的な継続メカニズムを提供しています。節2.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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
In an unknown key-share attack [UKS], a malicious participant in a protocol claims to control a key that is in reality controlled by some other actor. This arises when the identity associated with a key is not properly bound to the key.
未知のキーシェア攻撃[UKS]では、プロトコルの悪意のある参加者は、他の俳優によって制御されている実際にあるキーを制御することを主張しています。これは、キーに関連付けられているアイデンティティがキーに正しくバインドされていない場合に発生します。
An endpoint that can acquire the certificate fingerprint of another entity can advertise that fingerprint as their own in SDP. An attacker can use a copy of that fingerprint to cause a victim to communicate with another unaware victim, even though the first victim believes that it is communicating with the attacker.
他のエンティティの証明書の指紋を取得できるエンドポイントは、その指紋がSDPで自分自身として宣伝することができます。攻撃者はその指紋のコピーを使用して、最初の犠牲者が攻撃者と通信していると信じていても、被害者に他の知識の被害者とコミュニケーションをとることができます。
When the identity of communicating peers is established by higher-layer signaling constructs, such as those in SIP identity [SIP-ID] or WebRTC [WEBRTC-SEC], this allows an attacker to bind their own identity to a session with any other entity.
SIPアイデンティティ[SIP-ID]またはWEBRTC [WEBRTC-SEC]などの上位層のシグナリング構成によって通信ピアのIDが確立されると、これにより、攻撃者が自分のアイデンティティを他のどのエンティティとのセッションにバインドすることができます。。
The attacker obtains an identity assertion for an identity it controls, but binds that to the fingerprint of one peer. The attacker is then able to cause a TLS connection to be established where two victim endpoints communicate. The victim that has its fingerprint copied by the attack correctly believes that it is communicating with the other victim; however, the other victim incorrectly believes that it is communicating with the attacker.
攻撃者は、それがコントロールする識別情報のIDアサーションを取得しますが、それを1つのピアの指紋にバインドします。攻撃者は、2人の犠牲者エンドポイントが通信する場所にTLS接続を確立させることができます。攻撃によって指紋がコピーされた犠牲者は、それが他の犠牲者と通信していると正しく信じています。しかし、他の被害者は誤って攻撃者と通信していると信じています。
An unknown key-share attack does not result in the attacker having access to any confidential information exchanged between victims. However, the failure in mutual authentication can enable other attacks. A victim might send information to the wrong entity as a result. Where information is interpreted in context, misrepresenting that context could lead to the information being misinterpreted.
未知の鍵共有攻撃では、攻撃者が犠牲者間で交換された機密情報にアクセスすることはありません。ただし、相互認証の失敗は他の攻撃を可能にします。その結果、被害者が間違ったエンティティに情報を送信することがあります。情報が文脈で解釈される場合、そのコンテキストが情報が解釈されていることにつながる可能性があることを誤って表示されます。
A similar attack can be mounted based solely on the SDP "fingerprint" attribute [FINGERPRINT] without compromising the integrity of the signaling channel.
シグナリングチャネルの完全性を犠牲にすることなく、SDPの「フィンガープリント」属性[指紋]のみに同様の攻撃を施すことができます。
This attack is an aspect of SDP-based protocols upon which the technique known as third-party call control (3PCC) [RFC3725] relies. 3PCC exploits the potential for the identity of a signaling peer to be different than the media peer, allowing the media peer to be selected by the signaling peer. Section 2.3 describes the consequences of the mitigations described here for systems that use 3PCC.
この攻撃はSDPベースのプロトコルの側面であり、サードパーティの呼制御（3PCC）[RFC3725]として知られている技術が依存しています。3PCCは、シグナリングピアのIDがメディアピアとは異なる可能性を悪用し、メディアピアがシグナリングピアによって選択されます。セクション2.3は、3PCCを使用するシステムのためにここで説明されている緩和の結果を説明しています。
The use of TLS with SDP depends on the integrity of session signaling. Assuming signaling integrity limits the capabilities of an attacker in several ways. In particular:
SDPを使用したTLSの使用は、セッションシグナリングの完全性に依存します。シグナリングの整合性がいくつかの方法で攻撃者の機能を制限すると仮定します。特に：
1. An attacker can only modify the parts of the session signaling that they are responsible for producing, namely their own offers and answers.
1. 攻撃者は、それらが生産する責任があるセッションシグナリングの部分、すなわち彼ら自身のオファーや回答を修正することができます。
2. No entity will successfully establish a session with a peer unless they are willing to participate in a session with that peer.
2. そのピアとのセッションに参加しても構わない限り、エンティティはピアとセッションを確立しません。
The combination of these two constraints make the spectrum of possible attacks quite limited. An attacker is only able to switch its own certificate fingerprint for a valid certificate that is acceptable to its peer. Attacks therefore rely on joining two separate sessions into a single session. Section 4 describes an attack on SDP signaling under these constraints.
これら2つの制約の組み合わせは、可能な攻撃のスペクトルをかなり限られています。攻撃者は、そのピアに受け入れられる有効な証明書に独自の証明書フィンガープリントを切り替えることができるだけです。したがって、攻撃は2つの別々のセッションを1つのセッションに参加することに依存しています。セクション4は、これらの制約下でのSDPシグナリングに関する攻撃を説明しています。
Systems that rely on strong identity bindings, such as those defined in [WEBRTC] or [SIP-ID], have a different threat model, which admits the possibility of attack by an entity with access to the signaling channel. Attacks under these conditions are more feasible as an attacker is assumed to be able both to observe and to modify signaling messages. Section 3 describes an attack that assumes this threat model.
[WEBRTC]または[SIP-ID]で定義されているものなど、強力なアイデンティティバインディングに依存するシステムには、シグナリングチャネルへのアクセスを持つエンティティによる攻撃の可能性が認められます。これらの条件下での攻撃は、攻撃者が観察し、シグナリングメッセージを変更することができると仮定されるため、より実現可能です。セクション3では、この脅威モデルを想定している攻撃について説明します。
Systems that use key continuity (as defined in Section 15.1 of [ZRTP] or as recommended in Section 7 of [FINGERPRINT]) might be able to detect an unknown key-share attack if a session with either the attacker or the genuine peer (i.e., the victim whose fingerprint was copied by an attacker) was established in the past. Whether this is possible depends on how key continuity is implemented.
キー継続性を使用するシステム（[ZRTPのセクション15.1で定義されている）または[指紋]のセクション7で推奨されるように）攻撃者または本物のピアのいずれかのセッションがある場合は、未知のキーシェア攻撃を検出できる可能性があります（つまり、、指紋が攻撃者によってコピーされた犠牲者は過去に確立されました。これが可能かどうかは、キーの継続性がどのように実装されているかによって異なります。
Implementations that maintain a single database of identities with an index of peer keys could discover that the identity saved for the peer key does not match the claimed identity. Such an implementation could notice the disparity between the actual keys (those copied from a victim) and the expected keys (those of the attacker).
ピアキーのインデックスを持つIDの単一のデータベースを維持する実装は、ピアキーに保存されているIDがクレームされたIDと一致しないことを発見する可能性があります。そのような実装は、実際のキー（被害者からコピーされたもの）と予想されるキー（攻撃者のもの）の間の格差に気づく可能性がある。
In comparison, implementations that first match based on peer identity could treat an unknown key-share attack as though their peer had used a newly configured device. The apparent addition of a new device could generate user-visible notices (e.g., "Mallory appears to have a new device"). However, such an event is not always considered alarming; some implementations might silently save a new key.
比較して、ピア識別情報に基づいて最初に一致する実装は、それらのピアが新しく構成されたデバイスを使用したかのように、未知のキーシェア攻撃を扱う可能性がある。新しいデバイスの明らかな追加は、ユーザーが目に見える通知を生成することができます（例えば、「マロリーは新しいデバイスを持つように思われる」）。しかし、そのようなイベントは必ずしも驚くべきものと見なされません。一部の実装は、新しいキーを静かに保存する可能性があります。
Third-party call control (3PCC) [RFC3725] is a technique where a signaling peer establishes a call that is terminated by a different entity. An unknown key-share attack is very similar in effect to some 3PCC practices, so use of 3PCC could appear to be an attack. However, 3PCC that follows RFC 3725 guidance is unaffected, and peers that are aware of changes made by a 3PCC controller can correctly distinguish actions of a 3PCC controller from an attack.
サードパーティ通話制御（3PCC）[RFC3725]は、シグナリングピアが異なるエンティティで終了したコールを確立する技術です。未知のキーシェア攻撃は、いくつかの3PCC慣行に有効で非常に似ているため、3PCCの使用は攻撃であるように見える可能性があります。ただし、RFC 3725ガイダンスに続く3PCCは影響を受けず、3PCCコントローラによって行われた変更を認識しているピアは、3PCCコントローラのアクションを攻撃から正しく区別できます。
3PCC as described in RFC 3725 is incompatible with SIP identity [SIP-ID], as SIP Identity relies on creating a binding between SIP requests and SDP. The controller is the only entity that generates SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use of the "fingerprint" attribute without additional bindings or WebRTC identity [WEBRTC-SEC] is possible.
3PCC RFC 3725に記載されているように、SIP IDがSIP要求とSDP間のバインディングの作成に依存しているため、SIP ID [SIP-ID]と互換性がありません。コントローラは、RFC 3725でSIP要求を生成する唯一のエンティティです。したがって、3PCCコンテキストでは、追加のバインディングまたはWEBRTC ID [WEBRTC-SEC]のない「指紋」属性の使用のみが可能です。
The attack mitigation mechanisms described in this document will prevent the use of 3PCC if peers have different views of the involved identities or the value of SDP "tls-id" attributes.
この文書に記載されている攻撃軽減メカニズムは、ピアが関与しているIDまたはSDP "TLS-ID"属性の値の異なるビューを持つ場合、3PCCの使用を妨げます。
For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of the signaling so that they can correctly generate and check the TLS extensions. For a connection to be successfully established, a 3PCC controller needs either to forward SDP without modification or to avoid modifications to "fingerprint", "tls-id", and "identity" attributes. A controller that follows the best practices in RFC 3725 is expected to forward SDP without modification, thus ensuring the integrity of these attributes.
3PCCが提案されたメカニズムを扱うために、TLSピアはシグナリングを認識する必要があるため、TLS拡張機能を正しく生成して確認できます。接続に成功するためには、3PCCコントローラは変更なしでSDPを転送するか、「指紋」、「TLS-ID」、および「ID」属性の変更を回避する必要があります。RFC 3725のベストプラクティスに続くコントローラは、変更なしでSDPを転送すると予想され、したがってこれらの属性の整合性が確実になります。
The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) and the Personal Assertion Token (PASSporT) used in SIP identity ([SIP-ID], [PASSPORT]) are bound to the certificate fingerprint of an endpoint. An attacker can cause an identity binding to be created that binds an identity they control to the fingerprint of a first victim.
SIP ID（[SIP-ID]、[パスポート]）で使用されるWebRTC（[WEBRTC-SEC]のセクション7）に使用されるIDアサーション（[SIP-ID]、[パスポート]）は、エンドポイントの証明書フィンガープリントにバインドされています。攻撃者は、それらが最初の犠牲者の指紋に制御する身元をバインドするIDバインディングを作成する可能性があります。
An attacker can thereby cause a second victim to believe that they are communicating with an attacker-controlled identity, when they are really talking to the first victim. The attacker does this by creating an identity assertion that covers a certificate fingerprint of the first victim.
それによって、攻撃者は、彼らが本当に最初の犠牲者と話しているとき、彼らが攻撃的に管理されたアイデンティティと通信していると信じることができます。攻撃者は、最初の犠牲者の証明書の指紋をカバーするIDアサーションを作成することによってこれを行います。
A variation on the same technique can be used to cause both victims to believe they are talking to the attacker when they are talking to each other. In this case, the attacker performs the identity misbinding once for each victim.
同じ手法の変動を使用して、両者の被害者が互いに話しているときに攻撃者と話していると信じるようになります。この場合、攻撃者は被害者ごとに1回の誤解を誤解します。
The authority certifying the identity binding is not required to verify that the entity requesting the binding actually controls the keys associated with the fingerprints, and this might appear to be the cause of the problem. SIP and WebRTC identity providers are not required to perform this validation.
IDバインディングを認証する権限は、バインディングを要求するエンティティが実際に指紋に関連付けられているキーを制御することを確認するために必要ではなく、これは問題の原因であるように見えます。SIPおよびWebRTC IDプロバイダはこの検証を実行する必要はありません。
A simple solution to this problem is suggested by [SIGMA]. The identity of endpoints is included under a message authentication code (MAC) during the cryptographic handshake. Endpoints then validate that their peer has provided an identity that matches their expectations. In TLS, the Finished message provides a MAC over the entire handshake, so that including the identity in a TLS extension is sufficient to implement this solution.
この問題に対する簡単な解決策はσによって示唆されています。エンドポイントの識別情報は、暗号化ハンドシェイク中にメッセージ認証コード（MAC）の下に含まれています。その後、エンドポイントは、それらのピアが自分の期待に一致するアイデンティティを提供したことを検証します。TLSでは、完成したメッセージはハンドシェイク全体を介してMACを提供するので、TLS拡張子内の識別情報を含むことで、このソリューションを実装するのに十分です。
Rather than include a complete identity binding, which could be sizable, a collision- and preimage-resistant hash of the binding is included in a TLS extension as described in Section 3.2. Endpoints then need only validate that the extension contains a hash of the identity binding they received in signaling. If the identity binding is successfully validated, the identity of a peer is verified and bound to the session.
かなりのアイデンティティバインディングを含むのではなく、結合の衝突抵抗のハッシュおよびプリメージング耐性ハッシュは、セクション3.2に記載されているようにTLS拡張に含まれる。エンドポイントは、拡張子にシグナリングで受信されたIDバインディングのハッシュが含まれていることを検証するだけです。IDバインディングが正常に検証された場合、ピアのIDが検証され、セッションにバインドされます。
This form of unknown key-share attack is possible without compromising signaling integrity, unless the defenses described in Section 4 are used. In order to prevent both forms of attack, endpoints MUST use the "external_session_id" extension (see Section 4.3) in addition to the "external_id_hash" (Section 3.2) so that two calls between the same parties can't be altered by an attacker.
セクション4で説明されている防御が使用されない限り、この形式の未知の鍵式攻撃は、シグナリングの整合性を犠牲にすることなく可能です。両方の攻撃を防ぐために、エンドポイントは、「external_id_hash」（セクション3.2）に加えて、「external_id_hash」（セクション3.2）を使用する必要があります（セクション3.2）。
In the example shown in Figure 1, it is assumed that the attacker also controls the signaling channel.
図1に示す例では、攻撃者がシグナリングチャネルも制御すると仮定されます。
Mallory (the attacker) presents two victims, Norma and Patsy, with two separate sessions. In the first session, Norma is presented with the option to communicate with Mallory; a second session with Norma is presented to Patsy.
Mallory（攻撃者）は、2つの犠牲者、ノルマ、ティッシュ、2つの別々のセッションを備えています。最初のセッションでは、NormaはMalloryと通信するオプションが表示されます。ノルマを持つ2回目のセッションがPATSYに提示されています。
Norma Mallory Patsy
(fp=N) ----- (fp=P)
| | |
|<---- Signaling1 ------>| |
| Norma=N Mallory=P | |
| |<---- Signaling2 ------>|
| | Norma=N Patsy=P |
| |
|<=================DTLS (fp=N,P)=================>|
| |
(peer = Mallory!) (peer = Norma)
Figure 1: Example Attack on Identity Bindings
図1：IDバインディングに対する攻撃の例
The attack requires that Mallory obtain an identity binding for her own identity with the fingerprints presented by Patsy (P), which Mallory might have obtained previously. This false binding is then presented to Norma ('Signaling1' in Figure 1).
この攻撃には、マロリーがPATSY（P）によって提示された指紋とともに自分のアイデンティティに対するアイデンティティバインディングを取得する必要があります。この偽の結合は次にノルマに提示されます（図1の「シグナル伝達1」）。
Patsy could be similarly duped, but in this example, a correct binding between Norma's identity and fingerprint (N) is faithfully presented by Mallory. This session ('Signaling2' in Figure 1) can be entirely legitimate.
PATSYも同様に騙される可能性がありますが、この例では、ノルマのアイデンティティとフィンガープリント（N）との間の正しいバインディングは忠実にマロリーによって提示されます。このセッション（図1の「シグナリング2」）は完全に正当なものです。
A DTLS session is established directly between Norma and Patsy. In order for this to happen, Mallory can substitute transport-level information in both sessions, though this is not necessary if Mallory is on the network path between Norma and Patsy.
DTLSセッションは、ノルカとPATSYの間に直接確立されます。これが起こるために、Malloryは両方のセッションでトランスポートレベルの情報を置き換えることができますが、MalloryはNormaとPATSY間のネットワークパスにある場合はこれは必要ありません。
As a result, Patsy correctly believes that she is communicating with Norma. However, Norma incorrectly believes that she is talking to Mallory. As stated in Section 2, Mallory cannot access media, but Norma might send information to Patsy that Norma might not intend or that Patsy might misinterpret.
その結果、Patsyは正しくノルカと通信していると正しく信じています。しかし、ノルマが誤って彼女がマロリーと話していると信じています。セクション2に記載されているように、Malloryはメディアにアクセスできないが、ノルマはNORMAが意図しないこと、またはPATSYが誤解されない可能性があるという情報をPATSYに送信することがあります。
The "external_id_hash" TLS extension carries a hash of the identity assertion that the endpoint sending the extension has asserted to its peer. Both peers include a hash of their own identity assertion.
「external_id_hash」TLS拡張子は、拡張子を送信するエンドポイントがそのピアにアサートされたことが識別アサーションのハッシュを担います。両方のピアには、独自のアイデンティティアサーションのハッシュが含まれています。
The "extension_data" for the "external_id_hash" extension contains a "ExternalIdentityHash" struct, described below using the syntax defined in Section 3 of [TLS13]:
"external_id_hash"拡張子の "extension_data"には、[TLS13]のセクション3で定義されている構文を使用して、以下の「ExternalIdentyHash」構造体が含まれています。
struct {
opaque binding_hash<0..32>;
} ExternalIdentityHash;
Where an identity assertion has been asserted by a peer, this extension includes a SHA-256 hash of the assertion. An empty value is used to indicate support for the extension.
アイデンティティアサーションがピアによってアサートされた場合、この拡張はアサーションのSHA-256ハッシュを含む。空の値は、拡張子のサポートを示すために使用されます。
Note: For both types of identity assertion, if SHA-256 should prove to be inadequate in the future (see [AGILITY]), a new TLS extension that uses a different hash function can be defined.
注：SHA-256が将来不適切であることを証明する場合（[agility]を参照）、異なるハッシュ関数を使用する新しいTLS拡張機能を定義することができます。
Identity bindings might be provided by only one peer. An endpoint that does not produce an identity binding MUST generate an empty "external_id_hash" extension in its ClientHello or -- if a client provides the extension -- in ServerHello or EncryptedExtensions. An empty extension has a zero-length "binding_hash" field.
アイデンティティバインディングは1つのピアだけによって提供される可能性があります。IDバインディングを生成しないエンドポイントは、そのClientHelloに空の "external_id_hash"拡張子を生成する必要があります。空の拡張子には、長さゼロの "binding_hash"フィールドがあります。
A peer that receives an "external_id_hash" extension that does not match the value of the identity binding from its peer MUST immediately fail the TLS handshake with an "illegal_parameter" alert. The absence of an identity binding does not relax this requirement; if a peer provided no identity binding, a zero-length extension MUST be present to be considered valid.
そのピアからのIDバインディングの値と一致しない「external_id_hash」拡張子を受信するピアは、すぐに "ILLEGAL_PARAMETER"アラートでTLSハンドシェイクを失敗させる必要があります。アイデンティティ結合がないことはこの要件を緩和することはありません。ピアにIDバインディングが含まれていない場合は、ゼロの長さの拡張が有効であると見なす必要があります。
Implementations written prior to the definition of the extensions in this document will not support this extension for some time. A peer that receives an identity binding but does not receive an "external_id_hash" extension MAY accept a TLS connection rather than fail a connection where the extension is absent.
この文書内の拡張機能の定義の前に書かれた実装は、しばらくの間この拡張をサポートしません。IDバインディングを受信するが「external_id_hash」拡張子を受信しないピアは、拡張機能が存在しない接続ではなく、TLS接続を受け入れることがあります。
The endpoint performs the validation of the "external_id_hash" extension in addition to the validation required by [FINGERPRINT] and any verification of the identity assertion [WEBRTC-SEC] [SIP-ID]. An endpoint MUST validate any external_session_id value that is present; see Section 4.3.
エンドポイントは、[指紋]で必要な検証とIDアサーション[WEBRTC-SEC] [SIP-ID]の検証に加えて、「external_id_hash」拡張子の検証を実行します。エンドポイントは、存在するexternal_session_id値を検証する必要があります。セクション4.3を参照してください。
An "external_id_hash" extension with a "binding_hash" field that is any length other than 0 or 32 is invalid and MUST cause the receiving endpoint to generate a fatal "decode_error" alert.
0または32以外の長さの「binding_hash」フィールドを持つ "external_id_hash"拡張子は無効であり、受信側の "decode_error"アラートを生成する必要があります。
In TLS 1.3, an "external_id_hash" extension sent by a server MUST be sent in the EncryptedExtensions message.
TLS 1.3では、サーバーによって送信された「external_id_hash」拡張子は、暗号化されたEncriptEdentsメッセージで送信する必要があります。
A WebRTC identity assertion (Section 7 of [WEBRTC-SEC]) is provided as a JSON [JSON] object that is encoded into a JSON text. The JSON text is encoded using UTF-8 [UTF8] as described by Section 8.1 of [JSON]. The content of the "external_id_hash" extension is produced by hashing the resulting octets with SHA-256 [SHA]. This produces the 32 octets of the "binding_hash" parameter, which is the sole contents of the extension.
JSONテキストにエンコードされているJSON [JSON]オブジェクトとして、WebRTC IDアサーション（[WEBRTC-SEC]）が提供されています。JSONテキストは、[JSON]のセクション8.1で説明されているようにUTF-8 [UTF8]を使用してエンコードされています。結果のオクテットをSHA-256 [SHA]でハッシュすることによって、「external_id_hash」拡張子の内容が生成されます。これにより、拡張子の唯一の内容である「binding_hash」パラメータの32オクテットが生成されます。
The SDP "identity" attribute includes the base64 [BASE64] encoding of the UTF-8 encoding of the same JSON text. The "external_id_hash" extension is validated by performing base64 decoding on the value of the SDP "identity" attribute, hashing the resulting octets using SHA-256, and comparing the results with the content of the extension. In pseudocode form, using the "identity-assertion-value" field from the SDP "identity" attribute grammar as defined in [WEBRTC-SEC]:
SDP "ID"属性には、同じJSONテキストのUTF-8エンコードのencodingのencodingが含まれています。"external_id_hash"拡張子は、SDP "ID"属性の値に対してbase64デコードを実行し、結果のオクテットをSHA-256を使用してハッシュし、その結果を拡張子の内容と比較することによって検証されます。[WEBRTC-SEC]で定義されているSDP "ID"属性文法の "IDITITY-ASSERTION-VALUE"フィールドを使用して、疑似コード形式で。
external_id_hash = SHA-256(b64decode(identity-assertion-value))
Note: The base64 of the SDP "identity" attribute is decoded to avoid capturing variations in padding. The base64-decoded identity assertion could include leading or trailing whitespace octets. WebRTC identity assertions are not canonicalized; all octets are hashed.
注：SDPの「ID」属性のBase64は、パディングのバリエーションのキャプチャを回避するためにデコードされます。Base64復号化されたIDアサーションには、先行または末尾の空白のオクテットが含まれます。WebRTC IDアサーションは正規化されていません。すべてのオクテットがハッシュされています。
Where the compact form of PASSporT [PASSPORT] is used, it MUST be expanded into the full form. The base64 encoding used in the SIP Identity (or 'y') header field MUST be decoded then used as input to SHA-256. This produces the 32-octet "binding_hash" value used for creating or validating the extension. In pseudocode, using the "signed-identity-digest" parameter from the "Identity" header field grammar defined [SIP-ID]:
Passport [Passport]のコンパクトな形式が使用されている場合は、フルフォームに拡張する必要があります。SIP ID（または「Y '）ヘッダフィールドで使用されているBase64エンコーディングは、SHA-256への入力として使用する必要があります。これにより、拡張子の作成または検証に使用される32オクテットの「binding_hash」値が生成されます。疑似コードでは、「ID」ヘッダフィールド文法定義「SIP-ID」から「符号付きID - Digest」パラメータを使用して。
external_id_hash = SHA-256(b64decode(signed-identity-digest))
An attack on DTLS-SRTP is possible because the identity of peers involved is not established prior to establishing the call. Endpoints use certificate fingerprints as a proxy for authentication, but as long as fingerprints are used in multiple calls, they are vulnerable to attack.
コールを確立する前に、関連するピアの識別情報が確立されないため、DTLS-SRTPへの攻撃が可能です。エンドポイント認証用のプロキシとして証明書の指紋を使用しますが、指紋が複数の呼び出しで使用されている限り、それらは攻撃に対して脆弱です。
Even if the integrity of session signaling can be relied upon, an attacker might still be able to create a session where there is confusion about the communicating endpoints by substituting the fingerprint of a communicating endpoint.
セッションシグナリングの完全性が依存しても、攻撃者は依然として通信エンドポイントの指紋を置き換えることによって通信エンドポイントに関する混乱があるセッションを作成することができるかもしれない。
An endpoint that is configured to reuse a certificate can be attacked if it is willing to initiate two calls at the same time, one of which is with an attacker. The attacker can arrange for the victim to incorrectly believe that it is calling the attacker when it is in fact calling a second party. The second party correctly believes that it is talking to the victim.
証明書を再利用するように構成されているエンドポイントは、同時に2つの呼び出しを開始しても攻撃者が攻撃者である場合に攻撃することができます。攻撃者は、それが実際に第二のパーティーを呼び出すときにそれが攻撃者を呼んでいると誤って信じることを犠牲にすることができます。第二の当事者はそれが被害者と話していると正しく信じています。
As with the attack on identity bindings, this can be used to cause two victims to both believe they are talking to the attacker when they are talking to each other.
アイデンティティバインディングへの攻撃と同様に、これを使用して、2人の犠牲者が互いに話しているときに攻撃者と話していると信じることができます。
To mount this attack, two sessions need to be created with the same endpoint at almost precisely the same time. One of those sessions is initiated with the attacker, the second session is created toward another honest endpoint. The attacker convinces the first endpoint that their session with the attacker has been successfully established, but media is exchanged with the other honest endpoint. The attacker permits the session with the other honest endpoint to complete only to the extent necessary to convince the other honest endpoint to participate in the attacked session.
この攻撃をマウントするには、2つのセッションを同じエンドポイントでほぼ同じ時点で作成する必要があります。これらのセッションの1つが攻撃者で開始され、2番目のセッションは別の正直なエンドポイントに向けて作成されます。攻撃者は、攻撃者とのセッションが正常に確立されたことを最初のエンドポイントを確立していますが、メディアは他の正直なエンドポイントと交換されます。攻撃者は、他の正直なエンドポイントを攻撃されたセッションに参加するために他の正直なエンドポイントを納得させるために必要な範囲でのみ完了するためのセッションを許可します。
In addition to the constraints described in Section 2.1, the attacker in this example also needs the ability to view and drop packets between victims. That is, the attacker needs to be on path for media.
セクション2.1で説明されている制約に加えて、この例の攻撃者は犠牲者間でパケットを表示および削除する機能も必要です。つまり、攻撃者はメディアのパスにある必要があります。
The attack shown in Figure 2 depends on a somewhat implausible set of conditions. It is intended to demonstrate what sort of attack is possible and what conditions are necessary to exploit this weakness in the protocol.
図2に示す攻撃は、幾分致命的な条件のセットに依存します。それはどのような攻撃が可能であるか、そしてプロトコル内のこの弱さを悪用するためにどのような条件が必要であるかを実証することを意図しています。
Norma Mallory Patsy
(fp=N) ----- (fp=P)
| | |
+---Signaling1 (fp=N)--->| |
+-----Signaling2 (fp=N)------------------------>|
|<-------------------------Signaling2 (fp=P)----+
|<---Signaling1 (fp=P)---+ |
| | |
|=======DTLS1=======>(Forward)======DTLS1======>|
|<======DTLS2========(Forward)<=====DTLS2=======|
|=======Media1======>(Forward)======Media1=====>|
|<======Media2=======(Forward)<=====Media2======|
| | |
|=======DTLS2========>(Drop) |
| | |
Figure 2: Example Attack Scenario Using Fingerprints
図2：指紋を使用した攻撃シナリオの例
In this scenario, there are two sessions initiated at the same time by Norma. Signaling is shown with single lines ('-'), DTLS and media with double lines ('=').
このシナリオでは、ノルマによって同時に開始された2つのセッションがあります。シグナリングは、1本の線（ ' - '）、DTL、および二重線（ '='）で示されています。
The first session is established with Mallory, who falsely uses Patsy's certificate fingerprint (denoted with 'fp=P'). A second session is initiated between Norma and Patsy. Signaling for both sessions is permitted to complete.
最初のセッションはMalloryを使って確立され、誰がPatsyの証明書フィンガープリントを誤って使用します（ 'fp = P'で表されます）。第2のセッションは、NormaとPATSYの間で開始されます。両方のセッションのシグナリングは完了できます。
Once signaling is complete on the first session, a DTLS connection is established. Ostensibly, this connection is between Mallory and Norma, but Mallory forwards DTLS and media packets sent to her by Norma to Patsy. These packets are denoted 'DTLS1' because Norma associates these with the first signaling session ('Signaling1').
シグナリングが最初のセッションで完了したら、DTLS接続が確立されます。表面的に、この接続はMalloryとNormaの間にありますが、MalloryはDTLSとメディアパケットを正常にPATSYに転送します。これらのパケットは「DTLS1」と呼ばれます。なぜなら、Normaはこれらを最初のシグナリングセッション（ 'Signaling1'）と関連付けます。
Mallory also intercepts packets from Patsy and forwards those to Norma at the transport address that Norma associates with Mallory. These packets are denoted 'DTLS2' to indicate that Patsy associates these with the second signaling session ('Signaling2'); however, Norma will interpret these as being associated with the first signaling session ('Signaling1').
Malloryはまた、PATSYからのパケットを傍受し、それらを正常にマロリと関連付けるトランスポートアドレスで正常に転送します。これらのパケットは、PATSYがこれらを第2のシグナリングセッションと関連付けることを示すために「DTLS2」と表される（「シグナル伝達2」）。ただし、NORMAはこれらを最初のシグナリングセッション（ 'Signaling1'）に関連付けられていると解釈されます。
The second signaling exchange ('Signaling2'), which is between Norma and Patsy, is permitted to continue to the point where Patsy believes that it has succeeded. This ensures that Patsy believes that she is communicating with Norma. In the end, Norma believes that she is communicating with Mallory, when she is really communicating with Patsy. Just like the example in Section 3.1, Mallory cannot access media, but Norma might send information to Patsy that Norma might not intend or that Patsy might misinterpret.
ノルマとパターの間にある第2のシグナリング交換（「シグナル伝達2」）は、それが成功したと信じているという点に続くことが許されています。これにより、PATSYは彼女がノルマと通信していると信じています。最後に、ノルカは、彼女が本当にパラリーと交流しているとき、彼女がマロリーと通信していると信じています。セクション3.1の例と同じように、Malloryはメディアにアクセスできないですが、NormaはNormaが意図しないこと、またはPATSYが誤解されている可能性があるという情報をPATSYに送信することがあります。
Though Patsy needs to believe that the second signaling session has been successfully established, Mallory has no real interest in seeing that session also be established. Mallory only needs to ensure that Patsy maintains the active session and does not abandon the session prematurely. For this reason, it might be necessary to permit the signaling from Patsy to reach Norma in order to allow Patsy to receive a call setup completion signal, such as a SIP ACK. Once the second session is established, Mallory might cause DTLS packets sent by Norma to Patsy to be dropped. However, if Mallory allows DTLS packets to pass, it is likely that Patsy will discard them as Patsy will already have a successful DTLS connection established.
PATSYは、第2のシグナリングセッションが正常に確立されたと信じる必要があるが、Malloryはそのセッションも確立されることに本当の関心を秘めていない。Malloryは、PATSYがアクティブセッションを維持し、事前にセッションを放棄しないようにする必要があるだけです。このため、PATSYがSIP ACKのような呼設定完了信号を受信できるようにするために、PATSYからのシグナリングを正常に到達させることを許可する必要があるかもしれない。2番目のセッションが確立されると、MalloryはノルカによってDTLSパケットをドロップされるように送信される可能性があります。ただし、MalloryがDTLSパケットを通過できるようにすると、PATSYがすでに成功したDTLS接続が確立されているため、PATSYがそれらを破棄する可能性があります。
For the attacked session to be sustained beyond the point that Norma detects errors in the second session, Mallory also needs to block any signaling that Norma might send to Patsy asking for the call to be abandoned. Otherwise, Patsy might receive a notice that the call has failed and thereby abort the call.
ノルマが2番目のセッションでエラーを検出するという点を超えて攻撃されたセッションが維持されるために、Malloryはまた、ノルマが放棄されるべき呼び出しを尋ねるPATSYに送信される可能性のあるシグナリングをブロックする必要があります。それ以外の場合、PATSYは呼び出しが失敗したことに通知を受け取り、それによって通話を中止するかもしれません。
This attack creates an asymmetry in the beliefs about the identity of peers. However, this attack is only possible if the victim (Norma) is willing to conduct two sessions nearly simultaneously; if the attacker (Mallory) is on the network path between the victims; and if the same certificate -- and therefore the SDP "fingerprint" attribute value -- is used by Norma for both sessions.
この攻撃は、ピアのアイデンティティについての信念に非対称性を生み出します。しかし、この攻撃は、犠牲者（NORMA）がほぼ同時に2つのセッションを行うことを望んでいる場合にのみ可能です。攻撃者（マロリー）が犠牲者間のネットワーク経路上にある場合。そして同じ証明書の場合、したがってSDPの「指紋」属性値 - 両方のセッションのためにNormaによって使用されます。
Where Interactive Connectivity Establishment (ICE) [ICE] is used, Mallory also needs to ensure that connectivity checks between Patsy and Norma succeed, either by forwarding checks or by answering and generating the necessary messages.
Interactive Connectivity Setaction（ICE）が使用されている場合、Malloryは、チェックを送り、または必要なメッセージを回答して生成することによって、PATSYとNORMAの間の接続チェックを確実にする必要があります。
The solution to this problem is to assign a new identifier to communicating peers. Each endpoint assigns their peer a unique identifier during call signaling. The peer echoes that identifier in the TLS handshake, binding that identity into the session. Including this new identity in the TLS handshake means that it will be covered by the TLS Finished message, which is necessary to authenticate it (see [SIGMA]).
この問題に対する解決策は、Communicating Peersに新しい識別子を割り当てることです。各エンドポイントは、通話シグナリング中にピアを一意の識別子に割り当てます。ピアはTLSハンドシェイク内の識別子をエコーし、そのIDをセッションにバインドします。TLSハンドシェイクのこの新しい身元を含めることは、それがそれを認証するために必要なTLS完成メッセージによってカバーされることを意味します（[SIGMA]を参照）。
Successfully validating that the identifier matches the expected value means that the connection corresponds to the signaled session and is therefore established between the correct two endpoints.
識別子が予想される値と一致することを正常に検証することは、接続がシグナリングされたセッションに対応し、したがって正しい2つのエンドポイント間で確立されることを意味する。
This solution relies on the unique identifier given to DTLS sessions using the SDP "tls-id" attribute [DTLS-SDP]. This field is already required to be unique. Thus, no two offers or answers from the same client will have the same value.
このソリューションは、SDP "TLS-ID"属性[DTLS-SDP]を使用してDTLSセッションに与えられた一意の識別子に依存しています。このフィールドはすでにユニークである必要があります。したがって、同じクライアントからの2つのオファーや回答は同じ値になりません。
A new "external_session_id" extension is added to the TLS or DTLS handshake for connections that are established as part of the same call or real-time session. This carries the value of the "tls-id" attribute and provides integrity protection for its exchange as part of the TLS or DTLS handshake.
新しい呼び出しまたはリアルタイムセッションの一部として確立された接続のために、新しい "external_session_id"拡張子がTLSまたはDTLSハンドシェイクに追加されます。これにより、 "tls-id"属性の値があり、TLSまたはDTLSハンドシェイクの一部としてそのExchangeの整合性保護を提供します。
The "external_session_id" TLS extension carries the unique identifier that an endpoint selects. When used with SDP, the value MUST include the "tls-id" attribute from the SDP that the endpoint generated when negotiating the session. This document only defines use of this extension for SDP; other methods of external session negotiation can use this extension to include a unique session identifier.
"external_session_id"の拡張子は、エンドポイントが選択する一意の識別子を演算します。SDPと共に使用する場合、値は、セッションをネゴシエートするときに生成されたエンドポイントが生成されたSDPからの "tls-id"属性を含める必要があります。この文書はSDPのこの拡張機能のみを定義しています。外部セッションネゴシエーションの他の方法は、この拡張機能を使用して固有のセッション識別子を含めることができます。
The "extension_data" for the "external_session_id" extension contains an ExternalSessionId struct, described below using the syntax defined in [TLS13]:
"external_session_id"拡張子の "extension_data"には、[TLS13]で定義されている構文を使用して、後述の外部CissionID構造体が含まれています。
struct {
opaque session_id<20..255>;
} ExternalSessionId;
For SDP, the "session_id" field of the extension includes the value of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the "tls-id-value" ABNF production). The value of the "tls-id" attribute is encoded using ASCII [ASCII].
SDPの場合、拡張子の「session_id」フィールドには、[DTLS-SDP]で定義されている「TLS-ID」SDP属性（つまり、「TLS-ID-VALUE」ABNFプロダクション）の値が含まれます。"tls-id"属性の値はASCII [ASCII]を使用してエンコードされています。
Where RTP and RTCP [RTP] are not multiplexed, it is possible that the two separate DTLS connections carrying RTP and RTCP can be switched. This is considered benign since these protocols are designed to be distinguishable as SRTP [SRTP] provides key separation. Using RTP/ RTCP multiplexing [RTCP-MUX] further avoids this problem.
RTPとRTCP [RTP]が多重化されていない場合、RTPとRTCPを搭載した2つのDTLS接続を切り替えることができます。これらのプロトコルはSRTP [SRTP]と区別できるように設計されているため、これは良性と見なされます。RTP / RTCP多重化[RTCP-MUX]を使用するとこの問題が回避されます。
The "external_session_id" extension is included in a ClientHello, and if the extension is present in the ClientHello, either ServerHello (for TLS and DTLS versions older than 1.3) or EncryptedExtensions (for TLS 1.3).
"external_session_id"拡張子はClientHelloに含まれています。
Endpoints MUST check that the "session_id" parameter in the extension that they receive includes the "tls-id" attribute value that they received in their peer's session description. Endpoints can perform string comparison by ASCII decoding the TLS extension value and comparing it to the SDP attribute value or by comparing the encoded TLS extension octets with the encoded SDP attribute value. An endpoint that receives an "external_session_id" extension that is not identical to the value that it expects MUST abort the connection with a fatal "illegal_parameter" alert.
エンドポイントは、受信したエクステンション内の「session_id」パラメータに、ピアのセッションの説明で受信した「TLS-ID」属性値が含まれていることを確認する必要があります。エンドポイントは、TLS拡張値を復号化し、それをSDP属性値と比較するか、エンコードされたTLS拡張オクテットをエンコードされたSDP属性値と比較することによって、文字列比較を実行できます。「extronce_session_id」拡張子を受け取るエンドポイントは、致命的な「ILLEGAL_PARAMETER」アラートとの接続を中止しなければならない値と同じではありません。
The endpoint performs the validation of the "external_id_hash" extension in addition to the validation required by [FINGERPRINT].
エンドポイントは、[指紋]で必要な検証に加えて、拡張子の検証を実行します。
If an endpoint communicates with a peer that does not support this extension, it will receive a ClientHello, ServerHello, or EncryptedExtensions message that does not include this extension. An endpoint MAY choose to continue a session without this extension in order to interoperate with peers that do not implement this specification.
エンドポイントがこの拡張機能をサポートしていないピアと通信すると、この拡張子を含まないClientHello、ServerHello、またはEncryptedExtensionsメッセージが表示されます。この仕様を実装しないピアと相互運用するために、エンドポイントはこの拡張なしでセッションを続けることを選択できます。
In TLS 1.3, an "external_session_id" extension sent by a server MUST be sent in the EncryptedExtensions message.
TLS 1.3では、サーバーによって送信された「external_session_id」拡張子は、暗号化されたEncryptExtensionsメッセージで送信する必要があります。
This defense is not effective if an attacker can rewrite "tls-id" values in signaling. Only the mechanism in "external_id_hash" is able to defend against an attacker that can compromise session integrity.
この防御は、攻撃者がシグナリングで「TLS-ID」の値を書き換えることができれば効果的ではありません。「external_id_hash」のメカニズムだけが、セッションの整合性を危険にさらすことができる攻撃者に対して守ることができます。
Use of session identifiers does not prevent an attacker from establishing two concurrent sessions with different peers and forwarding signaling from those peers to each other. Concatenating two signaling sessions in this way creates two signaling sessions, with two session identifiers, but only the TLS connections from a single session are established as a result. In doing so, the attacker creates a situation where both peers believe that they are talking to the attacker when they are talking to each other.
セッション識別子の使用は、攻撃者が異なるピアを持つ2つの同時セッションとそれらのピアからの転送シグナリングを互いに確立するのを妨げません。このように2つのシグナリングセッションを連結すると、2つのセッション識別子を持つ2つのシグナリングセッションが作成されますが、その結果、1つのセッションからのTLS接続のみが確立されます。そうすることで、攻撃者は両方のピアが互いに話しているときに彼らが攻撃者と話していると信じる状況を生み出します。
In the absence of any higher-level concept of peer identity, an attacker who is able to copy the session identifier from one signaling session to another can cause the peers to establish a direct TLS connection even while they think that they are connecting to the attacker. This differs from the attack described in the previous section in that there is only one TLS connection rather than two. This kind of attack is prevented by systems that enable peer authentication, such as WebRTC identity [WEBRTC-SEC] or SIP identity [SIP-ID]; however, these systems do not prevent establishing two back-to-back connections as described in the previous paragraph.
ピアアイデンティティのより高いレベルの概念がない場合、セッション識別子をあるシグナリングセッションから別のシグナリングセッションにコピーすることができる攻撃者は、ピアが攻撃者に接続していると考えている間でも直接TLS接続を確立させる可能性があります。。これは、前のセクションで説明されている攻撃とは異なり、2つではなくTLS接続が1つしかありません。この種の攻撃は、WEBRTC ID [WEBRTC-SEC]またはSIP ID [SIP-ID]など、ピア認証を可能にするシステムによって防止されます。ただし、これらのシステムは、前の段落で説明されているように2つのバックツーバック接続の確立を妨げません。
Use of the "external_session_id" does not guarantee that the identity of the peer at the TLS layer is the same as the identity of the signaling peer. The advantage that an attacker gains by concatenating sessions is limited unless data is exchanged based on the assumption that signaling and TLS peers are the same. If a secondary protocol uses the signaling channel with the assumption that the signaling and TLS peers are the same, then that protocol is vulnerable to attack. While out of scope for this document, a signaling system that can defend against session concatenation requires that the signaling layer is authenticated and bound to any TLS connections.
「external_session_id」の使用は、TLS層のピアの識別情報がシグナリングピアのIDと同じであることを保証しません。シグナリングとTLSピアが同じであるという仮定に基づいてデータが交換されない限り、セッションを連結することによる攻撃者が制限されるという利点は限られています。セカンダリプロトコルがシグナリングチャネルを使用する場合、シグナリングとTLSピアが同じであるという仮定で、そのプロトコルは攻撃に対して脆弱です。この文書の範囲外には、セッション連結に対して守ることができるシグナリングシステムは、シグナリング層が認証され、どのTLS接続にバインドされることを必要とする。
It is important to note that multiple connections can be created within the same signaling session. An attacker might concatenate only part of a session, choosing to terminate some connections (and optionally forward data) while arranging to have peers interact directly for other connections. It is even possible to have different peers interact for each connection. This means that the actual identity of the peer for one connection might differ from the peer on another connection.
同じシグナリングセッション内で複数の接続を作成できることに注意することが重要です。攻撃者はセッションの一部のみを連結して、ピアが他の接続のために直接対話するように配置しながら、いくつかの接続（および任意選択で転送するデータ）を終了することを選択するかもしれません。接続ごとに異なるピアが対話することが可能です。つまり、1つの接続のピアの実際の識別情報は、別の接続のピアと異なる場合があります。
Critically, information about the identity of TLS peers provides no assurances about the identity of signaling peers and does not transfer between TLS connections in the same session. Information extracted from a TLS connection therefore MUST NOT be used in a secondary protocol outside of that connection if that protocol assumes that the signaling protocol has the same peers. Similarly, security-sensitive information from one TLS connection MUST NOT be used in other TLS connections even if they are established as a result of the same signaling session.
批判的には、TLSピアのIDに関する情報は、シグナリングピアのIDに関する保証はありません。同じセッション内のTLS接続間で転送されません。したがって、TLS接続から抽出された情報は、シグナリングプロトコルが同じピアを持つと仮定している場合、その接続以外の2次プロトコルで使用しないでください。同様に、同じシグナリングセッションの結果として確立されていても、あるTLS接続からのセキュリティに敏感な情報を他のTLS接続では使用しないでください。
When combined with identity assertions, the mitigations in this document ensure that there is no opportunity to misrepresent the identity of TLS peers. This assurance is provided even if an attacker can modify signaling messages.
アイデンティティアサーションと組み合わせると、この文書の軽減はTLSピアのIDを誤って表現する機会がないことを確認します。この保証は、攻撃者がシグナリングメッセージを変更できる場合でも提供されます。
Without identity assertions, the mitigations in this document prevent the session splicing attack described in Section 4. Defense against session concatenation (Section 5) additionally requires that protocol peers are not able to claim the certificate fingerprints of other entities.
アイデンティティアサーションがなければ、この文書の軽減はセクション4で説明されているセッションスプライシング攻撃を妨げています。セッション連結に対する防衛（セクション5）は、プロトコルピアが他のエンティティの証明書の指紋を主張することができないことをさらに必要とします。
This document registers two extensions in the "TLS ExtensionType Values" registry established in [TLS13]:
このドキュメントでは、[TLS13]で確立された「TLS ExtenctType値」レジストリに2つの拡張子が登録されます。
* The "external_id_hash" extension defined in Section 3.2 has been assigned a code point of 55; it is recommended and is marked as "CH, EE" in TLS 1.3.
* セクション3.2で定義されている「external_id_hash」拡張子には、55のコードポイントが割り当てられています。TLS 1.3では「CH、EE」としてマークされています。
* The "external_session_id" extension defined in Section 4.3 has been assigned a code point of 56; it is recommended and is marked as "CH, EE" in TLS 1.3.
* セクション4.3に定義されている「external_session_id」拡張子には、56のコードポイントが割り当てられています。TLS 1.3では「CH、EE」としてマークされています。
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[ASCII] CERF、V.、「ネットワークインターチェンジのASCIIフォーマット」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<https：//www.rfc-editor.org/info/rfc20>。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[Base64] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https：//www.rfc-editor.org/info/rfc4648>。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[DTLS] Rescorla、E.およびN. MODADUGU、「データグラムトランスポート層セキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[DTLS-SDP] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", RFC 8842, DOI 10.17487/RFC8842, January 2021, <https://www.rfc-editor.org/info/rfc8842>.
[DTLS-SDP] Holmberg、C、R. Shpount、「セッション記述プロトコル（SDP）データグラムトランスポート層セキュリティ（DTLS）およびトランスポート層セキュリティ（TLS）およびRFC 8842、DOI 10.17487 / RFC8842のためのオファー/回答考察2021年1月、<https://www.rfc-editor.org/info/rfc8842>。
[DTLS-SRTP] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[DTLS-SRTP] FISCHL、J.、TSCHOFENIG、H。、およびE.RescoRA、「データグラムトランスポート層セキュリティ（DTLS）」（DTLS）を使用したセキュアリアルタイムトランスポートプロトコル（SRTP）セキュリティコンテキストを確立するためのフレームワーク（DTLS） "、RFC 5763、DOI10.17487 / RFC5763、2010年5月、<https：//www.rfc-editor.org/info/rfc5763>。
[FINGERPRINT] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, <https://www.rfc-editor.org/info/rfc8122>.
[指紋] Lennox、J.およびC. Holmberg、「セッション記述プロトコル（SDP）」、RFC 8122、DOI 10.17487 / RFC8122、2017年3月、<HTTPS：//www.rfc-editor.org/info/rfc8122>。
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[JSON] Breay、T.、「JavaScriptオブジェクト表記（Jobascriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[PASSPORT] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[Passport] Wendt、C.およびJ.Peterson、「パスポート：個人的なアサーショントークン」、RFC 8225、DOI 10.17487 / RFC8225、2018年2月、<https：//www.rfc-editor.org/info/rfc8225>。
[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>。
[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>。
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[SDP]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ RFC4566>。
[SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[SHA]イーストレイク3RD、D.およびT.ハンセン、「米国セキュアハッシュアルゴリズム（SHAとSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：///www.rfc-editor.org/info/rfc6234>。
[SIP-ID] 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>.
[SIP-ID] Peterson、J.、Jennings、C、Rescorla、E.、およびC. WENDT、「セッション開始プロトコル（SIP）」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<https://www.rfc-editor.org/info/rfc8224>。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[SRTP] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[TLS13] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[UTF8] YERGEAU、F。、「ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/RFC3629>。
[WEBRTC-SEC] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.
[WEBRTC-SEC] RESCORLA、E。、「WEBRTCセキュリティアーキテクチャ」、RFC 8827、DOI 10.17487 / RFC8827、2021年1月、<https：//www.rfc-editor.org/info/rfc8827>。
[AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.
[敏捷性]ホームリー、R。、「暗号化アルゴリズムの敏捷性のためのガイドラインと必須の実施アルゴリズムの選択」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<https：//www.rfc-editor.org/ info / rfc7696>。
[ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[ICE]ケラネン、A。、Holmberg、C.、J.Rosenberg、「インタラクティブ接続確立（氷）：ネットワークアドレス翻訳のためのプロトコル（NAT）トラバース、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[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>.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H.、およびG. Camarillo、「セッション開始プロトコル（SIP）」、BCP 85、RFC 3725、DOI 10.17487 / RFC3725、2004年4月、<https：//www.rfc-editor.org/info/rfc3725>。
[RTCP-MUX] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-editor.org/info/rfc5761>.
[rtcp-mux] Perkins、CおよびM.Westerlund、 "1つのポート上の多重化RTPデータおよびコントロールパケット"、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<https://www.rfc-editor.org/ info / rfc5761>。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RTP] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、 "RTP：リアルタイムアプリケーション用輸送プロトコル"、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols", Advances in Cryptology -- CRYPTO 2003, Lecture Notes in Computer Science, Vol. 2729, DOI 10.1007/978-3-540-45146-4_24, August 2003, <https://doi.org/10.1007/978-3-540-45146-4_24>.
[シグマ] Krawczyk、H。、 "SIGMA：認証されたDiffie-Hellmanへの「サインアンドマック」アプローチとIKEプロトコルでのその使用は、Cryptology - Crypto 2003、Crypto 2003、Crypto 2003、Vol。2729、DOI 10.1007 / 978-3-540-45146-4_24、2003年8月、<https://doi.org/10.1007/978-3-540-45146-4_24>。
[UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol", Public Key Cryptography, Lecture Notes in Computer Science, Vol. 1560, DOI 10.1007/3-540-49162-7_12, March 1999, <https://doi.org/10.1007/3-540-49162-7_12>.
[UKS] Blake-Wilson、S.およびA.Menezes、「駅から駅への鍵共有攻撃」、パブリックキー暗号化、コンピュータサイエンス、講義情報1560、DOI 10.1007 / 3-540-49162-7_12、1999年3月、<https：//doi.org/10.1007/3-540-49162-7_12>。
[WEBRTC] Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Proposed Recommendation, <https://www.w3.org/TR/webrtc/>.
[WEBRTC]ジェニングニング、C、Boström、H.、およびJ-I。Bruaroey、 "WebRTC 1.0：ブラウザ間のリアルタイム通信"、W3Cは推奨事項、<https：//www.w3.org/tr/webrtc/>を提案しました。
[ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, <https://www.rfc-editor.org/info/rfc6189>.
[ZRTP] Zimmermann、P.、Johnston、A.、ED。、およびJ.Callas、「Zrtp：ユニキャストセキュアRTPのメディアパスキー契約」、RFC 6189、DOI 10.17487 / RFC6189、2011年4月、<https：//www.rfc-editor.org/info/rfc6189>。
Acknowledgements
謝辞
This problem would not have been discovered if it weren't for discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A solution similar to the one presented here was first proposed by Karthik Bhargavan, who provided valuable input on this document. Thyla van der Merwe assisted with a formal model of the solution. Adam Roach and Paul E. Jones provided significant review and input.
この問題は、SAM Scott、Hugo Krawczyk、Richard Barnesとの議論のためのものではなかった場合に発見されなかったでしょう。ここに提示されたものと同様の解決策は、この文書に貴重な入力を提供したKarthik Bhargavanによって最初に提案されました。Thyla van der Merweは、ソリューションの正式なモデルを支援しました。Adam RoachとPaul E. Jonesは、かなりのレビューと入力を提供しました。
Authors' Addresses
著者の住所
Martin Thomson Mozilla
Martin Thomson Mozilla.
Email: mt@lowentropy.net
Eric Rescorla Mozilla
Eric Rescorla Mozilla.
Email: ekr@rtfm.com