摘要

  • RFC 1472 用链路、优先级、方向、协议和状态来组织 PPP 认证协议与 ID/Secret 对。
  • valid 只说明配置行可被选用；真正的认证仍需要 PAP 或 CHAP 交互、认证方的判断，以及此后独立的网络层开启过程。

RFC 1472 的价值不只是把秘密放进 MIB。更重要的是，它没有让这张表冒充线路上发生过的事实。

这份 1993 年 6 月发布的文档与 RFC 1471 同属 PPP 管理对象家族。后者管理 LCP，前者把认证配置放入一个可选的安全组。之所以可选，是因为这组对象不仅能暴露身份与秘密，还能改变认证协议的选择和顺序。

优先级表安排的是尝试

pppSecurityConfigTable 按链路和优先级保存协议。数值较小的协议先尝试。链路值为零时，它成为没有专用记录的链路所采用的默认规则。

“优先”并不表示更安全，也不预测成功。“协议”字段说明准备尝试什么，不说明已经协商了什么。“默认”则是一条继承规则；如果具体链路存在自己的记录，默认项可能根本不生效。

状态字段进一步限制了解读。一行可以是 valid 或 invalid。把它设成无效，并不一定会删除这行；是否删除由实现决定。因此管理站必须容忍“仍然看得见、但已不再使用”的记录，并查看状态后才能判断。

行的存在是一条证据，行是否当前有效是另一条证据。

ID/Secret 对不是已验证的人

第二张表允许一个链路保存多个 ID/Secret 对，由索引区分。RFC 1472 明确把实际选择哪一对留给本地实现。

方向决定了这对数据用于哪一边。local-to-remote 表示本地实体向远端证明自己；remote-to-local 表示本地实体期待远端使用这对值。相同的字节放在不同方向，承担的是不同动作。

协议也决定字段含义。PAP 下，身份可能是 Peer-ID，秘密是口令；CHAP-MD5 下，身份可能是 CHAP Name，秘密则参与响应计算。文档把它们定义成八位组串，因为真正语义来自协议上下文。

所以，“身份”字段不是人的身份证明，存有秘密也不证明某个主体在某个时刻掌握它。valid 更不说明本地选中了哪一对、远端提交了什么、认证方作出了什么判断。

配置行只是一次可能事件的输入。

认证证据在另一条时间线上

同时代的 RFC 1334 描述了 PAP 的实际动作：链路建立后，对端发送 Peer-ID 与口令，认证方返回 Authenticate-Ack 或 Authenticate-Nak。后来的 RFC 1994 把 CHAP 写成挑战、计算响应、本地比对与成功或失败，并允许以后再次挑战。

这些报文才会生成“发生过认证尝试”的证据。审计至少要把链路、协商出的协议、请求或挑战标识、响应、所用凭据版本和结果连起来。

RFC 1661 还把后续边界写得很清楚：先建立并测试数据链路，然后可以认证对端，再由 NCP 配置网络层协议。只有相应 NCP 打开后，该网络层的数据报才可发送。

配置凭据不证明认证；认证成功不证明 IPCP 已开；IPCP 已开也不证明路由、到达或应用处理。

管理路径本身就是风险面

RFC 1472 强烈建议：没有 SNMPv2 隐私保护，就不要实现这个安全组。MIB view 可以限制敏感子树。把变量设为只读可以缩小写权限，却仍然可能泄露秘密，文档对此直言不讳。

这类保护约束的是管理会话，不是 PPP 对端认证。一次经过保护的写入最多证明管理员在某个通道里改变了配置；线路上的对端仍需完成自己的协议交互。

集中管理带来便利，也集中后果。错误的默认项、未经批准的优先级变化、暴露的 view 或被误读的旧行，都可能影响多条链路，而表里的一个绿色状态无法解释最终用了哪条记录。

两本账不能合成一盏灯

配置账应保存操作者、时间、链路范围、默认继承、优先级、协议、索引、方向、状态变化和 agent 回读。事件账另存 LCP 阶段、协商协议、请求或挑战、响应、判断、凭据版本、NCP 状态与流量观察。

从未被选择的有效行是库存，不是认证失败；仍被运行时选择的无效行才是偏差；无法关联凭据版本的成功记录存在归因缺口；已认证但未打开 IPCP 的链路是后续阶段故障。

RFC 1472 留下的历史启示很克制：MIB 可以说明系统准备做什么。它不能借用尚未发生的事件来证明自己已经成功。

来源