الخلاصة

  • توحّد RFC 9644 تمثيل قدرات خوارزميات SSH والسياسات المرتبة في YANG، لكنها لا تنشئ سجلاً لنتيجة التفاوض في كل جلسة.
  • الادعاء القابل للدفاع يربط نسخة السجل والوحدة، وقدرة التنفيذ، والإعداد المعتمد، وعرضي SSH_MSG_KEXINIT، والاختيارات حسب الاتجاه، ومفتاح المضيف، وNEWKEYS، والمصادقة، ونتيجة التطبيق.
  • الإيصال المقترح هنا ضابط تشغيلي وليس صيغة تفرضها RFC؛ غياب الملاحظة يجب أن يضيّق الاستنتاج بدلاً من ملء الفراغ بالافتراض.

حين تتجاوز العبارة حدود الدليل

تستطيع جهة الأمن أن تثبت أنها اعتمدت قائمة مرتبة. ويستطيع المورد أن يعلن أن نسخته تدعم خوارزمية ما. ويستطيع نظام الإدارة أن يسجل نجاح الكتابة. لكن جمع هذه الوقائع لا يخلق تلقائياً واقعة رابعة هي أن جلسة بعينها اختارت الخوارزمية نفسها.

تعرّف RFC 9644 التجميعات القابلة لإعادة الاستخدام ietf-ssh-common وietf-ssh-client وietf-ssh-server. كما تصف توليد أربع وحدات تعداد لخوارزميات SSH من سجلات IANA. الفائدة هي توحيد المفردات بين وحدة التحكم والتنفيذ. وليست الغاية إنشاء مسجل جلسات أو حكم على هوية الطرف أو صحة خدمة التطبيق.

لذلك يجب فصل أربع طبقات: الاسم مسجل، والتنفيذ يعلن دعمه، والسياسة تسمح به وتضع ترتيبه، والجلسة تختاره فعلياً. الطبقات الثلاث الأولى تخص المفردات والقدرة والقصد؛ الرابعة وحدها تصف حدثاً. وحتى الحدث لا يثبت وحده هوية الخادم أو مصادقة العميل أو نجاح العملية.

التسجيل لا يمنح توصية أمنية

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

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

كما يلزم حفظ revision الوحدة أو بصمتها. من دون ذلك قد يقرأ التدقيق اللاحق إعداداً قديماً بقاموس اليوم. وتلحق بذلك features وdeviations التي تغيّر بنية المخطط الظاهرة.

القدرة مساحة احتمال وليست إذناً

عند تفعيل feature الاختيارية algorithm-discovery تعرض supported-algorithms بيانات تشغيلية من نوع config false. وهي مفيدة لتخطيط الانتقال، لأنها تبين ما يزعم التنفيذ قدرته عليه من تبادل مفاتيح ومفتاح مضيف وتشفير وMAC.

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

أما القائمة الغائبة أو الخالية فلا تعني قيمة افتراضية آمنة مشتركة بين المنتجات. تترك RFC 9644 المجموعة المقبولة للتنفيذ في هذه الحالة. إذا لم يُتحقق من السلوك الفعلي، تكون النتيجة الصحيحة «غير محدد».

لا يتحول الترتيب إلى اختيار إلا مع الطرف الآخر

يحمل transport-params-grouping قوائم مرتبة لتبادل المفاتيح ومفتاح المضيف والتشفير وMAC، ويعبّر ترتيبها عن تناقص الأفضلية. يجب أن يحتفظ الإيصال بالقيم في ترتيبها الأصلي مع revision الإعداد وهوية المعتمد والجهاز الذي قبله.

تضع RFC 4253 الاختيار الفعلي داخل التبادل. يرسل الطرفان قوائم أسماء في SSH_MSG_KEXINIT. يُختار تبادل المفاتيح ومفتاح المضيف وفق أول خيار يفضله العميل ويعرضه الخادم أيضاً مع استيفاء متطلبات الطريقة. أما التشفير وMAC فيُختاران بصورة مستقلة من العميل إلى الخادم ومن الخادم إلى العميل.

ومن ثم فإن حقلًا واحداً بعنوان «التشفير معتمد» يمحو نصف النتيجة. يلزم حفظ العرضين والاختيارين الاتجاهيين. وإذا لم يوجد تقاطع مقبول تنتهي الوصلة؛ نجاح تطبيق الإعداد لم يكن وعداً بالتوافق مع كل طرف.

الخوارزمية والمفتاح والهوية ليست شيئاً واحداً

تصف خوارزمية مفتاح المضيف المختارة إجراءً تشفيرياً، لا المفتاح الذي قُدم فعلاً ولا سبب الثقة به. تقدم RFC 8332 مثالاً واضحاً: يمكن استخدام تنسيق مفتاح RSA العام نفسه مع rsa-sha2-256 أو rsa-sha2-512. وجود مفتاح RSA لا يعيد بناء خوارزمية التوقيع المستخدمة.

تفصل RFC 9644 هوية العميل عن معلمات مصادقة الخادم، ويمكنها الإشارة إلى keystore وtruststore. ويقود هذا الفصل إلى أسئلة مستقلة: ما الإجراء الذي تم التفاوض عليه؟ ما بصمة المفتاح المقدم؟ بأي قاعدة جرى التحقق؟ كيف صودق العميل؟ وما العملية التي أذن بها التطبيق؟

قد لا يرى موضع مراقبة واحد السلسلة كلها. يستطيع حساس الشبكة مشاهدة التفاوض ولا يرى قرار الثقة داخل العميل. عندئذ يثبت الاختيار، ويترك التحقق من الهوية غير محسوم.

NEWKEYS حد وسيط لا خاتمة

تفعّل رسالة SSH_MSG_NEWKEYS المفاتيح والخوارزميات المحسوبة حديثاً. وجود عرضين متوافقين لا يثبت الوصول إلى هذا الحد. والوصول إليه لا يثبت مصادقة المستخدم التي تصفها RFC 4252، ولا نجاح أمر التطبيق.

يمكن أن يربط إيصال تشغيلي قابل للمراجعة العناصر الآتية:

  • لقطة سجل IANA وrevision أو بصمة وحدات YANG المولدة؛
  • التنفيذ والنسخة البرمجية وfeatures وdeviations؛
  • ملاحظة مؤرخة للقدرات؛
  • القوائم المرتبة حرفياً وrevision الإعداد وهوية المعتمد؛
  • نسخة محمية أو بصمة لكل من عرضي KEXINIT؛
  • اختيارات تبادل المفاتيح ومفتاح المضيف والتشفير وMAC مع حفظ الاتجاه؛
  • بصمة مفتاح المضيف وأساس التحقق ونتيجته؛
  • دليل إتمام NEWKEYS؛
  • طريقة المصادقة ونتيجتها دون كشف الأسرار؛
  • عملية التطبيق وشرط القبول والنتيجة؛
  • الملاحظات المفقودة والجهة المخولة بصياغة الخلاصة.

لا تفرض المراجع المذكورة هذا التنسيق الموحد. إنه تصميم تشغيلي يصل حدود المسؤولية بين الإعداد والبروتوكول والخدمة.

أقل عبارة يمكن إثباتها

يدعو مبدأ Heng Lu للمواصفة الأولية الدنيا إلى تحديد العبارة المطلوبة قبل بناء منظومة جمع واسعة. قول «SSH آمن» أوسع من أن يُقبل كاختبار. أما العبارة القابلة للفحص فهي: في نافذة زمنية محددة، ارتبطت اختيارات عملية معلومة بسياسة معتمدة وطرف تم التحقق منه ونتيجة تطبيق متوقعة.

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

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

المصادر

  1. المواصفة الأولية الدنيا
  2. طبقات الواقع والسلطة الرمزية
  3. أولوية الكود العامل
  4. سجل RFC 9644 في Datatracker
  5. صفحة معلومات RFC 9644
  6. RFC 9644 بصيغة HTML
  7. RFC 9644 بصيغة نصية
  8. RFC 9644 بصيغة XML
  9. تصحيحات RFC 9644 المضمنة
  10. معلمات SSH لدى IANA
  11. معلمات YANG لدى IANA
  12. RFC 4250: الأرقام المسندة لـSSH
  13. RFC 4252: بروتوكول مصادقة SSH
  14. RFC 4253: طبقة نقل SSH
  15. RFC 6187: شهادات X.509v3 في SSH
  16. RFC 8332: مفاتيح RSA وتوقيعات SHA-2
  17. RFC 9142: تحديث طرق تبادل مفاتيح SSH
  18. RFC 7950: الإصدار 1.1 من YANG
  19. RFC 8341: التحكم في الوصول إلى الإعداد
  20. RFC 8342: بنية مخازن بيانات الإدارة