要約

  • RFC 2403とRFC 2404は、計算したHMACの先頭96ビットをESPまたはAHに格納する一方、全体の出力長と必須の鍵長は異なる。
  • 後のESP/AH実装要件は両変換を分けた。RFC 8221はHMAC-MD5-96をMUST NOT、HMAC-SHA1-96をMUST-とする。同じタグ長から同じ安全性評価が導かれたわけではない。

一つのフィールド、二つの構成

1998年11月、RFC 2403とRFC 2404はIPsecのEncapsulating Security Payload（ESP）とAuthentication Header（AH）で用いる鍵付き認証変換を定めた。一方はHMACとMD5を組み合わせ、もう一方はHMACとSHA-1を組み合わせる。秘密鍵が通信当事者だけに共有されることを前提に、いずれもデータの送信元認証と完全性を提供する。どちらの変換も、それ自体では機密性を与えない。

パケット上で見える数字は共通していた。96ビットである。RFC 2403のHMAC-MD5全体は128ビット、RFC 2404のHMAC-SHA-1全体は160ビットだった。どちらも送信側は先頭96ビットを認証フィールドに格納し、受信側は完全なHMACを計算して先頭96ビットを照合する。この長さはAHの既定値に合わせ、異なる構成に共通のワイヤ上の幅を与えた。完全なダイジェストが96ビットのハッシュに変わったわけではない。

鍵の規則も異なる。RFC 2403は128ビットのHMAC鍵を、RFC 2404は160ビットの鍵を必須とする。同じ長さのフィールドでも、全体の出力と固定鍵長は違う。ネゴシエートされた変換の識別と鍵管理は引き続き重要であり、目に見えるタグのビットだけでは仕組み全体を説明できない。

衝突耐性だけではHMACの問いに答えられない

1998年の文書は、鍵なしハッシュの衝突をHMACの即時破綻と同一視しなかった。RFC 2403は、MD5ベースの署名に比べるとHMACはMD5の強い衝突耐性への依存が小さいと説明し、当時HMAC-MD5-96への実用的攻撃は知られていないと記した。RFC 2404もHMAC-SHA-1-96について、同じく当時の評価を記録している。これは将来にわたる保証ではない。

実装要件の変遷は、タグ長ではなく評価が変わった様子を示す。2005年のRFC 4305はHMAC-SHA1-96をMUST、HMAC-MD5-96をMAYとした。2007年のRFC 4835もその区別を保ち、当時知られていた衝突の弱点はHMACとの組み合わせには影響しないはずだと注記した。2014年のRFC 7321はHMAC-MD5への理論的結果に触れながらも、実用的な脆弱性は明らかでなく、既存プロトコルから直ちに外す必要はないとした。SHA-1の衝突耐性が崩れても、HMAC-SHA-1は安全だとの見方を維持した。

2017年公開のRFC 8221は、ESP/AHの実装要件をより明確に分けた。HMAC-MD5-96はMUST NOTとなり、HMAC-SHA1-96はMUSTからMUST-に下がった。前者の禁止はMD5が既知の衝突脆弱性を持つことを根拠とし、後者の格下げは業界全体にSHA-1の利用をやめる流れがあることに結び付けられた。96ビットのフィールドが変わったという意味でも、RFC 2404が別のタグを定義し直したという意味でもない。

ステータス表は通信記録ではない

後年のRFC 9395はRFC 8221を更新し、IKEv2変換レジストリを変更した。そこにはAUTH_HMAC_MD5_96という項目があり、DEPRECATEDとされている。このレジストリはRFC 8221のESP/AH実装要件表とは別物だ。同じように見える名前が隣接するIPsec文脈に現れるため、ステータスには必ず対象プロトコルと文書の範囲を添える必要がある。

これらの文書が記録するのは、プロトコルのパラメーターと時点付きの実装推奨である。導入済み機器の数、HMAC-MD5で最後にネゴシエートされたSA、全ネットワーク共通の終了日を示すものではない。運用者は、使用プロトコル、変換ID、両ピアの能力、インストール済みSA、観測したトラフィックを区別して確認する必要がある。96ビットタグは証拠の一部にすぎない。

出典