الخلاصة
- صدر RFC 1492 في يوليو 1993 بصفة Informational بعدما تعذر على الكاتب الحصول على مواصفة TACACS الأصلية بسبب مسائل حقوق النشر.
- كان يُعتقد أن تنفيذ Cisco البسيط متوافق مع الأصل، لكن المقارنة مع النص الأصلي لم تكن ممكنة؛ أما النسخة الموسعة وحالة جامعة مينيسوتا فهما شاهدان محدودان على التشغيل لا إحصاءً للتبني.
- يربط nonce جواب UDP بطلب معلق فحسب؛ قرار daemon وفعل خادم الطرفية واتصال الوجهة وسجل المحاسبة إيصالات مستقلة.
يكشف مرور كلمة مرور واضحة عن حدود النقل، لكن غياب النص الأصلي يكشف حدوداً أعمق في السلطة. يذكر RFC 1492 أن مواصفة TACACS الأصلية كانت موجودة، إلا أن الكاتب لم يتمكن من الحصول عليها بسبب مسائل حقوق النشر. كان هذا الغياب السبب الرئيسي لإعداد وثيقة جديدة.
أتاح التعاون مع Cisco Systems مشاهدة تنفيذ للنسخة البسيطة كان يُعتقد أنه متوافق مع الأصل. العبارة حذرة بحق: لا يمكن إثبات التطابق مع وثيقة لم تُفحص. يستطيع الكود أن يبين حقولاً وفروعاً ونتائج مدخلات معينة، لكنه قد يحمل خياراً محذوفاً أو امتداداً خاصاً بالمنتج أو خطأً استمر حتى صار ضرورياً للتوافق.
لهذا حذر RFC من أن العثور لاحقاً على المواصفة الأصلية قد يجعل أجزاء من إعادة البناء معروفة بأنها غير صحيحة. كما أن صفته Informational تعني أنه لم يحدد Internet Standard. النشر منح الرواية ثباتاً وإمكانية للفحص، ولم يمنح تنفيذ المورد سلطة عالمية.
النسخة البسيطة والموسعة لا تملكان النسب نفسه
فصلت الوثيقة بين TACACS البسيط وTACACS الموسع. انطبق الاعتقاد بالتوافق مع الأصل على تنفيذ Cisco البسيط. ودعمت Cisco نسخة موسعة استُخدمت في خوادمها الطرفية وفي نظام المصادقة الموزع بجامعة مينيسوتا. يثبت ذلك وجود استعمال في سياقات مسماة، ولا يثبت انتشاراً واسعاً أو نجاح كل تركيب أو تطابق جميع اللهجات.
حين يغيب المصدر المكتوب ويبقى البرنامج، يصبح البرنامج الطريق الأرخص إلى التشغيل البيني. يقلده الآخرون بما فيه من خصائص عارضة، ثم تعيد الوثائق اللاحقة وصف تلك الخصائص كأنها قصد أصلي. أبقى RFC 1492 فجوة الدليل ظاهرة كي لا تتحول الضرورة العملية إلى يقين تاريخي.
LOGIN لم يكن إذناً دائماً لكل CONNECT
تألف التفاعل من طلب عميل وجواب daemon. احتاج كل طلب إلى جواب، ولذلك أمكن رفض كل طلب. قدم LOGIN بيانات الاعتماد؛ وعند القبول استطاع خادم الطرفية بدء اتصال دخول. أما CONNECT فجاء داخل اتصال قائم وسأل هل يجوز فتح اتصال TCP إلى عنوان وجهة ومنفذ محددين.
نجاح LOGIN لم يسمح بكل وجهة. والجواب الإيجابي لـCONNECT لم يثبت أن خادم الطرفية نفذ القرار أو أن الشبكة أوصلت المحاولة أو أن الوجهة قبلتها. وحتى المحاسبة، إن وُجدت، كانت حدثاً لاحقاً بسجل مستقل.
كان مشغل daemon يتحكم في الخوارزميات والبيانات المستخدمة للقبول والرفض. أعطى ذلك الموقع حرية تطبيق قواعده، لكنه جعل الجواب قراراً محلياً. تنسيق موحد للرسالة لا ينشئ سياسة موحدة للعالم.
أعاد nonce المطابقة ولم يصنع هوية
استخدم ترميز UDP التاريخي المنفذ 49. وضع العميل nonce في الطلب، ونسخه الخادم في الجواب. هكذا أمكن ربط datagram وارد بطلب ما زال معلقاً. لم يصادق nonce المستخدم أو الخادم، ولم يحم سلامة الرسالة أو سريتها.
بعد انتهاء المهلة، أمكن للعميل إعادة الإرسال؛ أما الخادم فلم يُعد الإرسال. لاحظ RFC أن البنية توحي بطلبات idempotent، مع أنها لم تكن كذلك في الواقع. قد تضيع الاستجابة الأولى بعد أن غيّرت المعالجة الأولى حالة اتصال أوسع. لذلك لا يمكن اختزال حزمتين متطابقتين إلى فعل واحد بلا زمن وحالة وسبب إعادة المحاولة وسجل تنفيذ الطرفية.
بقيت بيانات الاعتماد واضحة في UDP وTCP
حمل الترميزان اسم المستخدم وكلمة المرور بنص واضح. حذر قسم الأمن من أن مراقب الشبكة يستطيع جمع أزواج الأسماء وكلمات المرور، ومن أن الخدمة تتيح سطحاً لاختبار بيانات الاعتماد. لا يمنح ACCEPT لاحق السرية للطلب السابق، ولا تجعل الإدارة الفيزيائية للشبكة النص الواضح تشفيراً.
عالج ترميز TCP قضية مختلفة. كان غير متوافق صراحة مع TACACS التاريخي، واختار تأطيراً أبسط وتسليماً يديره TCP ومجالاً أوسع للرد. وصول البايتات مرتبة لا يثبت هوية الطرفين، ولا يخفي كلمة المرور، ولا يثبت تنفيذ السياسة.
TACACS+ اللاحق ليس تفسيراً بأثر رجعي
وصف RFC 8907 لاحقاً TACACS+ كحزمة تفصل المصادقة والتفويض والمحاسبة. وحذر أيضاً من أن جلسة البروتوكول قد لا تقابل مستخدماً أو فعلاً، وأن طلب المصادقة لا يرتبط تلقائياً بطلب تفويض. يساعد هذا التمييز على قراءة الأدلة، لكنه لا يجعل TACACS في 1993 نسخة من TACACS+ الحديث.
أما RFC 927 الأسبق فامتلك قصة تسليم هوية TUID في TELNET. يمتلك RFC 1492 قصة أخرى: كيف يوثق بروتوكول قرار عندما يغيب نص المصدر ويصبح تنفيذ متاح شاهده الأساسي.
لم يكن الإنجاز إزالة الشك، بل ضبطه. حيازة الوثيقة، وسلوك الكود، والنشر، ونقل الطلب، والقرار المحلي، وفعل الجهاز، والنتيجة الخارجية حقائق مترابطة لا بدائل بعضها عن بعض.
المصادر
- سجل RFC 1492
- RFC 1492, An Access Control Protocol, Sometimes Called TACACS
- سجل RFC 927
- RFC 927, TACACS User Identification Telnet Option
- سجل RFC 8907
- RFC 8907, The TACACS+ Protocol
- RFC 4962, Guidance for Authentication, Authorization, and Accounting Key Management
- سجل IANA لأسماء الخدمات وأرقام المنافذ
- Heng Lu, Running-Code Primacy
- Heng Lu, Minimum Initial Specification
- Heng Lu, On Reality Layers
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
