الخلاصة

  • أقرت IESG في 24 أغسطس 2026 الوثيقة draft-ietf-ipsecme-ikev2-pqc-auth-12 بوصفها Proposed Standard. وعند تثبيت الأدلة في 27 أغسطس، بقيت الوثيقة Internet-Draft نشطة في طابور RFC Editor، ولم تكن قد أصبحت RFC مرقمة.
  • تحدد الوثيقة كيفية استخدام ML-DSA وSLH-DSA في النمط الخالص ضمن طريقة Digital Signature القائمة في IKEv2. ولا تثبت أن بوابة ما اختارت هذه الخوارزميات أو أوصلت رسائل المصادقة الكبيرة أو تحققت من AUTH أو أنشأت IKE SA وChild SA مصرحًا بها.

حالتان خضراوان ونتيجتان مختلفتان

تظهر بوابتان لشبكة VPN في مراجعة ترحيل، وكلتاهما تحمل وسم «جاهزة لما بعد الكم». توجد مادة اعتماد ML-DSA في جرد كل جهاز، ويعرف إصدار البرنامج الخوارزمية. يبدو العمل منتهيًا على شاشة الأصول.

لكن أثر الحزم يفصل بينهما. تسمح سياسة البوابة الأولى بالرجوع إلى ECDSA، وهو ما يظهر فعلًا في AUTH. وتحاول الثانية نقل مادة مصادقة أكبر بكثير، إلا أن الأجزاء لا تكتمل إعادة تجميعها عبر المسار التشغيلي. لم تُصادق ML-DSA أيًا من الـ IKE SA في الحالتين.

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

ما الذي أُقر وما الذي لم يُنشر بعد

يقول إعلان IESG المؤرخ في 24 أغسطس إن النسخة 12 من «Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC» أُقرت بوصفها Proposed Standard. أعدت الوثيقة مجموعة IP Security Maintenance and Extensions، وهي لا تستبدل IKEv2 بل تضيف خوارزميات توقيع جديدة إلى إطاره العام للمصادقة.

الحالة الإجرائية جزء من الخبر. ففي 27 أغسطس كان Datatracker يعرض الحالة «RFC Ed Queue»، مع انتظار فحص المراجع والتنسيق. وتحمل المسودة تاريخ 21 أغسطس وموعد انتهاء في 22 فبراير 2027. وقد تتغير أثناء التحرير. وصفها الآن بأنها RFC منشورة يلغي فرقًا يمكن التحقق منه.

ولا تطلب الوثيقة تعيينات جديدة من IANA. فهي تجمع قيمًا قائمة: Digital Signature هي طريقة المصادقة 14، وIKEV2_FRAGMENTATION_SUPPORTED هو الإشعار 16430، وSIGNATURE_HASH_ALGORITHMS هو 16431، وSUPPORTED_AUTH_METHODS هو 16443، وIdentity هي دالة التجزئة ذات القيمة 5. هذه القيم توحد لغة البرمجيات، لكنها لا تسجل ما أرسلته جلسة معينة.

اختيار التوقيع موجود داخل AUTH

تتفاوض IKE_SA_INIT على المعلمات التعمية وتنقل nonces وقيم تبادل المفاتيح. ثم تحمل IKE_AUTH الهويات وأدلة المصادقة، وتتفاوض عادة على أول Child SA. تحسين أحد المحورين لا يثبت الآخر.

تحدد RFC 7427 طريقة Digital Signature العامة. تبدأ Authentication Data بـ AlgorithmIdentifier مرمّز وفق DER، ثم تأتي قيمة التوقيع. هذا المعرّف كما ظهر في AUTH الفعلي هو الذي يحدد خوارزمية التوقيع ومجموعة معلماتها.

تختار المسودة الجديدة النمط الخالص لـ ML-DSA وSLH-DSA. تدخل البيانات المرتبطة بالجلسة إلى الخوارزمية من دون تجزئة خارجية مسبقة. لذلك يجب أن يعلن الطرفان Identity ذات القيمة 5 في SIGNATURE_HASH_ALGORITHMS؛ ولا يجوز استخدام خوارزمية تحتاج إليها مع طرف لم يعلنها.

لكن Identity 5 ليست اسم خوارزمية توقيع. إنها تصف طريقة تمرير المدخل. ظهورها في الاتجاهين يثبت شرطًا لازمًا، أما الاختيار الفعلي فيظهر في AlgorithmIdentifier، ويثبت القبول من خلال الشهادة ونتيجة التحقق.

الإعلان عن طريقة لا يعني اختيارها

تذكر المسودة Certificate Request وSUPPORTED_AUTH_METHODS من RFC 9593 وسيلتين لمساعدة الطرفين في العثور على نوع مفتاح متوافق. ويمكن للإشعار الثاني حمل قائمة مرتبة من طرق المصادقة أو أنظمة التوقيع.

إرسال الإشعار واستخدام محتواه أمران اختياريان للطرفين. تخفف القائمة المحاولات العمياء عند وجود عدة مواد اعتماد، لكنها لا تلزم AUTH اللاحق. قد تعلن البوابة ML-DSA ثم تختار ECDSA وفق السياسة، أو تقدم سلسلة شهادات غير موثوقة، أو تفشل في التحقق.

تحدد FIPS 204 خوارزمية ML-DSA، وتحدد FIPS 205 خوارزمية SLH-DSA. وتضع RFC 9881 وRFC 9909 المعرّفات وترميزات PKIX وحدود استعمال المفاتيح. هذه أسس للتشغيل البيني، لكنها لا تنشئ مفتاحًا خاصًا ولا تصدر شهادة ولا تختار جذر ثقة ولا تضمن قدرة HSM أو نجاح منتجين معًا.

لذلك يجب أن يربط الجرد التشغيلي الجلسة بمعرّف المفتاح وبصمة الشهادة وسلسلة الإصدار وkey usage ومزود التعمية وبناء البرنامج وسياسة الاتصال.

الحجم يجعل المسار جزءًا من الدليل

تقدم المسودة أرقامًا عملية. يبلغ المفتاح العام لـ ML-DSA-44 مقدار 1,312 بايت، ويبلغ توقيعه 2,420 بايت. وحتى أصغر توقيع SLH-DSA يقارب 7,856 بايت. وقد تضاف إلى ذلك سلسلة شهادات.

لهذا يجب على الأطراف التي تنفذ الآلية دعم تجزئة رسائل IKEv2. تتيح RFC 7383 إعلان IKEV2_FRAGMENTATION_SUPPORTED أثناء IKE_SA_INIT، ثم تجزئة الرسائل اللاحقة التي تحتوي Encrypted payload. ولا تستطيع IKE_SA_INIT نفسها استعمال هذا النوع من التجزئة.

إعلان الدعم لا يثبت التسليم. قد تنشئ البوابة أجزاء صحيحة بينما يمنع جدار ناري أو NAT أو موزع حمل أو مسار كثير الفقد إعادة تجميعها. وقد لا تلزم التجزئة مع نقل موثوق أو PMTU معروفة وكافية. السجل المفيد يوثق إعلان الطرفين وعدد الأجزاء المشفرة وأحجامها وإعادة الإرسال والتجميع والاستجابة الختامية.

تبادل المفاتيح ليس توقيع المصادقة

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

تضيف RFC 9370 عدة عمليات لتبادل المفاتيح، وتقول صراحة إن تركيزها العاجل هو السرية لا المصادقة. وتمزج RFC 8784 مفتاحًا مشتركًا مسبقًا إضافيًا، لكنها تحافظ على فحوص المصادقة القائمة. وهكذا يمكن أن تحمل IKE SA مساهمة مقاومة للكم في إنشاء المفاتيح بينما يظل AUTH موقّعًا بـ ECDSA أو RSA.

والعكس صحيح: توقيع ML-DSA لا يكشف مجموعات تبادل المفاتيح. يجب أن يعرض التقرير المحورين منفصلين.

بعد نجاح AUTH تبقى سلطة الترخيص

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

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

المصادر