VPN 编程、身份验证阶段 - RFC 不够清晰
我有一个定制的 Unix 操作系统。
我的任务：向操作系统添加 IPSec。
我正在第一阶段工作，已发送前 2 个数据包。
我现在想做的是制作识别有效负载。 我一直在阅读 RFC 2409（附录 B），其中讨论了密钥材料（SKEYID 、SKEYID_d、SKEYID_a、SKEYID_e 和 IV 制作）。
现在，我使用 SHA-1 进行身份验证，因此我使用 HMAC -SHA1，我的加密算法是AES-256。 真正的问题是 RFC 不够清楚我应该对 PRF 做什么。 它说：
“使用协商的 PRF可能需要 PRF 输出因以下原因而扩大 采用的 PRF 反馈机制 本文档。”
我使用SHA-1，是否意味着我不协商PRF？
，AES是唯一需要扩展的算法（固定长度256位），那么，我是否只需要扩展SKEYID_e？
如果您碰巧知道更清晰但可靠的来源，请发布一个链接。
I have a custom build of a Unix OS.
My task: Adding an IPSec to the OS.
I am working on Phase I, done sending the first 2 packets.
What I am trying to do now is making the Identification Payload.
I've been reading RFC 2409 (Apendix B) which discuss the keying materials (SKEYID, SKEYID_d, SKEYID_a, SKEYID_e and the IV making).
Now, I use SHA-1 for authontication and thus I use HMAC-SHA1 and my encryption algorithm is AES-256.
The real problem is that the RFC is not clear enough of what should I do regarding the PRF.
It says:
"Use of negotiated PRFs may require the
PRF output to be expanded due to
the PRF feedback mechanism employed by
this document."
I use SHA-1, does it mean I do not negotiate a PRF?
In my opinion, AES is the only algorithm that needs expention (a fixed length of 256 bit), so, do I need to expand only the SKEYID_e?
If you happen to know a clearer, though relible, source then the RFC please post a link.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您无法仅根据 RFC2409 协商 PRF，因此不必担心。 3 密钥 Triple-DES、AES-192 和 AES-256 都需要附录 B 中的密钥扩展算法。许多实现都具有这些算法，因此测试互操作性应该不会那么困难。
You cannot negotiate a PRF based solely on RFC2409, so don't worry about that. 3 key Triple-DES, AES-192, and AES-256 all require the key expansion algorithm in Appendix B. Many implementations have these, so testing interoperability should not be that hard.
IETF RFC 通常不够明确。然而，编写它们的唯一目的是描述互操作性，因此找到一个参考实现来探索其代码或进行测试几乎是必要的。事实上2409特别指出：
寻找另一种实现才是您真正需要的；找到别人的来源更好。如果做不到这一点，请阅读参考书目。据说，一些公司编写的一些 RFC 故意混淆或简单地隐藏产生一致实施所需的信息，以建立“市场优势”。理解 2049 年没有坦途。
The IETF RFCs are often not clear enough. However, they are written for the sole purpose of describing interoperability so finding a reference implementation to either explore its code or test against is almost essential. Indeed 2409 specifically notes:
Finding another implementation is what you really need; finding someone else's source is better still. Failing that, read the bibliography. It has been said that some RFCs written by some firms intentionally obfuscate or simply hide the information needed to produce a conformant implementation in order to build 'market advantage'. There is no royal road to understanding 2049.