الخلاصة

  • في التبادلات التي تتضمن رداً، يكوّن RFC 2025 قيمة Context ID من randSrc الذي يقدمه البادئ ثم randTarg الذي تضيفه الجهة المستهدفة. وجود الجزأين يسجل مساهمة كل طرف في فصل السياق الجديد عن السياقات القديمة.
  • يتألف SPKM-2 أحادي الطرف من SPKM-REQ فقط. لا تضيف الجهة المستهدفة قيمة عشوائية، ولذلك إما أن تثق بحداثة قيمة البادئ أو ترفض السياق. يقوّي key-src-bind الربط بين الطلب والمفتاح، لكنه لا ينشئ مساهمة من الجهة المستهدفة.
  • الحماية من إعادة تشغيل تبادل إنشاء السياق، وخدمات replay/sequence الاختيارية للرسائل اللاحقة، مستويان منفصلان. كما أن Context ID لا يثبت التفويض أو التسليم أو تحقق نتيجة تجارية.

إيصال يمكن عدّ المساهمين فيه

يحدد RFC 2025 آلية Simple Public-Key GSS-API Mechanism، أو SPKM. تحمل رموز إنشاء السياق حقولاً كثيرة، غير أن طريقة تكوين Context ID تقدم أثراً واضح المصدر. يرسل البادئ randSrc. وإذا كان في التبادل رد، تضيف الجهة المستهدفة randTarg. ويصبح تسلسل القيمتين هو المعرّف المستخدم في رموز ذلك السياق بعد ذلك.

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

لا يشترط RFC 2025 أن تكون القيم العشوائية غير قابلة للتنبؤ. المطلوب هو احتمال مرتفع جداً بألا تكون قد استُخدمت من قبل. وظيفتها عدم التكرار بين السياقات، لا إخفاء سر. وصف القيمة بأنها أقوى عشوائياً لا يوسع نطاق ما تثبته.

الاستثناء الذي لا يحمل رداً

يحصل SPKM-1 دائماً على رد من الجهة المستهدفة. تستخدم المصادقة أحادية الطرف SPKM-REQ ثم SPKM-REP-TI، وتضيف المصادقة المتبادلة SPKM-REP-IT. ويتضمن SPKM-2 المتبادل رداً أيضاً. لذلك تتاح في هذه المسارات فرصة لإضافة randTarg.

أما SPKM-2 أحادي الطرف فينتهي بعد SPKM-REQ واحد. لا يوجد رمز عائد يحمل قيمة عشوائية من الجهة المستهدفة، فيقتصر Context ID على قيمة البادئ. وتذكر المواصفة النتيجة بوضوح: على الجهة المستهدفة أن تثق بأن البادئ قدم قيمة حديثة، وإلا فعليها رفض السياق.

الفرق ليس مجرد توفير جولة اتصال. في التبادلات ذات الرد، يستطيع الطرف الذي يقبل السياق أن يضع مساهمته الخاصة في عدم التكرار داخل المعرّف المشترك. في الحالة أحادية الطرف، لا يملك سوى تقييم ادعاء البادئ. يظل Context ID مفيداً للتعريف، لكنه لا يشهد بأن الطرفين صنعا الحداثة معاً.

ما الذي يضيفه key-src-bind فعلاً

توجد حماية إضافية لـSPKM-2 أحادي الطرف. إذا لم تربط خوارزمية إنشاء المفتاح اسم المصدر بمفتاح السياق بنفسها، يجب أن يحمل SPKM-REQ قيمة key-src-bind، وهي خلاصة MD5 للاسم المصدر المشفر والمفتاح المقترح.

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

الربط بين الهوية والمفتاح، ومصدر الحداثة، والمصادقة المتبادلة ثلاثة وقائع مختلفة. اختزالها إلى خانة واحدة باسم «تم إنشاء السياق» يمحو الحد الذي حافظ عليه البروتوكول.

مستويان مختلفان لإعادة التشغيل

يمكن لـSPKM أيضاً فحص تكرار الرسائل المحمية وترتيبها بعد إنشاء السياق. تستخدم هذه الخدمات أرقاماً تسلسلية حين يطلبها التطبيق. ولا تنشأ تلقائياً من القيم العشوائية في Context ID.

تعامل المواصفة العامة لـGSS-API، RFC 2743، replay وsequence لكل رسالة كخدمتين اختياريتين. يطلبهما المستدعي، ويبلغ الطرف القابل بما توفر. وقد تشير إحدى البرمجيات إلى التكرار أو اضطراب الترتيب بحالة إضافية ثم تمرر الرسالة المشكوك فيها إلى المستدعي. ويبقى نقل الرموز مسؤولية التطبيق.

لذلك يجب أن يفصل التدقيق بين سؤالين: هل تم تمييز محاولة إنشاء السياق هذه عن محاولة قديمة؟ وهل خضعت الرسائل اللاحقة لفحص التكرار أو الترتيب داخل السياق المقبول؟ يساعد Context ID في الأول، بينما تلزم الأعلام المتفق عليها وحالة التسلسل ونتائج فحص الرسائل للإجابة عن الثاني.

سجل للمعيار لا دليل على الانتشار

يسجل RFC Editor الوثيقة RFC 2025 باعتبارها Proposed Standard نُشرت في أكتوبر 1996، ولم يُظهر بحث التصحيحات أي تصحيح منشور وقت هذه المراجعة. كما يحتفظ سجل SMI لدى IANA بمعرّفات الكائنات الخاصة بـSPKM-1 وSPKM-2 وSPKM-3 ورموز SPKM GSS. تثبت هذه السجلات تاريخ المواصفة وتخصيص المعرّفات، لا استخدامها المعاصر.

عرّف RFC 2847 لاحقاً SPKM-3 بأنه مكافئ لـSPKM-1 باستثناء تغييرات محددة. تفيد هذه الصلة في تتبع عائلة الآليات، لكنها لا تغير الحد الإثباتي في RFC 2025: لا تُقرأ قيمة Context ID على نحو صحيح إلا مع نمط التبادل الذي أنتجها.

الخلاصة المنضبطة قصيرة. يسجل randSrc || randTarg مساهمة ثنائية في حداثة السياق. أما Context ID في SPKM-2 أحادي الطرف فيسجل مساهمة البادئ وحده، حتى مع وجود key-src-bind. ولا يثبت أي منهما بمفرده تفويض الشهادة أو اختيار الخوارزمية أو وصول الرسالة أو اكتمال عملية.

المصادر