对 VPN 进行编程，身份验证阶段 - RFC 不够清晰答案

【问题标题】：Programming a VPN, Authontication stage - RFC not clear enough对 VPN 进行编程，身份验证阶段 - RFC 不够清晰
【发布时间】：2011-01-30 20:39:12
【问题描述】：

我有一个自定义版本的 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 吗？

如果您碰巧知道更清晰但可靠的来源，请在 RFC 中发布链接。

【问题讨论】：

【解决方案1】：

您不能仅根据 RFC2409 协商 PRF，因此不必担心。 3 密钥 Triple-DES、AES-192 和 AES-256 都需要附录 B 中的密钥扩展算法。许多实现都有这些，因此测试互操作性应该不会那么难。

【讨论】：

那么我只需要扩展至 SKEYID_e 并且仅在使用密钥长度 > 160 位时），就是这样，对吧？
用于加密 IKE 消息，是的。但是，当 IPsec 转换要求大于 160 位时，您还需要扩展 SKEYID_d，例如 RFC 3602。在该 RFC 中，第 3.2 节说“从密钥交换协议发送到 ESP 算法的最小位数必须是大于或等于密钥大小。”您的 IKE 代码是提到的密钥交换协议，因此当 AES-192 和 AES-256 用于 ESP 时，您必须扩展 SKEYID_d。

【解决方案2】：

IETF RFC 通常不够清晰。然而，它们只是为了描述互操作性而编写的，因此找到一个参考实现来探索其代码或进行测试几乎是必不可少的。 Indeed 2409 特别指出：

作者鼓励这种混合协议的独立实施和互操作性测试。

找到另一个实现是您真正需要的；找到别人的来源更好。如果做不到这一点，请阅读参考书目。有人说，一些公司编写的一些 RFC 故意混淆或简单地隐藏产生一致实现所需的信息，以建立“市场优势”。了解2049没有王道。

【讨论】：

感谢您的提示。我试图在 Linux 2.6 内核的源代码中寻找答案，但找不到任何有用的东西。然后我转向其他一些开源 IPSec 项目，我通过它的代码大约 4 小时苦苦寻找解决方案，却发现一条评论说它没有实现，如果我碰巧实现它，我可能会捐赠代码>.> 任何人都可以尝试帮助我解决这个问题吗？我的学位取决于它，我没有太多时间，提前谢谢！
在 RFC 中使用“may”是一个技术术语。如果您在该领域找到了一个未实现该功能的示例，那么您现在有证据证明您可以与至少一个实现进行一致的互操作。这实际上是使用 RFC 可以做到的最好的事情。由于该功能是“可能”，因此其他符合要求的实现不能要求您确实实现该功能。除非你有一个实现它的盒子，否则你根本无法知道你是否做对了。
尽管 Cisco 的员工编写了 RFC，但这并不能保证他们已经实现了“可能”功能。这可能是他们从未发现需要的预期添加。也就是说，您（到目前为止）没有证据表明任何地方都存在任何实现。因此，您可以声称自己符合 2049，直到以其他方式证明存在，在这种情况下，由于“可能”，您仍然符合要求。