要約

  • RFC 3594 が変更するのは client device の local persistent ticket である。server 側の失効、memory 上の copy、既存 SA、新しい認証、通話結果まで同時に変更したとは言えない。
  • reboot と ticket 消去が同じ時刻に集まると、正しい端末要求でも KDC と application server に集中する。cohort、jitter、停止条件は security change の一部である。

一台ずつ見れば、どの端末も正常に動いている。DHCP を受け取り、ticket を無効にし、必要になったので KDC に要求する。それでも全体は停止できる。端末ごとに独立していた時刻が、中央の保守命令で同じ時刻に変わるからだ。

2003 年 9 月の Standards Track 文書 RFC 3594 は、DHCP CableLabs Client Configuration option に Security Ticket Control sub-option 9 を加えた。形式は code 9、length 2、network byte order の 16-bit mask である。短い wire format が示すのは、協調規則を小さく保つことと、その後の運用判断を別に持つことの重要性だ。

bit は対象を選ぶが、結果までは運ばない

bit 0 は device が使う PacketCable Provisioning Server の ticket を選ぶ。bit 1 は device が使うすべての Call Management Server ticket 群を選ぶ。bit 2 から 15 は reserved で送信時に 0 でなければならない。

1 の bit は対応する locally persisted ticket の即時無効化を命じる。0 は通常の invalidation rule に任せる。0 は「全 server で有効」という肯定証明ではない。期限、key version、local replacement、そのほかの状態によって使えない場合は残る。

対象の違いは rollout 設計に直結する。Provisioning Server の一枚と CMS 群の ticket は、後続要求の数も依存先も異なる。mask を単なる on/off に正規化すると、capacity model の入力を失う。

さらに、ticket を local に保存しない device は sub-option を無視しなければならない。device が知らない bit も無視する。同じ DHCP payload が届いても、正しい postcondition は同じとは限らない。wire receipt、parser receipt、storage receipt を分ける理由である。

永続化は reboot 時の負荷を先払いしていた

PacketCable では、有効な Kerberos ticket を persistent storage に持てば reboot 後に再利用できる。PKINIT を使う場合は public-key operation を避けられる。後の CableLabs security specification は、MTA が Provisioning Server ticket と必要数の CMS ticket を保持する要件を詳しく示す。

したがって ticket cache は単なる高速化ではない。reboot 後の shared infrastructure に到着する作業を減らし、時刻を分散させる仕組みでもある。cache を全端末から同時に外すことは、その節約を同時に期限切れにすることだ。

RFC 3594 の security section は、多数の MTA が reset または power cycle され、malicious DHCP server に全 ticket を invalid にされ、同時に authentication と ticket acquisition を始めると DoS になり得ると述べる。暗号が破られなくても、正当な処理の同期だけで障害は起きる。

通常の service key rotation について、後の CableLabs 文書は古い有効 key を ticket lifetime 以上保持し、多数の MTA が突然 PKINIT request で KDC を flood するのを避ける。ここでは互換期間が capacity control になっている。厳格な即時切替が常に安全とは限らない。

ticket、SA、service は別の時計を持つ

RFC 3594 が直接触るのは nonvolatile storage の ticket copy である。KDC response、AP exchange、SA identifier、application result は mask に含まれない。local ticket を消しても server の service key が消えたことにはならず、すでにある in-memory state や live security association の消滅も証明しない。

後の一次資料は、新しい ticket を取得する exchange が既存 security parameter に影響を与えずに終わり得ると説明する。ticket は次の phase の材料だが、phase の完了 receipt ではない。

運用画面には少なくとも四つの独立 status が必要だ。persistent ticket invalidated、replacement ticket obtained、association rebuilt、service verified である。最初だけ緑なら、残り三つは unknown のままにする。後段が失敗しても前段の成功を改ざんしない。

rollback も一つの flag ではできない。消した ticket を UI の状態変更で戻すことはできず、取得、association、application canary を順にやり直す必要がある。retry がすでに shared queue に入ったなら、その影響も消えない。

CMTS の境界は仮定として記録する

RFC は malicious DHCP scenario を described cable architecture では unlikely と評価する。正しく設定された CMTS は request を指定 DHCP server にだけ forward し、downstream DHCP を指定 source address からだけ許すからだ。ただし CMTS の内側にいる spoofed server までは防げず、その領域は provider によって厳しく管理されると仮定する。

これは現在の network に対する測定結果ではない。authoritative server、relay、CMTS policy version、source filter と client transaction match をその都度保存する必要がある。RFC 3118 の DHCP message authentication も別の control であり、標準化された事実は利用証明にならない。

IANA registry の sub-option 9 は syntax の割当を証明する。device support、delivery、parsing、storage mutation、KDC capacity は何も証明しない。

証拠の境界

本 Article は operator、MTA model、CMTS、DHCP product、KDC、CMS、subscriber、call、incident、deployment rate を特定しない。Standards Track は実装証拠ではない。

RFC 3495 は親 option、RFC 2131 は DHCP、RFC 3118 は別の authentication を扱う。RFC 1510 は当時参照された Kerberos、RFC 4120 は後継である。RFC 3634 は別の CableLabs sub-option を定義する。RFC 2434 と RFC 8126 は registry policy の歴史と現在を示す。2005 年の CableLabs specification は後の一次 context であり、RFC 3594 の意味を過去に向けて広げない。

Heng Lu の running code と minimum initial specification に関する論考は、公開した editorial lens としてだけ用いる。宣言より実行結果を観測し、共有 rule を local policy にまで膨らませないという問いを与えるが、author intent や deployment fact ではない。

結論は一段だけでよい。local persistent ticket が無効になった。その後の credential、association、capacity、service は、それぞれの receipt を待つ。

Sources