要約

  • RFC 5926は、完全準拠の実装にHMAC-SHA-1-96、AES-128-CMAC-96と、それぞれのKDFを求めた。
  • どちらもワイヤ上では96ビットのタグになり、共通の基盤と移行用の別案を提供した。

選択肢だけでは認証できない

TCP-AOは「強い暗号を使う」という抽象的な約束で認証するものではない。送信側は接続に固有のTraffic_Keyを導出し、特定のアルゴリズムでMACを計算する。受信側は同じ導出と計算を再現しなければならない。組み合わせが違えば、受信したタグは別の正しい解釈ではなく、検証不能な値になる。

そこでRFC 5926は、選択の自由に必須の下限を組み合わせた。準拠実装はHMAC-SHA-1-96、AES-128-CMAC-96、KDF_HMAC_SHA1、KDF_AES_128_CMACを実装しなければならない。これは一つの接続で二つを同時に使うという意味でも、TCP上でアルゴリズムをインバンド交渉するという意味でもない。独立に作られたシステムが、整合するよう設定できる共通の選択肢を持つという意味である。

MACの名前だけでも契約は完成しない。KDFは設定済みのMaster_Key、接続固有のContext、要求された出力長を受け取り、TCPセグメント用のTraffic_Keyを作る。各MACは対応するKDFを示しており、KDFが複数のMACに使われることはあっても、鍵導出の方法を未定義にはできない。

二つのプリミティブと限られたオプション領域

HMAC-SHA-1-96は160ビットのTraffic_KeyとHMAC-SHA1の出力を使う。AES-128-CMAC-96は128ビットのTraffic_KeyとAES-CMACを使う。いずれもTCP-AOオプションに載せる値は96ビットに切り詰められる。この長さは認証強度とTCPオプションの限られた領域との折衷であり、基礎となるプリミティブの出力が96ビットだけになることを意味しない。

2010年の公開時点では、HMAC-SHA1は広く実装されていたため、ユーザーインターフェースの既定値として推奨された。AES-128-CMACは、異なる代替手段とSHA-1依存からの移行路として必須とされた。これは当時の説明であり、現在の推奨ではない。

AES-CMAC KDFは、16オクテットに限らない長さのマスターキーも受け付ける。入力が正確に16オクテットでなければ128ビットの鍵を導出するが、この利便性によって弱い、または予測可能な鍵が安全になるわけではない。

基盤が決めたこと、決めなかったこと

四つの必須コンポーネントは、準拠ソフトウェアに共通の足場を与えた。ただし、設定の食い違いを自動修正するものではない。両端には同じ選択と共有秘密が必要であり、手動鍵管理モデルではその調整はTCP交換の外に残った。

RFCは将来のMACとKDFのためのインターフェースも示し、衝突確率を低く保つためのメッセージ数に関する目標を置いた。これは拡張の境界であって、自動選択やインバンド交渉の証拠ではない。

出典