الخلاصة

  • يثبت التحقق من CoA-Request أو Disconnect-Request أن رسالة محمية جاءت من نظير معروف؛ ولا يثبت وحده أن ذلك النظير مخول بتغيير هذا المستخدم أو هذا المجال التشغيلي.
  • بعد قرار التفويض، تبقى مجموعة الجلسات والتنفيذ الذري ومعنى ACK أو NAK وأثر الحركة طبقات مستقلة. ويمكن أن يعني NAK + 507 أن تبادل تفويض جديد قد بدأ بنجاح.

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

صمم RFC 5176 رسائل لتغيير حالة موجودة بعد بدء الاتصال. تطلب Disconnect-Request إنهاء الجلسة، بينما تطلب CoA-Request تعديل تفويضها. ولأن الفعل يقع على مستخدم حي، لا يجوز أن تتحول علاقة ثقة تقنية مع الجهاز إلى سلطة غير محدودة على كل حالة يحتفظ بها.

التفويض قرار له دليل مستقل

في نموذج RADIUS/UDP التاريخي، يختار عنوان المصدر السر المشترك وتستخدم بنية Request Authenticator المعتمدة على MD5 للتحقق من الحزمة. ويمكن أن تضيف Message-Authenticator حماية وفق قواعد عائلة RADIUS. أما Event-Timestamp وهوية إعادة الإرسال وكشف التكرار فتعالج حداثة الطلب ومنع إعادة تشغيله.

هذه كلها خصائص أمنية، لكنها لا تحدد نطاق الولاية. يحذر RFC 5176 من أن عميلاً موثقاً تابعاً لمزود واحد لا ينبغي أن يغير مستخدمي مزود آخر على NAS مشترك. ويقترح فحصاً شبيهاً بالمسار العكسي اعتماداً على realm المستخرج من User-Name. ويصحح erratum موثق نقطة دقيقة: Chargeable-User-Identity قيمة معتمة، فلا يجوز تحليلها وكأنها تحمل realm.

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

القناة الجديدة لا تلغي سؤال السلطة

لا ينبغي وصف RADIUS وكأنه بقي محصوراً في MD5 وUDP. يحدّث RFC 9765 النظام إلى RADIUS/1.1 فوق TLS أو DTLS متفاوض عليهما. هناك تحمي القناة الرسالة، ولا يرسل Message-Authenticator. هذا يقلل اعتماد التشغيل على البناء القديم ويقوي هوية النظير.

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

حتى الطلب المخول يحتاج هدفاً صحيحاً

بعد السماح للعميل بالفعل، يبحث NAS عن الجلسات باستخدام User-Name وNAS-Port وFramed-IP-Address وCalling-Station-Id وAcct-Session-Id وChargeable-User-Identity وغيرها. قد لا يجد شيئاً، أو يجد جلسة واحدة، أو يجد عدة جلسات.

إذا وجد عدة مطابقات، يطبق الطلب عليها كلها. يجب أن يكون التغيير ذرياً: تنجح كل التعديلات لكل الجلسات أو لا يتغير شيء. وينطبق الأمر نفسه على الفصل. إذا لم يدعم NAS الاختيار المتعدد، يرسل Error-Cause 508.

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

الرد لا يتكلم إلا من موقعه

Disconnect-ACK هو قول NAS إن سياق الجلسات المختارة أزيل وإنها لم تعد متصلة. وCoA-ACK هو قوله إن تغييرات التفويض المطلوبة نجحت. هذه دلالة تنفيذ قوية وليست إيصال استلام فقط.

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

كما أن NAK ليس لوناً واحداً. مع Authorize Only يجب أن يرسل NAS CoA-NAK مع Error-Cause 507، Request Initiated، حين ينجح في بدء Access-Request جديد. وتحدد Access-Accept أو Access-Reject اللاحقة النتيجة النهائية. بدأ المسار بنجاح، لكن الحكم لم يصدر بعد.

يضيف الوكيل طبقة أخرى من السلطة المحدودة. يوفر RFC 8559 ‏Operator-Name وOperator-NAS-Identifier معتماً لتوجيه الطلب عكسياً إلى NAS الصحيح. هذا يثبت مسار الجهاز، لا هوية جلسة المشترك داخله.

إن احترام حدود كل إيصال ليس ضعفاً. إنه يمنع الرمز من الاستيلاء على واقع لم يرصده: النظير يثبت نفسه، وقاعدة التفويض تثبت ولايته، والمحدد يثبت مجموعته، وNAS يثبت انتقاله، والمحاسبة والحركة تثبتان الأثر.

المصادر