読者です 読者をやめる 読者になる 読者になる

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で議論されるようですが、それに先立って簡単に斜め読みしたので自分用にメモ(間違いを含む可能性が多分にあります)。


関連IDは主にココらへんです

背景

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セッション確立を持ってコンテンツプロバイダを認証すること。

アーキテクチャ

方式として「Session Key Interface (SKI) for TLS and DTLS」といった方法が提案されているようです。

  • エッジサーバ:TLSクライアントから見るとただのTLSサーバのよう見見える。エッジサーバは秘密鍵を持たないTLSサーバのようにデザインされています。その代わり、秘密鍵が使用される時の暗号的操作はキーサーバに寄って行なわれます。
  • 鍵サーバ秘密鍵をホストしており、暗号的操作をエッジサーバの代わりに行います。


I-D中で記述されている、ハンドシェイクシーケンスを見たほうがイメージが湧くかもしれません。



https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01#section-7.2