Loading article…
Kerberized Internet Negotiation of Keys ( KINK ) は、RFC 4430 で定義されているプロトコルで、インターネット鍵交換(IKE) と同様に、 Kerberosプロトコルを使用して、信頼できる第三者がピアの認証とセキュリティ ポリシーの管理を一元的に処理できるようにすることで、 IPsecセキュリティ アソシエーション(SA)を確立するために使用されます。[ 1 ]
RFC 3129 では、IKE の代替としてその動機が示されています。IKE では、ピアはそれぞれ認証にX.509証明書を使用し、暗号化にDiffie–Hellman 鍵交換(DH) を使用し、接続するすべてのピアに対してセキュリティ ポリシーを知って実装する必要があります。[ 2 ] X.509 証明書の認証は、事前に取り決めるか、DNS を使用し、できればDNSSECを使用します。[ 3 ] Kerberos を利用する KINK ピアは、適切な認証サーバー(AS)と相互に認証するだけでよく、鍵配布センター(KDC) が暗号化用の鍵マテリアルの配布を制御し、それによって IPsec セキュリティ ポリシーを制御します。
KINKは、 IPsec SAの作成、削除、および維持を可能にするコマンド/レスポンスプロトコルです。各コマンドまたはレスポンスには、共通のヘッダーと、タイプ-長さ-値のセットからなるペイロードが含まれます。コマンドまたはレスポンスのタイプによって、交換メッセージで送信されるペイロードが制限されます。
KINK自体はステートレスなプロトコルであり、各コマンドや応答において、KINKのハードステートを保存する必要がない。これは、メインモードを使用してまずインターネットセキュリティアソシエーションおよび鍵管理プロトコル（ISAKMP）SAを確立し、その後クイックモードで交換を行うIKEとは対照的である。
KINKは、相互認証とリプレイ攻撃対策のためにKerberosメカニズムを使用します。SA（セキュリティアソシエーション）の確立において、KINKはKerberos AP-REQペイロードに続くペイロードの機密性を確保します。KINKの設計は、公開鍵操作や状態のインストールを行う前に認証済みの交換を要求することで、サービス拒否攻撃を軽減します。また、KINKは、サーバーとKDC（キー配布センター）間で鍵が共有されていない場合に、Kerberosユーザー間メカニズムを使用する手段も提供します。これは通常、初期認証にPKINITを使用するIPsecピアの場合に該当しますが、これに限定されるものではありません。
KINKは、 IKEのセクション5.5で定義されているクイックモードペイロードを、若干の変更と省略を加えてそのまま再利用します。ほとんどの場合、KINKの通信は単一のコマンドとその応答で構成されます。SAを作成する際にオプションの3番目のメッセージが必要となるのは、応答側がイニシエータからの最初の提案を拒否した場合、または鍵生成マテリアルを提供したい場合のみです。KINKは、鍵の再生成とデッドピア検出機能も提供します。
KINKメッセージには以下のフィールドが含まれます。
KINKペイロードは以下のように定義されます。
以下のペイロードが定義されています。
現在、KINKのオープンソース実装として以下のものが利用可能です。