要約

  • NTSで保護する各要求には、暗号学的に安全な乱数生成器が作る32オクテット以上のUnique Identifierを一つだけ入れ、サーバーは同じ値を応答に複写する。
  • クライアントは、その値が未処理の要求と一致し、かつ対応するサーバーからクライアント向け鍵で応答を認証できた場合だけ処理を続ける。
  • この仕組みは再送攻撃の検出と一往復の対応付けに使う。利用者や端末の恒久的な身元でも、NTS Cookieでも、時刻の正しさの証明でもない。

未回答の一通に付ける半券

二つのNTP応答がほぼ同時に届いたとする。片方は直前の要求への答えで、もう片方は以前に正しく作られたパケットを誰かが保存し、再び流したものだ。古い応答も作成時点では本物だったかもしれない。認証タグが正しいという事実だけでは、いま机上にある質問への答えかどうかは分からない。

RFC 8915は、クライアント自身が作る半券を用意した。NTSで保護する要求には、Unique Identifier拡張フィールドを正確に一つ入れる。その本体は暗号学的に安全な乱数生成器の出力で、長さは少なくとも32オクテットでなければならない。サーバーは要求を検証した後、応答にも同フィールドを一つだけ置き、受け取ったオクテット列を完全に同じ形で返す。

受信側の合格条件は二つで一組だ。識別子がまだ未処理の要求に一致すること、そしてその要求に対応するS2C鍵でパケットを認証できること。どちらか一方でも失敗すれば、それ以上処理せず破棄する。過去に本物だった応答が、新しい問い合わせの席に座ることはできない。

このフィールドは暗号化してはならないが、認証しなければならない。認証器の前に置かれ、AEADが完全性を保証する対象に含まれるため、通信を観測する者には値が見えても、別の値へ書き換えて有効な応答を作ることはできない。読めることと改変できることは別の性質である。

したがって「Unique」という名は、範囲を限定すれば正しい。クライアントが一つの未完了要求を他と区別するための値だ。サーバーが与えるアカウント番号でも、長期セッションの名札でもなく、背後の人や機器を指す情報でもない。要求が成立するか期限切れになれば、証拠としての役割も終わる。

時計の値を暗号学的な乱数にしない

従来のNTPにも対応付けはあった。RFC 5905のOrigin Timestampは64ビットで、要求がクライアントを出た時刻を示す。サーバーがそれを返し、クライアントは送信時の状態と照合して、不正、重複、再送されたパケットを退ける。

RFC 8915はこの仕組みを否定せず、暗号学的な挑戦値としての弱点を示した。64ビットは小さく、実装によっては大半のビットを予測できる。時刻印は順序や遅延計算には有用でも、攻撃者に推測されにくい値とは限らない。

そこで新フィールドは仕事を分離する。32オクテット以上の本体を、時計ではなく暗号学的に安全な生成器から得る。これにより、暗号用途に適した予測困難性と衝突耐性を目指せる。ただしRFC 4086が注意するように、出力が256ビット以上あることと、256ビットのエントロピーがあることは同義ではない。種が乏しければ、見かけの乱雑さの裏に小さな探索空間が残る。

RFC 8915は、NTSなしでこのフィールドだけを使い、経路外の攻撃者が偽造したパケットを見分ける用途も認める。NTSの中で得られる強い結論は、二つの検査の組み合わせにある。ランダムな反響はどの要求への応答かを示し、S2C認証はどの暗号コンテキストで作られたかを示す。片方をもう片方の代用品にはできない。

TLS、Cookie、反響を重ねない

最初のNTS-KEはTLS上で動き、サーバーの初期認証、パラメーター交渉、鍵の取り出しを行う。その後TLS接続は閉じる。後続のNTP要求に入るUnique Identifierは証明書ではなく、TLS上の身元を再定義もしない。

NTS Cookieは別の領収書だ。クライアントが以前サーバーから受け取った不透明なCookieを返すと、サーバーはクライアント別の状態を保存せずにAEAD方式と双方向鍵を復元できる。Sofia RenによるDieter Siboldの記事は、このTLS終了後の状態移送を扱った。Cookieは暗号上の関連付けを復元し、Unique Identifierは一つの返答を一つの未完了要求へ戻す。

認証器が三つ目の役割を担う。要求ではCookieと識別子の双方が認証され、暗号化されない。応答では識別子は見えるまま、新しいCookieは暗号化・認証された領域へ入る。この違いを消すと、機密性と持続性と身元が一つの曖昧な概念になってしまう。

プライバシーの評価も同じ境界に従う。長期識別子なら、時間をまたいだ行動を束ねられる。ここでは要求ごとに新しく予測不能な値を使うことが前提だ。再利用、衝突、ログへの無期限保存は監視すべき逸脱だが、標準がクライアント身元を定義した証拠ではない。

本物の返答でも、時計は誤り得る

再送防止は、古い保護済み応答を新しい要求に流用する経路を閉じる。しかし、時刻に関するすべての誤りは閉じない。RFC 7384は、再送、改変、なりすまし、遅延操作、グランドマスターの外部時刻源への攻撃を別々に扱う。サーバーが現在の本物の応答を作っても、参照元が誤っている場合がある。経路遅延も操作され得る。

そのためRFC 8633は、十分な数の時刻源、多様性、食い違いの監視を独立した運用課題としている。一つの時刻源しかなければ、その誤りはそのままクライアントへ届く。Unique Identifierが言えるのは「この保護済み応答は、この未完了要求へのものだ」までであり、「この時刻は正しい」ではない。

出典