RFC 3118: ظلت مصادقة DHCP محلية النطاق

الخلاصة

اعتمدت المصادقة المؤجلة في RFC 3118 على سر مشترك يوزع خارج القناة بين عميل DHCP وخادمه داخل نطاق إداري واحد.
ظل بوسع العميل قبول عرض غير موثّق إذا سمحت السياسة المحلية؛ وأوصت الوثيقة بإمكان الرفض وأن يكون الرفض هو الإعداد الافتراضي.

لم ينشئ الخيار هوية عامة

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

وضعت الخيار 90 على السلك حقول البروتوكول والخوارزمية وطريقة كشف إعادة الإرسال وقيمة الكشف ومعلومات المصادقة. بدا الخيار وحدة واحدة، لكنه جمع أسئلة مختلفة: ما الآلية المستخدمة؟ كيف نميز الرسالة القديمة؟ وأي سر يربط الحزمة بالطرف المقابل؟

فرّقت RFC 3118 بين رمز إعداد بسيط والمصادقة المؤجلة. قدم الرمز مصادقة ضعيفة للكيان من دون مصادقة الرسالة؛ ووصفته الوثيقة بأنه حماية أولية من خادم DHCP يُشغّل سهوا. أما الآلية المؤجلة فاستخدمت HMAC-MD5 وسرا مشتركا. وهذا وصف لاختيار تاريخي، لا توصية للأنظمة الجديدة.

بدأت المصادقة قبل الاكتشاف

في المصادقة المؤجلة، يطلب العميل الآلية في DHCPDISCOVER. يختار الخادم سرا ويرد بمعلومات المصادقة في DHCPOFFER. ينتقي العميل عرضا ويرسل DHCPREQUEST باستخدام السر المرتبط به؛ ثم يتحقق من الإقرار الموثّق. كما شملت العملية كشف إعادة الإرسال حتى لا تكفي إعادة نسخ وسم صالح من حزمة أقدم.

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

كان هذا الحد مقصودا. لم تعالج RFC 3118 التجوال بين نطاقات إدارية مختلفة، بل ركزت على الاستخدام داخل نطاق يمكن فيه تبادل السر خارج القناة، ونبهت إلى أن الأسلوب قد لا يتوسع جيدا مع اتصال العميل بنطاقات متعددة. يثبت MAC أن الرسالة تطابق مفتاحا مضبوطا؛ ولا ينشئ هوية عالمية أو اتفاق تجوال أو حقا في استخدام أي شبكة.

كانت المرحلات والقبول المحلي جزءا من نموذج الثقة

قد تعدل مرحلات DHCP الحقلين giaddr وhops وتضيف معلومات المرحل. وحددت RFC 3118 كيفية التعامل مع هذه الحقول في حساب المصادقة كيلا تبطل المعالجة المشروعة للمرحل الفحص. وقد ضبط ذلك المرور عبر الوسطاء، لكنه لم يجعل كل مرحل مرجعا للهوية.

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

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

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

بقيت مصادقة DHCP داخل نطاق الثقة: RFC 3118

لماذا هذا مهم

الخلاصة

لم ينشئ الخيار هوية عامة

بدأت المصادقة قبل الاكتشاف

كانت المرحلات والقبول المحلي جزءا من نموذج الثقة

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات