الخلاصة

  • فصل RFC 5113 بين اكتشاف نقطة الاتصال واختيار الهوية ومسار AAA ومسار البيانات وقدرات الخدمة.
  • يحدث اختيار الشبكة والهوية عادة قبل المصادقة، لذلك لا تستطيع المفاتيح المشتقة من المصادقة حماية الاكتشاف الذي سبقها.
  • realm hints أدوات محدودة للتعافي من فشل التوجيه وليست جدولاً كاملاً. الإعلان مؤشر يمكن رفضه، لا أمراً يخفض سياسة الأمان.

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

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

خمس طبقات داخل كلمة «شبكة»

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

اختيار NAI وبيانات الاعتماد يحدد الهوية المقدمة. ويستخدم realm أيضاً للمساعدة في توجيه طلب AAA إلى الخادم المنزلي.

توجيه AAA يمر عبر proxies وعلاقات تجوال. يمكن لأكثر من مسار قبول الهوية نفسها مع اختلاف الخدمة والسياسة التجارية.

مسار payload قد يستخدم نفقاً مختلفاً عن محادثة المصادقة. نجاح AAA لا يرسم مسار الحزم.

النتيجة التي يريدها المستخدم تقع في طبقة أخرى: الخدمة، الجودة، الأمان، الوصول والسعر.

جمع هذه الطبقات في إشارة «متصل» يجعل نجاحاً واحداً يتحدث باسم حقائق لم يرها.

اختيار بيانات الاعتماد كان اختيار مسار

خلص RFC 5113 إلى أن credential selection وAAA routing جانبان من مشكلة identity selection نفسها. المستخدم الذي يملك هويتين يستطيع تغيير الشبكات القابلة للاستخدام باختيار realm مختلف. وقد يصل realm واحد عبر علاقة مباشرة أو اتحاد تجوال.

يمكن للمسارين أن يصادقا الهوية ذاتها. ومع ذلك قد تختلف فاتورة الاستخدام والخدمات المتاحة والنفق اللاحق. لذلك لا يكفي سؤال «هل قُبلت الهوية؟». يجب تسجيل أي هوية، وأي realm، وأي proxy، وأي علاقة.

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

Realm hint بعد الفشل

يسمح RFC 4284 بإعادة realm hints عندما يصل الطلب إلى منطقة لا تملك route للrealm المختار. لكن القائمة قد تكون ناقصة بسبب حجم الرسالة أو سرية علاقات التوجيه. وهي ليست بروتوكول routing ديناميكي.

وظيفتها الأقوى هي التعافي: تفشل الهوية الأولى في الوصول، ويعرض core AAA proxy بدائل محدودة، فيجرب الطرف هوية أخرى ضمن ميزانية واضحة.

إذا أنشأ NAS القائمة من جدول يدوي، فقد يعلن realm لم يعد قابلاً للوصول أو يهمل علاقة جديدة. عندما ينشئ core proxy نفسه الـhint ثم يوجه المحاولة التالية، تتشارك المعلومة والتنفيذ المصير. لا تصبح القائمة كاملة، لكنها تصبح قابلة للمساءلة عند نقطة واحدة.

الإفصاح التدريجي

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

هذا يزيد التأخير في بعض الحالات، لكنه يمنع إعلان كل الانتماءات الممكنة لأي نقطة غير موثوقة. القرار المهني ليس بين «خصوصية» و«اتصال» كمطلقين، بل بين مقدار إفصاح معروف وفائدة قابلة للقياس.

لا يجوز أن يتحول الفشل إلى حلقة تكشف هوية بعد أخرى. ميزانية retry هي جزء من حماية الخصوصية ومن حماية AAA من الحمل.

الثقة تصل بعد الاختيار

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

بعد نجاح المصادقة يمكن لـchannel binding أو secure association تأكيد بعض الادعاءات. لا يثبت ذلك السعر أو الخدمة أو route إن لم تدخل هذه العناصر في الربط. بعض المعلمات قد تبقى غير قابلة للتأكيد.

هنا يظهر خطر bidding down. قد يعلن مهاجم قدرة أضعف لا تُقارن لاحقاً. لذلك يحتاج العميل سياسة أمان دنيا قبل الاكتشاف، ويعامل الإعلان كـhint يمكن تجاهله إذا خالفها.

النجاح لا يثبت الخدمة

ربما يصل طلب AAA إلى home server وينجح، ثم يسلك payload نفقاً آخر لا يقدم الخدمة المطلوبة. وربما تختلف التكلفة باختلاف وسيط التجوال.

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

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

حدود الحجم والحمل

لا ينبغي لـNAS إرسال probes دورية بهويات مصطنعة لاستخراج realm hints وبناء جدول. هذه الرسائل تزيد الحمل، ومع إسقاط الحزم تزداد retransmissions. والقائمة الناتجة تبقى ناقصة.

توزيع جدول كامل قد يكشف علاقات تجارية، ونسخه يدوياً يخلق حالة قديمة. وقد يطلب source route علاقة لا يملكها proxy فعلياً.

التعافي الصحيح محدود: سبب الفشل، مصدر hint، عمره، الهوية البديلة، النتيجة وحد المحاولات.

سلّم الأدلة

  • ظهور نقطة لا يثبت شبكة الخدمة؛
  • إعلان realm لا يثبت route حالياً؛
  • hint لا يثبت قائمة كاملة؛
  • وصول AAA لا يثبت قبول الهوية؛
  • قبول الهوية لا يثبت payload؛
  • عمل payload لا يثبت السعر؛
  • قيام الجلسة لا يثبت أفضل اختيار.

قدّم RFC 5113 طريقة لحفظ هذه الفواصل عندما تضغط واجهة الاتصال لتحويلها إلى حالة واحدة.

المصادر