RFC 9820: نجاح EAP يحتاج إلى شاهد محمي ثانٍ

الخلاصة

لا يجعل RFC 9820 نجاح طريقة EAP أو تصدير MSK دليلاً كاملاً على الجلسة. يرسل authenticator في Step 7 طلباً محمياً بـ OSCORE، ويتحقق منه peer ثم يعيد Step 8 المحمي 2.04 Changed؛ والتحققان معاً يثبتان امتلاك سياق مشتق متوافق.
لا يعني السياق المشترك السماح بكل موارد التطبيق. تفويض الانضمام وسياسة كل مورد ومدة الجلسة وإعادة المصادقة واستبدال الجيل والحذف القسري قرارات منفصلة ذات أصحاب ونقاط اكتمال مختلفة.
يوصل الإيصال الأدنى أجيال موارد CoAP بنتيجة EAP وسلسلة اشتقاق لا تكشف الأسرار والتفاوض وRecipient IDs والتحققين 7 و8 والسياسة النافذة وإقرارات الحذف وحركة المرور المرصودة، من دون تسجيل MSK.

العثور على الخدمة لا يثبت العثور على السلطة الصحيحة

تبدأ الحالة الافتراضية قبل النتيجة الخضراء. عثر peer على وسيط يقدم خدمة CoAP-EAP، وعبرت الرسائل إلى AAA، وانتهت طريقة EAP بنجاح. لم يحتفظ النظام بهوية جهة الاكتشاف ولا lower-layer identifier ولا المسار الذي جعل خادم AAA يثق في authenticator المحدد. صار النجاح صحيحاً داخل مسار لا تستطيع المؤسسة إثبات أنه المسار المقصود.

RFC 9820 يعرّف نقل EAP فوق CoAP للأجهزة المقيدة. يعمل جهاز IoT بصفته EAP peer وفي الوقت نفسه CoAP server. ويعمل Controller بصفته EAP authenticator ويرسل الطلبات كـ CoAP client. وفي نمط pass-through يمكن لخادم AAA خلفي تنفيذ الطريقة أو تقديم معلومات التفويض.

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

تصف صفحة RFC Editor وصفحة Datatracker الوثيقة بأنها Standards Track صادرة عن IETF في سبتمبر 2025 بعد عمل مجموعة ACE. تثبت هذه الصفة مكانة المواصفة، ولا تثبت أن منتجاً بعينه طبقها أو أن جهازاً انضم أو أن مورداً سُمح به.

يبقى discovery الخاص بـ authenticator أو intermediary خارج نطاق RFC 9820. ويمكن لـ RFC 6677 أن يساعد عبر EAP channel binding وlower-layer identifiers على كشف عدم التطابق، لكن وجود الآلية في مواصفة لا يثبت تفعيلها ولا نتيجتها في جلسة تشغيل.

المورد المؤقت هو جزء من ترتيب الحقيقة

لا يتقدم CoAP-EAP وراء عنوان دائم واحد. ينشئ peer مورداً للخطوة التالية ويحذف السابق؛ ويشير Location-Path أو Location-Query في الاستجابة إلى الوجهة التالية المقبولة.

لذلك يحمل جيل المورد ترتيب المحادثة. لا يصبح الطلب المرسل إلى مورد محذوف حديثاً لمجرد وصوله متأخراً. ويجب إسقاط Step 0 المكرر أثناء مصادقة جارية. وقد يصل trigger قديم بعد انتهاء الجلسة فيراه authenticator بداية جديدة، بينما لا يجد peer المورد المتوقع.

يحدد RFC 7252 دلالات طلبات CoAP واستجاباتها وموثوقيتها، ويصف RFC 4137 آلات حالات EAP لدى peer وauthenticator. يجمع RFC 9820 النظامين ولا يلغي أياً منهما لصالح خانة حالة واحدة.

ينبغي للإيصال أن يحتفظ بهوية الطرفين في دوريْهما، والجيل الحالي، والمورد المحذوف، ومعرفات الطلب والاستجابة، وانتقال EAP، ونتيجة CoAP، والتوقيت ومشاهدة النقل. وإذا وقع retry على جيل آخر، يجب بيان هل رُفض أم أُهمل أم عومل كمصادقة جديدة.

Step 7 يختبر انتقال النتيجة إلى الطرف الآخر

عند نجاح الطريقة، يحصل authenticator على MSK المصدّر ورسالة EAP Success ومعلومات مثل Session-Lifetime. يضع RFC 5247 إطار إدارة مفاتيح EAP، ويشترط RFC 9820 طريقة تصدّر MSK وEMSK بطول لا يقل عن 64 octets.

وجود MSK عند جهة واحدة لا يثبت أن الجهتين ركبتا الحماية نفسها. يشتق RFC 9820 قيمة OSCORE Master Secret وMaster Salt من MSK ومن transcript تفاوض cipher suite ومن context strings محددة. وتحدد Recipient IDs اتجاهي الإرسال والاستقبال. يعرّف RFC 5869 HKDF، ويعرّف RFC 8613 OSCORE.

بعد ذلك يرسل authenticator رسالة EAP Success داخل POST محمي بـ OSCORE. يستخرج peer قيمة MSK من آلة EAP لديه، ويشتق السياق، ويتحقق من الطلب. Step 7 ليس غلافاً تجميلياً فوق قرار مكتمل؛ إنه أول اختبار على أن الاستنتاج المحلي يستطيع أن يصبح حالة مقبولة لدى الجهة الأخرى.

لا يتطلب التدقيق نسخ MSK إلى السجلات. يكفي حفظ بصمة transcript ومعرفات الطريقة وsuite وRecipient IDs وجيل الاشتقاق وإصدارات التنفيذ ونتيجة التحقق. تخزين السر لتحسين الإثبات يحول نظام الإثبات إلى سطح اختراق.

Step 8 يعيد شهادة مستقلة إلى البادئ

بعد نجاح EAP والتحقق من Step 7، يعيد peer استجابة 2.04 Changed محمية بـ OSCORE. وعندما يتحقق authenticator منها، يحصل على دليل أن peer استطاع استخدام Master Secret نفسه والسياق المقابل.

هناك خمسة أحداث قابلة للفصل: نتيجة الطريقة، وتصدير المفتاح، والاشتقاق المحلي، وتحقق peer من Step 7، وتحقق authenticator من Step 8. فقدان الحدث الأخير لا يمحو ما سبقه، لكنه يمنع الادعاء بأن التأكيد الثنائي اكتمل.

يدخل transcript التفاوضي في الاشتقاق. وإذا غيّره مهاجم اشتقت الجهتان سياقين مختلفين وفشلت الرسائل المحمية. يسجل IANA CoRE Parameters وIANA EAP Parameters الأرقام والأنواع؛ ولا يشهد أي سجل بما عرضته نقطة نهاية تشغيلية أو اختارته أو طبقته.

يجب أن تعرض لوحة النضج عدادات مستقلة للطرق الناجحة، وعمليات Step 7 التي تحقق منها peer، وعمليات Step 8 التي تحقق منها authenticator. الفارق بينها حالة يجب إدارتها، لا ضجيجاً ينبغي إخفاؤه.

سياق الحماية ليس تفويضاً لكل تطبيق

بعد Step 8 يجب حماية آخر مورد CoAP-EAP بـ OSCORE. ويمكن استخدام السياق نفسه مع موارد أخرى فقط إذا سمحت سياسة التطبيق. هذه العبارة الشرطية تحفظ سلطة مالك المورد.

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

في بنية AAA قد تقدم المؤسسة المسؤولة عن peer معلومات التفويض عبر RADIUS أو Diameter؛ وفي standalone قد توجد لدى authenticator. ويمكن أن يلزم تفويض أدق بعد bootstrap. يقدم RFC 9200 استخدام OAuth في ACE، لكن الإشارة إلى المواصفة لا تثبت فحص token ولا قرار مورد بعينه.

امتلاك Controller لـ MSK لا يمنحه سياسة المؤسسة. وإرسال AAA لسمة لا يثبت تنفيذها. وصحة رسالة OSCORE لا تثبت أن المورد المطلوب داخل النطاق المسموح. يلزم ربط إصدار السياسة وصاحب القرار والطلب والأثر المرصود.

يسمح أثناء المصادقة باتصال IP الضروري لـ CoAP-EAP، لكن المرور غير المحمي ينبغي أن يقتصر على التبادل. فتح subnet كاملاً لمجرد ظهور EAP Success يمنح نتيجة الطريقة ولاية لم يعطها البروتوكول.

إعادة المصادقة تُبقي حاضرين في الوقت نفسه

إذا لم تصل Session-Lifetime يستخدم RFC 9820 مدة افتراضية ثماني ساعات وفق توصية RFC 5247. هذه قيمة بروتوكولية وليست هدفاً أمنياً عاماً ولا دليلاً على إعداد تشغيل بعينه.

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

لذلك لا تعني بداية التجديد تفعيل الجيل الجديد. يجب تسجيل الجيل القديم والمرشح ونتيجة الطريقة وStep 7 وStep 8 والتفعيل وآخر استخدام للقديم والتقاعد والانتهاء. وإذا قبل جيلان المرور معاً، ينبغي بيان هل التداخل مقصود وما الأفعال غير القابلة للعكس المسموحة فيه.

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

الحذف بعد timeout حقيقة محلية أولاً

في الإزالة القسرية يرسل authenticator طلب DELETE محمياً إلى آخر مورد حالة، ويعيد peer استجابة 2.02 Deleted محمية. وإذا لم تصل قبل EXCHANGE_LIFETIME يحذف authenticator حالته المحلية.

التنظيف المحلي منطقي، لكنه لا يثبت أن peer استلم الطلب أو مسح السياق أو توقف عن المحاولة. أثناء partition قد يعرض authenticator أن الجهاز طُرد، بينما يحتفظ peer بالحالة، وتحفظ application cache الإذن، وتستمر الشبكة في نقل الحزم.

يشمل receipt قرار الحذف وصاحبه وسببه والجيل والطلب المرسل واستلام peer إن عُرف ونتيجته المحلية والإقرار المحمي والتحقق والtimeout والتنظيف المحلي وإبطال caches والرفض اللاحق والتوقف المرصود. كلمة «محذوف» يجب أن تحدد actor وlayer.

الثقة في AAA تفويض محدود لا صفة دائمة

يستطيع peer أن يثق في authenticator الذي يملك MSK لأن AAA server الخاص به وثق بذلك authenticator. هذه جملة مشروطة داخل key-management architecture، وليست شارة دائمة اسمها «trusted controller».

على التشغيل حفظ هوية سلطة AAA والإعداد ونتيجة channel binding والمسار والجلسة. وإذا أدى discovery إلى جهة أخرى، فإن نجاح الطريقة لا يصلح الخطأ التنظيمي تلقائياً.

يمكن لرسائل Step 0 المزورة أيضاً أن تنشئ عبئاً على الحالة. يوصي RFC بالـ rate limiting وتقليل state حتى وصول EAP-Response/Identity. عداد الحد يثبت أن الحد عمل؛ لا يثبت شرعية كل مصدر.

الاختبار الجيد يصنع خلافاً بين الطبقات

يحتاج المختبر إلى peer وauthenticator ومسار AAA وموارد تطبيقية بسياسات مختلفة ومراقب حزم مستقل. بعد المسار الناجح، يغيّر transcript، ويفقد Step 7، ويفقد Step 8، ويعيد جيلاً قديماً، ويكرر Step 0، ويفشل إعادة مصادقة، ويقيس التداخل، ويرفض مورداً ثانياً، ويحذف مرة بإقرار ومرة بدونه.

في كل تجربة تقارن حالة EAP وجيل CoAP والتحقق في OSCORE وقرار التطبيق وحركة المرور. يفشل الاختبار إذا كان ناتجه النهائي مجرد success أو failure.

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

ما لا تثبته المصادر

لا يسمي RFC 9820 منتجاً أو operator أو deployment. ولا يقدم أرقاماً عن الطاقة أو latency أو loss أو admissions أو attacks أو interoperability. أمثلته تفسيرية وليست telemetry.

يسجل تاريخ Datatracker والوثائق التي تشير إلى RFC 9820 ومراجع RFC 9820 علاقات وثائقية. وتعرض صفحة errata حالة تحريرية لا تقييماً أمنياً.

يعرّف RFC 3748 إطار EAP الأوسع. وجود المواصفات لا يسمح باستنتاج هوية جهاز أو سلطته أو حالته أو أثره.

نجحت طريقة EAP، لكن الجلسة المحمية بقيت بحاجة إلى شاهد ثانٍ: RFC 9820

الخلاصة

العثور على الخدمة لا يثبت العثور على السلطة الصحيحة

المورد المؤقت هو جزء من ترتيب الحقيقة

Step 7 يختبر انتقال النتيجة إلى الطرف الآخر

Step 8 يعيد شهادة مستقلة إلى البادئ

سياق الحماية ليس تفويضاً لكل تطبيق

إعادة المصادقة تُبقي حاضرين في الوقت نفسه

الحذف بعد timeout حقيقة محلية أولاً

الثقة في AAA تفويض محدود لا صفة دائمة

الاختبار الجيد يصنع خلافاً بين الطبقات

ما لا تثبته المصادر

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات