8. セキュリティの考慮

本プロトコルは [RFC7525] の推奨に従い TLS 上の HTTP [RFC2818] を用いなければならない (MUST). これにはユーザエージェントとプッシュサービス間の通信に加え, アプリケーションサーバとプッシュサービス間の通信が含まれる. したがってすべての URI は https スキームを用いる. これにより外部当事者からの購読とプッシュメッセージに対する機密性と完全性保護が提供される.

8.1. Confidentiality from Push Service Access (プッシュサービスからの機密性)

TLS が提供する保護はプッシュサービスからコンテンツを守らない. 追加の保護なしでは, プッシュサービスはメッセージ内容を検査し改変できる.

本プロトコルを用いるアプリケーションは, エンドツーエンドの機密性, 完全性, データ起源認証を提供する機構を用いなければならない (MUST). プッシュメッセージを送るアプリケーションサーバとそれを受信するユーザエージェント上のアプリケーションは, しばしば同一アプリケーションの異なるインスタンスであるため, 適切なセキュリティコンテキストを確立するための標準化されたプロトコルは不要である. ユーザエージェントからアプリケーションサーバへの購読情報の配布も鍵合意の便利な媒体となる.

この要件に対して W3C Push API [API] は Message Encryption for WebPush [ENCRYPT] を採用し, メッセージ内容をプッシュサービスから保護する. 他のシナリオは類似の方針で扱いうる.

Topic ヘッダフィールドは, 同一主題のプッシュメッセージをより細かく相関させる情報を露出する. これはプッシュサービスによるプッシュメッセージのトラフィック分析を助けうる.

8.2. Privacy Considerations (プライバシー考慮)

プッシュメッセージの機密性は, 誰がいつ通信しているかという身元の保護を保証しない. しかし露出する情報量は制限できる.

プッシュリソースに対して提供される URI は, 所与のユーザエージェントの通信を相関させる根拠を提供してはならない (MUST NOT). 内容のみに基づいて二つのプッシュリソース URI を相関させることはできてはならない (MUST NOT). これによりユーザエージェントは異なるアプリケーション間や時間経過にわたる相関を制御できる. もちろんユーザエージェントが露出しうる他の情報を用いた相関は防げない.

同様に, プッシュメッセージを識別するためにプッシュサービスが提供する URI は, 購読間の相関を可能にする情報を提供してはならない (MUST NOT). 同一購読のプッシュメッセージ URI は, 関連する購読またはその購読の他のプッシュメッセージとの相関を可能にする情報を含めてもよい (MAY).

ユーザーおよびデバイス情報はプッシュまたはプッシュメッセージ URI を通じて露出してはならない (MUST NOT).

さらに, 同一ユーザエージェントが確立したプッシュ URI または同一購読のプッシュメッセージ URI は, ユーザエージェントと相関させる情報を含んではならない (MUST NOT).

注: 結果としての匿名集合 ([RFC6973] 第 6.1.1 節) が十分大きければ, 完璧である必要はない. プッシュ URI は必然的にプッシュサービスまたは単一サーバインスタンスを識別する. 購読の相関にはトラフィック分析も用いられうる.

ユーザエージェントはいつでも新しい識別子で新しい購読を作成できなければならない (MUST).

8.3. Authorization (認可)

本プロトコルは, プッシュサービスがユーザエージェントに購読の作成を許可するか, プッシュメッセージをユーザエージェントに配信できるかをどう確立するかを定義しない. プッシュサービスは, 利用可能な HTTP 互換の認可方法に基づいてリクエストを認可することを選んでもよい (MAY). 選択肢は複数あり (実験的オプションを含む), セキュリティ水準は様々である. 認可プロセスと関連する資格情報は, プッシュサービスの URI とともにユーザエージェントに構成されることが期待される.

認可はプッシュメッセージ購読, プッシュ, 受領購読リソースの能力 URL (capability URLs) を用いて管理される ([CAP-URI]). 能力 URL は URL の知識のみに基づいてリソースへのアクセスを付与する.

能力 URL は「容易な引き続き共有」と「容易なクライアント API」という性質のために用いられる. これらの性質により, プッシュサービスとアプリケーションサーバ間の事前の関係や追加プロトコルに依存しないようにできる.

能力 URL はベアラトークンとして機能する. プッシュメッセージ購読 URI を知ることは, プッシュメッセージを受信するか購読を削除する権限を意味する. プッシュ URI を知ることはプッシュメッセージを送る権限を意味する. プッシュメッセージ URI を知ることはその特定メッセージの読取りと確認を許す. 受領購読 URI を知ることはプッシュ受領を受信する権限を意味する.

パスコンポーネントに大量のランダムエントロピー (少なくとも 120 ビット) を符号化することで, 有効な能力 URL を推測することの困難さが保証される.

8.4. Denial-of-Service Considerations (DoS 考慮)

ユーザエージェントはプッシュ URI の配布を認可されたアプリケーションサーバに限定することで, 有効なプッシュメッセージの発信元を制御できる. プッシュ URI を推測しにくくすることで, プッシュ URI を受け取ったアプリケーションサーバのみがそれを使えるようにできる.

ユーザエージェントによって正常に認証されなかったプッシュメッセージは配信されないが, これはサービス拒否リスクを呈しうる. 比較的少量のプッシュメッセージでもバッテリー駆動デバイスの電力を枯渇させうる.

このケースに対処するため, W3C Push API [API] は Voluntary Application Server Identification [VAPID] を採用し, ユーザエージェントが購読を特定のアプリケーションサーバに制限できるようにする. プッシュサービスはユーザエージェントに接触せずに不要なメッセージを識別し拒否できる.

有効なプッシュ URI を持つ悪意あるアプリケーションは, プッシュサービスのより大きなリソースを用いてユーザエージェントに対するサービス拒否攻撃を仕掛けうる. プッシュサービスは個々のユーザエージェントへ送るプッシュメッセージのレートを制限すべきである (SHOULD).

アプリケーションサーバがプッシュリソースへのプッシュメッセージ配信のレート制限を超えた場合, プッシュサービスは 429 (Too Many Requests) ステータスコード [RFC6585] を返してもよい (MAY). プッシュサービスは Retry-After ヘッダ [RFC7231] も含めるべきである (SHOULD). アプリケーションサーバがプッシュリソースへの別のリクエストを行う前にどれだけ待つべきかを示す.

プッシュサービスまたはユーザエージェントは, プッシュメッセージを受け取りすぎる購読 (第 7.3 節) を終了してもよい (MAY).

プッシュサービスはユーザエージェントに対するサービス拒否も可能である. メッセージ配信を意図的に失敗させることは, 一時的ネットワークエラー, ユーザエージェント利用の中断, 真のサービス停止などによる故障と区別しにくい.

8.5. Logging Risks (ログのリスク)

サーバリクエストログは購読関連 URI または同一ユーザエージェントの購読関連 URI 間の関係を露呈しうる. ログ保持の制限と強いアクセス制御機構により, URI が不正な主体に露呈しないようにできる.