الخلاصة

  • قد تعيد إجابة SRV غير المحمية اسم خادم يثبت هويته الحقيقية بنجاح، مع أنه غير مخوّل لتمثيل خدمة النطاق الذي قصده العميل.
  • يضيف RFC 5178 اسم service [AT] domain [AT] hostname، حيث تمثل [AT] علامة at ذات ترميز ASCII الحرفية في صياغة RFC، فتغدو حيازة اعتماد هذا الاسم الثلاثي دليلاً محدوداً على التفويض. ولا تصبح نتيجة التطبيق أو صحة المحتوى جزءاً من هذا الدليل.

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

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

يفصل RFC 5178 هوية المنفّذ عن نطاق التفويض.

الاسم يحمل السؤال الذي يجب إثباته

يتكون نوع الاسم GSS_C_NT_DOMAINBASED_SERVICE من ثلاثة عناصر إلزامية: الخدمة، والنطاق الذي تُقدَّم له، واسم المضيف المعيّن. صيغته service [AT] domain [AT] hostname، وقد سجلته IANA بالقيمة 5 ضمن أنواع أسماء GSS-API.

الخدمة تحدد الوظيفة. النطاق يحدد الجهة أو المورد الجماعي المقصود. المضيف يحدد acceptor الفعلي. وقد يكون النطاق اسماً غير تابع لـ DNS، وإن كانت أسماء DNS هي الحالة المتوقعة.

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

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

المصادقة القوية لا تتجاوز حدودها

عندما يبني العميل الاسم المقصود ويقيم سياق GSS ناجحاً مع خادم يثبت الاعتماد المطابق، يحصل على دليل مهم: الطرف المقابل يسيطر، في ظل الآلية النشطة، على اعتماد يربط الخدمة بالنطاق والمضيف.

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

لذلك ينبغي أن تسجل العملية: النطاق المقصود قبل الاكتشاف، الاستعلام وحالة DNSSEC، كل المرشحين، المضيف المختار، نوع الاسم وصيغته، الاسم المعياري للآلية، realm المشتق، جهة إصدار الاعتماد وصلاحيته، نتيجة GSS، قرار التطبيق، وقياساً مستقلاً للنتيجة.

العبارة «نجحت Kerberos» تختصر سطراً واحداً من هذه السلسلة.

التراجع المتوافق يحتاج إلى تفويض بديل

لم يفترض RFC 5178 أن كل الآليات والخوادم ستدعم النوع فوراً. قد لا تتمكن الآلية من التفاوض عليه، وقد يعتمد LDAP قديم على أسماء المضيف، وقد لا توجد اعتمادات النطاق بعد. تشغيل الصيغة الجديدة من جانب العميل وحده قد يكسر التشغيل البيني.

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

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

ينبغي أن تظهر في القياس حالات منفصلة: اسم نطاق ناجح؛ تراجع مع تفويض مكافئ؛ تراجع بلا نطاق مكافئ؛ وفشل توافق. جمعها تحت «متصل» يحول قرار المخاطر إلى أثر جانبي لترتيب الأخطاء في المكتبة.

الترميز لا يمنح التطابق

تدخل الأسماء الدولية السلسلة عبر واجهات مختلفة. يشترط RFC 5178 أن يقبل الاستيراد التقليدي أسماء النطاق والمضيف بترميز ACE. وتقبل دالة UTF-8 المقترحة UTF-8 أو ACE. أما العرض التقليدي فيخرج ASCII أو ACE، بينما يخرج عرض UTF-8 نص UTF-8 ولا يجوز أن يخرج ACE.

هذه تحولات تمثيل وليست أحكام هوية. يفرق GSS-API بين الاسم الداخلي، والنص المعروض، واسم الآلية، والاسم المصدَّر. يحذر RFC 2743 من افتراض أن استيراد نص ثم عرضه يعيد النص أو نوع الاسم نفسيهما. وتعود المقارنة إلى GSS_Compare_name() أو canonization الآلية، لا إلى مقارنة سطرين قابلين للقراءة.

كما أن RFC 5178 استند إلى RFC 3490 قبل أن يحل IDNA2008 محله ويعرّف A-label وU-label. يجب على التنفيذ الحديث توثيق ملف المعالجة الذي يستخدمه من دون الادعاء بأن القواعد اللاحقة أعادت كتابة النص القديم. يحتاج المدقق إلى صيغة Unicode التي فهمها الإنسان، وصيغة ACE التي مرت على السلك، والprincipal الذي تحقق فعلياً.

تحويل Kerberos يحافظ على الفواصل

يحدد RFC 5179 تحويل الاسم إلى Kerberos V: الخدمة هي المكوّن الأول، والمضيف الثاني، والنطاق الثالث. يوصى بنوع NT-SRV-HST-DOMAIN ذي القيمة 12، مع جواز NT-UNKNOWN.

ولا يساوي realm حقل domain تلقائياً. تشدد اعتبارات الأمن على اشتقاق realm من hostname، لا من خانة النطاق في نص الإدخال. فالخانة التي تصف من تمثله الخدمة لا ينبغي أن تختار وحدها سلطة المصادقة التي ستصدقها.

لهذا يجب اختبار principal الناتج وrealm الفعلي والاعتماد الذي أجاب. قبول parser للسلسلة لا يثبت أن التحويل طبق سياسة المؤسسة.

مثال NFS يوضح التركيب

استخدم RFC 6641 البناء لاحقاً لاكتشاف جذور namespace في NFSv4 عبر SRV. ينبغي استخدام DNSSEC عند توفره. ويضيف اسم الخدمة المبني على النطاق تحققاً آخر: على المضيف المحدد أن يصادق اسماً من نوع nfs [AT] نطاق-المؤسسة [AT] المضيف.

ينشر DNS مواقع محتملة. ينشر نظام الاعتماد مجموعة المفوضين. يطبق NFS تفاوضه وتصاريحه. وتثبت عملية mount والمحتويات المرصودة النتيجة. لا يحق لإيصال واحد أن ينتحل وظيفة البقية.

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

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

المصادر