الخلاصة

  • أتاح P-Preferred-Identity للمستخدم أن يقترح هوية من بين هوياته الصحيحة، لكنه ظل تلميحا لا دليلا، وكان على الوكيل حذفه قبل تمرير الرسالة.
  • لم تكتسب P-Asserted-Identity معناها داخل نطاق الثقة إلا عندما صادق الوكيل على المنشئ وبناها بنفسه؛ أما القيمة القادمة من جهة غير موثوقة فكان يجب استبدالها أو إزالتها.

العرض والاختيار والتأكيد ليست صوتا واحدا

كان SIP يملك حقل From بالفعل، وفيه يستطيع الطرف أن يعرض الاسم أو اللقب الذي يناسب المحادثة. غير أن شبكات الهاتف احتاجت أحيانا إلى قيمة أخرى لتقديم هوية المتصل أو تشغيل خدمة أو تتبع أصل الطلب. وفي الوقت نفسه قد يرغب المستخدم في ألا تصل تلك القيمة التشغيلية إلى الطرف النهائي. لم يحاول RFC 3325 تحويل From إلى شهادة أقوى، بل وزع الأدوار على ثلاثة أفعال مختلفة.

ظل From عرضا يقدمه المستخدم. وجاء P-Preferred-Identity من وكيل المستخدم ليقول لأول وكيل موثوق: إذا كانت لدي عدة أرقام أو معرفات SIP صحيحة بعد المصادقة، فأنا أفضل هذا المعرف. أما P-Asserted-Identity فكان قول الشبكة بعد أن صادقت على المنشئ أو قبلت قول عقدة موثوقة أخرى. تشابه الاسمين لم يعن تشابه السلطة؛ الأول اختيار، والثاني مسؤولية تتحملها البنية الموثوقة.

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

بعد اتخاذ القرار، يجب على الوكيل إزالة P-Preferred-Identity التي قدمها المستخدم من كل رسالة يمررها. لم يكن الحذف تنظيما شكليا. كان يحمي نسب الدليل. لو سافر الاختيار إلى جانب التأكيد، فقد تعدهما سجلات أو تطبيقات لاحقة شاهدين مستقلين، مع أن أحدهما لم يكن سوى المدخل الذي أثر في إنتاج الآخر.

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

لا تمنح كتابة اسم الحقل سلطة لصاحبه

تظهر المشكلة بصورة أوضح عندما يرسل جهاز غير موثوق P-Asserted-Identity جاهزا. معرفة الاسم المميز للحقل لا تجعل المرسل ممثلا لنطاق الثقة. إذا أراد الوكيل إضافة تأكيد، فعليه أن يصادق على منشئ الطلب ويستخدم الهوية الناتجة من تلك العملية.

إذا احتوى الإدخال غير الموثوق على هوية SIP أو SIPS مؤكدة، وجب على الوكيل استبدالها بهوية واحدة من نوع SIP أو SIPS يبنيها بنفسه، أو حذف الحقل. وتنطبق القاعدة نفسها على الهوية الهاتفية. لم تسمح المواصفة بالإبقاء على القيمة القديمة ثم إضافة علامة ثقة إليها. كان لا بد أن تختفي السلطة المزيفة أو يعاد بناؤها من أدلة يسيطر عليها الوكيل.

أما P-Asserted-Identity القادمة من عقدة يثق بها الوكيل فيمكن استخدامها كما لو كان الوكيل قد صادق على المستخدم بنفسه. لكن هذا الاختصار يحمل جميع افتراضات Trust Domain التي عرضها RFC 3324: استقبال آمن، وعضوية مضبوطة، ووثيقة Spec(T) تحدد طرق المصادقة وحماية القناة والأعضاء وقواعد الخصوصية والامتثال. لم يكن الحقل شهادة تشفير قائمة بذاتها.

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

الخصوصية فرضت حذفا ثانيا

بعد بناء الهوية عند المدخل، بقي على كل وكيل أن يصنف القفزة التالية. إذا كان المقصد موثوقا، أبقى الوكيل على التأكيد الذي أنشأه أو تلقاه من مصدر موثوق. وإذا لم يكن المقصد موثوقا، وجب فحص حقل Privacy.

أضافت المواصفة الرمز id الذي يلزم الوكيل بإزالة جميع قيم P-Asserted-Identity قبل إرسال الطلب إلى العنصر غير الموثوق. أما القيمة المقابلة none فتمنع حذف الهوية المؤكدة بسبب الخصوصية. وإذا غاب حقل Privacy، تحدد سياسة النطاق الموثقة في Spec(T) السلوك. أوصى RFC بالإبقاء على الهوية عندما تسمح السياسة، لأن حذفها قد يعطل خدمات، لكنه حذر أيضا من أن تمريرها قد يكشف معلومات لم يطلب المستخدم نشرها ولا يستطيع منع كشفها إذا لم تتوفر خدمة خصوصية مناسبة.

يمكن أن يحمل الحقل قيمة واحدة، أو قيمتين إذا كانت إحداهما SIP أو SIPS وكانت الأخرى هاتفية. عندما تنطبق الخصوصية يجب حذف القيم كلها. حذف تمثيل واحد وترك الآخر يكشف الشخص نفسه بصيغة مختلفة ويجعل الحماية شكلية.

فرضت المواصفة قاعدة متناظرة على وكيل المستخدم المستقبل. إذا لم يكن العنصر السابق موثوقا، فلا يجوز استخدام P-Asserted-Identity بأي طريقة. وإذا وصلت القيمة داخل نطاق الثقة الصحيح، تستطيع سياسة الخدمة أو التطبيق أن تقرر كيفية عرضها. لم تحدد المواصفة طريقة التوفيق بين عدة قيم من أنواع مختلفة.

حدّث RFC 5876 بعض تفاصيل RFC 3325 لاحقا. وطور RFC 4474 وRFC 8224 وRFC 8225 نماذج أخرى للهوية المصادق عليها وPASSporT، بينما تناول RFC 4916 الهوية المتصلة خلال الحوار. لا تلغي هذه التطورات درس التصميم الأول: السلطة لا تأتي من اسم حقل يبدو رسميا، بل من سلسلة تحويل قابلة للتدقيق تشمل المصادقة، وحصر المجموعة الصحيحة، والاختيار، وإعادة البناء، وحذف التلميح، وتصنيف القفزة التالية، ثم إزالة التأكيد إذا طلبت الخصوصية ذلك.

يسجل RFC 3325 لحظة مهمة في تاريخ أدلة الشبكات. قد يكون إدخال المستخدم مشروعا ومفيدا للقرار، من دون أن يكون دليلا على القرار نفسه. لا يصنع الوكيل إيصالا يخصه إلا عندما يرفض أن يسمح لاختيار المستخدم بالبقاء وكأنه شاهد آخر على صحة النتيجة.

المصادر