الخلاصة

  • اشترطت RFC 3129 أن تكون مفاتيح الجلسات داخل تذاكر Kerberos أساساً لمفاتيح ارتباطات أمان IPsec، لتقليل الأسرار طويلة الأجل بين كل زوج من النظراء.
  • لم يكن KINK بديلاً عن IKE؛ فقد استبدل استقلال التبادل بين نظيرين بإدارة مركزية واقتصاد في الحساب واعتماد على طرف ثالث موثوق ونشط.
  • لم تختفِ التعقيدات، بل انتقلت إلى توافر KDC وبنية المجالات والوقت والأسماء، بينما بقي تفويض الأنفاق ومحددات الحركة محلياً.

أهم معادلة في RFC 3129 لم تكن معادلة تشفير. كانت حساباً لعدد العلاقات. عندما يحتفظ كل زوج من نظراء IPsec بسر مشترك مختلف، وصفت الوثيقة توزيع المفاتيح بأنه مشكلة من رتبة O(n²). أما في Kerberos فيقيم كل principal علاقة طويلة الأجل مع مركز توزيع المفاتيح، ويصدر المركز تذاكر خدمات تحمل مفاتيح جلسات. في هذا النموذج المبسط تصبح العلاقات الدائمة أقرب إلى O(n).

لا تحسب هذه المقارنة كل نفقات تشغيل Kerberos، لكنها تكشف سبباً عملياً للفشل. قد تبقى الخوارزمية قوية، في حين يصبح حصر الأسرار وتوزيعها وتدويرها وإلغاؤها أمراً لا يحتمل.

كان IPsec قد فصل بين حماية الرزم والتفاوض على الثقة. وصفت RFC 2401 ارتباطات الأمان واستخدام AH وESP، بينما عرّفت RFC 2409 بروتوكول IKE الذي يسمح لنظيرين بالمصادقة المتبادلة والتفاوض على المعلمات واشتقاق مادة المفاتيح. وكانت قدرة IKE على العمل من دون سلطة مركزية حاضرة لحظة التبادل ميزة حقيقية.

لكن الاستقلال وزع العمل على الأطراف. احتاجت المصادقة القابلة للتوسع إلى شهادات X.509 ومسارات ثقة وعمليات توقيع. وفر Diffie–Hellman سراً مشتركاً، لكنه فرض كلفة حسابية وضغطاً يمكن استغلاله لحجب الخدمة. أما المفاتيح المشتركة مسبقاً فأعادت مشكلة توزيع الأسرار بين الأزواج. كذلك توزعت سياسة المؤسسة على أجهزة قد لا تتساوى في الضبط أو الثقة.

عرض Kerberos جغرافيا مختلفة للثقة. وفق RFC 1510 يصادق العميل لدى KDC، ويحصل على تذكرة لخدمة ومفتاح جلسة. تستطيع الخدمة فك التذكرة والحصول على المفتاح نفسه. كان على KINK، أي Kerberized Internet Negotiation of Keys، أن يجعل مفتاح الجلسة أساس مادة مفاتيح ارتباطات IPsec.

لم يكن الأمر مجرد استبدال مصافحة بأخرى. صار بالإمكان وضع الأسرار الدائمة بين principals والمركز بدلاً من نسجها بين جميع النظراء. وعند استخدام PKINIT أمكن دفع كلفة المصادقة بالمفتاح العام مرة عند الحصول على الاعتماد الأولي، ثم توزيع فائدتها على تذاكر خدمات عدة. كما أمكن إدارة جزء من السياسة في سلطة المجال التي تتحكم بها المؤسسة.

مع ذلك كانت الوثيقة صريحة في الثمن. KINK ليس بديلاً عن IKE. يمتلك IKE خاصية لا يستطيع KINK تكرارها: يمكن لنظيرين المصادقة وتبادل المفاتيح من دون مشاركة طرف ثالث نشط. يصبح KINK منطقياً فقط عندما تكون سلطة الثقة موجودة ومشاركتها مرغوبة.

لذلك كانت المركزية اختياراً لنطاق العطل، لا إزالة مجانية للتعقيد. يقلل KDC التهيئة الثنائية وبعض عمليات المفتاح العام المتكررة على الخوادم، لكنه يصبح الحد الذي ترتبط به التذاكر وأسماء principals والثقة بين المجالات والوقت وبداية العلاقات الجديدة.

حاولت المتطلبات منع المركز من التحكم في كل لحظة. كان ينبغي أن يبدأ أي من نظيري IPsec التفاوض، سواء كان عميل Kerberos لا يملك سوى TGT أم خدمة لديها keytab. وكان نمط user-to-user مطلوباً عندما لا يستطيع المستجيب فك تذكرة خدمة عادية. كما وجب دعم مجالات متعددة والتعامل السليم مع الانحراف المطلق للوقت.

أوضح قيد هو تجديد المفاتيح. ما دامت تذكرة الجلسة صالحة، يجب أن يعيد النظيران توليد المفاتيح من دون مساعدة KDC. لم يكن المركز في مسار البيانات، ولم يكن يوافق على كل رزمة أو كل rekey. كان يصدر مادة مشتركة ذات صلاحية محددة، ثم يترك للنظيرين العمل داخل تلك المدة.

وبقي على KINK أداء الكثير: إنشاء ارتباطات الأمان وتعديلها وتجديدها وحذفها، والتفاوض على حزم التشفير ومحددات التدفق، ودعم نمطي النقل والنفق وAH وESP وIPv4 وIPv6. لا تقرر هوية Kerberos وحدها أي شبكة يستطيع principal تمثيلها. بقي التفويض في سياسة IPsec المحلية.

هذا الفصل بين المصادقة والتفويض حاسم. تثبت التذكرة الصحيحة الهوية وتقدم مفتاحاً مشتركاً، لكنها لا تمنح تلقائياً حق فتح نفق لنطاق معين. إذا ربطت القاعدة المحلية هوية صحيحة بمحدد واسع أكثر مما ينبغي، جعلت المصادقة المركزية القرار الخاطئ يبدو أكثر موثوقية.

ولم تكن RFC 3129 بروتوكول KINK المكتمل. كانت وثيقة Informational للمتطلبات. جاءت RFC 4430 في 2006 بصفتها Proposed Standard وحددت KINK، مستندة إلى متطلبات 3129. الفرق الزمني يمنع تحويل الخطة إلى ادعاء نشر. لا تثبت الوثيقتان أن KINK انتشر أو حل محل IKE.

استمر المحيط في التطور. حلت RFC 4120 محل مواصفات Kerberos V5 الأولى، ونظمت RFC 3961 إطار التشفير والتحقق، وقننت RFC 4556 بروتوكول PKINIT، ووسعت RFC 6113 إطار ما قبل المصادقة. وتطور IKE إلى IKEv2 في RFC 4306 ثم RFC 7296. لم يختر الإنترنت شكلاً واحداً للثقة، لأن البيئات لا تقبل أنماط العطل نفسها.

لذلك لا يصح تحويل O(n) مقابل O(n²) إلى وعد شامل بالكلفة. يقلل KDC الأسرار الثنائية طويلة الأجل في النموذج المبسط، لكنه لا يزيل حماية المفاتيح الرئيسية، وتدوير keytabs، والنسخ الاحتياطي، والثقة بين المجالات، وضبط الوقت، والتدقيق والسعة. إنه يستبدل علاقات صغيرة كثيرة بمؤسسات أقل عدداً وأكبر أثراً.

يظهر التدرج عند الانقطاع. قد تستمر ارتباطات الأمان القائمة، وقد تسمح التذكرة الصالحة بتجديد محلي. تفشل الاعتمادات الجديدة والتذاكر المنتهية والعلاقات التي لم تبدأ بعد في وقت مختلف. ليس الحد «تعطل KDC يعني تعطل IPsec كله»، بل تفاعل عمر التذكرة وعمر SA والذاكرة المؤقتة ولحظة الحاجة التالية إلى المركز.

وعند الاختراق تتحول الميزة إلى خطر واسع. تستطيع السجلات المركزية ربط principal بالتذكرة والوقت، لكن مركزاً مخترقاً يستطيع إصدار ثقة تبدو صحيحة على نطاق كبير. تزيد قابلية التفسير ويكبر معها نصف قطر الضرر.

كانت اعتبارات الأمان في RFC 3129 واقعية: سترث الارتباطات اتحاد نقاط ضعف IPsec وKerberos. جمع آليتين ناضجتين لا يلغي عيوبهما، وقد يخلق خللاً جديداً في موضع اتصالهما.

لهذا تدخل الوثيقة تاريخ الإنترنت. فقد اعترفت بأن الإدارة جزء من تصميم التشفير. لم يعد السؤال هل يصل جهازان إلى المفتاح نفسه فقط، بل من يعرف من، وأين تعيش السياسة، وأين تتكرر العمليات المكلفة، وأي مؤسسة تجعل الشبكة الكبيرة قابلة للحكم.

لم يلغِ KDC الثقة؛ جعلها قابلة لإعادة الاستخدام والتدقيق والتركيز. كانت تلك ميزة تشغيلية ومصدر خطر مشترك. وسجلت RFC 3129 جانبي الصفقة قبل إعلان اكتمال البروتوكول.

المصادر