要約

  • LTP Cookie はセッション内で変化する。長い拡張値が受理されると短い旧値は無効になり、再送セグメントは再送時点の値を使わなければならない。
  • Cookie は無差別な資源攻撃を難しくするが、更新者の本人性を示さない。AuthVal がセグメントを検証しても、鍵配布、KeyID の意味、鍵の廃止は仕様外である。

保存したパケットは保存した判断ではない

最初のセグメントが正しい Cookie とともに送られた後、相手が値へ新しい乱数を付加したとする。応答を待つ間にタイマーが切れ、送信側は保存済みパケットを取り出す。

ここで完全な再現は正しくない。RFC 5327 は、再送時点で正しい Cookie を付けるよう求める。元送信時に正しかった値とは異なる場合がある。論理データは同じでも、セキュリティ上の行為は新しい。

監査には payload のハッシュと、拡張を含む符号化セグメントのハッシュが別々に必要だ。各試行に Cookie 世代、再送理由、接触機会、受信判断を結び付ける。

旧パケットが黙って捨てられても、破損とは限らない。かつて有効だった短い値が、正当な状態遷移によって無効になった可能性がある。

Cookie の判定は時刻付き前方一致である

どちらのエンジンもセッション途中で Cookie を導入できる。相手へ伝わるまでの許容時間が過ぎた後は、双方向の全セグメントが良い値を持たなければならない。それ以前には、更新を知り得ない飛行中セグメントを扱う猶予がある。

猶予は実装が決める。片道伝搬時間、接触計画、リンクへの引き渡し、ローカル方針が判定を形作る。同じ欠落でも時刻によって結果が変わる。

Cookie は末尾へ乱数を連結して延長できる。保存値で始まる値、またはまだ何も見ていないときの初期値が良い。拡張を受理すると短い前値は良くない。複数の有効 token を並べる方式ではなく、単調な前方一致の鎖である。

前値、新値の保護指紋、観測者、受信時刻、発効時刻、最初の強制利用を残さなければ、猶予判断を再現できない。

二つの初期値が同時に生まれる場合

長い遅延のため、双方が相手の Cookie を見る前に自分の初期値を送ることがある。その後のセグメントには二つの Cookie 拡張が必要になり、双方を独立に検査する。

相手の初期値が認められる時間には限りがある。ローカル値が全トラフィックに反映されるはずの期限を過ぎてから、未知値を第二の初期根として無期限に追加することはできない。

この状態は一つの current_cookie では表せない。方向別の二つの鎖、二つの期限、拡張の順序と個別結果が必要だ。

同一タグの重複を map に変換すると、受理を決めた項目や失敗した項目を上書きする。生の多重性を先に保存すべきである。

応答がないことは拒否理由ではない

猶予後に Cookie が欠ける、または間違うと、受信側は黙って破棄する。攻撃者への仕事を減らす設計だが、送信側にはタイムアウトしか見えない。

原因は旧値、更新の欠落、猶予計算ミス、二重フィールド不正、AuthVal 不成立、未対応拡張、資源制限、接触不成立のいずれでもあり得る。沈黙は原因を一つに絞らない。

受信側ログも、自分の保存前方一致に失敗したとだけ言える。それだけで相手の悪意、リンクの再生、運用者の過失を断定できない。

両側の状態遷移、期限、再符号化ハッシュ、破棄分類、認証結果、接触履歴を合わせて初めて説明が成立する。

Cookie 更新者は Cookie では分からない

推測困難な値は盲目的な注入を難しくする。しかし誰が末尾を追加したかは証明しない。RFC 5327 は、送信元認証がないと中間者が Cookie を延長し、正規の相手を締め出せると警告する。

受信側は偽の長い値を受理した後、規則どおりに正規の短い値を拒否する。状態機械の故障ではなく、権限のない入力を正しく実行した結果だ。

Cookie は現在セッション状態との整合を、AuthVal は選択した暗号文脈での符号化セグメントを確認する。どちらも上位アプリの承認、Bundle 配送、組織本人性を証明しない。

Cookie はセッションを越えて存続しない。再起動や別セッションをまたぐ耐再生台帳ではない。

認証成功だけでは鍵移行を判定できない

LTP-auth は 8 ビットの暗号スイート、任意の生バイト KeyID、トレーラーの AuthVal を使う。KeyID の解釈は仕様外であり、鍵の配布・有効化・撤去も扱わない。

認証セッションの最初のセグメントにはヘッダーが必須で、その後は省略できる。最初が失われる問題を減らすため、帯域が許せば繰り返す。最初のセグメントの再送には再び必要だ。

鍵更新では新旧複数の AuthVal を付けられる。受信側は検索し、一つでも正しければ受理できる。可用性は保てるが、valid だけではどちらの鍵が働いたか分からない。

旧鍵が残れば、新鍵が一度も成功しなくても全体は緑になる。成功した AuthVal、スイート、KeyID、検証文脈、外部認可状態を個別に記録する。重複期間中の一候補失敗を直ちに攻撃扱いするのも誤りだ。

割当番号は安全性の認定ではない

RFC は HMAC-SHA1-80、RSA-SHA256、NULL を定義した。NULL は固定鍵を使い、強いチェックサムにはなるが認証ではなく、能動攻撃を防がない。検算成功は本人性ではない。

IANA 登録簿は番号の割当を示すだけで、現在の推奨、採用、鍵管理を証明しない。RFC 5327 は Experimental で、DTN の鍵管理を未解決の研究課題として残した。現代の利用には別の評価が要る。

出典と証拠の限界

以上は規則、割当、公開位置付けを示す。現在の導入、設定鍵、攻撃、会話履歴、実装適合、アプリ結果は立証しない。