الخلاصة

  • يحمل checksum من النوع 0x8003 ملخص ربط القناة الذي قدمه المستدعي، وأعلام الخدمات المطلوبة والمتاحة، وربما رسالة KRB_CRED تضم TGT قابلة لإعادة التوجيه.
  • الأصفار الستة عشر تعني غياب الربط، وKRB_AP_REQ أحادي الاتجاه لا يثبت تأكيد الطرف الآخر، كما أن التفويض وMIC وWrap وحالة التسلسل لا تثبت قرار الصلاحية أو قبول التطبيق.

تبدأ المشكلة عندما يتحول سجل أمني غني إلى كلمة واحدة: «نجاح». ففي RFC 1964 يمكن أن ينجح تحليل الغلاف، وتنجح مصادقة Kerberos، وتتوافر خدمة سلامة الرسائل، ثم يرفض التطبيق العملية. هذه ليست تناقضات؛ إنها نتائج في طبقات مختلفة.

نشرت الوثيقة في يونيو 1996 وحددت للآلية OID هو 1.2.840.113554.1.2.2. يبدأ KRB_AP_REQ بالمعرّف 01 00، ويحمل KRB_AP_REP القيمة 02 00، أما KRB_ERROR فيحمل 03 00. وللرموز الخاصة بالرسائل أرقام أخرى، منها 01 01 لـ MIC و02 01 لـ Wrap. يحدد TOK_ID القواعد التي ينبغي للمحلل تطبيقها، لكنه لا يثبت صحة المحتوى أو سياقه أو زمنه.

ربط القناة يبدأ خارج Kerberos

يستخدم المصادق checksum خاصاً من النوع 0x8003. تسجل البايتات الأولى طول Bnd وهو 16، ثم يأتي MD5 لمكونات بنية ربط القناة غير الفارغة، مع قواعد دقيقة لأطوال الحقول وترتيب الأعداد.

إذا مرر التطبيق GSS_C_NO_BINDINGS يصبح Bnd ستة عشر صفراً. لا تشير هذه القيمة إلى قناة افتراضية، ولا تصف TLS أو المقبس أو العنوان. إنها تسجل أن المستدعي لم يقدم ربطاً. لذلك يجب أن يتفق التطبيقان مسبقاً على نوع الربط وأن يقدما قيماً قابلة للمقارنة؛ الآلية لا تنشئ هوية القناة من الفراغ.

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

الدليل المتبادل يحتاج مساراً عائداً

عندما لا يطلب التطبيق mutual_req تكون المصادقة أحادية الاتجاه، ولا ترسل الجهة المستقبلة رمز تأكيد رداً على KRB_AP_REQ. قد تتأكد الجهة المستقبلة من البادئ، لكن البادئ لا يملك تأكيداً مقابلاً.

عند طلب المصادقة المتبادلة يظهر mutual-required في خيارات KRB_AP_REQ والعلم المقابل في checksum. ترسل الجهة المستقبلة KRB_AP_REP أو KRB_ERROR. لا يجوز مساواة الردين: KRB_AP_REP الصحيح يتمم التبادل المتبادل بنجاح، وKRB_ERROR يحمل الفشل. وحتى الرد الناجح يخص إنشاء السياق ولا يثبت تنفيذ أمر تطبيقي لاحق.

التفويض ينقل اعتماداً ولا يمنح حكماً نهائياً

عند تفعيل التفويض يمتد checksum ليضم الخيار 1 والطول وKRB_CRED. ويكون TGT المنقول موسوماً بـ FORWARDABLE. يتيح ذلك للجهة المستقبلة محاولة الحصول على تذاكر لخدمات أخرى.

لكن السلسلة لم تنته: يجب التحقق من KRB_CRED وفكها وتخزينها ضمن عمر محدد، ثم طلب تذكرة خدمة، ثم تطبيق سياسة الصلاحيات في الخدمة المقصودة. وصول الاعتماد لا يثبت استخدامه، واستخدامه لا يثبت قبول العملية. يحتفظ كل نظام لاحق بحق إصدار إيصال جديد.

MIC وWrap يحميان الرسالة لا معناها التجاري

يوثق MIC سلامة بيانات منفصلة، بينما يحمل Wrap البيانات مع السلامة ومع التشفير عند اختياره. ويحمي كلاهما رقم التسلسل واتجاه المرسل. إلا أن كشف الإعادة والخروج عن الترتيب خدمتان اختياريتان يمكن تعطيلهما بطلب المستدعي.

نجاح MIC يثبت علاقة تشفيرية داخل سياق معين. ونجاح Unwrap يثبت معالجة غلاف الحماية. لا يثبت أي منهما أن التطبيق فهم الأمر أو سمح به أو حفظ نتيجته.

حدّث RFC 4121 الآلية لاحقاً، وأهمل RFC 6649 خوارزميات ضعيفة من ذلك العصر. لذلك لا تصلح تفاصيل DES وMD5 في RFC 1964 كتوصية معاصرة. أما الدرس التشغيلي فيبقى صالحاً: تحدد المواصفة المشتركة أقل انتقال يمكن التحقق منه، ثم تظل القرارات التالية لدى المشاركين الذين يشغلون الشفرة ويتحملون الأثر. هذه قراءة تحريرية تستفيد من مبدأ Running-Code Primacy، وليست ادعاءً تاريخياً عن نية واضعي البروتوكول.

المصادر