要約

  • NTSはNTS-KEの相手を識別し、NTP応答が未完了の要求に対応することを認証できる。サーバー時計の正確さ、経路遅延の対称性、採用すべき時刻源、端末時計をステップさせる権限までは証明しない。
  • 説明可能な時刻変更には、身元と鍵確立、パケット認証、時刻源の適格性と選択、時計規律と実行という四つの記録が要る。一つの「安全」表示にまとめると、機械を動かした判断主体が見えなくなる。

二つの正しい認証から、一つの時刻は出ない

冒頭の場面は実事故ではなく、制御境界を示すための思考実験である。時刻源AとBは別々の有効な証明書を示し、NTS-KEは双方で成功する。cookieと鍵材料が渡され、その後のNTP応答はサーバーからクライアント向けの鍵で検証される。未完了要求の一意識別子も一致し、リプレイでもない。それでも、Aはほぼ修正不要、Bは800ミリ秒の修正を示す。

暗号の故障とは限らない。Bの上流参照が誤っているかもしれず、どちらかの経路に非対称な待ち時間があるかもしれない。同期距離がローカル上限を超えた可能性も、他の候補と多数派の交差区間を作れない可能性もある。

したがってクライアントは、Aを選ぶ、他の証拠とともにBを選ぶ、整合する複数源を合成する、あるいは同期しないという判断を残している。証拠が足りないとき時計を動かさないことは、プロトコルの敗北ではなく権限の適切な行使だ。

NTSが保証する命題

RFC 8915はNTSを二段に分ける。NTS Key EstablishmentはTLS上で行い、その後の時刻転送はNTPクライアント・サーバーモードの拡張フィールドを使う。比較的重い身元確認と鍵交換を先に終え、頻繁な測定は軽量に保てる。

NTS-KEはTCP 4460、TLS 1.3以降、ALPN識別子ntske/1を使う。サーバーは後段のNTPエンドポイントを示し、認証付き暗号方式を合意し、複数の不透明なcookieを渡せる。TLS exporterはクライアントからサーバー、サーバーからクライアントの方向別鍵を導出する。TLS接続が閉じれば、サーバーはクライアント固有の状態を保持しなくてもよい。

クライアントは状態をcookieに入れて返し、一意識別子と認証フィールドも要求に含める。応答はサーバーからクライアント向け鍵で検証でき、待機中の要求に属する識別子を反映しなければならない。新しいcookieを保護領域で返すことで、サーバー側の個別状態を増やさず補充と非連結性を両立する。

ここで成立する命題は限定的である。受理された応答はNTS鍵に結びつく相手が生成し、途中で改変されず、実在する要求への返答だった。相手の発振器や上流時刻、UTC値の正しさまでは含まれない。

IANAはUnique Identifier、NTS Cookie、Cookie Placeholder、Authenticator and Encrypted Extension Fieldsに共通の型値を登録する。これは実装間の文法を共有する仕事であり、時計品質の認定ではない。

身元と精度を混同しない

証明書が確認するのはNTS-KEサービスの身元であって、背後の時計ではない。cookieは認証用パラメータを復元する仕組みで、UTCの証明書ではない。一意識別子は要求と応答を結ぶが、往復経路の対称性を測らない。

RFC 8915の遅延攻撃はこの限界を明確にする。経路上の攻撃者は内容を変更も並べ替えもせず、片方向だけを余計に遅らせられる。暗号検証が全部成功しても、算出オフセットは誤る。操作された対象が保護された内容ではなく伝送時間だからだ。最大距離の方針は誤差を制限し、複数の時刻源や経路は一部だけが支配された場合の耐性を高めるが、認証を真実そのものにはしない。

機密性の範囲も狭い。基本NTPヘッダーは平文で、NTSが暗号化できるのは拡張フィールドである。可用性も別問題で、経路上の主体はパケットを落とせる。一部のKiss-o’-Death応答は認証されない。

NTS-KE失敗時に自動で平文NTPへ戻るべきでない理由も同じだ。攻撃者が鍵確立を妨げるだけで保護を剥がせてしまう。ダウングレードは明示的なローカル判断でなければならない。

起動時点ですでに信頼を選んでいる

X.509証明書には有効期間がある。自分の時計を信用できない端末がネットワーク時刻を求める一方、そのサービスを検証するにはおおよその時刻が要る。この循環に万能な解答はない。

RFC 8915は、バッテリー保持時計、手動の概算、永続化した最終時刻、複数源の比較を挙げる。NTS-KE直後の時刻が証明書期間と整合するか確認する方法もある。どれも正確なUTCを与えるのではなく、身元確認を開始できる妥当な窓を作る。

最初の認証済み測定より前に、運用者はすでに決めている。どの信頼ルートを採用するか、保存時刻の古さをどこまで許すか、証明書の時刻検査を緩和できる条件は何か、何源の一致で時計変更を許すか。文書化しなければ判断が消えるのではなく、初期設定が組織の代わりに決める。

パケット受理のあとに選択が始まる

RFC 5905の処理はクライアント内に段階を残す。パケット処理が測定を作り、clock filterが各関連の雑音を減らす。selectionは信頼できる候補の多数派交差区間を探し、clusterは外れ値を除き、combineが最終オフセットを作る。clock disciplineがそこで初めて位相と周波数の制御を行う。

NTSが強くするのは入口である。偽造やリプレイを測定になる前に排除するが、後段を置き換えない。認証済みの時刻源もfalsetickerになり得る。正しく認証された測定も、遅延やroot distanceが過大なら使えない。生き残る候補が足りなければ、未同期のままにできる。

現行chrony文書も証拠面を分離する。authdataは認証方式、鍵確立回数、試行、否定応答、cookie残数を示す。別の報告が到達性、合意、選択状態を示す。maxdelayと関連検査は遅すぎる測定を落とし、minsourcesは必要数の候補がそろうまで時計更新を止める。trustとrequireは認証済み・未認証の時刻源を選択にどう参加させるかを決める。

NTPsecにも証明書、NTSクライアントとサーバー、cookie鍵保存の運用制御がある。実装差は相互運用の失敗ではなく、共通規則の外側に残されたローカル方針を示す。

四つの証拠を残す

身元の証拠は設定したNTS-KE名、受理した証明書チェーンとサービス名、信頼集合、鍵確立時刻を含む。

パケットの証拠は鍵世代、一意識別子、cookie状態、認証器、対応する要求、リプレイやNTS否定応答による状態変化を含む。

測定の証拠はオフセット、遅延、分散、root distance、到達性、履歴、交差区間、外れ値判定を含む。本物の相手から来たパケットがここで不適格になり得る。

実行の証拠は選んだ時刻源または組み合わせ、slewやstepを許したしきい値、実行プロセス、変更前の時計状態を含む。これが機械に対する権限の記録である。

「NTS有効」だけでは、安全機構を使ったことしか分からず、時計が動いた理由を説明できない。

最小共通規則とローカルな決定

Heng LuのMinimum Initial Specificationは、共通層を相互運用、安全、ローカル検証に必要な決定的規則へ限定する。後の選択はコードを動かす参加者に残る。文書の公開は運用上の採用ではなく、共通文法は永続的な命令権を生まない。

この読み方ならNTSの役割は明快だ。IETFは交渉、鍵導出、cookie、保護フィールドの検証を定義し、IANAは共通番号を記録する。認証局はエンドポイントの身元確認に関与する。しかし、クライアントの時刻源一覧、最大距離、起動時刻の許容範囲、OS時計を変える許可は決めない。

Running-Code Primacyが加える試験は、独立した実装が同じ性質をローカルに検証できるかである。クライアントはパケットを受理しても測定を拒否でき、相手の身元を信頼してもstepを禁止できる。その分離こそ安全設計だ。

根拠と範囲

800ミリ秒の差は説明用で、実在の事業者、障害、事件、攻撃を指さない。固定した出典：