الخلاصة

  • تلزم النسخة 18 من مسودة RadSec عميل البروتوكول بإسقاط الرد الذي يفشل التحقق من Response Authenticator، مع إبقاء اتصال (D)TLS مفتوحاً. ويسري إبقاء الاتصال أيضاً على الرد الذي لا يقابله طلب معلّق. النص قيد تقييم IESG ولم يصبح RFC معتمداً.
  • يفسر ملحق جديد احتمال السباق: تنقضي مهلة طلب، فيعاد استعمال Identifier ذي البايت الواحد لطلب آخر؛ ثم يصل الرد القديم ويُفحص في سياق الطلب الجديد. لا يجعل هذا الرد مقبولاً، ولا يعفي من قطع الاتصال عند فشل Message-Authenticator في حالة ينطبق عليها فحصه.

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

في نص 30 سبتمبر 2026، نقلت RADEXT هذا الخطأ من خانة الإغلاق إلى خانة الإبقاء على الاتصال. تنص الفقرة 3.12 من draft-ietf-radext-radiusdtls-bis-18 على وجوب إسقاط الرد ذي Response Authenticator غير الصالح مع ترك الاتصال قائماً. وكذلك الرد الذي لا يجد طلباً معلقاً يطابقه. النسخة 17 كانت تضع الخطأ الأول بين أسباب الإغلاق، وتترك إغلاق الاتصال أو إبقاءه في الحالة الثانية خياراً للتنفيذ. الملحق A.1 الجديد يشرح ترتيب انتهاء المهلة، وإعادة تخصيص المعرّف، ووصول الرد السابق. هذا تغيير في مدى العقوبة، لا إلغاء للتحقق الأمني.

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

لا ينبغي قراءة قاعدة الإبقاء كإذن بتمرير الرد. الرد يفشل ويسقط. إذا أخفق Response Authenticator، يصبح فحص Message-Authenticator لذلك الرد المسقط غير مؤثر في مصيره. لكن عندما يكون ربط الرد بالطلب صالحاً ويفشل Message-Authenticator، يبقى إغلاق الاتصال مطلوباً. وإذا اعتبر الخادم العميل غير مقبول، فعليه إنهاء (D)TLS فوراً، وإن كان النقل RADIUS/TLS أغلق TCP أيضاً. الخلط بين الرد المتأخر والإخفاق الحقيقي في سلامة الرسالة يبدد التمييز الذي أضافته المراجعة.

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

يسجل Datatracker الوثيقة مسودة نشطة لفريق RADEXT، مقدمة إلى IESG وفي حالة IESG Evaluation::AD Followup، وتستهدف مرتبة Proposed Standard. أما استبدال RFC 6614 وRFC 7360 فمشروط بموافقة لاحقة. قيمة الخبر هنا محددة: فشل حزمة واحدة قد يسوّغ رفضها، لكنه لا يمنح وحده سلطة سحب الثقة من الاتصال كله.

المصادر