[要約] RFC 8833は、WebRTC (Web Real-Time Communication) のコンテキストにおいて、Application-Layer Protocol Negotiation (ALPN) を使用するためのガイドラインを提供します。この文書の目的は、WebRTCのデータチャネルでの効率的なプロトコル選択とネゴシエーションを可能にすることにあります。ALPNを利用することで、クライアントとサーバー間で使用するアプリケーション層のプロトコルを事前に合意することができ、これにより接続のセットアップ時間が短縮され、パフォーマンスが向上します。関連するRFCには、ALPNを定義するRFC 7301や、WebRTC自体を定義するRFC 7478などがあります。RFC 8833は、WebRTCアプリケーションの開発者にとって重要な参考資料となります。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8833 Mozilla
Category: Standards Track January 2021
ISSN: 2070-1721
Application-Layer Protocol Negotiation (ALPN) for WebRTC
WebRTCのアプリケーション層プロトコルネゴシエーション（ALPN）
Abstract
概要
This document specifies two Application-Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communication (WebRTC). The "webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control Transmission Protocol (SCTP) over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.
このドキュメントでは、Web Real-Time Communication（WebRTC）で使用する2つのApplication-Layer Protocol Negotiation（ALPN）ラベルを指定します。「webrtc」ラベルは、通常のWebRTCを識別します。これは、Secure Real-time Transport Protocol（SRTP）のキーを確立するため、またはDTLSを介したStream Control Transmission Protocol（SCTP）を使用してデータチャネルを確立するために使用されるDTLSセッションです。「c-webrtc」ラベルは同じプロトコルを説明しますが、ピアは他のアプリケーションと共有しないことでメディアの機密性を維持することにも同意します。
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コミュニティのコンセンサスを表しています。パブリックレビューを受け、Internet Engineering Steering Group（IESG）による公開が承認されました。インターネット標準の詳細については、RFC7841のセクション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/rfc8833.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8833で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2021 IETFTrustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
1.1. Conventions
2. ALPN Labels for WebRTC
3. Media Confidentiality
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Author's Address
Web Real-Time Communication (WebRTC) [RFC8825] uses Datagram Transport Layer Security (DTLS) [RFC6347] to secure all peer-to-peer communications.
Webリアルタイム通信（WebRTC）[RFC8825]は、Datagram Transport Layer Security（DTLS）[RFC6347]を使用して、すべてのピアツーピア通信を保護します。
Identifying WebRTC protocol usage with Application-Layer Protocol Negotiation (ALPN) [RFC7301] enables an endpoint to positively identify WebRTC uses and distinguish them from other DTLS uses.
Application-Layer Protocol Negotiation（ALPN）[RFC7301]を使用してWebRTCプロトコルの使用を識別することにより、エンドポイントはWebRTCの使用を明確に識別し、他のDTLSの使用と区別することができます。
Different WebRTC uses can be advertised and behavior can be constrained to what is appropriate to a given use. In particular, this allows for the identification of sessions that require confidentiality protection from the application that manages the signaling for the session.
さまざまなWebRTCの使用をアドバタイズでき、動作を特定の使用に適したものに制限できます。特に、これにより、セッションのシグナリングを管理するアプリケーションからの機密保護を必要とするセッションの識別が可能になります。
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]で説明されているように、ここに示すように、すべて大文字で表示される場合にのみ解釈されます。
The following identifiers are defined for use in ALPN:
以下の識別子は、ALPNで使用するために定義されています。
webrtc: The DTLS session is used to establish keys for the Secure Real-time Transport Protocol (SRTP) -- known as DTLS-SRTP -- as described in [RFC5764]. The DTLS record layer is used for WebRTC data channels [RFC8831].
webrtc：[RFC5764]で説明されているように、DTLSセッションは、Secure Real-time Transport Protocol（SRTP）（DTLS-SRTPと呼ばれる）のキーを確立するために使用されます。DTLSレコードレイヤーは、WebRTCデータチャネル[RFC8831]に使用されます。
c-webrtc: The DTLS session is used for confidential WebRTC, where peers agree to maintain the confidentiality of the media, as described in Section 3. The confidentiality protections ensure that media is protected from other applications, but the confidentiality protections do not extend to messages on data channels.
c-webrtc：DTLSセッションは、セクション3で説明されているように、ピアがメディアの機密性を維持することに同意する機密WebRTCに使用されます。機密性保護は、メディアが他のアプリケーションから保護されることを保証しますが、機密性保護はデータチャネル上のメッセージ。
Both identifiers describe the same basic protocol: a DTLS session that is used to provide keys for an SRTP session in combination with WebRTC data channels. Either SRTP or data channels could be absent. The data channels send the Stream Control Transmission Protocol (SCTP) [RFC4960] over the DTLS record layer, which can be multiplexed with SRTP on the same UDP flow. WebRTC requires the use of Interactive Connectivity Establishment (ICE) [RFC8445] to establish UDP flow, but this is not covered by the identifier.
両方の識別子は、同じ基本プロトコルを記述します。WebRTCデータチャネルと組み合わせてSRTPセッションのキーを提供するために使用されるDTLSセッションです。SRTPまたはデータチャネルのいずれかが存在しない可能性があります。データチャネルは、同じUDPフローでSRTPと多重化できるDTLSレコードレイヤーを介してストリーム制御伝送プロトコル（SCTP）[RFC4960]を送信します。WebRTCでは、UDPフローを確立するためにInteractive Connectivity Establishment（ICE）[RFC8445]を使用する必要がありますが、これは識別子の対象外です。
A more thorough definition of what WebRTC entails is included in [RFC8835].
WebRTCが必要とするもののより完全な定義は、[RFC8835]に含まれています。
There is no functional difference between the identifiers except that an endpoint negotiating "c-webrtc" makes a promise to preserve the confidentiality of the media it receives.
「c-webrtc」をネゴシエートするエンドポイントが、受信するメディアの機密性を保持することを約束することを除いて、識別子間に機能的な違いはありません。
A peer that is not aware of whether it needs to request confidentiality can use either identifier. A peer in the client role MUST offer both identifiers if it is not aware of a need for confidentiality. A peer in the server role SHOULD select "webrtc" if it does not prefer either.
機密性を要求する必要があるかどうかを認識していないピアは、どちらの識別子も使用できます。クライアントロールのピアは、機密性の必要性を認識していない場合、両方の識別子を提供する必要があります。サーバーロールのピアは、どちらも優先しない場合は「webrtc」を選択する必要があります。
An endpoint that requires media confidentiality might negotiate a session with a peer that does not support this specification. An endpoint MUST abort a session if it requires confidentiality but does not successfully negotiate "c-webrtc". A peer that is willing to accept "webrtc" SHOULD assume that a peer that does not support this specification has negotiated "webrtc" unless signaling provides other information; however, a peer MUST NOT assume that "c-webrtc" has been negotiated unless explicitly negotiated.
メディアの機密性を必要とするエンドポイントは、この仕様をサポートしていないピアとセッションをネゴシエートする場合があります。エンドポイントは、機密性が必要であるが「c-webrtc」のネゴシエーションに成功しない場合、セッションを中止する必要があります。「webrtc」を受け入れる意思のあるピアは、シグナリングが他の情報を提供しない限り、この仕様をサポートしないピアが「webrtc」をネゴシエートしたと想定する必要があります。ただし、ピアは、明示的にネゴシエートされない限り、「c-webrtc」がネゴシエートされたと想定してはなりません（MUSTNOT）。
Private communications in WebRTC depend on separating control (i.e., signaling) capabilities and access to media [RFC8827]. In this way, an application can establish a session that is end-to-end confidential, where the ends in question are user agents (or browsers) and not the signaling application. This allows an application to manage signaling for a session without having access to the media that is exchanged in the session.
WebRTCのプライベート通信は、分離制御（つまり、シグナリング）機能とメディアへのアクセスに依存しています[RFC8827]。このようにして、アプリケーションはエンドツーエンドの機密であるセッションを確立できます。この場合、問題のエンドはユーザーエージェント（またはブラウザー）であり、シグナリングアプリケーションではありません。これにより、アプリケーションは、セッションで交換されるメディアにアクセスしなくても、セッションのシグナリングを管理できます。
Without some form of indication that is securely bound to the session, a WebRTC endpoint is unable to properly distinguish between a session that requires this confidentiality protection and one that does not. The ALPN identifier provides that signal.
セッションに安全にバインドされている何らかの形式の表示がないと、WebRTCエンドポイントは、この機密保護を必要とするセッションと必要としないセッションを適切に区別できません。ALPN識別子はその信号を提供します。
A browser is required to enforce this confidentiality protection using isolation controls similar to those used in content cross-origin protections (see the "Origin" section of [HTML5]). These protections ensure that media is protected from applications, which are not able to read or modify the contents of a protected flow of media. Media that is produced from a session using the "c-webrtc" identifier MUST only be displayed to users.
ブラウザは、コンテンツのクロスオリジン保護で使用されるものと同様の分離コントロールを使用してこの機密保護を実施する必要があります（[HTML5]の「オリジン」セクションを参照）。これらの保護により、保護されたメディアフローのコンテンツを読み取ったり変更したりできないアプリケーションからメディアを確実に保護できます。「c-webrtc」識別子を使用してセッションから生成されたメディアは、ユーザーにのみ表示する必要があります。
The promise to apply confidentiality protections do not apply to data that is sent using data channels. Confidential data depends on having both data sources and consumers that are exclusively browser or user based. No mechanisms currently exist to take advantage of data confidentiality, though some use cases suggest that this could be useful, for example, confidential peer-to-peer file transfer. Alternative labels might be provided in the future to support these use cases.
機密保護を適用するという約束は、データチャネルを使用して送信されるデータには適用されません。機密データは、ブラウザまたはユーザーベースのみのデータソースとコンシューマーの両方を持っているかどうかに依存します。現在、データの機密性を利用するメカニズムは存在しませんが、一部のユースケースでは、機密のピアツーピアファイル転送など、これが役立つ可能性があることが示唆されています。これらのユースケースをサポートするために、将来的に代替ラベルが提供される可能性があります。
This mechanism explicitly does not define a specific authentication method; a WebRTC endpoint that accepts a session with this ALPN identifier MUST respect confidentiality no matter what identity is attributed to a peer.
このメカニズムは、特定の認証方法を明示的に定義していません。このALPN識別子を持つセッションを受け入れるWebRTCエンドポイントは、ピアに起因するIDに関係なく、機密性を尊重する必要があります。
RTP middleboxes and entities that forward media or data cannot promise to maintain confidentiality. Any entity that forwards content, or records content for later access by entities other than the authenticated peer, MUST NOT offer or accept a session with the "c-webrtc" identifier.
メディアまたはデータを転送するRTPミドルボックスおよびエンティティは、機密性の維持を約束できません。コンテンツを転送するエンティティ、または認証されたピア以外のエンティティによる後でアクセスするためにコンテンツを記録するエンティティは、「c-webrtc」識別子を持つセッションを提供または受け入れてはなりません（MUSTNOT）。
Confidential communications depend on more than just an agreement from browsers.
機密通信は、ブラウザからの合意以上のものに依存します。
Information is not confidential if it is displayed to others than for whom it is intended. Peer authentication [RFC8827] is necessary to ensure that data is only sent to the intended peer.
情報は、意図された相手以外に表示された場合、機密情報ではありません。ピア認証[RFC8827]は、データが目的のピアにのみ送信されるようにするために必要です。
This is not a digital rights management mechanism. A user is not prevented from using other mechanisms to record or forward media. This means that (for example) screen-recording devices, tape recorders, portable cameras, or a cunning arrangement of mirrors could variously be used to record or redistribute media once delivered. Similarly, if media is visible or audible (or otherwise accessible) to others in the vicinity, there are no technical measures that protect the confidentiality of that media.
これはデジタル著作権管理メカニズムではありません。ユーザーは、他のメカニズムを使用してメディアを記録または転送することを妨げられません。これは、（たとえば）画面記録デバイス、テープレコーダー、ポータブルカメラ、またはミラーの狡猾な配置を使用して、配信されたメディアを記録または再配布できることを意味します。同様に、メディアが近くにいる他の人に見えるか聞こえる（またはアクセスできる）場合、そのメディアの機密性を保護する技術的手段はありません。
The only guarantee provided by this mechanism and the browser that implements it is that the media was delivered to the user that was authenticated. Individual users will still need to make a judgment about how their peer intends to respect the confidentiality of any information provided.
このメカニズムとそれを実装するブラウザによって提供される唯一の保証は、認証されたユーザーにメディアが配信されたことです。個々のユーザーは、提供された情報の機密性をピアがどのように尊重するかについて判断する必要があります。
On a shared computing platform like a browser, other entities with access to that platform (i.e., web applications) might be able to access information that would compromise the confidentiality of communications. Implementations MAY choose to limit concurrent access to input devices during confidential communications sessions.
ブラウザのような共有コンピューティングプラットフォームでは、そのプラットフォームにアクセスできる他のエンティティ（つまり、Webアプリケーション）が、通信の機密性を損なう情報にアクセスできる可能性があります。実装は、機密通信セッション中に入力デバイスへの同時アクセスを制限することを選択できます（MAY）。
For instance, another application that is able to access a microphone might be able to sample confidential audio that is playing through speakers. This is true even if acoustic echo cancellation, which attempts to prevent this from happening, is used. Similarly, an application with access to a video camera might be able to use reflections to obtain all or part of a confidential video stream.
たとえば、マイクにアクセスできる別のアプリケーションは、スピーカーから再生されている機密オーディオをサンプリングできる場合があります。これは、これを防止しようとする音響エコーキャンセレーションが使用されている場合でも当てはまります。同様に、ビデオカメラにアクセスできるアプリケーションは、反射を使用して機密ビデオストリームの全部または一部を取得できる場合があります。
The following two entries have been added to the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]:
[RFC7301]によって確立された「TLSアプリケーション層プロトコルネゴシエーション（ALPN）プロトコルID」レジストリに、次の2つのエントリが追加されました。
webrtc: The "webrtc" label identifies mixed media and data communications using SRTP and data channels:
webrtc：「webrtc」ラベルは、SRTPとデータチャネルを使用したミクストメディアとデータ通信を識別します。
Protocol: WebRTC Media and Data
プロトコル：WebRTCメディアとデータ
Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")
識別シーケンス：0x77 0x65 0x62 0x72 0x74 0x63（ "webrtc"）
Specification: RFC 8833 (this document)
仕様：RFC 8833（このドキュメント）
c-webrtc: The "c-webrtc" label identifies WebRTC with a promise to protect media confidentiality:
c-webrtc：「c-webrtc」ラベルは、メディアの機密性を保護することを約束してWebRTCを識別します。
Protocol: Confidential WebRTC Media and Data
プロトコル：機密WebRTCメディアとデータ
Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 ("c-webrtc")
識別シーケンス：0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63（ "c-webrtc"）
Specification: RFC 8833 (this document)
仕様：RFC 8833（このドキュメント）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/rfc2119>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] McGrew、D。およびE. Rescorla、「Secure Real-time Transport Protocol（SRTP）のキーを確立するためのDatagram Transport Layer Security（DTLS）Extension」、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<https：//www.rfc-editor.org/info/rfc5764>。
[RFC6347] 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>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[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>。
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.
[RFC8827] Rescorla、E。、「WebRTC Security Architecture」、RFC 8827、DOI 10.17487 / RFC8827、2021年1月、<https://www.rfc-editor.org/info/rfc8827>。
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.
[RFC8831] Jesup、R.、Loreto、S。、およびM.Tüxen、「WebRTC Data Channels」、RFC 8831、DOI 10.17487 / RFC8831、2021年1月、<https://www.rfc-editor.org/info/rfc8831>。
[HTML5] WHATWG, "HTML - Living Standard", Section 7.5, January 2021, <https://html.spec.whatwg.org/#origin>.
[HTML5] WHATWG、「HTML-Living Standard」、セクション7.5、2021年1月、<https://html.spec.whatwg.org/#origin>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、 "Stream Control Transmission Protocol"、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC8445] 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>.
[RFC8445] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, <https://www.rfc-editor.org/info/rfc8825>.
[RFC8825] Alvestrand、H。、「Overview：Real-Time Protocols for Browser-Based Applications」、RFC 8825、DOI 10.17487 / RFC8825、2021年1月、<https://www.rfc-editor.org/info/rfc8825>。
[RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, DOI 10.17487/RFC8835, January 2021, <https://www.rfc-editor.org/info/rfc8835>.
[RFC8835] Alvestrand、H。、「Transports for WebRTC」、RFC 8835、DOI 10.17487 / RFC8835、2021年1月、<https://www.rfc-editor.org/info/rfc8835>。
Author's Address
著者の住所
Martin Thomson Mozilla
マーティントムソンMozilla
Email: martin.thomson@gmail.com