الخلاصة

  • يختار Ticket Control Mask تذكرة خادم التجهيز أو مجموعة تذاكر خوادم إدارة المكالمات المخزنة بصورة دائمة على الجهاز. لا يمتد هذا الإيصال إلى حالة KDC أو الخادم أو Security Association القائمة.
  • عندما تُبطل تذاكر أجهزة كثيرة بعد إعادة تشغيل متزامنة، تتحول وفورات التخزين السابقة إلى طلب متزامن على بنية المصادقة. صحة الأمر الأمني لا تعني سلامة توقيته.

قد يبدأ الخطأ من عبارة إدارية بريئة: «تم تحديث الثقة». أي ثقة؟ وفي أي موضع؟ ربما أثبت النظام أن ملفاً دائماً لم يعد صالحاً. لكنه لم يثبت بعد أن KDC أصدر تذكرة، أو أن الخادم قبل AP exchange، أو أن الخدمة عادت إلى المستخدم.

نُشرت RFC 3594 في سبتمبر 2003 بوصفها Standards Track. وهي تضيف Security Ticket Control، بالرقم 9، إلى خيار DHCP الخاص بتهيئة عملاء CableLabs. تضبط معنى بتّين فقط، ولذلك تمنح مثالاً واضحاً على ضرورة إبقاء السلطة مساوية لحجم الدليل.

البتّان لا يحملان النتيجة الكاملة

يتجه bit 0 إلى تذكرة PacketCable Provisioning Server التي يستخدمها الجهاز. ويتجه bit 1 إلى مجموعة كل تذاكر Call Management Servers التي يستخدمها. أما bits 2-15 فمحجوزة ويجب إرسالها بصفر. القيمة واحد تفرض إبطال التذكرة المحلية الدائمة فوراً؛ والصفر يترك قواعد الإبطال العادية تعمل.

يختلف نطاق الأثر بين البتّين. الأول يخص تذكرة محددة، والثاني قد يخص مجموعة تتبدل مع endpoints وتهيئة الجهاز. سجل يقول «تم مسح credentials» يخفي المعلومة اللازمة لحساب موجة الطلب التالية.

إذا كان الجهاز لا يحفظ تذاكر محلياً فعليه تجاهل sub-option. وعليه تجاهل البتّ الذي لا يعرفه. لذلك لا تكفي حزمة DHCP كدليل على التغيير. نحتاج إيصالاً من parser يبين المعنى المقبول، ثم إيصالاً من storage يبين ما كان موجوداً وما أُبطل وهل بقي الإبطال بعد reboot.

حتى الصفر ليس شهادة صلاحية. هو لا يفعل أكثر من ترك القواعد العادية تقرر. قد تنتهي التذكرة أو تتغير key version أو تصبح غير قابلة للاستعمال لسبب آخر.

حدود الثقة تمر عبر CMTS ولا تتوقف عنده

ترى RFC أن سيناريو DHCP الخبيث غير مرجح في المعمارية الموصوفة، لأن CMTS مضبوطاً بصورة صحيحة لا يمرر طلبات DHCP إلا إلى عناوين خوادم محددة، ولا يسمح بالتدفق الهابط إلا من عناوين محددة. لكنها تذكر أيضاً أن هذا الترشيح لا يمنع خادماً منتحلاً خلف CMTS؛ فالجزء الداخلي يُفترض أنه تحت سيطرة المزود.

ذلك افتراض معماري، لا قياس لبيئة حالية. يجب أن يسجل التغيير هوية الخادم الموثوق، relay، مسار CMTS، نسخة policy، عنوان المصدر ومطابقة transaction في الجهاز. وتقدم RFC 3118 آلية منفصلة لمصادقة رسائل DHCP، لكن وجود المعيار لا يثبت استعمالها.

أما سجل IANA فيثبت تنسيق الرقم 9. لا يثبت أن firmware يدعمه أو أن الخادم أرسله أو أن الجهاز نفذه. السلطة المسجلة على syntax لا تنتقل تلقائياً إلى حالة الجهاز.

التخزين كان يوزع كلفة المصادقة

أتاح PacketCable إعادة استعمال تذاكر Kerberos الصالحة بعد reboot، فتجنب الجهاز acquisition مكلفاً، بما فيه عمليات public key في مسار PKINIT. وتطلب مواصفة CableLabs اللاحقة من MTA حفظ تذكرة provisioning وقدرة كافية لتذاكر CMS.

إذن persistent storage ليس تفصيلاً محلياً فقط. إنه يخفض الطلب عند بدء التشغيل ويبعثره عبر الزمن. إبطال هذا المخزون في cohort كامل يعيد الكلفة إلى KDC والخوادم في لحظة واحدة.

تحذر RFC 3594 من أجهزة MTA كثيرة تُعاد تهيئتها أو تشغيلها، ويتولى DHCP خبيث إبطال كل تذاكرها، ثم تحاول معاً المصادقة والحصول على تذاكر. قد ينشأ DoS حتى لو كانت الطلبات التالية صحيحة. السبب هو الارتباط الزمني.

يمكن لصيانة مشروعة بلا cohorts أو jitter أن تعيد الشكل نفسه. وتكشف مواصفة CableLabs اللاحقة المنطق ذاته حين تحتفظ بالمفاتيح القديمة الصالحة أثناء دوران عادي حتى لا تغمر MTAs كثيرة KDC بطلبات PKINIT مفاجئة.

لذلك يلزم budget لمعدل الوصول، CPU التشفيري، queue depth، retry/backoff، failover، وحد توقف تلقائي. عدد الأوامر المرسلة ليس مؤشراً على التعافي.

التذكرة ليست الارتباط الأمني

تغير sub-option النسخة الموجودة في nonvolatile memory. لا تحمل KDC response أو AP-REP أو SA identifier أو نتيجة application. لا تقول إن server key اختفى أو إن نسخة memory مُسحت أو إن SA قائمة هُدمت.

توضح المادة الأولية اللاحقة أن exchange للحصول على تذكرة جديدة يمكن أن ينتهي من دون التأثير في security parameters القائمة. تستخدم التذكرة لاحقاً لبناء حالة أخرى؛ لكنها ليست إيصالاً عن تلك الحالة.

ينبغي أن يعرض النظام أربع خانات مستقلة: أُبطلت التذكرة الدائمة؛ حُصل على البديل؛ أُعيد بناء association؛ تحققت الخدمة. لكل خانة owner ووقت وفشل محتمل. نجاح الأولى لا يسمح بتلوين الرابعة بالأخضر.

ولا يعيد rollback شكلي ما مُسح. بعد الإبطال يلزم acquisition جديد وassociation جديد واختبار application، مع حساب retries التي دخلت الصف بالفعل.

حد الأدلة

لا يحدد هذا Article مشغل كابل أو طراز MTA أو CMTS أو منتج DHCP أو KDC أو CMS أو مستخدماً أو مكالمة أو حادثة أو نسبة deployment. وكون الوثيقة Standards Track لا يثبت التنفيذ.

تحدد RFC 3495 الخيار الأكبر؛ وتقدم RFC 2131 سياق DHCP؛ وتفصل RFC 3118 المصادقة. RFC 1510 هي Kerberos المشار إليها تاريخياً وRFC 4120 لاحقتها. RFC 3634 تضيف sub-option أخرى. وتصف RFC 2434 وRFC 8126 سياسة السجلات. مواصفة CableLabs لعام 2005 سياق أولي لاحق، وليست توسعاً رجعياً لنص RFC 3594.

تُستخدم مقالتا Heng Lu عن أولوية running code وعن minimum initial specification كعدستين تحريريتين معلنتين. تدعوان إلى إثبات الحالة الفعلية وإبقاء قاعدة التنسيق أضيق من policy المحلية؛ ولا تثبتان نية المؤلف أو deployment.

الخلاصة محدودة: أُبطلت نسخة محلية دائمة. أما credential البديل وassociation والسعة والخدمة فلكل منها دليل ينتظر.

Sources