اجتازت الشهادة الاختبار. وبقي المنفذ مغلقاً.

الخلاصة

• يحدد RFC 5216 مصادقة EAP-TLS القائمة على الشهادات واشتقاق المفاتيح. نجاح التحقق من المسار وCertificateVerify وFinished يثبت وقائع تشفيرية ضيقة، ولا ينشئ VLAN أو ACL ولا يفتح المنفذ المتحكم فيه.
• تحذر بنية EAP وAAA نفسها من دمج النتائج: قد تصح المصادقة ثم يُرفض التفويض، وقد يصل Access-Accept إلى جهاز لا يملك الخدمة المطلوبة، وقد توجد مادة مفتاحية لدى طرف من دون أن يثبت ذلك حقه في حيازتها.
• يحتاج التشغيل إلى سلسلة إيصالات من سياسة الشهادة إلى نتيجة EAP وقرار AAA وتنفيذ NAS ثم حركة فعلية. لا يجوز لمؤشر «قُبلت الشهادة» أن يرث سلطة المراحل اللاحقة.

أربع لحظات لا تختصرها إشارة خضراء

لنتصور حدث نفاذ مُركباً لأغراض التحليل. عند 08:14:02 يتحقق النظير من مسار شهادة خادم EAP ومن اسمه، ويتحقق الخادم من شهادة النظير. يثبت CertificateVerify امتلاك المفتاح الخاص، وتثبت رسائل Finished أن الطرفين وصلا إلى المحضر المحمي نفسه. تعرض لوحة التشفير اللون الأخضر.

عند 08:14:03 يقيّم نظام الخلفية الهوية الموثقة مع هوية جهاز NAS والمنفذ والخدمة المطلوبة. يصدر تفويضاً مشروطاً لدور محدد وشبكة VLAN بعينها. تعرض لوحة السياسة لوناً أخضر ثانياً.

عند 08:14:04 يجد جهاز الحافة أن VLAN المطلوبة غير موجودة في سياق التمرير المحلي. لا يستطيع تنفيذ التفويض، فيبقى المنفذ المتحكم فيه مغلقاً. لا تبدأ DHCP، ولا تتكون مجاورة IPv6، ولا تعبر حزمة تطبيق واحدة.

عند 08:14:20 تعرض لوحة تنفيذية مبنية على الحدثين الأولين عبارة «نجحت EAP-TLS». العبارة ليست مختلقة، لكنها رُفعت من حقيقة عن الهوية ونية السياسة إلى ادعاء عن خدمة مسلّمة. هنا يقع الخطأ الإداري لا في التشفير.

هذا المشهد ليس وصفاً لمشغل أو منتج أو عطل حقيقي. إنه تركيب لحدود منصوص عليها في RFC 5216 وRFC 3748 وRFC 3579 وإطار إدارة مفاتيح EAP. يمكن لكل مكوّن أن يعمل على نحو صحيح، ثم تكون الجملة الجامعة خاطئة.

ماذا تقول الشهادة فعلاً

تستخدم EAP-TLS بروتوكول TLS للمصادقة المتبادلة بالشهادات، والتفاوض المحمي على خوارزميات التشفير، وتبادل المفاتيح واشتقاقها. في تبادل متبادل كامل، يجيب فحص مسار الشهادة عن سؤال محدد: هل تنتهي الشهادة المعروضة إلى مرساة ثقة يقبلها المدقق ضمن سياسته الحالية؟ ويجيب CertificateVerify: هل يستطيع الطرف إنتاج توقيع صحيح بالمفتاح الخاص المقابل؟ أما Finished فيربط الطرفين بمحضر المصافحة وأسرارها المتفق عليها.

هذه أدلة قوية، لذلك يجب ألا تُهدر بتوسيع معناها. يمكن أن يوفر الاسم في Subject أو SAN مدخلاً موثقاً للسياسة. لكنه لا يحمل حالة منفذ المحول الآن، ولا سعة VLAN، ولا نتيجة تثبيت ACL، ولا سلامة سلسلة وسطاء AAA، ولا وصول تطبيق بعيد.

تطورت تفاصيل الطريقة من دون أن يتغير هذا الحد. ألغى RFC 8996 الاعتماد على TLS 1.0 و1.1. وشرح RFC 9190 استعمال TLS 1.3 وتغير المصافحة وجدول المفاتيح، مع بقاء RFC 5216 أساساً للإصدارات الأقدم المتفاوض عليها. وأضاف RFC 9965 أعمال تهيئة مرتبطة بـeap.arpa. لم يحوّل أي تحديث منها المصادقة التشفيرية إلى مراقب شامل للخدمة.

قسم التفويض في RFC 9190 مهم لأنه ينطبق على EAP-TLS عموماً. يجب أن تقوم المحاسبة والتفويض على معلومات موثقة، كشهادة أو هوية PSK أو حالة استئناف جرى تهيئتها، لا على EAP-Response/Identity غير الموثقة وحدها. وقد يضم الخادم إلى ذلك سياقاً من البروتوكول الحاضن: هوية authenticator أو MAC أو IP أو المنفذ أو SSID.

إضافة هذا السياق ليست ضعفاً في المصادقة. إنها إقرار بأن المصادقة تنتج مدخلات للسياسة ولا تستهلك كل قرار يليها.

لقد فصل EAP بين النجاح والإذن منذ البداية

يفصل RFC 3748 تزامن نتيجة المصادقة عن تزامن التفويض. وقد لا يرى خادم EAP قراراً اتخذه وسيط AAA. وقد ينتظر خادم AAA نجاح المصادقة ثم يكتشف أن التفويض غير ممكن. وقد تسمح الخلفية بالنفاذ بينما يعجز authenticator مؤقتاً عن تقديم الخدمة.

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

ينمذج RFC 4137 آلات حالة EAP لدى النظير وauthenticator وإشاراتها إلى الطبقة الأدنى. خرج آلة الحالة يظل حدث واجهة. فهو يخبرنا بما خلصت إليه آلة EAP، ولا يفحص خفيةً نسيج التحويل أو توزيع العناوين أو مسار التطبيق.

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

وجود المفتاح لا يحمل تفويضه داخله

تشتق EAP-TLS مفتاح الجلسة الرئيسي MSK والمفتاح الممتد EMSK. حداثتهما وربطهما بالمحادثة أمران حاسمان، لكن RFC 5247 يقسم الرحلة إلى مراحل. تشتق طريقة EAP المادة بين النظير والخادم، وتنقل AAA المادة المناسبة إلى authenticator، ثم يثبت بروتوكول الارتباط الآمن الحيازة ويبني مفاتيح مؤقتة.

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

يجعل RFC 4962 تفويض النظير وauthenticator شرطاً منفصلاً. ويفصل RFC 4017 بين المصادقة المتبادلة وقوة المفتاح والتفويض في متطلبات WLAN. أما RFC 5295 فيقيد المفاتيح الجذرية المشتقة من EMSK بالغرض والنطاق، بدلاً من اعتبار الحيازة إذناً عاماً.

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

Access-Accept تعليمة إلى حافة محددة

في تصميم pass-through شائع، ينقل NAS رسائل EAP بين النظير وخدمة RADIUS في الخلفية. يميز RFC 3579 بين Access-Accept وAccess-Reject من جهة، ومادة EAP المغلفة من جهة أخرى. يفرض الرفض منع النفاذ، بينما ينهي القبول مرحلة المصادقة وقد يحمل صلاحيات يجب تطبيقها على الحافة.

لكن جهاز الحافة ليس طابعة صامتة. ينص RFC 3579 على أن NAS غير القادر على تقديم خدمة مطلوبة يجب أن يعامل Access-Accept الذي يطلبها كما لو كان Access-Reject. كما يحذر RFC 3580 من تعارض نوع حزمة RADIUS مع EAP Success أو Failure داخلها؛ ويجب أن يبني authenticator ضبط النفاذ على نتيجة RADIUS، لا على الرسالة الداخلية وحدها.

الدور أو VLAN أو المرشح أو حد الجلسة العائد من الخادم هو تعليمة سياسة، ويجب رصد نجاحها حيث تُنفذ. يثبت سجل الخلفية أنها أرسلت التعليمة. ولا يثبت أن NAS فهم كل attribute، أو كان يملك المورد المحلي، أو ثبّت السياسة الصحيحة، أو فتح المنفذ المتحكم فيه.

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

قد يصف NAS شبكتين مختلفتين

الفجوة أوسع من VLAN مفقودة. يعالج RFC 6677 حالة authenticator يصف شبكة للنظير وأخرى لبنية AAA، وهي مشكلة «NAS الكاذب» أو «المزود الكاذب». يسمح channel binding للنظير والخادم بمقارنة رؤيتهما لخصائص الشبكة ذات الصلة ضمن نقل محمي.

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

ولا يصبح channel binding إيصال تسليم. يمكنه التحقق من سياق معرف قبل أن ينضم النظير إلى شبكة مخادعة، لكنه لا يثبت أن VLAN المختارة مررت الحركة لاحقاً، أو أن الجدار الناري قبل التطبيق، أو أن الخدمة بقيت متاحة بعد خمس دقائق.

يقيد RFC 7542 معالجة Network Access Identifier. ويحدث RFC 9427 استعمال TLS 1.3 عبر طرق EAP المعتمدة على TLS. تحسن هذه النصوص الهويات والانتقالات، ولا تلغي تعدد السلطات.

الاستئناف يمد علاقة ولا يجمد الصلاحية

يقلل TLS 1.3 resumption زمن الجولة ويمكن أن يتجنب إعادة الشهادة كاملة. يعد RFC 9190 الاستئناف المقبول مصادقاً ومرتبطاً بأمان بالمصادقة أو الاستئناف السابق. لكنه يطلب أيضاً ألا تمنح الجلسة المستأنفة صلاحية أوسع مما كان مقصوداً للأصل.

تختلف الساعات: قد تبقى التذكرة صحيحة تشفيرياً بعد سحب شهادة، أو تغيير دور جهاز، أو انتهاء عمل موظف، أو انتقال NAS، أو تعديل سياسة SSID، أو إزالة VLAN. مدة الشهادة ووقت بيانات الإبطال وعمر التذكرة وعمر التفويض والجلسة على المنفذ ونتيجة التطبيق ليست ساعة واحدة.

يقوي RFC 9190 معالجة الإبطال مع TLS 1.3 ويناقش OCSP stapling لأن النظير قد لا يملك اتصالاً عاماً قبل اكتمال المصادقة. تكشف الدائرة شيئاً مهماً: تحتاج منظومة البدء أحياناً إلى دليل مجهز قبل أن تصبح الشبكة متاحة. نجاح البدء لا يثبت ما سلّمته الشبكة بعد الفتح.

سلسلة إيصالات تسمح للفشل أن يظهر

يجب أن يسجل إيصال الشهادة مرساة الثقة وهاش الورقة والمسار والاسم المدقق ونافذة الصلاحية وطريقة الإبطال ونتيجتها. ويسجل إيصال TLS الإصدار والخوارزمية ونتيجة CertificateVerify وFinished ومعرّف جلسة آمن، من دون تسريب الأسرار.

يسجل إيصال EAP الطريقة والنتيجة المحمية ومعرفات المفاتيح المصدرة وSuccess أو Failure. ويسجل إيصال AAA هوية النظير الموثقة وهوية NAS والمنفذ والسياق وإصدار السياسة وAccept أو Reject وكل attributes. أما إيصال نقل المفتاح فيبين أي authenticator أُذن له بتلقي أي مادة مقيدة.

يقع إيصال التنفيذ عند NAS: هل تعرّف attributes؟ هل حُل الدور أو VLAN؟ هل ثُبت ACL؟ هل اكتمل الارتباط الآمن؟ هل تغيرت حالة المنفذ؟ ثم يأتي إيصال الخدمة: توزيع العنوان، حالة ARP أو neighbour، DNS، المسار، أول تبادل تطبيقي ناجح وسبب الفشل.

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

المصادر

1. RFC 5216
2. RFC 5216 في IETF Datatracker
3. حالة RFC 5216
4. تاريخ RFC 5216
5. تصحيحات RFC 5216
6. RFC 9190
7. RFC 3748
8. RFC 5247
9. RFC 4017
10. RFC 6677
11. RFC 8996
12. RFC 9965
13. RFC 7542
14. RFC 3579
15. RFC 3580
16. RFC 4137
17. RFC 4962
18. RFC 5295
19. RFC 9427
20. Heng Lu — Running-Code Primacy
21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption