الخلاصة

  • FRID هو NAI مستعار ينشئه الخادم للعثور على سياق EAP-IKEv2 قائم. مطابقة القيمة بسجل لا تثبت أن مقدمها يملك مفاتيح ذلك السياق.
  • لا ينجح fast reconnect إلا بعد التحقق من الرسالتين 3 و4 المحميتين بالسياق السابق، واستخدام SPI جديدة وnonces جديدة، ثم اشتقاق MSK وEMSK جديدين. أما تفويض الشبكة وتركيب المفاتيح والخدمة فهي إيصالات لاحقة.

يرى المراقب realm مكشوفاً واسم مستخدم لا يكشف الهوية الدائمة. قد يبدو ذلك كأن البروتوكول قد حل مشكلة الهوية كاملة، لكن الغرض أضيق: إبقاء معلومات كافية لتوجيه طلب AAA مع تقليل كشف اسم المستخدم الحقيقي.

يعرّف RFC 5106 طريقة EAP-IKEv2 تجريبية. في التشغيل الكامل يكون خادم EAP هو IKEv2 initiator ويكون النظير responder. يتفق الطرفان على الخوارزميات ويتبادلان nonces ومواد Diffie-Hellman ويتحقق كل منهما من هوية الآخر وAUTH داخل payload محمي. لا يجوز إنشاء MSK أو EMSK قبل نجاح التشغيل.

داخل تشغيل ناجح يستطيع الخادم إرسال Next Fast-ID. يحمل NFID قيمة Fast-Reconnect-ID بصيغة NAI: username مستعار وrealm صالح للتوجيه. ينشئ الخادم الاسم المستعار ويحتفظ بربطه بالهوية الدائمة وسياق الأمان.

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

ولا يضمن البروتوكول أن يصل الطلب التالي إلى الخادم نفسه الذي أنشأ الاسم المستعار. يوصي RFC خوادم المشغل المنزلي بآلية مشتركة لحل الأسماء المستعارة. إذا لم توجد، يستطيع خادم لا يفهم FRID أن يطلب الهوية الدائمة. قد يعني frid_unknown نقصاً في النسخ أو اختلاف مسار AAA، لا انتحالاً مؤكداً.

لا يجوز للنظير بدء fast reconnect إلا إذا منحه التشغيل الناجح السابق FRID عبر NFID. ويجب إرسال EAP-Response/Identity في البداية. بعد حل FRID تختار سياسة الخادم بين المسار السريع والتشغيل الكامل. وعلى النظير قبول رسالة التشغيل الكامل حتى لو عرض FRID.

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

الإثبات الفعلي في fast reconnect يقع في الرسالتين 3 و4. يستخدم payload المشفر فيهما مفاتيح السياق الناجح السابق للتشفير والسلامة. يختار الخادم SPI جديداً غير صفري داخل proposal وينشئ Ni جديداً. وإذا أرسل KEi، فيجب أن يكون جديداً أيضاً.

يفك النظير الرسالة 3 ويتحقق من سلامتها، ثم يختار SPI جديداً وينشئ Nr ويحمي الرسالة 4. يفك الخادم الرد ويتحقق منه. فقط عند وصول رسالة 4 صحيحة يعد التشغيل ناجحاً ويرسل EAP-Success. العثور على السجل المناسب خطوة سابقة، وليس نتيجة هذا الاختبار.

يمكن لمن يعرف FRID أن يفشل لأنه لا يملك المفاتيح القديمة. ويمكن لسجل cache صحيح الاسم أن يفشل لأن الطرفين في generation مختلف. هذه حالات مهمة: محرك البحث قد يعمل تماماً بينما تمنع طبقة التشفير انتقالاً غير صالح.

بعد النجاح يبدأ جيل مفاتيح جديد. يحسب SKEYSEED من SK_d القديم وNi وNr ومادة Diffie-Hellman الجديدة إن وُجدت. ثم يعاد إنشاء مفاتيح EAP-IKEv2. تنتج KEYMAT مقدار 128 octets؛ أول 64 لـ MSK والثانية لـ EMSK. يمنع RFC تصديرهما قبل النجاح.

Session-ID الجديد يتضمن نوع الطريقة وNi وNr الحاليين. أما Peer-ID وServer-ID فيرجعان إلى التشغيل الكامل الذي أسس السياق. FRID هو مفتاح بحث، وهويات الطرفين سجل للأصل المصادق عليه، وSession-ID اسم للتشغيل الجديد. لا ينبغي تخزين الثلاثة في حقل واحد.

تبديل FRID يحتاج نقطة commit. قد يرسل الخادم NFID جديداً ثم يتعطل النظير قبل حفظه. لذلك ينبغي للخادم الاحتفاظ بآخر FRID مستخدم وآخر FRID مُصدر. وإذا لم تكتمل المصادقة بنجاح، يجب ألا يستبدل القيمة المرتبطة بآخر مصادقة ناجحة.

هذه القاعدة تفصل issued عن stored وconfirmed. أحدث قيمة زمنياً ليست بالضرورة الحالة المشتركة بين الطرفين. حذف آخر قيمة مؤكدة بسبب تحديث غير مكتمل يجعل تحسين الأداء سبباً لفقدان الوصول.

منع replay يعتمد على generation. بعد reconnect ناجح تتغير مفاتيح التحقق، ولذلك ينبغي أن تفشل رسالة 3 قديمة أُعيد إرسالها. يحتاج التدقيق إلى generation وSPI وdigests لـ Ni/Nr ونتائج التحقق؛ تكرار FRID وحده لا يوضح إن كان retransmission أو replay أو محاولة صحيحة.

الخصوصية نفسها محدودة عن قصد. يبقى realm مكشوفاً للتوجيه. ويجب ألا يتحول FRID المستعار إلى معرف تتبع دائم في logs. يمكن استخدام digest مقيد بالفترة وgeneration للربط التشغيلي من دون نشر القيمة الأصلية.

EAP-Success يغلق طريقة EAP فقط. يضع RFC 5247 إخراج المفاتيح ضمن سلسلة أوسع. ما زال AAA يقرر التفويض، ويستلم authenticator المادة ويثبتها، وتفتح lower layer، ثم يظهر أول traffic محمي وتثبت الخدمة.

ويقول RFC 5106 صراحة إن channel binding غير مدعوم. لذلك لا يثبت نجاح الطريقة كل خصائص شبكة الوصول أو نقطة الاتصال. تحويل EAP-Success إلى «الشبكة الصحيحة والخدمة متاحة» استنتاج يتجاوز الدليل.

كذلك يجب تأريخ خوارزميات 2008. يذكر ملف interoperability مجموعات MODP 1024 و3DES وتحويلات من عصر SHA-1. هذا وصف لمعيار تجريبي تاريخي، وليس تفويضاً لسياسة تشفير معاصرة. يجب تسجيل suite الفعلية وإصدار السياسة على حدة.

يسجل نموذج evidence جيد digest لـ FRID وrealm والخادم المصدر والمستقبل ونتيجة mapping وcontext generation واختيار fast/full وSPI وdigests لـ Ni/Nr ومجموعة DH ونتائج رسالتي 3 و4 وSession-ID ونتيجة EAP وhandles للمفاتيح. لا حاجة لتسريب المفاتيح الخام.

ثم تُربط هذه السلسلة بقرار AAA وإيصال installation وأول packet محمي وprobe للخدمة. بهذه الطريقة تسمّي التنبيهات الحافة المفقودة: سياق غير معروف، generation غير متطابق، integrity فاشلة، nonce معاد، نجاح بلا export، تفويض بلا installation أو installation بلا traffic.

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

المصادر