قابلية الوصول إلى عنوان سري تثبت الاستلام، لا هوية دائمة

الخلاصة

• يثبت return routability أن طرفا استطاع استعمال URI سري وصل إلى endpoint محدد وفق شروط الحماية، لكنه لا يحول حيازة السر إلى هوية دائمة أو فهم بشري أو تفويض مفتوح.
• يضع RFC 5360 الإذن داخل translation logic للـ relay. يبقى HTTP 202 قبولا لطلب إداري قيد المعالجة إلى أن يصادق relay على grant محدد بالـ sender والـ target URI والـ final recipient URI.
• تفصل قاعدة متلق واحد لكل معاملة و470 Consent Needed وTrigger-Consent بين منع التضخيم وسلامة القائمة والإلغاء. ولا يثبت أي منها وحده صحة fan-out أو التسليم أو توقف الإرسال بعد الرفض.

ما الذي يثبته المسار الراجع فعلا

ينشئ relay عنوان grant وعنوان deny لا يمكن تخمينهما بسهولة، ويرسلهما في permission document إلى المتلقي المقترح. إذا عاد طلب إلى أحد العنوانين، يستطيع relay استنتاج أن الجهة التي أرسلته حصلت على القدرة السرية.

يضع RFC شروطا لهذا الاستنتاج. يجب أن يصل MESSAGE إلى SIPS URI، وأن تكون قدرات grant وdeny من نوع SIPS أو HTTPS، وأن يحتوي الجزء العشوائي على 32 بت على الأقل من العشوائية التشفيرية.

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

يمكن أن تمر القدرة عبر forwarding أو store-and-forward أو جهاز مشترك. وإذا تسربت، فقد يبدو الاستعمال اللاحق صحيحا من ناحية البروتوكول بينما فقد صلته بالشخص المقصود.

لذلك يحفظ السجل جودة التوليد وادعاء entropy وhash القدرة بدلا من النص القابل لإعادة الاستعمال ومسار التسليم المحمي ووقت الاسترداد وسياق المصدر وسياسة replay.

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

الإذن يحكم مكان تنفيذ التحويل

يستقبل relay طلبا موجها إلى target URI ثم يحوله إلى recipient URI واحدة أو أكثر. وقد يكون proxy أو B2BUA أو مزيجا منهما. القوائم والتسجيلات والسياسة المحلية تغذي هذا التحويل.

لهذا لا تكفي ملاحظة في دفتر عناوين المدير. يجب أن تكون permission قريبة من translation logic التي ستقرر إنشاء الطلبات الصادرة.

إذا لم يمنح recipient إذنه، يتجاهله relay عند التحويل. وإذا منحه، يجب أن يرتبط كل runtime match لاحق بنسخة الإذن الفعلية وبالنطاق الذي وافق عليه.

تثبت صورة شاشة إعداد أن المدير اقترح ربطا. وتثبت capability مصادق عليها أن recipient اتخذ قرارا معينا. لكن لا واحدة منهما تثبت أي نسخة من الخريطة استعملها relay عندما وصل INVITE أو MESSAGE لاحق.

يحتاج الإيصال التنفيذي إلى sender والـ target والـ final recipient ونسخة permission ومعرف الطلب الصادر. كما يجب تمييز custody الـ B2BUA الذي ينهي الطلب ويعيد إنشاءه عن proxy الذي يمرره.

مدير القائمة لا يملك موافقة المتلقي

يتعين مصادقة العميل وتخويله قبل السماح له بتغيير القائمة. هذا يمنع التعديل العشوائي، لكنه لا يمنح العميل سلطة على URI تخص شخصا آخر.

يفصل الإطار بين قرارين. تسمح السياسة للمدير بأن يقترح العضوية. ويقرر المتلقي ما إذا كان يسمح للـ relay بتحويل traffic إلى عنوانه ضمن السياق المحدد.

يجب أن يحتفظ audit بمن اقترح الإضافة، والسياسة التي سمحت بها، والهوية التي طُلب منها الإذن، وما عُرض عليها، والطريقة التي صودق بها على الرد.

عبارة «أضافه مستخدم مخول» لا تكفي. فهي تمحو القرار الذي صمم RFC 5360 لحماية صاحبه.

امتلاك اسم المجموعة وتشغيل الخدمة والتحكم في recipient URI ثلاثة أنواع مختلفة من السلطة. ولا تستطيع القائمة الجماعية ابتلاع موافقة كل عضو.

HTTP 202 إيصال انتظار

عندما يطلب A إضافة B، قد يقبل relay العملية عبر HTTP 202. يوضع B في pending لأن موافقته لم تصل بعد.

يفيد الرد أن الخدمة قبلت مسؤولية متابعة المعالجة. لا يعني أن B وافق، أو أن permission ثبتت، أو أن طلبا لاحقا طابقها، أو أن traffic وصل.

توجد حزمة أحداث Pending Additions لأن النتائج غير متزامنة. تميز الحالات بين pending وwaiting وerror وdenied وgranted. وقد يفشل MESSAGE نفسه إذا كان B غير متصل ولا تتوفر خدمة store-and-forward.

احفظ manipulation ID والـ target والـ recipient والرد ونسخة pending وكل NOTIFY لاحق. ويجب أن يشير الانتقال إلى granted إلى document ومصادقة محددين.

عرض كلمة «accepted» وحدها يسمح لسلطة الإدارة أن تقترض معنى موافقة المتلقي. هذه قفزة لا يقدمها البروتوكول.

وثيقة الإذن علاقة محددة

تضم permission document هوية sender والـ original recipient أو target URI والـ final recipient URI وقدرات grant وdeny. هذه ليست تفاصيل تجميلية؛ إنها حدود السلطة.

قد يكون sender واسعا، وقد يقبل target wildcard في نموذج الوثيقة، لكن final recipient لا يجوز أن يكون wildcard. يمنع ذلك نقل «نعم» واحدة إلى وجهات مستقبلية لم تعرض على صاحب القرار.

تبقى أسئلة التفسير. هل أظهرت الواجهة wildcard؟ هل تطابق النص البشري مع تمثيل الآلة؟ هل تغير alias الـ target بعد grant؟ هل اتسع نطاق sender بسبب تغيير في نظام الهوية؟

احفظ bytes الوثيقة وhash ونسخة الصيغة وهوية relay والـ sender والـ target والـ recipient وhash قدرات grant وdeny وhash العرض البشري.

لا يسمح متغير مثل consented=true بإعادة بناء المعنى. إنه يمحو الأطراف والنطاق والزمن.

المصادقة ليست قيمة منطقية واحدة

يرسل المتلقي SIP PUBLISH أو HTTP GET فارغ الجسم إلى capability الخاصة بالمنح أو الرفض. يحمل URI نفسه الصلة بإذن بعينه.

على relay التأكد من أن الفاعل هو مالك final recipient URI. يناقش RFC آليات SIP Identity وP-Asserted-Identity داخل نطاق إداري موثوق وSIP Digest عند وجود سر مشترك وreturn routability.

تعتمد كل آلية على custody مختلفة. ثقة P-Asserted-Identity تنتهي عند حدود النطاق. Digest يعتمد على ملكية السر وحالة challenge. الهوية الموقعة تعتمد على السلسلة المطبقة. والمسار الراجع يثبت حيازة القدرة بالشروط المحدودة السابقة.

بدلا من authenticated=true، سجل الطريقة والـ asserted principal والـ recipient الذي جرى التحقق منه ونطاق الثقة أو سياق credential وhash القدرة ونسخة السياسة والقرار.

نجاح مصادقة شخص آخر ليس موافقة صحيحة. المطلوب مقارنة originator بمالك URI النهائي.

متلق واحد لكل معاملة يحد من التضخيم

يمكن للـ relay نفسه أن يصبح أداة amplification. يرسل مهاجم طلب إعداد صغيرا يضيف عددا كبيرا، ثم يرسل relay طلب إذن إلى كل عنوان.

يشترط RFC أن تضيف معاملة XCAP متلقيا واحدا فقط، وكذلك contact واحدا في معاملة REGISTER ضمن هذا الإطار. فيتحمل الطرف الذي يقترح recipients حجما من الطلبات يقارب ما يولده relay.

هذه ليست rate limit شاملة. يستطيع المهاجم إرسال معاملات كثيرة أو توزيع الحسابات أو الانتظار بين المحاولات. لكنها تزيل مضاعفة فورية كان يشتريها طلب واحد.

سجل principal والـ target والـ recipient وعدد bytes ومعدل الطلب والقرار. رفض معاملة كبيرة يثبت تطبيق هذا الحد فقط، لا سلامة إجمالي الحمل.

تحتاج الخدمة أيضا إلى budgets عبر الحسابات والأهداف والوجهات، وإلى حساب retries وstore-and-forward الذي قد يخفي تكلفة إضافية.

470 يجعل القائمة كلًّا واحدا

تختار request-contained URI list recipients عند وقت الاتصال. يحتفظ relay بمجموعة permissions أوسع ثم يقارن بها القائمة الواردة.

إذا افتقدت URI واحدة الإذن، لا ينفذ relay التحويل ويرد 470 Consent Needed. ويحدد Permission-Missing العناوين الناقصة.

القاعدة all-or-nothing. إرسال traffic إلى المسموحين وإسقاط الآخرين بصمت سياسة أخرى، وقد يكشف تركيبة المجموعة من خلال نتائج متفاوتة.

احتفظ بـ hash القائمة ونسخة permission set ونتيجة كل match والرد 470 ومجموعة العناوين التي كشفها. وهذه المجموعة نفسها قد تكون حساسة.

تظهر صفحة errata المحفوظة تقريرا تقنيا بحالة Reported عن استعمال angle brackets عندما تجعل العلامات URI في Permission-Missing ملتبسة. هو اقتراح مؤرخ، لا تعديل نافذ تلقائيا للنص.

الإلغاء سلسلة لا زر

يمكن للمتلقي استعمال deny capability. وإذا فقدها، قد يحمل طلب محول لاحق Trigger-Consent والـ target URI، فيطلب وثيقة جديدة ثم ينفذ deny.

تبدأ الاستعادة عند trigger لكنها لا تنهي الإذن القديم. 200 يعني قبول طلب الاستعادة، وتسليم MESSAGE يعني وصول وثيقة جديدة. لا تتغير السلطة إلا بعد مصادقة deny وحذف permission من الحالة الفعالة.

سجل نية الإلغاء وtrigger والوثيقة الجديدة والرفض ونسخة الحذف ووقت cutover وآخر طلب خرج تحت grant السابق. وحدد مصير الطلبات المتزامنة.

يزول الإذن أيضا بزوال سياقه. إزالة recipient ينبغي أن تحذف permission، وانتهاء registration ينبغي أن يلغي إذن contact، وفشل refresh ينبغي أن يفعّل قاعدة الإزالة.

غياب رفض صريح لا يساوي صلاحية أبدية. freshness والوجود والسياق أجزاء من التفويض.

202 في third-party REGISTER ليس سلطة forwarding

في التسجيل المعتاد قد يكون المسجل والمتلقي جهة واحدة. أما third-party REGISTER فيسمح لمهاجم بربط Address of Record بcontact ضحية وتوجيه traffic إليها.

يفصل framework القبول عن الإذن. يستطيع registrar الرد 202 مع إبقاء contact في pending حتى يطلب الموافقة، ثم يبلغ النتيجة عبر Pending Additions.

لا يعني ذلك أن كل REGISTER يحتاج حفل موافقة. يميز RFC حالة user agent الذي يسجل ويتلقى على connection نفسها عن registrar يقبل تسجيل الغير.

يجب أن يسجل الدليل AoR والـ contact والمسجل المصادق عليه وعلاقة connection وعلامة الطرف الثالث وحالة pending وpermission tuple وقرار forwarding.

نجاح REGISTER قد يعني أن الخادم قبل العمل. لا يعني تلقائيا أنه حصل على سلطة إرسال مكالمات إلى contact.

تشفير الوثيقة لا يثبت فهمها

تكشف الوثائق علاقات sender وtarget وrecipient. وإذا عدلها مهاجم، قد يوافق الشخص على معنى مختلف عما رأى.

يوصي RFC بسرية وسلامة قويتين، مثل S/MIME من طرف إلى طرف وTLS/SIPS hop-by-hop عندما لا تتوفر حماية أقوى. كما يحتاج store-and-forward إلى حماية أثناء الحفظ.

تحمي هذه الآليات القناة والمحتوى ضمن افتراضاتها. لا تثبت تطابق النص البشري مع XML، ولا ظهور wildcard، ولا أن الشخص الصحيح فهم القرار، ولا أن relay ثبت الت tuple نفسها.

اربط العرض بـ hash الوثيقة، وسجل حماية النقل مستقلة عن دلالة الموافقة. واختبر mutation وreplay وتسرب capability وقدَم pending وتغير السياسة.

الهدف ليس التقليل من التشفير، بل منع الدليل التقني من الاستيلاء على معنى لم يقسه.

التوضيح اللاحق لا يثبت التنفيذ

يحدث RFC 8217 عددا من وثائق SIP ومنها RFC 5360 لتوضيح مواضع استعمال إنتاج name-addr. وهذا يغير البيئة المعيارية لتحليل حقول متأثرة.

لا يثبت أن relay فعليا شغّل parser الجديد. يجب ربط كل تنفيذ بإصدار البرنامج والتكوين ومجموعة الوثائق الحاكمة.

كذلك، صفة Proposed Standard حالة للوثيقة، لا إثبات تبنٍّ أو interoperability أو تشغيل داخل خدمة مسماة.