الخلاصة

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

من السهل أن تُقرأ عبارة الهوية المتصلة بوصفها وعداً كاملاً: تم الوصول إلى الجهة المطلوبة، وهي من يتحدث الآن، وسيبقى الاتصال معها، والجهاز يعرف أنه آمن. لكن RFC 9970 لا يبني ذلك الوعد. فعمل Chris Wendt وJon Peterson يفتح مساراً أضيق: يمكن لاستجابة SIP الراجعة أن تحمل رأس Identity، وأن يوقّع نوع rsp في PASSporT عنوان سجل الطرف الذي وصل إليه الاتصال في dest.

يشمل ذلك استجابات مؤقتة ونهائية مثل 100 و180 و183 و200. وهذه إضافة عملية لأن المتصل كان قد يرى نجاح الحوار من دون برهان تشفيري في الاتجاه العكسي على الوجهة التي وصل إليها المسار. وإذا غُيّرت الوجهة أثناء العبور بطريقة مخوّلة، قد تعود الاستجابة أيضاً بسلسلة div PASSporT. عندئذ يمكن التمييز بين الوجهة المطلوبة والوجهة التي ردت وتفسير التحويل، بدلاً من اعتبار نشوء الحوار دليلاً كافياً على الهوية.

لكن صحة بنية الرمز لا تنشئ الثقة به. يجب على الطرف المنهي أن يملك اعتماداً مناسباً لـdest؛ وإلا فالنص يمنعه من إرسال rsp. وعلى الطرف الذي يعتمد عليه أن يثق بالشهادة وأن يملك تأكيداً معقولاً بأنها مؤهلة للتوقيع لذلك الرقم. التحقق يربط عبارة بمفتاح، لكنه لا يقرر من منح الشهادة، ولا لماذا ينطبق اعتمادها على هذا الرقم، ولا إن كانت سياسة المؤسسة تقبل تلك العبارة في هذه المكالمة.

وتظهر الحدود عند اختلاف الوجهة. فإذا وقّع rsp قيمة dest غير القيمة التي وردت في الطلب المنشئ للحوار، فيلزم أن يصاحبه div واحد على الأقل. ومع ذلك، تظل الثقة في rsp أو div مسألة سياسة محلية. قد تقرر جهة مالية عدم قبول أي تحويل غير متوقع، بينما تقبل خدمة أخرى تحويل المناوبة المعروف. البروتوكول يوفر مواد للفحص، ولا يحوّلها إلى قرار ملزم للجميع.

كما أن الاستجابة في SIP لا تُعامل كالطلب. لا يستطيع المستلم رفضها وإرجاع خطأ إلى مرسلها. إذا وجد المتصل مشكلة في استجابة مؤقتة، فخياره هو CANCEL؛ وبعد إنشاء الحوار، BYE لإنهائه. وقد لا تصل الاستجابات المؤقتة أصلاً من دون آلية الموثوقية المناسبة، وقد يستهلكها وسيط. لذلك لا ينبغي أن تعني غياب rsp هجوماً بصورة آلية، ولا ينبغي أن تعني صحة التوقيع السماح الآلي بالاستمرار. يلزم ربط الإشارة بما كان متوقعاً وبأهمية الوجهة وبخيارات الإنهاء المتاحة فعلاً.

والفصل الحاسم هنا هو بين الإشارة والوسيط. قد تُجاب المكالمة ثم تُحوّل أو تُعلّق أو تتبدل الجهة التي تتعامل معها لاحقاً، من دون أن يعلم المتصل. RFC 9970 يعالج انتحال استجابة أو رسائل في منتصف الحوار أو في نهايته، مثل BYE مزوّر أو re-INVITE مزوّر. ولا يدعي أنه يثبت من يرسل الوسيط بعد ذلك. فلا يرث الصوت أو الفيديو هوية الاستجابة الموقعة تلقائياً.

وهذه قراءة منسجمة مع Running-Code Primacy لدى Lu Heng: ينبغي أن يقال بوضوح ما الذي تسمح به القاعدة القابلة للتحقق، وأن يبقى الحكم ذو الأثر عند الطرف الذي يمكنه تحمله وتبريره. يجعل rsp ادعاء الوجهة قابلاً للفحص؛ وتحكم جهة الشهادات الأهلية؛ ويقرر الطرف المعتمد القبول؛ وتحتاج حماية الوسيط إلى آليتها الخاصة. وضع كل ذلك في شارة واحدة يمنح حق قرار لبيان لم يصمم لاتخاذه.

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

المصادر