要約

  • NTSは、TLSを使う鍵確立と、その後のNTPパケットを分離する。クライアントが暗号化cookieを返すため、サーバーはクライアント別の状態を保存しなくてよい。
  • サーバーが共有するcookie鍵、方向別のC2S/S2C鍵、要求を結ぶ乱数、cookie補充、時刻源の選択は別の証拠である。「NTS有効」だけでは一つも説明し切れない。
  • Dieter SiboldはRFC 8915の5人の著者の一人であり、現在のIETF記録ではNTPワーキンググループ議長でもある。これは貢献の記録であって、実装や時刻そのものへの支配ではない。

時刻サーバーに、見覚えのないクライアントからパケットが届く。データベースを探しても、そのクライアントのセッション行はない。それでもパケットには、以前の合意を復元できる封印済みの小さな記録が付いている。

Network Time Securityのcookieは、この場面のためにある。Webの閲覧履歴でも、利用者のアカウントでもない。サーバーが作成して暗号化し、クライアントに保管を任せ、必要なときに返してもらう関連状態である。

状態を外へ持たせることで、公開時刻サービスは接続数に比例するセッション表を避けられる。一方で、運用者は「忘れた」という言葉を限定しなければならない。サーバーは個人別状態を忘れても、cookieを開く共有鍵や時刻源まで忘れるわけではない。

最初のTLSは次のNTPの準備である

NTS Key EstablishmentはTCP 4460番で動き、TLSのALPNとしてntske/1を使う。サーバー証明書を検証した後、双方は次に利用するプロトコルとAEADアルゴリズムを選ぶ。応答は、別のNTPサーバーやポートを指定することもできる。

TLS exporterからは、client-to-serverのC2S鍵とserver-to-clientのS2C鍵が別々に導出される。NTS-KEサーバーは最初のcookie群も渡す。その後、要求、応答、TLS接続は終了する。RFC 8915が目指すのは、サーバー側にクライアント固有の状態を残さないことだ。

日常の同期は通常のNTPデータグラムに戻る。48オクテットのNTPヘッダーは暗号化されず、認証対象になる。NTSの拡張フィールドがcookieと要求の識別子、認証情報を運ぶ。

この切断には意味がある。証明書と非対称暗号を使う重い処理を、まれな確立段階に閉じ込める。高頻度の時刻転送は対称鍵で軽く処理する。したがって監査では、TLS成功だけでなく、合意したAEAD、鍵世代、NTP宛先、cookie発行、最初の保護済みNTP応答まで一続きに確認しなければならない。

クライアントは中身を知らない保管者になる

RFCが示す推奨形式では、サーバーはAEAD識別子、S2C鍵、C2S鍵を一つの平文にする。それを別のcookie暗号化鍵で封印し、鍵識別子、nonce、暗号文からなるcookieを作る。

クライアントは内部値を読めない。別のアルゴリズムを選び直したり、自分の鍵を挿入したりもできない。次の要求で同じバイト列を返すだけである。サーバーは鍵識別子から世代を選び、検証と復号に成功すれば関連状態を取り戻す。

ここでいうstatelessは、クライアント別の記録を持たないという意味である。サービス全体は、cookie鍵の世代、設定、クラスタへの配布、参照時刻源を保持する。負荷分散先の一台だけが正しい鍵を受け取っていなければ、その一台は正当なcookieにNAKを返す。

この構造は権限も分ける。クライアントは記録を携帯するが、解釈者ではない。携帯性は中央セッションへの依存を減らすが、サーバーが作った主張をクライアントの主張へ変えない。

一回限りの識別子が返答を要求へ結ぶ

保護された要求には、暗号学的乱数で作ったUnique Identifierが一つ、cookieが一つ、C2S鍵で作った認証フィールドが一つ入る。サーバーは識別子を応答へ写し、S2C鍵で保護する。

クライアントはこの値を見て、応答が今の要求に対応していると判断できる。過去の正しい応答を再投入されても、新しい要求の値とは一致しない。識別子は端末の恒久名ではなく、一回の往復の証人である。

サーバー側は同じ方式で全要求の再送を記録しない。クライアント・サーバーモードでは、サーバーが有効な要求をもう一度処理すること自体は許容される。その代わり、応答を要求より大きくして反射増幅に使わせない設計が重要になる。RFC 8915の対象がNTPモード3と4に限定される理由でもある。

障害ログは、cookie鍵不明、cookie検証失敗、パケット認証失敗、識別子不一致、認証済み測定の選択除外を分けるべきだ。すべてを「NTSエラー」にすると、誰が直すべきか分からなくなる。

空のフィールドが新しいcookieの代金になる

同じcookieを何度も送ると、ネットワークを移動した端末の流量を結び付ける手掛かりになる。そこでサーバーは応答の中で新しいcookieを補う。しかし小さなUDP要求が大きな応答を自由に引き出せると、送信元詐称による増幅へ戻ってしまう。

Cookie Placeholderは、クライアントが要求側で先に確保する空間である。サーバーはその分を新しいcookieに置き換える。RFCの運用指針は、未使用cookieを8個に戻すよう調整し、通常は一回の要求で7個を超えるplaceholderを送らない。断片化の恐れがあればさらに減らす。

空欄は単なる詰め物ではない。応答のバイト数を要求側が前払いしたという証拠である。監視では、cookie残数だけでなく、placeholder数、補充数、cookie長、パケット長、損失を一緒に見る必要がある。8という数字は管理上の指針であり、全実装の絶対条件ではない。

古いcookieの寿命はサーバーの鍵世代が決める

推奨cookie形式そのものに普遍的な期限時刻が入るわけではない。参照する復号鍵をサーバーが保持している間だけ利用できる。RFCは鍵をローテーションし、古い鍵を消して侵害時の影響を狭めつつ、移行に必要な少数の世代を一時的に残す方法を示す。

識別子に対応する鍵がなければ、サーバーはNTS NAKを返す。クライアントはNTS-KEをやり直し、新しい鍵とcookieを得なければならない。鍵を保存しない再起動、クラスタ配布の失敗、急すぎるローテーションは、TLS再確立を一斉に発生させる。

反対に、NTS-KEだけが攻撃や障害で止まっても、利用可能なcookieを持つ既存クライアントはNTPを継続できる。この分離は障害を封じ込めるが、cookie鍵の連続性という新しい共有責任も作る。

chronyの現行文書は、実装例として有用である。authdataは鍵確立回数、AEAD、鍵長、経過時間、再試行、NAK、cookie数と長さを別々に表示する。設定にはcookie鍵の保存やローテーションもある。これはchrony固有の挙動であり、RFCの一律な既定値ではない。

非再利用と継続性は同時に最大化できない

未使用cookieがある間は、同じ値を再利用しない方がよい。移動前後の通信を受動的観測者に結び付けられる可能性を減らせるからだ。

ところがNTS-KEが長く停止すると、新しいcookieを補充できない。一回ずつ消費すれば、やがて認証時刻サービスも止まる。RFC 8915は、継続性を優先する場合に再利用を認める。これは安全か危険かの二択ではなく、リンク可能性と可用性の交換である。

NTSは匿名化技術ではない。時刻サーバー自身は接続元を観察でき、NTS-KEのTLS通信は不可リンク目標の対象外で、NTPヘッダーも公開のままである。運用記録には、再利用の有無、理由、期間、ネットワーク移動、補充回復を残すべきだ。

認証できても、時刻は間違い得る

有効な認証タグは、期待した鍵を持つ相手が保護対象を作り、途中で変更されていないことを示す。サーバーの時計が正しいこと、上流の参照源が健全なこと、クライアントがその測定を採用すべきことは示さない。

RFC 8633が独立性と多様性のある複数時刻源を勧めるのはこのためだ。NTPv4のフィルタリング、交差判定、クラスタリング、ローカル時計のdisciplineはNTSの外側に残る。

遅延攻撃では、経路上の攻撃者が認証済みパケットを改変せず、一方向だけ遅らせる。NTPのオフセット計算は経路の概ね対称な遅延を仮定するため、内容が正しくても測定が偏る。複数経路、複数源、距離上限は対策になるが、認証だけでは防げない。

証明書検証にも初期矛盾がある。証明書の有効期間を判断するには時刻が要るのに、クライアントは時計が不確かだから時刻同期を始める。RFCは、最後に確認した時刻の永続化、電池付き時計、厳格設定、複数源、同期直後の整合確認などを挙げるが、完全解はないとする。

したがって最終証拠には、オフセット、往復遅延、root distance、候補源、採用と除外、システム時計状態、実際の補正が必要である。認証は時刻判断の入口でしかない。

Dieter Siboldの役割は帰属できるが、独占できない

RFC 8915は2020年9月、Daniel Fox Franke、Dieter Sibold、Kristof Teichel、Marcus Dansarie、Ragnar Sundbladの5人を著者として公開された。IETF Standards Track文書であり、公開審査とIETFの合意を経た共同成果である。

現在のIETF DatatrackerはSiboldをNetwork Time Protocolsワーキンググループ議長、Internet Area Directorateのレビュアーとして掲載し、RFC 8633とRFC 8915を結び付ける。ワーキンググループのページはKaren O'Donoghueとともに議長として記載し、NTP、NTS、遅延耐性、次世代仕様の継続作業を示す。

ドイツの国立計量研究所PTBは、現在のインプリントでDr. Dieter Siboldを情報セキュリティ責任者とする。安全なコンピューター時刻同期に関するPTBの公式記事も、NTSの連絡先として氏名を挙げる。

これらは標準化と計量実務の接点を示す。ただし、Siboldが単独でNTSを発明したこと、IETFの結論、chronyの実装、PTBの全サービス、各運用者の方針を支配することは示さない。人物の貢献も、cookieの保管も、権限移転ではない。

秘密を書かずに、状態の連鎖を書く

証跡の第1部はNTS-KEである。相手、証明書チェーン、検証方針、TLSとALPN、プロトコル、AEAD、鍵世代、NTP宛先、初期cookie数を記録する。秘密鍵そのものではなく、安全な世代識別を残す。

第2部はcookie連続性である。封印鍵の世代、在庫、初回利用または再利用、placeholder、補充、NAK、ローテーション、再確立を結ぶ。クラスタでは、どのノードがどの世代を読めなかったかも必要になる。

第3部は各NTP交換で、要求識別子の安全なハッシュ、方向、認証、応答対応、オフセット、遅延、棄却理由を扱う。最後に候補時刻源、選択結果、ローカル時計への補正を残す。

この連鎖があれば、TLS成功、cookie成功、パケット成功、時刻選択成功を混同しない。動くコードを優先するとは、設定名を信じることではなく、実際の遷移を再構成できるようにすることだ。

参照資料