برمجة VPN ، مرحلة الملاحقة - RFC غير واضح بما فيه الكفاية

Question

لدي بناء مخصص لنظام التشغيل UNIX.

مهمتي: إضافة IPSEC إلى نظام التشغيل.

أنا أعمل في المرحلة الأولى ، فعلت إرسال أول 2 حزم.

ما أحاول القيام به الآن هو جعل حمولة تحديد الهوية. كنت أطالع RFC 2409 (Apendix B) التي تناقش مواد المفتاح (Skeyid ، Skeyid_D ، Skeyid_A رابعا صناعة).

الآن ، أنا أستخدم شا -1 من أجل الملاحقة ، وبالتالي أستخدم HMAC-SHA1 وخوارزمية التشفير الخاصة بي هي AES-256. المشكلة الحقيقية هي أن RFC ليس واضحًا بما يجب أن أفعله فيما يتعلق PRF. انها تقول:

"استخدام PRFs التفاوض مايو تتطلب توسيع إخراج PRF بسبب آلية ردود الفعل PRF التي تستخدمها هذا المستند. "

أستخدم SHA-1 ، هل هذا يعني أنني لا أتفاوض على PRF؟

في رأيي ، AES هي الخوارزمية الوحيدة التي تحتاج إلى انتهاء (طول ثابت قدره 256 بت) ، لذلك ، هل أحتاج إلى توسيع SKEYID_E فقط؟

إذا كنت تعرف المصدر أكثر وضوحًا ، على الرغم من راحة ، فإن RFC يرجى نشر رابط.

Answer 1

لا يمكنك التفاوض على PRF يعتمد فقط على RFC2409 ، لذلك لا تقلق بشأن ذلك. 3 تتطلب كل من المفاتيح الثلاثة و AES-192 و AES-256 خوارزمية التوسع الرئيسية في الملحق B. العديد من التطبيقات لديها هذه ، لذلك لا ينبغي أن يكون اختبار التشغيل البيني بهذه الصعوبة.

Answer 2

غالبًا ما تكون IETF RFCs غير واضحة بما فيه الكفاية. ومع ذلك ، فهي مكتوبة لغرض وحيد هو وصف قابلية التشغيل البيني ، لذا فإن العثور على تطبيق مرجعي إما لاستكشاف الكود أو الاختبار ضده أمر ضروري تقريبًا. في الواقع 2409 يلاحظ على وجه التحديد:

يشجع المؤلفون التنفيذ المستقل ، واختبار قابلية التشغيل البيني ، لهذا البروتوكول المختلط.

العثور على تطبيق آخر هو ما تحتاجه حقًا ؛ العثور على مصدر شخص آخر أفضل. إذا فشل ذلك ، اقرأ المراجع. لقد قيل أن بعض RFCs التي كتبها بعض الشركات تعمد أو تخفي ببساطة المعلومات اللازمة لإنتاج تنفيذ مطابق من أجل بناء "ميزة السوق". لا يوجد طريق ملكي لفهم 2049.