الخلاصة

  • في المثال الهجومي ذي الرسائل الثلاث في RFC 2412، أمكن التحقق من التوقيعات ووضع KEYID في حالة موثقة بينما ظل سر Diffie–Hellman المشترك موسومًا uncomputed.
  • إثبات التواصل لم يكن إثباتًا للحساب، والحساب لم يكن إثباتًا لتثبيت رابطتي الأمان عند الطرفين أو مرور حزمة محمية أو نجاح الخدمة.

تبدو كلمة «موثَّق» كأنها نهاية الطريق. في RFC 2412 كانت اسمًا لحد واحد فقط داخل الطريق.

نُشر المستند في نوفمبر 1998 بصفة Informational ووصف بروتوكول OAKLEY. كان الهدف أن يتفق طرفان موثقان على مادة مفاتيح سرية باستخدام Diffie–Hellman، مع إمكان السرية الأمامية واختيار الخوارزميات وتعريف المجموعات والعمل مع ISAKMP. لم يكن المستند معيارًا للإنترنت، ولم يقل إن تبادل OAKLEY وحده ثبّت الحالة التشغيلية التي تحتاجها AH أو ESP.

يتكون المثال السريع من ثلاث رسائل. يرسل المبادر cookie والمجموعة والقيمة العامة g^x وعروض الخوارزميات والهويات وnonce وتوقيعًا. يضيف المستجيب cookie الخاص به وg^y والاختيارات وnonce آخر وتوقيعه. ثم تغلق رسالة أخيرة موقعة سجل التبادل.

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

يجوز للتنفيذ حفظ x وg^y، ووسم المادة بأنها uncomputed، ثم حسابها لاحقًا.

يظهر الترتيب بوضوح في خطوات المعالجة. يتحقق المبادر من توقيع المستجيب ويضيف g^y إلى حالته. يمكنه حساب (g^y)^x = g^xy، كما يمكنه تأجيله إلى ما بعد إرسال الرد الأخير. ومع ذلك يضع KEYID في حالة موثقة. وعندما يتحقق المستجيب من التوقيع الأخير يضع المفتاح في الحالة نفسها، ثم ينبغي له حساب g^xy وربطه بـKEYID.

عُبر حد التوثيق. وربما لم يُعبر حد الحساب بعد.

تسمية KEYID تجعل الفرق ملموسًا. يقوم الـcookieان بدور ضعيف في مقاومة الإغراق والتحقق من المصدر، ويكوّنان أيضًا اسمًا قابلًا لإعادة الاستخدام لمادة المفتاح. أما sKEYID فهو المادة السرية التي يشير إليها الاسم؛ لا تُرسل على الشبكة، وتُشتق في المثال من g^xy وnonce والـcookieين. يمكن أن يوجد الاسم قبل مضمونه، ولا يؤدي توثيق الاسم إلى إنشاء البتات السرية.

تزيل واجهات التشغيل هذا الحد بسهولة. يكتب السجل “authenticated”، ويتحول المؤشر إلى الأخضر، وتفهم الطبقة العليا أن القناة جاهزة، ثم يفترض المشغّل تثبيت رابطتي الأمان ووجود مرور محمي. كل خطوة تنسب إلى الإيصال السابق واقعة لم يثبتها.

لم يكن تأجيل الحساب قرارًا غير منطقي. كان الأسّ المعياري مكلفًا. إخراجه من المسار الحرج للرسالة الأخيرة قد يقلل زمن الانتظار الظاهر أو يوزع حمل المعالج. ويتلقى النظير الحقول الموقعة نفسها؛ فلا تفرض قابلية التشغيل البيني بالضرورة اللحظة الداخلية ذاتها للحساب.

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

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

لا يحق لحقيقة في طبقة أن تشهد بدل الطبقة التالية.

أوصى RFC 2412 أصلًا برفض بعض القيم المتدهورة وبمصادر عشوائية جيدة للـcookie وnonce والأسس. يصحح سجل الأخطاء المنشور مصطلحات الأعداد الأولية الآمنة وأعداد Sophie Germain، من دون أن يغير آلية الحساب المؤجل.

جاء RFC 6989 لاحقًا ليفصّل اختبارات القيم العامة لـDiffie–Hellman في IKEv2، بما في ذلك المجموعات ذات الزمر الفرعية الصغيرة. يجب إسقاط حمولة KE غير الصالحة وعدم استخدامها لإنشاء IKE SA. لا يثبت هذا الشرط الصادر سنة 2013 ما كانت تنفذه منتجات OAKLEY أو IKEv1 القديمة. لكنه يؤكد الترتيب: الاستلام ليس تحققًا، والتحقق ليس حسابًا، والحساب ليس تثبيتًا.

جمع RFC 2409 عناصر ISAKMP وOAKLEY في IKEv1. وأتاح Aggressive Mode أن تبقى الحمولة الأخيرة بلا حماية من ISAKMP SA، بحيث يمكن تأخير الأسّ إلى نهاية التفاوض. إلا أن اشتقاق المفاتيح ظل يعتمد على القيمة المشتركة الفعلية. لا يصنع وصف «مكتمل» مادة تشفير.

أعادت أجيال IKEv2 تنظيم العملية في RFC 4306 وRFC 5996 وRFC 7296. يحسب RFC 7296 قيمة SKEYSEED من الـnonce والسر المؤقت لـDiffie–Hellman، ثم يشتق مفاتيح مستقلة. ويميز كذلك بين IKE SA موثقة وبين Child SA أو طلب إعداد قد يفشل.

ليست هذه آلة حالات OAKLEY نفسها. إنها مثال لاحق على المبدأ المنهجي: نجاح مستوى التحكم لا يثبت اكتمال مسار البيانات التابع له.

كما أن تاريخ الوثائق ليس جردًا للبرمجيات العاملة. كان RFC 2412 وثيقة Informational، ثم دخل IKEv1 مسار المعايير وحل IKEv2 محله وتغيرت إرشادات الخوارزميات، وأعلن RFC 9395 تقادم IKEv1 وخوارزميات قديمة. يغير النشر التوجيه الحالي، لكنه لا يحذف الشفرة من كل جهاز.

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

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

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

كلمة uncomputed إرث صادق. فهي لا تقلل من قيمة التوقيع، لكنها ترفض تحميله إثبات حساب لم يحدث بعد.

اكتمل التوثيق. وبقي حساب السر، وربط SA وتثبيتها، وتمرير الحزمة، والتحقق من الخدمة.

النظام الجدير بالثقة يمنح كل فعل إيصالًا مستقلًا.

المصادر