لماذا احتاج الخادم إلى قيمة عشوائية ثالثة: RFC 3163

الخلاصة

• في النمط المتبادل، وقّع العميل تحدي الخادم وقيمة عشوائية أنشأها للتو. وغطّى توقيع الخادم النهائي القيمتين، لكنه أضاف ثالثة لأن العميل كان يعرف التحدي الأول قبل أن يختار قيمته.
• ربطت القيمة الثالثة رد الخادم بمساهمة عشوائية جديدة، لكنها لم تجعل الآلية قناة آمنة: لا توفر RFC 3163 سلامة الرسائل أو سريتها، وتقر بإمكان وقوع هجمات نشطة.

قيمة تبدو زائدة

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

تجيب RFC 3163، «ISO/IEC 9798-3 Authentication SASL Mechanism»، بالرجوع إلى ترتيب الاختيارات. ليست المسألة عدد الرسائل، بل أي طرف كان يعرف تحدي الطرف الآخر حين اختار قيمته العشوائية. فهذا الترتيب يحدد ما الذي يمكن للتوقيع إثباته عن التبادل.

تعرّف المذكرة التجريبية المنشورة في أغسطس 2001 عائلتين من آليات SASL. تصادق 9798-U-<algorithm> على العميل لدى الخادم. أما 9798-M-<algorithm> فتضيف مصادقة متبادلة: يوقّع العميل تحدياً أرسله الخادم، ثم يوقّع الخادم تحدياً أنشأه العميل. تستخدم الآليتان توقيعات بالمفتاح العام وشهادات X.509، وتشمل خطوات التحقق الموصوفة معالجة مسار الشهادة.

ترتيب القيم الموقّعة

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

في النمط الأحادي ينتهي التبادل الأساسي عند رمز العميل. أما النمط المتبادل فيضيف رداً من الخادم: يحمل TokenBA2 شهادة الخادم وتوقيعاً يغطي R_A وR_B وقيمة جديدة هي R_C. ويتحقق العميل من الشهادة والتوقيع، ثم يتأكد من تطابق القيمتين السابقتين مع الخطوات الأولى، ومن صحة معرّف العميل الاختياري.

تشرح الفقرة 7 سبب إضافة R_C. فتضمين R_A في البيانات التي يوقّعها العميل يمنع الخادم من الحصول على توقيع العميل على بيانات اختارها الخادم قبل بدء الآلية. لكن الاتجاه العكسي غير متماثل: كان العميل يعرف R_B قبل اختياره R_A. لا بد من أن يتضمن توقيع الخادم R_B حتى يستطيع العميل التحقق من سجل التبادل، لكن هذه القيمة وحدها لا تمنح الخادم الحماية ذاتها. لذلك أضافت RFC 3163 القيمة R_C إلى TokenBA2 الذي يوقّعه الخادم.

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

التوقيع لا يحمي الجلسة

الحد واضح في النص. تقول RFC 3163 إن الآلية توفر المصادقة فقط. فهي لا تضمن سلامة رسائل البروتوكول اللاحقة ولا سرية محتواها. ويحصر قسم الأمن الحماية في التنصت السلبي، ويذكر أن الهجمات النشطة، ومنها اختطاف الجلسة، تظل ممكنة. وملاحظة IESG أشد صراحة: تتحمل الآلية تعقيد البنية التحتية للمفاتيح العامة ثم تتخلى عن سلامة كل عملية إرسال؛ بينما يمكن لـTLS توفير الأثر نفسه مع مزايا سلامة إضافية.

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

كما أن مثال IMAP في RFC لا يعرض النمط المتبادل. فهو مثال للمصادقة الأحادية 9798-U، وينص على أن ترميز Base64 والرمز + قبل الرد جزء من ملف IMAP، لا من آلية SASL. المثال توضيحي ولا يثبت الانتشار أو قابلية التشغيل البيني.

تُستخدم Note 20 لـLu Heng هنا كعدسة تفسيرية فحسب: الفصل بين ما يتحقق منه البروتوكول فعلياً وبين الادعاءات الأوسع عن الهوية أو السلطة. تطابق القيم العشوائية والتوقيعات المتحقق منها دليل ضمن سجل التبادل؛ أما حماية القناة وصلاحيات التطبيق فتحتاج إلى ضوابط أخرى. ولا ننسب هذا المنظور إلى مؤلفي RFC 3163.

المصادر

1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
2. سجل RFC Editor للوثيقة RFC 3163
3. RFC 2222 — Simple Authentication and Security Layer
4. RFC 4422 — Simple Authentication and Security Layer (SASL)
5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
7. RFC 2630 — Cryptographic Message Syntax
8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
11. سجل آليات SASL لدى IANA
12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
13. Lu Heng، Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile