要約

  • AES-XCBC-MAC-96は128ビットの結果の左端96ビットをIPsec認証値として送る。RFC 3664はIKEのPRF出力として128ビット全体を使う。
  • RFC 4434はその出力と128ビット鍵の場合の結果を保ちながら、鍵長を一種類に限定する条件を外した。IKEv2では鍵生成に固定長の扱いを、共有鍵による認証には可変長の扱いを適用する。

混同できない三つの長さ

この経緯で「128ビット」が指すものは一つではない。RFC 3566は128ビットのAES-XCBC値を計算し、その左端96ビットだけをESPまたはAHの認証フィールドに載せる。受信側は全体を再計算して同じ96ビットを照合する。短くしたフィールドはパケット認証用であり、構成要素の出力全体ではない。RFC 3566

IKEには別の要件がある。疑似乱数関数（PRF）の出力は鍵の生成に使われるため、RFC 3664は96ビットのPRF出力ではIKEv1/IKEv2の長期利用に短すぎると論じた。変更は限定的で、AES-XCBCの最後の切り詰め処理を省く。その結果、PRFの出力は128ビットになる。これはIKEが派生する鍵すべてが128ビットだという意味ではない。出力はプロトコル固有の鍵導出に渡される。RFC 3664

RFC 3664はAES-XCBC-MAC-96からもう一つ制約を引き継いだ。鍵は正確に128ビットでなければならない。出力は全幅でも、入力鍵は固定長だった。別の長さを持つIKE共有鍵には窮屈な条件である。後の文書は128ビット鍵の結果を変えず、AES演算前に入力をどう正規化するかを明記した。RFC 3664情報・正誤表 RFC 3664正誤表

2006年の修正は入力側にあった

RFC 4434は、鍵長が正確に128ビットであるという制限を取り除く。128ビット鍵はそのまま使う。短い鍵は右側にゼロビットを足して128ビットにする。129ビット以上なら、128ビットの全ゼロ鍵でPRFを再実行し、長すぎる鍵をメッセージとして渡す。その出力が正規化後の鍵になる。これは単純な切り捨てでも、汎用ハッシュでもない。RFC 4434

「同じアルゴリズム」という言い方では、プロトコル上の結果と実装が受け入れる入力という二つの問いが隠れる。RFC 4434によると、128ビット鍵ならRFC 3664と同じビット列が得られる。ほかの長さは拒否せず、128ビットのAES鍵へ変換する。出力は完全な128ビットXCBC値のままであり、ESP/AHの96ビット認証フィールドではない。RFC 4434情報・正誤表 RFC 4434正誤表

IKEv2ではPRFに二つの役割がある

後継文書はIKEv2内の用途も区別する。鍵材料の生成では、AES-XCBC-PRF-128を固定長PRFとして扱い、IKEv2の手順に沿って両側のnonceの寄与を分ける。一方、共有鍵の認証では可変長として扱うため、共有鍵自体は128ビットでなくてもよい。RFC 4434は、この少し複雑な規則の狙いを、RFC 3664の固定長解釈を使う実装と柔軟な解釈を使う実装の相互運用に置いている。RFC 4306 RFC 4434

これはインターフェース契約の改訂であり、特定実装の障害や広範な導入を示す証拠ではない。RFC 4434は全幅出力と128ビット鍵時の結果を保ち、短い鍵・長い鍵の変換を明記した。後年のRFC 8221はESP/AHのアルゴリズム推奨であり、IKEのPRF交渉や個々の実装を証明するものではない。RFC 8221

この標準化史の要点は処理を分けて読むことにある。パケット用にMACを切り詰め、IKEのPRFでは全幅を残し、用途に応じて入力鍵を正規化する。

出典