الخلاصة

  • يحفظ RFC 5419 مبررات مصادقة Binding Updates في Mobile IPv6 عبر AAA الأم، لكنه لا يجعل نقل المفاتيح من AAA إلى Home Agent عقداً عاماً وضعه IETF.
  • يميّز النص بين تبادل RADIUS موضّح في مثال وبين آلية معيارية لاشتقاق مفتاح MN–HA ورابطته الأمنية من رابطة MN–AAA.
  • أتاح RFC 4877 لاحقاً مسار IKEv2/IPsec، وأضعف بعض المبررات القديمة؛ أما وثيقة 2009 فلا تثبت ما يعمل في الشبكات اليوم.

تحديث الربط لا يحمل منظومة الثقة كلها

يسمح Mobile IPv6 للجهاز بأن يحتفظ بعنوانه المنزلي عندما يتصل من شبكة أخرى. يرسل العقد المتنقل (MN) تحديث ربط، Binding Update أو BU، إلى Home Agent (HA) ليعلن عنوان الرعاية الذي يمكن الوصول إليه عبره. يحتفظ HA بهذا الربط ويوجه الحزم عبر نفق. في التصميم الأساسي، تحمي رابطة IPsec الأمنية الإشارات بين MN وHA. الطرفان معروفان؛ لكن يبقى سؤال التشغيل: كيف يحصلان على مفاتيح متطابقة إذا كانت جهة إدارة المشترك موجودة في نظام منفصل؟

نُشر RFC 5419 في يناير 2009 بوصفه وثيقة معلوماتية تحفظ المبررات وراء خيار المصادقة في RFC 4285. وهو يوضح صراحة أن البديل لا يلغي IPsec. وتعود أمثلته إلى شبكات CDMA2000 وWiMAX كما وصفها مؤلفوه في ذلك الوقت: أراد المشغلون استخدام AAA الأم للتحقق من المشتركين، وإعادة استعمال ملفاتهم، وتعيين العنوان المنزلي أو HA ديناميكياً. هذه متطلبات تصميم تاريخية يوردها النص، وليست قياسات للشبكات الراهنة. (RFC 5419، القسمان 1 و5)

يحدد RFC 4285 خيارين لهما صلة بهذا المسار. يتيح خيار MN–AAA مصادقة BU اعتماداً على رابطة أمنية مشتركة بين MN وخادم AAA الأم. لكن تأكيد الربط الذي يرسله HA يجب أن يستخدم خيار MN–HA. ويقول RFC 4285 إن HA يعتمد على كيان AAA خارجي لمصادقة الطلب عبر قناة موثقة، بينما يترك تفاصيل التفاعل بين HA وAAA خارج نطاقه. لذلك فإن مصادقة الطلب والحالة اللازمة للمصادقة على الرد مترابطتان، لكنهما ليستا شيئاً واحداً. (RFC 4285، القسم 5.2)

مثال RADIUS يكشف نقطة الوصل

في مثال CDMA2000 الذي يورده RFC 5419، يمرر HA بيانات المصادقة إلى خادم RADIUS. يتحقق AAA من BU، ويحسب مفتاح جلسة من السر المشترك MN–AAA والطابع الزمني، ثم يعيد المفتاح إلى HA ضمن Access-Accept مستخدماً سمة خاصة بالمورّد عرّفتها 3GPP2. يربط HA المفتاح برابطة أمنية MN–HA؛ ويستخدم المثال SPI بقيمة 5. ثم يصادق HA على Binding Acknowledgement بهذه الرابطة. ويحسب الجهاز المتنقل المفتاح نفسه ليتحقق من الرد ويصادق تحديثات الربط اللاحقة. (RFC 5419، القسم 6.2)

يكشف هذا المسار حدّاً بين سلطتين تشغيليتين. تبدأ مصادقة المشترك بسر مشترك بين MN وAAA؛ لكن الإشارات التالية تحتاج مفتاحاً صالحاً بين MN وHA. يوضح المثال كيف يمكن لملف شبكة بعينه نقل مادة الجلسة بين هذين الدورين. أما سمة RADIUS المذكورة فهي من تعريف 3GPP2، وليست سمة عامة يحددها RFC 4285.

ثم يحدد RFC 5419 النقص مباشرة: لا يشرح RFC 4285 آلية إنشاء المفتاح المشترك ورابطة MN–HA انطلاقاً من رابطة MN–AAA. وتعتمد العملية على وسائل خاصة بالنشر لا يعيّرها IETF. ويقارن النص ذلك بـRFC 3957 الذي يحدد لـMobile IPv4 قيمة عشوائية لتوليد المفاتيح وخطوات اشتقاقها. لا يعني هذا أن RFC 4285 عاجز عن العمل؛ بل يحدد أين ينتهي عقد التوافق. يمكن للرسم أن يعرض مفتاحاً يصل إلى HA، لكنه لا يوحد وحده طريقة الاشتقاق أو ربط المفتاح بالهوية أو تحديد نطاقه وتسليمه بين تطبيقات مختلفة. (RFC 5419، القسم 7؛ RFC 3957، القسم 5)

لهذا الاستنتاج حدود أيضاً. خيار المصادقة في RFC 4285 ليس معيباً تلقائياً، ويمكن لملف نشر محلي أن يحدد التفاصيل الناقصة. لكن إذا بقيت تلك التفاصيل محلية، فعلى المشغل أن يعرف أي المكونات تتبعها: الجهاز المتنقل، وخدمة AAA، وسمات RADIUS، وHA، وآلية ربط المشترك بـHA يختار ديناميكياً. شكل الرسالة وحده لا يثبت اتساق السلسلة كلها.

تغيّر السياق أثناء حفظ المبررات

يعترف RFC 5419 بتغير السياق الزمني. فقد حدد RFC 4877، المنشور عام 2007، تشغيل Mobile IPv6 مع IKEv2 ومعمارية IPsec المنقحة. ويقول RFC 5419 إن IKEv2 حسن التكامل مع منظومة AAA الخلفية، وإن بعض الحجج السابقة لدعم RFC 4285 أصبحت زائدة. كما يشير إلى أن RFC 5026 وأعمالاً مرتبطة عالجت إعداد Home Agent والعنوان المنزلي ديناميكياً. لذلك لا يصح التعامل مع نص 2009 كأنه حكم دائم على المعمارية الوحيدة المتاحة. (RFC 4877؛ RFC 5026؛ RFC 5419، الأقسام 1 و5 و9)

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

ولخيار المصادقة قيود أخرى. يذكر RFC 5419 أن تحسين المسار يحتاج حماية إضافية، وأن الخيار لا يفاوض على خوارزميات التشفير، وأن الحماية من إعادة الإرسال تعتمد على ساعات متزامنة بما يكفي، وأن ظهور معرّف Network Access Identifier طويل الأجل يثير مسألة خصوصية. كما يفترض إنشاء رابطة MN–AAA خارج النطاق. هذه شروط ينبغي لملف النشر معالجتها؛ ولا يكفي أي منها منفرداً لإبطال الخيار. (RFC 5419، القسم 7)

لا تخلط المواصفة بالمثال وبالتشغيل

توجد هنا ثلاثة أنواع من الدليل. يحدد RFC 4285 صيغ الخيارات ومعالجتها. ويحفظ RFC 5419 المبررات ومثال RADIUS المرتبط بزمنه. ويعرض RFC 3957 مقارنة لاشتقاق المفاتيح في Mobile IPv4، فيما يشرح RFC 4877 مسار IKEv2/IPsec. ولا يثبت أي من هذه الوثائق ما التطبيق الذي شُحن في شبكة بعينها أو أي ملف يعمل اليوم.

لذلك ينبغي لمراجعة المعمارية أن تسأل: من أين يأتي السر المشترك؟ وكيف يرتبط مفتاح الجلسة بالمشترك وHA المختار؟ وأي سمة RADIUS تحمله؟ وكيف يتفق الطرفان على الصلاحية وحالة منع إعادة الإرسال؟ وماذا يحدث إذا قبل AAA الطلب ولم ينشئ HA الرابطة المتوقعة؟ إذا كانت الإجابات في ملف خاص بمورّد، فهذا الملف جزء من التصميم الأمني ويجب إصداره واختباره وترحيله بوصفه كذلك. وإذا كان IKEv2 يوفر الرابطة المطلوبة، فيلزم إثبات تكامله مع AAA ودعم الإصدارات الموجودة فعلياً، لا استنتاج ذلك من نشر RFC.

الدرس المستمر في RFC 5419 ليس أن خياراً واحداً انتصر. فقرار AAA المركزي بشأن المشترك والعلاقة التشفيرية بين MN وHA جزآن مختلفان من البنية التحتية. يمكن ربطهما بتبادل موحد أو بملف نشر واضح أو ببروتوكول آخر لإدارة المفاتيح. لكن كلمة «موثّق» لا تثبت أن المفتاح وصل إلى الطرف الصحيح.

المصادر