تقليل عدد الأسرار لم يوحّد الثقة بين الشبكات

الخلاصة

• استخدمت وثيقة من عام 1999 مثال مئة شريك لتوضيح كيف يمكن لوسيط مركزي أن يقلل علاقات الأسرار المشتركة من 4,950 إلى مئة. كان ذلك حساباً توضيحياً، لا قياساً لشبكة فعلية ولا برهاناً على انتقال الثقة بين الأطراف.
• يستطيع كل وسيط إضافة قيمة Proxy-State واحدة تخصه، ثم حذفها عند عودة الرد، مع المحافظة على قيم الآخرين وترتيبها النسبي من دون تفسير محتواها الخاص.
• إعادة الحالة ليست موافقة على الدخول، وحماية العلاقة مع الجار ليست ضماناً لسلامة جميع القرارات السابقة. لكل من هذه الالتزامات حدود وأدلة مختلفة.

الحساب الذي بسّط العلاقات ولم يحسب الثقة

إذا أرادت مئة جهة أن ترتب سراً مشتركاً لكل علاقة مباشرة بين جهتين، فستحتاج إلى 4,950 علاقة. وإذا مرت طلباتها عبر وسيط مركزي، أمكن أن تصبح العلاقات مئة، واحدة لكل جهة مع المركز. استخدمت الوثيقة المعلوماتية RFC 2607، الصادرة في يونيو 1999، هذا المثال لشرح فائدة الوسطاء في خدمات التجوال.

لا يصف الرقم حجم شركة أو نتيجة تجربة ميدانية. إنه يوضح كيف تتغير بنية العلاقات. ويترك سؤالاً آخر مفتوحاً: ماذا أصبح المركز مسؤولاً عنه بعدما قل عدد الترتيبات المباشرة؟

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

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

من كان العميل، ومن كان الخادم؟

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

عندما يمرر الطلب، يؤدي النظام وظيفتين مختلفتين: هو خادم بالنسبة إلى الجهة السابقة، وعميل بالنسبة إلى الجهة التالية. وقد يكون الوجهة النهائية لطلبات بعض النطاقات ووسيطاً لغيرها. ويمكن أن تتتابع عدة وسائط، مع ضرورة تجنب الحلقات. وجود Proxy-State لا يحسب المسار ولا يضمن وحده أن السلسلة خالية من الدوران.

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

قيمة تخص صاحبها، لا أمراً لجميع المشاركين

لم تبدأ Proxy-State في عام 2000. كانت موجودة بالفعل في RFC 2138 الصادرة في أبريل 1997. وقد أوضحت المراجعة اللاحقة سلوك الوسيط والمحافظة على ترتيب السمات بدرجة أكبر.

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

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

حين يعود الرد، يحذف الوسيط آخر Proxy-State إذا كان قد أضاف واحدة، أي قيمته هو. وتبقى القيم السابقة لتعود إلى أصحابها السابقين. بهذه الطريقة يمكنه إنهاء عمله من دون أن يحتاج إلى معرفة طريقة ترميز كل وسيط آخر لحالته.

ترتيب نسبي لا موضع ثابت في نهاية الحزمة

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

يمكن، إذن، أن توجد سمة أخرى بين قيمتين من Proxy-State، أو أن تأتي سمة من نوع مختلف بعد آخر Proxy-State. المهم أن تظل علاقة الترتيب بين القيم الخاصة بالوسطاء صحيحة، لا أن تحتل كتلة متصلة في نهاية الحزمة.

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

ما يعود لم يصل بالضرورة إلى النهاية

هناك اختيار آخر أكثر دلالة. يستطيع الوسيط ألا يمرر قيم Proxy-State التي تلقاها إلى الخادم التالي، وأن يحتفظ بها محلياً. لكنه إذا فعل ذلك، فعليه إعادتها إلى الرد قبل إرساله إلى عميله السابق.

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

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

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

رفض الخدمة لا يلغي واجب الرد

يعيد الخادم النهائي قيم Proxy-State التي استلمها من دون تعديل وبالترتيب نفسه، سواء كانت النتيجة Access-Accept أو Access-Reject أو Access-Challenge. فحالة الوسيط لا تستحق العودة فقط عندما يسمح للمستخدم بالدخول. حتى الرفض يحتاج إلى إكمال التبادل وإيصال النتيجة إلى الجهة التي بدأت الطلب.

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

وقد يسمح البروتوكول للوسيط بتغيير بعض السمات لتنفيذ سياسة محلية، مع حماية Proxy-State وState وClass الموجودة من التعديل. ليست كل أجزاء الرد غير قابلة للتغيير، وليس كل تغيير عملاً عدائياً. لكن القدرة التقنية على تغيير النتيجة لا تجعل كل تغيير مسموحاً، ولا تمنح الوسيط سلطة عامة على الجهات الأخرى.

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

حالات متشابهة في الشكل، مختلفة في العمر

يسجل سجل سمات RADIUS لدى IANA الأرقام 24 و25 و33 لكل من State وClass وProxy-State. هذه الأرقام مرجع مشترك للتعرف إلى الأنواع، لا تعريف لمعنى كل قيمة خاصة في كل شبكة.

قد يحمل State معلومات لاستكمال محادثة مصادقة، فيخرج مع تحدٍّ ويعود في الطلب التالي. وقد ينتقل Class من قبول الدخول إلى طلبات المحاسبة، وتوصي القاعدة الأساسية بنقله بلا تغيير عندما تستخدم المحاسبة. أما Proxy-State فيعود إلى الوسيط الذي أضافه، ليحذفه ذلك الوسيط من الرد المتجه إلى الخلف.

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

وتضيف المحاسبة التزاماً آخر. فالوثيقة المعلوماتية RFC 2866، الصادرة في يونيو 2000، تجعل Accounting-Response مشروطاً بتلقي الطلب وتسجيله، لا بمجرد وصوله إلى الواجهة. لكن تأكيد وسيط يتحمل مسؤولية التخزين وإعادة الإرسال لا يثبت وحده أن كل الجهات البعيدة سجلت الحدث نفسه بالفعل. يجب تتبع من أكد، وما الذي تحمله، وما الذي ما زال معلقاً.

عدم التفسير ليس تشفيراً

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

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

تطورت حماية النقل في مسار مستقل. تناولت RFC 6614، التجريبية الصادرة في مايو 2012، نقل RADIUS عبر TLS مع بقاء قدرة الوسطاء على معالجة الرسائل. ثم عرّفت RFC 9765، التجريبية الصادرة في أبريل 2025، ملف RADIUS/1.1 لاتصالات TLS وDTLS، وأزالت ضمنه آليات الحزم القديمة المبنية على MD5 والأسرار المشتركة.

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

قيمة Proxy-State في هذه القصة أنها جعلت الالتزام المشترك واضحاً من دون أن توسع معناه أكثر مما يحتمل. احفظ ما يخص غيرك، وأعده كما ينبغي، واسترد ما أضفته أنت. أما تفسير كل حالة خاصة أو منح الثقة للسلسلة بأكملها، فليس عملاً تؤديه علامة في حزمة.