الخلاصة

  • نظم RFC 1472 بروتوكولات مصادقة PPP وأزواج ID/Secret بحسب الوصلة والأولوية والاتجاه والبروتوكول والحالة.
  • كانت valid تعني أن سجل الإعداد قابل للاختيار؛ أما إثبات المصادقة فاحتاج إلى تبادل PAP أو CHAP وقرار مستقل من المصادِق.

صدر RFC 1472 في يونيو 1993 ليجعل إعداد أمن PPP قابلاً للإدارة عبر MIB. ولم يساوِ بين ما خزنه وكيل الإدارة وبين ما جرى لاحقاً بين طرفي الوصلة.

كان RFC 1471 وثيقته الشقيقة لإدارة LCP. أما مجموعة الأمن في RFC 1472 فكانت اختيارية لأنها جمعت هويات وأسراراً ومتغيرات تستطيع تغيير البروتوكول الذي سيجرب وترتيبه.

الأولوية رتبت المحاولات

ربط pppSecurityConfigTable كل بروتوكول بوصلة ودرجة أولوية. القيم الأصغر تجرب أولاً. وكانت قيمة الوصلة صفر قاعدة افتراضية للوصلات التي لا تملك سجلاً خاصاً.

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

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

الوجود معلومة، والسريان معلومة أخرى.

زوج ID/Secret لم يكن شخصاً مثبتاً

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

حدد الاتجاه دور الزوج. local-to-remote يعني أن الكيان المحلي يستخدمه كي يصادق عليه الطرف البعيد. وremote-to-local يعني أن المحلي يتوقعه من البعيد. قد تبقى البايتات نفسها بينما يتغير صاحب الفعل المتوقع.

وحدد البروتوكول معنى الحقول. في PAP قد تكون الهوية Peer-ID والسر كلمة مرور. وفي CHAP-MD5 قد تكون الهوية CHAP Name والسر مادة حساب الاستجابة. عرّف RFC 1472 الحقلين كسلسلتي ثمانيات لأن معناهما لا يكتمل خارج سياق البروتوكول.

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

الحدث وقع خارج الجدول

وصف RFC 1334 PAP: بعد إنشاء الوصلة يرسل الطرف Peer-ID وكلمة المرور، ثم يتلقى Authenticate-Ack أو Nak. ووصف RFC 1994 لاحقاً CHAP كتحد واستجابة محسوبة ومقارنة محلية ونجاح أو فشل.

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

وحافظ RFC 1661 على حدود المراحل: تنشأ وصلة البيانات أولاً، ثم يمكن مصادقة الطرف، وبعدها تضبط NCP بروتوكولات طبقة الشبكة. لذا لا تثبت المصادقة أن IPCP فتح، ولا يثبت IPCP مساراً أو تسليماً أو قبول تطبيق.

مسار الإدارة نفسه كان حساساً

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

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

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

خطان زمنيان بدلاً من ضوء واحد

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

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

تكمن قيمة RFC 1472 في أنه جعل الاستعداد مرئياً من غير أن يسميه حدثاً منجزاً.

المصادر