摘要

  • RFC 1994 让对端用 Identifier、共享秘密和每次变化的 Challenge Value 计算 Response，秘密本身不经过链路。
  • Success 只说明认证方针对这次挑战算出了相同结果；反向认证、授权、NCP 和流量需要各自的证据。

RFC 1994 的三步很短：认证方发送 Challenge，对端返回 Response，认证方以本地预期值比较后发送 Success 或 Failure。Response 复制 Challenge 的 Identifier，Success/Failure 再复制 Response 的 Identifier。响应值则依次对 Identifier、secret 与 Challenge Value 连接后的字节流做单向散列。

每次新挑战都必须更换 Identifier 和 Challenge Value。挑战与同一秘密重复，会让截获的旧响应重新有用；挑战可预测，则攻击者可能提前诱使对端计算未来答案。因此规范要求唯一性和不可预测性，同时明确 CHAP 不能防住实时主动窃听。

认证方掌握时钟。它可以在链路建立后再次挑战，甚至在 Network-Layer Protocol phase 中提问。每次提问产生新的、带时点的比较，并不会让第一次 Success 自动延续。若 Success 丢失，对端可以重发 Response；认证方必须针对当前 Challenge Identifier 返回与先前相同的 reply Code，补交回执不能改写决定。

方向也不能省略。RFC 1994 明说 CHAP 只是单向认证。双向认证必须在反方向另行协商；PPP 甚至允许两个方向采用不同协议，规范还建议两个方向不要共用同一秘密。Name 用于在秘密表中定位系统条目，不等于自然人身份或账户授权。

RFC 1661 把后续结果留给 NCP：每种网络层协议必须单独配置，达到 Opened 后才能承载报文。因此 CHAP Success 不证明保密、地址、路由、包到达或应用投递。

来源：RFC 1994、RFC Editor 记录、RFC 1661、RFC 1334、IANA PPP 编号。