Limited Use of Remote Keys(Lurk)についてのメモ

kazuhoさんのIETF95参加報告資料が参考になるかと思います(20160608追記)
http://www.slideshare.net/kazuho/tls-lurk-ietf-95

2016年1月に、IETFで"Limited Use of Remote Keys(Lurk)"と言う議論が始まりました。

Lurkに関する議論はIETF95のBoFで議論されるようですが、それに先立って簡単に斜め読みしたので自分用にメモ（間違いを含む可能性が多分にあります）。

背景

TLSはサーバを認証するのに使用されています。今まではコンテンツの責任を持つアプリケーションエンドポイント(コンテンツプロバイダ)と、TLSエンドポイントは同じサーバでした。しかし、現在のWebサービスは負荷分散などの理由で、アプリケーションエンドポイントとTLSエンドポイントが異なる構成を取ることが多いです。

エンドポイントが分かれている場合でも、TLSレイヤのサーバ認証を持ってして、アプリケーションエンドポイントを信頼する形になっています。

また、CDNやクラウドのロードバランサを使用している場合は、アプリケーションエンドポイントとTLSエンドポイントが別の組織によって管理されている事になります。

TLSエンドポイント(エッジーサーバ)が、別の組織で運営されている場合でも、コンテンツプロバイダを認証できるようにする方法として2つ挙げられています。

コンテンツプロバイダに関連付けられたクレデンシャルを、各エッジサーバに共有する(なりすますような形)
コンテンツプロバイダのクレデンシャルのままに、コンテンツプロバイダを巻き込む形でWebサーバとエッジーサーバの間でTLSセッションを確立する。

主に議論されるのは後者であり、クライアントはエッジサーバとTLSセッションを確立することでコンテンツプロパイダをも認証できるようにする形かと思います。

つまり、鍵などを共有すること無くHTTPSをCDNにオフロードすることが出来るようになります。

用語の整理

TLSクライアント： TLSセッションを開始するエンドポイントです。
TLSサーバ：TLSセッションの開始を受け付けるエンドポイント。Lurkの議論ではアプリケーションのエンドポイントとは別として考えられます。
エッジサーバ：コンテンツプロバイダへのトラフィックをハンドルするサーバ。TLSサーバでもあり、TLSクライアントはコンテンツプロパイダを認証するためにTLSセッションを開始しますが、エッジサーバがTLSエンドポイントになります。
コンテンツプロバイダ：コンテンツの所有者。
分離認証(Split Authentication)：TLSクライアントが、エッジサーバとのTLSセッション確立を持ってコンテンツプロバイダを認証すること。