الخلاصة
- عندما يقبل الخادم استئناف جلسة TEAP، تنص RFC 9930 على تجاوز المرحلة الثانية بالكامل؛ لذلك يجب أن تظل التذكرة مرتبطة بنجاح المصادقة الداخلية وبأساس التفويض المطلوب الآن.
- إذا تعذر ربط بيانات الاعتماد الجديدة بالتذكرة، فيجب على الخادم إبطالها وإجبار الاتصال التالي على إجراء مصادقة كاملة.
يعالج الاستئناف تكلفة تشغيلية حقيقية. ففي البيئات التي يعيد فيها المستخدمون والأجهزة الاتصال مرات عدة يومياً، يؤدي تكرار كل طرق المصادقة الداخلية إلى ضغط متواصل على مخزن الهوية. لهذا تُلزم RFC 9930 كل تطبيقات TEAP بدعم الاستئناف، وتربطه بتحسين قابلية التوسع والاستقرار. لكن دعم القدرة لا يعني قبول كل تذكرة تُعرض على الخادم.
تقسم جلسة TEAP الكاملة العمل إلى مرحلتين. تنشئ المرحلة الأولى نفق TLS محمياً ومصادقاً عليه. وفي المرحلة الثانية تنتقل الطرق الداخلية وعناصر TLV التي يمكنها مصادقة الجهاز أو المستخدم أو كليهما، وإصدار بيانات اعتماد أو تغييرها، وتنفيذ Crypto-Binding، وتبادل نتائج محمية. تحدد RFC 6678 متطلبات طريقة EAP نفقية معيارية، بينما تحدد RFC 3748 الأدوار ونموذج النجاح والفشل في EAP. إنشاء النفق لا يثبت اكتمال ما يجب أن يحدث داخله.
تأتي فائدة الاستئناف من حذف هذا العمل. فإذا وافق الخادم على الاستئناف، تُتجاوز المرحلة الثانية كلها. وإذا رفض، يُكمل الطرفان مصافحة TLS كاملة ثم يجب عليهما تنفيذ المرحلة الثانية. قد تبقى الحالة لدى الخادم، أو تحملها تذكرة لدى العميل وفق آلية مثل RFC 5077. وفي TLS 1.3، تنشئ رسالة NewSessionTicket في RFC 8446 حالة مرتبطة بمفتاح مشترك مسبقاً لاتصال لاحق. هذه الاستمرارية التشفيرية لا تعلن أن كل شروط الوصول بقيت كما كانت.
وقد تصدر التذكرة قبل المصادقة الداخلية أصلاً. توضح RFC 9427 أن TLS 1.3 يسمح بإرسال NewSessionTicket بعد رسالة Finished من العميل، في حين قد لا تكون الطريقة الداخلية قد نُفذت بعد. يستطيع عميل الحصول على التذكرة ثم قطع الجلسة ومحاولة استئنافها من دون اجتياز الفحص الداخلي. لذلك يجب ألا يسمح الخادم باستئناف المصادقة ما لم تنجح المصادقة الداخلية. والأفضل تأخير إصدار التذكرة؛ وإذا حالت مكتبة TLS دون ذلك، فيجب إبطال تذاكر الجلسات الفاشلة أو التخلص منها. وإذا لم تكشف التذكرة حالة المصادقة، فعلى الخادم افتراض عدم اكتمالها وتشغيل الطرق الداخلية قبل منح الوصول.
ولا يحل Crypto-Binding محل قرار التفويض. بعد نجاح كل طريقة داخلية، تفرض RFC 9930 تبادل Intermediate-Result وCrypto-Binding. يربط Compound MAC المشاركين بالنفق وتسلسل المصادقة، ويمكنه كشف الاستبدال أو انقطاع الربط. لكنه لا يختار VLAN أو ACL أو دوراً أو حالة حساب أو خدمة مسموحاً بها. وحتى بعد Result TLV ناجح، يستطيع النظير طلب إجراء إضافي إذا لم تُستوف سياسته، ويبقى رد الخادم خاضعاً لسياسته المحلية.
تستمر المشكلة الزمنية حتى بعد جلسة أولى صحيحة تماماً. تستطيع المرحلة الثانية إصدار بيانات اعتماد أو تغييرها، لذلك يجب أن يعتمد التفويض اللاحق على بيانات الاعتماد التي تمت مصادقتها، لا على هوية مجهولة أو مختلفة في المرحلة الأولى. ويجب تطبيق التفويض الصحيح عند الاستئناف أيضاً: تُربط بيانات الاعتماد الجديدة بتذكرة الجلسة. فإذا تعذر الربط، وجب على الخادم إبطال تذاكر الجلسة الحالية. يعود الاتصال التالي إلى المصادقة الكاملة، وعندها يمكن إسناد أساس تفويض حديث وقابل للتفسير إلى تذكرة جديدة.
توسع RFC 9190 نطاق الفحص ليشمل المعلومات التي قد تتغير بين المصافحة الأولى والاستئناف: بيانات النظير، وجهة المصادقة، والطبقات المحيطة. إذا أمكن للتغيير أن يبدل قرار التفويض أو المحاسبة أو السياسة، فيجب إعادة تقييم القرار. وعندما يتعذر الوصول إلى قرار آمن، ينبغي رفض الاستئناف ومتابعة مصافحة كاملة. الحد الأقصى البالغ سبعة أيام لتذكرة TLS 1.3 ليس تصريح وصول لمدة سبعة أيام.
ينبغي أن يعيد السجل التشغيلي بناء السلسلة: بصمة التذكرة أو Session ID، الجهة المصدرة، وقت الإصدار والانتهاء، الجلسة الكاملة الأصلية، نجاح المصادقة الداخلية، إصدارات بيانات الاعتماد والسياسة، سياق جهة المصادقة، التغييرات اللاحقة، نتيجة إعادة التقييم، وسبب القبول أو الرفض أو الإبطال. ثم يُسجل التفويض الحالي بصورة منفصلة، وكذلك إيصال تطبيق NAS وملاحظة حركة البيانات أو الخدمة. تساعد RFC 5247 في تحديد سياق مفاتيح EAP وهوياته، لكنها لا تثبت هذه الآثار اللاحقة.
يضع مبدأ Heng Lu للمواصفة الأولية الدنيا حداً مناسباً: تحمل التذكرة المشتركة حالة محدودة تكفي للتشغيل البيني، بينما يظل القرار المستقبلي محلياً وخاضعاً للمساءلة. يجب أن يبين الكود العامل ما قرأه فعلاً، وأن تبقى طبقات الواقع منفصلة: التذكرة، وبيانات الاعتماد المصادق عليها، والسياسة الحالية، والتفويض، والتنفيذ، والنتيجة. الاستئناف الموثوق هو اختصار يمكن شرح ما حذفه ولماذا كان الحذف آمناً.
Sources
- https://www.rfc-editor.org/rfc/rfc9930.html
- https://www.rfc-editor.org/rfc/rfc9427.html
- https://www.rfc-editor.org/rfc/rfc9190.html
- https://www.rfc-editor.org/rfc/rfc8446.html
- https://www.rfc-editor.org/rfc/rfc5077.html
- https://www.rfc-editor.org/rfc/rfc3748.html
- https://www.rfc-editor.org/rfc/rfc5247.html
- https://www.rfc-editor.org/rfc/rfc6678.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

