الخلاصة

  • تتيح RFC 9867 مزج PPK في IKEv2 عبر IKE_INTERMEDIATE وCREATE_CHILD_SA، بما في ذلك استعمال PPK جديد عند إنشاء Child SA أو IKE SA أو إعادة توليد مفاتيحهما.
  • قد يخلو رد CREATE_CHILD_SA من هوية PPK، ومع ذلك ينشئ المسار العادي في IKEv2 ارتباطاً جديداً. إذا خالف هذا التراجع سياسة إلزامية لدى البادئ، يستطيع حذف الارتباط فور إنشائه.
  • ينبغي وجود إيصال لكل SA يفصل بين الاختيار والتأكيد والتفويض والإنشاء والقبول والاستخدام والحذف. هذا اقتراح تحريري من Daniel Kade، وليس حقلاً في RFC أو أمراً من IETF.

تبدو عبارة «تم إنشاء الارتباط» كأنها نهاية القصة. رد الطرف الآخر، واشتقت مادة مفاتيح، وظهرت المعرّفات في جدول الحالة، وأصبح لدى نظام التشغيل نجاح قابل للعد. وبعد أشهر قد يتحول السجل نفسه إلى دليل في تقرير يعلن اكتمال التعزيز لما بعد الحوسبة الكمية.

تكشف RFC 9867 الحلقة المفقودة في هذا الاستنتاج. قد ينشأ الارتباط بينما لا يدعم المستجيب الامتداد، أو لم يضبطه، أو لا يجد هوية مطابقة ضمن المعروض، أو يحتفظ بقيمة مختلفة تحت هوية تبدو متطابقة. عندما يكون PPK اختيارياً يكون الاستمرار نتيجة مشروعة. نجاح البروتوكول وإثبات الحماية حقيقتان منفصلتان.

علاقة IKE واحدة تحمل أكثر من سلالة مفاتيح

لا ينشئ IKEv2 نفقاً واحداً ثابتاً. فهو يؤسس IKE SA، ويوثق الأطراف، وينشئ Child SA، ويسمح بإعادة توليد مفاتيح النوعين كل على حدة. القول إن «النفق يستعمل PPK» يحذف ثلاثة أسئلة: أي ارتباط، وفي أي تبادل، وفي أي اشتقاق؟

عرّفت RFC 8784 مساراً أول لمزج مفتاح مشترك مسبقاً في مفاتيح جلسة IKEv2. يفترض ذلك المسار الاستعمال عند التأسيس الأول، لكنه لا يحمي IKE SA الأولي نفسه بذلك المفتاح في مواجهة الخصم الكمي محل النقاش. لا تستبدله RFC 9867، بل تضيف مسارين آخرين.

يستعمل المسار الأول IKE_INTERMEDIATE، وهو التبادل السابق للتوثيق الذي عرّفته RFC 9242. يعرض البادئ هويات PPK، ويمكن للمستجيب اختيار واحدة وإرجاع قيمة تأكيد. يحدث المزج قبل IKE_AUTH، ولذلك يمكن أن يسهم في حماية IKE SA الأولي وفي حماية التوثيق. وإذا أعادت تبادلات وسيطة أخرى حساب المفاتيح، يجب أن تكون عملية PPK آخر إعادة حساب قبل التبادل التالي. ترتيب العمليات جزء من ادعاء الحماية، لا تفصيل تنفيذ صغير.

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

توفر التبادلات المتعددة في RFC 9370 ومصطلحات المخططات الهجينة لما بعد الحوسبة الكمية في RFC 9838 سياقاً مهماً. لكن قائمة الخوارزميات تثبت القدرة فقط، وسجل التفاوض يثبت وقوع حدث؛ ولا يثبت أي منهما وحده أن مساهمة بعينها وصلت إلى مفاتيح ارتباط بعينه.

تطابق القيمة لا يمنح الإذن

تستعمل RFC 9867 إشعارين مسجلين: USE_PPK_INT بالقيمة 16445، وPPK_IDENTITY_KEY بالقيمة 16446. يوثق سجل IANA هذين التخصيصين. هذان عنصران ظاهرَان في البروتوكول، لكنهما ليسا سر PPK ولا يبرران تسجيله.

يتكون التأكيد من أول ثمانية ثمانيات من ناتج الدالة شبه العشوائية المتفق عليها على السياق المحدد. يكشف هذا حالة اختيار الطرفين لهوية تبدو واحدة مع امتلاكهما قيمتي PPK مختلفتين. وهو أقوى من مجرد تطابق اسم في الإعداد، لكنه لا يثبت بعد أن استعمال المفتاح مسموح للطرف الذي ستظهر هويته الموثقة لاحقاً.

أثناء IKE_INTERMEDIATE قد يضطر المستجيب إلى اختيار PPK قبل معرفة هوية البادئ الموثقة. وبعد التوثيق قد يتبين للسياسة المحلية أن المفتاح غير مناسب لهذا الطرف. تقول RFC 9867 إنه ينبغي عندئذ الإنهاء، مع السماح بالاستمرار إذا أجازته السياسة المحلية. العثور على المادة، وتأكيد القيمة، ومعرفة الطرف، والتصريح بالربط أربع قرارات مختلفة.

تضغط الأتمتة هذه القرارات بسهولة. يقول مخزن المفاتيح «موجود»، ويقول التأكيد «القيمة نفسها»، ويقول التوثيق «هذا هو الطرف»، ثم تقول السياسة وحدها «مسموح». تختفي المسؤولية والتسلسل عندما تختزل المنظومة ذلك كله في علامة نجاح واحدة.

ارتباط يُنشأ ثم يُرفض ثم يُحذف

تظهر الحالة الأوضح في CREATE_CHILD_SA. يطلب البادئ PPK جديداً. إذا كان المستجيب لا يدعم الامتداد أو لم يضبطه أو لم يجد هوية مطابقة أو وجد قيمة مختلفة، يغيب PPK_IDENTITY_KEY عن الرد. ومع ذلك قد تنشئ معالجة IKEv2 العادية ارتباطاً جديداً.

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

يلزم فصل ثلاث لحظات على الأقل: وقت الإنشاء، ووقت تقييم السياسة لغياب دليل PPK، ووقت القبول أو الحذف. وتهم طبقة البيانات أيضاً. هل مرّت حزم قبل الحذف؟ هل ثبّت مسار احتياطي الارتباط؟ هل ظل الطرف البعيد يعتقد أنه قائم بعد إزالته محلياً؟ يحدد المعيار سلوك التبادل، أما إثبات الادعاء التشغيلي فمسؤولية المشغّل.

وتحتاج كلمة «إلزامي» إلى مالك ونطاق. قد تنطبق القاعدة على طرف محدد أو فئة حركة أو عملية إعادة مفاتيح أو مرحلة انتقال. لا تنشأ الإلزامية لمجرد أن البرنامج يدعم PPK. كما قد يكون التراجع الاختياري قرار توافق واعياً. الخطأ الحوكمي هو عرضه كدليل على تحقق الحالة الأقوى.

إيصال لانتقال المفاتيح، لا للمفتاح السري

إيصال مزج PPK المقترح هنا أداة ضبط تحريرية. ليس حقلاً في RFC 9867 ولا امتداداً بروتوكولياً ولا أمراً بجمع مركزي، ويجب ألا يحتوي سر PPK مطلقاً.

يسجل الإيصال لكل SA جديد أو مجدد نوع التبادل وسلالة IKE SA الأب. ويميّز مسار RFC 8784 من مسارات RFC 9867. ويمكنه حفظ هوية غير سرية أو بصمة مصممة لتقليل البيانات، وحالتي العرض والاختيار، ونتيجة التأكيد، واللحظة التي أصبحت فيها الهوية الموثقة معروفة. كما يربط السياسة الإلزامية أو الاختيارية المرصودة، وإصدارها، وصاحب القرار، ومالك الاستثناء.

ثم يأتي ترتيب الاشتقاق. إذا غيّرت تبادلات وسيطة متعددة المادة، فهل كانت عملية PPK آخر إعادة حساب كما هو مطلوب؟ تربط SPI ومعرّفات SA الإيصال بالكائن، لكنها لا تثبت الحساب بنفسها. تبقى حالات الإنشاء والتثبيت والقبول وأول حزمة وآخر حزمة والحذف منفصلة، مع سبب التراجع وقرار الرجوع وموعد المراجعة.

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

إغلاق ادعاء الانتقال عند حد كل SA

الدافع لما بعد الحوسبة الكمية لا يبرر الشعارات. تشرح RFC 9867 أن البدائيات المتناظرة لا يُعتقد حالياً أنها تتأثر بالطريقة نفسها التي تتأثر بها آليات المفتاح العام محل النقاش أمام حاسوب كمي ذي صلة تشفيرية. يضيف مزج PPK قوي قبل التوثيق مسار حماية. لكنه لا يعلن وجود ذلك الحاسوب، ولا يقدم موعداً، ولا يصادق على منتج بوصفه آمناً كمياً.

كما يجب أن يعني «جديد» أنه مختلف. إعادة استعمال PPK السابق لا تمنح مسار التدوير الجديد غايته. وتظل جودة المفتاح وحفظه وتوزيعه والاستجابة لانكشافه مسؤوليات تشغيلية لا يثبتها نجاح التبادل.

لذلك يعد التقرير الموثوق الارتباطات والنتائج الدقيقة: RFC 8784، أو IKE_INTERMEDIATE، أو إعادة مفاتيح مع PPK جديد، أو تراجع اختياري، أو فشل تأكيد، أو إنشاء يتبعه حذف إلزامي. هذا التنوع ليس ضوضاء إحصائية، بل خريطة القرارات الفعلية.

يسمح البروتوكول بالتقدم بين قدرات غير متساوية لأن الشبكة يجب أن تستمر في العمل. وعلى الحوكمة أن تحفظ الطريقة التي تم بها ذلك التقدم. تتيح RFC 9867 انتقالاً مرناً، لكنها لا تحول كلمة «أُنشئ» إلى دليل لم يُجمع.

المصادر