要約

  • RFC 5197は、MIKEYのmodeを実装可否だけでなく、PKI依存、PFS、両者の鍵生成への関与、group keying、forkやearly mediaへの適合性で比較している。
  • fork先、CSB、TGK、各Crypto SessionのTEK、SSRC、応答時刻を結び付けなければ、二つの「成功」が同じ鍵境界を共有していたかどうかを後から判定できない。

forkは配送ではなく鍵の複製でもある

SIPのforkでは、proxyがINVITEを複数の場所へ送る。SDPにMIKEY payloadが含まれていれば、鍵確立の材料も同時に枝分かれする。ここで重要なのは、どのmodeも同じようにforkへ適応するわけではないことだ。

PSKでは受信側が事前に同じ秘密を持たなければならない。通常のRSAでは、送信側が最終応答先の証明書を先に知る必要がある。全候補を知っていれば複数containerを入れる方法もあるが、それは全証明書を事前に持つことを要求する。DH系やRSA-Rは未知の応答先を扱いやすい一方、応答が増えれば署名検証やDiffie-Hellman計算も増える。

RFC 5197は、forward型で同じ鍵素材が複数の応答先へ届く場合をさらに追う。二つのbranchが同じTEKを使い、同じ32ビットSSRCを選ぶと、SRTPは同じ入力から同じsession keyとpacketごとの初期化ベクトルを導出し得る。結果はツータイムパッドである。

SSRC衝突が通常は低確率であることと、あるsessionで衝突しなかったことは別の主張だ。運用証跡には、forkのbranch、実際に応答したendpoint、TEKの共有範囲、SSRC、衝突検出と解消結果が必要になる。

CSBという成功単位では粗すぎる

MIKEYは、一つのCrypto Session Bundleで複数のCrypto Sessionの鍵とsecurity parameterを確立できる。各sessionはTGKとparameterを共有しながら、異なるTEKを得られる。この階層は効率を生むが、CSB established だけを残す監視には見えない。

調査に必要なのは秘密鍵の値ではない。CSB識別子、TGKの非秘密識別子、各Crypto Session、導出されたTEKのscope、関連するmedia streamと応答先の対応である。これがあれば、鍵の再利用が設計通りの共有だったのか、forkが意図せず広げたのかを区別できる。

group communicationも同じである。RSAやPSKは中央serverが各clientへgroup keyを配る構成で使える場合がある。DH-SIGNは主にpoint-to-pointで、DH-HMACはPFSと双方の関与を得られるがgroup keyingを自動的に支えない。「MIKEY実装済み」はconference topologyへの適合性を意味しない。

modeは安全強度の順位ではない

RFC 5197が扱う七つの方法は、PSK、RSA、DH-SIGN、NULL、DH-HMAC、文書内で議論されるDH-SAML、そしてRSA-Rである。それぞれが異なる不足を補う。

PSKは軽量でPKI不要だがPFSがなく、initiatorだけが鍵素材を作る。RSAもPFSがなく、responder certificateを事前に必要とし、revocation確認がリアルタイムでない場合がある。DH-SIGNは双方がsecretへ寄与しPFSを持つが、広い規模のidentityにはPKIが要る。DH-HMACはPSKでDHを認証し、PKIなしで双方寄与とPFSを得るが、PSK配布とgroup制約は残る。

NULLは下位層に全面依存する。TLSがproxyで終端すれば、そのproxyがmaster keyを平文で得る可能性がある。RSA-Rはresponder certificateをband内で渡せるためforkやretargetingに役立つが、initiatorのRANDは相手の正しい関与を強制できず、真のPFSにはならない。

したがって、mode名から一つの「強さ」を計算するのは誤りである。identity、PFS、双方寄与、replay、group適合、下位層の終端点を別々に評価しなければならない。

応答を待つmodeと待たないmedia

PSKとRSAは一つのinitiator messageで必要な材料を渡せる。early mediaが来る前に双方が鍵を持ちやすい。DH系とRSA-Rはresponseを必要とし、initiatorはそれを受け取るまで最終鍵を得られない。

signalingが複数proxyを戻る一方、mediaが短い経路で届けば、通常のearly media用途でなくてもSRTPが先に来る。ここで鍵が未準備なのは、暗号modeの破損ではない。選択した交換の時間構造である。precondition、保留、packet drop、fallbackのどれを採るかはpolicyとして記録すべきで、成功表示へ隠してはならない。

一つのsessionに必要な証拠

最初にinitiator、想定responder、fork policy、media contextと、実際に実行したmodeを残す。PSK、certificate、下位層、credential serverなどの前提条件と、そのidentity bindingを保存する。certificateなら検証時刻とrevocation情報の鮮度、replayならtime source、許容skew、cache horizonと再起動世代が必要だ。

次にtranscript hashをCSBへ結び、TGKから各TEKへのscope、全branch、SSRCとcollision処理を記録する。最後にresponse受信、鍵install、最初の暗号化packet、最初の復号成功を並べる。PFS、双方寄与、peer authentication、replay resistance、group suitability、media readinessは独立した結果欄にする。

これはRFC 5197に新しいwire formatを要求する提案ではない。同文書が示した適用差を、実際のsessionから消さないための記録である。実装、設定、選択、完了、利用可能は別の現実層であり、一つの緑色表示が全部を代理することはできない。

出典

  1. RFC 5197 HTML
  2. RFC 5197 テキスト
  3. RFC 5197 情報ページ
  4. IETF Datatracker：RFC 5197
  5. RFC 5197の履歴
  6. RFC 5197の参照文献
  7. RFC 5197 errata
  8. RFC 3830 — MIKEY
  9. RFC 3711 — SRTP
  10. RFC 4650 — DH-HMAC
  11. RFC 4738 — RSA-R
  12. RFC 4567 — SDP/RTSPの鍵管理拡張
  13. RFC 4568 — media streamのsecurity description
  14. RFC 5027 — SDP mediaのsecurity precondition
  15. RFC 4086 — randomness要件
  16. RFC 4082 — TESLA
  17. RFC 4442 — TESLA bootstrapping
  18. Heng Lu — 現実の層と象徴的権力
  19. Heng Lu — 最小初期仕様
  20. Heng Lu — running codeの優先