要約

  • RFC 3129はKerberosチケットのセッション鍵をIPsec SAの鍵素材の基礎にし、ピアごとの長期共有秘密を減らそうとした。
  • KINKはIKEの代替ではない。中央管理と計算の節約を得る代わりに、稼働中の信頼できる第三者へ依存する設計だった。
  • 複雑さは消えず、KDCの可用性、realm、時刻、名前管理へ移った。トラフィックselectorの認可は依然として各ピアに残った。

RFC 3129の中心にあるのは、暗号式というより関係数の問題である。IPsecピアのすべての組み合わせに別々の事前共有鍵を置けば、文書の整理では配布がO(n²)になる。Kerberosなら、各principalはKDCとの長期的な関係を持ち、サービスごとのticketとsession keyを受け取る。長期秘密の関係は簡略化されたモデルでO(n)になる。

もちろん、これはrealm運営の全費用を表す式ではない。しかし、鍵管理の本質をよく示す。暗号が破られなくても、関係を登録し、交換し、更新し、失効させる作業が増えすぎれば、安全な仕組みは運用不能になる。

当時のIPsecには既に役割分担があった。RFC 2401はSecurity AssociationとAH、ESPによる保護を定め、RFC 2409はIKEを規定していた。IKEでは二つのピアが相互認証し、parameterと鍵素材を交渉する。交換時に中央機関が参加しなくてもよい点は、peer-to-peer設計の大きな価値だった。

その独立性は、各端末に仕事を配った。公開鍵認証を拡張するにはX.509証明書、trust path、署名検証が必要になる。Diffie–Hellmanには計算負荷があり、応答側はDoS圧力を受ける。事前共有鍵へ戻れば、今度は組み合わせごとの配布が増える。組織のsecurity policyも、多数の装置に同じ意味で実装されるとは限らない。

RFC 3129が求めたKINKは、この配置をKerberosで変える。RFC 1510のKerberos V5では、clientがKDCへ認証し、service ticketを得る。ticketにはclientとserviceが共有できるsession keyが含まれる。KINKはその鍵をIPsec SA用の鍵素材の基礎にするはずだった。

利点はhandshakeの短縮だけではない。長期秘密は全ピア間の網ではなく、principalとKDCの間に置ける。PKINITで公開鍵を使う場合も、initial credential取得時の処理を複数のservice ticketへ分散できる。policyの一部をrealmの管理点へ集め、信頼できないかもしれない各ピアが同じ規則を守ることだけに期待せずに済む。

一方、RFC 3129は「KINKはIKEの置き換えではない」と明記した。IKEは、稼働中の第三者なしで二つのピアを相互認証し、鍵を交換できる。KINKにはそれができない。信頼できる第三者が現実に存在し、その関与が望ましい環境に限って、この交換条件は成立する。

つまり中央化は、複雑さを無料で消す技法ではなく、failure domainの選択だった。KDCはペアごとの設定や各serverで繰り返す公開鍵処理を減らす。その代わり、ticket発行、principal名、realm間信頼、時刻、そして新しい関係の開始が、一つの制度的境界に結び付く。

要件は中央への依存を可能な限り限定していた。IPsecピアは、TGTだけを持つKerberos clientでも、keytabを持つserverでも、initiatorになれなければならない。通常のservice ticketを応答側が復号できない場合にはuser-to-user modeを使う。複数realmへの参加と、絶対的な時刻ずれへの対処も必要だった。

特に重要なのがrekeyである。Kerberos session ticketが有効な間は、KDCの助けなしにSAの鍵を更新できなければならない。KDCがpacketごと、更新ごとに判断する設計ではない。期限付きの共有materialを発行し、その期間の内部ではピアが処理を続ける。

ピアに残る処理は多い。KINKはSAを作成、変更、更新、削除し、cipher suiteとflow selectorを交渉し、transportとtunnel、AHとESP、IPv4とIPv6を扱う必要があった。Kerberosがidentityを認証しても、そのidentityがどのprefixを代表できるかは決めない。local IPsec policyがauthorizationを担う。

この線引きは実務で崩れやすい。正しいticketは「誰か」を示し、共有鍵を渡す。しかし「どのnetworkのためにtunnelを張ってよいか」までは自動的に決めない。本物のidentityに広すぎるselectorを結び付ければ、中央認証は誤った許可をより信頼できそうに見せる。

また、RFC 3129は完成したprotocolではない。Informationalのrequirements documentである。2006年にRFC 4430がProposed StandardとしてKINKを規定し、3129を要件の基礎にした。要件を定めた時点と相互運用仕様ができた時点は別であり、どちらの発行も普及やIKEの置換を証明しない。

周囲の標準も動き続けた。RFC 4120はKerberos V5を更新し、RFC 3961は暗号とchecksumのframeworkを整理した。RFC 4556はPKINITを標準化し、RFC 6113はpre-authenticationを一般化した。IKEもRFC 4306のIKEv2、さらにRFC 7296へ進んだ。Internetは一つの信頼配置だけを選ばなかった。それぞれが異なる失敗を受け入れるからである。

O(n)対O(n²)という表現も、総費用の保証ではない。KDCは単純モデルのpairwise long-term secretを減らすが、master key保護、keytab rotation、backup、realm設計、clock同期、監査、capacity planningを必要とする。多数の小さな関係を、少数だが重大な機関へ交換する。

停止時の挙動にも段階がある。KDCが一時的に失われても、既存SAは直ちに消えない。有効なticketがあれば、要件どおりKDCなしでrekeyできる場合がある。影響は新しいcredential、期限切れticket、新規service関係から現れる。「KDC停止＝全IPsec停止」ではなく、ticket寿命、SA寿命、cacheと再接触時点の組み合わせである。

侵害の場合、集中logはprincipalとticketの対応を追跡しやすくする。同時に、侵害されたKDCは多数のもっともらしいidentityを発行できる。説明可能性とblast radiusが共に大きくなる。

RFC 3129のSecurity Considerationsは、KINKで作るSAがIPsecとKerberos双方の弱点の和を継承すると述べた。二つの成熟技術を組み合わせても、欠点は相殺されない。接合部に新しい弱点が生まれる可能性もある。

この文書の歴史的価値は、運用を暗号要件の中へ入れたことにある。二点が同じ鍵を計算できるかだけではない。誰が誰を知るのか、policyを誰が管理するのか、重い処理をどこで反復するのか、大規模networkをどの機関が統治可能にするのかが問われた。

KDCは信頼を消さない。信頼を再利用しやすく、記録しやすく、集中管理しやすくする。そして、その中心の可用性と侵害を多くのピアに共有させる。RFC 3129は、protocol完成を宣言する前に、この取引条件をrequirementsとして残した。

典拠