الخلاصة

  • يحذف draft-ietf-emu-eap-ppt-04 الـ128 ثمانية التي اشتقتها المراجعة السابقة من مُصدِّر TLS الخارجي، وينص بوضوح على أن EAP-PPT لا ينتج MSK ولا EMSK.
  • رمز Privacy Pass اعتماد لحامله يُرسل داخل النفق. يرى الطرف المنهي للنفق الرمز ويستطيع حساب قيمة المُصدِّر نفسها، لذلك لا تثبت تلك البايتات أن حامل الرمز ومنهي النفق طرف واحد.

نفّذ المُصدِّر التشفيري المطلوب منه: أعاد 128 ثمانية. لم يكن الخلل في عملية الحساب، بل في السلطة التي كان من الممكن منحها للنتيجة.

كانت المراجعة 03 من Extensible Authentication Protocol (EAP) Using Privacy Pass Token تشتق القيمة من نفق TLS الحامل باستخدام الوسم EXPORTER_EAP_PPT_Key_Material. ضم السياق نوع EAP والرمز المسترد، وكان يمكن للتنفيذ تقديم الناتج بوصفه Master Session Key وExtended Master Session Key صادرين عن EAP-PPT.

تحذف المراجعة 04 المؤرخة في 30 سبتمبر هذا البناء. فهي تقول إن EAP-PPT لا يولد MSK أو EMSK، وإن التنفيذ يجب ألا يبلّغ طريقة النفق بأي مادة مفاتيح لـEAP-PPT. لا يزيل الحذف حماية حقيقية؛ بل يمنع بايتات ذات مظهر مقنع من الادعاء بوجود رابطة لا تدعمها مدخلاتها.

رمز الحامل لا يضيف سراً حصرياً

يعمل EAP-PPT كطريقة EAP داخلية. يحصل النظير على رمز Privacy Pass خارج المسار من جهة إصدار، ثم يدخل نفق TLS موثَّق الخادم توفره طريقة EAP أخرى، ويرسل الرمز إلى خادم EAP-PPT لاسترداده.

يُتحقق من الرمز القابل للتحقق العام بالمفتاح العام لجهة الإصدار. أما الرمز القابل للتحقق الخاص فيعتمد على مادة مشتركة بين جهة الإصدار وخادم EAP-PPT. لا ينشئ أي منهما سراً مشتركاً جديداً بين النظير والخادم. يثبت النظير الحيازة بإرسال اعتماد قابل للنقل، ويقرر الخادم إن كان صالحاً.

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

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

لا يثبت TLS الخارجي هوية النظير الداخلي

يصبح الفرق خطيراً داخل TEAP. يستطيع Crypto-Binding TLV أن يجمع مادة النفق مع مادة طريقة داخلية. فإذا أبلغ EAP-PPT قيمة مشتقة بالكامل من النفق نفسه ومن رمز ظاهر لمنهيه على أنها مفتاح داخلي، بدت النتيجة كأنها تربط دليلين مستقلين، مع أن طرفاً واحداً يملك كل المدخلات.

تشرح المراجعة 04 الإخفاق صراحة. كان الإبلاغ عن القيمة القديمة سيسمح لطريقة النفق بحساب Crypto-Binding TLV من دون ضمان أن EAP-PPT ارتبط بالنفق تشفيرياً. يبدو في مخطط الرسائل أن هناك مساهمين اثنين، بينما يوجد في بنية الأسرار مساهم واحد.

الحد المصحح واضح: يصرّح EAP-PPT للنظير عبر استرداد الرمز، لكنه لا ينتج مفاتيح الوصلة. تأتي مادة مفاتيح الوصلة من طريقة EAP النفقية الخارجية. إذا استمرت منصة في إظهار MSK أو مفتاح شبيه بـexporter لـEAP-PPT، فهي لا تعرض ضماناً إضافياً، بل تعيد الغموض الذي حذفته الوثيقة.

طريقة داخلية بلا مفتاح تغيّر خطر الترحيل

من دون ربط تشفيري داخلي، يصبح التحقق الصارم من شهادة الخادم خط الدفاع الأول ضد relay. إذا أقنع مهاجم النظير بقبول نفق TLS الخاص به، يستطيع تمرير تبادل EAP-PPT إلى خدمة حقيقية، ورؤية رمز الحامل واسترداده للحصول على وصول للمهاجم.

لذلك تشترط المسودة التحقق الصارم والمحدد للشبكة من شهادة خادم EAP. على النظير مطابقة هوية الخادم المتوقعة، ورفض الفشل بدلاً من إحالة القرار إلى المستخدم، وألا يعتمد على الثقة عند أول استخدام. عندما تُملأ origin_info في challenge الخاص بـPrivacy Pass وتُقارن بهوية الشهادة، فإنها تقيد استبدال challenge، لكنها لا تنشئ مفتاحاً داخلياً.

مكان الخوادم جزء من نموذج الثقة أيضاً. جمع خادم EAP وخادم EAP-PPT يزيل سطح فصل يمكن استغلاله داخل مزود واحد. فصل خادمي Phase 1 وPhase 2 غير موصى به من دون علاقة واضحة وبروتوكول محمي بينهما. هذه حدود مسؤولية، وليست مجرد مسألة طوبولوجيا.

يمكن لـchannel binding كشف اختلاف بين الشبكة التي يعتقد النظير أنه انضم إليها والـauthenticator الذي يراه الخادم. تقصر الرموز قصيرة العمر نافذة الخسارة، وقد يكشف رصد الإنفاق المزدوج عملية relay بعد وقوعها. هذه قيود وكواشف مفيدة، لكنها لا تحول مخرج المُصدِّر المحذوف إلى دليل على استمرارية حامل الرمز.

قد يُنفق الرمز قبل حكم السياق

تضيف المراجعة 04 ترتيباً زمنياً قد تخفيه نسبة نجاح عامة. بعد استرداد الرمز بنجاح، يمكن لخادم EAP-PPT إرسال EAP-Request/PPT-Channel-Binding قبل EAP Success. ويمكنه تجاوز الطلب إن كانت طريقة EAP سابقة قد قدمت معلومات مناسبة.

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

«الرمز منفق» إيصال محدود. يثبت نجاح الاسترداد، ولا يثبت نجاح channel binding أو صدور EAP Success أو تثبيت مفاتيح الوصلة الخارجية أو سماح RADIUS/NAS أو مرور حركة فعلية.

عدّ الإنفاق اتصالاً يدمج قرارات مستقلة. واعتبار EAP Success دليلاً على أن الكيان نفسه حمل الرمز وأنهى النفق يكرر في القياس المبالغة التي أزالتها المراجعة 04 من جدول المفاتيح.

تغيّر المراجعة 04 أكثر من الترميز

تستبدل النسخة الجديدة محتوى JSON بـTLV على نمط TEAP، وتحمل بنى Privacy Pass مباشرة بدلاً من تغليفها في base64url. تضيف No-Suitable-Token TLV، وقواعد للطول والتكرار والاستهلاك الكامل ومستوى واحد من التداخل، وسياسة M-bit للعناصر المجهولة، ومتجهات اختبار على مستوى الثمانيات.

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

لا تساوي الدقة على السلك دليلاً على النشر. الوثيقة Internet-Draft نشطة ضمن مجموعة عمل EMU وتهدف إلى Proposed Standard. ما زالت حالتها في Datatracker هي I-D Exists، ولا يوجد مدير منطقة مسؤول أو shepherd أو telechat. ليست RFC، ولا تثبت المصادر المجمدة تنفيذاً أو قابلية تشغيل بيني أو أداءً أو اعتماداً.

يجب أن يربط التشغيل إيصالات منفصلة

يحفظ التشغيل القابل للتدقيق بصورة منفصلة: الشبكة المهيأة واسم خادم EAP المتوقع؛ الشهادة المتحقق منها ومرساة الثقة ونقطة TLS الفعلية؛ challenge وorigin_info؛ نوع الرمز ومفتاح جهة الإصدار وملخص challenge؛ نتيجة الاسترداد ووقت الإنفاق؛ مصدر channel binding وحكمه؛ EAP Success أو Failure؛ مفاتيح الوصلة الخارجية؛ قرار RADIUS/NAS؛ والوصول المرصود.

تجيب الشهادة عن الخادم الذي قبله النظير. يجيب الاسترداد عن صلاحية الاعتماد. يقارن channel binding سياق الشبكة لدى الجانبين. تنهي نتيجة EAP مرحلة من البروتوكول. وحدهما قرار NAS والحركة يبينان إن كان الوصول قد نُفذ وأصبح قابلاً للاستخدام. لا يستطيع حقل واحد باسم «موثَّق» حمل هذه العلاقات السببية.

لا تقلل هذه القراءة من أهمية المواصفات. قيمة المراجعة 04 أنها ترفض منح مخرج مقنع سلطة لا يملكها. يجب على النظام العامل حفظ الروابط التي لم تستطع الـ128 ثمانية المحذوفة إثباتها قط.

المصادر