الخلاصة

  • يوثّق RFC 5421 استخدام EAP-FAST-GTC للنوع 6، المخصص أصلاً لـ EAP-GTC، من أجل تبادل داخلي مختلف التنسيق يجري عبر النفق.
  • تجعل قيود الاستخدام داخل النفق وخارجه وتحذير التوافق الصادر عن IESG سياق EAP-FAST جزءاً من هوية الطريقة؛ وهذه دلالة تنفيذية مستنبطة، لا دليل على انقطاع مقاس.

البايت لا يروي القصة كلها

حقل Type في EAP بايت واحد، لكنه يحدد مسار المعالجة. يوضح RFC 3748 أن الحقل يعرّف طريقة المصادقة وأن طبقات EAP توجّه الحزم وفق قيمته، على نحو يشبه استخدام منفذ في طبقة النقل. لذلك يبدو أن رؤية النوع 6 تكفي لاختيار Generic Token Card.

يضيف RFC 5421 قيداً لا يظهر في ذلك البايت وحده. فالوثيقة المعلوماتية الصادرة عام 2009 تصف EAP-FAST-GTC، وهي طريقة داخلية لتبادل كلمة مرور أساسي. وتشمل الاستخدامات المذكورة قواعد كلمات المرور القديمة وتغيير كلمة المرور ورموز المرور لمرة واحدة. ولأسباب تاريخية، أعادت الطريقة استخدام الرمز المخصص أصلاً لـ EAP-GTC. وما زال سجل IANA الحالي يسمي النوع 6 «Generic Token Card»؛ ولم ينشئ RFC 5421 تخصيصاً عالمياً ثانياً.

يكمن الاختلاف في الإطار والحمولة. ينشئ EAP-FAST نفق TLS، وتحمل مرحلة المصادقة الداخلية حزم EAP داخل كائنات EAP Payload TLV. ويقول RFC 5421 إن تنسيق حمولة EAP-FAST-GTC خاص بالنفق وقد لا يتوافق مع آليات EAP-GTC المستخدمة خارجه. لذلك يفرض حدّين متقابلين: يجب ألا تُستخدم EAP-FAST-GTC خارج نفق EAP-FAST، ويجب ألا تُستخدم EAP-GTC داخله.

تحدد هاتان القاعدتان أيضاً معنى النوع 6 في كل سياق. فإذا احتفظ الموجّه بقيمة Type وحدها ولم يعرف هل جاءت الحزمة من التبادل الخارجي أم من مرحلة EAP-FAST الداخلية، فقد أسقط معلومة يعتمد عليها البروتوكول للتمييز بين الطريقتين. هذه دلالة على التنفيذ يمكن استنباطها من المواصفة، وليست ادعاءً بأن أنظمة قائمة ارتكبت هذا الخطأ.

تحذير التوافق مكتوب صراحة

تقول ملاحظة IESG المرفقة بـ RFC 5421 إن إعادة استخدام رموز EAP المخصصة تتعارض مع التفاوض على الطريقة كما حدده RFC 3748. وبما أن EAP-GTC لا تدعم تفاوضاً خاصاً بإصدار الطريقة، يُفهم أن Type 6 داخل النفق يعني EAP-FAST-GTC. وتحذر الملاحظة من أن ذلك قد يسبب مشكلات إذا احتاج التنفيذ إلى دعم EAP-GTC لمورّد آخر؛ كما أن تشغيل الرمز نفسه داخل النفق وخارجه يفرض حالات معالجة خاصة. وترى الملاحظة أن تخصيص رموز Type فريدة كان سيجنب هذه الصعوبة، وتوصي بألا تعيد طرق مستقبلية داخل الأنفاق استخدام أنواع مخصصة بمعانٍ مختلفة.

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

يوفر مبدأ أولوية الشيفرة العاملة زاوية تحريرية مفيدة: سطر السجل ليس النظام كله. تعتمد النتيجة أيضاً على الشيفرة التي تستقبل الحزمة وتحدد طبقتها ثم تختار الطريقة. تساعد ملاحظة Heng Lu رقم 65 على صياغة هذه الزاوية فحسب؛ فهي ليست دليلاً على متطلبات EAP أو سلوك المورّدين أو انتشار التنفيذ.

حماية بيانات الاعتماد حدّ مختلف

يذكر RFC 5421 أيضاً أن EAP-FAST-GTC ترسل معلومات كلمة المرور كنص واضح داخل نفق TLS المشفر. يجب أن يتحقق الطرف من هوية الخادم قبل كشف بيانات الاعتماد. كما يجب ألا تستخدم EAP-FAST-GTC في وضع Server-Unauthenticated Provisioning الذي لا يصادق الخادم. هذا قيد أمني أساسي، لكنه منفصل عن مسألة رمز Type: تشفير الاتصال لا يحسم اختيار الطريقة، واختيار الطريقة الصحيحة لا يثبت وحده أن الخادم صودق.

على المشغّل أن يحدد موضع القرار: أين يقرر النظام إن كان النوع 6 يعني EAP-GTC العادية أم EAP-FAST-GTC؟ يجب أن يعتمد القرار على Type ومرحلة النفق، وأن يفرض القيود المتقابلة. يمكن للاختبارات أن تتحقق من GTC خارج النفق وFAST-GTC داخله، ثم ترفض كل طريقة في السياق المعاكس. هذه ممارسة تحقق مقترحة، وليست متطلباً جديداً من RFC.

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

المصادر