Internet Engineering Task Force (IETF) B. Haberman, Ed.
Request for Comments: 5906 JHU/APL
Category: Informational D. Mills
ISSN: 2070-1721 U. Delaware
June 2010
Internet Engineering Task Force (IETF) B. Haberman, Ed.
Request for Comments: 5906 JHU/APL
Category: Informational D. Mills
ISSN: 2070-1721 U. Delaware
June 2010
Network Time Protocol Version 4: Autokey Specification
网络时间协议版本4：自动密钥规范
Abstract
摘要
This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.
本备忘录描述了使用网络时间协议（NTP）和公钥加密技术向客户端验证服务器的自动密钥安全模型。它的设计基于这样一个前提，即不能完整地采用IPsec方案，因为这将排除无状态服务器，并严重影响计时准确性。此外，公钥基础设施（PKI）方案假定经过身份验证的时间值始终可用于强制执行证书生命周期；然而，经过加密验证的时间戳需要计时和身份验证功能之间的交互。
This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org.
本备忘录包括自动密钥需求分析、设计原则和协议规范。包括协议状态、事件和转换函数的详细描述。基于此备忘录的自动密钥设计原型已在NTP版本4（NTPv4）软件分发版中实施、测试并记录在以下位置：Unix、Windows和虚拟内存系统（VMS）操作系统http://www.ntp.org.
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5906.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5906.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. NTP Security Model ..............................................4
3. Approach ........................................................7
4. Autokey Cryptography ............................................8
5. Autokey Protocol Overview ......................................12
6. NTP Secure Groups ..............................................14
7. Identity Schemes ...............................................19
8. Timestamps and Filestamps ......................................20
9. Autokey Operations .............................................22
10. Autokey Protocol Messages .....................................23
10.1. No-Operation .............................................26
10.2. Association Message (ASSOC) ..............................26
10.3. Certificate Message (CERT) ...............................26
10.4. Cookie Message (COOKIE) ..................................27
10.5. Autokey Message (AUTO) ...................................27
10.6. Leapseconds Values Message (LEAP) ........................27
10.7. Sign Message (SIGN) ......................................27
10.8. Identity Messages (IFF, GQ, MV) ..........................27
11. Autokey State Machine .........................................28
11.1. Status Word ..............................................28
11.2. Host State Variables .....................................30
11.3. Client State Variables (all modes) .......................33
11.4. Protocol State Transitions ...............................34
11.4.1. Server Dance ......................................34
11.4.2. Broadcast Dance ...................................35
11.4.3. Symmetric Dance ...................................36
11.5. Error Recovery ...........................................37
12. Security Considerations .......................................39
12.1. Protocol Vulnerability ...................................39
12.2. Clogging Vulnerability ...................................40
13. IANA Considerations ...........................................42
13. References ....................................................42
13.1. Normative References .....................................42
13.2. Informative References ...................................43
Appendix A. Timestamps, Filestamps, and Partial Ordering .........45
Appendix B. Identity Schemes .....................................46
Appendix C. Private Certificate (PC) Scheme ......................47
Appendix D. Trusted Certificate (TC) Scheme ......................47
Appendix E. Schnorr (IFF) Identity Scheme ........................48
Appendix F. Guillard-Quisquater (GQ) Identity Scheme .............49
Appendix G. Mu-Varadharajan (MV) Identity Scheme .................51
Appendix H. ASN.1 Encoding Rules .................................54
Appendix I. COOKIE Request, IFF Response, GQ Response, MV
Response .............................................54
Appendix J. Certificates .........................................55
1. Introduction ....................................................4
2. NTP Security Model ..............................................4
3. Approach ........................................................7
4. Autokey Cryptography ............................................8
5. Autokey Protocol Overview ......................................12
6. NTP Secure Groups ..............................................14
7. Identity Schemes ...............................................19
8. Timestamps and Filestamps ......................................20
9. Autokey Operations .............................................22
10. Autokey Protocol Messages .....................................23
10.1. No-Operation .............................................26
10.2. Association Message (ASSOC) ..............................26
10.3. Certificate Message (CERT) ...............................26
10.4. Cookie Message (COOKIE) ..................................27
10.5. Autokey Message (AUTO) ...................................27
10.6. Leapseconds Values Message (LEAP) ........................27
10.7. Sign Message (SIGN) ......................................27
10.8. Identity Messages (IFF, GQ, MV) ..........................27
11. Autokey State Machine .........................................28
11.1. Status Word ..............................................28
11.2. Host State Variables .....................................30
11.3. Client State Variables (all modes) .......................33
11.4. Protocol State Transitions ...............................34
11.4.1. Server Dance ......................................34
11.4.2. Broadcast Dance ...................................35
11.4.3. Symmetric Dance ...................................36
11.5. Error Recovery ...........................................37
12. Security Considerations .......................................39
12.1. Protocol Vulnerability ...................................39
12.2. Clogging Vulnerability ...................................40
13. IANA Considerations ...........................................42
13. References ....................................................42
13.1. Normative References .....................................42
13.2. Informative References ...................................43
Appendix A. Timestamps, Filestamps, and Partial Ordering .........45
Appendix B. Identity Schemes .....................................46
Appendix C. Private Certificate (PC) Scheme ......................47
Appendix D. Trusted Certificate (TC) Scheme ......................47
Appendix E. Schnorr (IFF) Identity Scheme ........................48
Appendix F. Guillard-Quisquater (GQ) Identity Scheme .............49
Appendix G. Mu-Varadharajan (MV) Identity Scheme .................51
Appendix H. ASN.1 Encoding Rules .................................54
Appendix I. COOKIE Request, IFF Response, GQ Response, MV
Response .............................................54
Appendix J. Certificates .........................................55
A distributed network service requires reliable, ubiquitous, and survivable provisions to prevent accidental or malicious attacks on the servers and clients in the network or the values they exchange. Reliability requires that clients can determine that received packets are authentic; that is, were actually sent by the intended server and not manufactured or modified by an intruder. Ubiquity requires that a client can verify the authenticity of a server using only public information. Survivability requires protection from faulty implementations, improper operation, and possibly malicious clogging and replay attacks.
分布式网络服务需要可靠、普遍且可生存的规定，以防止对网络中的服务器和客户端或它们交换的值进行意外或恶意攻击。可靠性要求客户端能够确定接收到的数据包是真实的；也就是说，它们实际上是由预期的服务器发送的，而不是由入侵者制造或修改的。普遍性要求客户端只能使用公共信息来验证服务器的真实性。生存能力要求能够防止错误实现、不当操作以及可能的恶意阻塞和重放攻击。
This memo describes a cryptographically sound and efficient methodology for use in the Network Time Protocol (NTP) [RFC5905]. The various key agreement schemes [RFC4306][RFC2412][RFC2522] proposed require per-association state variables, which contradicts the principles of the remote procedure call (RPC) paradigm in which servers keep no state for a possibly large client population. An evaluation of the PKI model and algorithms, e.g., as implemented in the OpenSSL library, leads to the conclusion that any scheme requiring every NTP packet to carry a PKI digital signature would result in unacceptably poor timekeeping performance.
本备忘录描述了一种在网络时间协议（NTP）[RFC5905]中使用的可靠且高效的加密方法。提出的各种密钥协商方案[RFC4306][RFC2412][RFC2522]需要每个关联状态变量，这与远程过程调用（RPC）范例的原则相矛盾，在远程过程调用（RPC）范例中，服务器对于可能大量的客户机群体不保持任何状态。对PKI模型和算法的评估（例如，在OpenSSL库中实现的）得出的结论是，任何要求每个NTP数据包携带PKI数字签名的方案都会导致不可接受的计时性能差。
The Autokey protocol is based on a combination of PKI and a pseudo-random sequence generated by repeated hashes of a cryptographic value involving both public and private components. This scheme has been implemented, tested, and deployed in the Internet of today. A detailed description of the security model, design principles, and implementation is presented in this memo.
自动密钥协议基于PKI和伪随机序列的组合，伪随机序列由涉及公共和私有组件的加密值的重复散列生成。该方案已经在今天的互联网上实施、测试和部署。本备忘录详细描述了安全模型、设计原则和实现。
This informational document describes the NTP extensions for Autokey as implemented in an NTPv4 software distribution available from http://www.ntp.org. This description is provided to offer a basis for future work and a reference for the software release. This document also describes the motivation for the extensions within the protocol.
本信息性文档介绍了在NTPv4软件发行版中实现的自动密钥的NTP扩展，可从http://www.ntp.org. 本说明旨在为以后的工作提供基础，并为软件发布提供参考。本文档还描述了协议内扩展的动机。
NTP security requirements are even more stringent than most other distributed services. First, the operation of the authentication mechanism and the time synchronization mechanism are inextricably intertwined. Reliable time synchronization requires cryptographic keys that are valid only over designated time intervals; but, time intervals can be enforced only when participating servers and clients are reliably synchronized to UTC. In addition, the NTP subnet is
NTP安全要求甚至比大多数其他分布式服务更严格。首先，身份验证机制和时间同步机制的运作密不可分。可靠的时间同步要求加密密钥仅在指定的时间间隔内有效；但是，只有当参与的服务器和客户端可靠地与UTC同步时，才能强制执行时间间隔。此外，NTP子网是
hierarchical by nature, so time and trust flow from the primary servers at the root through secondary servers to the clients at the leaves.
本质上是分层的，因此时间和信任从根目录下的主服务器通过辅助服务器流向叶目录下的客户端。
A client can claim authentic to dependent applications only if all servers on the path to the primary servers are bona fide authentic. In order to emphasize this requirement, in this memo, the notion of "authentic" is replaced by "proventic", an adjective new to English and derived from "provenance", as in the provenance of a painting. Having abused the language this far, the suffixes fixable to the various derivatives of authentic will be adopted for proventic as well. In NTP, each server authenticates the next-lower stratum servers and proventicates (authenticates by induction) the lowest stratum (primary) servers. Serious computer linguists would correctly interpret the proventic relation as the transitive closure of the authentic relation.
只有在主服务器路径上的所有服务器都是真正可信的情况下，客户机才能向依赖应用程序声明可信。为了强调这一要求，在本备忘录中，“真实”的概念替换为“proventic”，这是英语中新出现的一个形容词，来源于“provence”，就像在绘画的provence中一样。迄今为止，普罗旺斯语滥用了该语言，因此，普罗旺斯语也将采用可固定于各种“真实”派生词的后缀。在NTP中，每个服务器对下一个较低层的服务器进行身份验证，并对最低层（主）服务器进行身份验证（通过归纳进行身份验证）。严肃的计算机语言学家会正确地将普罗旺斯语关系解释为真实关系的传递闭包。
It is important to note that the notion of proventic does not necessarily imply the time is correct. An NTP client mobilizes a number of concurrent associations with different servers and uses a crafted agreement algorithm to pluck truechimers from the population possibly including falsetickers. A particular association is proventic if the server certificate and identity have been verified by the means described in this memo. However, the statement "the client is synchronized to proventic sources" means that the system clock has been set using the time values of one or more proventic associations and according to the NTP mitigation algorithms.
值得注意的是，普罗旺斯的概念并不一定意味着时间是正确的。NTP客户机与不同的服务器移动大量并发关联，并使用特制的协议算法从人群中提取TrueChemer，可能包括Falsticker。如果服务器证书和身份已通过本备忘录中所述的方式进行验证，则特定关联为proventic。然而，“客户端与proventic源同步”的语句意味着系统时钟已使用一个或多个proventic关联的时间值并根据NTP缓解算法进行设置。
Over the last several years, the IETF has defined and evolved the IPsec infrastructure for privacy protection and source authentication in the Internet. The infrastructure includes the Encapsulating Security Payload (ESP) [RFC4303] and Authentication Header (AH) [RFC4302] for IPv4 and IPv6. Cryptographic algorithms that use these headers for various purposes include those developed for the PKI, including various message digest, digital signature, and key agreement algorithms. This memo takes no position on which message digest or digital signature algorithm is used. This is established by a profile for each community of users.
在过去几年中，IETF定义并发展了IPsec基础设施，用于互联网中的隐私保护和源认证。基础设施包括IPv4和IPv6的封装安全有效负载（ESP）[RFC4303]和身份验证头（AH）[RFC4302]。将这些头用于各种目的的加密算法包括为PKI开发的加密算法，包括各种消息摘要、数字签名和密钥协商算法。此备忘录不考虑使用哪种消息摘要或数字签名算法。这是由每个用户社区的配置文件建立的。
It will facilitate the discussion in this memo to refer to the reference implementation available at http://www.ntp.org. It includes Autokey as described in this memo and is available to the general public; however, it is not part of the specification itself. The cryptographic means used by the reference implementation and its user community are based on the OpenSSL cryptographic software library available at http://www.openssl.org, but other libraries with equivalent functionality could be used as well. It is important for
这将有助于本备忘录中的讨论，以参考http://www.ntp.org. 它包括本备忘录中所述的自动钥匙，可供公众使用；但是，它不是规范本身的一部分。参考实现及其用户社区使用的加密方法基于OpenSSL加密软件库，可在http://www.openssl.org，但也可以使用具有同等功能的其他库。这对我们来说很重要
distribution and export purposes that the way in which these algorithms are used precludes encryption of any data other than incidental to the construction of digital signatures.
分发和导出的目的是，这些算法的使用方式排除了除数字签名构造之外的任何数据加密。
The fundamental assumption in NTP about the security model is that packets transmitted over the Internet can be intercepted by those other than the intended recipient, remanufactured in various ways, and replayed in whole or part. These packets can cause the client to believe or produce incorrect information, cause protocol operations to fail, interrupt network service, or consume precious network and processor resources.
NTP中关于安全模型的基本假设是，通过互联网传输的数据包可以被预期接收者以外的人截获，以各种方式重新制造，并全部或部分重放。这些数据包可能导致客户端相信或产生错误信息，导致协议操作失败，中断网络服务，或消耗宝贵的网络和处理器资源。
In the case of NTP, the assumed goal of the intruder is to inject false time values, disrupt the protocol or clog the network, servers, or clients with spurious packets that exhaust resources and deny service to legitimate applications. The mission of the algorithms and protocols described in this memo is to detect and discard spurious packets sent by someone other than the intended sender or sent by the intended sender, but modified or replayed by an intruder.
在NTP的情况下，入侵者的假定目标是注入错误的时间值，破坏协议，或使用消耗资源并拒绝向合法应用程序提供服务的虚假数据包阻塞网络、服务器或客户端。本备忘录中所述算法和协议的任务是检测并丢弃由非预期发送者发送的或由预期发送者发送但被入侵者修改或重播的虚假数据包。
There are a number of defense mechanisms already built in the NTP architecture, protocol, and algorithms. The on-wire timestamp exchange scheme is inherently resistant to spoofing, packet-loss, and replay attacks. The engineered clock filter, selection, and clustering algorithms are designed to defend against evil cliques of Byzantine traitors. While not necessarily designed to defeat determined intruders, these algorithms and accompanying sanity checks have functioned well over the years to deflect improperly operating but presumably friendly scenarios. However, these mechanisms do not securely identify and authenticate servers to clients. Without specific further protection, an intruder can inject any or all of the following attacks.
NTP体系结构、协议和算法中已经构建了许多防御机制。在线时间戳交换方案固有地抵抗欺骗、数据包丢失和重放攻击。精心设计的时钟过滤、选择和聚类算法旨在抵御拜占庭叛徒的邪恶集团。虽然这些算法不一定是为了击败确定的入侵者而设计的，但这些算法和伴随的健全性检查多年来一直发挥着良好的作用，以避免出现操作不当但可能是友好的情况。但是，这些机制不能安全地向客户端识别和验证服务器。在没有特定的进一步保护的情况下，入侵者可以注入以下任何或所有攻击。
1. An intruder can intercept and archive packets forever, as well as all the public values ever generated and transmitted over the net.
1. 入侵者可以永远截获和归档数据包，以及通过网络生成和传输的所有公共值。
2. An intruder can generate packets faster than the server, network, or client can process them, especially if they require expensive cryptographic computations.
2. 入侵者生成数据包的速度比服务器、网络或客户端处理数据包的速度要快，特别是当它们需要昂贵的加密计算时。
3. In a wiretap attack, the intruder can intercept, modify, and replay a packet. However, it cannot permanently prevent onward transmission of the original packet; that is, it cannot break the wire, only tell lies and congest it. Except in the unlikely cases considered in Section 12, the modified packet cannot arrive at the victim before the original packet, nor does it have the server private keys or identity parameters.
3. 在窃听攻击中，入侵者可以拦截、修改和重放数据包。然而，它不能永久地阻止原始数据包的向前传输；也就是说，它不能断开电线，只能说谎并堵塞电线。除第12节中考虑的不太可能的情况外，修改后的数据包不能在原始数据包之前到达受害者，也没有服务器私钥或身份参数。
4. In a man-in-the-middle or masquerade attack, the intruder is positioned between the server and client, so it can intercept, modify, and replay a packet and prevent onward transmission of the original packet. Except in unlikely cases considered in Section 12, the middleman does not have the server private keys.
4. 在中间人攻击或伪装攻击中，入侵者位于服务器和客户端之间，因此它可以拦截、修改和重播数据包，并阻止原始数据包的向前传输。除第12节中考虑的不太可能的情况外，中间人没有服务器私钥。
The NTP security model assumes the following possible limitations.
NTP安全模型假设了以下可能的限制。
1. The running times for public key algorithms are relatively long and highly variable. In general, the performance of the time synchronization function is badly degraded if these algorithms must be used for every NTP packet.
1. 公钥算法的运行时间相对较长且变化很大。通常，如果必须对每个NTP数据包使用这些算法，则时间同步功能的性能会严重降低。
2. In some modes of operation, it is not feasible for a server to retain state variables for every client. It is however feasible to regenerated them for a client upon arrival of a packet from that client.
2. 在某些操作模式下，服务器不可能为每个客户端保留状态变量。然而，在来自客户机的数据包到达时为客户机重新生成它们是可行的。
3. The lifetime of cryptographic values must be enforced, which requires a reliable system clock. However, the sources that synchronize the system clock must be cryptographically proventicated. This circular interdependence of the timekeeping and proventication functions requires special handling.
3. 必须强制执行加密值的生存期，这需要可靠的系统时钟。但是，同步系统时钟的源必须经过加密验证。计时和预防功能的这种循环相互依赖性需要特殊处理。
4. Client security functions must involve only public values transmitted over the net. Private values must never be disclosed beyond the machine on which they were created, except in the case of a special trusted agent (TA) assigned for this purpose.
4. 客户端安全功能必须仅涉及通过网络传输的公共值。私有值不得在创建它们的计算机之外公开，除非为此目的指定了特殊的受信任代理（TA）。
Unlike the Secure Shell (SSH) security model, where the client must be securely authenticated to the server, in NTP, the server must be securely authenticated to the client. In SSH, each different interface address can be bound to a different name, as returned by a reverse-DNS query. In this design, separate public/private key pairs may be required for each interface address with a distinct name. A perceived advantage of this design is that the security compartment can be different for each interface. This allows a firewall, for instance, to require some interfaces to authenticate the client and others not.
与Secure Shell（SSH）安全模型不同，在NTP中，客户端必须安全地通过服务器身份验证，而服务器必须安全地通过客户端身份验证。在SSH中，每个不同的接口地址都可以绑定到一个不同的名称，正如反向DNS查询返回的那样。在这种设计中，可能需要为具有不同名称的每个接口地址提供单独的公钥/私钥对。这种设计的一个明显优势是，每个接口的安全隔室可能不同。例如，这允许防火墙需要一些接口来验证客户端，而其他接口则不需要。
The Autokey protocol described in this memo is designed to meet the following objectives. In-depth discussions on these objectives is in the web briefings and will not be elaborated in this memo. Note that here, and elsewhere in this memo, mention of broadcast mode means multicast mode as well, with exceptions as noted in the NTP software documentation [RFC5905].
本备忘录中描述的自动密钥协议旨在满足以下目标。关于这些目标的深入讨论见网络简报，本备忘录将不再详述。请注意，在这里以及本备忘录的其他地方，提及广播模式也意味着多播模式，NTP软件文档[RFC5905]中指出的例外情况除外。
1. It must interoperate with the existing NTP architecture model and protocol design. In particular, it must support the symmetric key scheme described in [RFC1305]. As a practical matter, the reference implementation must use the same internal key management system, including the use of 32-bit key IDs and existing mechanisms to store, activate, and revoke keys.
1. 它必须与现有的NTP架构模型和协议设计进行互操作。特别是，它必须支持[RFC1305]中描述的对称密钥方案。实际上，参考实现必须使用相同的内部密钥管理系统，包括使用32位密钥ID和现有机制来存储、激活和撤销密钥。
2. It must provide for the independent collection of cryptographic values and time values. An NTP packet is accepted for processing only when the required cryptographic values have been obtained and verified and the packet has passed all header sanity checks.
2. 它必须提供加密值和时间值的独立集合。只有在获得并验证了所需的加密值并且该数据包已通过所有报头健全性检查时，才会接受NTP数据包进行处理。
3. It must not significantly degrade the potential accuracy of the NTP synchronization algorithms. In particular, it must not make unreasonable demands on the network or host processor and memory resources.
3. 它不得显著降低NTP同步算法的潜在精度。特别是，不得对网络或主机处理器和内存资源提出不合理的要求。
4. It must be resistant to cryptographic attacks, specifically those identified in the security model above. In particular, it must be tolerant of operational or implementation variances, such as packet loss or disorder, or suboptimal configurations.
4. 它必须能够抵抗加密攻击，特别是上述安全模型中识别的攻击。特别是，它必须能够容忍操作或实现差异，例如数据包丢失或无序，或次优配置。
5. It must build on a widely available suite of cryptographic algorithms, yet be independent of the particular choice. In particular, it must not require data encryption other than that which is incidental to signature and cookie encryption operations.
5. 它必须建立在一套广泛可用的密码算法之上，但不依赖于特定的选择。特别是，除签名和cookie加密操作附带的数据加密外，它不得要求其他数据加密。
6. It must function in all the modes supported by NTP, including server, symmetric, and broadcast modes.
6. 它必须在NTP支持的所有模式下工作，包括服务器模式、对称模式和广播模式。
Autokey cryptography is based on the PKI algorithms commonly used in the Secure Shell and Secure Sockets Layer (SSL) applications. As in these applications, Autokey uses message digests to detect packet modification, digital signatures to verify credentials, and public certificates to provide traceable authority. What makes Autokey cryptography unique is the way in which these algorithms are used to deflect intruder attacks while maintaining the integrity and accuracy of the time synchronization function.
自动密钥加密基于安全外壳和安全套接字层（SSL）应用程序中常用的PKI算法。在这些应用程序中，Autokey使用消息摘要检测数据包修改，使用数字签名验证凭据，使用公共证书提供可跟踪的权限。自动密钥加密的独特之处在于，这些算法用于抵御入侵者攻击，同时保持时间同步功能的完整性和准确性。
Autokey, like many other remote procedure call (RPC) protocols, depends on message digests for basic authentication; however, it is important to understand that message digests are also used by NTP when Autokey is not available or not configured. Selection of the digest algorithm is a function of NTP configuration and is transparent to Autokey.
与许多其他远程过程调用（RPC）协议一样，自动密钥依赖于基本身份验证的消息摘要；但是，重要的是要了解，当Autokey不可用或未配置时，NTP也会使用消息摘要。摘要算法的选择是NTP配置的一个功能，对自动键是透明的。
The protocol design and reference implementation support both 128-bit and 160-bit message digest algorithms, each with a 32-bit key ID. In order to retain backwards compatibility with NTPv3, the NTPv4 key ID space is partitioned in two subspaces at a pivot point of 65536. Symmetric key IDs have values less than the pivot and indefinite lifetime. Autokey key IDs have pseudo-random values equal to or greater than the pivot and are expunged immediately after use.
协议设计和参考实现支持128位和160位消息摘要算法，每个算法都有32位密钥ID。为了保持与NTPv3的向后兼容性，NTPv4密钥ID空间在65536的枢轴点分为两个子空间。对称密钥ID的值小于pivot，且不确定生存期。自动密钥ID的伪随机值等于或大于枢轴，使用后会立即删除。
Both symmetric key and public key cryptography authenticate as shown in Figure 1. The server looks up the key associated with the key ID and calculates the message digest from the NTP header and extension fields together with the key value. The key ID and digest form the message authentication code (MAC) included with the message. The client does the same computation using its local copy of the key and compares the result with the digest in the MAC. If the values agree, the message is assumed authentic.
对称密钥和公钥加密都进行身份验证，如图1所示。服务器查找与密钥ID关联的密钥，并根据NTP头和扩展字段以及密钥值计算消息摘要。密钥ID和摘要构成消息中包含的消息身份验证码（MAC）。客户端使用密钥的本地副本执行相同的计算，并将结果与MAC中的摘要进行比较。如果值一致，则假定消息是真实的。
+------------------+
| NTP Header and |
| Extension Fields |
+------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Message Authentication Code |
\|/ \|/ + (MAC) +
******************** | +-------------------------+ |
* Compute Hash *<----| Key ID | Message Digest | +
******************** | +-------------------------+ |
| +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+
\|/ \|/
+------------------+ +-------------+
| Message Digest |------>| Compare |
+------------------+ +-------------+
+------------------+
| NTP Header and |
| Extension Fields |
+------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Message Authentication Code |
\|/ \|/ + (MAC) +
******************** | +-------------------------+ |
* Compute Hash *<----| Key ID | Message Digest | +
******************** | +-------------------------+ |
| +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+
\|/ \|/
+------------------+ +-------------+
| Message Digest |------>| Compare |
+------------------+ +-------------+
Figure 1: Message Authentication
图1：消息身份验证
Autokey uses specially contrived session keys, called autokeys, and a precomputed pseudo-random sequence of autokeys that are saved in the autokey list. The Autokey protocol operates separately for each association, so there may be several autokey sequences operating independently at the same time.
“自动密钥”使用特别设计的会话密钥（称为“自动密钥”）和保存在“自动密钥”列表中的预先计算的伪随机序列。自动密钥协议对每个关联单独运行，因此可能有多个自动密钥序列同时独立运行。
+-------------+-------------+--------+--------+
| Src Address | Dst Address | Key ID | Cookie |
+-------------+-------------+--------+--------+
+-------------+-------------+--------+--------+
| Src Address | Dst Address | Key ID | Cookie |
+-------------+-------------+--------+--------+
Figure 2: NTPv4 Autokey
图2:NTPv4自动键
An autokey is computed from four fields in network byte order as shown in Figure 2. The four values are hashed using the MD5 algorithm to produce the 128-bit autokey value, which in the reference implementation is stored along with the key ID in a cache used for symmetric keys as well as autokeys. Keys are retrieved from the cache by key ID using hash tables and a fast lookup algorithm.
如图2所示，按网络字节顺序从四个字段计算自动密钥。使用MD5算法对这四个值进行散列，以生成128位的自动密钥值，在参考实现中，该值与密钥ID一起存储在用于对称密钥和自动密钥的缓存中。使用哈希表和快速查找算法，通过密钥ID从缓存中检索密钥。
For use with IPv4, the Src Address and Dst Address fields contain 32 bits; for use with IPv6, these fields contain 128 bits. In either case, the Key ID and Cookie fields contain 32 bits. Thus, an IPv4 autokey has four 32-bit words, while an IPv6 autokey has ten 32-bit words. The source and destination addresses and key ID are public values visible in the packet, while the cookie can be a public value or shared private value, depending on the NTP mode.
对于IPv4，Src地址和Dst地址字段包含32位；对于IPv6，这些字段包含128位。在这两种情况下，密钥ID和Cookie字段都包含32位。因此，IPv4自动密钥有四个32位字，而IPv6自动密钥有十个32位字。源和目标地址以及密钥ID是数据包中可见的公共值，而cookie可以是公共值或共享私有值，具体取决于NTP模式。
The NTP packet format has been augmented to include one or more extension fields piggybacked between the original NTP header and the MAC. For packets without extension fields, the cookie is a shared private value. For packets with extension fields, the cookie has a default public value of zero, since these packets are validated independently using digital signatures.
NTP数据包格式已被扩充，包括一个或多个在原始NTP报头和MAC之间搭载的扩展字段。对于没有扩展字段的数据包，cookie是一个共享的私有值。对于具有扩展字段的数据包，cookie的默认公共值为零，因为这些数据包是使用数字签名独立验证的。
There are some scenarios where the use of endpoint IP addresses may be difficult or impossible. These include configurations where network address translation (NAT) devices are in use or when addresses are changed during an association lifetime due to mobility constraints. For Autokey, the only restriction is that the address fields that are visible in the transmitted packet must be the same as those used to construct the autokey list and that these fields be the same as those visible in the received packet. (The use of alternative means, such as Autokey host names (discussed later) or hashes of these names may be a topic for future study.)
在某些情况下，使用端点IP地址可能很困难或不可能。这些配置包括使用网络地址转换（NAT）设备的配置，或者由于移动性限制在关联生存期内更改地址的配置。对于自动密钥，唯一的限制是传输数据包中可见的地址字段必须与用于构造自动密钥列表的地址字段相同，并且这些字段必须与接收数据包中可见的地址字段相同。（使用替代方法，如自动键主机名（稍后讨论）或这些名称的哈希可能是未来研究的主题。）
+-----------+-----------+------+------+ +---------+ +-----+------+
|Src Address|Dst Address|Key ID|Cookie|-->| | |Final|Final |
+-----------+-----------+------+------+ | Session | |Index|Key ID|
| | | | | Key ID | +-----+------+
\|/ \|/ \|/ \|/ | List | | |
************************************* +---------+ \|/ \|/
* COMPUTE HASH * *******************
************************************* *COMPUTE SIGNATURE*
| Index n *******************
\|/ |
+--------+ |
| Next | \|/
| Key ID | +-----------+
+--------+ | Signature |
Index n+1 +-----------+
+-----------+-----------+------+------+ +---------+ +-----+------+
|Src Address|Dst Address|Key ID|Cookie|-->| | |Final|Final |
+-----------+-----------+------+------+ | Session | |Index|Key ID|
| | | | | Key ID | +-----+------+
\|/ \|/ \|/ \|/ | List | | |
************************************* +---------+ \|/ \|/
* COMPUTE HASH * *******************
************************************* *COMPUTE SIGNATURE*
| Index n *******************
\|/ |
+--------+ |
| Next | \|/
| Key ID | +-----------+
+--------+ | Signature |
Index n+1 +-----------+
Figure 3: Constructing the Key List
图3：构建密钥列表
Figure 3 shows how the autokey list and autokey values are computed. The key IDs used in the autokey list consist of a sequence starting with a random 32-bit nonce (autokey seed) greater than or equal to the pivot as the first key ID. The first autokey is computed as above using the given cookie and autokey seed and assigned index 0. The first 32 bits of the result in network byte order become the next key ID. The MD5 hash of the autokey is the key value saved in the key cache along with the key ID. The first 32 bits of the key become the key ID for the next autokey assigned index 1.
Figure 3 shows how the autokey list and autokey values are computed. The key IDs used in the autokey list consist of a sequence starting with a random 32-bit nonce (autokey seed) greater than or equal to the pivot as the first key ID. The first autokey is computed as above using the given cookie and autokey seed and assigned index 0. The first 32 bits of the result in network byte order become the next key ID. The MD5 hash of the autokey is the key value saved in the key cache along with the key ID. The first 32 bits of the key become the key ID for the next autokey assigned index 1.translate error, please retry
Operations continue to generate the entire list. It may happen that a newly generated key ID is less than the pivot or collides with another one already generated (birthday event). When this happens, which occurs only rarely, the key list is terminated at that point. The lifetime of each key is set to expire one poll interval after its scheduled use. In the reference implementation, the list is terminated when the maximum key lifetime is about one hour, so for poll intervals above one hour, a new key list containing only a single entry is regenerated for every poll.
操作将继续生成整个列表。可能会发生新生成的密钥ID小于枢轴或与另一个已生成的密钥ID冲突（生日事件）。当这种情况发生时（这种情况很少发生），键列表将在该点终止。每个密钥的生存期设置为在其计划使用后一个轮询间隔过期。在参考实现中，当最大密钥生存期约为一小时时，列表将终止，因此对于超过一小时的轮询间隔，将为每次轮询重新生成仅包含单个条目的新密钥列表。
+------------------+
| NTP Header and |
| Extension Fields |
+------------------+
| |
\|/ \|/ +---------+
**************** +--------+ | Session |
* COMPUTE HASH *<---| Key ID |<---| Key ID |
**************** +--------+ | List |
| | +---------+
\|/ \|/
+-----------------------------------+
| Message Authentication Code (MAC) |
+-----------------------------------+
+------------------+
| NTP Header and |
| Extension Fields |
+------------------+
| |
\|/ \|/ +---------+
**************** +--------+ | Session |
* COMPUTE HASH *<---| Key ID |<---| Key ID |
**************** +--------+ | List |
| | +---------+
\|/ \|/
+-----------------------------------+
| Message Authentication Code (MAC) |
+-----------------------------------+
Figure 4: Transmitting Messages
图4：传输消息
The index of the last autokey in the list is saved along with the key ID for that entry, collectively called the autokey values. The autokey values are then signed for use later. The list is used in reverse order as shown in Figure 4, so that the first autokey used is the last one generated.
列表中最后一个自动键的索引与该条目的键ID一起保存，统称为自动键值。然后对自动密钥值进行签名，以供以后使用。列表的使用顺序与图4所示相反，因此使用的第一个自动键是生成的最后一个自动键。
The Autokey protocol includes a message to retrieve the autokey values and verify the signature, so that subsequent packets can be validated using one or more hashes that eventually match the last key ID (valid) or exceed the index (invalid). This is called the autokey test in the following and is done for every packet, including those with and without extension fields. In the reference implementation, the most recent key ID received is saved for comparison with the first 32 bits in network byte order of the next following key value. This minimizes the number of hash operations in case a single packet is lost.
自动密钥协议包括一条用于检索自动密钥值和验证签名的消息，以便可以使用最终与最后一个密钥ID（有效）匹配或超过索引（无效）的一个或多个哈希来验证后续数据包。这在下文中称为自动密钥测试，对每个数据包都进行测试，包括有扩展字段和没有扩展字段的数据包。在参考实现中，保存接收到的最新密钥ID，以便与下一个密钥值的网络字节顺序中的前32位进行比较。这样可以在单个数据包丢失的情况下最小化哈希操作的数量。
The Autokey protocol includes a number of request/response exchanges that must be completed in order. In each exchange, a client sends a request message with data and expects a server response message with data. Requests and responses are contained in extension fields, one request or response in each field, as described later. An NTP packet can contain one request message and one or more response messages. The following is a list of these messages.
自动密钥协议包括许多必须按顺序完成的请求/响应交换。在每一次交换中，客户机都会发送一条包含数据的请求消息，并期望收到一条包含数据的服务器响应消息。请求和响应包含在扩展字段中，每个字段中包含一个请求或响应，如下文所述。NTP数据包可以包含一条请求消息和一条或多条响应消息。以下是这些消息的列表。
o Parameter exchange. The request includes the client host name and status word; the response includes the server host name and status word. The status word specifies the digest/signature scheme to use and the identity schemes supported.
o 参数交换。请求包括客户端主机名和状态字；响应包括服务器主机名和状态字。状态字指定要使用的摘要/签名方案以及支持的标识方案。
o Certificate exchange. The request includes the subject name of a certificate; the response consists of a signed certificate with that subject name. If the issuer name is not the same as the subject name, it has been signed by a host one step closer to a trusted host, so certificate retrieval continues for the issuer name. If it is trusted and self-signed, the trail concludes at the trusted host. If nontrusted and self-signed, the host certificate has not yet been signed, so the trail temporarily loops. Completion of this exchange lights the VAL bit as described below.
o 证书交换。请求包括证书的主体名称；响应由具有该使用者名称的签名证书组成。如果颁发者名称与使用者名称不同，则该名称已由主机签名，距离受信任主机更近一步，因此继续对颁发者名称进行证书检索。如果它是受信任的并且是自签名的，则跟踪将在受信任的主机上结束。如果未受信任且自签名，则主机证书尚未签名，因此跟踪将临时循环。完成此交换将点亮VAL位，如下所述。
o Identity exchange. The certificate trail is generally not considered sufficient protection against man-in-the-middle attacks unless additional protection such as the proof-of-possession scheme described in [RFC2875] is available, but this is expensive and requires servers to retain state. Autokey can use one of the challenge/response identity schemes described in Appendix B. Completion of this exchange lights the IFF bit as described below.
o 身份交换。通常认为证书跟踪不足以防止中间人攻击，除非[RFC2875]中描述的占有证明方案等附加保护可用，但这是昂贵的，需要服务器保留状态。自动密钥可以使用附录B中所述的一种质询/响应标识方案。完成此交换将点亮IFF位，如下所述。
o Cookie exchange. The request includes the public key of the server. The response includes the server cookie encrypted with this key. The client uses this value when constructing the key list. Completion of this exchange lights the COOK bit as described below.
o 饼干交换。请求包括服务器的公钥。响应包括使用此密钥加密的服务器cookie。客户端在构造密钥列表时使用此值。完成此交换将点亮COOK位，如下所述。
o Autokey exchange. The request includes either no data or the autokey values in symmetric modes. The response includes the autokey values of the server. These values are used to verify the autokey sequence. Completion of this exchange lights the AUT bit as described below.
o 自动密钥交换。该请求不包含任何数据或对称模式下的自动关键帧值。响应包括服务器的自动密钥值。这些值用于验证自动钥匙序列。完成此交换将点亮AUT位，如下所述。
o Sign exchange. This exchange is executed only when the client has synchronized to a proventic source. The request includes the self-signed client certificate. The server acting as certification authority (CA) interprets the certificate as a X.509v3 certificate request. It extracts the subject, issuer, and extension fields, builds a new certificate with these data along with its own serial number and expiration time, then signs it using its own private key and includes it in the response. The client uses the signed certificate in its own role as server for dependent clients. Completion of this exchange lights the SIGN bit as described below.
o 签名交换。此交换仅在客户端已同步到proventic源时执行。该请求包括自签名客户端证书。充当证书颁发机构（CA）的服务器将证书解释为X.509v3证书请求。它提取subject、issuer和extension字段，使用这些数据以及自己的序列号和过期时间构建新证书，然后使用自己的私钥对其进行签名，并将其包含在响应中。客户端在其自己的角色中将已签名证书用作从属客户端的服务器。交换完成后，符号位将点亮，如下所述。
o Leapseconds exchange. This exchange is executed only when the client has synchronized to a proventic source. This exchange occurs when the server has the leapseconds values, as indicated in the host status word. If so, the client requests the values and compares them with its own values, if available. If the server
o 跳跃秒交换。此交换仅在客户端已同步到proventic源时执行。当服务器具有主机状态字中指示的leapseconds值时，将发生此交换。如果是这样，客户端将请求这些值，并将它们与自己的值（如果可用）进行比较。如果服务器
values are newer than the client values, the client replaces its own with the server values. The client, acting as server, can now provide the most recent values to its dependent clients. In symmetric mode, this results in both peers having the newest values. Completion of this exchange lights the LPT bit as described below.
值比客户机值新，客户机将用服务器值替换自己的值。作为服务器的客户端现在可以向其依赖的客户端提供最新的值。在对称模式下，这将导致两个对等点都具有最新的值。完成此交换将点亮LPT位，如下所述。
Once the certificates and identity have been validated, subsequent packets are validated by digital signatures and the autokey sequence. The association is now proventic with respect to the downstratum trusted host, but is not yet selectable to discipline the system clock. The associations accumulate time values, and the mitigation algorithms continue in the usual way. When these algorithms have culled the falsetickers and cluster outliers and at least three survivors remain, the system clock has been synchronized to a proventic source.
证书和身份验证完成后，后续数据包将通过数字签名和自动密钥序列进行验证。现在，与下层受信任主机的关联是proventic的，但尚未选择该关联来调节系统时钟。关联累积时间值，缓解算法以通常的方式继续。当这些算法剔除了错误标记和集群异常值，并且至少有三个幸存者幸存下来时，系统时钟已同步到普罗旺斯源。
The time values for truechimer sources form a proventic partial ordering relative to the applicable signature timestamps. This raises the interesting issue of how to differentiate between the timestamps of different associations. It might happen, for instance, that the timestamp of some Autokey message is ahead of the system clock by some presumably small amount. For this reason, timestamp comparisons between different associations and between associations and the system clock are avoided, except in the NTP intersection and clustering algorithms and when determining whether a certificate has expired.
truechimer源的时间值相对于适用的签名时间戳形成普罗旺斯偏序。这就提出了一个有趣的问题，即如何区分不同关联的时间戳。例如，可能会发生某些自动键消息的时间戳比系统时钟提前了一小部分的情况。出于这个原因，避免了不同关联之间以及关联与系统时钟之间的时间戳比较，NTP交叉和集群算法中以及确定证书是否过期时除外。
NTP secure groups are used to define cryptographic compartments and security hierarchies. A secure group consists of a number of hosts dynamically assembled as a forest with roots the trusted hosts (THs) at the lowest stratum of the group. The THs do not have to be, but often are, primary (stratum 1) servers. A trusted authority (TA), not necessarily a group host, generates private identity keys for servers and public identity keys for clients at the leaves of the forest. The TA deploys the server keys to the THs and other designated servers using secure means and posts the client keys on a public web site.
NTP安全组用于定义加密分区和安全层次结构。一个安全组由许多主机组成，这些主机动态组合为一个林，其根位于组的最低层，即可信主机（THs）。THs不一定是，但通常是主（第1层）服务器。可信机构（TA）（不一定是组主机）在林的叶子处为服务器生成私有身份密钥，为客户端生成公共身份密钥。TA使用安全手段将服务器密钥部署到THs和其他指定服务器，并将客户端密钥发布到公共网站上。
For Autokey purposes, all hosts belonging to a secure group have the same group name but different host names, not necessarily related to the DNS names. The group name is used in the subject and issuer fields of the TH certificates; the host name is used in these fields for other hosts. Thus, all host certificates are self-signed. During the use of the Autokey protocol, a client requests that the server sign its certificate and caches the result. A certificate
出于自动密钥目的，属于安全组的所有主机都具有相同的组名，但主机名不同，不一定与DNS名称相关。在TH证书的主题和颁发者字段中使用组名称；主机名在这些字段中用于其他主机。因此，所有主机证书都是自签名的。在使用自动密钥协议期间，客户端请求服务器对其证书进行签名并缓存结果。证书
trail is constructed by each host, possibly via intermediate hosts and ending at a TH. Thus, each host along the trail retrieves the entire trail from its server(s) and provides this plus its own signed certificates to its clients.
trail由每个主机构建，可能通过中间主机，并在第。因此，跟踪过程中的每个主机都从其服务器检索整个跟踪，并向其客户机提供该跟踪以及自己的签名证书。
Secure groups can be configured as hierarchies where a TH of one group can be a client of one or more other groups operating at a lower stratum. In one scenario, THs for groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, THs for group CYAN can be clients of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. There are many other scenarios, but all must be configured to include only acyclic certificate trails.
安全组可以配置为层次结构，其中一个组的TH可以是在较低层次上运行的一个或多个其他组的客户端。在一种情况下，红色组和绿色组的THs可以在密码上不同，但两者都是在较低层运营的蓝色组的客户。在另一种情况下，青色组的THs可以是多个黄色和品红组的客户，这两个组都在较低的层中运行。还有许多其他方案，但所有方案都必须配置为仅包括非循环证书跟踪。
In Figure 5, the Alice group consists of THs Alice, which is also the TA, and Carol. Dependent servers Brenda and Denise have configured Alice and Carol, respectively, as their time sources. Stratum 3 server Eileen has configured both Brenda and Denise as her time sources. Public certificates are identified by the subject and signed by the issuer. Note that the server group keys have been previously installed on Brenda and Denise and the client group keys installed on all machines.
在图5中，Alice组由Alice和Carol组成，Alice也是TA。从属服务器Brenda和Denise分别将Alice和Carol配置为它们的时间源。第三层服务器Eileen将Brenda和Denise都配置为她的时间源。公共证书由主体识别并由发行人签署。请注意，服务器组密钥以前已安装在Brenda和Denise上，客户端组密钥已安装在所有计算机上。
+-------------+ +-------------+ +-------------+
| Alice Group | | Brenda | | Denise |
| Alice | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
Certificate | | Alice | | | | Brenda| | | | Denise| |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Subject | | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Issuer | S | | | | | |
+-+-+-+-+-+ | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
| ||Alice|| 3 | | | Alice | | | | Carol | |
Group Key | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ +-------------+ | | Alice*| 2 | | | Carol*| 2 |
|| Group || S | Alice Group | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ | Carol | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
S = step | | Carol | | | | Brenda| | | | Denise| |
* = trusted | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | | | | |
| +=======+ | | +=======+ | | +=======+ |
| ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 |
| +=======+ | | +=======+ | | +=======+ |
+-------------+ +-------------+ +-------------+
Stratum 1 Stratum 2
+-------------+ +-------------+ +-------------+
| Alice Group | | Brenda | | Denise |
| Alice | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
Certificate | | Alice | | | | Brenda| | | | Denise| |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Subject | | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Issuer | S | | | | | |
+-+-+-+-+-+ | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
| ||Alice|| 3 | | | Alice | | | | Carol | |
Group Key | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ +-------------+ | | Alice*| 2 | | | Carol*| 2 |
|| Group || S | Alice Group | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ | Carol | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
S = step | | Carol | | | | Brenda| | | | Denise| |
* = trusted | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | | | | |
| +=======+ | | +=======+ | | +=======+ |
| ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 |
| +=======+ | | +=======+ | | +=======+ |
+-------------+ +-------------+ +-------------+
Stratum 1 Stratum 2
+---------------------------------------------+
| Eileen |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Eileen| | Eileen| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| 4 | Carol | 4 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice*| 2 | Carol*| 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Denise| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | 2 | Carol | 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ |
| | Eileen| |
| +-+-+-+-+ |
| | Eileen| 1 |
| +-+-+-+-+ |
| |
| +=======+ |
| ||Alice|| 3 |
| +=======+ |
+---------------------------------------------+
Stratum 3
+---------------------------------------------+
| Eileen |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Eileen| | Eileen| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| 4 | Carol | 4 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice*| 2 | Carol*| 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Denise| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | 2 | Carol | 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ |
| | Eileen| |
| +-+-+-+-+ |
| | Eileen| 1 |
| +-+-+-+-+ |
| |
| +=======+ |
| ||Alice|| 3 |
| +=======+ |
+---------------------------------------------+
Stratum 3
Figure 5: NTP Secure Groups
图5:NTP安全组
The steps in hiking the certificate trails and verifying identity are as follows. Note the step number in the description matches the step number in the figure.
证书跟踪和身份验证的步骤如下所示。注意：说明中的步骤编号与图中的步骤编号匹配。
1. The girls start by loading the host key, sign key, self-signed certificate, and group key. Each client and server acting as a client starts the Autokey protocol by retrieving the server host name and digest/signature. This is done using the ASSOC exchange described later.
1. 女孩们首先加载主机密钥、签名密钥、自签名证书和组密钥。作为客户端的每个客户端和服务器通过检索服务器主机名和摘要/签名来启动自动密钥协议。这是使用后面描述的ASSOC交换来完成的。
2. They continue to load certificates recursively until a self-signed trusted certificate is found. Brenda and Denise immediately find trusted certificates for Alice and Carol,
2. 它们继续递归加载证书，直到找到自签名的可信证书。Brenda和Denise立即找到Alice和Carol的可信证书，
respectively, but Eileen will loop because neither Brenda nor Denise have their own certificates signed by either Alice or Carol. This is done using the CERT exchange described later.
但艾琳将循环，因为布伦达和丹尼斯都没有自己的证书，由爱丽丝或卡罗尔签名。这是使用后面描述的证书交换来完成的。
3. Brenda and Denise continue with the selected identity schemes to verify that Alice and Carol have the correct group key previously generated by Alice. This is done using one of the identity schemes IFF, GQ, or MV, described later. If this succeeds, each continues in step 4.
3. Brenda和Denise继续使用选定的身份方案，以验证Alice和Carol是否具有Alice先前生成的正确组密钥。这是使用稍后描述的身份方案IFF、GQ或MV之一实现的。如果成功，则在步骤4中继续执行每个步骤。
4. Brenda and Denise present their certificates for signature using the SIGN exchange described later. If this succeeds, either one of or both Brenda and Denise can now provide these signed certificates to Eileen, which may be looping in step 2. Eileen can now verify the trail via either Brenda or Denise to the trusted certificates for Alice and Carol. Once this is done, Eileen can complete the protocol just as Brenda and Denise did.
4. Brenda和Denise使用后面描述的符号交换出示证书以供签名。如果成功，Brenda和Denise中的任何一方或双方现在都可以向Eileen提供这些签名证书，Eileen可能会在步骤2中循环。Eileen现在可以通过Brenda或Denise验证Alice和Carol的可信证书。一旦完成，艾琳就可以像布伦达和丹尼斯一样完成协议。
For various reasons, it may be convenient for a server to have client keys for more than one group. For example, Figure 6 shows three secure groups Alice, Helen, and Carol arranged in a hierarchy. Hosts A, B, C, and D belong to Alice with A and B as her THs. Hosts R and S belong to Helen with R as her TH. Hosts X and Y belong to Carol with X as her TH. Note that the TH for a group is always the lowest stratum and that the hosts of the combined groups form an acyclic graph. Note also that the certificate trail for each group terminates on a TH for that group.
出于各种原因，服务器可以方便地为多个组提供客户端密钥。例如，图6显示了按层次结构排列的三个安全组Alice、Helen和Carol。主机A、B、C和D属于爱丽丝，A和B是她的主机。主持人R和S属于海伦，R是她的主题。主持人X和Y属于卡罗尔，X是她的第四位。请注意，组的TH始终是最低层，并且组合组的主机形成一个非循环图。还请注意，每个组的证书跟踪在该组的第次终止。
***** ***** @@@@@
Stratum 1 * A * * B * @ R @
***** ***** @@@@@
\ / /
\ / /
***** @@@@@ *********
2 * C * @ S @ * Alice *
***** @@@@@ *********
/ \ /
/ \ / @@@@@@@@@
***** ##### @ Helen @
3 * D * # X # @@@@@@@@@
***** #####
/ \ #########
/ \ # Carol #
##### ##### #########
4 # Y # # Z #
##### #####
***** ***** @@@@@
Stratum 1 * A * * B * @ R @
***** ***** @@@@@
\ / /
\ / /
***** @@@@@ *********
2 * C * @ S @ * Alice *
***** @@@@@ *********
/ \ /
/ \ / @@@@@@@@@
***** ##### @ Helen @
3 * D * # X # @@@@@@@@@
***** #####
/ \ #########
/ \ # Carol #
##### ##### #########
4 # Y # # Z #
##### #####
Figure 6: Hierarchical Overlapping Groups
图6：分层重叠组
The intent of the scenario is to provide security separation, so that servers cannot masquerade as clients in other groups and clients cannot masquerade as servers. Assume, for example, that Alice and Helen belong to national standards laboratories and their server keys are used to confirm identity between members of each group. Carol is a prominent corporation receiving standards products and requiring cryptographic authentication. Perhaps under contract, host X belonging to Carol has client keys for both Alice and Helen and server keys for Carol. The Autokey protocol operates for each group separately while preserving security separation. Host X can prove identity in Carol to clients Y and Z, but cannot prove to anybody that it belongs to either Alice or Helen.
该场景的目的是提供安全隔离，以便服务器不能伪装成其他组中的客户端，客户端也不能伪装成服务器。例如，假设Alice和Helen属于国家标准实验室，他们的服务器密钥用于确认每个组成员之间的身份。Carol是一家接受标准产品并要求密码认证的知名公司。也许根据合同，属于Carol的主机X拥有Alice和Helen的客户端密钥以及Carol的服务器密钥。自动密钥协议为每个组分别运行，同时保持安全隔离。主机X可以向客户Y和Z证明Carol中的身份，但不能向任何人证明它属于Alice或Helen。
A digital signature scheme provides secure server authentication, but it does not provide protection against masquerade, unless the server identity is verified by other means. The PKI model requires a server to prove identity to the client by a certificate trail, but independent means such as a driver's license are required for a CA to sign the server certificate. While Autokey supports this model by default, in a hierarchical ad hoc network, especially with server discovery schemes like NTP manycast, proving identity at each rest stop on the trail must be an intrinsic capability of Autokey itself.
数字签名方案提供安全的服务器身份验证，但它不提供防止伪装的保护，除非通过其他方式验证服务器身份。PKI模型要求服务器通过证书跟踪向客户端证明身份，但CA需要独立的手段（如驾驶执照）来签署服务器证书。虽然Autokey默认支持此模型，但在分层自组织网络中，特别是在NTP manycast等服务器发现方案中，在跟踪过程中的每个休息站证明身份必须是Autokey本身的固有功能。
While the identity scheme described in [RFC2875] is based on a ubiquitous Diffie-Hellman infrastructure, it is expensive to generate and use when compared to others described in Appendix B. In principle, an ordinary public key scheme could be devised for this purpose, but the most stringent Autokey design requires that every challenge, even if duplicated, results in a different acceptable response.
虽然[RFC2875]中描述的身份方案基于普遍存在的Diffie-Hellman基础设施，但与附录B中描述的其他方案相比，生成和使用该方案的成本较高。原则上，可以为此目的设计普通公钥方案，但最严格的自动密钥设计要求每个挑战，即使重复，也会产生不同的可接受响应。
1. The scheme must have a relatively long lifetime, certainly longer than a typical certificate, and have no specific lifetime or expiration date. At the time the scheme is used, the host has not yet synchronized to a proventic source, so the scheme cannot depend on time.
1. 该方案必须具有相对较长的生存期，当然比典型证书更长，并且没有特定的生存期或到期日期。在使用方案时，主机尚未同步到proventic源，因此方案不能依赖于时间。
2. As the scheme can be used many times where the data might be exposed to potential intruders, the data must be either nonces or encrypted nonces.
2. 由于该方案可在数据可能暴露于潜在入侵者的情况下多次使用，因此数据必须为nonce或加密nonce。
3. The scheme should allow designated servers to prove identity to designated clients, but not allow clients acting as servers to prove identity to dependent clients.
3. 该方案应允许指定服务器向指定客户端证明身份，但不允许充当服务器的客户端向依赖客户端证明身份。
4. To the greatest extent possible, the scheme should represent a zero-knowledge proof; that is, the client should be able to verify that the server has the correct group key, but without knowing the key itself.
4. 在最大可能的范围内，方案应代表零知识证明；也就是说，客户端应该能够验证服务器是否具有正确的组密钥，但不知道密钥本身。
There are five schemes now implemented in the NTPv4 reference implementation to prove identity: (1) private certificate (PC), (2) trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka Identify Friendly or Foe), (4) a modified Guillou-Quisquater (GQ) algorithm, and (5) a modified Mu-Varadharajan (MV) algorithm. Not all of these provide the same level of protection and one, TC, provides no protection but is included for comparison. The following is a brief summary description of each; details are given in Appendix B.
NTPv4参考实现中现在实现了五种方案来证明身份：（1）私有证书（PC），（2）可信证书（TC），（3）改进的Schnorr算法（IFF aka Identify or Foe），（4）改进的Guillou-Quisquater（GQ）算法，以及（5）改进的Mu-Varadharajan（MV）算法。并非所有这些都提供相同级别的保护，其中一个TC不提供保护，但用于比较。以下是每种方法的简要概述；详情见附录B。
The PC scheme involves a private certificate as group key. The certificate is distributed to all other group members by secure means and is never revealed outside the group. In effect, the private certificate is used as a symmetric key. This scheme is used primarily for testing and development and is not recommended for regular use and is not considered further in this memo.
PC方案涉及一个私有证书作为组密钥。该证书通过安全的方式分发给所有其他组成员，并且从不在组外公开。实际上，私有证书用作对称密钥。此方案主要用于测试和开发，不建议定期使用，本备忘录中不作进一步考虑。
All other schemes involve a conventional certificate trail as described in [RFC5280]. This is the default scheme when an identity scheme is not required. While the remaining identity schemes incorporate TC, it is not by itself considered further in this memo.
所有其他方案都涉及[RFC5280]中所述的常规证书跟踪。当不需要标识方案时，这是默认方案。虽然其余的身份识别方案包含TC，但本备忘录并未对其进行进一步考虑。
The three remaining schemes IFF, GQ, and MV involve a cryptographically strong challenge-response exchange where an intruder cannot deduce the server key, even after repeated observations of multiple exchanges. In addition, the MV scheme is properly described as a zero-knowledge proof, because the client can verify the server has the correct group key without either the server or client knowing its value. These schemes start when the client sends a nonce to the server, which then rolls its own nonce, performs a mathematical operation and sends the results to the client. The client performs another mathematical operation and verifies the results are correct.
其余三种方案IFF、GQ和MV涉及一种加密强质询-响应交换，入侵者即使在多次观察交换后也无法推断服务器密钥。此外，MV方案被恰当地描述为零知识证明，因为客户端可以在服务器或客户端都不知道其值的情况下验证服务器是否具有正确的组密钥。当客户机向服务器发送一个nonce时，这些方案就开始了，然后服务器滚动自己的nonce，执行数学运算并将结果发送给客户机。客户端执行另一个数学运算，并验证结果是否正确。
While public key signatures provide strong protection against misrepresentation of source, computing them is expensive. This invites the opportunity for an intruder to clog the client or server by replaying old messages or originating bogus messages. A client receiving such messages might be forced to verify what turns out to be an invalid signature and consume significant processor resources. In order to foil such attacks, every Autokey message carries a
虽然公钥签名提供了强大的保护，防止源代码被误报，但计算它们的成本很高。这使得入侵者有机会通过重播旧消息或发出虚假消息来阻塞客户端或服务器。接收此类消息的客户端可能会被迫验证结果为无效的签名，并消耗大量处理器资源。为了抵御这种攻击，每个自动密钥消息都带有
timestamp in the form of the NTP seconds when it was created. If the system clock is synchronized to a proventic source, a signature is produced with a valid (nonzero) timestamp. Otherwise, there is no signature and the timestamp is invalid (zero). The protocol detects and discards extension fields with old or duplicate timestamps, before any values are used or signatures are verified.
创建NTP秒形式的时间戳。如果系统时钟与proventic源同步，则生成具有有效（非零）时间戳的签名。否则，没有签名且时间戳无效（零）。在使用任何值或验证签名之前，该协议检测并丢弃具有旧的或重复的时间戳的扩展字段。
Signatures are computed only when cryptographic values are created or modified, which is by design not very often. Extension fields carrying these signatures are copied to messages as needed, but the signatures are not recomputed. There are three signature types:
只有在创建或修改加密值时才计算签名，这在设计上并不常见。携带这些签名的扩展字段会根据需要复制到消息中，但不会重新计算签名。有三种签名类型：
1. Cookie signature/timestamp. The cookie is signed when created by the server and sent to the client.
1. Cookie签名/时间戳。cookie由服务器创建并发送到客户端时进行签名。
2. Autokey signature/timestamp. The autokey values are signed when the key list is created.
2. 自动密钥签名/时间戳。创建密钥列表时，会对自动密钥值进行签名。
3. Public values signature/timestamp. The public key, certificate, and leapsecond values are signed at the time of generation, which occurs when the system clock is first synchronized to a proventic source, when the values have changed and about once per day after that, even if these values have not changed.
3. 公共值签名/时间戳。公钥、证书和leapsecond值在生成时进行签名，这发生在系统时钟首次同步到proventic源时，值发生更改时，之后每天约一次，即使这些值没有更改。
The most recent timestamp received of each type is saved for comparison. Once a signature with a valid timestamp has been received, messages with invalid timestamps or earlier valid timestamps of the same type are discarded before the signature is verified. This is most important in broadcast mode, which could be vulnerable to a clogging attack without this test.
保存每种类型的最近接收的时间戳以供比较。收到具有有效时间戳的签名后，在验证签名之前，将丢弃具有无效时间戳或相同类型的早期有效时间戳的消息。这在广播模式中最为重要，如果不进行此测试，广播模式可能容易受到阻塞攻击。
All cryptographic values used by the protocol are time sensitive and are regularly refreshed. In particular, files containing cryptographic values used by signature and encryption algorithms are regenerated from time to time. It is the intent that file regenerations occur without specific advance warning and without requiring prior distribution of the file contents. While cryptographic data files are not specifically signed, every file is associated with a filestamp showing the NTP seconds at the creation epoch.
协议使用的所有加密值都是时间敏感的，并且会定期刷新。特别是，包含签名和加密算法使用的加密值的文件会不时重新生成。其目的是在不发出特定的预先警告和不要求事先分发文件内容的情况下重新生成文件。虽然加密数据文件没有特别签名，但每个文件都与一个filestamp相关联，该filestamp显示创建时的NTP秒数。
Filestamps and timestamps can be compared in any combination and use the same conventions. It is necessary to compare them from time to time to determine which are earlier or later. Since these quantities have a granularity only to the second, such comparisons are ambiguous if the values are in the same second.
文件戳和时间戳可以以任何组合进行比较，并使用相同的约定。有必要不时地对它们进行比较，以确定哪一个是较早的还是较晚的。由于这些量的粒度仅为秒，因此如果值在同一秒内，则此类比较是不明确的。
It is important that filestamps be proventic data; thus, they cannot be produced unless the producer has been synchronized to a proventic source. As such, the filestamps throughout the NTP subnet represent a partial ordering of all creation epochs and serve as means to expunge old data and ensure new data are consistent. As the data are forwarded from server to client, the filestamps are preserved, including those for certificate and leapseconds values. Packets with older filestamps are discarded before spending cycles to verify the signature.
重要的是，文件戳记是原始数据；因此，除非生产者已与普罗旺斯源同步，否则无法生产它们。因此，整个NTP子网中的文件标记表示所有创建时间的偏序，并用作删除旧数据和确保新数据一致的手段。当数据从服务器转发到客户端时，会保留文件戳记，包括用于证书和值的文件戳记。具有旧文件戳的数据包在花费周期验证签名之前被丢弃。
The NTP protocol has three principal modes of operation: client/ server, symmetric, and broadcast and each has its own Autokey program, or dance. Autokey choreography is designed to be non-intrusive and to require no additional packets other than for regular NTP operations. The NTP and Autokey protocols operate simultaneously and independently. When the dance is complete, subsequent packets are validated by the autokey sequence and thus considered proventic as well. Autokey assumes NTP clients poll servers at a relatively low rate, such as once per minute or slower. In particular, it assumes that a request sent at one poll opportunity will normally result in a response before the next poll opportunity; however, the protocol is robust against a missed or duplicate response.
NTP协议有三种主要的操作模式：客户机/服务器、对称和广播，每种模式都有自己的自动密钥程序或舞蹈。自动密钥编排设计为非侵入式，除了常规NTP操作外，不需要额外的数据包。NTP和自动密钥协议同时独立运行。舞蹈完成后，后续数据包由自动键序列验证，因此也被认为是普罗旺斯的。Autokey假设NTP客户端以相对较低的速率轮询服务器，例如每分钟轮询一次或更慢。特别是，它假设在一个轮询机会发送的请求通常会在下一个轮询机会之前得到响应；然而，该协议对遗漏或重复响应具有鲁棒性。
The server dance was suggested by Steve Kent over lunch some time ago, but considerably modified since that meal. The server keeps no state for each client, but uses a fast algorithm and a 32-bit random private value (server seed) to regenerate the cookie upon arrival of a client packet. The cookie is calculated as the first 32 bits of the autokey computed from the client and server addresses, key ID zero, and the server seed as cookie. The cookie is used for the actual autokey calculation by both the client and server and is thus specific to each client separately.
前段时间，史蒂夫·肯特（Steve Kent）在午餐时建议跳服务员舞，但从那顿饭开始，这种舞蹈有了很大的改进。服务器不为每个客户端保留任何状态，但使用快速算法和32位随机私有值（服务器种子）在客户端数据包到达时重新生成cookie。cookie计算为自动密钥的前32位，该自动密钥是根据客户机和服务器地址、密钥ID 0以及服务器种子作为cookie计算的。cookie用于客户机和服务器的实际自动密钥计算，因此分别针对每个客户机。
In the server dance, the client uses the cookie and each key ID on the key list in turn to retrieve the autokey and generate the MAC. The server uses the same values to generate the message digest and verifies it matches the MAC. It then generates the MAC for the response using the same values, but with the client and server addresses interchanged. The client generates the message digest and verifies it matches the MAC. In order to deflect old replays, the client verifies that the key ID matches the last one sent. In this dance, the sequential structure of the key list is not exploited, but doing it this way simplifies and regularizes the implementation while making it nearly impossible for an intruder to guess the next key ID.
在服务器舞蹈中，客户端依次使用cookie和密钥列表上的每个密钥ID来检索自动密钥并生成MAC。服务器使用相同的值生成消息摘要，并验证它是否与MAC匹配。然后，它使用相同的值为响应生成MAC，但客户端和服务器地址互换。客户端生成消息摘要并验证它是否与MAC匹配。为了转移旧的重播，客户端将验证密钥ID是否与上次发送的密钥ID匹配。在这种舞蹈中，密钥列表的顺序结构没有被利用，但这样做简化并规范了实现，同时使入侵者几乎无法猜测下一个密钥ID。
In the broadcast dance, clients normally do not send packets to the server, except when first starting up. At that time, the client runs the server dance to verify the server credentials and calibrate the propagation delay. The dance requires the association ID of the particular server association, since there can be more than one operating in the same server. For this purpose, the server packet includes the association ID in every response message sent and, when sending the first packet after generating a new key list, it sends the autokey values as well. After obtaining and verifying the autokey values, no extension fields are necessary and the client verifies further server packets using the autokey sequence.
在广播舞蹈中，客户端通常不向服务器发送数据包，除非第一次启动。此时，客户机运行服务器舞蹈以验证服务器凭据并校准传播延迟。舞蹈需要特定服务器关联的关联ID，因为在同一服务器中可以有多个操作。为此，服务器分组在发送的每个响应消息中包括关联ID，并且当在生成新密钥列表之后发送第一个分组时，它也发送自动密钥值。获取并验证自动密钥值后，无需扩展字段，客户端将使用自动密钥序列进一步验证服务器数据包。
The symmetric dance is similar to the server dance and requires only a small amount of state between the arrival of a request and departure of the response. The key list for each direction is generated separately by each peer and used independently, but each is generated with the same cookie. The cookie is conveyed in a way similar to the server dance, except that the cookie is a simple nonce. There exists a possible race condition where each peer sends a cookie request before receiving the cookie response from the other peer. In this case, each peer winds up with two values, one it generated and one the other peer generated. The ambiguity is resolved simply by computing the working cookie as the EXOR of the two values.
对称舞蹈类似于服务器舞蹈，在请求到达和响应离开之间只需要少量的状态。每个方向的密钥列表由每个对等方单独生成并独立使用，但每个都使用相同的cookie生成。cookie的传输方式与服务器舞蹈类似，只是cookie是一个简单的nonce。存在一种可能的竞争条件，即每个对等方在从另一个对等方接收cookie响应之前发送cookie请求。在这种情况下，每个对等点都会有两个值，一个是它生成的，另一个是对等点生成的。通过计算工作cookie作为两个值的EXOR，可以简单地解决歧义。
Once the Autokey dance has completed, it is normally dormant. In all except the broadcast dance, packets are normally sent without extension fields, unless the packet is the first one sent after generating a new key list or unless the client has requested the cookie or autokey values. If for some reason the client clock is stepped, rather than slewed, all cryptographic and time values for all associations are purged and the dances in all associations restarted from scratch. This ensures that stale values never propagate beyond a clock step.
一旦自动键舞蹈完成，它通常处于休眠状态。在除广播舞蹈外的所有舞蹈中，数据包通常在没有扩展字段的情况下发送，除非该数据包是生成新密钥列表后发送的第一个数据包，或者除非客户端已请求cookie或自动密钥值。如果出于某种原因，客户端时钟是步进的，而不是转换的，那么所有关联的所有加密和时间值都将被清除，并且所有关联中的舞蹈将从头开始。这可确保过时值的传播不会超过时钟步长。
The Autokey protocol data unit is the extension field, one or more of which can be piggybacked in the NTP packet. An extension field contains either a request with optional data or a response with optional data. To avoid deadlocks, any number of responses can be included in a packet, but only one request can be. A response is generated for every request, even if the requestor is not synchronized to a proventic source, but most contain meaningful data only if the responder is synchronized to a proventic source. Some requests and most responses carry timestamped signatures. The signature covers the entire extension field, including the timestamp
自动密钥协议数据单元是扩展字段，其中一个或多个可在NTP数据包中携带。扩展字段包含带有可选数据的请求或带有可选数据的响应。为了避免死锁，一个数据包中可以包含任意数量的响应，但只能包含一个请求。即使请求者未与proventic源同步，也会为每个请求生成响应，但大多数响应仅在响应者与proventic源同步时才包含有意义的数据。一些请求和大多数响应带有时间戳签名。签名覆盖整个扩展字段，包括时间戳
and filestamp, where applicable. Only if the packet has correct format, length, and message digest are cycles spent to verify the signature.
和filestamp（如果适用）。只有当数据包具有正确的格式、长度和消息摘要时，才会花费周期来验证签名。
There are currently eight Autokey requests and eight corresponding responses. The NTP packet format is described in [RFC5905] and the extension field format used for these messages is illustrated in Figure 7.
目前有八个自动键请求和八个相应的响应。NTP数据包格式在[RFC5905]中描述，用于这些消息的扩展字段格式如图7所示。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E| Code | Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E| Code | Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Value \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Signature \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Padding (if needed) \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Value \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Signature \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ Padding (if needed) \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: NTPv4 Extension Field Format
图7:NTPv4扩展字段格式
While each extension field is zero-padded to a 4-octet (word) boundary, the entire extension is not word-aligned. The Length field covers the entire extension field, including the Length and Padding fields. While the minimum field length is 8 octets, a maximum field length remains to be established. The reference implementation discards any packet with a field length more than 1024 octets.
虽然每个扩展字段都被零填充到4个八位字节（字）的边界，但整个扩展字段不是字对齐的。长度字段覆盖整个扩展字段，包括长度和填充字段。虽然最小字段长度为8个八位字节，但最大字段长度仍有待确定。参考实现丢弃任何字段长度超过1024个八位字节的数据包。
One or more extension fields follow the NTP packet header and the last followed by the MAC. The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet. If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete. If the remaining length is greater than 22, an extension field is present. If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field.
一个或多个扩展字段紧跟在NTP数据包头之后，最后一个字段紧跟在MAC之后。扩展字段解析器初始化指向NTP数据包头以外的第一个八位字节的指针，并计算到数据包末尾剩余的八位字节数。如果剩余长度为20（128位摘要加上4个八位键ID）或22（160位摘要加上4个八位键ID），则剩余数据为MAC，解析完成。如果剩余长度大于22，则存在扩展字段。如果剩余长度小于8或不是4的倍数，则发生格式错误并丢弃该分组；否则，解析器将指针递增扩展字段长度，然后使用与上面相同的规则来确定是否存在MAC或其他扩展字段。
In Autokey the 8-bit Field Type field is interpreted as the version number, currently 2. For future versions, values 1-7 have been reserved for Autokey; other values may be assigned for other applications. The 6-bit Code field specifies the request or response operation. There are two flag bits: bit 0 is the Response Flag (R) and bit 1 is the Error Flag (E); the Reserved field is unused and should be set to 0. The remaining fields will be described later.
在Autokey中，8位字段类型字段被解释为版本号，当前为2。对于将来的版本，值1-7已保留用于自动键；可以为其他应用程序指定其他值。6位代码字段指定请求或响应操作。有两个标志位：位0是响应标志（R），位1是错误标志（E）；保留字段未使用，应设置为0。其余字段将在后面描述。
In the most common protocol operations, a client sends a request to a server with an operation code specified in the Code field and both the R bit and E bit dim. The server returns a response with the same operation code in the Code field and lights the R bit. The server can also light the E bit in case of error. Note that it is not necessarily a protocol error to send an unsolicited response with no matching request. If the R bit is dim, the client sets the Association ID field to the client association ID, which the server returns for verification. If the two values do not match, the response is discarded as if never sent. If the R bit is lit, the Association ID field is set to the server association ID obtained in the initial protocol exchange. If the Association ID field does not match any mobilized association ID, the request is discarded as if never sent.
在最常见的协议操作中，客户机使用代码字段中指定的操作代码以及R位和E位向服务器发送请求。服务器在代码字段中返回具有相同操作代码的响应，并点亮R位。服务器还可以在出错时点亮E位。请注意，在没有匹配请求的情况下发送未经请求的响应不一定是协议错误。如果R位为dim，则客户机将关联ID字段设置为客户机关联ID，服务器返回该ID进行验证。如果这两个值不匹配，将丢弃响应，就像从未发送一样。如果R位点亮，则关联ID字段将设置为在初始协议交换中获得的服务器关联ID。如果关联ID字段与任何已动员的关联ID不匹配，则请求将被丢弃，就像从未发送一样。
In some cases, not all fields may be present. For requests, until a client has synchronized to a proventic source, signatures are not valid. In such cases, the Timestamp field and Signature Length field (which specifies the length of the Signature) are zero and the Signature field is absent. Some request and error response messages carry no value or signature fields, so in these messages only the first two words (8 octets) are present.
在某些情况下，并非所有字段都存在。对于请求，在客户端与proventic源同步之前，签名无效。在这种情况下，时间戳字段和签名长度字段（指定签名长度）为零，并且签名字段不存在。一些请求和错误响应消息不包含值或签名字段，因此在这些消息中只存在前两个单词（8个八位字节）。
The Timestamp and Filestamp words carry the seconds field of an NTP timestamp. The timestamp establishes the signature epoch of the data field in the message, while the filestamp establishes the generation epoch of the file that ultimately produced the data that is signed.
时间戳和文件戳字携带NTP时间戳的秒字段。时间戳建立消息中数据字段的签名纪元，而filestamp建立最终生成已签名数据的文件的生成纪元。
A signature and timestamp are valid only when the signing host is synchronized to a proventic source; otherwise, the timestamp is zero. A cryptographic data file can only be generated if a signature is possible; otherwise, the filestamp is zero, except in the ASSOC response message, where it contains the server status word.
签名和时间戳只有在签名主机与proventic源同步时才有效；否则，时间戳为零。只有签名是可能的，才能生成加密数据文件；否则，filestamp为零，除非在ASSOC响应消息中包含服务器状态字。
As in all other TCP/IP protocol designs, all data are sent in network byte order. Unless specified otherwise in the descriptions to follow, the data referred to are stored in the Value field. The Value Length field specifies the length of the data in the Value field.
与所有其他TCP/IP协议设计一样，所有数据都以网络字节顺序发送。除非后面的说明中另有规定，否则参考的数据存储在值字段中。值长度字段指定值字段中数据的长度。
A No-operation request (Code 0) does nothing except return an empty response, which can be used as a crypto-ping.
无操作请求（代码0）只返回空响应，该响应可用作加密ping。
An Association Message (Code 1) is used in the parameter exchange to obtain the host name and status word. The request contains the client status word in the Filestamp field and the Autokey host name in the Value field. The response contains the server status word in the Filestamp field and the Autokey host name in the Value field. The Autokey host name is not necessarily the DNS host name. A valid response lights the ENAB bit and possibly others in the association status word.
在参数交换中使用关联消息（代码1）来获取主机名和状态字。请求在Filestamp字段中包含客户机状态字，在Value字段中包含自动密钥主机名。响应在Filestamp字段中包含服务器状态字，在Value字段中包含自动键主机名。自动密钥主机名不一定是DNS主机名。一个有效的响应将点亮ENAB位，可能还会点亮关联状态字中的其他位。
When multiple identity schemes are supported, the host status word determines which ones are available. In server and symmetric modes, the response status word contains bits corresponding to the supported schemes. In all modes, the scheme is selected based on the client identity parameters that are loaded at startup.
当支持多个标识方案时，主机状态字将确定哪些方案可用。在服务器和对称模式下，响应状态字包含与支持的方案相对应的位。在所有模式中，根据启动时加载的客户端标识参数选择方案。
A Certificate Message (Code 2) is used in the certificate exchange to obtain a certificate by subject name. The request contains the subject name; the response contains the certificate encoded in X.509 format with ASN.1 syntax as described in Appendix H.
证书交换中使用证书消息（代码2）按使用者名称获取证书。请求包含主题名称；响应包含以X.509格式编码的证书，其ASN.1语法如附录H所述。
If the subject name in the response does not match the issuer name, the exchange continues with the issuer name replacing the subject name in the request. The exchange continues until a trusted, self-signed certificate is found and lights the CERT bit in the association status word.
如果响应中的主题名称与发卡机构名称不匹配，则交易所继续使用发卡机构名称替换请求中的主题名称。交换将继续，直到找到受信任的自签名证书并点亮关联状态字中的证书位。
The Cookie Message (Code 3) is used in server and symmetric modes to obtain the server cookie. The request contains the host public key encoded with ASN.1 syntax as described in Appendix H. The response contains the cookie encrypted by the public key in the request. A valid response lights the COOKIE bit in the association status word.
Cookie消息（代码3）在服务器和对称模式下用于获取服务器Cookie。请求包含用ASN.1语法编码的主机公钥，如附录H所述。响应包含由请求中的公钥加密的cookie。有效的响应将点亮关联状态字中的COOKIE位。
The Autokey Message (Code 4) is used to obtain the autokey values. The request contains no value for a client or the autokey values for a symmetric peer. The response contains two 32-bit words, the first is the final key ID, while the second is the index of the final key ID. A valid response lights the AUTO bit in the association status word.
自动钥匙信息（代码4）用于获取自动钥匙值。该请求不包含客户端的值，也不包含对称对等方的自动密钥值。响应包含两个32位字，第一个是最终关键字ID，第二个是最终关键字ID的索引。有效的响应将点亮关联状态字中的自动位。
The Leapseconds Values Message (Code 5) is used to obtain the leapseconds values as parsed from the leapseconds table from the National Institute of Standards and Technology (NIST). The request contains no values. The response contains three 32-bit integers: first the NTP seconds of the latest leap event followed by the NTP seconds when the latest NIST table expires and then the TAI offset following the leap event. A valid response lights the LEAP bit in the association status word.
Leapseconds值消息（代码5）用于获取从国家标准与技术研究所（NIST）的Leapseconds表解析的Leapseconds值。请求不包含任何值。响应包含三个32位整数：首先是最新leap事件的NTP秒，然后是最新NIST表过期时的NTP秒，然后是leap事件后的TAI偏移量。有效响应点亮关联状态字中的闰位。
The Sign Message (Code 6) requests that the server sign and return a certificate presented in the request. The request contains the client certificate encoded in X.509 format with ASN.1 syntax as described in Appendix H. The response contains the client certificate signed by the server private key. A valid response lights the SIGN bit in the association status word.
签名消息（代码6）请求服务器签名并返回请求中提供的证书。该请求包含以X.509格式编码的客户端证书，其ASN.1语法如附录H所述。响应包含由服务器私钥签名的客户端证书。有效响应点亮关联状态字中的符号位。
The Identity Messages (Code 7 (IFF), 8 (GQ), or 9 (MV)) contains the client challenge, usually a 160- or 512-bit nonce. The response contains the result of the mathematical operation defined in Appendix B. The Response is encoded in ASN.1 syntax as described in Appendix H. A valid response lights the VRFY bit in the association status word.
标识消息（代码7（IFF）、8（GQ）或9（MV））包含客户端质询，通常为160位或512位nonce。响应包含附录B中定义的数学运算结果。响应采用附录H中描述的ASN.1语法进行编码。有效响应点亮关联状态字中的VRFY位。
This section describes the formal model of the Autokey state machine, its state variables and the state transition functions.
本节介绍自动键状态机的形式化模型、状态变量和状态转换函数。
The server implements a host status word, while each client implements an association status word. These words have the format and content shown in Figure 8. The low-order 16 bits of the status word define the state of the Autokey dance, while the high-order 16 bits specify the Numerical Identifier (NID) as generated by the OpenSSL library of the OID for one of the message digest/signature encryption schemes defined in [RFC3279]. The NID values for the digest/signature algorithms defined in RFC 3279 are as follows:
服务器实现一个主机状态字，而每个客户端实现一个关联状态字。这些单词的格式和内容如图8所示。状态字的低阶16位定义自动密钥舞蹈的状态，而高阶16位指定OID的OpenSSL库为[RFC3279]中定义的消息摘要/签名加密方案之一生成的数字标识符（NID）。RFC 3279中定义的摘要/签名算法的NID值如下：
+------------------------+----------------------+-----+
| Algorithm | OID | NID |
+------------------------+----------------------+-----+
| pkcs-1 | 1.2.840.113549.1.1 | 2 |
| md2 | 1.2.840.113549.2.2 | 3 |
| md5 | 1.2.840.113549.2.5 | 4 |
| rsaEncryption | 1.2.840.113549.1.1.1 | 6 |
| md2WithRSAEncryption | 1.2.840.113549.1.1.2 | 7 |
| md5WithRSAEncryption | 1.2.840.113549.1.1.4 | 8 |
| id-sha1 | 1.3.14.3.2.26 | 64 |
| sha-1WithRSAEncryption | 1.2.840.113549.1.1.5 | 65 |
| id-dsa-wth-sha1 | 1.2.840.10040.4.3 | 113 |
| id-dsa | 1.2.840.10040.4.1 | 116 |
+------------------------+----------------------+-----+
+------------------------+----------------------+-----+
| Algorithm | OID | NID |
+------------------------+----------------------+-----+
| pkcs-1 | 1.2.840.113549.1.1 | 2 |
| md2 | 1.2.840.113549.2.2 | 3 |
| md5 | 1.2.840.113549.2.5 | 4 |
| rsaEncryption | 1.2.840.113549.1.1.1 | 6 |
| md2WithRSAEncryption | 1.2.840.113549.1.1.2 | 7 |
| md5WithRSAEncryption | 1.2.840.113549.1.1.4 | 8 |
| id-sha1 | 1.3.14.3.2.26 | 64 |
| sha-1WithRSAEncryption | 1.2.840.113549.1.1.5 | 65 |
| id-dsa-wth-sha1 | 1.2.840.10040.4.3 | 113 |
| id-dsa | 1.2.840.10040.4.1 | 116 |
+------------------------+----------------------+-----+
Bits 24-31 are reserved for server use, while bits 16-23 are reserved for client use. In the host portion, bits 24-27 specify the available identity schemes, while bits 28-31 specify the server capabilities. There are two additional bits implemented separately.
位24-31保留供服务器使用，而位16-23保留供客户端使用。在主机部分，位24-27指定可用的标识方案，而位28-31指定服务器功能。有两个附加位分别实现。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest / Signature NID | Client | Ident | Host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest / Signature NID | Client | Ident | Host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Status Word
图8：状态字
The host status word is included in the ASSOC request and response messages. The client copies this word to the association status word and then lights additional bits as the dance proceeds. Once enabled, these bits ordinarily never become dark unless a general reset occurs and the protocol is restarted from the beginning.
主机状态字包含在ASSOC请求和响应消息中。客户端将这个字复制到关联状态字，然后随着舞蹈的进行点亮额外的位。一旦启用，这些位通常不会变暗，除非发生一般重置，并且协议从一开始就重新启动。
The host status bits are defined as follows:
主机状态位定义如下：
o ENAB (31) is lit if the server implements the Autokey protocol.
o 如果服务器实现自动密钥协议，则ENAB（31）点亮。
o LVAL (30) is lit if the server has installed leapseconds values, either from the NIST leapseconds file or from another server.
o 如果服务器安装了NIST leapseconds文件或其他服务器中的leapseconds值，则LVAL（30）将点亮。
o Bits (28-29) are reserved - always dark.
o 位（28-29）保留-始终为暗。
o Bits 24-27 select which server identity schemes are available. While specific coding for various schemes is yet to be determined, the schemes available in the reference implementation and described in Appendix B include the following:
o 位24-27选择可用的服务器标识方案。虽然各种方案的具体编码尚未确定，但参考实施中可用的方案以及附录B中描述的方案包括：
* none - Trusted Certificate (TC) Scheme (default).
* 无-受信任证书（TC）方案（默认）。
* PC (27) Private Certificate Scheme.
* PC（27）私人证书计划。
* IFF (26) Schnorr aka Identify-Friendly-or-Foe Scheme.
* IFF（26）Schnorr又名识别友军或敌军方案。
* GQ (25) Guillard-Quisquater Scheme.
* GQ（25）Guillard-Quisquater方案。
* MV (24) Mu-Varadharajan Scheme.
* MV（24）Mu Varadharajan方案。
o The PC scheme is exclusive of any other scheme. Otherwise, the IFF, GQ, and MV bits can be enabled in any combination.
o 个人电脑计划不包括任何其他计划。否则，可以以任何组合启用IFF、GQ和MV位。
The association status bits are defined as follows:
关联状态位定义如下：
o CERT (23): Lit when the trusted host certificate and public key are validated.
o CERT（23）：验证受信任主机证书和公钥时亮起。
o VRFY (22): Lit when the trusted host identity credentials are confirmed.
o VRFY（22）：确认受信任主机标识凭据时亮起。
o PROV (21): Lit when the server signature is verified using its public key and identity credentials. Also called the proventic bit elsewhere in this memo. When enabled, signed values in subsequent messages are presumed proventic.
o PROV（21）：当使用其公钥和身份凭据验证服务器签名时亮起。在本备忘录的其他地方也被称为普罗旺斯比特。启用后，将假定后续消息中的有符号值为无符号。
o COOK (20): Lit when the cookie is received and validated. When lit, key lists with nonzero cookies are generated; when dim, the cookie is zero.
o COOK（20）：收到并验证cookie时点亮。点亮时，生成具有非零cookie的密钥列表；当变暗时，cookie为零。
o AUTO (19): Lit when the autokey values are received and validated. When lit, clients can validate packets without extension fields according to the autokey sequence.
o 自动（19）：收到并验证自动键值时亮起。点亮时，客户端可以根据自动密钥序列验证不带扩展字段的数据包。
o SIGN (18): Lit when the host certificate is signed by the server.
o SIGN（18）：当服务器对主机证书进行签名时亮起。
o LEAP (17): Lit when the leapseconds values are received and validated.
o LEAP（17）：收到并验证LEAP秒值时亮起。
o Bit 16: Reserved - always dark.
o 位16：保留-总是黑暗。
There are three additional bits: LIST, SYNC, and PEER not included in the association status word. LIST is lit when the key list is regenerated and dim when the autokey values have been transmitted. This is necessary to avoid livelock under some conditions. SYNC is lit when the client has synchronized to a proventic source and never dim after that. PEER is lit when the server has synchronized, as indicated in the NTP header, and never dim after that.
还有三个附加位：列表、同步和对等未包含在关联状态字中。当重新生成钥匙列表时，列表点亮；当自动钥匙值已传输时，列表变暗。在某些情况下，这对于避免活锁是必要的。当客户端已同步到proventic源时，“同步”将亮起，此后再也不会变暗。当服务器已同步时（如NTP标头中所示），对等点点亮，此后再也不会变暗。
The following is a list of host state variables.
以下是主机状态变量的列表。
Host Name: The name of the host, by default the string returned by the Unix gethostname() library function. In the reference implementation, this is a configurable value.
主机名：主机名，默认情况下是Unix gethostname（）库函数返回的字符串。在参考实现中，这是一个可配置的值。
Host Status Word: This word is initialized when the host first starts up. The format is described above.
主机状态字：该字在主机首次启动时初始化。格式如上所述。
Host Key: The RSA public/private key pair used to encrypt/ decrypt cookies. This is also the default sign key.
主机密钥：用于加密/解密cookie的RSA公钥/私钥对。这也是默认的签名密钥。
Sign Key: The RSA or Digital Signature Algorithm (DSA) public/private key pair used to encrypt/decrypt signatures when the host key is not used for this purpose.
签名密钥：当主机密钥不用于加密/解密签名时，用于加密/解密签名的RSA或数字签名算法（DSA）公钥/私钥对。
Sign Digest: The message digest algorithm used to compute the message digest before encryption.
签名摘要：用于在加密之前计算消息摘要的消息摘要算法。
IFF Parameters: The parameters used in the optional IFF identity scheme described in Appendix B.
IFF参数：附录B中描述的可选IFF身份方案中使用的参数。
GQ Parameters: The parameters used in the optional GQ identity scheme described in Appendix B.
GQ参数：附录B中描述的可选GQ标识方案中使用的参数。
MV Parameters: The parameters used in the optional MV identity scheme described in Appendix B.
MV参数：附录B中描述的可选MV标识方案中使用的参数。
Server Seed: The private value hashed with the IP addresses and key identifier to construct the cookie.
服务器种子：用IP地址和密钥标识符散列的私有值，用于构造cookie。
CIS: Certificate Information Structure. This structure includes certain information fields from an X.509v3 certificate, together with the certificate itself. The fields extracted include the subject and issuer names, subject public key and message digest algorithm (pointers), and the beginning and end of the valid period in NTP seconds.
CIS：证书信息结构。此结构包括X.509v3证书中的某些信息字段以及证书本身。提取的字段包括主题和颁发者名称、主题公钥和消息摘要算法（指针）以及有效期的开始和结束（以NTP秒为单位）。
The certificate itself is stored as an extension field in network byte order so it can be copied intact to the message. The structure is signed using the sign key and carries the public values timestamp at signature time and the filestamp of the original certificate file. The structure is used by the CERT response message and SIGN request and response messages.
证书本身以网络字节顺序存储为扩展字段，因此可以完整地复制到消息中。该结构使用签名密钥进行签名，并携带签名时的公共值时间戳和原始证书文件的文件戳。该结构由证书响应消息和签名请求及响应消息使用。
A flags field in the CIS determines the status of the certificate. The field is encoded as follows:
CIS中的标志字段确定证书的状态。该字段的编码如下所示：
* TRUST (0x01) - The certificate has been signed by a trusted issuer. If the certificate is self-signed and contains "trustRoot" in the Extended Key Usage field, this bit is lit when the CIS is constructed.
* 信任（0x01）-证书已由受信任的颁发者签名。如果证书是自签名的，并且在扩展密钥使用字段中包含“trustRoot”，则在构造CI时此位点亮。
* SIGN (0x02) - The certificate signature has been verified. If the certificate is self-signed and verified using the contained public key, this bit is lit when the CIS is constructed.
* 签名（0x02）-已验证证书签名。如果证书是自签名的，并使用包含的公钥进行验证，则在构造CI时，此位点亮。
* VALID (0x04) - The certificate is valid and can be used to verify signatures. This bit is lit when a trusted certificate has been found on a valid certificate trail.
* 有效（0x04）-证书有效，可用于验证签名。当在有效的证书跟踪中找到受信任的证书时，此位点亮。
* PRIV (0x08) - The certificate is private and not to be revealed. If the certificate is self-signed and contains "Private" in the Extended Key Usage field, this bit is lit when the CIS is constructed.
* PRIV（0x08）-证书是私有的，不可泄露。如果证书是自签名的，并且在扩展密钥使用字段中包含“Private”，则在构造CI时此位点亮。
* ERROR (0x80) - The certificate is defective and not to be used in any way.
* 错误（0x80）-证书有缺陷，不能以任何方式使用。
Certificate List: CIS structures are stored on the certificate list in order of arrival, with the most recently received CIS placed first on the list. The list is initialized with the CIS for the host certificate, which is read from the host certificate file. Additional CIS entries are added to the list as certificates are obtained from the servers during the certificate exchange. CIS entries are discarded if overtaken by newer ones.
证书列表：CI结构按到达顺序存储在证书列表中，最近收到的CI放在列表的第一位。使用从主机证书文件读取的主机证书的CI初始化列表。在证书交换期间从服务器获取证书时，会将其他CI条目添加到列表中。如果被较新的CI条目取代，则会丢弃CI条目。
The following values are stored as an extension field structure in network byte order so they can be copied intact to the message. They are used to send some Autokey requests and responses. All but the Host Name Values structure are signed using the sign key and all carry the public values timestamp at signature time.
以下值以网络字节顺序存储为扩展字段结构，以便可以完整地复制到消息中。它们用于发送一些自动键请求和响应。除了主机名值结构之外，所有结构都使用签名密钥进行签名，并且在签名时都带有公共值时间戳。
Host Name Values: This is used to send ASSOC request and response messages. It contains the host status word and host name.
主机名值：用于发送ASSOC请求和响应消息。它包含主机状态字和主机名。
Public Key Values: This is used to send the COOKIE request message. It contains the public encryption key used for the COOKIE response message.
公钥值：用于发送COOKIE请求消息。它包含用于COOKIE响应消息的公共加密密钥。
Leapseconds Values: This is used to send the LEAP response message. It contains the leapseconds values in the LEAP message description.
Leapseconds值：用于发送LEAP响应消息。它包含LEAP消息描述中的LEAP秒值。
The following is a list of state variables used by the various dances in all modes.
以下是各种舞蹈在所有模式下使用的状态变量列表。
Association ID: The association ID used in responses. It is assigned when the association is mobilized.
关联ID：响应中使用的关联ID。它是在协会动员时分配的。
Association Status Word: The status word copied from the ASSOC response; subsequently modified by the state machine.
关联状态字：从ASSOC响应复制的状态字；随后由状态机修改。
Subject Name: The server host name copied from the ASSOC response.
主题名称：从ASSOC响应复制的服务器主机名。
Issuer Name: The host name signing the certificate. It is extracted from the current server certificate upon arrival and used to request the next host on the certificate trail.
颁发者名称：签署证书的主机名。它在到达时从当前服务器证书中提取，并用于请求证书跟踪上的下一个主机。
Server Public Key: The public key used to decrypt signatures. It is extracted from the server host certificate.
服务器公钥：用于解密签名的公钥。它是从服务器主机证书中提取的。
Server Message Digest: The digest/signature scheme determined in the parameter exchange.
服务器消息摘要：在参数交换中确定的摘要/签名方案。
Group Key: A set of values used by the identity exchange. It identifies the cryptographic compartment shared by the server and client.
组键：标识交换使用的一组值。它标识服务器和客户端共享的加密分区。
Receive Cookie Values: The cookie returned in a COOKIE response, together with its timestamp and filestamp.
接收Cookie值：在Cookie响应中返回的Cookie及其时间戳和文件戳。
Receive Autokey Values: The autokey values returned in an AUTO response, together with its timestamp and filestamp.
接收自动密钥值：自动响应中返回的自动密钥值及其时间戳和文件戳。
Send Autokey Values: The autokey values with signature and timestamps.
发送自动密钥值：带有签名和时间戳的自动密钥值。
Key List: A sequence of key IDs starting with the autokey seed and each pointing to the next. It is computed, timestamped, and signed at the next poll opportunity when the key list becomes empty.
密钥列表：一系列密钥ID，从自动密钥种子开始，每个都指向下一个。当密钥列表变为空时，它将在下一次轮询机会时进行计算、时间戳和签名。
Current Key Number: The index of the entry on the Key List to be used at the next poll opportunity.
当前键编号：下一次轮询机会时要使用的键列表上的项的索引。
The protocol state machine is very simple but robust. The state is determined by the client status word bits defined above. The state transitions of the three dances are shown below. The capitalized truth values represent the client status bits. All bits are initialized as dark and are lit upon the arrival of a specific response message as detailed above.
协议状态机非常简单，但很健壮。状态由上面定义的客户机状态字位确定。三种舞蹈的状态转换如下所示。大写的真值表示客户机状态位。所有位初始化为暗，并在特定响应消息到达时点亮，如上所述。
The server dance begins when the client sends an ASSOC request to the server. The clock is updated when PREV is lit and the dance ends when LEAP is lit. In this dance, the autokey values are not used, so an autokey exchange is not necessary. Note that the SIGN and LEAP requests are not issued until the client has synchronized to a proventic source. Subsequent packets without extension fields are validated by the autokey sequence. This example and others assumes the IFF identity scheme has been selected in the parameter exchange.
当客户端向服务器发送ASSOC请求时，服务器舞蹈开始。当PREV点亮时，时钟会更新，当LEAP点亮时，舞蹈结束。在这个舞蹈中，不使用自动键值，因此不需要交换自动键。请注意，在客户端与proventic源同步之前，不会发出SIGN和LEAP请求。没有扩展字段的后续数据包由自动密钥序列验证。此示例和其他示例假定已在参数交换中选择IFF标识方案。
1 while (1) {
2 wait_for_next_poll;
3 make_NTP_header;
4 if (response_ready)
5 send_response;
6 if (!ENB) /* parameter exchange */
7 ASSOC_request;
8 else if (!CERT) /* certificate exchange */
9 CERT_request(Host_Name);
10 else if (!IFF) /* identity exchange */
11 IFF_challenge;
12 else if (!COOK) /* cookie exchange */
13 COOKIE_request;
14 else if (!SYNC) /* wait for synchronization */
15 continue;
16 else if (!SIGN) /* sign exchange */
17 SIGN_request(Host_Certificate);
18 else if (!LEAP) /* leapsecond values exchange */
19 LEAP_request;
20 send packet;
21 }
1 while (1) {
2 wait_for_next_poll;
3 make_NTP_header;
4 if (response_ready)
5 send_response;
6 if (!ENB) /* parameter exchange */
7 ASSOC_request;
8 else if (!CERT) /* certificate exchange */
9 CERT_request(Host_Name);
10 else if (!IFF) /* identity exchange */
11 IFF_challenge;
12 else if (!COOK) /* cookie exchange */
13 COOKIE_request;
14 else if (!SYNC) /* wait for synchronization */
15 continue;
16 else if (!SIGN) /* sign exchange */
17 SIGN_request(Host_Certificate);
18 else if (!LEAP) /* leapsecond values exchange */
19 LEAP_request;
20 send packet;
21 }
Figure 9: Server Dance
图9：服务器舞蹈
If the server refreshes the private seed, the cookie becomes invalid. The server responds to an invalid cookie with a crypto-NAK message, which causes the client to restart the protocol from the beginning.
如果服务器刷新私有种子，cookie将无效。服务器用crypto-NAK消息响应无效cookie，这会导致客户端从头重新启动协议。
The broadcast dance is similar to the server dance with the cookie exchange replaced by the autokey values exchange. The broadcast dance begins when the client receives a broadcast packet including an ASSOC response with the server association ID. This mobilizes a client association in order to proventicate the source and calibrate the propagation delay. The dance ends when the LEAP bit is lit, after which the client sends no further packets. Normally, the broadcast server includes an ASSOC response in each transmitted packet. However, when the server generates a new key list, it includes an AUTO response instead.
广播舞蹈类似于服务器舞蹈，cookie交换被autokey值交换替换。当客户端接收到包含服务器关联ID的ASSOC响应的广播数据包时，广播舞蹈开始。这将移动客户端关联，以防止源验证和校准传播延迟。跳跃位点亮时舞蹈结束，之后客户端不再发送进一步的数据包。通常，广播服务器在每个发送的分组中包括ASSOC响应。但是，当服务器生成新的密钥列表时，它会包含一个自动响应。
In the broadcast dance, extension fields are used with every packet, so the cookie is always zero and no cookie exchange is necessary. As in the server dance, the clock is updated when PREV is lit and the
在广播舞蹈中，扩展字段用于每个数据包，因此cookie始终为零，不需要进行cookie交换。与服务器舞蹈一样，当PREV点亮且
dance ends when LEAP is lit. Note that the SIGN and LEAP requests
are not issued until the client has synchronized to a proventic
source. Subsequent packets without extension fields are validated by
the autokey sequence.
1 while (1) {
2 wait_for_next_poll;
3 make_NTP_header;
4 if (response_ready)
5 send_response;
6 if (!ENB) /* parameters exchange */
7 ASSOC_request;
8 else if (!CERT) /* certificate exchange */
9 CERT_request(Host_Name);
10 else if (!IFF) /* identity exchange */
11 IFF_challenge;
12 else if (!AUT) /* autokey values exchange */
13 AUTO_request;
14 else if (!SYNC) /* wait for synchronization */
15 continue;
16 else if (!SIGN) /* sign exchange */
17 SIGN_request(Host_Certificate);
18 else if (!LEAP) /* leapsecond values exchange */
19 LEAP_request;
20 send NTP_packet;
21 }
dance ends when LEAP is lit. Note that the SIGN and LEAP requests
are not issued until the client has synchronized to a proventic
source. Subsequent packets without extension fields are validated by
the autokey sequence.
1 while (1) {
2 wait_for_next_poll;
3 make_NTP_header;
4 if (response_ready)
5 send_response;
6 if (!ENB) /* parameters exchange */
7 ASSOC_request;
8 else if (!CERT) /* certificate exchange */
9 CERT_request(Host_Name);
10 else if (!IFF) /* identity exchange */
11 IFF_challenge;
12 else if (!AUT) /* autokey values exchange */
13 AUTO_request;
14 else if (!SYNC) /* wait for synchronization */
15 continue;
16 else if (!SIGN) /* sign exchange */
17 SIGN_request(Host_Certificate);
18 else if (!LEAP) /* leapsecond values exchange */
19 LEAP_request;
20 send NTP_packet;
21 }
Figure 10: Broadcast Dance
图10：广播舞蹈
If a packet is lost and the autokey sequence is broken, the client hashes the current autokey until either it matches the previous autokey or the number of hashes exceeds the count given in the autokey values. If the latter, the client sends an AUTO request to retrieve the autokey values. If the client receives a crypto-NAK during the dance, or if the association ID changes, the client restarts the protocol from the beginning.
如果数据包丢失且自动密钥序列中断，客户端将对当前自动密钥进行散列，直到它与以前的自动密钥匹配，或者散列数超过自动密钥值中给定的计数。如果是后者，客户端将发送一个自动请求来检索自动密钥值。如果客户端在舞蹈过程中收到加密NAK，或者如果关联ID更改，则客户端从一开始就重新启动协议。
The symmetric dance is intricately choreographed. It begins when the active peer sends an ASSOC request to the passive peer. The passive peer mobilizes an association and both peers step a three-way dance where each peer completes a parameter exchange with the other. Until one of the peers has synchronized to a proventic source (which could be the other peer) and can sign messages, the other peer loops waiting for a valid timestamp in the ensuing CERT response.
对称舞是精心编排的。它从主动对等方向被动对等方发送ASSOC请求时开始。被动对等方激活一个关联，两个对等方进行三方舞蹈，其中每个对等方完成与另一个对等方的参数交换。在其中一个对等方已同步到proventic源（可能是另一个对等方）并对消息进行签名之前，另一个对等方循环等待后续CERT响应中的有效时间戳。
1 while (1) {
2 wait_for_next_poll;
3 make_NTP_header;
4 if (!ENB) /* parameters exchange */
5 ASSOC_request;
6 else if (!CERT) /* certificate exchange */
7 CERT_request(Host_Name);
8 else if (!IFF) /* identity exchange */
9 IFF_challenge;
10 else if (!COOK && PEER) /* cookie exchange */
11 COOKIE_request);
12 else if (!AUTO) /* autokey values exchange */
13 AUTO_request;
14 else if (LIST) /* autokey values response */
15 AUTO_response;
16 else if (!SYNC) /* wait for synchronization */
17 continue;
18 else if (!SIGN) /* sign exchange */
19 SIGN_request;
20 else if (!LEAP) /* leapsecond values exchange */
21 LEAP_request;
22 send NTP_packet;
23 }
1 while (1) {
2 wait_for_next_poll;
3 make_NTP_header;
4 if (!ENB) /* parameters exchange */
5 ASSOC_request;
6 else if (!CERT) /* certificate exchange */
7 CERT_request(Host_Name);
8 else if (!IFF) /* identity exchange */
9 IFF_challenge;
10 else if (!COOK && PEER) /* cookie exchange */
11 COOKIE_request);
12 else if (!AUTO) /* autokey values exchange */
13 AUTO_request;
14 else if (LIST) /* autokey values response */
15 AUTO_response;
16 else if (!SYNC) /* wait for synchronization */
17 continue;
18 else if (!SIGN) /* sign exchange */
19 SIGN_request;
20 else if (!LEAP) /* leapsecond values exchange */
21 LEAP_request;
22 send NTP_packet;
23 }
Figure 11: Symmetric Dance
图11：对称舞蹈
Once a peer has synchronized to a proventic source, it includes timestamped signatures in its messages. The other peer, which has been stalled waiting for valid timestamps, now mates the dance. It retrieves the now nonzero cookie using a cookie exchange and then the updated autokey values using an autokey exchange.
一旦对等方与proventic源同步，它就会在其消息中包含带时间戳的签名。另一个同伴被暂停等待有效的时间戳，现在与舞蹈配对。它使用cookie交换检索现在的非零cookie，然后使用自动密钥交换检索更新的自动密钥值。
As in the broadcast dance, if a packet is lost and the autokey sequence broken, the peer hashes the current autokey until either it matches the previous autokey or the number of hashes exceeds the count given in the autokey values. If the latter, the client sends an AUTO request to retrieve the autokey values. If the peer receives a crypto-NAK during the dance, or if the association ID changes, the peer restarts the protocol from the beginning.
与广播舞蹈一样，如果数据包丢失且自动密钥序列中断，对等方将对当前自动密钥进行散列，直到它与前一个自动密钥匹配，或者散列数超过自动密钥值中给定的计数。如果是后者，客户端将发送一个自动请求来检索自动密钥值。如果对等方在舞蹈期间接收到加密NAK，或者如果关联ID发生变化，则对等方从一开始就重新启动协议。
The Autokey protocol state machine includes provisions for various kinds of error conditions that can arise due to missing files, corrupted data, protocol violations, and packet loss or misorder, not to mention hostile intrusion. This section describes how the protocol responds to reachability and timeout events that can occur due to such errors.
自动密钥协议状态机包括针对因文件丢失、数据损坏、协议违反、数据包丢失或顺序错误（更不用说恶意入侵）而可能出现的各种错误情况的规定。本节描述协议如何响应由于此类错误而可能发生的可达性和超时事件。
A persistent NTP association is mobilized by an entry in the configuration file, while an ephemeral association is mobilized upon the arrival of a broadcast or symmetric active packet with no matching association. Subsequently, a general reset reinitializes all association variables to the initial state when first mobilized. In addition, if the association is ephemeral, the association is demobilized and all resources acquired are returned to the system.
持久NTP关联由配置文件中的一个条目激活，而临时关联则在广播或对称活动数据包到达时激活，没有匹配的关联。随后，常规重置会在首次启动时将所有关联变量重新初始化为初始状态。此外，如果关联是短暂的，则该关联将被解除，并将获取的所有资源返回到系统。
Every NTP association has two variables that maintain the liveness state of the protocol, the 8-bit reach register and the unreach counter defined in [RFC5905]. At every poll interval, the reach register is shifted left, the low order bit is dimmed and the high order bit is lost. At the same time, the unreach counter is incremented by one. If an arriving packet passes all authentication and sanity checks, the rightmost bit of the reach register is lit and the unreach counter is set to zero. If any bit in the reach register is lit, the server is reachable; otherwise, it is unreachable.
每个NTP关联都有两个变量来维持协议的活动状态，即[RFC5905]中定义的8位到达寄存器和未读计数器。在每个轮询间隔，到达寄存器向左移位，低阶位变暗，高阶位丢失。同时，未读计数器增加1。如果到达的数据包通过了所有身份验证和健全性检查，则到达寄存器最右边的位将点亮，未到达计数器将设置为零。如果reach寄存器中的任何位点亮，则服务器是可访问的；否则，它是无法到达的。
When the first poll is sent from an association, the reach register and unreach counter are set to zero. If the unreach counter reaches 16, the poll interval is doubled. In addition, if association is persistent, it is demobilized. This reduces the network load for packets that are unlikely to elicit a response.
从关联发送第一次轮询时，到达寄存器和未到达计数器设置为零。如果未读计数器达到16，则轮询间隔加倍。此外，如果关联是持久的，则它将被解除。这减少了不太可能引起响应的数据包的网络负载。
At each state in the protocol, the client expects a particular response from the server. A request is included in the NTP packet sent at each poll interval until a valid response is received or a general reset occurs, in which case the protocol restarts from the beginning. A general reset also occurs for an association when an unrecoverable protocol error occurs. A general reset occurs for all associations when the system clock is first synchronized or the clock is stepped or when the server seed is refreshed.
在协议中的每个状态下，客户机都希望服务器做出特定的响应。在每个轮询间隔发送的NTP数据包中包含一个请求，直到收到有效响应或发生一般重置，在这种情况下，协议从一开始就重新启动。当发生不可恢复的协议错误时，关联也会发生常规重置。当系统时钟首次同步或时钟步进或服务器种子刷新时，所有关联都会发生常规重置。
There are special cases designed to quickly respond to broken associations, such as when a server restarts or refreshes keys. Since the client cookie is invalidated, the server rejects the next client request and returns a crypto-NAK packet. Since the crypto-NAK has no MAC, the problem for the client is to determine whether it is legitimate or the result of intruder mischief. In order to reduce the vulnerability in such cases, the crypto-NAK, as well as all responses, is believed only if the result of a previous packet sent by the client and not a replay, as confirmed by the NTP on-wire protocol. While this defense can be easily circumvented by a man-in-the-middle, it does deflect other kinds of intruder warfare.
有一些特殊情况设计用于快速响应断开的关联，例如当服务器重新启动或刷新密钥时。由于客户机cookie无效，服务器拒绝下一个客户机请求并返回加密NAK数据包。由于crypto-NAK没有MAC，客户端的问题是确定它是合法的还是入侵者恶意破坏的结果。为了减少这种情况下的漏洞，只有当客户端发送的前一个数据包的结果而不是NTP在线协议确认的重播结果时，才会相信加密NAK以及所有响应。虽然这种防御很容易被中间的人绕过，但它确实可以转移其他类型的入侵战。
There are a number of situations where some event happens that causes the remaining autokeys on the key list to become invalid. When one of these situations happens, the key list and associated autokeys in
在许多情况下，某些事件会导致键列表上剩余的自动键无效。当出现这些情况之一时，将显示“关键点列表”和关联的自动关键点
the key cache are purged. A new key list, signature, and timestamp are generated when the next NTP message is sent, assuming there is one. The following is a list of these situations:
密钥缓存将被清除。当发送下一条NTP消息时，会生成一个新的密钥列表、签名和时间戳（假设有）。以下是这些情况的列表：
1. When the cookie value changes for any reason.
1. 当cookie值因任何原因更改时。
2. When the poll interval is changed. In this case, the calculated expiration times for the keys become invalid.
2. 更改轮询间隔时。在这种情况下，计算出的密钥过期时间将无效。
3. If a problem is detected when an entry is fetched from the key list. This could happen if the key was marked non-trusted or timed out, either of which implies a software bug.
3. 如果从密钥列表中提取条目时检测到问题。如果密钥被标记为不可信或超时，则可能发生这种情况，这两种情况都意味着软件错误。
This section discusses the most obvious security vulnerabilities in the various Autokey dances. In the following discussion, the cryptographic algorithms and private values themselves are assumed secure; that is, a brute force cryptanalytic attack will not reveal the host private key, sign private key, cookie value, identity parameters, server seed or autokey seed. In addition, an intruder will not be able to predict random generator values.
本节讨论各种自动密钥舞蹈中最明显的安全漏洞。在下面的讨论中，密码算法和私有值本身被假定为安全的；也就是说，暴力密码分析攻击不会泄露主机私钥、签名私钥、cookie值、身份参数、服务器种子或自动密钥种子。此外，入侵者将无法预测随机生成器值。
While the protocol has not been subjected to a formal analysis, a few preliminary assertions can be made. In the client/server and symmetric dances, the underlying NTP on-wire protocol is resistant to lost, duplicate, and bogus packets, even if the clock is not synchronized, so the protocol is not vulnerable to a wiretapper attack. The on-wire protocol is resistant to replays of both the client request packet and the server reply packet. A man-in-the-middle attack, even if it could simulate a valid cookie, could not prove identity.
虽然该协议尚未经过正式分析，但可以做出一些初步断言。在客户机/服务器和对称网络中，即使时钟不同步，底层NTP on wire协议也能抵抗丢失、重复和伪造的数据包，因此该协议不易受到Wiretaper攻击。在线协议抵抗客户端请求数据包和服务器应答数据包的重播。中间人攻击，即使可以模拟有效的cookie，也无法证明身份。
In the broadcast dance, the client begins with a volley in client/ server mode to obtain the autokey values and signature, so has the same protection as in that mode. When continuing in receive-only mode, a wiretapper cannot produce a key list with valid signed autokey values. If it replays an old packet, the client will reject it by the timestamp check. The most it can do is manufacture a future packet causing clients to repeat the autokey hash operations until exceeding the maximum key number. If this happens the broadcast client temporarily reverts to client mode to refresh the autokey values.
在广播舞蹈中，客户机以客户机/服务器模式下的截击开始，以获取自动密钥值和签名，因此具有与该模式下相同的保护。在仅接收模式下继续时，wiretapper无法生成具有有效签名自动密钥值的密钥列表。如果它重放旧数据包，客户端将通过时间戳检查拒绝它。它所能做的最多就是制造一个未来的数据包，使客户端重复自动密钥散列操作，直到超过最大密钥数。如果发生这种情况，广播客户端将临时恢复到客户端模式以刷新自动密钥值。
By assumption, a man-in-the-middle attacker that intercepts a packet cannot break the wire or delay an intercepted packet. If this assumption is removed, the middleman could intercept a broadcast packet and replace the data and message digest without detection by the clients.
根据假设，拦截数据包的中间人攻击者无法断开线路或延迟被拦截的数据包。如果去掉这个假设，中间人就可以截获广播包并替换数据和消息摘要，而无需客户端检测。
As mentioned previously in this memo, the TC identity scheme is vulnerable to a man-in-the-middle attack where an intruder could create a bogus certificate trail. To foil this kind of attack, either the PC, IFF, GQ, or MV identity schemes must be used.
如本备忘录前面所述，TC身份方案容易受到中间人攻击，入侵者可能会创建虚假证书线索。为了抵御这种攻击，必须使用PC、IFF、GQ或MV身份方案。
A client instantiates cryptographic variables only if the server is synchronized to a proventic source. A server does not sign values or generate cryptographic data files unless synchronized to a proventic source. This raises an interesting issue: how does a client generate proventic cryptographic files before it has ever been synchronized to a proventic source? (Who shaves the barber if the barber shaves everybody in town who does not shave himself?) In principle, this paradox is resolved by assuming the primary (stratum 1) servers are proventicated by external phenomenological means.
只有当服务器与proventic源同步时，客户端才会实例化加密变量。除非与proventic源同步，否则服务器不会对值进行签名或生成加密数据文件。这引发了一个有趣的问题：客户端在与proventic源同步之前如何生成proventic加密文件？（如果理发师给城里所有不自己刮胡子的人刮胡子，谁给理发师刮胡子？）原则上，通过假设主要（第1层）服务器通过外部现象学手段进行验证，可以解决这一矛盾。
A self-induced clogging incident cannot happen, since signatures are computed only when the data have changed and the data do not change very often. For instance, the autokey values are signed only when the key list is regenerated, which happens about once an hour, while the public values are signed only when one of them is updated during a dance or the server seed is refreshed, which happens about once per day.
自诱导堵塞事件不会发生，因为只有当数据发生变化且数据不经常变化时，才会计算特征。例如，仅当重新生成密钥列表（大约每小时一次）时，才会对自动密钥值进行签名，而仅当其中一个值在舞蹈期间更新或服务器种子刷新（大约每天一次）时，才会对公共值进行签名。
There are two clogging vulnerabilities exposed in the protocol design: an encryption attack where the intruder hopes to clog the victim server with needless cryptographic calculations, and a decryption attack where the intruder attempts to clog the victim client with needless cryptographic calculations. Autokey uses public key cryptography and the algorithms that perform these functions consume significant resources.
协议设计中暴露了两个阻塞漏洞：一个是加密攻击，入侵者希望用不必要的密码计算阻塞受害者服务器；另一个是解密攻击，入侵者试图用不必要的密码计算阻塞受害者客户端。自动密钥使用公钥加密，执行这些功能的算法消耗大量资源。
In client/server and peer dances, an encryption hazard exists when a wiretapper replays prior cookie request messages at speed. There is no obvious way to deflect such attacks, as the server retains no state between requests. Replays of cookie request or response messages are detected and discarded by the client on-wire protocol.
在客户机/服务器和对等机中，当有线窃听器以高速重放之前的cookie请求消息时，存在加密危险。没有明显的方法来转移这种攻击，因为服务器在请求之间不保留任何状态。cookie请求或响应消息的重播被客户端在线协议检测到并丢弃。
In broadcast mode, a decryption hazard exists when a wiretapper replays autokey response messages at speed. Once synchronized to a proventic source, a legitimate extension field with timestamp the
在广播模式下，当窃听器以高速重放自动密钥响应消息时，存在解密危险。一旦同步到proventic源，一个带有时间戳的合法扩展字段
same as or earlier than the most recently received of that type is immediately discarded. This foils a man-in-the-middle cut-and-paste attack using an earlier response, for example. A legitimate extension field with timestamp in the future is unlikely, as that would require predicting the autokey sequence. However, this causes the client to refresh and verify the autokey values and signature.
与该类型的最近接收的相同或更早的将立即被丢弃。例如，这会挫败中间人使用早期响应进行剪切粘贴攻击。将来不太可能使用带有时间戳的合法扩展字段，因为这需要预测自动密钥序列。但是，这会导致客户端刷新并验证自动密钥值和签名。
A determined attacker can destabilize the on-wire protocol or an Autokey dance in various ways by replaying old messages before the client or peer has synchronized for the first time. For instance, replaying an old symmetric mode message before the peers have synchronize will prevent the peers from ever synchronizing. Replaying out of order Autokey messages in any mode during a dance could prevent the dance from ever completing. There is nothing new in these kinds of attack; a similar vulnerability even exists in TCP.
确定的攻击者可以通过在客户端或对等方首次同步之前重播旧消息，以各种方式破坏在线协议或自动密钥舞蹈。例如，在对等方进行同步之前重播旧的对称模式消息将阻止对等方进行同步。在舞蹈过程中，以任何模式重放无序的自动键信息都可能会阻止舞蹈完成。这类攻击没有什么新鲜事；TCP中甚至存在类似的漏洞。
The IANA has added the following entries to the NTP Extensions Field Types registry:
IANA已将以下条目添加到NTP扩展字段类型注册表：
+------------+------------------------------------------+
| Field Type | Meaning |
+------------+------------------------------------------+
| 0x0002 | No-Operation Request |
| 0x8002 | No-Operation Response |
| 0xC002 | No-Operation Error Response |
| 0x0102 | Association Message Request |
| 0x8102 | Association Message Response |
| 0xC102 | Association Message Error Response |
| 0x0202 | Certificate Message Request |
| 0x8202 | Certificate Message Response |
| 0xC202 | Certificate Message Error Response |
| 0x0302 | Cookie Message Request |
| 0x8302 | Cookie Message Response |
| 0xC302 | Cookie Message Error Response |
| 0x0402 | Autokey Message Request |
| 0x8402 | Autokey Message Response |
| 0xC402 | Autokey Message Error Response |
| 0x0502 | Leapseconds Value Message Request |
| 0x8502 | Leapseconds Value Message Response |
| 0xC502 | Leapseconds Value Message Error Response |
| 0x0602 | Sign Message Request |
| 0x8602 | Sign Message Response |
| 0xC602 | Sign Message Error Response |
| 0x0702 | IFF Identity Message Request |
| 0x8702 | IFF Identity Message Response |
| 0xC702 | IFF Identity Message Error Response |
| 0x0802 | GQ Identity Message Request |
| 0x8802 | GQ Identity Message Response |
| 0xC802 | GQ Identity Message Error Response |
| 0x0902 | MV Identity Message Request |
| 0x8902 | MV Identity Message Response |
| 0xC902 | MV Identity Message Error Response |
+------------+------------------------------------------+
+------------+------------------------------------------+
| Field Type | Meaning |
+------------+------------------------------------------+
| 0x0002 | No-Operation Request |
| 0x8002 | No-Operation Response |
| 0xC002 | No-Operation Error Response |
| 0x0102 | Association Message Request |
| 0x8102 | Association Message Response |
| 0xC102 | Association Message Error Response |
| 0x0202 | Certificate Message Request |
| 0x8202 | Certificate Message Response |
| 0xC202 | Certificate Message Error Response |
| 0x0302 | Cookie Message Request |
| 0x8302 | Cookie Message Response |
| 0xC302 | Cookie Message Error Response |
| 0x0402 | Autokey Message Request |
| 0x8402 | Autokey Message Response |
| 0xC402 | Autokey Message Error Response |
| 0x0502 | Leapseconds Value Message Request |
| 0x8502 | Leapseconds Value Message Response |
| 0xC502 | Leapseconds Value Message Error Response |
| 0x0602 | Sign Message Request |
| 0x8602 | Sign Message Response |
| 0xC602 | Sign Message Error Response |
| 0x0702 | IFF Identity Message Request |
| 0x8702 | IFF Identity Message Response |
| 0xC702 | IFF Identity Message Error Response |
| 0x0802 | GQ Identity Message Request |
| 0x8802 | GQ Identity Message Response |
| 0xC802 | GQ Identity Message Error Response |
| 0x0902 | MV Identity Message Request |
| 0x8902 | MV Identity Message Response |
| 0xC902 | MV Identity Message Error Response |
+------------+------------------------------------------+
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[DASBUCH] Mills, D., "Computer Network Time Synchronization - the Network Time Protocol", 2006.
[DASBUCH]Mills，D.，“计算机网络时间同步-网络时间协议”，2006年。
[GUILLOU] Guillou, L. and J. Quisquatar, "A "paradoxical" identity-based signature scheme resulting from zero-knowledge", 1990.
[GUILLOU]GUILLOU，L.和J.Quisquatar，“一个基于零知识的“矛盾的”基于身份的签名方案”，1990年。
[MV] Mu, Y. and V. Varadharajan, "Robust and secure broadcasting", 2001.
[MV]Mu，Y.和V.Varadharajan，“稳健和安全的广播”，2001年。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522]Karn，P.和W.Simpson，“Photuris：会话密钥管理协议”，RFC 2522，1999年3月。
[RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, July 2000.
[RFC2875]Prafullchandra，H.和J.Schaad，“Diffie-Hellman占有算法证明”，RFC 28752000年7月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210]Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 42102005年9月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[SCHNORR] Schnorr, C., "Efficient signature generation for smart cards", 1991.
[SCHNORR]SCHNORR，C.，“智能卡的有效签名生成”，1991年。
[STINSON] Stinson, D., "Cryptography - Theory and Practice", 1995.
[STINSON]STINSON，D.，“密码学-理论与实践”，1995年。
Appendix A. Timestamps, Filestamps, and Partial Ordering
附录A.时间戳、文件戳和偏序
When the host starts, it reads the host key and host certificate files, which are required for continued operation. It also reads the sign key and leapseconds values, when available. When reading these files, the host checks the file formats and filestamps for validity; for instance, all filestamps must be later than the time the UTC timescale was established in 1972 and the certificate filestamp must not be earlier than its associated sign key filestamp. At the time the files are read, the host is not synchronized, so it cannot determine whether the filestamps are bogus other than by using these simple checks. It must not produce filestamps or timestamps until synchronized to a proventic source.
当主机启动时，它读取主机密钥和主机证书文件，这是继续操作所必需的。如果可用，它还会读取符号键和leapseconds值。读取这些文件时，主机会检查文件格式和文件标记的有效性；例如，所有文件标记必须晚于1972年UTC时间刻度建立的时间，并且证书文件标记不得早于其关联的签名密钥文件标记。在读取文件时，主机没有同步，因此除了使用这些简单的检查之外，它无法确定文件是否是伪造的。在与proventic源同步之前，它不能生成文件戳或时间戳。
In the following, the relation A --> B is Lamport's "happens before" relation, which is true if event A happens before event B. When timestamps are compared to timestamps, the relation is false if A <--> B; that is, false if the events are simultaneous. For timestamps compared to filestamps and filestamps compared to filestamps, the relation is true if A <--> B. Note that the current time plays no part in these assertions except in (6) below; however, the NTP protocol itself ensures a correct partial ordering for all current time values.
在下文中，关系A-->B是Lamport的“发生在”关系，如果事件A发生在事件B之前，则该关系为真。当时间戳与时间戳进行比较时，如果A<-->B，则该关系为假；也就是说，如果事件同时发生，则为false。对于与filestamp相比的时间戳和与filestamp相比的filestamp，如果A<-->B，则关系为真。请注意，当前时间在这些断言中不起任何作用，除非在下面的（6）中；但是，NTP协议本身确保所有当前时间值的正确偏序。
The following assertions apply to all relevant responses:
以下断言适用于所有相关响应：
1. The client saves the most recent timestamp T0 and filestamp F0 for the respective signature type. For every received message carrying timestamp T1 and filestamp F1, the message is discarded unless T0 --> T1 and F0 --> F1. The requirement that T0 --> T1 is the primary defense against replays of old messages.
1. 客户端保存相应签名类型的最新时间戳T0和文件戳F0。对于每个接收到的带有时间戳T1和文件戳F1的消息，除非T0-->T1和F0-->F1，否则将丢弃该消息。T0-->T1是防止重放旧消息的主要防御措施的要求。
2. For timestamp T and filestamp F, F --> T; that is, the filestamp must happen before the timestamp. If not, this could be due to a file generation error or a significant error in the system clock time.
2. 对于时间戳T和文件戳F，F-->T；也就是说，filestamp必须发生在时间戳之前。如果不是，这可能是由于文件生成错误或系统时钟时间中的重大错误造成的。
3. For sign key filestamp S, certificate filestamp C, cookie timestamp D and autokey timestamp A, S --> C --> D --> A; that is, the autokey must be generated after the cookie, the cookie after the certificate, and the certificate after the sign key.
3. 对于签名密钥文件戳S、证书文件戳C、cookie时间戳D和自动密钥时间戳A，S-->C-->D-->A；也就是说，必须在cookie之后生成自动密钥，在证书之后生成cookie，在签名密钥之后生成证书。
4. For sign key filestamp S and certificate filestamp C specifying begin time B and end time E, S --> C--> B --> E; that is, the valid period must not be retroactive.
4. 对于指定开始时间B和结束时间E的签名密钥文件夯实S和证书文件夯实C，S-->C-->B-->E；也就是说，有效期不得追溯。
5. A certificate for subject S signed by issuer I and with filestamp C1 obsoletes, but does not necessarily invalidate, another certificate with the same subject and issuer but with filestamp C0, where C0 --> C1.
5. 由颁发者I签署的具有filestamp C1的主体S证书将废弃但不一定使具有相同主体和颁发者但具有filestamp C0的另一证书失效，其中C0-->C1。
6. A certificate with begin time B and end time E is invalid and cannot be used to verify signatures if t --> B or E --> t, where t is the current proventic time. Note that the public key previously extracted from the certificate continues to be valid for an indefinite time. This raises the interesting possibility where a truechimer server with expired certificate or a falseticker with valid certificate are not detected until the client has synchronized to a proventic source.
6. 具有开始时间B和结束时间E的证书无效，如果t-->B或E-->t，则不能使用该证书来验证签名，其中t是当前时间。请注意，以前从证书中提取的公钥在无限期内仍然有效。这就提出了一种有趣的可能性，即在客户端与proventic源同步之前，不会检测到具有过期证书的truechimer服务器或具有有效证书的Falsticker。
There are five identity schemes in the NTPv4 reference implementation: (1) private certificate (PC), (2) trusted certificate (TC), (3) a modified Schnorr algorithm (IFF - Identify Friend or Foe), (4) a modified Guillou-Quisquater (GQ) algorithm, and (5) a modified Mu-Varadharajan (MV) algorithm.
NTPv4参考实现中有五种身份方案：（1）私有证书（PC），（2）可信证书（TC），（3）改进的Schnorr算法（IFF-识别朋友或敌人），（4）改进的Guillou-Quisquater（GQ）算法，以及（5）改进的Mu-Varadharajan（MV）算法。
The PC scheme is intended for testing and development and not recommended for general use. The TC scheme uses a certificate trail, but not an identity scheme. The IFF, GQ, and MV identity schemes use a cryptographically strong challenge-response exchange where an intruder cannot learn the group key, even after repeated observations of multiple exchanges. These schemes begin when the client sends a nonce to the server, which then rolls its own nonce, performs a mathematical operation and sends the results to the client. The client performs a second mathematical operation to prove the server has the same group key as the client.
PC方案用于测试和开发，不建议用于一般用途。TC方案使用证书跟踪，但不使用身份方案。IFF、GQ和MV身份方案使用加密的强质询-响应交换，入侵者即使在多次观察交换后也无法学习组密钥。当客户机向服务器发送一个nonce时，这些方案就开始了，然后服务器滚动自己的nonce，执行数学运算并将结果发送给客户机。客户端执行第二个数学运算，以证明服务器具有与客户端相同的组密钥。
Appendix C. Private Certificate (PC) Scheme
附录C私人证书（PC）计划
The PC scheme shown in Figure 12 uses a private certificate as the group key.
图12所示的PC方案使用私有证书作为组密钥。
Trusted
Authority
Secure +-------------+ Secure
+--------------| Certificate |-------------+
| +-------------+ |
| |
\|/ \|/
+-------------+ +-------------+
| Certificate | | Certificate |
+-------------+ +-------------+
Server Client
Trusted
Authority
Secure +-------------+ Secure
+--------------| Certificate |-------------+
| +-------------+ |
| |
\|/ \|/
+-------------+ +-------------+
| Certificate | | Certificate |
+-------------+ +-------------+
Server Client
Figure 12: Private Certificate (PC) Identity Scheme
图12：私人证书（PC）身份方案
A certificate is designated private when the X.509v3 Extended Key Usage extension field is present and contains "Private". The private certificate is distributed to all other group members by secret means, so in fact becomes a symmetric key. Private certificates are also trusted, so there is no need for a certificate trail or identity scheme.
当存在X.509v3扩展密钥使用扩展字段且包含“private”时，证书被指定为private。私有证书通过秘密方式分发给所有其他组成员，因此实际上成为对称密钥。私有证书也受信任，因此不需要证书跟踪或身份方案。
Appendix D. Trusted Certificate (TC) Scheme
附录D.受信任证书（TC）方案
All other schemes involve a conventional certificate trail as shown
in Figure 13.
Trusted
Host Host Host
+-----------+ +-----------+ +-----------+
+--->| Subject | +--->| Subject | +--->| Subject |
| +-----------+ | +-----------+ | +-----------+
...---+ | Issuer |---+ | Issuer |---+ | Issuer |
+-----------+ +-----------+ +-----------+
| Signature | | Signature | | Signature |
+-----------+ +-----------+ +-----------+
All other schemes involve a conventional certificate trail as shown
in Figure 13.
Trusted
Host Host Host
+-----------+ +-----------+ +-----------+
+--->| Subject | +--->| Subject | +--->| Subject |
| +-----------+ | +-----------+ | +-----------+
...---+ | Issuer |---+ | Issuer |---+ | Issuer |
+-----------+ +-----------+ +-----------+
| Signature | | Signature | | Signature |
+-----------+ +-----------+ +-----------+
Figure 13: Trusted Certificate (TC) Identity Scheme
图13：可信证书（TC）身份方案
As described in RFC 4210 [RFC4210], each certificate is signed by an issuer one step closer to the trusted host, which has a self-signed trusted certificate. A certificate is designated trusted when an X.509v3 Extended Key Usage extension field is present and contains "trustRoot". If no identity scheme is specified in the parameter exchange, this is the default scheme.
如RFC 4210[RFC4210]中所述，每个证书都由发卡机构在距离可信主机更近一步的地方进行签名，可信主机具有自签名的可信证书。当存在X.509v3扩展密钥使用扩展字段且包含“trustRoot”时，证书被指定为受信任。如果在参数交换中未指定标识方案，则这是默认方案。
Appendix E. Schnorr (IFF) Identity Scheme
附录E.施诺尔（IFF）身份方案
The IFF scheme is useful when the group key is concealed, so that client keys need not be protected. The primary disadvantage is that when the server key is refreshed all hosts must update the client key. The scheme shown in Figure 14 involves a set of public parameters and a group key including both private and public components. The public component is the client key.
当组密钥被隐藏时，IFF方案非常有用，因此不需要保护客户端密钥。主要缺点是，刷新服务器密钥时，所有主机都必须更新客户端密钥。图14所示的方案涉及一组公共参数和一个组密钥，包括私有和公共组件。公共组件是客户机密钥。
Trusted
Authority
+------------+
| Parameters |
Secure +------------+ Insecure
+-------------| Group Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Group Key |------------------------>| Client Key |
+------------+ Response +------------+
Server Client
Trusted
Authority
+------------+
| Parameters |
Secure +------------+ Insecure
+-------------| Group Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Group Key |------------------------>| Client Key |
+------------+ Response +------------+
Server Client
Figure 14: Schnorr (IFF) Identity Scheme
图14:Schnorr（IFF）身份方案
By happy coincidence, the mathematical principles on which IFF is based are similar to DSA. The scheme is a modification an algorithm described in [SCHNORR] and [STINSON] (p. 285). The parameters are generated by routines in the OpenSSL library, but only the moduli p, q and generator g are used. The p is a 512-bit prime, g a generator of the multiplicative group Z_p* and q a 160-bit prime that divides (p-1) and is a qth root of 1 mod p; that is, g^q = 1 mod p. The TA rolls a private random group key b (0 < b < q), then computes public client key v = g^(q-b) mod p. The TA distributes (p, q, g, b) to all servers using secure means and (p, q, g, v) to all clients not necessarily using secure means.
幸运的是，IFF所基于的数学原理与DSA相似。该方案是对[SCHNORR]和[STINSON]（第285页）中所述算法的修改。这些参数是由OpenSSL库中的例程生成的，但只使用模p、q和生成器g。p是512位素数，g是乘法组Z_p*和q的160位素数的生成器，其除以（p-1），并且是1 mod p的第qth根；也就是说，g^q=1 mod p。TA滚动一个私有随机组密钥b（0<b<q），然后计算公共客户端密钥v=g^（q-b）mod p。TA使用安全手段将（p、q、g、b）分发给所有服务器，并将（p、q、g、v）分发给不一定使用安全手段的所有客户端。
The TA hides IFF parameters and keys in an OpenSSL DSA cuckoo structure. The IFF parameters are identical to the DSA parameters, so the OpenSSL library can be used directly. The structure shown in Figure 15 is written to a file as a DSA private key encoded in PEM. Unused structure members are set to one.
TA在OpenSSL DSA布谷鸟结构中隐藏IFF参数和密钥。IFF参数与DSA参数相同，因此可以直接使用OpenSSL库。图15所示的结构作为编码在PEM中的DSA私钥写入文件。未使用的结构杆件设置为一个。
+----------------------------------+-------------+
| IFF | DSA | Item | Include |
+=========+==========+=============+=============+
| p | p | modulus | all |
+---------+----------+-------------+-------------+
| q | q | modulus | all |
+---------+----------+-------------+-------------+
| g | g | generator | all |
+---------+----------+-------------+-------------+
| b | priv_key | group key | server |
+---------+----------+-------------+-------------+
| v | pub_key | client key | client |
+---------+----------+-------------+-------------+
+----------------------------------+-------------+
| IFF | DSA | Item | Include |
+=========+==========+=============+=============+
| p | p | modulus | all |
+---------+----------+-------------+-------------+
| q | q | modulus | all |
+---------+----------+-------------+-------------+
| g | g | generator | all |
+---------+----------+-------------+-------------+
| b | priv_key | group key | server |
+---------+----------+-------------+-------------+
| v | pub_key | client key | client |
+---------+----------+-------------+-------------+
Figure 15: IFF Identity Scheme Structure
图15:IFF身份方案结构
Alice challenges Bob to confirm identity using the following protocol exchange.
Alice要求Bob使用以下协议交换确认身份。
1. Alice rolls random r (0 < r < q) and sends to Bob.
1. Alice随机滚动r（0<r<q）并发送给Bob。
2. Bob rolls random k (0 < k < q), computes y = k + br mod q and x = g^k mod p, then sends (y, hash(x)) to Alice.
2. Bob滚动随机k（0<k<q），计算y=k+br mod q和x=g^k mod p，然后将（y，散列（x））发送给Alice。
3. Alice computes z = g^y * v^r mod p and verifies hash(z) equals hash(x).
3. Alice计算z=g^y*v^r mod p并验证散列（z）是否等于散列（x）。
If the hashes match, Alice knows that Bob has the group key b. Besides making the response shorter, the hash makes it effectively impossible for an intruder to solve for b by observing a number of these messages. The signed response binds this knowledge to Bob's private key and the public key previously received in his certificate.
如果哈希匹配，Alice知道Bob拥有组密钥b。除了缩短响应之外，散列还使得入侵者无法通过观察大量这些消息来有效地解决b问题。签名响应将此知识绑定到Bob的私钥和以前在其证书中收到的公钥。
Appendix F. Guillard-Quisquater (GQ) Identity Scheme
附录F.Guillard Quisquater（GQ）身份认证方案
The GQ scheme is useful when the server key must be refreshed from time to time without changing the group key. The NTP utility programs include the GQ client key in the X.509v3 Subject Key Identifier extension field. The primary disadvantage of the scheme is that the group key must be protected in both the server and client. A secondary disadvantage is that when a server key is refreshed, old extension fields no longer work. The scheme shown in Figure 16 involves a set of public parameters and a group key used to generate private server keys and client keys.
当必须在不更改组密钥的情况下不时刷新服务器密钥时，GQ方案非常有用。NTP实用程序在X.509v3主题密钥标识符扩展字段中包含GQ客户端密钥。该方案的主要缺点是组密钥必须在服务器和客户端都受到保护。第二个缺点是，当刷新服务器密钥时，旧的扩展字段不再工作。图16所示的方案涉及一组公共参数和一个用于生成私有服务器密钥和客户端密钥的组密钥。
Trusted
Authority
+------------+
| Parameters |
Secure +------------+ Secure
+-------------| Group Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Group Key | | Group Key |
+------------+ Response +------------+
| Server Key |------------------------>| Client Key |
+------------+ +------------+
Server Client
Trusted
Authority
+------------+
| Parameters |
Secure +------------+ Secure
+-------------| Group Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Group Key | | Group Key |
+------------+ Response +------------+
| Server Key |------------------------>| Client Key |
+------------+ +------------+
Server Client
Figure 16: Schnorr (IFF) Identity Scheme
图16:Schnorr（IFF）身份方案
By happy coincidence, the mathematical principles on which GQ is based are similar to RSA. The scheme is a modification of an algorithm described in [GUILLOU] and [STINSON] (p. 300) (with errors). The parameters are generated by routines in the OpenSSL library, but only the moduli p and q are used. The 512-bit public modulus is n=pq, where p and q are secret large primes. The TA rolls random large prime b (0 < b < n) and distributes (n, b) to all group servers and clients using secure means, since an intruder in possession of these values could impersonate a legitimate server. The private server key and public client key are constructed later.
幸运的是，GQ所基于的数学原理与RSA相似。该方案是对[GUILLOU]和[STINSON]（第300页）中描述的算法的修改（有错误）。参数是由OpenSSL库中的例程生成的，但只使用模p和q。512位公共模是n=pq，其中p和q是秘密大素数。TA滚动随机大素数b（0<b<n）并使用安全手段将（n，b）分发给所有组服务器和客户端，因为拥有这些值的入侵者可以模拟合法服务器。私有服务器密钥和公共客户端密钥将在后面构造。
The TA hides GQ parameters and keys in an OpenSSL RSA cuckoo
structure. The GQ parameters are identical to the RSA parameters, so
the OpenSSL library can be used directly. When generating a
certificate, the server rolls random server key u (0 < u < n) and
client key its inverse obscured by the group key v = (u^-1)^b mod n.
These values replace the private and public keys normally generated
by the RSA scheme. The client key is conveyed in a X.509 certificate
extension. The updated GQ structure shown in Figure 17 is written as
an RSA private key encoded in PEM. Unused structure members are set
to one.
The TA hides GQ parameters and keys in an OpenSSL RSA cuckoo
structure. The GQ parameters are identical to the RSA parameters, so
the OpenSSL library can be used directly. When generating a
certificate, the server rolls random server key u (0 < u < n) and
client key its inverse obscured by the group key v = (u^-1)^b mod n.
These values replace the private and public keys normally generated
by the RSA scheme. The client key is conveyed in a X.509 certificate
extension. The updated GQ structure shown in Figure 17 is written as
an RSA private key encoded in PEM. Unused structure members are set
to one.
+---------------------------------+-------------+
| GQ | RSA | Item | Include |
+=========+==========+============+=============+
| n | n | modulus | all |
+---------+----------+------------+-------------+
| b | e | group key | all |
+---------+----------+------------+-------------+
| u | p | server key | server |
+---------+----------+------------+-------------+
| v | q | client key | client |
+---------+----------+------------+-------------+
+---------------------------------+-------------+
| GQ | RSA | Item | Include |
+=========+==========+============+=============+
| n | n | modulus | all |
+---------+----------+------------+-------------+
| b | e | group key | all |
+---------+----------+------------+-------------+
| u | p | server key | server |
+---------+----------+------------+-------------+
| v | q | client key | client |
+---------+----------+------------+-------------+
Figure 17: GQ Identity Scheme Structure
图17:GQ身份方案结构
Alice challenges Bob to confirm identity using the following exchange.
Alice要求Bob使用以下交换确认身份。
1. Alice rolls random r (0 < r < n) and sends to Bob.
1. Alice随机滚动r（0<r<n）并发送给Bob。
2. Bob rolls random k (0 < k < n) and computes y = ku^r mod n and x = k^b mod n, then sends (y, hash(x)) to Alice.
2. Bob滚动随机k（0<k<n）并计算y=ku^r mod n和x=k^b mod n，然后将（y，散列（x））发送给Alice。
3. Alice computes z = (v^r)*(y^b) mod n and verifies hash(z) equals hash(x).
3. Alice计算z=（v^r）*（y^b）mod n并验证散列（z）是否等于散列（x）。
If the hashes match, Alice knows that Bob has the corresponding server key u. Besides making the response shorter, the hash makes it effectively impossible for an intruder to solve for u by observing a number of these messages. The signed response binds this knowledge to Bob's private key and the client key previously received in his certificate.
如果哈希匹配，Alice知道Bob具有相应的服务器密钥u。除了缩短响应时间外，散列还使得入侵者无法通过观察大量这些消息来为u解决问题。签名响应将此知识绑定到Bob的私钥和以前在其证书中接收到的客户端密钥。
Appendix G. Mu-Varadharajan (MV) Identity Scheme
附录G.Mu Varadharajan（MV）身份认证计划
The MV scheme is perhaps the most interesting and flexible of the three challenge/response schemes, but is devilishly complicated. It is most useful when a small number of servers provide synchronization to a large client population where there might be considerable risk of compromise between and among the servers and clients. The client population can be partitioned into a modest number of subgroups, each associated with an individual client key.
MV方案可能是三种挑战/响应方案中最有趣、最灵活的方案，但极其复杂。当少量服务器向大量客户机提供同步时，它最有用，因为在这些客户机和服务器之间可能存在相当大的妥协风险。客户机总体可以划分为数量适中的子组，每个子组与单个客户机密钥相关联。
The TA generates an intricate cryptosystem involving encryption and decryption keys, together with a number of activation keys and associated client keys. The TA can activate and revoke individual client keys without changing the client keys themselves. The TA provides to the servers an encryption key E, and partial decryption keys g-bar and g-hat which depend on the activated keys. The servers
TA生成一个复杂的密码系统，包括加密和解密密钥，以及许多激活密钥和相关的客户端密钥。TA可以激活和撤销单个客户端密钥，而无需更改客户端密钥本身。TA向服务器提供加密密钥E，以及依赖于激活密钥的部分解密密钥g-bar和g-hat。服务器
have no additional information and, in particular, cannot masquerade as a TA. In addition, the TA provides to each client j individual partial decryption keys x-bar_j and x-hat_j, which do not need to be changed if the TA activates or deactivates any client key. The clients have no further information and, in particular, cannot masquerade as a server or TA.
没有其他信息，尤其是不能冒充助教。此外，TA向每个客户端j提供单独的部分解密密钥x-bar_j和x-hat_j，如果TA激活或停用任何客户端密钥，则不需要更改这些密钥。客户端没有进一步的信息，特别是不能伪装成服务器或TA。
The scheme uses an encryption algorithm similar to El Gamal cryptography and a polynomial formed from the expansion of product terms (x-x_1)(x-x_2)(x-x_3)...(x-x_n), as described in [MV]. The paper has significant errors and serious omissions. The cryptosystem is constructed so that, for every encryption key E its inverse is (g-bar^x-hat_j)(g-hat^x-bar_j) mod p for every j. This remains true if both quantities are raised to the power k mod p. The difficulty in finding E is equivalent to the discrete log problem.
该方案使用类似于El-Gamal加密的加密算法和由乘积项（x-x_1）（x-x_2）（x-x_3）…（x-x_n）展开形成的多项式，如[MV]中所述。论文存在重大错误和严重遗漏。该密码系统的构造使得，对于每个加密密钥E，其逆是（g-bar^x-hat_j）（g-hat^x-bar_j）mod p，对于每个j。如果这两个量都提高到k mod p的幂，则仍然如此。求E的困难相当于离散对数问题。
The scheme is shown in Figure 18. The TA generates the parameters, group key, server keys, and client keys, one for each client, all of which must be protected to prevent theft of service. Note that only the TA has the group key, which is not known to either the servers or clients. In this sense, the MV scheme is a zero-knowledge proof.
该方案如图18所示。TA生成参数、组密钥、服务器密钥和客户端密钥，每个客户端一个，所有这些都必须受到保护，以防止服务被盗。请注意，只有TA具有组密钥，服务器或客户端都不知道组密钥。从这个意义上讲，MV方案是一个零知识证明。
Trusted
Authority
+------------+
| Parameters |
+------------+
| Group Key |
+------------+
| Server Key |
Secure +------------+ Secure
+-------------| Client Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Server Key |------------------------>| Client Key |
+------------+ Response +------------+
Server Client
Trusted
Authority
+------------+
| Parameters |
+------------+
| Group Key |
+------------+
| Server Key |
Secure +------------+ Secure
+-------------| Client Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Server Key |------------------------>| Client Key |
+------------+ Response +------------+
Server Client
Figure 18: Mu-Varadharajan (MV) Identity Scheme
图18:Mu Varadharajan（MV）身份方案
The TA hides MV parameters and keys in OpenSSL DSA cuckoo structures. The MV parameters are identical to the DSA parameters, so the OpenSSL library can be used directly. The structure shown in the figures below are written to files as a the fkey encoded in PEM. Unused structure members are set to one. The Figure 19 shows the data
TA在OpenSSL DSA布谷鸟结构中隐藏MV参数和密钥。MV参数与DSA参数相同，因此可以直接使用OpenSSL库。下图所示的结构作为PEM中编码的fkey写入文件。未使用的结构杆件设置为一个。图19显示了数据
structure used by the servers, while Figure 20 shows the client data structure associated with each activation key.
服务器使用的数据结构，而图20显示了与每个激活密钥关联的客户机数据结构。
+---------------------------------+-------------+
| MV | DSA | Item | Include |
+=========+==========+============+=============+
| p | p | modulus | all |
+---------+----------+------------+-------------+
| q | q | modulus | server |
+---------+----------+------------+-------------+
| E | g | private | server |
| | | encrypt | |
+---------+----------+------------+-------------+
| g-bar | priv_key | public | server |
| | | decrypt | |
+---------+----------+------------+-------------+
| g-hat | pub_key | public | server |
| | | decrypt | |
+---------+----------+------------+-------------+
+---------------------------------+-------------+
| MV | DSA | Item | Include |
+=========+==========+============+=============+
| p | p | modulus | all |
+---------+----------+------------+-------------+
| q | q | modulus | server |
+---------+----------+------------+-------------+
| E | g | private | server |
| | | encrypt | |
+---------+----------+------------+-------------+
| g-bar | priv_key | public | server |
| | | decrypt | |
+---------+----------+------------+-------------+
| g-hat | pub_key | public | server |
| | | decrypt | |
+---------+----------+------------+-------------+
Figure 19: MV Scheme Server Structure
图19:MV方案服务器结构
+---------------------------------+-------------+
| MV | DSA | Item | Include |
+=========+==========+============+=============+
| p | p | modulus | all |
+---------+----------+------------+-------------+
| x-bar_j | priv_key | public | client |
| | | decrypt | |
+---------+----------+------------+-------------+
| x-hat_j | pub_key | public | client |
| | | decrypt | |
+---------+----------+------------+-------------+
+---------------------------------+-------------+
| MV | DSA | Item | Include |
+=========+==========+============+=============+
| p | p | modulus | all |
+---------+----------+------------+-------------+
| x-bar_j | priv_key | public | client |
| | | decrypt | |
+---------+----------+------------+-------------+
| x-hat_j | pub_key | public | client |
| | | decrypt | |
+---------+----------+------------+-------------+
Figure 20: MV Scheme Client Structure
图20:MV方案客户端结构
The devil is in the details, which are beyond the scope of this memo. The steps in generating the cryptosystem activating the keys and generating the partial decryption keys are in [DASBUCH] (page 170 ff).
魔鬼在于细节，这超出了这份备忘录的范围。生成密码系统激活密钥和生成部分解密密钥的步骤见[DASBUCH]（第170页ff）。
Alice challenges Bob to confirm identity using the following exchange.
Alice要求Bob使用以下交换确认身份。
1. Alice rolls random r (0 < r < q) and sends to Bob.
1. Alice随机滚动r（0<r<q）并发送给Bob。
2. Bob rolls random k (0 < k < q) and computes the session encryption key E-prime = E^k mod p and partial decryption keys g-bar-prime = g-bar^k mod p and g-hat-prime = g-hat^k mod p. He encrypts x = E-prime * r mod p and sends (x, g-bar-prime, g-hat-prime) to Alice.
2. Bob随机滚动k（0<k<q）并计算会话加密密钥E-prime=E^k mod p和部分解密密钥g-bar-prime=g-bar^k mod p和g-hat-prime=g-hat^k mod p。他加密x=E-prime*r mod p并发送（x，g-bar-prime，g-hat-prime）给Alice。
3. Alice computes the session decryption key E^-1 = (g-bar-prime)^x-hat_j (g-hat-prime)^x-bar_j mod p and verifies that r = E^-1 x.
3. Alice计算会话解密密钥E^-1=（g-bar-prime）^x-hat\u j（g-hat-prime）^x-bar\u j mod p，并验证r=E^-1 x。
Appendix H. ASN.1 Encoding Rules
附录H.ASN.1编码规则
Certain value fields in request and response messages contain data encoded in ASN.1 distinguished encoding rules (DER). The BNF grammar for each encoding rule is given below along with the OpenSSL routine used for the encoding in the reference implementation. The object identifiers for the encryption algorithms and message digest/ signature encryption schemes are specified in [RFC3279]. The particular algorithms required for conformance are not specified in this memo.
请求和响应消息中的某些值字段包含ASN.1可分辨编码规则（DER）中编码的数据。下面给出了每个编码规则的BNF语法以及参考实现中用于编码的OpenSSL例程。[RFC3279]中规定了加密算法和消息摘要/签名加密方案的对象标识符。本备忘录未规定合规性所需的特定算法。
Appendix I. COOKIE Request, IFF Response, GQ Response, MV Response
附录I.COOKIE请求、IFF响应、GQ响应、MV响应
The value field of the COOKIE request message contains a sequence of two integers (n, e) encoded by the i2d_RSAPublicKey() routine in the OpenSSL distribution. In the request, n is the RSA modulus in bits and e is the public exponent.
COOKIE请求消息的值字段包含由OpenSSL发行版中的i2d_RSAPublicKey（）例程编码的两个整数（n，e）的序列。在请求中，n是以位为单位的RSA模，e是公共指数。
RSAPublicKey ::= SEQUENCE {
n ::= INTEGER,
e ::= INTEGER
}
RSAPublicKey ::= SEQUENCE {
n ::= INTEGER,
e ::= INTEGER
}
The IFF and GQ responses contain a sequence of two integers (r, s) encoded by the i2d_DSA_SIG() routine in the OpenSSL distribution. In the responses, r is the challenge response and s is the hash of the private value.
IFF和GQ响应包含由OpenSSL发行版中的i2d_DSA_SIG（）例程编码的两个整数（r，s）序列。在响应中，r是质询响应，s是私有值的散列。
DSAPublicKey ::= SEQUENCE {
r ::= INTEGER,
s ::= INTEGER
}
DSAPublicKey ::= SEQUENCE {
r ::= INTEGER,
s ::= INTEGER
}
The MV response contains a sequence of three integers (p, q, g) encoded by the i2d_DSAparams() routine in the OpenSSL library. In the response, p is the hash of the encrypted challenge value and (q, g) is the client portion of the decryption key.
MV响应包含由OpenSSL库中的i2d_DSAparams（）例程编码的三个整数（p、q、g）的序列。在响应中，p是加密质询值的散列，（q，g）是解密密钥的客户端部分。
DSAparameters ::= SEQUENCE {
p ::= INTEGER,
q ::= INTEGER,
g ::= INTEGER
}
DSAparameters ::= SEQUENCE {
p ::= INTEGER,
q ::= INTEGER,
g ::= INTEGER
}
Appendix J. Certificates
附录J.证书
Certificate extension fields are used to convey information used by the identity schemes. While the semantics of these fields generally conform with conventional usage, there are subtle variations. The fields used by Autokey version 2 include:
证书扩展字段用于传递标识方案使用的信息。虽然这些字段的语义通常符合常规用法，但存在细微的变化。Autokey版本2使用的字段包括：
o Basic Constraints. This field defines the basic functions of the certificate. It contains the string "critical,CA:TRUE", which means the field must be interpreted and the associated private key can be used to sign other certificates. While included for compatibility, Autokey makes no use of this field.
o 基本限制。此字段定义证书的基本功能。它包含字符串“critical，CA:TRUE”，这意味着必须解释该字段，并且可以使用关联的私钥对其他证书进行签名。虽然包含Autokey是为了兼容，但它不使用此字段。
o Key Usage. This field defines the intended use of the public key contained in the certificate. It contains the string "digitalSignature,keyCertSign", which means the contained public key can be used to verify signatures on data and other certificates. While included for compatibility, Autokey makes no use of this field.
o 关键用法。此字段定义证书中包含的公钥的预期用途。它包含字符串“digitalSignature，keyCertSign”，这意味着所包含的公钥可用于验证数据和其他证书上的签名。虽然包含Autokey是为了兼容，但它不使用此字段。
o Extended Key Usage. This field further refines the intended use of the public key contained in the certificate and is present only in self-signed certificates. It contains the string "Private" if the certificate is designated private or the string "trustRoot" if it is designated trusted. A private certificate is always trusted.
o 扩展密钥使用。此字段进一步细化了证书中包含的公钥的预期用途，并且仅存在于自签名证书中。如果证书被指定为Private，则包含字符串“Private”；如果证书被指定为trusted，则包含字符串“trustRoot”。私有证书始终受信任。
o Subject Key Identifier. This field contains the client identity key used in the GQ identity scheme. It is present only if the GQ scheme is in use.
o 主题密钥标识符。此字段包含GQ标识方案中使用的客户端标识密钥。只有在使用GQ方案时才存在。
The value field contains an X.509v3 certificate encoded by the i2d_X509() routine in the OpenSSL distribution. The encoding follows the rules stated in [RFC5280], including the use of X.509v3 extension fields.
值字段包含由OpenSSL发行版中的i2d_X509（）例程编码的X.509v3证书。编码遵循[RFC5280]中规定的规则，包括使用X.509v3扩展字段。
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
The signatureAlgorithm is the object identifier of the message digest/signature encryption scheme used to sign the certificate. The signatureValue is computed by the certificate issuer using this algorithm and the issuer private key.
signatureAlgorithm是用于对证书进行签名的消息摘要/签名加密方案的对象标识符。证书颁发者使用此算法和颁发者私钥计算signatureValue。
TBSCertificate ::= SEQUENCE {
version EXPLICIT v3(2),
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
extensions EXPLICIT Extensions OPTIONAL
}
TBSCertificate ::= SEQUENCE {
version EXPLICIT v3(2),
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
extensions EXPLICIT Extensions OPTIONAL
}
The serialNumber is an integer guaranteed to be unique for the generating host. The reference implementation uses the NTP seconds when the certificate was generated. The signature is the object identifier of the message digest/signature encryption scheme used to sign the certificate. It must be identical to the signatureAlgorithm.
serialNumber是保证生成主机唯一的整数。生成证书时，参考实现使用NTP秒数。签名是用于签名证书的消息摘要/签名加密方案的对象标识符。它必须与签名算法相同。
CertificateSerialNumber
SET { ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
}
CertificateSerialNumber
SET { ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
}
The notBefore and notAfter define the period of validity as defined in Appendix B.
附录B中规定的有效期之前和之后的日期。
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The AlgorithmIdentifier specifies the encryption algorithm for the subject public key. The subjectPublicKey is the public key of the subject.
AlgorithmIdentifier指定主题公钥的加密算法。subjectPublicKey是主题的公钥。
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
}
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
}
SET {
Name ::= SEQUENCE {
OBJECT IDENTIFIER commonName
PrintableString HostName
}
}
SET {
Name ::= SEQUENCE {
OBJECT IDENTIFIER commonName
PrintableString HostName
}
}
For trusted host certificates, the subject and issuer HostName is the NTP name of the group, while for all other host certificates the subject and issuer HostName is the NTP name of the host. In the reference implementation, if these names are not explicitly specified, they default to the string returned by the Unix gethostname() routine (trailing NUL removed). For other than self-signed certificates, the issuer HostName is the unique DNS name of the host signing the certificate.
对于受信任的主机证书，使用者和颁发者主机名是组的NTP名称，而对于所有其他主机证书，使用者和颁发者主机名是主机的NTP名称。在引用实现中，如果未显式指定这些名称，则默认为Unix gethostname（）例程返回的字符串（尾部NUL已删除）。对于自签名证书以外的证书，颁发者主机名是签署证书的主机的唯一DNS名称。
It should be noted that the Autokey protocol itself has no provisions to revoke certificates. The reference implementation is purposely restarted about once a week, leading to the regeneration of the certificate and a restart of the Autokey protocol. This restart is not enforced for the Autokey protocol but rather for NTP functionality reasons.
应该注意的是，自动密钥协议本身没有撤销证书的规定。参考实现大约每周重新启动一次，从而重新生成证书并重新启动自动密钥协议。此重新启动不是出于自动密钥协议，而是出于NTP功能的原因。
Each group host operates with only one certificate at a time and constructs a trail by induction. Since the group configuration must form an acyclic graph, with roots at the trusted hosts, it does not matter which, of possibly several, signed certificates is used. The reference implementation chooses a single certificate and operates with only that certificate until the protocol is restarted.
每个组主机一次仅使用一个证书进行操作，并通过归纳构建一个跟踪。由于组配置必须形成一个非循环图，根位于受信任的主机上，因此使用几个签名证书中的哪一个并不重要。参考实现选择单个证书并仅使用该证书操作，直到协议重新启动。
Authors' Addresses
作者地址
Brian Haberman (editor) The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
布莱恩·哈伯曼（编辑）美国马里兰州劳雷尔市约翰·霍普金斯路11100号约翰·霍普金斯大学应用物理实验室20723-6099
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Dr. David L. Mills University of Delaware Newark, DE 19716 US
戴维·L·米尔斯·德拉瓦大学NeWalk，DE 19716美国
Phone: +1 302 831 8247
EMail: mills@udel.edu
Phone: +1 302 831 8247
EMail: mills@udel.edu