الخلاصة

  • أضافت نسخة 1 أكتوبر 2026 من draft-ietf-tcpm-tcp-ao-algs توضيحاً بأن KMAC256-KDF المقترحة تتبع صيغة KMAC# في NIST SP 800-56C Rev. 2، لا مجرد واجهة KMAC256 الأصلية في SP 800-185؛ فمجموعتا الوسائط مختلفتان. وفسرت أيضاً أن العداد ذا 32 بت، وقيمته واحد بترتيب بايتات الشبكة، يدل على نسخة دالة الاشتقاق.
  • كانت المعادلة ومتجهات الاختبار وخيارتا رمز التوثيق ذي 128 بت موجودة في النسخة 07. الجديد تثبيت تفسير وصفة قائمة في مسودة نشطة، وليس إعلان تغيير مفاتيح منشورة أو اعتماد معيار نهائي.

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

تقول الفقرة 3.1.2 في النسخة 08 إن اشتقاق KMAC256-KDF يستند إلى دالة الخطوة الواحدة في القسم 4.1 من NIST SP 800-56C Rev. 2، الخيار الثالث. أضاف المؤلفون أن المقصود هو صيغة KMAC#، ذات وسائط تختلف عن KMAC256 كما عُرِّفت أصلاً في SP 800-185. كما أوضحوا دور العداد: العدد واحد ممثلاً في 32 بت بترتيب الشبكة، ويشير إلى نسخة دالة الاشتقاق. عند مقارنة النسختين 07 و08، لا يظهر أن معادلة الاشتقاق أو بايتات متجهات الاختبار استُبدلت؛ التغيير يزيل غموض مرجعها.

تتضمن الوصفة ملحاً صفرياً بطول 132 بايت، والعداد، والمفتاح الرئيسي بصفة Z، وسياق اتصال TCP بصفة FixedInfo، وطول خرج 256 بت، وسلسلة التخصيص ASCII KDF. تنتج دعوة واحدة مفتاح مرور بطول 256 بت. ثم تستخدمه صيغة KMAC256-128 المقترحة لإنتاج رمز توثيق بطول 128 بت. وتقترح المسودة أيضاً HMAC-SHA256-128 مع مسار HKDF-SHA256. لم تُستحدث هاتان الصيغتان أو متجهاتهما في أكتوبر؛ كذلك فإن الرمز ذي 16 بايت كان يستهلك، بعد إدخاله في TCP-AO، 20 من أصل 40 بايت متاحة لخيارات TCP قبل هذه المراجعة.

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

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

يعرض Datatracker الوثيقة كمسودة إنترنت نشطة لفريق TCPM في حالة I-D Exists. يذكر رأس النص نية Standards Track، بينما يعرض حقل الحالة المقصودة في السجل (None)؛ لم تصبح الوثيقة RFC معتمداً. الخبر المحدد هو أن اسم KMAC صار مرتبطاً بصيغة اشتقاق مضبوطة أكثر. أما قرار استخدامها في التشغيل فيحتاج دليلاً مستقلاً على أن الطرفين ينتجان البايتات نفسها.

المصادر