提案仕様「HTTP Transport Authentication」について

HTTPレイヤにおいて、使用しているトランスポートレイヤの認証を行う「HTTP Transport Authentication」という仕様がGoogleのDavid Schinazi氏から提案されています。軽く読んだのでメモがてら



この提案では新しいリクエストヘッダ、Transport-Authenticationヘッダを定義します。サーバはこのヘッダをもとに接続相手が正しいクライアントかトランスポートレイヤ的に確認することができます。後述の通りTLSの利用を前提としています

もちろん、この機能は既存のHTTP認証を置き換えるものではなく補完する機能となります。

既存のHTTP認証だけでは、トランスポートのコネクション相手が本当に正しいかはわからず、途中でTLSがほどかれている可能性もあります(サーバ認証するのでほぼないでしょうが)。逆に、TLSのクライアント認証だけではどのAuthorityに対するHTTPリクエストかはわからない状態で認証することになります(HTTP/2ではSNIとリクエスト先のhostが一緒とは限らないため)。

下記の記事でも紹介したとおり、HTTP/3上で別の通信を行うに際して利用することを想定しています。

David Schinazi氏は、MASQUEプロトコルの提案者でもあり、まさにMASQUEプロトコルで利用していた認証方式を別出しした形に近いです。

認証とTransport-Authenticationヘッダ

このHTTP Transport Authenticationでは認証用に、事前に共有鍵をサーバとクライアントを共有している、もしくはクライアントの公開鍵をサーバが知っている前提になります。

TLS keying material exporter (rfc5705)の仕組みを利用して、該当のTLSコネクション由来の乱数を取り出しNonceとして利用します。この取り出したNonceを共有鍵、もしくは秘密鍵で暗号化することで認証用データを作ります。作った認証用データをTransport-Authenticationヘッダに入れて送信します。

それでは、Transport-Authenticationヘッダの中身を見ていきます。

   Transport-Authentication: Signature u="am9obi5kb2U=";a=1.3.101.112;
   p="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo
   aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ=="

(表示上改行を入れています)

ヘッダにはいくつかのディレクティブがつきます

  • u: 認証するユーザidをBase64で符号化したもの
  • a: しようする暗号アルゴリズムのOID
  • p: 認証用データ。Nonceを暗号化したもの

HTTPレイヤからトランスポートを認証するメリット

MASQUEプロトコルの仕様でも書かれている通り、TLSのクライアント認証とは異なり通信経路上の第三者に認証を行っていることがわからないというメリットがあります。