الخلاصة

  • أثبت توقيع BTNS أن الطرف يملك المفتاح الخاص المقابل للمفتاح العام الذي أرسله، ولم يثبت أن جهة خارجية ربطت المفتاح باسم أو عنوان أو مؤسسة.
  • كان على العقدة أن تبحث أولاً في مداخل PAD غير BTNS؛ فإذا طابق الطرف هوية معروفة وفشل في مصادقتها وجب رفضه، لا تمريره إلى المدخل المجهول.
  • لا يقبل المرور الناتج إلا مدخل SPD يحمل BTNS_OK، كما يجب ألا تتداخل هويات Child SA للمدخل العام مع نطاقات العلاقات الأقوى.

ما الذي وقّع فعلاً؟

في BTNS يرسل الطرف مفتاحاً عاماً عارياً داخل CERT payload، ثم ينشئ AUTH signature بالمفتاح الخاص المناظر. نجاح التحقق يربط رسالة IKE والتبادل بذلك المفتاح. يمكن للنظام أن يقول إن منشئ التبادل يسيطر على المفتاح الخاص في تلك اللحظة.

لا يحتوي هذا الحدث على قول مستقل إن المفتاح يعود إلى شركة معينة أو جهاز مسجل أو اسم نطاق أو مالك عنوان. المصدر الذي قد يمنح هذا الربط—CA موثوقة، تهيئة مسبقة، سجل آمن أو إجراء إداري—غير موجود بالضرورة.

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

RFC 5387 سمّى الضمان الناتج «استمرارية الارتباط». يبقى مصدر غير موثّق واحداً خلال عمر SA. إذا لم يُختطف الإنشاء الأول، تستطيع IPsec توفير السلامة والسرية ومقاومة الإعادة. لكن الاستمرارية ليست هوية ثابتة بين SAs ولا إثباتاً لمالك المفتاح.

العلاقة المعروفة تملك حق الرفض

لو كان المدخل العام قادراً على معالجة كل فشل، لأمكن لمهاجم أن يزعم هوية شريك معروف، يفشل في تقديم اعتماد الشريك، ثم يُقبل بوصفه مجهولاً. تصبح القاعدة الأضعف علاجاً لفشل القاعدة الأقوى.

RFC 5386 منع ذلك من خلال ترتيب PAD. يبدأ البحث بالهوية التي أعلنها الطرف ضمن المداخل غير BTNS. إذا وُجد مدخل، يحدد طريقة المصادقة والهوية المسموح بها لـChild SA. فشل المصادقة يعني رفض IKE SA.

فقط إذا لم يطابق الطرف أي مدخل غير BTNS يُحوّل تمثيله المحلي إلى PUBLICKEY ويبدأ بحث BTNS. يجب أن تأتي كل مداخل BTNS بعد المداخل الأخرى منطقياً. لا يجوز وجود أكثر من wildcard واحد، ويجب أن يكون الأخير.

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

المفتاح المقبول لا يملك كل عنوان

حتى بعد قبول الطرف، تُحدَّد حركة Child SA بمحددات مرور. يمكن لمهاجم أن يحاول إعلان عنوان مضيف معروف أو شبكة وراء بوابة موثقة. لو قُبلت المحددات، لاستعاد المهاجم سلطة الهوية من باب المرور.

لذلك يجب ألا تتداخل قيود wildcard BTNS مع هويات أي مدخل PAD آخر. يقترح RFC 5386 بحثاً ثانياً عند تفاوض Child SA للتأكد من أن المحددات التي يعلنها الطرف المجهول لا تصطدم بمجال طرف معروف.

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

تعيد RFC 7619 صياغة الخطر مع NULL Authentication. يمكن لطرف مجهول خلف NAT أن يطلب محدد خادم DNS ويحاول جذب المرور المخصص له. التشفير الصحيح داخل SA لا يجعل هذا التفويض صحيحاً؛ العزل ونطاقات العناوين المقيدة يظلان ضروريين.

BTNS_OK جعل القبول محلياً

لم يجعل RFC 5386 دعم BTNS إذناً عاماً. أضاف علامة BTNS_OK إلى مدخل SPD، ولا يطابق مرور طرف BTNS إلا قاعدة تحملها. يمكن للنظام أن يفتح خدمة عامة واحدة مع إبقاء الإدارة أو شبكات الشركاء تحت مصادقة عادية.

هنا تتوزع السلطة على ثلاث طبقات. PAD يقرر أي نظام إثبات ينطبق على الطرف. قيود Child SA تقرر أي هويات مرور يجوز له تمثيلها. SPD يقرر أي فئة مرور محلية تقبل ذلك النظام. نجاح IKE لا يختصر القرارات الثلاثة.

RFC 7619 أبقى المبدأ نفسه: القواعد التي تسمح بمصادقة NULL يجب أن تحمل موافقة صريحة، ولا ينبغي للمجهول أن يحل محل مصادقة متاحة لنطاق المحددات نفسه.

سجل «النفق قائم» لا يكفي. يجب حفظ مدخل PAD وترتيبه وطريقة المصادقة وبصمة المفتاح ونتيجة فحص المحدد ومدخل SPD وعلامته. وجود SA لا يثبت أيضاً أن حزمة بعينها استخدمتها أو أن التطبيق وافق على العملية.

اكتشاف الوسيط يأتي في وقت مختلف

Stand-Alone BTNS يقبل غياب مصادقة الطبقة الشبكية. يظل إنشاء SA عرضة لوسيط نشط يمكنه إنشاء ارتباط منفصل مع كل طرف. بعد الإنشاء، قد تحمي كل SA مرورها جيداً، لكن المسار الكامل يمر عبر المهاجم.

Channel-Bound BTNS يضيف مصادقة في طبقة أعلى ويربطها بخصائص قناة IPsec. إذا دمج الوسيط رابطين، تختلف قيمة channel binding ويُفترض أن تفشل المصادقة العليا. connection latching يربط تدفق التطبيق بتسلسل SAs عند إعادة المفاتيح.

الميزة لا تغير الزمن. تنجح IKE أولاً، وتُنشأ الموارد، ثم قد تفشل المصادقة العليا. يحذر RFC 5387 من استخدام بروتوكول يكشف كلمة مرور أو مادة قابلة لهجوم غير متصل قبل اكتشاف الوسيط. معرفة الهجوم لاحقاً لا تسترجع السر.

كما أن نجاح المصادقة العليا لا يعيد كتابة التاريخ ليقول إن هوية IKE كانت موثقة منذ البداية. السجل الصحيح يحفظ التبادل، وSA pair، وقيمة الربط، وهوية الطبقة العليا، وقرار التطبيق كلّاً في مكانه.

لم يعرّف RFC مساراً إلى النص الصريح

يقول RFC 5386 صراحة إنه لا يعرّف نمطاً ينخفض إلى IP غير محمي إذا لم يدعم الطرف IKEv2. ولا يحدد leap of faith أو connection latching بصورة كاملة.

يوصي RFC 5387 باستخدام BTNS بديلاً من عدم الحماية، لا بديلاً من حماية أقوى. إذا جرّب نظام شهادة ثم مفتاحاً مجهولاً ثم نصاً صريحاً حتى ينجح الاتصال، فقد أنشأ سلماً آخر للخفض.

لهذا تملك القرارات السلبية قيمة إثباتية. رفض هوية معروفة فشلت في المصادقة يبين أن العلاقة القوية لم تُبتلع. رفض محدد متداخل يبين أن القبول المجهول لم يتحول إلى وكالة. رفض قاعدة SPD غير معلّمة يبين أن الاستثناء بقي محدوداً.

تطور المفتاح الخام لا يثبت الانتشار

كان RFC 5386 يعمل في سياق RFC 4306 حيث عُرّف Raw RSA Key. أزال RFC 7296 ذلك الشكل، ثم أعاد RFC 7670 دعماً عاماً للمفاتيح الخام بصيغة SubjectPublicKeyInfo. يقول RFC 7670 إن النشر يحتاج تحققاً خارج النطاق إذا أراد الثقة في أصالة المفتاح.

هذا التسلسل يثبت تطور المعيار، لا وجود تنفيذ حالي أو توافقه مع BTNS. لا تدعم المصادر ادعاءً عن منتج أو شبكة أو حادثة أو معدل اعتماد. يلزم لذلك إصدار التنفيذ والتهيئة وسجل IKE والمحددات وملاحظة المرور.

تساعد عدسة Lu Heng على منع توسع الرمز: التوقيع يثبت المفتاح، وPAD تمنح مساراً، وSPD تمنح مروراً، وSA تطبق حماية، والتطبيق يمنح فعلاً. حين يحتفظ كل مستوى بإيصاله، يصبح المجهول خياراً محدوداً. وحين تُدمج المستويات في كلمة «authenticated»، يستطيع أضعف مسار أن يتكلم بلسان أقواها.