الخلاصة
- يمنح خادم التفويض في RFC 9594 العميل حق الوصول إلى مورد عضوية؛ لكن KDC يجب أن يتحقق من طلب Join وينشئ العضوية ويعيد مادة المفاتيح التي يحددها ملف التطبيق.
- الرمز الصحيح، وسجل العضو، وإصدار المفتاح المثبت، ونجاح اتصال المجموعة أربع وقائع مستقلة، ولا يجوز أن تتحدث إحداها باسم الأخرى.
تبدو شاشة الهوية حاسمة: رمز موقّع، نطاق مسموح، دور صحيح، وصلاحية لم تنته. لكن هذه الشاشة لا تعرف إن كان العميل قد نقل الرمز إلى KDC، أو أنشأ الارتباط الآمن، أو أرسل طلب Join، أو ثبّت المفاتيح التي تلقاها.
تجعل RFC 9594 هذا النقص في المعرفة جزءاً من التصميم. تقسم العملية إلى مرحلتين. الأولى هي تفويض ACE بين العميل وخادم التفويض وKDC بوصفه Resource Server. الثانية هي توزيع مادة المفاتيح فعلياً بين العميل وKDC. الإذن بطلب العضوية ليس العضوية نفسها.
خادم التفويض يسمح بالوصول إلى العتبة
يطبق خادم التفويض السياسة ويقرر أي مورد عضوية يمكن للعميل الوصول إليه، وما الأدوار التي يحق له طلبها. ينقل العميل الرمز إلى KDC، غالباً عبر /authz-info، ثم يستخدم الطرفان ملف نقل ACE مثل DTLS أو OSCORE لإنشاء اتصال آمن.
بعد ذلك فقط يرسل العميل طلباً إلى /ace-group/GROUPNAME. يقارن KDC المجموعة والنطاق والأدوار بالتفويض المخزن، وينفذ متطلبات المواصفة الأساسية وملف التطبيق. عند النجاح يضيف العميل إلى الأعضاء الحاليين ويعيد المادة اللازمة للاتصال المحمي.
لذلك لا يثبت الرمز وصوله إلى KDC، ولا استمرار الارتباط الآمن، ولا قبول Join، ولا إنشاء مورد العقدة، ولا نجاح إثبات الحيازة، ولا تثبيت الحالة محلياً. إنه إيصال عن قرار اتخذه خادم التفويض، وليس شهادة شاملة عن بقية النظام.
ثبات الاسم لا يعني حداثة الحالة
يبقى GROUPNAME ثابتاً بعد إنشاء مورد العضوية. ويبقى اسم العقدة وNODENAME ثابتين وفريدين بين الأعضاء الحاليين. تمنح هذه الأسماء الإدارة عنواناً مستقراً.
أما الحالة التشفيرية فتتغير. يحدد num إصدار مادة مفاتيح المجموعة الحالية. يجب تفسير معرفات المجموعة والمادة الفردية واعتمادات النظراء والسياسات ضمن ملف التطبيق والإصدار المعني. وقد يشير عميلان إلى الاسم نفسه بينما يحملان مؤقتاً إصدارين مختلفين.
يضيف التصويب التقني 8239 لدى RFC Editor حقل num المطلوب إلى مثال لاسترجاع الاعتمادات أغفله النص المنشور. ويصحح التصويب 8864 وصف مرشحات اعتماد فارغة. كان كلاهما في حالة Reported وقت البحث؛ ولا يثبتان عيباً في منتج. لكنهما يوضحان أن اعتماداً بلا سياق إصدار لا يكفي لإعادة بناء الواقع التشغيلي.
ملف التطبيق يكمل العقد الأمني
لا تختار RFC 9594 طريقة حماية واحدة لكل المجموعات. فهي توحد واجهة KDC، وبنى CBOR العامة، والأخطاء، ونوع الوسائط، وسجلات IANA، ثم تلزم ملف التطبيق بتحديد التفاصيل.
يحدد الملف نوع المفتاح وصيغته، ومعرفات المجموعة والعقد، وتمثيل الاعتمادات، وإثبات الحيازة، والسياسات، وحماية إعادة توزيع المفاتيح، والموارد المدعومة، وقدرات العميل. تسمي قيمة ace_groupcomm_profile هذا التخصيص، لكنها لا تنفذه.
ومن ثم لا تكفي عبارة «يدعم RFC 9594». يجب معرفة الملف الفعلي، والمعلمات المستخدمة، والموارد والفحوص، والإصدار المثبت. هذا هو منطق المواصفة الأولية الدنيا: يوضع المشترك الضروري في الطبقة العامة، وتبقى الخيارات المتخصصة معلنة وقابلة للاختبار. يخسر التصميم نزاهته عندما تخفي الواجهة اسم الملف وتسمح لرقم RFC بأن يعد بما لم تحدده المواصفة.
زيادة NUM لا تصل إلى الجميع في اللحظة نفسها
يجدد KDC المادة عند انتهاء صلاحيتها وقد يجددها دورياً. وقد يتطلب الأمن الخلفي مادة جديدة عند انضمام عضو كي لا يقرأ ما سبق، بينما يتطلب الأمن الأمامي مادة جديدة عند مغادرة عضو أو طرده كي لا يقرأ المستقبل.
يزيد KDC قيمة NUM قبل توزيع NUM+1. وقد يحتاج التوزيع إلى رسائل متعددة لمجموعات مختلفة من الأعضاء. تعترف RFC 9594 باختلال مؤقت: بعض الأعضاء انتقلوا، وبعضهم ما زال في الإصدار القديم. بعد اكتمال العملية يحذف KDC المادة القديمة وينبغي أن يحفظ الجديدة بصورة دائمة.
لا يعيد هذا المقال أطروحة RFC 9838 الخاصة بتعاقب KEK ثم TEK لاستبعاد العضو. حد RFC 9594 هنا أعم: تغيير الإصدار داخل KDC لا يثبت أن كل عميل استلم المادة وتحقق منها وفعلها. لكل انتقال إيصال مستقل.
الموزّع ينقل الرسالة ولا يمنح العضوية
قد يمر الاتصال واحد-إلى-متعدد عبر Dispatcher. تكون الوظيفة ضمنية في multicast، أو صريحة في وسيط نشر واشتراك أو مرحّل. يعامل RFC الموزّع الصريح كوسيط غير موثوق على المسار: يرى الرسائل المحمية وينقلها، لكنه لا يملك مفاتيح المجموعة ولا يقرأ النص الصريح.
الموقع في مسار التسليم ليس سلطة عضوية. قد يرسل الوسيط إلى وجهات ذات قيم num مختلفة، وقد يسجل المرحّل عملية إرسال دون إثبات القبول. أما الفرق اللاحق بين الرسالة المحمية والفعل المحلي فقد تناولته مقالة RFC 10020. ينتهي نطاق هذا التقرير عند إثبات انتقال الإذن إلى عضوية، ثم العضوية إلى حالة مثبتة.
سجل الانتقال يحفظ الإثبات لا السر
ينبغي حفظ معرف الرمز أو بصمته، والجهة المصدرة، والجمهور، والنطاق، والأدوار، والانتهاء؛ ونتيجة نقله إلى KDC؛ وملف النقل؛ وهوية الارتباط الآمن؛ ومعرف Join؛ وGROUPNAME وNODENAME؛ وملف التطبيق؛ وnum؛ ونتائج الاعتماد وإثبات الحيازة؛ والتثبيت المحلي؛ وإصدار السياسات؛ وبداية إعادة توزيع المفاتيح ونهايتها؛ والاسترداد؛ وآخر استخدام مؤكد. ولا تحفظ مادة المفتاح نفسها.
يشهد AS على السياسة، ويشهد KDC على القبول والتوزيع، ويشهد العميل على التحقق والتثبيت، ويشهد Dispatcher على النقل، ويشهد التطبيق على الأثر. هذه هي طبقات الواقع لدى Lu Heng: السجل يصف قراراً ولا ينشئ واقع الطبقة التالية، والكود العامل هو الذي يثبت حدوث الانتقال.
المصادر
- RFC 9594: Key Provisioning for Group Communication Using ACE، وسجل IETF Datatracker، وتصويبات RFC Editor
- RFC 9200: إطار ACE، وRFC 9202: ملف DTLS، وRFC 9203: ملف OSCORE
- RFC 8613: OSCORE، وRFC 8949: CBOR، وRFC 9052: بنى COSE، وRFC 8392: CBOR Web Token
- RFC 7641: مراقبة موارد CoAP
- IANA، سجلات ACE وسجل أنواع الوسائط
- Lu Heng، Running-Code Primacy، وMinimum Initial Specification، وReality Layers
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

