要約

  • draft-smyslov-ipsecme-ikev2-psp-02 は、Child SAを持たないIKEv2 SAで相互認証を終えた後、変更版CREATE_CHILD_SAの両方向Key DownloadでPSP鍵を渡す手順を提案する。
  • 各エンドポイントが送るのは、自分が受信するときに相手が使う鍵である。応答はSPI、selector、PSP parameter、wrapped keyを結びつけるが、相手側NICへの設定や実パケットのICV成功までは証明しない。
  • PSPには派生鍵単位の失効機構がなく、replay protectionも別レイヤーに委ねる。SA切替、二段階のマスター鍵rotation、replay判定、アプリ到達には独立した受領証が必要である。

「渡した」と「使われた」の間にはローカルな空白がある

受信側Bは自分のNICにあるマスター鍵を知っている。BはSPIを選び、それに対応する鍵をAへ安全に渡す。Aは受け取った鍵を送信パスへ設定し、B向けのパケットをPSPで保護する。Bはパケット内のSPIから同じ鍵を導出して認証・復号する。

ここには三つの異なる動詞がある。Bが生成して渡す。Aがインストールして送る。Bが再導出して検証する。制御プレーンの応答が確認できるのは第一の動詞までである。Aのデバイスキューが詰まっている、対象NICを取り違えた、送信classifierが別経路を選んだ、といった事実は応答の外に残る。

現在の draft-smyslov-ipsecme-ikev2-psp-02 は、この鍵供給方法を定義する。HTML と XML も同じ範囲であり、NIC設定の受領証は追加しない。Security Considerationsは依然として「To be added」である。そこから先の安全性を記事側で補完してはならない。

PSPの受信スケールは受信側の権限を強める

PSP Architecture Specification は、受信NICがSAごとの鍵を保存しない設計を説明する。NICは二つの256-bitマスター鍵を持つ。SPIの最上位bitがどちらを使うか示し、残りの値とマスター鍵から受信鍵を導出する。

アクティブなマスター鍵とSPI割当を知るのは受信側なので、SPIを決めるのも受信側である。送信側が勝手にSPIを選べば、鍵再利用やepoch不一致を招く。したがって初期handshakeは単なる鍵要求ではなく、受信側が選んだSPIと対応鍵の受け渡しになる。

PSP SAは単方向である。双方向通信には、Aが受信者としてBへ渡す鍵と、Bが受信者としてAへ渡す鍵が必要になる。片方向の証拠をもう片方へ流用できない。

RFC 7296 の通常のChild SAでは、IKE秘密やnonceから鍵材料を導く。PSP案は受信者が制御する鍵を運ぶため、RFC 9838 のKey Downloadを単方向group配布からpeer-to-peer用途へ再利用する。これは搬送の標準化であり、デバイス設定の標準化ではない。

Childless IKE SAは鍵を早く出し過ぎないためにある

IKE_SA_INITでKey Wrap Algorithmを合意し、対応するresponderはCHILDLESS_IKEV2_SUPPORTEDを返す。RFC 6023 は、最初のIKE_AUTHでChild SAを作らずにIKE SAだけを成立させる方法を定めた。

PSP鍵はIKE_AUTHで渡せない。initiatorが受信鍵を送る時点ではresponderの認証がまだ完了していないからである。まず相互認証し、その後にCREATE_CHILD_SAで敏感な材料を交換する。

この順序は重要だが、その意味を広げてはいけない。IKE identityは制御主体を認証する。背後の物理NIC、virtual function、queue、VMまで自動的に同一視するものではない。Key Wrap Algorithmの合意もPSP専用性を示さず、同じIKE SAはESPとPSP双方を作れると案は記す。

したがって状態は少なくとも、capability、peer authentication、PSP key delivery、local installation、packet verdictに分ける必要がある。

Message bindingは強いが、hardware commandではない

変更版CREATE_CHILD_SAには、まだIANA <TBA>のPSP protocol identifierとPSP parameter transform、Traffic Selectors、SPI、両方向それぞれ一つのKD payloadが入る。Key BagのSPIはproposalに対応し、SA_KEYはSK_w = prf+(SK_d, "Key Wrap for PSP")で保護される。

この構造は制御監査に有用である。どの認証済みpeerが、どのtrafficに、どのSPIとparameterを提示したかを再構成できる。しかし、返された鍵をhostやNICへ渡すAPIは本文の範囲外である。

archive済みの Google PSP repository はreference implementationとpacket testを含む。Architecture Specificationは、on-chip flow table、RAM上のSA database、transmit descriptorに鍵または参照を載せる方法など、複数の送信鍵管理を挙げる。それぞれ容量、遅延、acknowledgement、failureが違う。repositoryは公開コードの存在を示すだけで、特定製品や運用採用を示さない。

ローカル受領証にはSPI、方向、algorithm、NICまたはvirtual function、queue/SA object、driver結果、epochを含めるべきである。鍵の平文をlogへ残す必要はない。どの参照がどの実行対象に設定されたかは残さなければならない。

Statelessという語はepochを消さない

PSPが減らすのは、主として受信側のper-SA key storageである。二つのmaster key、active側、SPI space、SA lifetime、rotationは残る。送信側はper-SAの送信鍵を持つ。upper layerはsocketごとのapproved SPI listを持つ場合がある。

RFC 4301 はSA管理、policy、packet processingを分離する。RFC 4303 でもESP SAの成立はpacket成功そのものではない。PSPは状態の配置を変えるが、controlとexecutionを一つにしない。

同様に、設計上のscale目標はbenchmarkではない。PSP文書は多数のSAや高いkey update rateを考慮するが、名前のあるNICの実測を示していない。IKE処理が正常でも、送信table不足やprogramming delayは起き得る。

最初のpacketを別に検証する

PSP仕様は、成功したTX/RX packet・byte、authentication/encryption failure、format error、無効なmaster-key selectionなどのcounterを要求する。成功したdecrypt/authenticate flagとSPI metadataをupper layerへ渡す仕組みも求める。

制御受領証の次に、限定したcanary packetを送ればよい。送信側はSPIとIV、TX counter、使用したlocal objectを記録する。受信側はmaster-key epoch、key derivation、ICV判定、RX counter、upper-layer deliveryを記録する。

その結果は一つのpacketまたはtest flowを証明するにすぎない。しかし、鍵配送だけをend-to-end testとして扱うよりはるかに正確である。TXのみ増えればpathやencapsulationを調べ、RX auth成功後にapplication receiptがなければSPI policy、transport、applicationを調べられる。

Rekey responseの後に切替と削除が残る

PSP案はREKEY_SAで置換対象を示せる。IKEv2一般では、新SAを作り、trafficを移し、旧SAを削除する。最初のresponseは作成までを示す。

運用記録には新SPIのinstall、新SAでのfirst accepted packet、旧SAのlast packet、classifier切替、両端のdelete、loss/reorderingが必要である。新SAが存在しても旧objectが選ばれ続ければ、rekeyは完了していない。

master-key rotationはさらに長い。新規SA向けactive keyを切り替えても、旧SAのために以前のkeyは残る。PSP仕様は、古いmaster keyを本当に追い出すには「double rotation」が必要だとする。それまでに古いepochのconnectionをrekeyしなければならない。

また、PSPには個々のderived key revocationがなく、rotationが無効化手段である。管理画面の「revoked」は判断であって、cryptographic evictionではない。

Replay protectionは別レイヤーの責任として記録する

PSP自体はreplay protectionを提供せず、TCPなどlayer 4に期待する。IKEv2による新しい鍵配送もその境界を変えない。有効なICVはauthenticityを支えるが、duplicate rejectionを自動的には示さない。

これは実装が無防備だという主張ではない。replayを拒否したと主張するなら、どのlayerが、どのstateを使い、何を観測し、どのverdictを出したかを保存せよという意味である。SPI、IV、ICVをpolicy verdictへ読み替えてはならない。

Revision 02は更新であり、新しい安全評価ではない

Datatracker API はrevision 02を2026年9月30日、expiryを2027年4月3日とする。document page はactive individual Internet-Draft、history は三revisionを記録する。

01から02への差分は日付、revision番号、expiry、headerだけで、protocol本文は同じである。headerはExperimentalを意図するが、DatatrackerにはRFC、stream、responsible AD、standards levelがない。更新日をadoptionやdeploymentへ拡大してはいけない。

PSP identifierとtransformはまだ<TBA>である。IANA IKEv2 registry が実際の割当を示す。Internet-Draftのrequestはregistry receiptではない。

情報源と限界

根拠はrevision 02のtext/HTML/XML、Datatracker、RFC 7296、RFC 6023、RFC 9838、RFC 4301、RFC 4303、IANA、PSP repositoryとArchitecture Specificationである。production adoption、performance、conformance、vulnerability、incident、service outcomeは示さない。