[要約] RFC 5906は、Network Time Protocol（NTP）バージョン4のAutokey仕様を定義しています。この仕様の目的は、NTPサーバーとクライアント間のセキュアな通信を確立し、時刻同期の信頼性を向上させることです。
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：Autokey仕様
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）と公開キー暗号化を使用して、クライアントにサーバーを認証するためのAutokeyセキュリティモデルについて説明しています。その設計は、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.
このメモには、Autokey要件分析、設計原則、およびプロトコル仕様が含まれています。プロトコルの状態、イベント、および遷移関数の詳細な説明が含まれています。このメモに基づいたAutokey Designのプロトタイプは、http：// wwwでUNIX、Windows、および仮想メモリシステム（VMS）オペレーティングシステムのNTPバージョン4（NTPV4）ソフトウェア分布で実装、テスト、および文書化されています。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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.
分散ネットワークサービスには、ネットワーク内のサーバーやクライアントに対する偶発的または悪意のある攻撃を防ぐために、信頼性が高く、ユビキタスな、そして生存可能な条項が必要です。信頼性では、クライアントが受信したパケットが本物であると判断できることが必要です。つまり、実際には意図したサーバーによって送信され、侵入者によって製造または変更されていません。Ubiquityでは、クライアントが公開情報のみを使用してサーバーの信頼性を確認できることが必要です。生存性には、故障した実装、不適切な動作、およびおそらく悪意のある詰まりやリプレイ攻撃からの保護が必要です。
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]は、アソシエーションごとの状態変数を要求することを提案しました。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.
Autokeyプロトコルは、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.
この情報ドキュメントでは、http://www.ntp.orgから入手可能なNTPV4ソフトウェア配信に実装されているAutokeyのNTP拡張機能について説明しています。この説明は、将来の作業の基礎とソフトウェアリリースのリファレンスを提供するために提供されます。このドキュメントでは、プロトコル内の拡張機能の動機についても説明しています。
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 hierarchical by nature, so time and trust flow from the primary servers at the root through secondary servers to the clients at the leaves.
NTPセキュリティ要件は、他のほとんどの分散サービスよりもさらに厳しいものです。まず、認証メカニズムと時間同期メカニズムの動作は密接に絡み合っています。信頼できる時間同期には、指定された時間間隔でのみ有効な暗号化キーが必要です。ただし、参加サーバーとクライアントがUTCに確実に同期されている場合にのみ、時間間隔を実施できます。さらに、NTPサブネットは本質的に階層的であるため、ルートのプライマリサーバーからセカンダリサーバーを介して葉のクライアントに時間と信頼が流れます。
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」に置き換えられます。ここまで言語を乱用した後、本物のさまざまな派生物に固定可能な接尾辞も、プロボンティックに採用されます。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クライアントは、さまざまなサーバーとの多くの同時関連を動員し、細工された合意アルゴリズムを使用して、おそらくFalsetickersを含む人口からTruechimersを引き抜きます。このメモに記載されている手段によってサーバー証明書と身元が検証されている場合、特定の関連付けは証明されます。ただし、「クライアントはプロボンティックソースに同期される」というステートメントは、NTP緩和アルゴリズムに従って、1つ以上のプロボンティックアソシエーションの時間値を使用してシステムクロックが設定されていることを意味します。
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 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.
このメモの議論を促進し、http：//www.ntp.orgで利用可能な参照実装を参照します。このメモに記載されているようにAutokeyが含まれており、一般の人々が利用できます。ただし、仕様自体の一部ではありません。参照実装とそのユーザーコミュニティで使用される暗号化手段は、http://www.openssl.orgで入手可能なOpenSSL暗号化ソフトウェアライブラリに基づいていますが、同等の機能を持つ他のライブラリも使用できます。これらのアルゴリズムが使用される方法が、デジタル署名の構築に付随する以外のデータの暗号化を妨げることが、配布と輸出の目的で重要です。
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で検討されている可能性の高いケースを除き、修正されたパケットは元のパケットの前に被害者に到達することも、サーバーのプライベートキーやIDパラメーターも持っていません。
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.
クライアントがサーバーに安全に認証される必要があるセキュアシェル（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].
このメモで説明されているAutokeyプロトコルは、次の目的を満たすように設計されています。これらの目的に関する詳細な議論はWebブリーフィングにあり、このメモでは詳しく説明されません。ここで、このメモの他の場所では、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.
Autokey Cryptographyは、安全なシェルおよびセキュアソケット層（SSL）アプリケーションで一般的に使用されるPKIアルゴリズムに基づいています。これらのアプリケーションと同様に、Autokekeyはメッセージダイジェストを使用して、パケットの変更、デジタル署名を検出して資格情報を検証し、公的証明書を追跡可能な権限を提供します。Autokey Cryptographyをユニークにしているのは、これらのアルゴリズムを使用して、時間同期関数の完全性と精度を維持しながら、侵入者攻撃をそらすために使用される方法です。
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.
Autokeyは、他の多くのリモートプロシージャコール（RPC）プロトコルと同様に、基本認証のメッセージダイジェストに依存します。ただし、Autokeyが利用できないか、構成されていない場合、メッセージダイジェストはNTPによっても使用されることを理解することが重要です。Digestアルゴリズムの選択は、NTP構成の関数であり、Autokeyに対して透明です。
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のピボットポイントの2つの部分空間に分割されます。対称キーIDは、ピボットおよび無期限の寿命よりも少ない値を持っています。Autokey Key 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 |
+------------------+ +-------------+
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.
Autokekeyは、Autokeysと呼ばれる特別に不自然なセッションキーと、Autokeyリストに保存されているオートケイの事前に計算された擬似ランダムシーケンスを使用します。Autokey Protocolは各アソシエーションで個別に動作するため、同時に独立して動作するいくつかのAutokeyシーケンスがある場合があります。
+-------------+-------------+--------+--------+
| Src Address | Dst Address | Key ID | Cookie |
+-------------+-------------+--------+--------+
Figure 2: NTPv4 Autokey
図2：ntpv4 autokey
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.
Autokekeyは、図2に示すように、ネットワークバイトの順序で4つのフィールドから計算されます。4つの値は、MD5アルゴリズムを使用して128ビットAutokekey値を生成するためにハッシュされます。対称キーとオートケイに使用されます。キーは、ハッシュテーブルと高速ルックアップアルゴリズムを使用して、キー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 Autokekeyには4つの32ビット単語があり、IPv6 Autokeyyには10個の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の間にピギーバックされた1つ以上の拡張フィールドを含めるように拡張されています。拡張フィールドのないパケットの場合、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）デバイスが使用されている構成が含まれます。Autokeyの場合、唯一の制限は、送信されたパケットに表示されるアドレスフィールドが、Autokeyリストの作成に使用されているアドレスフィールドと同じでなければならず、これらのフィールドは受信したパケットで表示されるフィールドと同じであることです。（Autokeyホスト名（後述）やこれらの名前のハッシュなどの代替手段の使用は、将来の研究のトピックかもしれません。）
+-----------+-----------+------+------+ +---------+ +-----+------+
|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.
図3は、Autokey ListとAutokey値がどのように計算されるかを示しています。Autokeyリストで使用されているキーIDは、最初のキーIDとしてピボット以下のランダム32ビットNonCE（Autokey Seed）から始まるシーケンスで構成されています。最初のAutokeyは、指定されたCookieおよびAutokey Seedと割り当てられたインデックス0を使用して上記のように計算されます。ネットワークバイトの結果の最初の32ビットが次のキーIDになります。AutokekeyのMD5ハッシュは、キーキャッシュとキーIDとともに保存されているキー値です。キーの最初の32ビットは、次のAutokeyが割り当てられたインデックス1のキーIDになります。
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は、ピボットよりも少ないか、すでに生成された別のものと衝突することがあります（誕生日イベント）。これが発生した場合、それはまれに発生するだけで、キーリストはその時点で終了します。各キーの寿命は、スケジュールされた使用後に1つの投票間隔を期限切れにするように設定されています。参照実装では、最大のキー寿命が約1時間の場合、リストは終了するため、1時間以上の世論調査間隔では、1つのエントリのみを含む新しいキーリストがすべての世論調査で再生されます。
+------------------+
| 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.
リスト内の最後のAutokeyyのインデックスは、そのエントリのキーIDとともに保存され、総称してAutokey Valuesと呼ばれます。Autokey値は、後で使用するために署名されます。このリストは、図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.
Autokey Protocolには、Autokey値を取得して署名を検証するメッセージが含まれています。これにより、最終的に最後のキーID（有効）に一致するか、インデックス（INVALID）を超える1つ以上のハッシュを使用して後続のパケットを検証できます。これは、以下のAutokeyテストと呼ばれ、拡張フィールドの有無を含むすべてのパケットに対して行われます。参照実装では、受信した最新のキー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.
Autokeyプロトコルには、順番に完了する必要がある多くのリクエスト/応答交換が含まれています。各交換で、クライアントはデータを使用して要求メッセージを送信し、データを使用したサーバー応答メッセージを期待します。リクエストと応答は、後述のように、拡張フィールド、各フィールドに1つの要求または応答に含まれます。NTPパケットには、1つの要求メッセージと1つ以上の応答メッセージを含めることができます。以下は、これらのメッセージのリストです。
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 パラメーター交換。リクエストには、クライアントのホスト名とステータスワードが含まれます。応答には、サーバーホスト名とステータスワードが含まれます。ステータスワードは、使用するダイジェスト/署名スキームとサポートされるIDスキームを指定します。
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]に記載されているプルーフオブポッセッションスキームなどの追加の保護が利用可能でない限り、証明書のトレイルは一般に、中間攻撃に対する十分な保護とは見なされませんが、これは高価であり、状態を保持するためにサーバーが必要です。Autokekeyは、付録Bで説明されているチャレンジ/応答のアイデンティティスキームの1つを使用できます。
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が含まれます。クライアントは、キーリストを作成するときにこの値を使用します。この交換の完了は、以下で説明するようにクックビットを照らします。
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 Autokey Exchange。リクエストには、対称モードにデータがないか、自動化された値が含まれます。応答には、サーバーのAutokey値が含まれます。これらの値は、Autokeyシーケンスを検証するために使用されます。この交換の完了は、以下に説明するように自動ビットを照らします。
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 サインエクスチェンジ。この交換は、クライアントがプロバンティックソースに同期した場合にのみ実行されます。リクエストには、自己署名のクライアント証明書が含まれます。認証機関（CA）として機能するサーバーは、証明書をX.509V3証明書要求として解釈します。被験者、発行者、および拡張フィールドを抽出し、独自のシリアル番号と有効期限とともにこれらのデータを使用して新しい証明書を作成し、独自の秘密キーを使用してサインし、応答にそれを含みます。クライアントは、依存するクライアントのサーバーとして独自の役割で署名された証明書を使用します。この交換の完了は、以下で説明するようにサインビットを照らします。
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 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.
o 跳躍交換。この交換は、クライアントがプロバンティックソースに同期した場合にのみ実行されます。この交換は、ホストステータスワードに示されているように、サーバーの跳躍値を持っているときに発生します。その場合、クライアントは値を要求し、利用可能な場合は独自の値と比較します。サーバーの値がクライアント値よりも新しい場合、クライアントはそれ自体をサーバー値に置き換えます。サーバーとして機能するクライアントは、依存するクライアントに最新の値を提供できるようになりました。対称モードでは、両方のピアが最新の値を持つようになります。この交換の完了は、以下で説明するように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.
証明書と身元が検証されると、後続のパケットはデジタル署名とAutokeyシーケンスによって検証されます。協会は現在、ダウンストラタム信頼できるホストに関しては職業的であるが、システムクロックを懲戒するためにまだ選択できない。関連付けは時間の値を蓄積し、緩和アルゴリズムは通常の方法で継続します。これらのアルゴリズムがFalsetickersとCluster Outlierをculし、少なくとも3人の生存者が残っている場合、システムクロックはプロボンティックソースに同期されています。
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.
トルエキマー源の時間値は、該当する署名タイムスタンプに比べて、証拠的な部分的な順序を形成します。これは、異なる関連のタイムスタンプを区別する方法の興味深い問題を提起します。たとえば、いくつかの自動化されたメッセージのタイムスタンプは、おそらく少量のシステムクロックよりも先にあることが起こる可能性があります。このため、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およびその他の指定されたサーバーに展開し、パブリックWebサイトにクライアントキーを投稿します。
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 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.
Autokeyの目的のために、安全なグループに属するすべてのホストは同じグループ名を持っていますが、DNS名に必ずしも関連しているわけではありません。グループ名は、TH証明書の件名および発行者フィールドで使用されます。ホスト名は、これらのフィールドで他のホストに使用されます。したがって、すべてのホスト証明書は自己署名されています。Autokey Protocolの使用中、クライアントはサーバーが証明書に署名し、結果をキャッシュすることを要求します。証明書のトレイルは、各ホストによって、おそらく中間ホストを介して構築され、THで終了します。したがって、トレイルに沿った各ホストは、サーバーからトレイル全体を取得し、これに加えてクライアントに独自の署名証明書を提供します。
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.
安全なグループは、1つのグループのTHがより低い層で動作する1つ以上の他のグループのクライアントになることができる階層として構成できます。1つのシナリオでは、赤と緑のグループのTHSは暗号化的に異なる場合がありますが、どちらもより低い層で動作するグループブルーのクライアントです。別のシナリオでは、グループCyanの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では、アリスグループはTHSアリスで構成されています。これもTAとキャロルです。依存するサーバーのブレンダとデニスは、それぞれアリスとキャロルを時間源として構成しました。Stratum 3 Server Eileenは、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
+---------------------------------------------+
| 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.
証明書のトレイルをハイキングし、IDの確認の手順は次のとおりです。記述のステップ番号は、図のステップ番号と一致します。
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. 女の子は、ホストキー、署名キー、自己署名証明書、およびグループキーをロードすることから始めます。クライアントとして機能する各クライアントとサーバーは、サーバーのホスト名とダイジェスト/署名を取得することにより、Autokeyプロトコルを開始します。これは、後で説明したAssoc Exchangeを使用して行われます。
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, 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.
2. 自己署名の信頼できる証明書が見つかるまで、証明書を再帰的にロードし続けます。ブレンダとデニスはすぐにアリスとキャロルの信頼できる証明書を見つけますが、アイリーンはブレンダもデニスもアリスまたはキャロルのいずれかが署名した独自の証明書を持っていないため、ループします。これは、後で説明したCERT Exchangeを使用して行われます。
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. ブレンダとデニスは、選択したアイデンティティスキームを継続して、アリスとキャロルが以前にアリスによって生成された正しいグループキーを持っていることを確認します。これは、後で説明するIFF、GQ、またはMVのIDスキームの1つを使用して行われます。これが成功した場合、それぞれがステップ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. ブレンダとデニスは、後で説明した標識交換を使用して、署名の証明書を提示します。これが成功した場合、ブレンダとデニスのいずれかまたは両方のいずれかが、これらの署名された証明書をアイリーンに提供できるようになりました。これはステップ2でループしている可能性があります。これが完了すると、アイリーンはブレンダとデニスのようにプロトコルを完了することができます。
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は、アリス、ヘレン、キャロルが階層に配置した3つの安全なグループを示しています。ホストA、B、C、およびDは、AとBを持つAliceに属します。ホストrとSは、彼女のthとしてrを持つヘレンに属します。ホストXとYは、キャロルに属し、XはXとして属します。グループのTHは常に最も低い層であり、結合グループのホストが非環式グラフを形成することに注意してください。また、各グループの証明書のトレイルは、そのグループのTHで終了することに注意してください。
***** ***** @@@@@
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.
シナリオの意図は、セキュリティ分離を提供することです。そうすれば、サーバーは他のグループのクライアントを装って、クライアントがサーバーを装っていないことです。たとえば、アリスとヘレンは国家標準研究所に属し、サーバーキーが各グループのメンバー間でアイデンティティを確認するために使用されると仮定します。キャロルは、標準製品を受け取っており、暗号化認証を必要とする著名な企業です。おそらく契約下では、キャロルに属するホストXには、アリスとヘレンの両方のクライアントキーとキャロルのサーバーキーがあります。Autokey Protocolは、セキュリティの分離を保持しながら、各グループに対して個別に動作します。ホストXは、CarolのアイデンティティをクライアントYとZに証明できますが、アリスまたはヘレンのいずれかに属していることを誰にも証明することはできません。
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.
デジタル署名スキームは安全なサーバー認証を提供しますが、サーバーのIDが他の手段によって検証されない限り、仮面舞踏会に対する保護を提供しません。PKIモデルでは、サーバーが証明書のトレイルでクライアントにIDを証明する必要がありますが、CAがサーバー証明書に署名するには、ドライバーのライセンスなどの独立した手段が必要です。Autokekeyはデフォルトでこのモデルをサポートしていますが、特に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]で説明されているIDスキームは、ユビキタスな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. スキームは、比較的長い寿命であり、典型的な証明書よりも確かに長く、特定の生涯または有効期限がない必要があります。スキームが使用されている時点で、ホストはまだ証拠ソースに同期していないため、スキームは時間に依存することはできません。
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. スキームは、データが潜在的な侵入者にさらされる可能性がある場合に何度も使用できるため、データはNoncesまたは暗号化されたNoncesのいずれかでなければなりません。
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. このスキームでは、指定されたサーバーが指定されたクライアントにIDを証明できるようにする必要がありますが、サーバーとして行動するクライアントが依存するクライアントにIDを証明できるようにすることはできません。
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リファレンス実装に実装された5つのスキームがIDを証明するために実装されています。4）修正されたGuillou-Quisquater（GQ）アルゴリズム、および（5）修正されたMu-Varadharajan（MV）アルゴリズム。これらのすべてが同じレベルの保護を提供するわけではなく、1つの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]に記載されている従来の証明書のトレイルが含まれます。これは、IDスキームが不要な場合のデフォルトスキームです。残りのアイデンティティスキームには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.
残りの3つのスキームIFF、GQ、およびMVには、複数の交換の繰り返しの観測の後でも、侵入者がサーバーキーを推測できない暗号化的に強力な課題反応交換が含まれます。さらに、MVスキームは、サーバーまたはクライアントのいずれかがその値を知らずにサーバーが正しいグループキーを持っていることを確認できるため、ゼロ知識証明として適切に説明されています。これらのスキームは、クライアントがサーバーにノンセを送信し、それが独自の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秒の形でタイムスタンプを運びます。システムクロックがプロバンティックソースに同期されている場合、有効な（ゼロ以外の）タイムスタンプで署名が生成されます。それ以外の場合、署名はなく、タイムスタンプは無効です（ゼロ）。プロトコルは、値が使用されるか、署名が検証される前に、古いまたは重複したタイムスタンプで拡張フィールドを検出および破棄します。
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:
署名は、暗号化値が作成または変更された場合にのみ計算されます。これらの署名を運ぶ拡張フィールドは、必要に応じてメッセージにコピーされますが、署名は再計算されません。3つの署名タイプがあります。
1. Cookie signature/timestamp. The cookie is signed when created by the server and sent to the client.
1. クッキー署名/タイムスタンプ。Cookieは、サーバーによって作成されたときに署名され、クライアントに送信されます。
2. Autokey signature/timestamp. The autokey values are signed when the key list is created.
2. Autokey Signature/Timestamp。キーリストが作成されたときに、Autokey値が署名されます。
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. パブリックバリューシグネチャー/タイムスタンプ。公開鍵、証明書、および跳躍値は、生成時に署名されます。これは、システムクロックが最初にプロバンティックソースに同期されたとき、値が変更された場合、およびその後1日あたり約1回で発生します。かわった。
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.
プロトコルで使用されるすべての暗号値は時間感受性が高く、定期的に更新されます。特に、署名および暗号化アルゴリズムで使用される暗号化値を含むファイルは、時々再生されます。ファイルの再生は、特定の事前警告なしで、ファイルの内容を事前に配布することなく発生することを意図しています。暗号化データファイルは具体的に署名されていませんが、すべてのファイルは、作成エポックでNTP秒を示すFilestampに関連付けられています。
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.
Filestampsとタイムスタンプは、任意の組み合わせで比較し、同じ規則を使用できます。それらを時々比較して、どちらが早いかそれ以降であるかを判断する必要があります。これらの数量は2番目に粒度しかないため、値が同じ秒にある場合、そのような比較はあいまいです。
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.
Filestampsが証拠データであることが重要です。したがって、プロデューサーが証人の情報源に同期していない限り、それらを生産することはできません。そのため、NTPサブネット全体のFilestampsは、すべての作成エポックの部分的な順序を表し、古いデータを削除し、新しいデータが一貫していることを確認する手段として機能します。データがサーバーからクライアントに転送されるため、証明書および跳躍等値の値を含むFilestampsは保存されます。古いFilestampを持つパケットは、サイクルを費やして署名を確認する前に破棄されます。
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プロトコルには、クライアント/サーバー、対称、ブロードキャストの3つの主要な操作モードがあり、それぞれに独自の自動機関プログラムまたはダンスがあります。Autokey Choreographyは、侵入していないように設計されており、通常のNTP操作以外の追加パケットを必要としません。NTPとAutokeyプロトコルは、同時に独立して動作します。ダンスが完了すると、後続のパケットは自動操作シーケンスによって検証され、したがってプロボンティックとも考えられます。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.
サーバーダンスは、スティーブケントがしばらく前に昼食時に提案されましたが、その食事以来かなり修正されました。サーバーは、クライアントごとに状態を保持しませんが、高速アルゴリズムと32ビットのランダムなプライベート値（サーバーシード）を使用して、クライアントパケットの到着時にCookieを再生します。Cookieは、クライアントとサーバーアドレスから計算されたAutokeyの最初の32ビット、キーIDゼロ、サーバーシードとしてCookieとして計算されます。Cookieは、クライアントとサーバーの両方による実際のAutokey計算に使用されるため、各クライアントに個別に固有です。
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を使用して、Autokeyを取得してMacを生成します。サーバーは同じ値を使用してメッセージを生成し、Macに一致するメッセージを検証します。次に、同じ値を使用して応答のMACを生成しますが、クライアントとサーバーのアドレスは交換されます。クライアントはメッセージを生成し、Macに一致するメッセージを確認します。古いリプレイをそらすために、クライアントは、キー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.
ブロードキャストダンスでは、クライアントは通常、最初に起動する場合を除き、サーバーにパケットを送信しません。その時点で、クライアントはサーバーダンスを実行してサーバーの資格情報を確認し、伝播遅延を調整します。ダンスは、同じサーバーで複数の動作が可能になる可能性があるため、特定のサーバーアソシエーションの関連付けを必要とします。この目的のために、サーバーパケットには、送信されるすべての応答メッセージにAssociation IDが含まれ、新しいキーリストを生成した後に最初のパケットを送信すると、Autokey値も送信されます。Autokey値を取得および検証した後、拡張フィールドは必要ありません。クライアントはAutokeyシーケンスを使用してさらにサーバーパケットを検証します。
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が単純な非CEであることを除いて、サーバーダンスに似た方法で伝えられます。他のピアからCookie応答を受信する前に、各ピアがCookieリクエストを送信する可能性のあるレース条件が存在します。この場合、各ピアは2つの値で巻き上げられます。1つは生成され、もう1つは生成されます。あいまいさは、2つの値の展望として作業Cookieを計算するだけで解決されます。
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.
Autokey Danceが完了すると、通常は休眠状態になります。ブロードキャストダンスを除いて、パケットが新しいキーリストを生成した後に最初に送信されたものである場合、またはクライアントがCookieまたはAutokey値を要求しない限り、パケットが拡張フィールドなしで通常送信されます。何らかの理由でクライアントクロックが段階的に段階的に段階的になっている場合、すべての関連付けのすべての暗号化と時間の値がパージされ、すべての関連付けのダンスがゼロから再起動されます。これにより、古い値がクロックステップを超えて伝播しないようになります。
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 and filestamp, where applicable. Only if the packet has correct format, length, and message digest are cycles spent to verify the signature.
Autokey Protocol Dataユニットは拡張フィールドであり、そのうち1つ以上はNTPパケットでピギーバックできます。拡張フィールドには、オプションのデータを使用した要求またはオプションのデータを使用した応答のいずれかが含まれます。デッドロックを避けるために、任意の数の応答をパケットに含めることができますが、1つのリクエストのみが可能です。要求者がプロボンティックソースに同期されていない場合でも、リクエストごとに応答が生成されますが、ほとんどの場合、対応者がプロバンティックソースに同期している場合にのみ意味のあるデータが含まれています。一部のリクエストとほとんどの応答には、タイムスタンプ付き署名があります。署名は、該当する場合、タイムスタンプと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.
現在、8つのオートケイリクエストと8つの対応する応答があります。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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ 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-OCTET（Word）の境界にゼロパッドされていますが、拡張機能全体は単語整列ではありません。長さのフィールドは、長さとパディングフィールドを含む拡張フィールド全体をカバーします。最小フィールドの長さは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.
1つ以上の拡張フィールドは、NTPパケットヘッダーに続き、最後に続くMACが続きます。拡張フィールドパーサーは、NTPパケットヘッダーを越えて最初のオクテットへのポインターを初期化し、パケットの最後まで残っているオクテットの数を計算します。残りの長さが20（128ビットダイジェストと4-OCTETキーID）または22（160ビットダイジェストと4-OCTETキー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はAutokeyのために予約されています。他のアプリケーションには、その他の値が割り当てられる場合があります。6ビットコードフィールドは、リクエストまたは応答操作を指定します。2つのフラグビットがあります。ビット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ビットDIMの両方で指定された操作コードを持つサーバーにリクエストを送信します。サーバーは、コードフィールドに同じ操作コードを使用して応答を返し、Rビットを点灯します。サーバーは、エラーが発生した場合にeビットに火をつけることもできます。一致するリクエストなしで未承諾の応答を送信することは必ずしもプロトコルエラーではないことに注意してください。RビットがDIMである場合、クライアントはAssociation IDフィールドをクライアントアソシエーションIDに設定し、サーバーが確認のために戻ります。2つの値が一致しない場合、応答は送信されないかのように破棄されます。Rビットが点灯している場合、Association IDフィールドは、初期プロトコル交換で取得されたサーバーアソシエーションIDに設定されます。Association IDフィールドがMobilized Association 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.
場合によっては、すべてのフィールドが存在するわけではありません。リクエストの場合、クライアントが証人ソースに同期するまで、署名は無効です。そのような場合、タイムスタンプフィールドと署名長フィールド（署名の長さを指定）はゼロであり、署名フィールドは存在しません。一部のリクエストおよびエラー応答メッセージには、値または署名フィールドが含まれていないため、これらのメッセージでは、最初の2つの単語（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.
タイムスタンプとFilestampの単語には、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.
署名とタイムスタンプは、署名ホストがプロバンティックソースに同期している場合にのみ有効です。それ以外の場合、タイムスタンプはゼロです。暗号化データファイルは、署名が可能な場合にのみ生成できます。それ以外の場合は、Assoc Responseメッセージを除き、サーバーステータスワードが含まれている場合を除き、Filestampはゼロです。
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）は、暗号化として使用できる空の応答を返すこと以外は何もしません。
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フィールドのサーバーステータスワードと、値フィールドにAutokeyホスト名が含まれています。Autokeyホスト名は、必ずしもDNSホスト名ではありません。有効な応答は、Association Status Wordの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.
複数のアイデンティティスキームがサポートされている場合、ホストステータスワードが使用可能なものを決定します。サーバーモードと対称モードでは、応答ステータスワードには、サポートされているスキームに対応するビットが含まれています。すべてのモードで、スキームは、スタートアップ時にロードされるクライアントIDパラメーターに基づいて選択されます。
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）が証明書交換で使用され、件名名で証明書を取得します。リクエストには件名が含まれています。応答には、付録Hに記載されているように、asn.1構文を使用してx.509形式でエンコードされた証明書が含まれています。
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）は、サーバークッキーを取得するためにサーバーモードと対称モードで使用されます。リクエストには、付録Hで説明されているように、asn.1構文でエンコードされたホスト公開キーが含まれています。応答には、リクエストの公開キーによって暗号化されたCookieが含まれています。有効な応答は、Association Status Wordの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.
Autokeyメッセージ（コード4）は、Autokey値を取得するために使用されます。リクエストには、クライアントの値が含まれていないのは、対称ピアの自動化された値です。応答には2つの32ビット単語が含まれています。1つ目は最終キーID、2つ目は最終キーIDのインデックスです。有効な応答は、Association Status Wordの自動ビットを点灯します。
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 Valuesメッセージ（コード5）は、国立標準技術研究所（NIST）からの跳躍テーブルから解析されたLeapseconds値を取得するために使用されます。リクエストには値が含まれていません。応答には3つの32ビット整数が含まれています。最初に、最新のLEAPイベントのNTP秒で、最新のNISTテーブルが失効したNTP秒、次にLEAPイベントに続いてTAIオフセットが続きます。有効な応答は、Association Status Wordの跳躍ビットを照らします。
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）は、サーバーがリクエストに提示された証明書をサインし、返すように要求します。リクエストには、付録Hで説明されているように、ASN.1構文を使用してX.509形式でエンコードされたクライアント証明書が含まれています。応答には、サーバーの秘密キーによって署名されたクライアント証明書が含まれています。有効な応答は、協会のステータスワードのサインビットを照らします。
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ビットのノンセが含まれています。応答には、付録Bで定義された数学操作の結果が含まれています。応答は、付録Hで説明されているようにASN.1構文でエンコードされています。
This section describes the formal model of the Autokey state machine, its state variables and the state transition functions.
このセクションでは、Autokey State Machineの正式なモデル、その状態変数、および状態遷移関数について説明します。
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ビットはOpenSSLライブラリによって生成された数値識別子（NID）を指定します。[RFC3279]で定義されているメッセージダイジェスト/署名暗号化スキームの1つのOIDの。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 |
+------------------------+----------------------+-----+
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はクライアントの使用のために予約されています。ホスト部分では、BITS 24-27は利用可能なアイデンティティスキームを指定し、ビット28-31はサーバー機能を指定します。別々に実装された2つの追加ビットがあります。
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 RequestおよびResponseメッセージに含まれています。クライアントは、この単語をAssociation Status Wordにコピーし、ダンスが進むにつれて追加のビットを照らします。有効になると、これらのビットは通常、一般的なリセットが発生し、プロトコルが最初から再起動されない限り、暗くなることはありません。
The host status bits are defined as follows:
ホストステータスビットは次のように定義されます。
o ENAB (31) is lit if the server implements the Autokey protocol.
o サーバーがAutokeyプロトコルを実装する場合、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 LVAL（30）は、NIST Leapsecondsファイルまたは別のサーバーから、サーバーがLeapseconds値をインストールしている場合に点灯します。
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どのサーバーIDスキームが利用可能かを選択します。さまざまなスキームの特定のコーディングはまだ決定されていませんが、参照実装で利用可能なスキームと付録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 PCスキームは、他のスキームを除いています。それ以外の場合、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）：信頼できるホストID資格情報が確認されたときに点灯します。
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）：サーバーの署名が公開キーとID資格情報を使用して検証されたときに点灯します。また、このメモの他の場所でプロボンティックビットとも呼ばれます。有効にすると、後続のメッセージで署名された値が推定されます。
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 Auto（19）：Autokey値が受信され、検証されたときに点灯します。点灯すると、クライアントはAutokeyシーケンスに従って拡張フィールドなしでパケットを検証できます。
o SIGN (18): Lit when the host certificate is signed by the server.
o 署名（18）：ホスト証明書がサーバーによって署名されたときに点灯します。
o LEAP (17): Lit when the leapseconds values are received and validated.
o Leap（17）：leapseconds値が受信および検証されたときに点灯します。
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.
Association Status Wordに含まれていないリスト、同期、およびピアの3つの追加ビットがあります。キーリストが再生され、自動化された値が送信されたときに薄暗い場合、リストが点灯します。これは、いくつかの条件下でライブロックを避けるために必要です。クライアントがプロボンティックソースに同期し、その後に暗くなることはない場合、同期が点灯します。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 IDスキームで使用されるパラメーター
GQ Parameters: The parameters used in the optional GQ identity scheme described in Appendix B.
GQパラメーター：付録Bで説明されているオプションのGQ IDスキームで使用されるパラメーター
MV Parameters: The parameters used in the optional MV identity scheme described in Appendix B.
MVパラメーター：付録Bで説明されているオプションのMV IDスキームで使用されるパラメーター
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.
証明書自体は、ネットワークバイトの順序で拡張フィールドとして保存されるため、メッセージにそのままコピーできます。構造は、署名キーを使用して署名され、署名時間と元の証明書ファイルのFilestampでパブリックバリュータイムスタンプを搭載しています。構造は、CERT応答メッセージと署名リクエストと応答メッセージによって使用されます。
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） - 証明書は、信頼できる発行者によって署名されています。証明書が自己署名されており、拡張されたキー使用フィールドに「Trustrot」が含まれている場合、CISが構築されるとこのビットが点灯します。
* 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） - 証明書署名が検証されました。含まれている公開キーを使用して証明書が自己署名および検証されている場合、CISが構築されるとこのビットが点灯します。
* 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） - 証明書はプライベートであり、明らかにされるべきではありません。証明書が自己署名されており、拡張された主要な使用状況フィールドに「プライベート」が含まれている場合、CISが構築されるとこのビットが点灯します。
* 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.
証明書リスト：CIS構造は到着順に証明書リストに保存され、最近受信したCIがリストに最初に配置されます。リストは、ホスト証明書ファイルから読み取られるホスト証明書のCISで初期化されます。証明書交換中にサーバーから証明書が取得されるため、追加のCISエントリがリストに追加されます。CISエントリは、新しいエントリに追い抜かれた場合に破棄されます。
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 RequestおよびResponseメッセージを送信するために使用されます。ホストステータスワードとホスト名が含まれています。
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 Responseメッセージの送信に使用されます。Leapメッセージの説明にLeapseConds値が含まれています。
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.
Associationステータスワード：Assoc Responseからコピーされたステータスワード。その後、状態マシンによって変更されました。
Subject Name: The server host name copied from the ASSOC response.
件名：Assoc Responseからコピーされたサーバーホスト名。
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.
グループキー：ID交換で使用される値のセット。サーバーとクライアントが共有する暗号化コンパートメントを識別します。
Receive Cookie Values: The cookie returned in a COOKIE response, together with its timestamp and filestamp.
クッキーの値を受け取る：クッキーは、そのタイムスタンプとフィルスタンプとともに、クッキー応答で返されます。
Receive Autokey Values: The autokey values returned in an AUTO response, together with its timestamp and filestamp.
Autokey Valuesを受け取る：Autokey Valuesは、そのタイムスタンプとFilestampとともに、自動応答で返されます。
Send Autokey Values: The autokey values with signature and timestamps.
Autokey Values：Signature and TimestampsでAutokey Valuesを送信します。
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.
キーリスト：Autokey Seedから始まり、それぞれが次を指しているキー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.
プロトコル状態マシンは非常にシンプルですが堅牢です。状態は、上記のクライアントステータスワードビットによって決定されます。3つのダンスの状態遷移を以下に示します。大文字の真理値は、クライアントステータスビットを表します。すべてのビットは暗いものとして初期化され、上記のように特定の応答メッセージが到着すると点灯します。
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.
サーバーダンスは、クライアントがサーバーにアソシエイトリクエストを送信すると始まります。時計は前に照らされたときに更新され、跳躍が点灯するとダンスが終了します。このダンスでは、自動化された値は使用されていないため、自動操作交換は必要ありません。クライアントがプロバンティックソースに同期するまで、サインと跳躍のリクエストは発行されないことに注意してください。拡張フィールドのない後続のパケットは、Autokeyシーケンスによって検証されます。この例と他の例では、IFF IDスキームがパラメーター交換で選択されていると想定しています。
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.
放送ダンスは、Autokey Values Exchangeに置き換えられたCookie Exchangeとともに、サーバーダンスに似ています。ブロードキャストダンスは、クライアントがサーバーアソシエーションIDとの関連応答を含むブロードキャストパケットを受信すると始まります。これにより、ソースを証明し、伝播遅延を調整するために、クライアント協会を動員します。Leap Bitが点灯するとダンスは終了し、その後、クライアントはそれ以上のパケットを送信しません。通常、ブロードキャストサーバーには、送信された各パケットにAssoc Responseが含まれます。ただし、サーバーが新しいキーリストを生成すると、代わりに自動応答が含まれます。
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
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.
パケットが紛失し、自動機関のシーケンスが壊れている場合、クライアントは、以前のオートケイまたはハッシュ数がAutokey値で指定されたカウントを超えるまで、現在のオートケイをハッシュします。後者の場合、クライアントは自動値を取得するための自動要求を送信します。クライアントがダンス中に暗号NAKを受け取った場合、またはAssociation 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リクエストを送信すると始まります。受動的なピアは協会を動員し、両方のピアは各ピアが他のピアとパラメーター交換を完了する3ウェイダンスをステップします。ピアの1人がプロボンティックソース（他のピアになる可能性がある）に同期し、メッセージに署名することができるまで、他のピアループは次の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 }
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.
ピアがプロバンティックソースに同期すると、メッセージにタイムスタンプの署名が含まれます。有効なタイムスタンプを待って停滞しているもう1人のピアは、今ではダンスを交尾させています。Cookie Exchangeを使用して、現在ゼロ以外のCookieを取得し、Autokey Exchangeを使用して更新されたAutokey値を取得します。
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.
ブロードキャストダンスのように、パケットが失われ、自動シーケンスが壊れた場合、ピアは、以前の自動化と一致するか、ハッシュの数が自動化された値で与えられたカウントを超えるまで現在の自動をハッシュします。後者の場合、クライアントは自動値を取得するための自動要求を送信します。ピアがダンス中にCrypto-Nakを受け取った場合、またはAssociation 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.
Autokey Protocol Stateマシンには、敵対的な侵入は言うまでもなく、ファイルが欠落している、破損したデータ、プロトコル違反、パケットの損失またはMisorderが発生する可能性のあるさまざまな種類のエラー条件の規定が含まれています。このセクションでは、プロトコルがそのようなエラーのために発生する可能性のある到達可能性とタイムアウトイベントにどのように応答するかについて説明します。
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ビットリーチレジスタと未到達のカウンターを維持する2つの変数があります。すべての投票間隔で、リーチレジスタが左にシフトされ、低いオーダービットが暗くなり、高次ビットが失われます。同時に、未eachカウンターは1つずつ増加します。到着するパケットがすべての認証と正気のチェックに合格した場合、Reachレジスタの右端のビットが点灯し、Unreachカウンターがゼロに設定されます。Reach Registerに少し照らされている場合、サーバーは到達可能です。そうでなければ、それは到達できません。
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.
協会から最初の投票が送信されると、Reach RegisterとUnreachカウンターはゼロに設定されます。未eachカウンターが16に達すると、投票間隔が2倍になります。さらに、関連性が持続的である場合、動員解除されます。これにより、応答を引き出す可能性が低いパケットのネットワーク負荷が削減されます。
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が無効になっているため、サーバーは次のクライアントリクエストを拒否し、Crypto-Nakパケットを返します。Crypto-NakにはMACがないため、クライアントにとっての問題は、それが合法か侵入者のいたずらの結果であるかを判断することです。そのような場合の脆弱性を減らすために、Crypto-Nakおよびすべての応答は、NTPオンワイヤープロトコルで確認されているように、リプレイではなくクライアントから送信された以前のパケットの結果が場合にのみ考えられます。この防御は中間の男によって簡単に回避することができますが、他の種類の侵入者の戦争をそらすことができます。
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.
このセクションでは、さまざまなオートケイダンスにおける最も明白なセキュリティの脆弱性について説明します。次の議論では、暗号化アルゴリズムとプライベートバリュー自体が安全であると想定されています。つまり、ブルートフォースの暗号化攻撃では、ホストの秘密鍵、署名の秘密鍵、クッキー値、アイデンティティパラメーター、サーバーシード、または自動シードが明らかになりません。さらに、侵入者はランダムジェネレーター値を予測することができません。
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オンワイヤープロトコルは、クロックが同期していなくても、紛失、複製、および偽のパケットに耐性があるため、プロトコルは盗聴者攻撃に対して脆弱ではありません。ワイヤーオンワイヤープロトコルは、クライアントリクエストパケットとサーバーの応答パケットの両方のリプレイに耐性があります。中間の攻撃は、有効な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.
ブロードキャストダンスでは、クライアントはクライアント/サーバーモードのボレーから始まり、自動化された値と署名を取得するため、そのモードと同じ保護があります。受信専用モードで継続する場合、盗聴者は有効な署名された自動化値を備えたキーリストを作成できません。古いパケットを再生すると、クライアントはタイムスタンプチェックによって拒否されます。それができることは、将来のパケットを製造することで、クライアントが最大キー数を超えるまで自動ハッシュ操作を繰り返すことです。これが発生した場合、ブロードキャストクライアントは一時的にクライアントモードに戻り、Autokey値を更新します。
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.
仮定することで、パケットを傍受する中間の攻撃者は、ワイヤーを破壊したり、傍受されたパケットを遅らせることはできません。この仮定が削除された場合、Middlemanはブロードキャストパケットを傍受し、クライアントによる検出せずにデータとメッセージダイジェストを置き換えることができます。
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 IDスキームのいずれかを使用する必要があります。
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.
クライアントは、サーバーがプロバンティックソースに同期されている場合にのみ、暗号化変数をインスタンス化します。サーバーは、プロバンティックソースに同期しない限り、値に署名したり、暗号化データファイルを生成したりしません。これは興味深い問題を提起します。クライアントは、それがこれまでにプロボンシックのソースに同期される前に、どのようにして証明の暗号化ファイルを生成しますか？（理髪師が自分自身を剃らない町のすべての人を剃る場合、誰が理髪師を剃りますか？）原則として、このパラドックスは、一次（層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.
署名はデータが変更され、データがあまり頻繁に変更されない場合にのみ計算されるため、自己誘発の詰まりインシデントは発生することはできません。たとえば、Autokey値はキーリストが再生された場合にのみ署名されます。これは1時間に1回程度発生しますが、パブリック値はダンス中に更新されるか、サーバーシードが更新される場合にのみ署名されます。1日あたり。
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.
プロトコルの設計には2つの詰まり脆弱性が暴露されています。侵入者が不必要な暗号計算で被害者サーバーを詰まらせることを望んでいる暗号化攻撃と、侵入者が不必要な暗号計算で被害者のクライアントを詰まらせようとする復号化攻撃です。Autokekeyは、公開キーの暗号化と、これらの機能を実行するアルゴリズムを使用して、重要なリソースを消費します。
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 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 |
+------------+------------------------------------------+
[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 5905、2010年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）仕様、実装」、RFC 1305、1992年3月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412] Orman、H。、「The Oakley Key Deicination Protocol」、RFC 2412、1998年11月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Phyuris：Session-Key Management Protocol」、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 Proof-of-Possession Algorithms」、RFC 2875、2000年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、「Internet X.509公開キーインフラストラクチャ証明書管理プロトコル（CMP）」、RFC 4210、2005年9月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年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 5280、2008年5月。
[SCHNORR] Schnorr, C., "Efficient signature generation for smart cards", 1991.
[Schnorr] Schnorr、C。、「スマートカードの効率的な署名生成」、1991年。
[STINSON] Stinson, D., "Cryptography - Theory and Practice", 1995.
[スティンソン]スティンソン、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.
ホストが起動すると、継続的な操作に必要なホストキーとホストの証明書ファイルを読み取ります。また、利用可能な場合は、サインキーと跳躍値を読み取ります。これらのファイルを読み取るとき、ホストはファイル形式とFilestampの有効性をチェックします。たとえば、すべてのFileStampは、1972年にUTCタイムスケールが設立された時よりも遅くなければならず、証明書Filestampは、関連する署名キーFilestampよりも早くてはなりません。ファイルが読み取られたとき、ホストは同期されていないため、これらの単純なチェックを使用する以外にFilestampsが偽物であるかどうかを判断することはできません。プロティックソースに同期するまで、フィルスタンプやタイムスタンプを生成してはなりません。
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の前に発生する場合に当てはまります。つまり、イベントが同時にある場合は偽です。FilestampsやFilestampsと比較したタイムスタンプの場合、A < - > Bの場合、関係はこれらの主張で現在の時間がこれらの主張で役割を果たしていないことに注意してください。ただし、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とFilestamp F0を保存します。タイムスタンプT1とFileStamp 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およびfileStamp 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. 署名キーFileStamp S、証明書FileStamp C、Cookie Timestamp DおよびAutokey Timestamp A、S-> C-> D-> A;つまり、Autokeyは、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. 署名キーFilestamp sおよび証明書Filestamp cを指定します。つまり、有効な期間が遡及的であってはなりません。
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 Obtoletesと署名した被験者Sの証明書。
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は現在の証拠時間です。証明書から以前に抽出された公開鍵は、無期限に有効であることに注意してください。これにより、クライアントがプロバンティックソースに同期するまで、有効期限が切れた証明書または有効な証明書を持つFalsetickerが検出されないという興味深い可能性が高まります。
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参照実装には5つのIDスキームがあります：（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スキームは、証明書のトレイルを使用しますが、IDスキームではありません。IFF、GQ、およびMVのIDスキームは、複数の交換の繰り返しの観測の後でも、侵入者がグループキーを学習できない暗号的に強力なチャレンジ応答交換を使用します。これらのスキームは、クライアントがサーバーにノンセを送信し、それが独自のNONCEを転がし、数学的操作を実行し、結果をクライアントに送信するときに始まります。クライアントは、サーバーがクライアントと同じグループキーを持っていることを証明するために、2番目の数学操作を実行します。
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
Figure 12: Private Certificate (PC) Identity Scheme
図12：プライベート証明書（PC）IDスキーム
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の拡張キー使用量拡張フィールドが存在し、「プライベート」が含まれている場合、証明書はプライベートに指定されます。秘密証明書は、秘密の手段によって他のすべてのグループメンバーに配布されるため、実際には対称キーになります。プライベート証明書も信頼されているため、証明書のトレイルまたはIDスキームは必要ありません。
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 |
+-----------+ +-----------+ +-----------+
Figure 13: Trusted Certificate (TC) Identity Scheme
図13：信頼できる証明書（TC）IDスキーム
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」が含まれている場合に信頼されています。パラメーター交換でIDスキームが指定されていない場合、これがデフォルトスキームです。
Appendix E. Schnorr (IFF) Identity Scheme
付録E. Schnorr（IFF）IDスキーム
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
Figure 14: Schnorr (IFF) Identity Scheme
図14：Schnorr（IFF）IDスキーム
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]（p。285）で説明されているアルゴリズムを変更します。パラメーターはOpenSSLライブラリのルーチンによって生成されますが、Moduli P、Q、およびGenerator Gのみが使用されます。Pは512ビットプライムで、gは乗法グループZ_P*の発電機とq A 160ビットプライム（p-1）で、1 mod pのqthルートです。つまり、g^q = 1 mod p。TAはプライベートランダムグループキーK（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は、IFFパラメーターとキーをOpenSSL DSAカッコウ構造に隠します。IFFパラメーターはDSAパラメーターと同一であるため、OpenSSLライブラリを直接使用できます。図15に示す構造は、PEMでエンコードされたDSA秘密キーとしてファイルに書き込まれます。未使用の構造メンバーは1つに設定されています。
+----------------------------------+-------------+
| 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 IDスキーム構造
Alice challenges Bob to confirm identity using the following protocol exchange.
アリスはボブに挑戦し、次のプロトコル交換を使用してアイデンティティを確認します。
1. Alice rolls random r (0 < r < q) and sends to Bob.
1. アリスはランダムr（0 <r <q）を転がし、ボブに送ります。
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. ボブはランダムk（0 <k <q）、y = k br mod qとx = g^k mod pを計算し、（y、hash（x））をアリスに送信します。
3. Alice computes z = g^y * v^r mod p and verifies hash(z) equals hash(x).
3. アリスは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.
ハッシュが一致する場合、アリスはボブにグループキーを持っていることを知っていますb。応答を短くすることに加えて、ハッシュにより、これらのメッセージの多くを観察することにより、侵入者がBを解決することは事実上不可能になります。署名された応答は、この知識をボブの秘密鍵に結び付け、公開鍵は以前に証明書で受け取った。
Appendix F. Guillard-Quisquater (GQ) Identity Scheme
付録F. Guillard-Quisquater（GQ）IDスキーム
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
Figure 16: Schnorr (IFF) Identity Scheme
図16：Schnorr（IFF）IDスキーム
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]（p。300）（エラー付き）に記載されているアルゴリズムの変更です。パラメーターはOpenSSLライブラリのルーチンによって生成されますが、Moduli 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.
+---------------------------------+-------------+
| 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 IDスキーム構造
Alice challenges Bob to confirm identity using the following exchange.
アリスはボブに挑戦し、次の交換を使用して身元を確認します。
1. Alice rolls random r (0 < r < n) and sends to Bob.
1. アリスはランダムr（0 <r <n）を転がし、ボブに送ります。
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. ボブはランダムk（0 <k <n）を転がし、y = ku^r mod nとx = k^b mod nを計算し、（y、hash（x））をアリスに送信します。
3. Alice computes z = (v^r)*(y^b) mod n and verifies hash(z) equals hash(x).
3. アリスは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.
ハッシュが一致する場合、アリスはボブに対応するサーバーキーuがあることを知っています。応答を短くすることに加えて、ハッシュにより、これらのメッセージの多くを観察することにより、侵入者がUを解決することは事実上不可能になります。署名された応答は、この知識をボブの秘密鍵に結び付け、以前に彼の証明書で受け取ったクライアントキーに結び付けます。
Appendix G. Mu-Varadharajan (MV) Identity Scheme
付録G. Mu-Varadharajan（MV）IDスキーム
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スキームは、おそらく3つのチャレンジ/応答スキームの中で最も興味深く柔軟ですが、悪魔のように複雑です。少数のサーバーが、サーバーとクライアントの間で妥協するかなりのリスクがある可能性のある大規模なクライアント集団に同期を提供する場合に最も役立ちます。クライアント母集団は、それぞれが個々のクライアントキーに関連付けられている控えめな数のサブグループに分割できます。
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 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は、暗号化と復号化キーを含む複雑な暗号システムと、多くのアクティベーションキーと関連するクライアントキーを生成します。TAは、クライアントキー自体を変更せずに、個々のクライアントキーをアクティブにして取り消すことができます。TAは、暗号化キーEと、アクティブ化されたキーに依存する部分的な復号化キーG-BARおよびG-HATをサーバーに提供します。サーバーには追加情報がなく、特に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ガマル暗号化と同様の暗号化アルゴリズムを使用し、製品用語（x-x_1）（x-x_2）（x-x_3）...（x-x_n）の拡張から形成された多項式を使用します。]。この論文には、重大なエラーと深刻な省略があります。暗号システムは、すべての暗号化キーに対して、その逆数が（g-bar^x-hat_j）（g-hat^x-bar_j）mod pがすべてのjに対して（g-hat^x-bar_j）mod pを構築します。これは、両方の量がパワー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
Figure 18: Mu-Varadharajan (MV) Identity Scheme
図18：Mu-Varadharajan（MV）IDスキーム
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 structure used by the servers, while Figure 20 shows the client data structure associated with each activation key.
TAは、OpenSSL DSA Cuckoo構造のMVパラメーターとキーを隠します。MVパラメーターはDSAパラメーターと同一であるため、OpenSSLライブラリを直接使用できます。以下の図に示されている構造は、PEMでエンコードされたFKEYとしてファイルに書かれています。未使用の構造メンバーは1つに設定されています。図19は、サーバーで使用されているデータ構造を示しています。図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 | |
+---------+----------+------------+-------------+
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 | |
+---------+----------+------------+-------------+
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.
アリスはボブに挑戦し、次の交換を使用して身元を確認します。
1. Alice rolls random r (0 < r < q) and sends to Bob.
1. アリスはランダムr（0 <r <q）を転がし、ボブに送ります。
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. ボブはランダム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）をアリスに送信します。
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. アリスはセッション復号化キーe^-1 =（g-bar-prime）^x-hat_j（g-hat-prime）^x-bar_j mod pを計算し、r = e^-1 xを確認します。
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（）ルーチンによってエンコードされた2つの整数（n、e）のシーケンスが含まれています。リクエストでは、nはビットのRSAモジュラスであり、Eはパブリックエクスポーネントです。
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（）ルーチンによってエンコードされた2つの整数（R、S）のシーケンスが含まれています。応答では、Rはチャレンジ応答であり、Sはプライベート価値のハッシュです。
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（）ルーチンによってエンコードされた3つの整数（P、Q、G）のシーケンスが含まれています。応答では、pは暗号化されたチャレンジ値のハッシュであり、（q、g）は復号化キーのクライアント部分です。
DSAparameters ::= SEQUENCE {
p ::= INTEGER,
q ::= INTEGER,
g ::= INTEGER
}
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:
証明書拡張フィールドは、IDスキームで使用される情報を伝えるために使用されます。これらのフィールドのセマンティクスは一般に従来の使用に準拠していますが、微妙なバリエーションがあります。Autokekeyバージョン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 基本的な制約。このフィールドは、証明書の基本機能を定義します。文字列「クリティカル、CA：true」が含まれています。つまり、フィールドを解釈する必要があり、関連する秘密鍵を使用して他の証明書に署名できます。互換性のために含まれていますが、Autokekeyはこのフィールドを使用しません。
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」が含まれています。つまり、含まれる公開キーを使用して、データやその他の証明書の署名を確認することができます。互換性のために含まれていますが、Autokekeyはこのフィールドを使用しません。
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 拡張された主要な使用法。このフィールドは、証明書に含まれる公開キーの意図された使用をさらに洗練し、自己署名証明書にのみ存在します。証明書がプライベートに指定されている場合は「プライベート」が含まれています。民間証明書は常に信頼されています。
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 IDスキームで使用されるクライアントIDキーが含まれています。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証明書が含まれています。エンコーディングは、X.509V3拡張フィールドの使用を含む[RFC5280]に記載されているルールに従います。
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.
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秒を使用します。署名は、証明書に署名するために使用されるメッセージダイジェスト/署名暗号化スキームのオブジェクト識別子です。SignatureAlgorithmと同じでなければなりません。
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
}
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
}
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.
Autokeyプロトコル自体には、証明書を取り消す規定がないことに注意する必要があります。参照実装は、意図的に週に1回約1回再起動され、証明書の再生とAutokeyプロトコルの再起動につながります。この再起動は、Autokeyプロトコルではなく、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.
各グループホストは、一度に1つの証明書のみで動作し、誘導によりトレイルを構築します。グループ構成は、信頼できるホストにルーツを持つ非環式グラフを形成する必要があるため、おそらくいくつかの署名証明書が使用されていることは問題ではありません。参照実装では、単一の証明書を選択し、プロトコルが再起動されるまでその証明書のみで動作します。
Authors' Addresses
著者のアドレス
Brian Haberman (editor) The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ブライアン・ハーバーマン（編集者）ジョンズ・ホプキンス大学応用物理学研究所11100ジョンズ・ホプキンス・ロード・ローレル、MD 20723-6099 US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Dr. David L. Mills University of Delaware Newark, DE 19716 US
デビッドL.ミルズ大学デラウェア大学ニューアーク、19716年米国
Phone: +1 302 831 8247
EMail: mills@udel.edu