摘要

  • NTS 可以确认 NTS-KE 服务端身份，并验证 NTP 响应是否对应尚未完成的请求。它不能证明服务器的钟是准的，不能消除非对称时延，也不会替客户端选择来源或批准本机跳变时钟。
  • 可解释的时间决策至少包含四份彼此独立的证据：身份与密钥建立、报文认证、来源适用性与选择、时钟纪律与执行。把它们压成一个“安全”绿灯，恰好会抹掉谁有权让机器改时间。

两个认证结果，并不构成一道命令

开篇是一个构造的控制实验，不是真实事故。来源 A 与来源 B 都有可验证的证书，两次 NTS-KE 都成功，服务器分别发回密钥材料与 cookie。随后的 NTP 响应用正确的服务端至客户端方向密钥通过认证，回显各自尚未完成请求的唯一标识，也没有触发重放判断。然而一份响应认为时钟几乎无须调整，另一份要求修正 800 毫秒。

这并不要求密码算法出错。某一来源可能继承了错误的上游时间；某一路径可能存在严重的非对称排队；某份测量的根距离可能超过本地上限；两台服务器也可能无法与其他候选形成选择算法需要的共同交集。

客户端仍须作出判断：选择 A，在更多来源支持下选择 B，组合一组相容测量，或者保持未同步。证据不足时不动时钟不是协议失败，而是本地决定权真正发挥作用。

NTS 究竟认证了什么

RFC 8915 把 NTS 分成两个松耦合协议。NTS 密钥建立运行于 TLS 之上；之后的时间同步则把 NTS 扩展字段放进客户端—服务器模式的 NTP 报文。身份与密钥协商可以先完成，频繁的时间交换保持轻量。

NTS-KE 使用 TCP 4460 端口、TLS 1.3 或更高版本，以及 ALPN 标识 ntske/1。服务端可指定后续 NTP 端点，协商认证加密算法，并交付一批不透明 cookie。TLS 导出器产生两个方向不同的密钥：客户端至服务端和服务端至客户端。TLS 连接关闭后，服务端不必保留每个客户端的状态。

客户端把状态装进 cookie 带回。请求还包含唯一标识与认证字段。合格的响应必须由服务端至客户端密钥验证，并回显一个仍在等待响应的标识。新的 cookie 可放在受保护的扩展字段里返回，使客户端补充库存，同时降低多次出现被关联的风险。

因此，NTS 证明的是一个精确而有限的命题：被接受的响应来自持有相应 NTS 密钥的一方，传输途中未被篡改，而且确实对应客户端发出的请求。它没有证明对方振荡器、上游参考源或 UTC 值正确。

IANA 的 NTP 参数登记表体现了同一边界。它为唯一标识、NTS Cookie、Cookie Placeholder、认证器与加密扩展字段分配共同类型值，使实现可以互操作；它不评价任何时钟的质量，也不批准任何一次调钟。

身份不是准确度

证书回答 NTS-KE 服务“是谁”，不检查该服务背后的时钟。cookie 帮助无状态服务端恢复认证所需参数，不是“真实时间证书”。唯一标识把响应绑定到请求，却不测量路径是否对称。

RFC 8915 对时延攻击的说明揭示了这条界线。路径上的攻击者可以不改动、不重排报文，只让两个方向的延迟不同。所有密码校验依然成功，客户端计算出的偏移却会离开真实值。被操纵的是传输时间，而不是受保护的内容，密码学无法单独消除它。最大距离策略可以限制影响，多来源或多路径可在攻击者只控制部分路径时增强韧性，但认证本身不会变成时间真值。

保密范围同样有限。NTP 基本头仍是明文，NTS 支持对扩展字段加密，却不是整份时间报文的全面加密。可用性也属于另一层：路径上的参与者仍能丢包，一些 Kiss-o’-Death 响应也不在认证保护内。

所以，NTS-KE 失败后不应自动降级到未认证 NTP。若失败自然触发降级，攻击者只需破坏密钥建立就能剥离保护。是否降级必须是明确的本地决定。

第一次认证之前，启动策略已经作出选择

X.509 证书带有有效期。可是一台因为时钟不可信而寻求网络时间的机器，又需要大致可信的时间来验证将帮助它校时的服务。这一循环没有适用于所有部署的完美解。

RFC 8915 提出若干不完美的锚点：带电池的硬件时钟、人工给出的近似值、持久化的上次时间，以及多个来源之间的比较。紧接 NTS-KE 收到的时间也应与证书有效期相容。它们提供的是“足以启动身份验证”的合理窗口，不是精确 UTC。

运营者在第一份认证测量到达前就已经分配权力：接受哪些信任根，持久化时间可以旧到什么程度，何时可以暂时放宽证书时间校验，需要多少独立来源同意后才允许改钟。没有写下这些选择，并不意味着没有策略，只意味着默认配置代替组织作答。

报文通过之后，选源才刚开始

RFC 5905 描述的是一条留在客户端内部的决策链。报文处理产生测量；时钟滤波降低每个关联的噪声；选择算法寻找由多数可信候选支持的交集；聚类剔除离群者；组合阶段给出最终偏移；时钟纪律再决定如何调整相位与频率。

NTS 加强的是这条链的入口。伪造或重放的响应可以在成为测量前被拒绝，但后续步骤并未消失。认证来源仍可能成为错误计时者；密码上有效的测量仍可能因时延或根距离过大而被丢弃；存活候选不足时，系统应保持未同步。

chrony 的现行文档把这些证据面分开呈现。authdata 报告认证方式、密钥建立次数、尝试、负确认与剩余 cookie；其他报告才显示可达性、来源一致性和选择状态。maxdelay 及相关测试可拒绝过大或异常时延，minsources 可要求达到一定可选来源数量后才更新本地时钟，信任与必需选项则约束认证和未认证来源如何参与选择。

NTPsec 另有证书、客户端、服务端和 cookie 密钥持久化控制。实现表面的差异不违背标准，而是说明共同互操作规则在哪里结束，运营策略从哪里开始。

不要一枚徽章，要四份证据

身份凭据应保存配置的 NTS-KE 名称、接受的证书链与服务身份、使用的信任集合以及密钥建立时间。

报文凭据应保存密钥代次、唯一标识、cookie 状态、认证器、所对应的未完成请求，以及重放或 NTS 负确认如何改变状态。

测量凭据应保存偏移、时延、离散度、根距离、可达性、来源历史、交集和离群状态。真实来源发来的认证报文，可以在这一层成为不可用测量。

执行凭据应保存最终选择的来源或组合、允许渐调或跳变的阈值、执行进程和改动前状态。这才是机器上的实际权力记录。

只保留“NTS 已启用”的面板，最多说明用了安全机制，无法说明为什么时钟发生变化。

最小共同规则与本地决定

Heng Lu 的“最小初始规范”提供了清晰的分析方法：共同层只容纳互操作、共同安全和本地验证所必需的确定规则；后续选择应留给运行代码的参与者。规则被发布不等于已经成为运行事实，共同语法也不会赋予某个持续机构对参与者的永久命令权。

按这条边界理解，NTS 的结构十分克制。IETF 规定端点如何协商、导出密钥、携带状态和验证字段；IANA 记录共享编号；证书机构参与端点身份验证。它们都不会替客户端决定来源清单、最大距离、启动时间是否可信，也不会批准主机调用系统接口修改时钟。

“运行代码优先”补充了操作检验：规范有价值，因为独立系统能够实现并在本地验证它。客户端可以接受报文却拒绝测量，可以信任服务身份却禁止时钟跳变。这不是对标准的不服从，而是分层安全得以成立的条件。

证据与范围

800 毫秒差异仅为说明，不对应任何供应商、产品故障、事故或攻击。冻结来源如下：