الخلاصة

  • فتح فريق LAKE في IETF يوم 8 سبتمبر 2026 آخر نداء داخل فريق العمل بشأن draft-ietf-lake-authz-08، وينتهي في 22 سبتمبر.
  • في المسار العادي لـ ELA، يرسل الجهاز U قيمة ID_CRED_I في رسالة EDHOC الثالثة؛ يمررها الموثِّق V إلى خادم التسجيل W، ثم تصل قسيمة W إلى U في الرسالة الرابعة.
  • يقرّ النص بأن U يكشف هويته لـ V موثَّق قبل أن يعرف هل ستكتمل عملية الإجازة. ويجيز استخدام هوية مخصصة لمرحلة التسجيل كوسيلة تخفيف.
  • يقترح Daniel Kade إيصالاً محدوداً يفصل توثيق V عن قرار W ورفض السياسة وحذف الهوية المؤقتة. هذا تحليل تحريري وليس شرطاً في المسودة.

تطلب رسالة النداء الأخير من المشاركين إعلان التأييد أو شرح الاعتراض واقتراح علاجه قبل 22 سبتمبر. ويسجل تاريخ Datatracker انتقال الوثيقة في 8 سبتمبر من WG Document إلى In WG Last Call. هذه بداية مراجعة مركزة وليست نتيجة تصويت نهائي. أما صفحة الوثيقة الحالية فتعرض النسخة 08 بوصفها Internet-Draft تستهدف Proposed Standard، لا RFC منشوراً ولا قراراً من IESG.

ELA اختصار لـ Lightweight Authorization using EDHOC. تجمع البنية ثلاثة أطراف: الجهاز المقيّد U، وموثِّق النطاق V، وخادم التسجيل W الموجود خلف V على شبكة أقل تقييداً. الهدف هو إجراء التوثيق والإجازة والتسجيل بالتوازي داخل تبادل EDHOC، بدلاً من بدء بروتوكول مستقل بعد انتهاء التوثيق.

لا تبدأ الأطراف الثلاثة من نقطة الثقة نفسها. تفترض النسخة 08 أن U يحمل مسبقاً المفتاح العام لـ W وموقعه. وبين V وW علاقة ضمنية، مثل الثقة القائمة على Web PKI. ولا يلزم وجود علاقة سابقة بين U وV. تستخدم ELA العلاقتين القائمتين لتأسيس الثالثة.

المعرّف يغادر في الرسالة الثالثة

يعرض V اعتماده في رسالة EDHOC الثانية، فيتحقق U من امتلاك المفتاح المقابل. ثم يرسل U الرسالة الثالثة التي تتضمن ID_CRED_I، وهو معرّف اعتماد الجهاز. كما تحمل بيانات الإجازة الخارجية موقع W ومادة DH آنية أو نص KEM مشفراً لحماية القسيمة التي قد تعود.

ينشئ V طلب القسيمة إلى W. يحتوي الطلب على حزمة التشفير المختارة، وH_12 الذي يربط أول رسالتين، والمادة الآنية، ومعرّف U، وعَلَماً يطلب عند الحاجة استرجاع اعتماد U الكامل. يربط W بصمة الجلسة بالمعرّف، ويبحث عن سياسة U وينفذها. قد تقصر السياسة التسجيل على هويات أو أوقات أو موثِّقين محددين، إلا أن صياغة هذه السياسة تقع خارج نطاق المسودة.

القسيمة التي ينشئها W موجهة في معناها إلى U: إنها قول من W إن V مُجاز. وترتبط حمايتها بالجلسة الحالية، وبـID_CRED_I، وباعتماد V. ويمكن أن تحمل نطاقاً اختيارياً يقرأه U وW، بينما يظل غامضاً على V. ينقل V القسيمة إلى U في الرسالة الرابعة.

تجعل RFC 9528 الرسالة الرابعة اختيارية في EDHOC الأساسي، لكن ELA تجعلها إلزامية في المسار العادي لأنها تحمل دليل الإجازة. ولا تصف المسودة U وV بأنهما مجازان للتفاعل إلا بعد معالجة هذه الرسالة.

قبل تلك اللحظة، يكون U قد وثّق أن V يملك مفتاح اعتماده، لكنه لم يتلق بعد قول W إن V مسموح له بهذا التسجيل. ومع ذلك، وصل معرّف U إلى V ثم إلى W. إثبات السيطرة على مفتاح وإثبات التفويض من جهة موثوقة حالتان منفصلتان حتى لو حدثتا في المصافحة نفسها.

حماية الهوية لا تلغي المتلقي الموثَّق

لا يعني ذلك أن حماية الهوية في EDHOC قد فشلت. الرسائل محمية عن المتنصت وعن طرف غير موثَّق. المستلم هنا هو V الذي نجح توثيقه. تحدد اعتبارات الأمان في ELA الحد بدقة: يكشف U هويته لـ V قبل أن يعرف هل ستنجح عملية الإجازة كلها.

وتقترح المسودة خياراً متناسباً مع هذا الحد. يمكن لـ U استخدام هوية خاصة بالتسجيل، ثم الانتقال إلى هوية أخرى للاتصالات التشغيلية داخل القناة الآمنة التي أُنشئت. بذلك لا يلزم أن تكشف محاولة مرفوضة أو بوابة خاطئة المعرّف الدائم للجهاز. لكن الخيار لا يقرر مدة احتفاظ V وW بالهوية، ولا كيف يُثبت تعطيل الهوية المؤقتة.

كما أن كلمة «قسيمة» لا تجعل كل المعايير متطابقة. تعرّف RFC 8366 أثراً موقعاً من المصنع يربط جهازاً منتظراً بمالك ويثبت شهادة النطاق. تستعير ELA الوظيفة العامة في صيغة أخف، لا البنية نفسها. وتفصل RFC 8995 في BRSKI بين الجهاز والمسجل وسلطة المصنع، وتخصص مجالاً للتدقيق والخصوصية. وتقدم RFC 9031 مثالاً آخر لانضمام أجهزة مقيّدة. هذه خلفية لنموذج الثقة وليست بديلاً عن ترتيب ELA.

الرفض حدث قرار لا انقطاع غامض

قد يعرف W قيمة ID_CRED_I ثم يرفض التسجيل بسبب السياسة. عندئذ تعيد الواجهة HTTP 403 أو CoAP 4.03. ويمكن لـ W أيضاً تشفير معلومة قابلة للتنفيذ للجهاز، مثل اقتراح V آخر، ثم يمررها V داخل خطأ EDHOC من نوع Access denied.

لا يصح اختزال ذلك في عداد «فشل اتصال». رفض السياسة يختلف عن تعذر جلب اعتماد U، أو فشل تحقق القسيمة، أو انتهاء مهلة W، أو الوصول إلى V غير مناسب. وفي كل حالة وصلت الهوية إلى مرحلة مختلفة. من دون تسجيل المرحلة تضيع قابلية التحقيق ويستحيل قياس تقليل البيانات.

تذكر محاضر LAKE في IETF 126 أن التصميم أبقى مفاتيح آنية مستقلة لـ EDHOC وELA، وأن بعض المشاركين أبدوا استعداداً للنداء، ثم أعلن الرؤساء المضي فيه. يملك فريق LAKE سلطة تقييم النص المشترك. أما المؤسسة المشغلة فتملك سلطة الذاكرة التي تتركها المحاولات المقبولة والمرفوضة.

إيصال يثبت الترتيب من دون إنشاء سجل تتبع

يمكن لإيصال التسجيل أن يتجنب حفظ ID_CRED_I الخام. يكفي مقبض أحادي الاتجاه لكل محاولة، وبصمة اعتماد V، وإصدار مرساة الثقة ونقطة W، وH_12، وإصدار السياسة، وفئة الهوية التي استخدمها U، ونتيجة محدودة: قسيمة مقبولة، رفض سياسة، إعادة توجيه، فشل اعتماد، أو انتهاء مهلة.

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

هذه البنية اقتراح تحريري من Daniel Kade؛ لا تفرضها النسخة 08 التي تترك سياسة الإجازة خارج نطاقها. لهذا ينبغي ألا تتحول خفة الرسائل إلى خفة في تفسيرها: التوثيق، وإجازة W لـ V، وقرار سياسة U، والتخلص من الهوية حقائق مستقلة.

المصادر