الخلاصة

  • يفصل RFC 5281 بين مصافحة TLS ومرحلة بيانات محمية داخل EAP-TTLSv0. في الفرع الشائع الذي لا يستخدم شهادة عميل، تصادق المرحلة الأولى على خادم TTLS، بينما لا تصل هوية المشترك ودليلها إلا في المرحلة الثانية.
  • يحتاج إثبات الوصول القابل للدفاع إلى ربط هوية التوجيه الخارجية، والتحقق من الشهادة، والطريقة والهوية الداخليتين، وقرار AAA، والتفويض، وتسليم المفاتيح، وتطبيق نقطة الوصول، وحركة المرور المرصودة. لا يملك أي نجاح مبكر نتيجة المراحل اللاحقة.

انتهاء المصافحة أتاح طرح السؤال ولم يُجب عنه

المرحلة الأولى من EAP-TTLSv0 هي مصافحة TLS. يعرض خادم TTLS شهادته، ويتحقق العميل من سلسلة الثقة والاسم المتوقع والسياسة المعتمدة. أما شهادة العميل فاختيارية. بعد تبادل ChangeCipherSpec وFinished تصبح طبقة السجلات جاهزة لحماية الرسائل التالية.

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

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

ينتمي RFC 5281 إلى فئة Informational ويسجل ممارسة تاريخية. لم تعد إجازته القديمة لـ TLS 1.0 وTLS 1.1 توجيهاً صالحاً؛ يحظرهما RFC 8996، ويحدّث RFC 9427 اشتقاق المفاتيح ومعالجة النتائج في EAP-TTLS مع TLS 1.3. تحديث التشفير لا يزيل الحدود بين هوية الخادم وهوية المشترك والتنفيذ اللاحق.

الاسم الأول عنوان توجيه لا شهادة شخصية

قبل إنشاء النفق قد تطلب نقطة الوصول رسالة EAP-Response/Identity مكشوفة. ولحماية الخصوصية، يجيز RFC 5281 حذف اسم المستخدم الحقيقي أو إرسال قيمة مجهولة، مع الاحتفاظ بجزء realm اللازم لتوجيه الطلب إلى المزود المناسب.

تجيب الهوية الخارجية عن سؤال «إلى أي نطاق إداري نرسل المحادثة؟»، لا عن سؤال «من هو صاحب الطلب؟». تظهر الهوية الداخلية داخل القناة المحمية، ثم تصل إلى سلطة AAA التي تختبر الدليل وفق سياستها.

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

حماية النفق تنتهي عند خادم TTLS

يحمي TLS بيانات AVP الداخلية حتى خادم TTLS. هناك تُفك السجلات ويصبح المحتوى واضحاً، ثم تُرسل مواد المصادقة الملائمة إلى AAA/H بواسطة RADIUS أو Diameter أو ناقل AAA آخر. قد يكون خادم TTLS والسلطة المنزلية مكوّناً واحداً، وقد يفصل بينهما نظام أو وكلاء متعددون.

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

كما أن خادم TTLS ليس أنبوباً شفافاً. فهو يرى بيانات الاعتماد، ويحوّل سياقات AVP، ويقرر ما يمرره. يحذر RFC 5281 من أن الرمز نفسه لا يعني بالضرورة الشيء نفسه في EAP-TTLS وفي بروتوكول backend؛ ولا يجوز نسخ AVP من سياق إلى آخر من دون فهم الدلالتين. تطابق البنية لا يثبت حفظ المعنى.

قد تتكون المصادقة من سلسلة قرارات

يمكن لـ AAA/H أن يتحدى أو يقبل أو يرفض. يعود التحدي عبر خادم TTLS إلى القناة المحمية، ويرسل العميل رداً آخر. بعد اكتمال التبادلات التي تفرضها السياسة، يحول خادم TTLS النتيجة إلى EAP-Success أو EAP-Failure في السياق الخارجي.

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

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

أما الخطأ المعاكس فأخطر: حفظ جلسة أكملت TLS ثم فشلت في مصادقة المستخدم بوصفها قابلة للاستئناف. يصف RFC 5281 عاقبة ذلك بأنها كارثية. يجب أن تأتي أهلية الاستئناف من نجاح مصادقة المشترك، لا من نجاح المصافحة وحدها.

إمكان اشتقاق المفتاح ليس إذناً باستعماله

يمكن اشتقاق MSK وEMSK من سر TLS والقيم العشوائية. وعند النجاح الكلي تُرسل مواد مفاتيح اتصال البيانات ومعلومات التفويض إلى نقطة الوصول عبر ناقل AAA.

هاتان حقيقتان مختلفتان. قد يحسب البرنامج وحدات البايت المرشحة قبل أن تسمح السياسة باستخدامها. وقد يرتبط المفتاح بجلسة خاطئة، أو يصل مع جيل قديم من التفويض، أو لا تركبه نقطة الوصول، أو يحمي وصلة لا تقدم خدمة مفيدة.

السؤال السليم ليس «هل وُلّد مفتاح؟» فقط. يجب أن يبيّن السجل أي transcript وهويات أنتجته، وأي قرار سمح بتوزيعه، وأي جلسة وصول استهلكته، وأي سياسة رافقته، وأي حركة مرور أثبتت النتيجة المقصودة.

يصل النجاح إلى العميل والمنفذ عبر طريقين

عندما يقبل AAA/H المشترك، يرى العميل عادة EAP-Success. وتتلقى نقطة الوصول عبر مسار AAA قرار القبول والمفاتيح وقيوداً مثل الشبكة المنطقية والمرشحات والمدة وعرض النطاق. ينشأ المخرجان من الحكم نفسه، لكنهما يسلكان طريقين إلى جهتين مختلفتين.

لا يثبت EAP-Success لدى العميل أن نقطة الوصول طبقت التفويض نفسه. ولا يثبت وصول Access-Accept أن المرشحات أو VLAN أو القيود رُكبت فعلاً. وحتى تفعيل حماية الوصلة لا يثبت نجاح العنوان أو المسار أو DNS أو التطبيق.

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

نجاح الطبقتين لا يعني أنهما مرتبطتان تشفيرياً

يسجل RFC 5281 قيداً في EAP-TTLSv0 الأساسي: لا يوجد ربط تشفيري بين مصادقة TLS الخارجية والمصادقة الداخلية. إذا كان دليل اعتماد صالحاً داخل النفق وخارجه، فقد يعيد مهاجم تمريره في سياق آخر. يوصي المستند بعدم إعادة الاستخدام هذه وبالاستعانة بامتدادات تربط الطبقتين.

لا يعني ذلك أن كل جلسة EAP-TTLS مزورة. لكنه يفرق بين قولين: «نجحت الخطوتان» و«ثبت أن الخطوتين تنتميان إلى السياق نفسه». لا ينبغي إسقاط ضمانات طرق نفقية أحدث على النسخة الأساسية بأثر رجعي.

ابنِ سجل الوصول وفق انتقال السلطة

ينبغي أن يحفظ أي قرار وصول مهم ما يلي:

  • هويات العميل ونقطة الوصول وخادم TTLS وAAA/H؛
  • الهوية الخارجية المكشوفة وrealm ومسار الوكلاء؛
  • سلسلة شهادة الخادم وسياسة الاسم المتوقع ونتيجة التحقق؛
  • إصدار TLS ومجموعة التعمية وtranscript واكتمال المرحلة الأولى؛
  • وجود شهادة عميل والدور الذي أدته؛
  • كون الجلسة جديدة أو مستأنفة، والمصادقة والتفويض الموروثين؛
  • الهوية الداخلية وترتيب الطرق والتحديات والنتائج؛
  • معرّف معاملة TTLS–AAA ودليل حماية الناقل؛
  • القبول أو الرفض، وجيل السياسة، والتفويض المعاد؛
  • EAP-Success أو EAP-Failure كما رآه العميل؛
  • تسليم MSK وربطه بجلسة نقطة الوصول الصحيحة؛
  • المرشحات وتعيين الشبكة والوقت وعرض النطاق المنفذة فعلاً؛
  • تفعيل حماية الوصلة وحركة المرور الثنائية؛ و
  • نتيجة التطبيق التي يتطلبها الادعاء التشغيلي.

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

Sources