الملخص

  • سمحت RFC 2385 بتغيير مفتاح متزامن بين الطرفين، لكنها لم توفر تفاوضاً داخل البروتوكول أو معرفات تنسق العملية.
  • يحدد KeyID في TCP-AO الـMKT الذي استُخدم لمصادقة الحزمة المرسلة، بينما يعلن RNextKeyID الـMKT الذي أصبح المرسل جاهزاً لاستخدامه للحزم القادمة التي سيستقبلها.

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

عرّفت RFC 2385 عام 1998 خيار TCP MD5 Signature لحماية جلسات BGP خصوصاً. حملت كل حزمة محمية خلاصة MD5 من 16 بايت محسوبة بسر يضبط بصورة مستقلة في الطرفين. أجازت الوثيقة تغيير المفتاح أثناء الاتصال إذا تزامن الطرفان، لكنها لم تعرف تفاوضاً ولا رقماً للمفتاح الحالي ولا إشارة إلى المفتاح التالي.

استبدلت RFC 5925 ذلك بـTCP-AO وبنية حالة صريحة. يجمع Master Key Tuple، أو MKT، محددات الاتصال والمعرفات والمادة السرية والخوارزميات والمعلمات. ثم تشتق منه مفاتيح حركة أحادية الاتجاه لاتصال بعينه. وبعد تفعيل أي MKT لا تتغير مكوناته داخل الاتصال، لكن مجموعة MKT المتاحة يمكن أن تتغير، ويمكن للاتصال الانتقال إلى MKT آخر.

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

لا يعود التبديل محتاجاً إلى لحظة مشتركة مثالية. يثبت أحد الطرفين MKT التالي للاستقبال، ويعلن عبر RNextKeyID أنه أصبح جاهزاً لاستخدامه. يرى الطرف الآخر هذه الإشارة، ثم يقرر وفق قواعد RFC متى يغير KeyID لإرساله هو؛ ولا تفرض الإشارة تبديلًا فورياً في حزمة TCP التالية. يسمح التداخل المنضبط بالتحقق من الحزم القديمة التي غادرت قبل الانتقال. يصبح التقدم حقيقة على السلك بدلاً من استنتاج يعتمد على الساعة وأخطاء MAC فقط.

لا يتولى TCP-AO إدارة أصل المفاتيح. فهو لا يتفاوض على الأسرار الرئيسية ولا يقرر من يملك حق توفيرها. تصل MKT عبر إعداد ثابت أو نظام خارجي خارج الحزمة. ينسق البروتوكول استعمال مادة سبق اعتمادها، ولا ينشئ الاعتماد نفسه.

ولا يمكن تحويل اتصال TCP MD5 قائم إلى TCP-AO في مكانه. يستخدم كل منهما خياراً مختلفاً وتمنع RFC 5925 جمعهما في اتصال واحد. لم يكن TCP MD5 يملك مساراً لتغيير خوارزمية الحماية بعد الإنشاء. لذلك تتطلب الهجرة اتصالاً جديداً، مع إمكان تدوير مفاتيح TCP-AO لاحقاً من دون فقدان حالة النقل.

تحدد RFC 5926 توليفات الخوارزميات الإلزامية لضمان التشغيل المتبادل، لكنها لا تختار مفتاح التشغيل ولا تفرض فترة تدوير موحدة. يتحقق TCP-AO من أصالة الحزم وسلامتها ويقاوم إعادة إرسالها، لكنه لا يشفر بيانات التطبيق.

المصادر الأولية