摘要

  • RFC 1004 提议由名为 Cookie Jar 的认证服务器核对哪些协议对端可以建立关联，并为获准的一对生成一次性会话密钥。这是 1987 年 4 月的讨论方案。
  • 重放建联流程的第三条消息，可能让接收方误以为新关联开始；发起方会拒绝随后的错误序号答复。快速重复这一动作，可能造成一串超时与服务中断。

两台网关准备交换路由信息。包头上写的源地址，像信封上的署名：有用，但谁拿笔写的，还得另说。EGP 已要求邻居先建立关联。Mills 盯住了这一刻：谁有权宣布“这两位可以互相信任”？他给答案起了一个很不庄严的名字，Cookie Jar。罐子里没有点心，装的是准入名单和发给对端的临时秘密。

RFC 1004 把方案放在 EGP、当时提议中的 DGP，以及类似的分布式协议场景里。网络可能丢包、重复投递，也可能有人截获、篡改后重新发送。每个用户拥有公开地址和自己的长期私钥。公开目录列出允许交谈的对象，Cookie Jar 持有私钥表并检查目录。如果 j 在 i 的许可名单中，罐子就掷出一个随机的一次性密钥 K(i,j)，分别包成给双方的“饼干”。i 带着 j 那份继续建联，双方的长期私钥仍留在各自和罐子手里。

权力结构一点也不神秘：罐子管客人名单，也管钥匙。两台网关物理上连通，仍须过它这一关。关联建立后，临时密钥保护消息的校验和与序号，使对端能够识别冒名和旧消息。普通数据本身继续走原路。Mills 还当场点名工具的弱点：16 位 Internet 校验和对词序、字节交换有不变性；DES 虽是当时自然想到的加密算法，也值得重新考虑。饼干罐上画得再漂亮，薄锁还是薄锁。

真正滑稽的漏洞出现在“重新开始”。新的 Request 会清除旧关联状态。Mills 分析了建联第三条消息被重放的情况：j 可能把旧消息当成新关联的开头，按旧或当前密钥回话；i 看见错误序号便丢弃。单次重放很难建立一段可用的非法关联，连续快速重放却可能逼着 j 反复重置、等到超时。闯入者不必进门，只要不停按门铃，就能让屋里的人没空工作。

为什么不再加一道问答？Mills 研究过三次握手式的额外挑战，认为成本和开销不划算；决心拖延的人仍可用挑战消耗资源。文中还提到无需坏人参与的一场竞速：双方同时找罐子认证，交叉的 Request 可能互相重置密钥，直到错开的超时把僵局打破。换钥匙的周期、请求相撞时的处理、谁能重置状态，这些都是认证协议的日常生活，而非脚注。

这份 RFC 的身份是一项公开讨论提案。它把准入权与故障面摆在同一张桌上：认证服务器可以批准一对网关、交付一次性秘密；同一条建联通道也可能被旧消息拖成循环。互联网早期的网关安全讨论里，这只罐子最值得看的地方，是有人把昨天的饼干又端上来了。