الخلاصة

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

قيمة رئيسية تتوقف قبل حركة البيانات

تنص الوثيقة بوضوح على أن مفاتيح الجلسة الرئيسية لا تشفّر البيانات ولا تفكها. في مسار MS-CHAP-2، يُنتج تجزئة كلمة المرور المزدوجة وNT-Response قيمة رئيسية. ثم يختار GetAsymmetricStartKey فرعاً بناءً على سؤالين: أهو مفتاح إرسال أم استقبال، وهل الطرف المحلي خادم؟ وبعد ذلك ينتج GetNewKeyFromSHA المفتاح العابر الذي يدخل في حالة RC4 المناسبة.

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

نُشرت RFC 3079 في مارس 2001 بوصفها RFC معلوماتية لتقديم مرجع مفتوح للتشغيل البيني مع منتجات Microsoft. أما تفاوض CCP وحزم MPPE وتغيير المفاتيح أثناء الجلسة فكانت ضمن RFC 3078. لم تكن الوثيقة معيار إنترنت ولا دليلاً على الانتشار.

ثلاث سلاسل اعتماد لا يمحوها الناتج

اشتق MS-CHAP-1 فرعي 40 و56 بت من تجزئة LAN Manager، وفرع 128 بت من تجزئة Windows NT والتحدي. واستخدم MS-CHAP-2 سلسلة Windows NT وNT-Response للقوى الثلاث. أما EAP-TLS فبدأ من مادة رئيسية مصدّرة من TLS.

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

حددت RFC 2759 قيم MS-CHAP-2، ووصفت RFC 2433 السلف، ووضعت RFC 2716 EAP-TLS داخل PPP. تثبت هذه الوثائق مدخلات محتملة، لا وصول CCP إلى حالة Opened.

كانت «المصادقة الأولى» جزءاً من هوية الجلسة

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

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

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

الإرسال هنا هو الاستقبال هناك

ربطت الثوابت في GetAsymmetricStartKey الطرفين على نحو متقاطع. فرع إرسال الخادم يقابل استقبال العميل، والعكس بالعكس. وفي قسم EAP-TLS قالت الوثيقة مباشرة إن مفتاح الإرسال في جانب هو مفتاح الاستقبال في الجانب الآخر.

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

لم تكن القوة طولاً فقط. استخدم فرعا 40 و56 بت ثمانية أوكتات؛ استبدل الأول ثلاثة أوكتات أولى بثوابت، والثاني أوكتة واحدة. استخدم 128 بت ستة عشر أوكتة. وفي EAP-TLS كان يجب حشو القيم القصيرة بأصفار من اليسار أو قطع القيم الطويلة. لا يثبت الطول النهائي نسباً متطابقاً.

اختبرت المتجهات المنشورة الحساب، لا الجلسة الحية ولا النقل الآمن ولا نتيجة التفاوض. وحذرت RFC من تكرار مفتاح MS-CHAP-1 الأولي ذي 40 بت مع بيانات الاعتماد نفسها. هذا تحليل تاريخي، وليس توصية حديثة باستخدام RC4 أو MS-CHAP.

تبدأ الخدمة بعد اكتمال الاشتقاق

اشترطت RFC 3078 بلوغ PPP مرحلة Network-Layer Protocol وبلوغ CCP حالة Opened قبل إرسال MPPE. وعالجت RFC 2548 نقل المفاتيح الاتجاهية عبر RADIUS وحيازة الوكلاء لها. وفصلت RFC 1661 مراحل PPP.

نجاح المصادقة، ووصول السر، وربطه بالرابط، ومطابقة الاتجاهين، وتفاوض CCP، وفك التشفير المتزامن، ومعالجة التطبيق إيصالات مختلفة. تمنع قراءة طبقات الواقع لدى Lu Heng الكلمات مثل «رئيسي» و«مرسل» و«مصادق عليه» و«128 بت» من الحلول محل الانتقالات المنفذة.

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

المصادر