الخلاصة

  • ربط DASS بين اسم principal ومفتاحه العام عبر شهادات تصدرها سلطات تصديق تتبع شجرة التسمية X.500.
  • أراد RFC 1507 أن تحدد الشجرة نطاق ما تستطيع سلطة تصديق مخترقة انتحاله، مع استخدام الشهادات المتقاطعة لربط أجزاء متباعدة من فضاء الأسماء.
  • بقيت الشجرة أيضاً جزءاً من مسار البحث عن الشهادات وإبطالها؛ فالتصميم يصف حدود الثقة والاعتمادية ولا يقدم دليلاً على انتشار DASS في التشغيل الفعلي.

ليست هناك سلطة واحدة تعرف الجميع

يبدأ RFC 1507 من مشكلة توزيع المفاتيح: إذا أراد كل خادم أن يعرف المفتاح العام لكل مستخدم مسبقاً، فلن يتسع هذا الأسلوب لشبكة كبيرة. وإذا ظهرت جهة واحدة لتسجيل الجميع، فستحصل تلك الجهة على قدرة واسعة في ربط الأسماء بالمفاتيح. اقترح Distributed Authentication Security Service (DASS) أن تعتمد الأنظمة على سلطات تصديق متعددة، مع وصلها في تسلسل يمكن التحقق منه.

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

كان اختيار شجرة X.500 مهماً لأن الشهادات لم تُرتب في فراغ. الاسم والسلطة الإدارية يتبعان الهيكل نفسه: لكل دليل سلطة محلية مسؤولة عن مفاتيح الأسماء الموجودة فيه، ويمكن لشهادات الآباء والأبناء أن تربط مستويات الشجرة. أما الأسماء الواقعة في فروع بعيدة، فيمكن وصلها بشهادة متقاطعة تصادق على سلطة أخرى. ويصف RFC 1507 إمكان ربط «جزر» مستقلة عبر جهة عالمية لا يلزم أن تكون عند جذر فضاء الأسماء.

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

كان للشهادة المخترقة نطاقٌ محدد

يشرح RFC 1507 ما يمكن أن تفعله سلطة تصديق مخترقة بدلاً من الاكتفاء بوصف الشهادات بأنها «موثوقة». تستطيع السلطة انتحال principal مسجل في دليلها. وتتغير مساحة الضرر بحسب موقع السلطة في شجرة الأسماء: فالسلطة الأدنى تؤثر في فرع أقرب، بينما يمكن لسلطة أعلى أن تصل إلى مسارات وثقة أوسع.

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

وتظهر المشكلة نفسها عند استخدام هوية عالمية للوصول إلى موارد محلية. شرح DASS أن الشخص قد يملك حسابات على عدة أجهزة، وأن الموارد قد تحتاج إلى التعرف عليه عبر أي جهاز يعمل منه. لكنه لم يلغ الحسابات المحلية. كان من المتوقع أن يربط نظام التشغيل هوية المستخدم بحساب محلي، ويمكن لقواعد تشبه .rhosts أن تسمح للحساب المحلي بقبول الاسم العام.

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

الشجرة كانت مساراً للتراجع أيضاً

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

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

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

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

الساعة جزء من الثقة، لا مجرد خدمة جانبية

استخدم DASS الطوابع الزمنية لمقاومة إعادة إرسال رسالة مصادقة قديمة. يرفض الخادم الرسائل التي خرجت عن نافذة زمنية، ويحتفظ بما رآه بالفعل حتى لا يقبل الرسالة مرتين. اختير هذا المسار لتقليل عدد رسائل التبادل مقارنة بتحدٍّ واستجابة، لكن نجاحه يعتمد على مصدر وقت متزايد ومنسق بين الأجهزة بدقة دقائق تقريباً.

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

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

ما الذي يثبته RFC 1507؟

يصنف RFC 1507 نفسه بأنه Experimental ويقول إنه لا يحدد معياراً للإنترنت. يتضمن ملحقاً يشرح دعماً ممكناً لـ Generic Security Service API. يعرّف RFC 1508 واجهة عامة مستقلة عن آلية التشفير، ويحدد RFC 1509 روابطها بلغة C. وسجل RFC 1510 في الفترة نفسها خدمة Kerberos V5 القائمة على مركز موثوق لتوزيع المفاتيح؛ أما RFC 1704 فاستعرض لاحقاً آليات متعددة للمصادقة.

هذه النصوص تضع DASS بين مقترحات عصره، لكنها لا تقيس استخدامه ولا تفسر مساره اللاحق. لا يقدم RFC 1507 تعداداً للتطبيقات أو المشغّلين، ولا تسجل المصادر هنا حادثة تشغيلية محددة. إن عبارة «Experimental» تصف وضع الوثيقة عند نشرها، ولا تصلح وحدها لإثبات أن التنفيذ كان واسعاً أو معدوماً.

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

المصادر