Open Screenネットワークプロトコル

1. 序論

Open Screenネットワークプロトコルは、ブラウザーとデバイスが互いを発見し、 安全なネットワーク接続を確立するための、ネットワークプロトコルの基本集合を提供する。 この接続は、 Open Screenアプリケーションプロトコルのトランスポート層として使用できる。

アプリケーションプロトコルとネットワークプロトコルは独立している。しかし、 ネットワークプロトコルはアプリケーションプロトコルの要件を満たすように設計されている。 そのトランスポート層を利用する他のアプリケーションレベルのプロトコルに適している場合もあれば、 適していない場合もある。

ネットワークプロトコルの基本的な流れは次のとおりである:

• エージェントがローカルエリア ネットワーク上で互いを発見するためのDNS-SDの使用。

• 初期の未認証接続を確立するため、自己署名 証明書を伴うTLS 1.3の使用。

• 相互の同一性を検証し 証明書を交換するためのSPAKE2の使用。

• IP上のトランスポート層としての QUICの使用。

付録C: フロー全体図のフローチャートは、 一連のイベント全体を示している。

付随する 解説は、 このプロトコルに関するより多くの背景を提供する。

1.1. 用語

Open Screenネットワーク プロトコルエージェント（またはOSPエージェント）は、このプロトコルの任意の実装 （ブラウザー、ディスプレイ、スピーカー、またはその他のソフトウェア）である。

2. 要件

2.1. 一般要件

1. Open Screenネットワークプロトコルエージェントは、 同じIPv4またはIPv6サブネットに接続され、IPマルチキャストで到達可能な 別のOSPエージェントの存在を発見できなければならない。

2. OSPエージェントは、エージェントのIPv4またはIPv6アドレス、 エージェントの表示名、およびそのエージェントへのネットワークトランスポートを 確立するためのIPポート番号を取得できなければならない。

2.2. 非機能要件

1. Open Screenネットワークプロトコルは、ローエンドのスマートフォン、 スマートTVまたはストリーミングデバイスに見られるものと同程度の控えめな ハードウェア要件で実装できるべきである。エージェントのハードウェア仕様については、 デバイス 仕様 文書を参照のこと。

2. 発見および接続プロトコルは、特にバッテリー駆動である可能性が高い 待受エージェントにおいて、 電力消費を最小化すべきである。

3. このプロトコルは、プレゼンテーション、リモート再生、メディアストリームの内容を含め、 ユーザーの同一性またはエージェント上の活動について、受動的なネットワーク観測者に提供される 情報量を最小化すべきである。

4. このプロトコルは、能動的なネットワーク攻撃者がディスプレイになりすまし、 コントローラーまたはレシーバー向けのデータを観測または変更することを 防ぐべきである。

5. 待受エージェントは、告知エージェントが利用可能または 利用不能になる時点（すなわち、ネットワークに接続または切断された時点）を 迅速に発見できるべきである。

6. エージェントは、ユーザーが別のエージェントを認証したことを記憶できるべきである。 これは、エージェントが、ユーザーがすでに認証したエージェントに接続しようとするたびに、 ユーザーが介入して再認証する必要はないことを意味する。

7. エージェント間のメッセージ遅延は、対話的な利用を可能にするために 最小化されるべきである。たとえば、あるエージェントでフォームに入力したテキストが プレゼンテーションにリアルタイムで表示されることが快適であるべきである。 ゲームまたはマウス利用に対するリアルタイム遅延が理想的だが、要件ではない。

3. mDNSによる発見

Open Screenネットワークプロトコルエージェントは、 IPサービスエンドポイントとともに自らを識別する情報を告知し、待ち受けることで 互いを発見する。DNS-SDおよび mDNSによるエージェントの告知および発見は、 この仕様で定義され、すべてのエージェントによる実装が必須である。 ただし、エージェントは、ユニキャストDNS経由で同じDNS-SDレコードを問い合わせるなど、 追加の発見機構を自由に実装できる。

OSPエージェントはDNS-SDのサービス名 _openscreen._udpを使用しなければならない。

告知エージェントとは、 _openscreen._udp.localに対するmDNSクエリに応答するエージェントである。そのようなエージェントは、 プレゼンテーション表示の人間が読める説明である表示 名（空でない文字列）を持つべきである。例: "Living Room TV."

待受エージェントとは、 _openscreen._udp.localに対するmDNSクエリを送信するエージェントである。 待受エージェントは表示名を持ってもよい。

告知エージェントは、エージェントの表示名の接頭辞であるDNS-SDのインスタンス 名を使用しなければならない。インスタンス名が完全な表示名ではない場合、 待受エージェントがそれが切り詰められたことを知ることができるように、 null（\000）文字で終端されなければならない。

告知エージェントは、複数の告知エージェントが同じDNS-SDインスタンス名を使用することを防ぐため、 mDNSの衝突 解決手順に従わなければならない。

エージェントは、インスタンス名をユーザーに表示する際に注意すべきである。インスタンス名表示の指針については、 § 7.4.1 インスタンス名および表示名を参照のこと。

告知エージェントは、次のキーおよび値を持つDNS TXTレコードを含めなければならない:

fp

告知エージェントのエージェント フィンガープリント。エージェントフィンガープリントを計算する手順は 下で定義される。

mv

メタデータが変更されたことを示す符号なし整数値。 告知エージェントはこれをより大きな値に更新しなければならない。 これは、更新されたメタデータを発見するために告知エージェントへ接続すべきであることを 待受エージェントに合図する。この値は 可変長整数としてエンコードされるべきである。

at

[A-Za-z0-9+/]の集合に含まれる文字からなる、 推測困難な英数字トークン。

注: atは、LAN外の当事者による 認証の試行を防ぐ。§ 7.3.3 リモートの能動的ネットワーク攻撃者を参照のこと。 atは、ブルートフォース攻撃を実用的でなくするため、 少なくとも32ビットの真のエントロピーを持つべきである。

注: OSPエージェントが（省電力などの理由で） ネットワーク接続を一時停止する場合、ネットワーク接続が再開されたときに 発見状態が維持されるよう、キャッシュ済みで有効なmDNSレコードの保持を試みるべきである。

このQUICベースのプロトコルの将来の拡張は、同じメタデータ発見プロセスを用い、 今後決定される機能機構を通じて、それらの拡張への対応を示すことができる。 Open Screenネットワークプロトコルの将来バージョンがmDNSを使用するが メタデータ発見プロセスとの互換性を破る場合、新しいDNS-SDサービス名に変更し、 メタデータ発見の新しい機構を示すべきである。

3.1. エージェントフィンガープリントの計算

エージェントのエージェントフィンガープリントは、 次の手順に従って計算される:

1. エージェント 証明書の SKPI Fingerprintを、 ハッシュアルゴリズムとしてSHA-256を用い、 [RFC7469]に従って計算する。

2. 手順1の結果を[RFC4648]に従ってbase64エンコードする。

注: 結果の文字列は長さ44バイトになる。

3.2. 証明書シリアル番号の計算

証明書 シリアル番号を、次の手順の結果とする:

1. エージェントがエージェント証明書を生成したことがない場合:
   1. 証明書シリアル番号ベースを128ビットの UUIDとする。
   2. 証明書シリアル番号カウンターを32ビットの 符号なし整数とし、初期値を0に設定する。
2. 次のように160ビット値を生成する:
   1. 証明書シリアル番号カウンターを1増加させる。
   2. 上位128ビットを証明書シリアル番号ベースに割り当てる。
   3. 下位32ビットを証明書シリアル番号カウンターに割り当てる。

3.3. エージェントホスト名の計算

エージェントは、自身のDNS-SDサービス インスタンス名または 証明書 シリアル番号を変更するたびに、次のようにエージェントホスト名を 計算しなければならない。

1. base64SerialNumberを、base64エンコードされた 証明書シリアル番号に設定する。

2. encodedInstanceNameを、次の結果に設定する:

   1. DNS-SDインスタンス名内の [A-Za-z0-9-]以外の任意の文字をハイフン-に置換する。

3. encodedDomainを、次の結果に設定する:

   1. DNS-SDドメイン名内の [A-Za-z0-9-]以外の任意の文字をハイフン-に置換する。

4. エージェントホスト名を 次の文字列に設定する: base64SerialNumber + . + encodedInstanceName + . + encodedDomain

TODO: 告知エージェントについて、メタデータ、DNS-SDレコード、および証明書 フィールドの例を含む付録を追加する。

4. QUICによるトランスポートおよびメタデータ発見

待受エージェントが 告知エージェントに接続する、 またはその追加メタデータを知ろうとする場合、SRVレコードのIPおよびポートに対して QUIC接続を開始する。 認証前に（追加メタデータなどの）メッセージが交換されることがあるが、 そのような情報は未検証として扱われるべきである（たとえば、未認証エージェントの表示名が 未検証であることをユーザーに示すなど）。

両方のエージェントで使用される接続IDは長さ0であるべきである。長さ0の接続IDが選ばれる場合、 エージェントは新しいQUIC接続を確立せずにIPまたはポートを変更することが制限される。 そのような場合、エージェントはIPまたはポートを変更するために新しいQUIC接続を 確立しなければならない。

4.1. TLS 1.3

OSPエージェントが別のエージェントへのQUIC接続を行うとき、 接続を保護するために TLS 1.3を使用しなければならない。 TLS 1.3は、接続がOSPを用いて特定のOSPエージェントと通信するために使用されることを示す、 次のアプリケーション固有のパラメーターとともに使用されるべきである。 OSPエージェントは、これらのパラメーターを欠く着信接続を拒否してもよい。

• 使用されるALPNは "osp"でなければならない。

• server_name extensionは、エージェントホスト名に設定されなければならない。

• 受信した エージェント 証明書について計算されたエージェント フィンガープリントは、告知エージェントによって告知された fp mDNS TXTレコードと一致しなければならない。

OSPエージェントはTLS early dataを送信してはならない。

IANAにALPNを登録する。 [Issue #228]

4.2. エージェント証明書

各OSPエージェントは、TLS 1.3証明書交換で使用される公開鍵を含む X.509 v3エージェント 証明書を生成しなければならない。告知エージェントおよび待受エージェントの双方は、 QUIC接続を行うとき、TLS 1.3のCertificateメッセージで エージェント 証明書を使用しなければならない。

エージェント証明書は、 次の特性を持たなければならない:

• 256ビットECDSA公開鍵。

• 自己署名。

• TLS 1.3で定義されるecdsa_secp256r1_sha256 署名スキームに対応する。

  • AlgorithmIdentifier値は、（公開 鍵については）[RFC5480]、および （署名スキームについては）[RFC5758] で定義される。

  • [X690]は、 識別子をエンコードするために使用されるDER（Distinguished Encoding Rules）表現を 規定する。

• 署名に有効。

各エージェント証明書は、上記の手順で計算された一意の 証明書シリアル番号を持つ。 下の値<sn>は、そのシリアル番号で置換されるべきである。

次のX.509 v3フィールドは次のように設定される:

上で言及されていない必須フィールドは、[RFC5280]に従って設定されるべきである。

注: OSPエージェントは、ユーザーインターフェイスおよびデバッグ目的で、 Oキーの値として実装者名またはデバイスモデル名を使用してもよい。 また、ユーザーインターフェイスおよびデバッグ目的で、位置キー（L、 ST、およびC）の値としてエージェント実装者または デバイス製造者の所在地を使用してもよい。

OSPエージェントが、§ 6 認証を通じてまだ検証していない エージェント証明書を見た場合、そのエージェントを未検証として扱い、 そのエージェントとの追加メッセージの交換を許可する前に、そのエージェントとの認証を 開始しなければならない。

OSPエージェントが、認証を通じて検証済みの有効な エージェント証明書を見た場合、以後のメッセージを送信する前に そのエージェントとの認証を開始する必要はない。

待受エージェントが告知エージェントからメッセージを受信したい場合、または 告知エージェントが待受エージェントへメッセージを送信したい場合、 接続上で定期的にデータを送信することにより、QUIC接続を維持したいと考えることがある。

OSPエージェントが（省電力などの理由で）ネットワーク接続を一時停止する場合、 ネットワーク接続が復元された後、以前接続していたOSPエージェントへのQUIC接続の 再開を試みるべきである。

5. CBORおよびQUICストリームを用いたメッセージ配信

メッセージはCBORを用いてシリアライズされる。 メッセージのグループを順序どおりに送信するには、そのメッセージグループは1つのQUICストリームで 送信されなければならない。独立したメッセージグループ（グループ間に順序依存関係がないもの）は、 異なるQUICストリームで送信されるべきである。複数のCBORシリアライズ済みメッセージを 同じQUICストリームに入れるため、次が使用される。

注: Open Screenエージェントは、音声、動画、またはデータストリーミングのユースケースに 必要となり得る同時ストリーム数を考慮し、アプリケーション性能を妨げないようにQUICストリーム制限 （MAX_STREAMS）を設定すべきである。

各メッセージについて、OSPエージェントは、単方向QUICストリームに 次を書き込まなければならない:

1. メッセージの型を表す型キー。可変長整数としてエンコードされる（型キーについては 付録A: メッセージを参照）

2. CBORとしてエンコードされたメッセージ。

エージェントが、認識しない型キーのメッセージを受信した場合、アプリケーションエラーコード404で QUIC接続を閉じなければならず、CONNECTION_CLOSEフレームの理由フレーズに 未知の型キーを含めるべきである。

可変長整数は、 Variable-Length Integer Encodingでエンコードされる。 これはQUICで使用される。

6. 認証

各対応認証方式は、その方式に固有の認証メッセージを通じて実装される。 認証方式はメッセージ自体によって明示的に指定される。認証ステータスメッセージは すべての認証方式に共通である。追加される新しい認証方式は、新しい認証メッセージを定義しなければならない。

Open Screenネットワークプロトコルエージェントは、 事前共有鍵を用いる§ 6.1 SPAKE2による認証を実装しなければならない。

認証に先立ち、エージェントは、ユーザーにとっての事前共有鍵（PSK）入力容易性および対応PSK入力方式を指定する auth-capabilitiesメッセージを交換する。 PSK入力容易性が最も低いエージェントは、認証要求を送信または受信するときにPSKをユーザーに提示する。 両方のエージェントが同じPSK入力容易性値を持つ場合、サーバーがPSKをユーザーに提示する。 同じ事前共有鍵が両方のエージェントで使用される。PSKをユーザーに提示するエージェントがPSK提示者であり、 ユーザーにPSKの入力を要求するエージェントがPSK消費者である。

PSK入力容易性は0から100まで（両端を含む）の整数であり、0はこのデバイスで ユーザーがPSKを入力することが不可能であることを意味し、100はそのデバイスで ユーザーがPSKを入力しやすいことを意味する。対応PSK入力方式は、数値およびQRコードのスキャンである。 0でないPSK入力容易性を持つデバイスは、数値PSK入力方式に対応しなければならない。

任意の認証方式は、ユーザーにPSKを表示する、またはユーザーからPSK入力を要求する前に、 auth-initiation-tokenを要求してもよい。 告知エージェントについては、 そのmDNS TXTレコード内のatフィールドが、そのエージェントとの間で送受信される 最初の認証メッセージのauth-initation-tokenとして使用されなければならない。 エージェントは、auth-initation-tokenが設定されており、 告知エージェントによって提供されたatと一致しない任意の認証メッセージを破棄すべきである。

auth-capabilitiesメッセージの psk-min-bits-of-entropyフィールドにおいて、 エージェントは、PSKに要求する最小エントロピービット数を、20から60ビットまで（両端を含む）の範囲で 指定してもよく、既定値は20である。PSK提示者は、このフィールドで受信した値以上、 かつこのフィールドで送信した値以上のエントロピービットを持つPSKを生成しなければならない。

エージェントがユーザーに複数の方法（たとえばQRコードと数値PSKの両方）でPSKを表示することを選ぶ場合、 それらは同じPSKに対するものであるべきである。異なる場合、PSK提示者はユーザーがどれを選んで使用したかを 知ることができず、それが認証失敗につながる可能性がある。

付録C: フロー全体図では、エージェントが対応してもよいPSKの2つのエンコーディングスキームを説明する。 これらは、ユーザーに表示するための文字列または QRコードのいずれかを生成する。

6.1. SPAKE2による認証

[Meta] CFRG PAKE competitionの結果を追跡する [Issue #242]

この節で定義されるすべてのメッセージおよびオブジェクトについては、完全なCDDL定義を 付録A: メッセージで参照のこと。

既定の認証方式は、次の暗号スイートを持つ SPAKE2である:

1. 楕円曲線はedwards25519である。

2. ハッシュ関数はSHA-256である。

3. 鍵導出関数はHKDFである。

4. メッセージ認証コードはHMACである。

5. パスワードハッシュ関数はSHA-512である。

Open Screenネットワークプロトコルは、SPAKE2でPSKをハッシュするためにメモリハードなハッシュ関数を使用せず、 代わりにSHA-512を使用する。これは、PSKが一回限りの使用であり、いかなる形でも保存されないためである。

SPAKE2は明示的な相互認証を提供する。

この認証方式は、エージェントが、ユーザーが電話、キーボードまたはTVリモコンで入力できる 数値や短いパスワードなどの低エントロピー秘密を共有していることを前提とする。

SPAKE2は対称ではなく、Alice（A）とBob（B）の2つの役割を持つ。

この認証方式で使用されるメッセージは、auth-spake2-handshake、 auth-spake2-confirmation、およびauth-statusである。[SPAKE2]は、 auth-spake2-handshakeおよびauth-spake2-confirmationが どのように計算されるかを詳細に説明している。

SPAKE2で使用される値AおよびBは、それぞれクライアントおよびサーバーの エージェントフィンガープリントである。 pwはユーザーに提示されるPSKである。

PSK提示者またはPSK消費者は、（SPAKE2のAliceの役割を引き受けて） 認証を開始してもよい。

PSK提示者が認証を開始したい場合、PSKをユーザーに提示し、 auth-spake2-handshakeメッセージを送信することで 認証プロセスを開始する。 auth-spake2-handshakeメッセージのpublic-valueフィールドは SPAKE2からのpAの値に設定されなければならず、psk-statusフィールドは psk-shownに設定されなければならない。

PSK消費者がauth-spake2-handshakeメッセージを受信すると、PSK消費者は まだ行っていない場合、ユーザーにPSK入力を求める。PSKを受け取ると、 auth-spake2-handshakeメッセージを送信し、 public-valueフィールドをSPAKE2からのpBの値に設定し、 psk-status フィールドをpsk-inputに設定する。

PSK消費者が認証を開始したい場合、PSK消費者はPSK提示者へ auth-spake2-handshakeメッセージを送信し、 psk-status フィールドをpsk-needs-presentationに設定し、public-valueフィールドを pAに設定する。このメッセージを受信したPSK提示者はPSKを作成し、 それをユーザーに提示する。それが完了すると、PSK消費者へauth-spake2-handshake メッセージを送信し、psk-statusをpsk-inputに設定し、 public-valueフィールドをpBに設定する。

エージェントがauth-spake2-handshakeメッセージから pAとpBの両方を知ると、 auth-spake2-confirmationを計算して送信し、 confirmation-valueフィールドを他方のエージェントに対する cA（Aliceの場合）またはcB（Bobの場合）に設定する。

エージェントがauth-spake2-confirmationメッセージを受信すると、 [SPAKE2]の手順を用いてそのメッセージを検証し、その後、 auth-status認証済みメッセージで 他方のエージェントに応答する。resultの値が authenticated以外の場合は、認証が失敗したことを意味し、エージェントは 直ちに切断しなければならない。

注: auth-statusメッセージは単なる情報提供である。各エージェントは 鍵確認の検証を通じてSPAKE2の結果を独立に計算するためである。

付録C: フロー全体図は、エージェント同士がまだ認証していない場合のプロセス全体、 すなわち発見、QUIC接続確立、メタデータ交換、および認証を示している。 エージェントが認証を完了した場合、認証段階は省略できる。

7. セキュリティとプライバシー

Open Screenネットワークプロトコルは、2つのOSP エージェントが互いを発見し、 ユーザーおよびアプリケーションデータを交換することを可能にする。そのため、そのセキュリティおよび プライバシーに関する考慮事項は綿密に検討されるべきである。私たちは、W3Cの Security and Privacy Questionnaireを用いて プロトコル自体を評価し、またエージェントがこれらのセキュリティおよびプライバシー要件を満たすために 使用できる推奨緩和策についても議論する。

7.1. 脅威モデル

7.1.1. 受動的ネットワーク攻撃者

Open Screenネットワークプロトコルは、同じLANに接続されているすべての当事者が OSPエージェント間を流れるすべてのデータを観測できると想定すべきである。

これらの当事者は、mDNSレコードおよびQUICハンドシェイクなど、 暗号化されていないメッセージを通じて公開される任意のデータを収集できる。

これらの当事者は、QUIC接続上のデータフローを観測すること、または暗号処理タイミングを観測することにより、 暗号パラメーターを知ろうと試みる可能性がある。

7.1.2. 能動的ネットワーク攻撃者

侵害されたルーターなどの能動的攻撃者は、エージェント間で交換されるデータを操作できる。 彼らは既存のQUIC接続にトラフィックを注入し、新しいQUIC接続を開始しようと試みることができる。 これらの能力は、次を試みるために使用できる:

• エージェント、またはユーザーによりすでに認証されたエージェントになりすまし、 ユーザーにそれへ認証させようとする。

• エージェントに接続し、その機能を問い合わせる。

特に懸念される攻撃の1つは、設定ミスまたは侵害されたルーターが、 ローカルネットワークデバイス（OSPエージェントなど）をインターネットに露出させることである。 この攻撃ベクトルは、通常はインターネットからアクセスできないローカルネットワークサービスに接続することで、 悪意ある当事者がプリンターやスマートTVを制御するために使用されてきた。

7.1.3. サービス拒否

LANに接続された当事者は、OSPエージェントへのアクセスを拒否しようと試みる可能性がある。 たとえば、攻撃者は、正当な接続をブロックしたりエージェントのシステムリソースを枯渇させたりする目的で、 エージェントへ大量のQUIC接続を開こうとする可能性がある。また、mDNS待受側のキャッシュ容量を 枯渇させるため、または待受側に大量の偽QUIC接続を開かせるために、 偽のDNS-SDレコードをマルチキャストする可能性もある。

7.2. Open Screenネットワークプロトコルのセキュリティおよびプライバシーに関する考慮事項

7.2.1. 個人識別情報および高価値 データ

次のデータは、合理的に機密にすることができず、 公開と見なされるべきである:

1. Open Screenネットワークプロトコルで使用されるIPアドレスおよびポート。

2. 表示名接頭辞、証明書フィンガープリントおよびシリアル番号、ならびにメタデータバージョンを含む、 mDNSを通じて告知されるデータ。

7.2.2. クロスオリジン状態に関する考慮事項

ネットワークプロトコルは、オリジン状態を直接扱わない。

7.2.3. 他のデバイスへのオリジンアクセス

設計上、Open Screenネットワークネットワークプロトコルは、それを使用するアプリケーションプロトコルを通じて、 Webからデバイスへのアクセスを許可する。このプロトコルを実装することにより、 これらのデバイスは自らをWebから利用可能にしていることを承知しており、それに応じて設計されるべきである。

以下では、これらのデバイスの悪意ある利用を防ぐための緩和手順を議論する。

7.2.4. プライベートブラウジングモード

ユーザーエージェントは、同じユーザーエージェントインスタンスからの通常ブラウジングと プライベートブラウジングについて、別々の認証コンテキスト（§ 6 認証を参照）および QUIC接続（§ 4 QUICによるトランスポートおよびメタデータ発見を参照）を使用することが推奨される。 これにより、他のデバイスが同じユーザーによる通常ブラウジングとプライベートブラウジングの活動を 照合することがより困難になる。

7.2.5. 永続状態

エージェントは、§ 6 認証を正常に完了したエージェントの同一性を 永続化する可能性が高い。これには、それらの当事者の公開鍵フィンガープリント、 メタデータバージョン、およびメタデータが含まれる可能性がある。

ただし、このデータは通常Webに公開されず、表示選択または表示認証プロセス中に ユーザーエージェントのネイティブUIを通じてのみ公開される。ユーザーが閲覧データを消去したときに、 ユーザーエージェントがこのデータを消去するか保持するかは実装上の選択となり得る。

7.2.6. その他の考慮事項

Open Screenネットワークネットワークプロトコルは、Webに対して次への追加アクセスを付与しない:

• 新しいスクリプト読み込み機構

• ユーザーの位置情報へのアクセス

• デバイスセンサーへのアクセス

• ユーザーのローカルコンピューティング環境へのアクセス

• ユーザーエージェントのネイティブUIに対する制御

• ユーザーエージェントのセキュリティ特性

7.3. 緩和戦略

7.3.1. ローカルの受動的ネットワーク攻撃者

ローカルの受動的攻撃者は、Open Screenネットワークプロトコルを使用して、ユーザー活動および デバイス機能に関するデータを収集しようと試みる可能性がある。これに対処する主な戦略は、 ユーザー媒介の認証が行われる前には不透明な公開鍵フィンガープリントのみを公開するという データ最小化である。

受動的攻撃者はまた、TLS 1.3 QUIC接続の暗号パラメーターを知るために タイミング攻撃を試みる可能性がある。TLS 1.3のアプリケーションプロファイルは 定時間暗号を義務付けており、TLS 1.3実装はサイドチャネル攻撃に耐性のある 楕円曲線署名操作を使用すべきである。

7.3.2. ローカルの能動的ネットワーク攻撃者

ローカルの能動的攻撃者は、ユーザーが通常信頼するプレゼンテーションディスプレイになりすまそうとする可能性がある。 Open Screenネットワークプロトコルの§ 6 認証手順は、 共有秘密を知らない中間者がエージェントになりすますことを防ぐ。しかし、攻撃者が 既存の信頼済みエージェント、またはまだ認証されていない新しく発見されたエージェントになりすまし、 ユーザーにそれへ認証するよう仕向けることは可能である。（この文脈における信頼とは、 ユーザーが自身のエージェントから別のエージェントへの§ 6 認証を完了したことを意味する。）

これは複数の技術の組み合わせによって対処できる。第一は、 なりすましの試みを検出することである。エージェントは次の状況を検出し、 いずれかの基準を満たすエージェントを不審な エージェントとしてフラグ付けすべきである:

• 同時告知中に、公開鍵フィンガープリントが衝突する別個のIPエンドポイントを持つ エージェント。

• 特定の公開鍵フィンガープリントの下で以前に告知されたものと表示名が異なる 信頼されていないエージェント。

• 一定回数、認証チャレンジに失敗する信頼されていないエージェント。

• すでに信頼済みのエージェントの表示名に類似する表示名を告知する 信頼されていないエージェント。

第二は、相互認証中の低エントロピー秘密の管理による:

• ブルートフォース攻撃を防ぐために、低エントロピー秘密をローテーションする。

• 認証チャレンジへの応答に増加するバックオフを用いる。これもブルートフォース攻撃を 防ぐためである。

• 共有秘密を生成するために暗号学的に健全なエントロピー源を使用する。

能動的攻撃者はまた、トラフィックを注入または変更することにより、 QUIC接続上で交換されるデータを妨害しようとする可能性がある。これらの攻撃は、 TLS 1.3の正しい実装によって緩和されるべきである。TLS 1.3プロトコルの詳細な セキュリティ分析については、[RFC8446]の付録Eを参照のこと。

7.3.3. リモートの能動的ネットワーク攻撃者

残念ながら、ネットワークデバイスがOSPエージェントを完全に保護することには依存できない。 設定ミスのあるファイアウォールまたはNATが、LAN接続されたエージェントを より広いインターネットに露出させる可能性があるためである。OSPエージェントは、 任意のインターネットホストからの攻撃に対して安全であるべきである。

告知エージェントは、LAN外から§ 6 認証を開始しようとする試みから 自身を保護するため、mDNS TXTレコードのatフィールドを設定しなければならない。 そのような試みは、ユーザーの迷惑（PSKの表示または入力）およびPSKに対する 潜在的なブルートフォース攻撃をもたらす。

7.3.4. サービス拒否

ユーザーのローカルエリアネットワークに由来するサービス拒否攻撃を完全に防ぐことは困難である。 OSPエージェントは、そのような攻撃にもかかわらず既存の活動を継続できるようにする試みとして、 新しい接続を拒否したり、過剰な数のメッセージを受信した接続を閉じたり、 特定の応答者からキャッシュされるmDNSレコード数を制限したりできる。

7.3.5. 悪意ある入力

OSPエージェントは、解析脆弱性を悪用して対象デバイスを侵害しようとする 悪意ある入力に対して堅牢であるべきである。

可能な場合、OSPエージェント（コンテンツやメディアレンダリングなどのアプリケーションレベルのコンポーネントを含む）は、 脆弱性がユーザーデータへアクセスしたり永続的な悪用につながったりすることを防ぐため、 サンドボックス化のような 多層防御技術を使用すべきである。

7.4. ユーザーインターフェイスに関する考慮事項

この仕様は、OSPエージェントのセキュリティ関連ユーザーインターフェイスについて 具体的な要件を設けない。しかし、PSKベースの認証ではユーザーがどのエージェントを信頼するかについて 十分な情報に基づく判断を行う必要があるため、これらのユーザーインターフェイスを設計する際には 重要な考慮事項がある。

1. エージェントが別のデバイスを認証する前に、そのエージェントはそのデバイスからの任意のデータが 認証によって検証されていないことを明確にすべきである。 （これがDNS-SDインスタンス名にどのように適用されるかについては以下を参照。）

2. 不審なエージェントは、 不審ではない信頼済みエージェントとは異なるように表示されるべきであり、 またはまったく表示されないべきである。

3. 認証中にPSKを提示するユーザーインターフェイスは、信頼されたUIで行われ、 なりすましが困難であるべきである。どの物理デバイスがPSKを提示しているかが ユーザーに明確であるべきである。

4. 認証中にPSKを入力するユーザーインターフェイスは、信頼されたUIで行われ、 なりすましが困難であるべきである。

5. ユーザーがこの手順を盲目的にクリックして進めることを防ぐため、 ユーザーはPSKを入力するための操作を要求されるべきである。

6. PSKをレンダリングおよび入力するユーザーインターフェイスは、 アクセシビリティガイドラインを満たすべきである。

7.4.1. インスタンス名および表示名

DNS-SDインスタンス名は、認証前にユーザーが見る主要な情報であるため、 これらの名前を注意深く提示する必要がある。

DNS-SDをagent-infoという アプリケーションメッセージに関連付けないように言い換える。 [Issue #346]

エージェントはインスタンス名を未検証情報として扱わなければならず、 QUIC接続の成功後にagent-infoメッセージを通じて受信した表示名の接頭辞であることを 確認すべきである。エージェントがこの確認を行った後、その名前を 検証済み 表示名として表示できる。

エージェントは、DNS-SDからの切り詰められた表示名の代わりに、完全な表示名のみをユーザーに 表示すべきである。切り詰められた表示名は、完全な検証済み表示名として表示される前に、 上記のように検証されるべきである。

付録A: メッセージ

次のメッセージは、Concise Data Definition Language構文を用いて定義される。整数キーが使用される場合、 フィールド名を示すコメントが行に追加される。この仕様のオブジェクト定義は、 ワイヤ上のバイト数を減らしながら各キーに対する人間が読める名前を維持するため、 この通常とは異なる構文を持つ。任意フィールドの容易な索引付けを可能にするため、 オブジェクト配列の代わりに整数キーが使用される。

各ルートメッセージ（別のメッセージに包まれずにQUICストリームに入れられるもの）は、 メッセージ型キーを示すコメントを持つ。

より小さい数は、より頻繁に送信される、または非常に小さい、あるいはその両方であるメッセージのために 予約されるべきであり、より大きい数は、あまり頻繁に送信されない、または大きい、あるいはその両方である メッセージのために予約されるべきである。小さい型キーはワイヤ上でより小さくエンコードされるためである。

; type key 1001
auth-capabilities = {
  0: uint ; psk-ease-of-input
  1: [* psk-input-method] ; psk-input-methods
  2: uint ; psk-min-bits-of-entropy
}

psk-input-method = &(
  numeric: 0
  qr-code: 1
)

auth-initiation-token = {
  ? 0: text ; token
}

auth-spake2-psk-status = &(
  psk-needs-presentation: 0
  psk-shown: 1
  psk-input: 2
)

; type key 1003
auth-spake2-confirmation = {
  0: bytes .size 64 ; confirmation-value
}

auth-status-result = &(
  authenticated: 0
  unknown-error: 1
  timeout: 2
  secret-unknown: 3
  validation-took-too-long : 4
  proof-invalid: 5
)

; type key 1004
auth-status = {
  0: auth-status-result ; result
}

; type key 1005
auth-spake2-handshake = {
  0: auth-initiation-token; initiation-token
  1: auth-spake2-psk-status ; psk-status
  2: bytes ; public-value
}

付録B: PSKエンコーディングスキーム

次の付録では、20ビットから80ビットの長さの値 Pを取り、ユーザーに表示するための文字列またはQRコードを 生成する2つのPSKエンコーディングスキームを説明する。

エージェントは、認証手順の相互運用性を最大化するために、これらのエンコーディングスキームを使用すべきである。 認証手順では通常、一方のデバイスにPSKを表示し、ユーザーがそれを別のデバイスに入力する必要がある。

10進数値

Pを数値文字列へエンコードするには、次の手順に従う:

1. Pを10進整数Nに変換する。

2. Nが9桁未満の場合:

   • Nの左側を3 - len(N) mod 3桁のゼロで埋める。

   • Nを、3桁ごとにダッシュで区切って出力する。

3. Nが9桁を超える場合:

   • Nの左側を4 - len(N) mod 4桁のゼロで埋める。

   • Nを、4桁ごとにダッシュで区切って出力する。

文字列NをPSK Pへデコードするには、次の手順に従う:

1. Nからダッシュおよび先頭のゼロを削除する。

2. Nを10進数として解析し、Pを得る。

注: Pの値が約2^30から2^40の間である場合、 長さ10から12桁の値が生成される。12桁を超える値は入力に不便であり、 追加のセキュリティ価値は限られる。

注: ここでは16進エンコーディングの使用を許可しない。 それは10進数値エンコーディングと曖昧になり得るためであり、またすべてのデバイスが 英数字入力に対応しているとは限らないためである。

QRコード

PSKをQRコードへエンコードするには、次の手順に従う:

1. Nを、Pの値をASCIIエンコードされた16進文字列へ変換したものに設定する。

2. 値Nを持つテキストQRコードを構築する。

QRコードが与えられたときにPSK Pをデコードするには、次の手順に従う:

1. QRコードをデコードして文字列Nを得る。

2. Nを16進数として解析し、Pを得る。