要約

  • RFC 1004は、Cookie Jarという認証サーバーが許可された相手を調べ、一組の通信相手に一度きりの鍵を渡す案を示した。1987年4月の議論用文書である。
  • 接続を始める三番目のメッセージが再送されると、受け手は新しい関係が始まったと思う可能性がある。送り手は返答を捨て、再送が続けばタイムアウトが重なる。

二台のゲートウェイをAとBと呼ぼう。AはBに経路情報を送りたい。だがパケットに「Aから」と書くだけなら、第三者にも同じ字が書ける。EGPでは、隣り合う機器がまず関係を結ぶ。Millsはこの最初の一歩に確認役を置いた。名前はCookie Jar。AとBが話してよい組み合わせかを調べ、二台だけが使う新しい鍵を渡すサーバーだ。名前は台所風でも、仕事は門番である。

RFC 1004はEGPや提案段階のDGPなど、分散して動く通信手順を念頭に置く。道中ではメッセージが失われたり、重なったり、悪意のある相手に書き換えられたりする。各利用者には公開のアドレスと、長く持つ秘密鍵がある。公開名簿には、誰と関係を結んでよいかが載る。瓶は秘密鍵の表を持ち、名簿を確認する。iがjと話す許可を得ていれば、一組専用の乱数鍵K(i,j)を作る。瓶は双方のために別々に包んだ「クッキー」を返し、iがjの分を運ぶ。長く使う秘密鍵はネットワーク上で渡さずに済む。

瓶が握るのは、入場名簿と鍵の配布だ。二台が線でつながっていても、名簿に載っていなければ関係は始まらない。関係を結んだ後は、共有した鍵でチェックサムと連番を保護する。偽の送信者や古いメッセージを見分けるためだ。通常のデータを隠す設計ではない。Millsは部品の弱さも書いた。16ビットのInternetチェックサムには語やバイトの並べ替えに関わる弱点があり、当時候補だったDESも再検討すべきだとした。瓶の名前がかわいくても、鍵穴の出来は別問題だった。

ここで古いRequestが問題になる。AがBへ送った三番目の接続メッセージを、誰かが保存して後からもう一度流す。Bは新しい接続の始まりだと思い、以前の状態を消して返事を出す。Aにはその返事の連番が合わず、受け取らない。古い一通で第三者の接続が完成する見込みは低い。だが同じ一通を素早く繰り返せば、Bは状態を消し、返事を待ち、時間切れになる作業を重ねる。経路の話を始める前に、玄関の呼び鈴ばかり鳴る。

追加の問いかけと返事を入れればよいだろうか。Millsは三段階のやり取りを検討し、その費用を重すぎると判断した。攻撃者は追加のやり取り自体にも仕事を発生させられる。さらに、悪意のない二台が同時に瓶へ鍵を求める競走もある。要求が交差すると互いの鍵をリセットし、タイムアウトがずれてようやく先へ進む場合がある。鍵を替える時期と待ち時間が、この話の実際の歯車だった。

RFC 1004は採用済みの規格を告げる文書ではなく、議論のための提案だった。面白いのは、誰が会話を許すかと、誰が会話を止められるかを同じ玄関で示したことだ。瓶は鍵を渡す。古いクッキーは、その玄関でゲートウェイの時間を食べる。