Kerberos يعبر Realm بحقل transited فارغ؛ والحكم الأخير لخادم التطبيق

الخلاصة

ربطت RFC 1510 نطاقات Kerberos بالمفاتيح وتذاكر TGT. في الاتصال المباشر قد يخلو transited من الوسطاء، لذلك يفحص مشغّل الخدمة حقلي نطاق المستخدم والخدمة أيضاً.
جعلت RFC 4120 خادم التطبيق صاحب القرار الأخير: يتحقق من مسار KDC أو يرفض التذكرة العابرة للنطاقات إذا غابت علامة فحص السياسة.

التحليل

طرفا المسار خارج القائمة

باستخدام أسماء توضيحية للنطاقات: يطلب مستخدم مسجل في ALPHA.EXAMPLE تذكرة لخدمة ملفات في BETA.EXAMPLE. إذا تقاسم النطاقان المفتاح المطلوب ولم يوجد نطاق ثالث بينهما، فقد يكون transited فارغاً. وتحدد حقول الطرفين هوية الجهتين؛ ويسجل الفراغ اتصالاً مباشراً بلا وسيط.

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

تصف RFC 1510 كل نطاق بأنه مجال إداري يشغّل خدمة Kerberos الخاصة به. ويدخل اسم النطاق في اسم هوية المستخدم، ويمكن للخدمة المستقبلة الاستناد إليه عند تقرير قبول الطلب. لعبور نطاق آخر، ينشئ المسؤولون مفتاحاً بين النطاقين؛ وقد يستخدمون مفتاحاً مستقلاً لكل اتجاه. يسجل النطاق البعيد خدمة منح التذاكر التابعة للنطاق الآخر كهوية رئيسية، ثم يفك KDC البعيد التذكرة التي أصدرها الطرف المقابل باستخدام المفتاح المشترك.

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

أسماء الوسطاء محفوظة بلا ترتيب زمني

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

تسجل RFC 1510 أسماء النطاقات الوسيطة كمجموعة غير مرتبة، وتضغط الأسماء الهرمية الشائعة لتقصير الحقل. يظل ترتيب المرور في سجل تشغيلي آخر إذا احتاجت المؤسسة إلى إعادة بناء التسلسل.

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

في يوليو 2005، حلت RFC 4120 محل RFC 1510 وحسمت جهة القرار: خادم التطبيق يقبل المصادقة أو يرفضها، وعليه أن يتحقق من موثوقية KDCs المشاركة لهذا المستخدم. يمكن لـ KDC نطاق الخدمة فحص المسار وفق سياسته المحلية ووضع العلم TRANSITED-POLICY-CHECKED في تذكرة الخدمة. عند غياب العلم، يفحص التطبيق النطاقات بنفسه أو يرفض التذكرة العابرة للنطاقات. وتحذر RFC 4120 من أن KDC غير موثوق يستطيع اختلاق القائمة، حتى لو أدرج أسماء جهات موثوقة.

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

ذكرت RFC 1510 في سبتمبر 1993 أن البروتوكول قيد المراجعة ولم يكن مطروحاً آنذاك ليصبح معياراً للإنترنت. دخلت RFC 4120 مسار Standards Track عام 2005 وشرحت مسؤوليات التنفيذ بوضوح أكبر. الدليل الغائب هو سجل نشر من التسعينيات يحدد خوادم التطبيقات التي فحصت transited؛ هذا السجل سيبين ما إذا كان الضابط يعمل في الأنظمة الفعلية، بينما توثق RFC تصميم البروتوكول.