摘要

  • NTS 先用 TLS 完成身份核验、算法协商和双向密钥导出，随后关闭连接；日常 NTP 请求把加密 cookie 带回服务器，服务器无需保存逐客户端会话。
  • cookie 加密密钥、C2S/S2C 报文密钥、随机请求标识、补充占位符、时间源选择和本地时钟调整是不同状态，不能压缩成“已启用 NTS”。
  • Dieter Sibold 是 RFC 8915 五位作者之一，现行 IETF 资料也列出其工作组职责；这证明贡献，不证明他独自发明 NTS 或控制任何部署与时间真值。

一条 TLS 连接已经正常关闭，服务器也没有留下这位客户端的记录。稍后，一份 UDP 授时请求抵达，其中有个发送方自己也看不懂的密封对象。服务器解开它，恢复先前协商的两个方向密钥，验证请求，再生成客户端能够核验的回答。

这不是无中生有。状态没有消失，只是换了保管人。RFC 8915 让客户端携带服务器自己生成、自己加密、日后仍由自己解释的收据。结果是服务端可以不维护庞大的客户端会话表，而认证连续性仍能跨过 TLS 连接的终止。

“把状态移出去”很容易被说成一句性能优化。实际上，它重新划分了控制面：谁建立身份，谁保管密钥世代，谁携带 cookie，谁判断报文属于哪次请求，谁决定这份时间样本能不能校准本机时钟。只有把这些问题分开，NTS 才不会从安全机制变成一盏含义过多的绿灯。

两段协议故意不连成一条隧道

第一段是 NTS Key Establishment。NTS-KE 运行在 TCP 4460 端口之上，通过 TLS 与 ALPN 标识 ntske/1 完成服务身份核验。双方协商后续协议与 AEAD 算法，服务器还可以把客户端引向另一个 NTP 地址和端口。

TLS 导出器从这次会话中生成两把用途分离的密钥：C2S 用于客户端到服务器，S2C 用于服务器到客户端。NTS-KE 返回一批初始 cookie，然后双方结束 TLS。RFC 明确把“服务器端不再保留逐客户端状态”作为设计目标。

第二段回到 NTP 的数据报路径。普通 48 字节 NTP 头部被认证而非加密，请求另外携带随机 Unique Identifier、一个 cookie，以及用 C2S 生成的认证字段；响应使用 S2C，并回送同一个标识。

中间的断点非常重要。昂贵的非对称运算集中在偶发的建立阶段，高频授时只用较轻的对称保护。NTS-KE 与 NTP 服务甚至可以分离部署，只要它们对 cookie 加密密钥与可接受的 NTP 端点保持一致。

运行记录因此不能停在“握手成功”。它还要回答：核验了哪个证书、用什么时钟政策判断有效期、协商了什么协议与算法、导出了哪个密钥世代、发了多少 cookie、指向哪个 NTP 服务，以及第一份受保护 NTP 响应是否真的通过核验。

cookie 是服务器写下、客户端保管的密封账页

RFC 8915 给出一种建议格式。服务器把 AEAD 标识、S2C 密钥与 C2S 密钥组成明文，再用一把独立的服务器 cookie 加密密钥封装。最终对象由密钥标识、nonce 与密文构成。

客户端只看到不透明字节。它不能选择其中的算法，不能替换方向密钥，也不能把对象改写成另一份有效声明。下次请求时，它只负责原样带回。服务器根据密钥标识找到相应世代，验证并解密，从而恢复关联状态。

所以“无状态服务器”不是“服务器什么都不记得”。它不必记住某个客户端，却仍要保存共享的 cookie 密钥世代、算法配置、集群分发状态与时间源。若负载均衡后的某个节点拿不到正确世代，客户端手里的完整 cookie 也会被拒绝。

这正是收据与权威的区别。客户端拥有的是保管权，不是解释权；cookie 维持的是上一次协商的连续性，不是客户端身份，更不是时间来源的所有权。载体可以移动，声明的作者没有因此改变。

请求见证、方向密钥与 cookie 密钥不能混为一谈

Unique Identifier 由安全随机数产生，在请求中接受认证，在响应中被回送。客户端借此确认回答属于刚才那次请求，并拒绝被攻击者重新注入的旧回答。它是一次性事务见证，不是 cookie 的解密索引，也不是长期设备号码。

C2S 与 S2C 的分离则让两个方向的证据不能互换。再加上服务器用于封装 cookie 的密钥，至少存在三类不同秘密。把它们统一称为“NTS 密钥”会掩盖轮换、泄露与责任归属上的差异。

RFC 8915 在客户端—服务器模式中保护客户端免受响应重放，却不要求服务器保存所有已处理请求。对无状态服务器而言，重新处理一份有效请求可以接受，前提是响应不会被用来放大攻击。这也是规范只覆盖 NTP 客户端模式 3 与服务器模式 4，而不是覆盖所有模式的原因。

告警同样需要细分：找不到 cookie 密钥、cookie 完整性失败、NTP 认证字段失败、响应标识不匹配、样本虽认证却被时间算法淘汰，分别指向不同控制面。

占位符先为响应付出字节预算

客户端不宜反复使用同一个 cookie，因为稳定的不透明值可能让旁观者把设备在两个网络上的流量联系起来。服务器因此需要在响应中补充新 cookie。可是一份很小的 UDP 请求若能索取很大的响应，就会制造源地址欺骗与放大攻击空间。

NTS Cookie Placeholder 让客户端先在请求里预留空间，服务器再用相应空间回填新 cookie。规范建议把未使用库存补到八个，并通常不在一份请求里放超过七个占位符；若包长可能造成分片，就应减少数量。

这个字段不是无意义填充。它证明响应规模已经由请求方用自己的报文长度预付。运营监测应同时记录库存、占位数、补充数、cookie 长度、丢包与最终数据报大小，而不是把“八个”误当成所有实现的强制合格线。

密钥轮换决定旧收据何时失效

建议的 cookie 明文没有一个统一的内置到期时间。它能否继续使用，取决于服务器是否仍保留标识所指的解密密钥。规范建议轮换密钥，删除更老世代以缩小泄露影响，同时短暂保留有限旧世代，让客户端平滑过渡。

若密钥从未存在或已经删除，服务器无法解密，就返回 NTS NAK。客户端必须重新执行 NTS-KE。没有持久化的重启、集群成员间分发错误、过快轮换，或者应对泄露时的主动清除，都可能让大量客户端同时转向 TLS 建立。

双服务结构也带来故障隔离。NTS-KE 被压垮时，手里仍有可解密 cookie 的客户端可以继续得到受保护时间；新客户端或库存失效的客户端不行。反过来，建立服务健康也不能修复 NTP 数据面故障。

chrony 的现行文档给出一份运行代码样本。authdata 把建立次数、AEAD、密钥长度、上次成功、重试、NAK、cookie 数量与长度分列显示；服务器配置还涉及重启持久化和轮换。这些是 chrony 的实现选择，不是 RFC 对所有产品的统一默认值，却说明可审计状态应该长什么样。

不复用更利于隐私，复用更利于连续性

当新 cookie 充足时，客户端应避免复用。这样，设备更换网络地址后，不会因为持续发送同一个可识别值而额外暴露关联线索。

但若 NTS-KE 长时间不可用，一次一用会耗尽库存。RFC 允许在连续性优先时复用 cookie。这不是没有代价的回退，而是明确把“较少关联”与“不中断认证授时”放在同一张决策表上。

NTS 也不承诺匿名。时间服务器本身仍看得到自己的客户端，建立阶段的 TLS 流量不在这项不可关联目标内，NTP 头部也没有被整体加密。准确的运行记录要写明是否复用、为什么允许、持续多久、客户端是否换网，以及何时恢复新库存。

报文真实，不代表时间正确

认证能够证明持有预期密钥的一方生成了报文，并且受保护字段未被篡改。它不能证明服务器时钟正确、上游参考源诚实，或客户端应该采用这份测量。

RFC 8633 因此建议需要可靠精度的运营者使用至少四个独立且多样的时间源。RFC 5905 的筛选、交集、聚类与本地时钟纪律仍然存在。NTS 缩小攻击面，却不替代“从互相可能出错的来源中选择”的算法。

延迟攻击把边界展示得最清楚。路径上的攻击者无需修改任何认证字节，只要让单向时延增加，就能扭曲客户端根据往返时间推算的偏移。认证全绿，测量仍可能偏。多源、多路径与距离上限只能降低风险，不能让密码学删除物理时延。

证书冷启动又形成一个小循环：TLS 证书带有有效期，而客户端正因为本机时间不可信才来授时。RFC 建议结合有后备电池的时钟、持久化的最后已知时间、多源比较，以及首次同步后再核查证书区间，但承认没有完美方案。

因此一份完整收据必须继续到偏移、时延、根距离、候选源、被选与被弃结果、本机时钟状态和实际调整。报文认证只是时间判断的输入。

Dieter Sibold 的名字属于集体标准工作

RFC 8915 于 2020 年 9 月发布，作者是 Daniel Fox Franke、Dieter Sibold、Kristof Teichel、Marcus Dansarie 与 Ragnar Sundblad。它是经过公开评审并代表 IETF 共识的标准轨文档。署名让贡献可追溯，不把共识变成个人命令。

IETF 现行资料将 Sibold 列为 Network Time Protocols 工作组主席与 Internet Area Directorate 评审员，并在其资料下列出 RFC 8633 与 RFC 8915。工作组页面还说明 NTP、NTS、延迟抵抗与下一代时间协议仍在继续演进。

德国国家计量院 PTB 的现行法律声明将 Dr. Dieter Sibold 列为信息安全负责人。PTB 关于安全计算机授时的正式消息也把他列为 NTS 工作联系人。

这些资料连接了计量机构、信息安全与开放标准，却不证明他单独发明 NTS、控制 IETF、决定 chrony 行为，或者操作每一项 PTB 时间服务。人物文章也必须遵守协议文章的权力边界：贡献可归属，系统权威不能凭叙事转移。

从建立到校时，收据要连续但不能泄露秘密

第一段记录 NTS-KE：端点、证书链与核验政策、TLS/ALPN 结果、协议、AEAD、导出世代、NTP 目标与初始库存。日志保存安全的世代标识，不保存秘密密钥内容。

第二段记录 cookie：封装密钥世代、库存、首次使用或复用、占位符、补充、NAK、轮换与重建。在集群中，还应能看出哪一个节点无法解释哪一代对象。

第三段记录 NTP 交换：请求标识的安全摘要、方向、认证、响应关联、偏移、时延与淘汰理由。最后才是本地时钟：候选源集合、选择结果、校正动作与恢复状态。

把四段连起来，才能防止一步冒充全局结论。TLS 成功后可能没有可用 NTP；NTP 认证后样本可能被淘汰；时钟当前正确时，cookie 密钥分发仍可能在下次重启失败。运行代码优先，就是让真实状态转移压过“功能已开启”的标签。

资料来源