الخلاصة

  • يفرض RFC 8915 وجود حقل Unique Identifier واحد في كل طلب يحميه NTS؛ يولّده العميل بمولّد عشوائي آمن تشفيرياً ولا يقل طوله عن 32 ثمانية، ثم يرد الخادم بالقيمة نفسها.
  • لا يعالج العميل الجواب إلا إذا طابقت القيمة طلباً معلقاً ونجحت مصادقة الحزمة بمفتاح الخادم إلى العميل المرتبط بذلك الطلب.
  • هذه قرينة قوية لكشف إعادة الإرسال وربط الطلب بالجواب، وليست هوية ثابتة أو NTS Cookie أو دليلاً على صحة الوقت المعروض.

إيصال ينتهي بانتهاء السؤال

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

يمنح RFC 8915 العميل إيصالاً يصنعه بنفسه. يتضمن كل طلب محمي حقلاً واحداً بالضبط من نوع Unique Identifier. يتكون جسمه من سلسلة ثمانيات ينتجها مولّد أرقام عشوائية آمن تشفيرياً، ولا يجوز أن يقل الطول عن 32 ثمانية. وبعد أن يتحقق الخادم من الطلب، يضع حقلاً واحداً مقابلاً في الجواب وينسخ السلسلة ذاتها بلا تغيير.

عند الاستقبال يصبح شرطان قراراً واحداً: أن يطابق المعرّف طلباً ما زال معلقاً، وأن تصح مصادقة الحزمة تحت مفتاح S2C الخاص بذلك الطلب. إذا أخفق أي منهما تُرمى الحزمة قبل أي معالجة أخرى. وبذلك لا تستطيع إجابة قديمة، وإن كانت أصلية، أن تحل محل إجابة منتظرة اليوم.

الحقل غير مشفّر، لكنه ليس غير محمي. فالمعيار يوجب مصادقته، وهو ضمن البيانات التي يغطي AEAD سلامتها قبل حقل المصادقة. يستطيع المراقب قراءة القيمة، لكنه لا يستطيع استبدالها ثم إنتاج جواب مقبول من دون المفتاح. السرية تجيب عمن يستطيع القراءة، والسلامة تجيب عمن يستطيع التغيير؛ وهما خاصيتان منفصلتان.

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

لماذا لم تعد ساعة الإرسال كافية

امتلك NTP آلية ربط أقدم. يعرّف RFC 5905 قيمة Origin Timestamp ذات 64 بت بأنها وقت خروج الطلب من العميل وفق ساعته. يعيد الخادم هذه القيمة، ويقارنها العميل بحالة الإرسال كي يكتشف الحزم الزائفة أو المكررة أو المعاد إرسالها.

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

يفصل الحقل الجديد المهمتين. فجسمه لا يقل عن 32 ثمانية ويأتي من مولّد آمن، ما يتيح قدراً أنسب من عدم القابلية للتنبؤ ومقاومة التصادم. مع ذلك يحذر RFC 4086 من مساواة الطول بالإنتروبيا: قد يبدو خرج من 256 بت عشوائياً بينما يأتي من حالة أولية صغيرة يمكن البحث فيها. لذلك تشمل القرينة صحة المولّد وجودة بذرته، لا عدد البتات وحده.

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

TLS وCookie والصدى: حدود لا ينبغي دمجها

تأتي مرحلة NTS-KE أولاً فوق TLS، فتنجز المصادقة الأولية للخادم والتفاوض واستخراج المفاتيح، ثم يُغلق اتصال TLS. لذلك لا يكون Unique Identifier في طلب NTP اللاحق شهادة ولا إعادة تعريف لهوية TLS.

يحمل NTS Cookie إيصالاً آخر. يعيد العميل إلى الخادم Cookie معتماً سبق أن تسلمه، فيستعيد الخادم خوارزمية AEAD والمفتاحين الاتجاهيين من دون الاحتفاظ بحالة لكل عميل. تناول مقال سابق لـSofia Ren عن Dieter Sibold هذا الانتقال بعد إغلاق TLS. الـCookie يعيد بناء ارتباط تشفيري؛ أما المعرّف الفريد فيوصل جواباً واحداً بطلب واحد ما زال مفتوحاً.

ويؤدي حقل المصادقة الدور الثالث. في الطلب يخضع الـCookie والمعرّف للمصادقة من دون تشفير. في الجواب يبقى المعرّف ظاهراً، بينما توضع ملفات Cookie الجديدة داخل الجزء المشفّر والموثّق. الخلط بينها يمحو قرارات مختلفة في السرية والاستمرار.

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

جواب أصلي لا يعني وقتاً صحيحاً

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

لهذا يعالج RFC 8633 تعدد مصادر الوقت واستقلالها ومراقبتها بوصفها مسؤوليات منفصلة. إذا لم يوجد إلا مصدر واحد، انتقل خطؤه مباشرة إلى العميل. يقول المعرّف الفريد: «هذا الجواب المحمي يعود إلى هذا الطلب المعلق». أما صحة الوقت فتحتاج إلى قرائن أخرى.

المصادر