الخلاصة

  • يوصي RFC 5422 بعدم منح الوصول في نهاية نمط التهيئة بلا مصادقة الخادم، بينما يجوز منحه بعد النمط الموثّق وفق سياسة الخادم.
  • يبلّغ إقرار Tunnel PAC بنتيجة المعالجة والتخزين التي أعلنها النظير؛ ولا يثبت المصادقة اللاحقة أو قرار السماح بالدخول.

التهيئة لها نهاية مختلفة عن السماح

قد يصل جهاز إلى الشبكة من دون سر مشترك أو جذر موثوق للخادم أو Protected Access Credential. يشرح RFC 5422 كيف يمكن لـEAP-FAST تزويده بهذه المواد. والسؤال الإداري ليس مجرد: هل نجحت المحادثة؟ بل: أي نجاح سجلته؟ الوثيقة تفصل إعداد الاعتماد عن السماح باستخدام موارد الشبكة.

يتألف EAP-FAST من مرحلة TLS أولى ومرحلة EAP داخلية. ويميّز RFC 5422 بين تهيئة يتحقق فيها النظير من الخادم وتهيئة لا يحدث فيها ذلك أولاً. في النمط الموثّق، يتحقق النظير من الخادم أثناء مصافحة TLS؛ وهذا يتطلب وجود مادة ثقة سابقة. أما النمط غير الموثّق فيبدأ بنفق TLS مجهول قائم على Diffie–Hellman، فيسهل التهيئة لمن يفتقد الثقة المسبقة، لكنه لا يثبت هوية الخادم في المرحلة الأولى.

لا يعني ذلك ترك المصادقة. ففي النمط المجهول يجب أن يكمل الطرفان داخل النفق طريقة EAP تحقق المصادقة المتبادلة واشتقاق المفاتيح. ثم يتحقق النظير من Crypto-Binding TLV لربط التبادل الداخلي بسلامة نفق TLS والحد من خطر وسيط نشط. وفي إصدار 2009 اشترط RFC 5422 على تطبيقات هذا النمط دعم EAP-FAST-MSCHAPv2 بوصفه طريقة مصادقة داخلية. النتيجة ذات المعنى هي الربط بين المرحلتين، لا نجاح إحداهما منفردة. (RFC 5422، الأقسام 2 و3.2–3.2.3 و6.1.2؛ RFC 4851)

بعد نجاح المصادقة الداخلية والتحقق من الربط، يمكن للخادم إرسال Tunnel PAC، بما فيه PAC-Key وPAC-Opaque، أو جذور موثوقة للخادم. يستخدم Tunnel PAC لإقامة نفق EAP-FAST لاحق؛ لكنه ليس إذناً بدخول الشبكة.

يرسل النظير PAC-Acknowledgement لإبلاغ الخادم بنتيجة معالجة Tunnel PAC الجديد وتخزينه. ولا يستخدم هذا الإقرار مع أنواع PAC الأخرى. ما يصل إلى الخادم هو تقرير النظير عن التخزين، لا دليل على نجاح مصادقة تالية أو سماح سياسة الوصول أو وصول حركة التطبيق. (RFC 5422، الأقسام 3.2 و4.1.4 و4.2.5)

النص صريح: بعد Server-Unauthenticated Provisioning ينبغي ألا يمنح الوصول، لأن المحادثة مخصصة للتهيئة فقط. ويمكن لسياسة النظير إنهاء الاتصال ثم بدء EAP-FAST جديد باستخدام المعلومات التي تلقاها. أما النمط الذي يصادق الخادم فيتيح له منح الوصول بعد نجاح التهيئة. لذلك لا تعني كلمة «اكتملت التهيئة» قراراً موحداً بالقبول. (RFC 5422، القسم 3.5)

لكل خيار كلفة. يوفر التحقق من الخادم حماية أقوى من الوسيط، لكنه يعتمد على ثقة مثبتة مسبقاً. ويسهّل النمط المجهول التهيئة من دون تدخل، لكنه يزيد التعرض لهجمات القاموس غير المتصلة على تبادلات كلمات المرور. ويذكر RFC 5422 ضوابط لمحاولات التخمين المتصلة، ويشجع على تقييد المكان أو الوقت الذي يعمل فيه النمط المجهول. هذه اعتبارات وثيقة معلوماتية صدرت عام 2009، لا قياسات لانتشار المنتجات اليوم. (RFC 5422، الأقسام 6.1–6.3)

ينبغي للسجل التشغيلي أن يفصل نمط البداية، ونتيجة المصادقة الداخلية وCrypto-Binding، ونوع الاعتماد ومدته، وإقرار Tunnel PAC، والمصادقة التالية التي تستخدم الاعتماد، وقرار الوصول النهائي. وإذا كان فريق يصدر الاعتمادات وآخر يملك سياسة الشبكة، فهما يحتاجان إلى معرّف ارتباط مشترك ومسؤول يتابع غياب التبادل الثاني. نجاح الخطوة الأولى لا يملأ هذا الفراغ.

نجاح التبادل الداخلي لا يمنع رفض الدخول

تجعل الفقرة 3.5 سياسة الخادم هي الفيصل حتى بعد اكتمال التهيئة. ففي نمط Server-Authenticated يمكن للخادم منح الوصول بعد التحقق من النظير وتزويده بـTunnel PAC. أما نمط Server-Unauthenticated فلا ينبغي أن يمنح الوصول عند انتهاء المحادثة لأنها مخصصة للتهيئة وحدها. تسليم بيانات الاعتماد لا يعني أن النمطين ينتجان قرار التفويض نفسه.

ولا يحسم Result TLV الناجح قرار الدخول. فقد ينجح أسلوب EAP الداخلي، ثم يقرر الخادم أن سياسة الوصول لم تتحقق وينهي التبادل بـEAP Failure. وإذا لم تكن المحادثة معدة لمنح الوصول، فلا يجوز للخادم فتح الشبكة أو إرسال مفاتيح الجلسة إلى Network Access Server. وقد تعرض لوحة تشغيل تراقب النجاح الداخلي فقط حالة خضراء بينما حجبت الشبكة الدخول كما ينبغي. يجب أن يمتد السجل إلى نتيجة EAP النهائية وإرسال المفاتيح، لا أن يتوقف عند أول علامة نجاح. (RFC 5422، الفقرة 3.5؛ RFC 4851، الفقرة 4.2.2)

الإقرار يوثق لحظة واحدة من عمر بيانات الاعتماد

يتكون Tunnel PAC من عناصر مختلفة. PAC-Key سر بطول 32 بايتاً يستخدم لإنشاء نفق المرحلة الأولى. أما PAC-Opaque فخاص بالخادم الذي أصدره ويعود إليه أثناء المصادقة اللاحقة. وقد يتضمن PAC-Info هوية الجهة المصدرة ومدة الصلاحية. وتلزم RFC 4851 بحماية PAC-Key، بينما تذكّر RFC 5422 بأن النظير والخادم مسؤولان عن التخزين الآمن. لذلك تنشئ عملية التهيئة واجبات مستمرة للحفظ والانتهاء والتجديد.

أما PAC-Acknowledgement فأضيق نطاقاً: يرسله النظير مع Tunnel PAC الجديد ليبلغ نتيجة المعالجة والتخزين، وتكون النتيجة نجاحاً أو إخفاقاً. النجاح هو تقرير النظير في تلك اللحظة؛ لا يثبت أن إنشاء نفق لاحق سينجح، أو أن السر ظل آمناً، أو أن سياسة الشبكة ستسمح بالدخول. التبادل اللاحق لـEAP-FAST هو الذي يختبر بيانات الاعتماد في سياق مصادقة جديد. وحتى نجاحه لا يثبت وصول التطبيق. (RFC 5422، الأقسام 4.2.2–4.2.5 و6.8؛ RFC 4851، القسم 3.2.2)

قد يقطع الرفض الاتصال أيضاً

لهذا الفصل كلفة على الإتاحة. تذكر RFC 5422 أن EAP Failure بعد رفض الدخول قد يؤدي إلى قطع ارتباط كامل لأجهزة 802.11. ويمكن للنظير أو الخادم محاولة إعادة تفاوض TLS لاستخدام بيانات الاعتماد الجديدة في مصادقة تالية من دون إعادة التشغيل الكامل، لكن أياً منهما قد يرفض الطلب. ولا تطبق سياسة الوصول العادية إلا بعد نجاح المصادقة التالية. لذلك ينبغي قياس من عاد ومن رُفض، وما إذا كان الاستئناف عبر إعادة التشغيل أو إعادة التفاوض. وإلا بدا الرفض المقصود كأنه عطل في الإعداد، أو أخفى عدّاد التهيئة الناجحة أجهزة لم تدخل قط. (RFC 5422، القسم 3.5)

المصادر