要約

  • draft-ietf-kitten-sasl-ht-02 は、短命な共有トークンを使う二メッセージの SASL 再認証方式を提案する。開始側と応答側は、役割、チャネルバインディング入力、任意の値に対して別々の HMAC を計算する。
  • revision 02 は KITTEN 作業部会の active Internet-Draft で、WG Last Call 中、Proposed Standard を意図し、2026 年 12 月 24 日に期限を迎える。RFC、実装報告、配備実績ではない。
  • 開始メッセージは TLS 1.3 の 0-RTT に置けるが、他のアプリケーション payload を一緒に送ってはならない。早期データがリプレイされ得ることが、その境界の理由である。
  • 正しい再認証証明と、トークン使用の原子的予約、失効の収束、現在の認可、セッション世代、非冪等操作、最終結果は、それぞれ独立した受領証を必要とする。

早く届くことと、一度だけ起きることは別である

再接続で往復を減らす価値は明確だ。クライアントは先に強い SASL 方式で認証し、短命な HT トークンを得る。接続が切れた後、その秘密を知ることを HMAC で示せば、最初の認証をすべて繰り返さずに済む。

草案はさらに、開始メッセージを TLS 1.3 early data に含めることを認める。その場合、SASL profile に必要な framing 以外の application payload を入れてはならず、応答側は追加 payload を見つけたら認証を中止しなければならない。

この禁止は細部ではない。early data は別の主体にリプレイされ得るため、そこに置く操作は冪等でなければならない。HT の証明をもう一度評価することと、支払い、削除、鍵更新、管理設定をもう一度実行することは同じではない。

したがって受信ログの HMAC valid を exactly-once の証拠にしてはならない。サーバはトークンの使用を予約し、再送とリプレイを分類し、現在の認可を行い、その後で初めて非冪等な処理を受け入れる必要がある。

トークンが一回限りかどうかは共有状態が決める

草案の例では、サービスは成功後に使ったトークンを失効させる。規範部分は、application-specific extension が rotation や revocation を提供すること、トークンが時間または使用回数で有限の寿命を持つことを推奨する。

しかし HMAC は失効トランザクションではない。二つの front end が同じ未使用レコードを読み、同時に正しい証明を受け取れば、どちらも数学的には成功できる。片方の書き込みが他方へ届くまでの間、single-use というラベルと実行状態は分かれる。

運用設計は、検証前に予約するのか、応答作成後に消費するのか、障害時に予約を戻すのか、地域間 partition で拒否するのかを決める必要がある。事前予約は失敗した試行でもトークンを焼く可能性がある。事後消費は二重成功の窓を作る。正解は後続効果の不可逆性に依存する。

証拠として残すべきなのは、秘密そのものではなく、token record ID、発行 epoch、利用上限、予約 ID、最初の決定、失効 commit、replica の確認範囲、再試行の分類である。「短命」には時計が、「一回」には共有 counter が必要だ。

開始側と応答側は異なる証明を持つ

開始側 HMAC は文字列 Initiator、選択された channel-binding data、開始側の追加値を含む。応答側は受け取った値を再計算し、一致すれば開始側を認証する。不一致なら失敗しなければならない。

成功応答には、応答側の追加値と Responder を使う別の HMAC がある。クライアントは mutual authentication を成立させるためにそれを検証しなければならない。役割を分けることで、一方向の authenticator を他方向へ流用しにくくする。

サーバ側の成功記録だけでは、クライアントが応答を受信し、検証したとは言えない。応答送信直後に接続が落ちれば、サーバは成功、クライアントは結果不明となる。次の試行でトークンがすでに消費されていれば、その不一致を障害ではなく状態として説明できなければならない。

受領証は、開始メッセージ受信、比較、予約、応答生成、送信、クライアントの後続進行、消費 commit を分ける。二メッセージ方式だからといって、観測も二行で足りるわけではない。

channel binding を選ばない方式も定義されている

方式名は hash と ENDP、UNIQ、EXPR、NONE のいずれかを組み合わせる。NONE では binding data は空である。そこで HMAC が成功しても、tls-exporter や endpoint に結び付いたという証拠は生まれない。

policy が EXPR を要求するなら、NONE の成功は cryptographic success と policy failure の組み合わせである。監視は完全な mechanism name、TLS peer identity、binding type、入力の安全な digest または明示的な欠落を保存しなければならない。

トークン発行時の mechanism pin も別の制御である。草案は要求時に利用予定方式を伝えられることを推奨し、異なる方式で使われた token は失敗させる。すべての verifier が発行記録の pin を参照しなければ、この防御は成立しない。

認証された追加値は policy ではない

両メッセージは任意の key/value を持てる。それらは HMAC 入力に含まれるので、改変検出と送信主体への帰属が可能になる。downgrade protection hash のような context を同時に運ぶ用途は合理的である。

だが integrity は意味を定義しない。未知 key、型、重複、version、組み合わせ、最大長、その identity が値を主張できるかどうかは application が決める。role=admin が真正に送られたことは、admin role が与えられたことではない。

schema version、許可 key、raw octet の digest、解析結果、policy decision、実際の state transition を別に記録する必要がある。認証は判断材料を信用できる形にするが、判断権を譲渡しない。

発行の強さは現在の権限を凍結しない

extension は新しい token を暗号学的安全な乱数生成器で作り、少なくとも 128 bit の entropy を持たせなければならない。草案は定期的に HT token を使わない強い SASL 認証へ戻ることも推奨する。

entropy は推測耐性であって、発行 authority、subject、service、session lineage、現在の role の証明ではない。権限が発行後に取り消されても、token の HMAC は依然として正しくなり得る。authorization は現在の account state を見る必要がある。

また token は salt を使わず一回の hash iteration なので、password のような長期共有秘密の保護には不適切だと草案自身が述べる。再認証の利便性を理由に token store を永続的な credential root へ変えてはならない。

セッション復元は application の状態遷移である

SASL-HT が証明するのは token possession である。queue cursor、document generation、subscription、lock、未完了 transaction は自動的に HMAC に入らない。previous session という語を、どの状態 object に結び付けるかは application extension が決める。

再開するなら session ID、predecessor generation、target generation、conflict policy、restored-state hash を残すべきだ。該当世代がなければ、fresh session を作る、拒否する、full authentication を要求するという選択肢を明示する。identity success を state recovery success に書き換えない。

最終 receipt は層を保つ。token が所定 mechanism と binding の下で検証された。mutual proof が完了した。利用状態が所定範囲で commit した。current policy が所定 session transition を許可した。application が所定 result を生んだ。前の文だけが分かるなら、後ろの文は報告しない。

出典