الخلاصة

  • فصل RFC 3652 غلاف رسالة ثابتاً من 20 ثمانية بتات، مخصصاً للتسليم وإعادة التركيب، عن ترويسة من 24 ثمانية بتات وجسم خاص بكل عملية. لم تشمل التوقيعات الرقمية في Message Credential الغلاف، لكنها شملت الترويسة والجسم.
  • أمكن أن يحمل الاعتماد توقيعاً رقمياً من منشئ الرسالة أو رمز مصادقة للرسائل قائماً على مفتاح جلسة أُنشئ مسبقاً. يصف هذا الحد نطاق سلامة البروتوكول، لا هجوماً موثقاً أو عيباً تنفيذياً أو استحالة وجود حماية في طبقة أدنى.

رسالة واحدة، ومساحات ثقة مختلفة

في عام 2003، كان على مواصفة بروتوكول Handle أن تحدد أكثر من مجرد الاستعلام. احتاج العميل إلى العثور على خادم Handle المسؤول، وطلب حلّ معرّف Handle أو إدارته، ثم فهم الرد. وكان على البروتوكول أيضاً نقل الرسائل عبر وسائل لا تعرض البيانات بالطريقة نفسها. رتّب RFC 3652 الإصدار 2.1 هذه المهام في أربعة أجزاء متجاورة: Envelope وHeader وBody وCredential. RFC 3652

كان الغلاف إلزامياً وثابتاً بطول 20 ثمانية بتات. وصفه RFC بأنه غلاف للتسليم، لا بيانات تطبيق. شملت حقوله إصدار البروتوكول وأعلام الرسالة، ومعرّف الجلسة، ومعرّف الطلب، ورقم التسلسل وطول الرسالة. أما الترويسة الإلزامية فبلغت 24 ثمانية بتات، وحملت الحقول المشتركة مثل رمزي العملية والاستجابة. وحمل الجسم بيانات العملية المحددة، وقد يكون فارغاً. RFC 3652

لم يتطابق حد الثقة مع حد الحزمة. ينص RFC 3652 على أن التوقيع الرقمي في Message Credential لا يحمي محتوى الغلاف، لكنه يحمي الترويسة والجسم. وقد يتضمن Credential غير الفارغ توقيعاً رقمياً من منشئ الرسالة أو رمز MAC أحادي الاتجاه مبنياً على مفتاح جلسة قائم. يقدّم النص الاعتماد وسيلة لمصادقة الرسالة وفحص سلامة بياناتها أثناء النقل. يعتمد MAC على سر مشترك، بينما يستخدم التوقيع الرقمي نموذج مفاتيح مختلفاً. RFC 3652 RFC 2104

وافق هذا الفصل وظيفة الغلاف. أمكن لعميل Handle استخدام مخططات UDP أو دفق بايتات TCP. وحدد RFC 3652 رسائل UDP بما لا يتجاوز 512 ثمانية بتات، دون احتساب ترويستي IP وUDP. وكان لا بد من تجزئة الرسائل الأطول، مع حمل كل جزء رقم تسلسله في الغلاف كي يعاد تركيبه. أما TCP فيوفر دفقاً من البايتات، لكنه لا يحدد حدود رسالة Handle؛ لذلك ظل البروتوكول قادراً على تجزئة الرسائل الكبيرة وإعادة تركيبها. RFC 3652 RFC 768 RFC 793

على خلاف ذلك، وصفت الترويسة والجسم ما يفعله العميل والخادم. يطلب رمز العملية نوعاً من عمليات Handle، ويبلغ رمز الاستجابة عن النتيجة: نجاح، أو غياب قيمة، أو إحالة خدمة، أو رفض إذن، أو حاجة إلى المصادقة. اتبع البروتوكول نموذج أسماء وبيانات محدداً في وثيقة منفصلة، بينما وصف RFC 3650 بنية الخدمة الأوسع. وهكذا يبدأ المحتوى الدلالي المحمي بعد غلاف التسليم: إعادة تركيب جزء لا تعني السماح بالعملية التي يحمله. RFC 3652 RFC 3650 RFC 3651

المصادقة ليست الإذن

فصل RFC 3652 أيضاً إثبات العميل عن قرار الخادم بشأن الإذن. في العمليات الإدارية، أمكن للخادم إرسال تحدٍّ، ثم يثبت العميل في رده امتلاك المفتاح الخاص أو السر المشترك المعني. وبعد التحقق من الإثبات، يظل على الخادم التأكد من أن للمسؤول صلاحية كافية للعملية المطلوبة. اجتياز التحدي لا يوافق وحده على تغيير Handle. وقد تشارك جلسة واحدة الحالة والمفاتيح بين عدة عمليات. RFC 3652

يفصل RFC 3552 بين سلامة البيانات، ومصادقة الطرف المقابل، والسرية، وأمن النظام؛ فلا يحقق التوقيع أو MAC هذه الأهداف جميعاً تلقائياً. يناقش قسم الأمن في RFC 3652 توقيعات الخادم ومصادقة العميل، لكن تعريف الصيغة أدق: يغطي Credential الترويسة والجسم، لا غلاف التسليم. لا يثبت ذلك وحده أن رسالة عُدلت في نظام منشور؛ فقد توفر قناة في طبقة أدنى حماية أخرى. RFC 3652 مواصفة بروتوكول، لا تقرير حادث. RFC 3552 RFC 3652

ولا ينبغي الخلط بين اعتماد Handle وملف توقيعات X.509. يعرّف RFC 3279 معرّفات الخوارزميات وترميزات الشهادات وقوائم إبطالها في ذلك الملف؛ لكنه لا يوسّع البايتات التي يوقعها RFC 3652، ولا يجعل الغلاف محتوى موثّقاً. لا يكفي استخدام المصطلحات التشفيرية؛ ينبغي تسمية الكائن الذي تجري حمايته بدقة. RFC 3279 RFC 3652

تصنيف RFC 3652 هو Informational، وتشير ملاحظة IESG إلى أن المناقشات لم تنتج توافقاً في IETF على نظام Handle أو موقعه ضمن بنية المعرّفات في IETF. يصف المستند بروتوكولاً مقترحاً، ولا يثبت اعتماده عالمياً. أما الدرس الأضيق فهو أن تأطير الرسالة وإعادة تركيبها ومصادقتها قد تتبع قواعد مختلفة؛ لذا يجب على أي ادعاء بسلامة الرسالة أن يحدد البايتات التي يغطيها Credential فعلاً. RFC 3652

المصادر