الخلاصة

  • جعل Ident كل استعلام خاصاً باتصال بعينه: تُكتب منافذ الخادم والعميل كما يراهما المضيف المستعلَم عنه، ثم يعيد ذلك المضيف معرّف المستخدم الذي يربطه محلياً بهذا المقبس.
  • اقترح RFC 931 استخداماً تجريبياً للاتصال التلقائي في FTP. وفي عام 1993 سمّى RFC 1413 الخدمة بروتوكول التعرّف، ونصّ على أن استجابتها قد تدعم التدقيق، لكنها لا تصلح للمصادقة أو منح صلاحية الوصول.

رقمان ومنظور مضيف واحد

يبدو المثال الأوضح في RFC 1413 كأنه تصحيح لخطأ كتابي. يظهر الاتصال عند أحد الطرفين على النحو 23, 6191، لكن الاستعلام عن الاتصال نفسه عند الطرف الآخر يتطلب إرسال 6191, 23. لم يتغير الاتصال؛ الذي تغير هو المضيف الذي يصف منفذاً بأنه محلي والآخر بأنه بعيد.

كان هذا الانعكاس هو مفتاح عمل البروتوكول. يتصل عميل Ident بالمنفذ TCP 113 لدى مضيف، ثم يرسل سطراً بالشكل <منفذ-الخادم>, <منفذ-العميل>. وتأتي عناوين IP من اتصال TCP بخدمة Ident نفسها. ومع رقمي المنفذين، تحدد هذه العناوين اتصال TCP قائماً بالفعل. عندئذ يستطيع الخادم إعادة المعرّف المرتبط بذلك الاتصال على جهازه، وفقاً لما يسجله نظام التشغيل لديه.

كان نطاق الطلب ضيقاً عن قصد. فهو لا يطلب من خدمة مركزية العثور على شخص عبر الإنترنت؛ بل يسأل مضيفاً كيف ربط نظامه المحلي مقبساً معيناً بسلسلة مستخدم. تتضمن استجابة USERID اسم نظام التشغيل ومعرّفاً، ويمكن لـERROR أن يوضح تعذر تحديد مالك المنفذ. كما عرّف RFC 1413 الاستجابة HIDDEN-USER عندما يستطيع الخادم تحديد المستخدم لكنه يمتنع عن كشف المعلومة بطلب منه.

لم يكن هذا سطح الاستعلام نفسه الذي قدمته خدمة Name/Finger الأقدم. فقد يطلب استعلام Finger الفارغ من مضيف قائمة بمن يستخدمونه في تلك اللحظة؛ أما Ident فيحدد اتصال TCP واحداً عبر زوج منافذ. قائمة الحضور وسلسلة مالك المقبس تجيبان عن سؤالين تشغيليين مختلفين. ويشرح المقال السابق عن Name/Finger حدود الحضور على مستوى المضيف.

«خادم المصادقة» كان فكرة لاستخدام تطبيقي

تبدأ السلسلة مع RFC 912 الذي نشره Mike St. Johns في سبتمبر 1984 بعنوان «Authentication Service». اقترح خدمة TCP على المنفذ 113 تعيد معرّف مالك اتصال TCP محدد. وذكر من الاستخدامات المحتملة المصادقة التلقائية لمستخدم FTP والتحقق من بعض العمليات ذات الامتيازات. لكنه حذّر أيضاً من تفاوت موثوقية المضيفين، وترك لكل تطبيق تحديد مقدار الثقة التي سيمنحها للاستجابة.

حل RFC 931، المنشور في يناير 1985، محل ذلك الاقتراح. وجعل صيغة الاستجابة أكثر رسمية، بحيث تجمع اسم نظام التشغيل مع معرّف المستخدم. وفي حالة FTP رسم مساراً محتملاً: يرسل العميل الأمر USER بلا اسم، وربما يستخدم الخادم خدمة المصادقة. وصف RFC هذا الاستخدام صراحة بأنه تجريبي، وكرر التحذير من اختلاف الثقة بين المضيفين. إنه يوثق طريقة تكامل مقترحة، لا انتشارها على نطاق واسع في خوادم FTP.

وهنا تكمن أهمية الفصل بين رد البروتوكول وقرار التطبيق. لم يتحقق خادم المصادقة من كلمة مرور بصورة مستقلة، ولم يثبت من كان أمام الطرفية. بل أعاد المعرّف المحلي الذي يقول المضيف إنه يخص اتصالاً بعينه. وكان بإمكان خادم FTP أن يقرر استخدام هذه السلسلة، لكن القرار وتبعاته يخصان التطبيق وعلاقته بالمضيف الآخر.

في 1993 كشف الاسم الجديد حدّ الخدمة

ألغى RFC 1413، الذي صدر في فبراير 1993، RFC 931، وغيّر اسم Authentication Server Protocol إلى Identification Protocol، أو Ident، «ليعكس وظيفته على نحو أفضل». وأبقى الخدمة على TCP 113 وعلى زوج المنافذ الخاص بكل اتصال، مع توضيح معالجة عدة استعلامات في اتصال Ident واحد وردود مثل HIDDEN-USER.

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

ينبع هذا الحد من مسار إنتاج البيانات. فالمضيف المستعلَم عنه هو الذي يولّد المعرّف وفق منظور نظام التشغيل لديه. وإذا اختُرق المضيف فقد يعيد بيانات مضللة؛ وقد يستطيع مستخدم في مختبر مفتوح اختيار المعرّف الذي يظهر. إن سلامة صياغة سطر USERID لا تحول تصريح الخادم إلى حقيقة تحقّق منها طرف مستقل. يعرف العميل ما أفاد به المضيف، لا ما إذا كان شخص ما قد خضع لمصادقة في مكان آخر.

لذلك يرسم تغيير الاسم حداً تاريخياً مفيداً، لكنه لا يثبت أن كل الاستخدامات السابقة توقفت. فقد سمّى RFC 1413 الخدمة «تعرّفاً» لا «مصادقة»، وحدد ما يجوز استنتاجه من الرد. ولا توضح الوثائق كم موقعاً شغّل Ident، ولا مدى استخدام HIDDEN-USER، ولا ما إذا كانت برامج FTP معينة اعتمدت عليه. يسجل المعيار التزاماً بروتوكولياً، لا إحصاءً للتبني.

ما الذي يدعمه زوج المنافذ

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

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

المصادر