インターネット技術タスクフォース (IETF) D. Schinazi
Request for Comments: 9729 Google LLC
カテゴリ: Standards Track D. Oliver
ISSN: 2070-1721 Guardian Project
J. Hoyland
Cloudflare Inc.
2025年2月

隠蔽された HTTP 認証スキーム

要旨

ほとんどの HTTP 認証スキームはプローブ可能であり、認証されていないクライアントが当該オリジンが認証を要求するリソースを提供しているかどうかを調べることが可能です。オリジンは Unauthorized ステータスコードを生成しないことで認証を要求している事実を隠すことができますが、これは非暗号的な認証スキームにのみ有効です：暗号署名は新鮮な nonce の署名を必要とします。本書以前には、オリジンがそのような nonce を、認証を要求するリソースを提供している事実を露呈せずに共有する方法は存在しませんでした。本書は新しいプローブ不可能な暗号認証スキームを定義します。

このメモの状態

これはインターネット標準トラック文書です。

本書はインターネット技術タスクフォース (IETF) の成果物です。IETF コミュニティの合意を表しており、公開審査を受け Internet Engineering Steering Group (IESG) により公開が承認されています。インターネット標準に関する詳細は RFC 7841 のセクション 2 を参照してください。

本書の現行の状態、訂正情報 (errata)、およびフィードバックの提供方法に関する情報は https://www.rfc-editor.org/info/rfc9729 で入手できます。

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

1. はじめに

HTTP authentication schemes（Section 11 of [HTTP]参照）は、オリジンが一部のリソースへのアクセスを認証済みのリクエストのみに制限することを可能にします。これらのスキームは通常、オリジンがクライアントに認証情報の提示を要求するチャレンジを伴いますが、クライアントが事前にそのような情報を送信することも可能です。これは、オリジンが「知る者のみ」にサービスや機能を提供し、その他の者にはその存在を示さないようにしたい場合に特に有用です。このような設計は、鍵配布のために外部で定義された仕組みに依存します。例えば、ある企業が従業員の認証情報を使ってウェブサイト経由で従業員向けのリモートアクセスを提供したり、特定の従業員にのみ限定的な特別機能を提供し、その機能の発見（またはプローブ）を難しくする、などのケースが考えられます。別の例として、より明確に定義されていないコミュニティのメンバーが、より大きな利用者基盤を持つ発行者から一時的な鍵を発行され、地理的・機能的に限定されたリソースへのアクセスを取得することがあります。

デジタル署名ベースの HTTP 認証スキーム（例: [HOBA]）は既に存在しますが、それらは署名入力の新鮮性を確保するためにオリジンが明示的に新しいチャレンジをクライアントに送ることに依存します。これにより、チャレンジを未認証クライアントへ送信する段階でオリジンがプローブ可能になってしまいます。本書ではプローブ不可能な新しい署名ベースの認証スキームを定義します。

1.1. 慣習および定義

本書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、すべて大文字で表記される場合に限り BCP 14（[RFC2119] および [RFC8174]）に従って解釈されます。

本書は Section 1.3 of [QUIC] の記法を使用します。

本書のいくつかの例は長い行を含み、それらは [RFC8792] に記載された折り畳み方で折り畳まれることがあります。

2. 隠蔽された HTTP 認証スキーム

本書は "Concealed" HTTP 認証スキームを定義します。本スキームは非対称暗号を使用します。クライアントは key ID と公開/秘密鍵ペアを保有し、オリジンサーバは認可された key ID を対応する公開鍵へマッピングしたデータを保持します。

クライアントは TLS キー素材エクスポーターを用いて署名するためのデータを生成し（Section 3参照）、その署名を Authorization（または Proxy-Authorization）ヘッダフィールドで送信します（Section 11 of [HTTP]参照）。署名および追加情報は認証パラメータでやり取りされます（Section 4参照）。サーバはこれらを受け取ると、自身の既知鍵データベースのエントリに対して署名が検証できるかを確認できます。検証結果に基づき、サーバはクライアントへの応答（例えば特定リソースへのアクセス制限など）を決定できます。

3. クライアント処理

クライアントがリクエストで Concealed HTTP 認証スキームを使用する際、次のパラメータを用いて TLS キー素材エクスポーターを使い認証証明を計算しなければなりません（SHALL）：

  • ラベルは "EXPORTER-HTTP-Concealed-Authentication" に設定する。

  • コンテキストは Section 3.1 で説明する構造に設定する。

  • エクスポーター出力長は 48 バイトに設定する（Section 3.2参照）。

注: TLS 1.3 のキー素材エクスポーターは Section 7.5 of [TLS]、TLS 1.2 のキー素材エクスポーターは [KEY-EXPORT] に定義されています。

3.1. キーエクスポーターコンテキスト

TLS キーエクスポーターのコンテキストは 図 1 に示すとおりで、記法は Section 1.3 of [QUIC] に従います：

  Signature Algorithm (16),
  Key ID Length (i),
  Key ID (..),
  Public Key Length (i),
  Public Key (..),
  Scheme Length (i),
  Scheme (..),
  Host Length (i),
  Host (..),
  Port (16),
  Realm Length (i),
  Realm (..),

図 1: キーエクスポーターコンテキストのフォーマット

キーエクスポーターコンテキストは次のフィールドを含みます：

Signature Algorithm:
s パラメータで送信される署名スキーム（Section 4.4参照）。
Key ID:
k パラメータで送信されるキー ID（Section 4.1参照）。
Public Key:
サーバがクライアントの署名を検証するために使う公開鍵。そのエンコーディングは Section 3.1.1 に記載。
Scheme:
このリクエストのスキーム。URI のスキーム部分の形式（Section 3.1 of [URI]）に従ってエンコードされます。
Host:
このリクエストのホスト。URI のホスト部分の形式（Section 3.2.2 of [URI]）に従ってエンコードされます。
Port:
このリクエストのポート。ネットワークバイト順でエンコードされます。ポートは URI に含まれるか、使用中のスキームのデフォルトポートである点に注意（Section 3.2.3 of [URI]参照）。
Realm:
realm 認証パラメータで送信される認証レルム（Section 11.5 of [HTTP]参照）。realm 認証パラメータが存在しない場合、このフィールドは空でなければなりません（SHALL）。本書はオリジンがクライアントへレルムを伝える手段を定義しません。クライアントが特定のレルムを使用するよう設定されていない場合、空のレルムを使用し、レルム認証パラメータを送信してはなりません（SHALL NOT）。

Signature Algorithm と Port フィールドは符号なし 16 ビット整数（ネットワークバイト順）でエンコードされます。Key ID、Public Key、Scheme、Host、Realm フィールドは長さ接頭文字付き文字列であり、それぞれの長さを表す Length フィールドが先に付きます。これらの長さフィールドは Section 16 of [QUIC] にある可変長整数エンコーディングを用いてエンコードされ、必要最小限のバイト数でエンコードされなければなりません（MUST）。

3.1.1. 公開鍵のエンコーディング

TLS キーエクスポーターコンテキストの "Public Key" フィールド（上記参照）と a パラメータ（Section 4.2参照）は同じ公開鍵を運びます。公開鍵のエンコーディングは利用される署名アルゴリズムによって決まります。以下のとおり：

RSASSA-PSS アルゴリズム:
公開鍵は RSAPublicKey 構造体（[PKCS1]）で、DER（[X.690]）でエンコードされます。BER のうち DER でないエンコーディングは拒否されなければなりません（MUST）。
ECDSA アルゴリズム:
公開鍵は TLS 1.3 の Section 4.2.8.2 に定義された UncompressedPointRepresentation 構造で、SignatureScheme で指定された曲線を用います。
EdDSA アルゴリズム:
公開鍵は [EdDSA] に定義されるバイト列エンコーディングです。

本書は他のアルゴリズムの公開鍵エンコーディングを定義しません。ある SignatureScheme を Concealed HTTP 認証スキームで使用可能にするためには、その公開鍵エンコーディングが対応文書で定義されている必要があります。

3.2. キーエクスポーター出力

キーエクスポーター出力は 48 バイト長です。そのうち最初の 32 バイトは署名の入力の一部となり、次の 16 バイトは署名とともに送信されます。これにより受信者がエクスポーターが正しい値を生成したことを確認できます。これは 図 2 に示したとおりで、記法は Section 1.3 of [QUIC] に従います：

  Signature Input (256),
  Verification (128),

図 2: キーエクスポーター出力のフォーマット

キーエクスポーター出力は次のフィールドを含みます：

Signature Input:
クライアントが選択した非対称秘密鍵で署名されるデータの一部（Section 3.3参照）。
Verification:
検証値は v パラメータでサーバへ送信されます（Section 4.5参照）。

3.3. 署名の計算

Signature Input がキーエクスポーター出力から抽出されたら（Section 3.2参照）、静的データでプレフィックスを付けてから署名します。署名は次を連結したものに対して計算されます：

  • オクテット 32（0x20）を 64 回繰り返した文字列

  • コンテキスト文字列 "HTTP Concealed Authentication"

  • 区切りとしての単一の 0 バイト

  • キーエクスポーター出力から抽出した Signature Input（Section 3.2参照）

例えば、Signature Input の 32 バイトがすべて 01 に設定されている場合、署名でカバーされる内容（16 進表記）は次のようになります：

2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
48545450205369676E61747572652041757468656E7469636174696F6E
00
0101010101010101010101010101010101010101010101010101010101010101

図 3: 署名でカバーされる内容の例

この静的プレフィックスの目的は、もし認証用の非対称鍵が別プロトコルで誤って再利用された場合に生じ得る問題を軽減するためです（再利用は禁止されていますが、詳細は Section 8 を参照）。この構成は TLS 1.3 の CertificateVerify メッセージ（Section 4.4.3 of [TLS]）のそれを踏襲しています。

生成された署名は p パラメータを用いてサーバに送信されます（Section 4.3参照）。

4. 認証パラメータ

本仕様は以下の認証パラメータを定義します。

以下のバイト列はいずれも base64url（Section 5 of [BASE64]参照）でエンコードされ、引用符やパディングは付けません。つまり、これらのバイト列認証パラメータの値は ASCII の英字、数字、ダッシュ、アンダースコア以外の文字を含んではなりません（MUST NOT）。

以下の整数は符号なしかつ先頭ゼロ無しでエンコードされます。つまり、この整数認証パラメータの値は数字以外の文字を含んではならず（MUST NOT）、値全体が "0" の場合を除いて先頭が 0 であってはなりません。

以下は [ABNF] の記法を用いた構文です： 

concealed-byte-sequence-param-value = *( ALPHA / DIGIT / "-" / "_" )
concealed-integer-param-value =  %x31-39 1*4( DIGIT ) / "0"

図 4: 認証パラメータ値の ABNF

4.1. k パラメータ

必須の "k"（キー ID）パラメータは、クライアントがどの鍵を使って認証したいかを識別するバイト列です。バックエンドはこれを用いて既知鍵のサーバ側データベース内のエントリを参照します（Section 6.3参照）。

4.2. a パラメータ

必須の "a"（公開鍵）パラメータは、サーバがクライアントの署名を検証するために用いる公開鍵を指定するバイト列です。これにより鍵の混同問題が回避されます（参照: [SEEMS-LEGIT]）。公開鍵のエンコーディングは Section 3.1.1 に記載されています。

4.3. p パラメータ

必須の "p"（proof）パラメータは、クライアントが自身の key ID に対応する資格情報を保持していることを証明するために提示する証明を指定するバイト列です。

4.4. s パラメータ

必須の "s"（署名スキーム）パラメータは、p パラメータで送信される証明の計算に使用された署名スキームを指定する整数です。その値は 0 から 65535 の範囲の整数で、IANA の "TLS SignatureScheme" レジストリ（<https://www.iana.org/assignments/tls-parameters>）から取られます。

4.5. v パラメータ

必須の "v"（verification）パラメータは、クライアントがキーエクスポーター出力を保持していることを証明するために提供する検証値を指定するバイト列です（詳細は Section 3.2 参照）。これは、特定の入力に対して複数の入力に有効な署名を生成できる鍵が存在する署名スキームに関する問題を回避します（参照: [SEEMS-LEGIT]）。

5. 例

例えば、key ID が "basement" で署名アルゴリズムに Ed25519 [ED25519] を用いるクライアントは、以下のようなヘッダフィールドを生成する可能性があります：

NOTE: '\' line wrapping per RFC 8792

Authorization: Concealed \
  k=YmFzZW1lbnQ, \
  a=VGhpcyBpcyBh-HB1YmxpYyBrZXkgaW4gdXNl_GhlcmU, \
  s=2055, \
  v=dmVyaWZpY2F0aW9u_zE2Qg, \
  p=QzpcV2luZG93c_xTeXN0ZW0zMlxkcml2ZXJz-ENyb3dkU\
    3RyaWtlXEMtMDAwMDAwMDAyOTEtMD-wMC0w_DAwLnN5cw

図 5: ヘッダフィールドの例

6. サーバ処理

本節ではサーバの役割を二つに分けます：

  • 「フロントエンド」はクライアントが作成した TLS または QUIC 接続を終端する HTTP サーバ上で稼働します。

  • 「バックエンド」は許容されたキー識別子と公開鍵のデータベースへアクセスできる HTTP サーバ上で稼働します。

多くの導入では、フロントエンドとバックエンドの役割は単一の HTTP オリジンサーバ内に実装されることが想定されます（Section 3.6 of [HTTP]参照）。しかしながら、フロントエンドを HTTP ゲートウェイ（Section 3.7 of [HTTP]参照）とし、バックエンドを HTTP オリジンサーバとするように分割することもできます。

6.1. フロントエンド処理

フロントエンドが Concealed HTTP 認証スキームをチェックするよう設定されている場合、Authorization（または Proxy-Authorization）ヘッダフィールドを解析します。認証スキームが "Concealed" に設定されているとき、フロントエンドは Section 4 に定義されたとおり、すべての必須認証パラメータが存在し正しく解析可能であることを検証しなければなりません（MUST）。もし任意のパラメータが欠落するか解析に失敗した場合、フロントエンドは Authorization（または Proxy-Authorization）ヘッダフィールド全体を無視しなければなりません（MUST）。

フロントエンドはこれらの認証パラメータからキーエクスポーター出力を計算します（Section 3.2参照）。その後、フロントエンドはヘッダフィールドとキーエクスポーター出力をバックエンドと共有します。

6.2. フロントエンドとバックエンド間の通信

フロントエンドとバックエンドの役割が同一マシン上で実装されている場合、単純な関数呼び出しで処理できます。

役割が別々の HTTP サーバ間で分割されている場合、バックエンドはクライアントとフロントエンド間の TLS 接続から直接 TLS キー素材エクスポーターへアクセスできないため、フロントエンドがそれを明示的に送信する必要があります。本書はその目的のために "Concealed-Auth-Export" リクエストヘッダフィールドを定義します。Concealed-Auth-Export ヘッダフィールドの値は、48 バイトのキーエクスポーター出力（Section 3.2参照）を含む Structured Field Byte Sequence（Section 3.3.5 of [STRUCTURED-FIELDS]参照）であり、パラメータは含みません。なお Structured Field Byte Sequence は非 URL 安全（standard base64）な variant の base64 でエンコードされます。例えば：

NOTE: '\' line wrapping per RFC 8792

Concealed-Auth-Export: :VGhpc+BleGFtcGxlIFRMU/BleHBvcn\
  Rlc+BvdXRwdXQ/aXMgNDggYnl0ZXMgI/+h:

図 6: Concealed-Auth-Export ヘッダフィールドの例

フロントエンドは、元の未変更の Authorization（または Proxy-Authorization）ヘッダフィールドおよび新たに追加した Concealed-Auth-Export ヘッダフィールドを含めて HTTP リクエストをバックエンドへ転送しなければなりません（SHALL）。

このメカニズムの安全性はキーエクスポーター出力が正しいことを前提とするため、バックエンドはフロントエンドがそれを真実に送信していると信頼する必要があります。この信頼関係は一般的で、フロントエンドは応答するためにすでに TLS 証明書の秘密鍵へアクセスする必要があることが多いからです。Concealed-Auth-Export ヘッダフィールドを解析する HTTP サーバは、送信元を信頼していることを確認していない限りそれを無視しなければなりません（MUST）。同様に、Concealed-Auth-Export ヘッダフィールドを送信するフロントエンドは、クライアントから受け取った Concealed-Auth-Export ヘッダフィールドを転送しないようにしなければなりません（MUST）。

6.3. バックエンド処理

バックエンドが Authorization（または Proxy-Authorization）ヘッダフィールドとキーエクスポーター出力を受け取ったら、キー ID を自身の公開鍵データベースで検索します。バックエンドは次のチェックを行わなければなりません（SHALL）：

  • すべての必須認証パラメータが存在し Section 4 に定義されたとおり正しく解析可能であることを検証する

  • キー ID がバックエンドのデータベースに存在し対応する公開鍵へマッピングされていることを確認する

  • データベースの公開鍵が Authorization（または Proxy-Authorization）ヘッダフィールド内のものと等しいことを検証する

  • Authorization（または Proxy-Authorization）ヘッダフィールドの検証フィールドがキーエクスポーター出力から抽出されたものと一致することを検証する

  • Section 3.3 に定義されたとおり暗号署名を検証する

これらのチェックがすべて成功した場合、バックエンドはリクエストが正しく認証されたとみなして適切に応答できます（バックエンドはリクエストを別の HTTP サーバへ転送することもできます）。

上記のいずれかのチェックが失敗した場合、バックエンドは Authorization（または Proxy-Authorization）ヘッダフィールドが存在しなかったかのように扱わなければなりません（MUST）。

6.4. プローブ不可能なサーバ処理

存在がプローブされないリソースを導入したいサーバは、未認証のクライアントに対してそれらのリソースに関する情報を決して露呈しないようにする必要があります。特に、そのようなサーバは認証失敗に対して、存在しないリソースに対して使用するのと同一の応答を返さなければなりません（MUST）。例えば、401（Unauthorized）の代わりに 404（Not Found）を使用することが挙げられます。

上述の認証チェックは計算に時間がかかることがあり、攻撃者は既知の存在しないリソースへのリクエストと、認証が必要な可能性のあるリソースへのリクエストのタイミングを比較することでこのメカニズムの使用を検出する可能性があります。サーバは、いくつかの存在しないリソースへの応答にわずかな遅延を導入することで認証検証のタイミングが観測されないように緩和できます。ただし、この遅延自体がこの機構の使用を明らかにしないように慎重に検討する必要があります。

プローブ不可能なリソースは、未認証ユーザにとって発見不能である必要もあります。例えば、サーバ運営者が未認証ユーザに対してある認証済みリソースを存在しないかのように偽装して隠したい場合、その運営者は当該リソースへのリンクを含む未認証ページや、未認証ユーザが当該リソースを発見するための他の帯域外手段が存在しないことを保証する必要があります。

7. TLS 使用に関する要件

本認証スキームは TLS を用いる HTTP の使用に対してのみ定義されます（[TLS]）。これは、典型的に HTTP/2（[HTTP/2]）や、トランスポートプロトコルが認証と鍵交換機構として TLS を使用する HTTP/3（[HTTP/3]）を含みます（参照: [QUIC-TLS]）。

TLS キー素材エクスポーターは TLS セッションに一意に結び付けられている場合にのみ認証に対して安全であるため（[RFC7627]）、Concealed 認証スキームは以下のいずれかのプロパティを要求します：

  • 使用中の TLS バージョンが 1.3 以上であること（[TLS]）。

  • 使用中の TLS バージョンが 1.2 であり、extended master secret 拡張（[RFC7627]）がネゴシエートされていること。

クライアントは上記のいずれのプロパティも満たさない接続上で Concealed HTTP 認証スキームを使用してはなりません（MUST NOT）。サーバが上記いずれのプロパティも満たさない接続上で本認証スキームを用いるリクエストを受け取った場合、サーバは認証が存在しなかったかのようにそのリクエストを扱わなければなりません（MUST）。

8. セキュリティに関する考慮事項

Concealed HTTP 認証スキームは、サーバがクライアントへ nonce を送信することなく、新鮮性を保証しつつオリジンサーバへクライアントが認証することを可能にします。これにより、サーバは一部リソースについて認証を受け付けながら、そのことを未認証クライアントに対して明らかにせずに済みます。また、クライアントが TLS Client Hello の平文拡張のために認証の存在を観測者へ漏らすことなく認証できる点も利点です。

上で述べた新鮮性は TLS キーエクスポーターによって提供されるため、基盤となる TLS 接続と同程度に古くなり得ます。サーバは GOAWAY フレーム（Section 5.2 of [HTTP/3]参照）等の仕組みでクライアントに新しい接続の作成を強制することにより、より強い新鮮性を要求できます。

本書で説明する認証証明は個々の HTTP リクエストに結び付いていません。同一接続上で同じ鍵を複数のリクエスト認証に使用する場合、それらはすべて同一になります。これはワイヤ上の圧縮を向上させますが、クライアント実装が単一の HTTP 接続で異なるセキュリティコンテキストを多重化する場合、それらのコンテキストが互いのヘッダフィールドを読めないようにする必要があります。さもなければ、あるコンテキストが他のコンテキストの Authorization ヘッダフィールドをリプレイできてしまいます。この制約は現代のウェブブラウザで満たされています。もし攻撃者がブラウザを乗っ取り別コンテキストのメモリへアクセスできるようになれば、攻撃者は対応する鍵へもアクセスできる可能性があるため、リクエストに認証を結び付けることは実際上あまり利点がないでしょう。

Concealed HTTP 認証スキームで使用する認証用の非対称鍵は他プロトコルで再利用してはなりません（MUST NOT）。署名対象データへ静的プレフィックスを追加することでこの問題を緩和しようとしていますが（Section 3.3参照）、鍵の再利用は認証の安全性を損なう可能性があります。

本スキームを提供するオリジンは同一鍵を使うリクエストをリンク（関連付け）できます。ただし、使用される鍵が個々のオリジン固有である限り、リクエストはオリジン間でリンク可能にはなりません。

9. IANA に関する考慮事項

9.1. HTTP 認証スキームレジストリ

IANA は "HTTP Authentication Schemes" レジストリ（<https://www.iana.org/assignments/http-authschemes>）に以下のエントリを登録しました：

Authentication Scheme Name:
Concealed
Reference:
RFC 9729
Notes:
なし

9.2. TLS キー素材エクスポーター ラベル

IANA は "TLS Exporter Labels" レジストリ（<https://www.iana.org/assignments/tls-parameters>）に以下のエントリを登録しました：

Value:
EXPORTER-HTTP-Concealed-Authentication
DTLS-OK:
N
Recommended:
Y
Reference:
RFC 9729

9.3. HTTP フィールド名

IANA は "Hypertext Transfer Protocol (HTTP) Field Name Registry"（<https://www.iana.org/assignments/http-fields>）に以下のエントリを登録しました：

Field Name:
Concealed-Auth-Export
Status:
permanent
Structured Type:
Item
Reference:
RFC 9729
Comments:
なし

10. 参考文献

10.1. 規範的参照文献

[ABNF]
...（参照情報は原文のまま）

10.2. 情報参考文献

[ED25519]
...（参照情報は原文のまま）

謝辞

著者らは多くの IETF コミュニティメンバーに感謝します。本文書は多数の廊下での会話の成果です。特に、David Benjamin、Reese Enghardt、Nick Harper、Dennis Jackson、Ilari Liusvaara、François Michel、Lucas Pardue、Justin Richer、Ben Schwartz、Martin Thomson、Chris A. Wood に対して、そのレビューと貢献に感謝します。本書で説明するメカニズムは元々 MASQUE の最初の反復の一部でした（[MASQUE-ORIGINAL]）。

著者の連絡先

David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
EMail: dschinazi.ietf@gmail.com
David M. Oliver
Guardian Project
EMail: david@guardianproject.info
URI: https://guardianproject.info
Jonathan Hoyland
Cloudflare Inc.
EMail: jonathan.hoyland@gmail.com