الخلاصة

  • يمكّن TLS-POK في RFC 9966 الخادم من إثبات معرفته بالمفتاح العام BSK للجهاز، والجهاز من إثبات امتلاكه المفتاح الخاص المقابل.
  • لا يحدد المعيار كيف وصلت تلك المادة العامة إلى الخادم، ولا يجعل المصافحة دليلاً على الملكية أو الحيازة أو استحقاق الشبكة أو نتيجة القبول الفعلية.

يظهر في إدخال جهاز جديد إلى شبكة مؤسسية تناقض بسيط: يحتاج الجهاز إلى اعتماد EAP للدخول، لكنه يحتاج إلى الاتصال كي يحصل على الاعتماد. عالج Owen Friel وDan Harkins هذا الموضع الأولي في RFC 9966، لا بوعد بهوية كاملة، بل بآلية TLS Proof of Knowledge أو TLS-POK لشبكات سلكية. تنطلق الآلية من زوج مفاتيح بيضوي يسمى Bootstrap Key، أو BSK.

يبقى الجزء الخاص من BSK عند الجهاز. أما الجزء العام فيكون معروفاً للجهاز ولمالكه أو حائزه، ثم يزوّد به مشغل خادم TLS خادمه. أثناء TLS 1.3 يبرهن الخادم للعميل أنه يعرف المفتاح العام، ويبرهن العميل للخادم أنه يملك المفتاح الخاص المقابل. تُشتق EPSK من المفتاح العام ويجري استعمال BSK كمفتاح عام خام في المصادقة. هذه نتيجة دقيقة عن معرفة مادة مفتاحية؛ وليست سجلاً يثبت تاريخ الجهاز أو حقه القانوني في الارتباط بالشبكة.

تترك RFC 9966 مرحلة الإدخال السابقة خارج نطاقها صراحة. لا تقول كيف اكتسب خادم TLS المفتاح العام BSK، وإن كانت تذكر مسح رمز QR أو رفع قائمة مواد BOM كأمثلة. وإذا كان رمز QR مثبتاً مادياً على جهاز، يفترض النموذج أن حيازة الجهاز تعني ملكية مشروعة. الافتراض مفيد لكي يبدأ الإقلاع، لكنه ليس فحصاً أجراه TLS لعملية شراء أو تسليم أو نقل ملكية أو سلامة ملصق أو سجل مخزون.

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

وتحافظ متطلبات التنفيذ على هذه الحدود. يجب ألا يرسل العميل مفتاح BSK العام قبل معالجة ServerHello والتحقق من جدول مفاتيح TLS؛ وإذا فشل تحقق PSK، ينهي الجلسة من دون إرساله. وينبغي أن يكون لكل جهاز BSK فريد. فالمفتاح المشترك بين أجهزة عديدة يمنع مشغل الشبكة من تمييزها أو من ضمان اتصال أجهزة محددة ومصرح بها فقط. تلك ضوابط ضد الانكشاف والالتباس التقني، لا بديل عن مراجعة الحيازة.

بعد اكتمال المصافحة يستطيع الخادم تزويد الجهاز باعتماد يستخدمه في مصادقات EAP اللاحقة. وتقول RFC إن BSK يُستخدم في الإقلاع فقط. لذلك تبقى واقعة الحصول على المفتاح، وتزويد الخادم به، ونجاح TLS، وإصدار الاعتماد، وقرار EAP، وتنفيذ القرار في نقطة النفاذ وقائع مترابطة لا يجوز دمجها في إيصال واحد.

تربط صفحة IETF العامة Dan Harkins بـRFC 9966، وتوفر صورة تقدير عامة من IEEE 802.11 مرجع الهوية للصورة التحريرية. ولا يثبت أي منهما سيطرته على أجهزة أو شبكات حية. القيمة في النص المشترك هي رفضه منح برهان أولي سلطة لم يحصل عليها.

المصادر