الخلاصة

  • اقترحت RFC 927 خيار Telnet رقم 26، واسمه TUID، كي يرسل مضيف سبق أن وثّق المستخدم معرّفاً ثنائياً من 32 بت إلى هدف موافق.
  • كان لا بد أن يتفق الطرفان عبر WILL TUID وDO TUID قبل إرسال القيمة؛ وأبقى WON'T وDON'T الرفض نتيجة بروتوكولية طبيعية.
  • سمّت الثمانيات الأربع المستخدم الذي يدّعيه المصدر. لم تثبت فحص كلمة المرور بذاتها، ولم تمنح إذناً لدى الهدف، ولم تثبت أثراً تطبيقياً.

نشر Brian A. Anderson من BBN RFC 927 في ديسمبر 1984 تحت عنوان TACACS User Identification Telnet Option. بدأت المسألة من احتكاك يومي: يعطي المستخدم اسمه وكلمة مروره إلى Terminal Access Controller، أو TAC، ثم قد يطلب منه المضيف الذي يصل إليه عبر Telnet أن يعيد العملية.

حمل الحل المقترح اسم TUID ورقم الخيار 26. يعلن Telnet في جهة المستخدم أنه سيوثّق الشخص ويرسل UUID الخاص به. ويعلن Telnet الخادم أنه يقبل الاعتماد على ذلك التوثيق. بعد الاتفاق تنتقل قيمة ثنائية من 32 بت.

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

بقي السر في المصدر وسافرت الشهادة

تقول RFC 927 إن TACACS كان يشترط زوجاً صحيحاً من الاسم وكلمة المرور قبل أن يصل المستخدم إلى مضيف عبر TAC. ولتجنب توثيق ثانٍ، يستطيع TAC أن يرسل ما يسميه النص «هوية المستخدم المثبتة»، أي UUID الخاص به.

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

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

سبق الاتفاق إرسال الرقم

بنت RFC 854 Telnet على طرفية افتراضية أساسية وخيارات قابلة للتفاوض. عبّرت WILL وDO وWON'T وDON'T عن العرض والطلب والقبول والرفض. وأضافت RFC 855 ترتيباً للخيارات التي تحمل معاملات: يتفق الطرفان أولاً على فهم الخيار، ثم تبدأ المفاوضة الفرعية للقيم.

في TUID عنت IAC WILL TUID أن جهة المستخدم مستعدة لتوثيق المستخدم وإرسال معرّفه. وعنت IAC DO TUID أن جهة الخادم تريد القيمة وتوافق على قبول توثيق الطرف الآخر. رفض WON'T دور المصدر، ورفض DON'T ثقة الهدف.

بعد ذلك فقط حملت الصيغة IAC SB TUID <uuid> IAC SE الثمانيات الأربع. عرضت RFC حالتين ناجحتين: قد يطلب الخادم أولاً، أو يعرض المستخدم أولاً. وعرضت أيضاً نهاية واضحة حين يرفض أحدهما.

كان الوضع الافتراضي هو الرفض. يرد برنامج المستخدم غير الداعم بـWON'T، ويرد الخادم غير الداعم بـDON'T. لم يتحول الجهل بالخيار إلى ثقة صامتة؛ بقيت جلسة Telnet العادية وسياسة الدخول المحلية متاحة.

كان UUID هنا 32 بت فقط

يرتبط UUID اليوم غالباً بصيغة من 128 بت. أما RFC 927 فتعرّف <uuid> بأنه عدد ثنائي من 32 بت. وتوضح كيف تنتقل القيم 1 و255 والقيمة ذات البتات كلها واحداً داخل المفاوضة الفرعية.

حجز Telnet الثمانية 255 للأمر IAC، لذلك كان لا بد من مضاعفتها إذا ظهرت داخل المعرّف. تمثل القيمة العددية 255 بثلاث ثمانيات صفرية ثم IAC IAC. هذه شفافية للبيانات، لا تشفير ولا توقيع.

لم تحدد RFC جهة تخصيص عالمية، أو طريقة لمنع التصادم، أو مدة صلاحية، أو إعادة استخدام، أو nonce، أو طابعاً زمنياً، أو حماية من الإعادة، أو ربطاً تشفيرياً بالقناة. ولم تحدد كيف يربط الهدف الرقم بحساب محلي. لا يصبح العدد حقيقة عالمية لمجرد أنه صحيح الطول.

يمكن لالتقاط الحزم أن يثبت أن طرفاً قدم أربع ثمانيات بوصفها معرّف المستخدم بعد تفعيل الخيار. لا يثبت من أدخل كلمة المرور، أو سلامة نظام المصدر، أو أن الرقم لم يُعد تخصيصه، أو أن الهدف اختار الحساب الصحيح.

قبول التوثيق لا يساوي منح الصلاحية

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

تساعد RFC 1492، وهي إعادة بناء معلوماتية لـTACACS من 1993، على رؤية الفصل. وصفت طلب اسم وكلمة مرور يقبله daemon أو يرفضه، ثم وصفت CONNECT كطلب آخر داخل سياق دخول قائم لمعرفة هل يجوز فتح اتصال إلى عنوان ومنفذ محددين.

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

تصف RFC 8907 TACACS+ اللاحق. تفصل بين التوثيق والتفويض والمحاسبة، وتذكر أن البروتوكول لا يربط طلب توثيق بطلب تفويض على مستواه. ليست دلالات TACACS+ دلالات رجعية لـTUID؛ لكنها تسمي فرقاً دائماً: معرفة الهوية المدعاة ليست قراراً بما يسمح لها فعله.

كان حق الرفض جزءاً من التشغيل البيني

سمحت RFC 927 لأي مضيفين متعاونين باستخدام TUID، وضربت مثالاً بمضيفي موقع واحد. لم تنشئ سلطة هوية مركزية تفرض نفسها على الجميع. وحدت شكل العرض والقبول والرفض والقيمة، وتركت سياسة الثقة محلية.

ما زال سجل IANA لخيارات Telnet يسجل الرقم 26 باسم TACACS User Identification ويحيل إلى RFC 927. يثبت السجل تخصيص الرمز، لا انتشار التنفيذ ولا الاستخدام الحالي.

كان DON'T TUID قدرة، لا عطلاً. إذا لم يستطع الهدف أن يقول «لا»، لصارت راحة المصدر أمراً مفروضاً على نظام آخر. جعلت اللغة المشتركة الثقة مفهومة، وجعلت عدم الثقة مفهوماً أيضاً.

احتاجت شاشة أبسط إلى سجل أغنى

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

يسقط سجل يقول فقط «نجح الدخول» كل هذه القرارات. لا يبين هل فُحصت كلمة مرور محلية، أم قُبل TUID، أم رُبط حساب، أم فُوّض أمر، أم فُتح النقل فقط. لا ينبغي لاختصار الواجهة أن يختصر الأدلة.

يجب فصل نتيجة توثيق المصدر، وتسلسل WILL/DO، وقيمة TUID وفضائها، وسياسة ثقة الهدف، وربط الحساب، والتفويض، ونتيجة التطبيق. كل حدث يثبت القرار الذي اتخذه صاحبه فحسب.

لم تحل RFC 927 الهوية الرقمية الشاملة. أظهرت صفقة أصغر وأكثر دقة: تختفي الإعادة عندما يتحدث مضيف باسم فحص أجراه، ويختار مضيف آخر تصديقه. عبر UUID الاتصال؛ وبقي قرار الثقة عند من يدير الوجهة.

المصادر والحدود

يعتمد هذا المقال على RFC 854 و855 و927، وسجل IANA، ومقارنتين محدودتين في RFC 1492 و8907. تثبت هذه المصادر الصيغة والدافع المعلن وتخصيص الرقم وفواصل لاحقة. لا تثبت انتشاراً واسعاً، أو حماية تشفيرية، أو نسباً مباشراً إلى تسجيل الدخول الاتحادي الحديث، أو نجاح جلسة فعلية.