[要約] RFC 8915は、Network Time Protocol (NTP) に対するNetwork Time Security (NTS) の導入を規定しています。その目的は、時刻同期プロセスのセキュリティを強化し、改ざんや偽装から保護することです。利用場面としては、インターネット上で正確な時刻を提供・同期するシステムやデバイスに適用されます。
Internet Engineering Task Force (IETF) D. Franke
Request for Comments: 8915 Akamai
Category: Standards Track D. Sibold
ISSN: 2070-1721 K. Teichel
PTB
M. Dansarie
R. Sundblad Netnod September 2020
R. Sundblad Netnod 2020年9月
Network Time Security for the Network Time Protocol
ネットワークタイムプロトコルのネットワークタイムセキュリティ
Abstract
概要
This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).
このメモは、ネットワークタイムセキュリティ（NTS）、トランスポートレイヤセキュリティ（TLS）を使用するためのメカニズム（AED）（AED）を使用して、ネットワークタイムプロトコル（NTP）のクライアントサーバモードの暗号化セキュリティを提供するためのメカニズム（AED）。
NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.
NTSは、2つの疎結合サブプロトコルのスイートとして構成されています。最初の（NTSキー確立（NTS-KE））は、TLSを介した初期認証と重要な確立を処理します。2番目（NTPv4のNTS拡張フィールド）は、NTPパケット内の拡張フィールドを介してNTP時間同期中に暗号化と認証を処理し、不透明なクッキーを介してクライアント上ですべての必要な状態を保持します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8915.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8915で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Objectives
1.2. Terms and Abbreviations
1.3. Protocol Overview
2. Requirements Language
3. TLS Profile for Network Time Security
4. The NTS Key Establishment Protocol
4.1. NTS-KE Record Types
4.1.1. End of Message
4.1.2. NTS Next Protocol Negotiation
4.1.3. Error
4.1.4. Warning
4.1.5. AEAD Algorithm Negotiation
4.1.6. New Cookie for NTPv4
4.1.7. NTPv4 Server Negotiation
4.1.8. NTPv4 Port Negotiation
4.2. Retry Intervals
4.3. Key Extraction (Generally)
5. NTS Extension Fields for NTPv4
5.1. Key Extraction (for NTPv4)
5.2. Packet Structure Overview
5.3. The Unique Identifier Extension Field
5.4. The NTS Cookie Extension Field
5.5. The NTS Cookie Placeholder Extension Field
5.6. The NTS Authenticator and Encrypted Extension Fields
Extension Field
5.7. Protocol Details
6. Suggested Format for NTS Cookies
7. IANA Considerations
7.1. Service Name and Transport Protocol Port Number Registry
7.2. TLS Application-Layer Protocol Negotiation (ALPN) Protocol
IDs Registry
7.3. TLS Exporter Labels Registry
7.4. NTP Kiss-o'-Death Codes Registry
7.5. NTP Extension Field Types Registry
7.6. Network Time Security Key Establishment Record Types
Registry
7.7. Network Time Security Next Protocols Registry
7.8. Network Time Security Error and Warning Codes Registries
8. Security Considerations
8.1. Protected Modes
8.2. Cookie Encryption Key Compromise
8.3. Sensitivity to DDoS Attacks
8.4. Avoiding DDoS Amplification
8.5. Initial Verification of Server Certificates
8.6. Delay Attacks
8.7. NTS Stripping
9. Privacy Considerations
9.1. Unlinkability
9.2. Confidentiality
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
This memo specifies Network Time Security (NTS), a cryptographic security mechanism for network time synchronization. A complete specification is provided for application of NTS to the client-server mode of the Network Time Protocol (NTP) [RFC5905].
このメモは、ネットワーク時刻のセキュリティ（NTS）、ネットワーク時間同期のための暗号化セキュリティメカニズムを指定します。ネットワークタイムプロトコル（NTP）[RFC5905]のクライアント - サーバモードにNTSをアプリケーションに適用するための完全な仕様が提供されています。
The objectives of NTS are as follows:
NTSの目的は次のとおりです。
* Identity: Through the use of a X.509 public key infrastructure, implementations can cryptographically establish the identity of the parties they are communicating with.
* ID：X.509公開鍵インフラストラクチャを使用することで、実装は通信している当局の身元を暗号化することができます。
* Authentication: Implementations can cryptographically verify that any time synchronization packets are authentic, i.e., that they were produced by an identified party and have not been modified in transit.
* 認証：実装は、いつでも同期パケットが本物であること、すなわちそれらが識別されたパーティーによって生成され、輸送中で修正されていないことを暗号化することができる。
* Confidentiality: Although basic time synchronization data is considered nonconfidential and sent in the clear, NTS includes support for encrypting NTP extension fields.
* 機密性：基本的な時刻同期データは非構成と見なされ、Clear NTSで送信されているが、NTSはNTP拡張フィールドを暗号化するためのサポートを含む。
* Replay prevention: Client implementations can detect when a received time synchronization packet is a replay of a previous packet.
* リプレイ防止：クライアント実装は、受信した時間同期パケットが前のパケットの再生である場合に検出できます。
* Request-response consistency: Client implementations can verify that a time synchronization packet received from a server was sent in response to a particular request from the client.
* 要求応答の一貫性：クライアント実装は、サーバーから受信した時間同期パケットがクライアントからの特定の要求に応答して送信されたことを確認できます。
* Unlinkability: For mobile clients, NTS will not leak any information additional to NTP which would permit a passive adversary to determine that two packets sent over different networks came from the same client.
* リンク不可能：モバイルクライアントの場合、NTSはNTPに追加の情報をリークしません。これは、パッシブの敵対者が異なるネットワーク上で送信された2つのパケットが同じクライアントからのものであると判断することを許可するであろう。
* Non-amplification: Implementations (especially server implementations) can avoid acting as distributed denial-of-service (DDoS) amplifiers by never responding to a request with a packet larger than the request packet.
* 非増幅：実装（特にサーバ実装）は、リクエストパケットよりも大きいパケットを有する要求に応答しないことによって、分散サービス拒否（DDOS）増幅器として機能することを回避することができる。
* Scalability: Server implementations can serve large numbers of clients without having to retain any client-specific state.
* スケーラビリティ：サーバー実装は、クライアント固有の状態を保持する必要なしに多数のクライアントを提供できます。
* Performance: NTS must not significantly degrade the quality of the time transfer. The encryption and authentication used when actually transferring time should be lightweight (see Section 5.7 of RFC 7384 [RFC7384]).
* 性能：NTSは時間転送の品質を大幅に低下させてはいけません。実際に転送時間を転送するときに使用される暗号化と認証は軽量であるべきです（RFC 7384 [RFC7384]のセクション5.7を参照）。
AEAD Authenticated Encryption with Associated Data [RFC5116]
関連データを使用したAED認証された暗号化[RFC5116]
ALPN Application-Layer Protocol Negotiation [RFC7301]
ALPNアプリケーション層プロトコルネゴシエーション[RFC7301]
C2S Client-to-server
C2Sクライアントからサーバーへ
DoS Denial-of-Service
DOS拒否
DDoS Distributed Denial-of-Service
DDOS分散されたサービス拒否
EF Extension Field [RFC5905]
EF拡張フィールド[RFC5905]
HKDF Hashed Message Authentication Code-based Key Derivation Function [RFC5869]
HKDFハッシュメッセージ認証コードベースのキー派生機能[RFC5869]
KoD Kiss-o'-Death [RFC5905]
KOD KISS-O'-Death [RFC5905]
NTP Network Time Protocol [RFC5905]
NTPネットワークタイムプロトコル[RFC5905]
NTS Network Time Security
NTSネットワークタイムセキュリティ
NTS NAK NTS negative-acknowledgment
NTS NAK NTS否定的な確認
NTS-KE Network Time Security Key Establishment
NTS-KEネットワークタイムセキュリティキー設立
S2C Server-to-client
S2Cサーバー間のクライアント
TLS Transport Layer Security [RFC8446]
TLSトランスポート層セキュリティ[RFC8446]
The Network Time Protocol includes many different operating modes to support various network topologies (see Section 3 of RFC 5905 [RFC5905]). In addition to its best-known and most-widely-used client-server mode, it also includes modes for synchronization between symmetric peers, a control mode for server monitoring and administration, and a broadcast mode. These various modes have differing and partly contradictory requirements for security and performance. Symmetric and control modes demand mutual authentication and mutual replay protection. Additionally, for certain message types, the control mode may require confidentiality as well as authentication. Client-server mode places more stringent requirements on resource utilization than other modes because servers may have a vast number of clients and be unable to afford to maintain per-client state. However, client-server mode also has more relaxed security needs because only the client requires replay protection: it is harmless for stateless servers to process replayed packets. The security demands of symmetric and control modes, on the other hand, are in conflict with the resource-utilization demands of client-server mode: any scheme that provides replay protection inherently involves maintaining some state to keep track of which messages have already been seen.
ネットワークタイムプロトコルは、さまざまなネットワークトポロジをサポートするためのさまざまな動作モードを含みます（RFC 5905 [RFC5905]のセクション3を参照）。最もよく知られているほとんどの広く使用されているクライアントサーバーモードに加えて、対称ピア間の同期モード、サーバー監視と管理のための制御モード、およびブロードキャストモードも含まれています。これらのさまざまなモードには、セキュリティと性能には異なる矛盾する要件が異なります。対称モードと制御モードは、相互認証と相互再生保護を求めます。さらに、特定のメッセージタイプの場合、制御モードは認証と同様に機密性を必要とする可能性があります。クライアントサーバーモードは、サーバーが膨大な数のクライアントを持ち、クライアントごとの状態を維持できない可能性があるため、他のモードよりもリソース使用率に関するより厳格な要件を課します。ただし、クライアントのみが再生保護を必要とするため、クライアントサーバーモードにはリラックスしたセキュリティニーズがあります。ステートレスサーバーには、再生パケットを処理するのは無害です。一方、対称モードと制御モードのセキュリティ要求は、クライアント - サーバモードのリソース利用要求と矛盾しています。リプレイ保護を提供する任意のスキームは、どのメッセージをすでに見てきたかを追跡するための状態を維持する方法。
This memo specifies NTS exclusively for the client-server mode of NTP. To this end, NTS is structured as a suite of two protocols:
このメモは、NTPのクライアントサーバモード専用NTを指定します。この目的のために、NTSは2つのプロトコルのスイートとして構成されています。
The "NTS Extension Fields for NTPv4" define a collection of NTP extension fields for cryptographically securing NTPv4 using previously established key material. They are suitable for securing client-server mode because the server can implement them without retaining per-client state. All state is kept by the client and provided to the server in the form of an encrypted cookie supplied with each request. On the other hand, the NTS Extension Fields are suitable _only_ for client-server mode because only the client, and not the server, is protected from replay.
「NTPv4のNTS拡張フィールド」は、以前に確立されたキーマテリアルを使用してNTPv4を暗号的に保護するためのNTP拡張フィールドのコレクションを定義します。クライアントごとの状態を保持せずにサーバが実装できるため、それらはクライアント - サーバモードを確保するのに適しています。すべての状態はクライアントによって保持され、各要求に付属の暗号化されたCookieの形でサーバーに提供されます。一方、サーバではなく、クライアントのみが再生から保護されているため、NTS拡張フィールドはクライアントサーバモードに適している_only_である。
The "NTS Key Establishment" protocol (NTS-KE) is a mechanism for establishing key material for use with the NTS Extension Fields for NTPv4. It uses TLS to establish keys, to provide the client with an initial supply of cookies, and to negotiate some additional protocol options. After this, the TLS channel is closed with no per-client state remaining on the server side.
「NTSキー確立」プロトコル（NTS - KE）は、NTPv4のNTS拡張フィールドと共に使用するための重要な資料を確立するためのメカニズムである。TLSを使用してキーを確立し、クライアントにクッキーの初期の供給を提供し、いくつかの追加のプロトコルオプションをネゴシエートします。その後、TLSチャネルは、クライアントごとの状態がサーバー側に残っていない状態で閉じられます。
The typical protocol flow is as follows: The client connects to an NTS-KE server on the NTS TCP port and the two parties perform a TLS handshake. Via the TLS channel, the parties negotiate some additional protocol parameters, and the server sends the client a supply of cookies along with an address and port of an NTP server for which the cookies are valid. The parties use TLS key export [RFC5705] to extract key material, which will be used in the next phase of the protocol. This negotiation takes only a single round trip, after which the server closes the connection and discards all associated state. At this point, the NTS-KE phase of the protocol is complete. Ideally, the client never needs to connect to the NTS-KE server again.
一般的なプロトコルフローは次のとおりです。クライアントはNTS TCPポートのNTS-KEサーバーに接続し、2つのパーティはTLSハンドシェイクを実行します。TLSチャネルを介して、当事者はいくつかの追加のプロトコルパラメータをネゴシエートし、サーバーはクライアントをCookieのアドレスとポートとともに、クッキーが有効なNTPサーバーのアドレスとポートとともに送信します。当事者はTLSキーエクスポート[RFC5705]を使用して、プロトコルの次のフェーズで使用されます。このネゴシエーションは単一の往復のみを取ります。その後、サーバーは接続を閉じ、すべての関連状態を破棄します。この時点で、プロトコルのNTS-KEフェーズは完了です。理想的には、クライアントはNTS-KEサーバーに再度接続する必要はありません。
Time synchronization proceeds with the indicated NTP server. The client sends the server an NTP client packet that includes several extension fields. Included among these fields are a cookie (previously provided by the key establishment server) and an authentication tag, computed using key material extracted from the NTS-KE handshake. The NTP server uses the cookie to recover this key material and send back an authenticated response. The response includes a fresh, encrypted cookie that the client then sends back in the clear in a subsequent request. This constant refreshing of cookies is necessary in order to achieve NTS's unlinkability goal.
表示されたNTPサーバーで時間同期が進みます。クライアントは、複数の拡張フィールドを含むNTPクライアントパケットをサーバに送信します。これらのフィールドの中に含まれているのは、NTS-KEハンドシェイクから抽出されたキーマテリアルを使用して計算されたCookie（鍵設立サーバーによって提供されていました）と認証タグです。NTPサーバーはCookieを使用してこのキーの資料を回復し、認証された応答を送り返します。応答には、クライアントが後続の要求でクリアに送信する新鮮で暗号化されたクッキーが含まれます。NTSのリンク不能目標を達成するためには、このクッキーの絶え間ない爽快感が必要です。
Figure 1 provides an overview of the high-level interaction between the client, the NTS-KE server, and the NTP server. Note that the cookies' data format and the exchange of secrets between NTS-KE and NTP servers are not part of this specification and are implementation dependent. However, a suggested format for NTS cookies is provided in Section 6.
図1は、クライアント、NTS-KEサーバー、およびNTPサーバー間の高レベルの対話の概要を示しています。Cookieのデータ形式とNTS-KEとNTPサーバー間の秘密の交換は、この仕様の一部ではなく実装に依存しています。しかしながら、NTSクッキーのための推奨フォーマットはセクション6に提供されている。
+--------------+
| |
+-> | NTP Server 1 |
| | |
Shared cookie | +--------------+
+---------------+ encryption parameters | +--------------+
| | (Implementation dependent) | | |
| NTS-KE Server | <------------------------------+-> | NTP Server 2 |
| | | | |
+---------------+ | +--------------+
^ | .
| | .
| 1. Negotiate parameters, | .
| receive initial cookie | +--------------+
| supply, generate AEAD keys, | | |
| and receive NTP server IP +-> | NTP Server N |
| addresses using "NTS Key | |
| Establishment" protocol. +--------------+
| ^
| |
| +----------+ |
| | | |
+-----------> | Client | <-------------------------+
| | 2. Perform authenticated
+----------+ time synchronization
and generate new
cookies using "NTS
Extension Fields for
NTPv4".
Figure 1: Overview of High-Level Interactions in NTS
図1：NTSにおける高レベルの相互作用の概要
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Network Time Security makes use of TLS for NTS key establishment.
ネットワークタイムセキュリティは、NTSキー確立のためにTLSを利用します。
Since the NTS protocol is new as of this publication, no backward-compatibility concerns exist to justify using obsolete, insecure, or otherwise broken TLS features or versions. Implementations MUST conform with RFC 7525 [RFC7525] or with a later revision of BCP 195.
NTSプロトコルはこの出版物のように新しいので、時代遅れの、不安定、またはその他の壊れたTLS機能またはバージョンを使用して正当化するための下位互換性の懸念はありません。実装は、RFC 7525 [RFC7525]に準拠している必要があります.BCP 195の後のリビジョンを使用する必要があります。
Implementations MUST NOT negotiate TLS versions earlier than 1.3 [RFC8446] and MAY refuse to negotiate any TLS version that has been superseded by a later supported version.
実装は1.3 [RFC8446]より前のTLSバージョンをネゴシエートしてはならず、後でサポートされているバージョンによって置き換えられたTLSバージョンをネゴシエートすることを拒否することがあります。
Use of the Application-Layer Protocol Negotiation Extension [RFC7301] is integral to NTS, and support for it is REQUIRED for interoperability.
アプリケーション層プロトコルネゴシエーション拡張[RFC7301]の使用はNTSにとって不可欠であり、それのサポートは相互運用性に必要です。
Implementations MUST follow the rules in RFC 5280 [RFC5280] and RFC 6125 [RFC6125] for the representation and verification of the application's service identity. When NTS-KE service discovery (out of scope for this document) produces one or more host names, use of the DNS-ID identifier type [RFC6125] is RECOMMENDED; specifications for service discovery mechanisms can provide additional guidance for certificate validation based on the results of discovery. Section 8.5 of this memo discusses particular considerations for certificate verification in the context of NTS.
実装は、アプリケーションのサービスIDの表現と検証のために、RFC 5280 [RFC5280]とRFC 6125 [RFC6125]の規則に従う必要があります。NTS-KEサービスの検出（この文書の範囲外）の場合、1つ以上のホスト名が生成されると、DNS-ID識別子タイプ[RFC6125]を使用することをお勧めします。サービス発見メカニズムの仕様は、発見結果に基づいて証明書検証のための追加のガイダンスを提供できます。このメモのセクション8.5は、NTSの文脈における証明書検証に関する特定の考慮事項について説明しています。
The NTS key establishment protocol is conducted via TCP port 4460. The two endpoints carry out a TLS handshake in conformance with Section 3, with the client offering (via an ALPN extension [RFC7301]), and the server accepting, an application-layer protocol of "ntske/1". Immediately following a successful handshake, the client SHALL send a single request as Application Data encapsulated in the TLS-protected channel. Then, the server SHALL send a single response. After sending their respective request and response, the client and server SHALL send TLS "close_notify" alerts in accordance with Section 6.1 of RFC 8446 [RFC8446].
NTSキー設立プロトコルはTCPポート4460を介して行われます.2つのエンドポイントは、セクション3に準拠してTLSハンドシェイクを実行し、クライアントは（ALPN拡張[RFC7301]を介して）、およびサーバー受付、アプリケーション層プロトコルを提供します。「NTSKE / 1」の。サポートされたハンドシェイクの直後に、クライアントはTLS保護チャネルにカプセル化されたアプリケーションデータとして単一の要求を送信します。その後、サーバーは単一の応答を送ります。それぞれの要求と応答を送信した後、クライアントとサーバーは、RFC 8446 [RFC8446]のセクション6.1に従ってTLS "close_notify"アラートを送信しなければならない。
The client's request and the server's response each SHALL consist of a sequence of records formatted according to Figure 2. The request and a non-error response each SHALL include exactly one NTS Next Protocol Negotiation record. The sequence SHALL be terminated by a "End of Message" record. The requirement that all NTS-KE messages be terminated by an End of Message record makes them self-delimiting.
クライアントの要求とサーバーの応答は、それぞれ図2に従ってフォーマットされた一連のレコードで構成されます。要求と非エラー応答はそれぞれ1つのNTS次のプロトコルネゴシエーションレコードを含めなければならない。シーケンスは「メッセージの終わり」レコードによって終了するものとします。すべてのNTS-KEメッセージをメッセージレコードの終わりによって終了させる必要性はそれらを自己区切りにします。
Clients and servers MAY enforce length limits on requests and responses; however, servers MUST accept requests of at least 1024 octets, and clients SHOULD accept responses of at least 65536 octets.
クライアントとサーバーは、リクエストや応答に長さの制限を強制することがあります。ただし、サーバーは少なくとも1024オクテットの要求を受け入れ、クライアントは少なくとも65536オクテットの反応を受け入れる必要があります。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Record Type | Body Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Record Body .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NTS-KE Record Format
図2：NTS-KEレコードフォーマット
The fields of an NTS-KE record are defined as follows:
NTS-KEレコードのフィールドは次のように定義されています。
C (Critical Bit): Determines the disposition of unrecognized Record Types. Implementations which receive a record with an unrecognized Record Type MUST ignore the record if the Critical Bit is 0 and MUST treat it as an error if the Critical Bit is 1 (see Section 4.1.3).
C（クリティカルビット）：認識されていないレコードタイプの配置を決定します。認識されていないレコードタイプを持つレコードを受信する実装は、クリティカルビットが0の場合はレコードを無視し、クリティカルビットが1の場合はエラーとして扱う必要があります（セクション4.1.3を参照）。
Record Type Number: A 15-bit integer in network byte order. The semantics of Record Types 0-7 are specified in this memo. Additional type numbers SHALL be tracked through the IANA "Network Time Security Key Establishment Record Types" registry.
レコードタイプ番号：ネットワークバイトオーダーの15ビット整数。このメモには、レコードタイプ0~7のセマンティクスが指定されています。追加のタイプ番号は、IANA "ネットワークタイムセキュリティキー設立レコードタイプ"レジストリを介して追跡されます。
Body Length: The length of the Record Body field, in octets, as a 16-bit integer in network byte order. Record bodies MAY have any representable length and need not be aligned to a word boundary.
ボディ長：八重奏のレコード本文の長さ、ネットワークバイト順の16ビット整数として。記録体は表現可能な長さを持ち、単語境界に整列させる必要はありません。
Record Body: The syntax and semantics of this field SHALL be determined by the Record Type.
記録体：この分野の構文と意味論は、記録タイプによって決定されなければならない。
For clarity regarding bit-endianness: the Critical Bit is the most significant bit of the first octet. In the C programming language, given a network buffer 'unsigned char b[]' containing an NTS-KE record, the critical bit is 'b[0] >> 7' while the record type is '((b[0] & 0x7f) << 8) + b[1]'.
ビットエンディーネスに関して明確にするために：クリティカルビットは最初のオクテットの最上位ビットです。Cプログラミング言語では、NTS-KEレコードを含むネットワークバッファ '符号なしCHAR B []'を指定して、クリティカルビットは 'B [0] >> 7'、レコードタイプは '（b [0]＆）です。0x7f）<< 8）b [1] '。
Note that, although the Type-Length-Body format of an NTS-KE record is similar to that of an NTP extension field, the semantics of the length field differ. While the length subfield of an NTP extension field gives the length of the entire extension field including the type and length subfields, the length field of an NTS-KE record gives just the length of the body.
なお、NTS-KEレコードのType-Length-BodyフォーマットはNTP拡張フィールドと似ていますが、長さフィールドのセマンティクスは異なります。NTP拡張フィールドの長さサブフィールドは、タイプおよび長さサブフィールドを含む全体拡張フィールドの長さを与えているが、NTS - KEレコードの長さフィールドは本体の長さだけを与える。
Figure 3 provides a schematic overview of the key establishment. It displays the protocol steps to be performed by the NTS client and server and Record Types to be exchanged.
図3は、キー設立の概略概要を示しています。交換するNTSクライアントとサーバーとレコードタイプによって実行されるプロトコルステップを表示します。
+---------------------------------------+
| - Verify client request message. |
| - Extract TLS key material. |
| - Generate KE response message. |
| - Include Record Types: |
| o NTS Next Protocol Negotiation |
| o AEAD Algorithm Negotiation |
| o <NTPv4 Server Negotiation> |
| o <NTPv4 Port Negotiation> |
| o New Cookie for NTPv4 |
| o <New Cookie for NTPv4> |
| o End of Message |
+-----------------+---------------------+
|
|
Server -----------+---------------+-----+----------------------->
^ \
/ \
/ TLS application \
/ data \
/ \
/ V
Client -----+---------------------------------+----------------->
| |
| |
| |
+-----------+----------------------+ +------+-----------------+
|- Generate KE request message. | |- Verify server response|
| - Include Record Types: | | message. |
| o NTS Next Protocol Negotiation | |- Extract cookie(s). |
| o AEAD Algorithm Negotiation | +------------------------+
| o <NTPv4 Server Negotiation> |
| o <NTPv4 Port Negotiation> |
| o End of Message |
+----------------------------------+
Figure 3: NTS Key Establishment Messages
図3：NTSキー設立メッセージ
The following NTS-KE Record Types are defined:
次のNTS-KEレコードタイプが定義されています。
The End of Message record has a Record Type number of 0 and a zero-length body. It MUST occur exactly once as the final record of every NTS-KE request and response. The Critical Bit MUST be set.
メッセージレコードの終わりには、レコードタイプ数が0とゼロ長の本体があります。NTS-KEの要求と応答の最後のレコードとして一度は正確に発生する必要があります。クリティカルビットを設定する必要があります。
The NTS Next Protocol Negotiation record has a Record Type number of 1. It MUST occur exactly once in every NTS-KE request and response. Its body consists of a sequence of 16-bit unsigned integers in network byte order. Each integer represents a Protocol ID from the IANA "Network Time Security Next Protocols" registry (Section 7.7). The Critical Bit MUST be set.
NTS次のプロトコルネゴシエーションレコードには、レコードタイプ番号が1です.NTS-KEの要求と応答ごとに一度正確に発生する必要があります。その本体は、ネットワークバイト順に16ビットの符号なし整数のシーケンスで構成されています。各整数は、IANA "Network Time Security次のプロトコル"レジストリ（セクション7.7）のプロトコルIDを表します。クリティカルビットを設定する必要があります。
The Protocol IDs listed in the client's NTS Next Protocol Negotiation record denote those protocols that the client wishes to speak using the key material established through this NTS-KE session. Protocol IDs listed in the NTS-KE server's response MUST comprise a subset of those listed in the request and denote those protocols that the NTP server is willing and able to speak using the key material established through this NTS-KE session. The client MAY proceed with one or more of them. The request MUST list at least one protocol, but the response MAY be empty.
クライアントのNTS次のプロトコルネゴシエーションレコードにリストされているプロトコルIDは、クライアントがこのNTS-KEセッションを通じて確立されたキーマテリアルを使用して話すプロトコルを示します。NTS-KEサーバの応答にリストされているプロトコルIDは、要求にリストされているもののサブセットを構成し、NTPサーバーが喜んで、このNTS-KEセッションを通じて確立されたキーマテリアルを使用して話すことができるプロトコルを表している必要があります。クライアントはそれらのうちの1つ以上を進めることができる。要求は少なくとも1つのプロトコルをリストする必要がありますが、応答は空になる可能性があります。
The Error record has a Record Type number of 2. Its body is exactly two octets long, consisting of an unsigned 16-bit integer in network byte order, denoting an error code. The Critical Bit MUST be set.
エラーレコードにはレコードタイプ数が2です。そのボディは、ネットワークバイト順に符号なしの16ビット整数で、エラーコードを表す1台のオクテット長です。クリティカルビットを設定する必要があります。
Clients MUST NOT include Error records in their request. If clients receive a server response that includes an Error record, they MUST discard any key material negotiated during the initial TLS exchange and MUST NOT proceed to the Next Protocol. Requirements for retry intervals are described in Section 4.2.
クライアントは、要求にエラーレコードを含めないでください。クライアントがエラーレコードを含むサーバーの応答を受信した場合、それらは最初のTLS Exchangeの間にネゴシエートされた任意の重要な資料を破棄しなければならず、次のプロトコルに進んではいけません。リトライ間隔の要件は4.2節で説明されています。
The following error codes are defined:
次のエラーコードが定義されています。
Error code 0 means "Unrecognized Critical Record". The server MUST respond with this error code if the request included a record that the server did not understand and that had its Critical Bit set. The client SHOULD NOT retry its request without modification.
エラーコード0は「認識されない重要な記録」を意味します。要求にサーバーが理解していないレコードが含まれており、その重要なビットセットが含まれていた場合、サーバーはこのエラーコードで応答する必要があります。クライアントは変更なしでその要求を再試行しないでください。
Error code 1 means "Bad Request". The server MUST respond with this error if the request is not complete and syntactically well-formed, or, upon the expiration of an implementation-defined timeout, it has not yet received such a request. The client SHOULD NOT retry its request without modification.
エラーコード1は「不正な要求」を意味します。要求が完全で構文的に整形されていない場合、または実装定義のタイムアウトの有効期限が満たされていない場合、サーバーはこのエラーで応答する必要があります。クライアントは変更なしでその要求を再試行しないでください。
Error code 2 means "Internal Server Error". The server MUST respond with this error if it is unable to respond properly due to an internal condition. The client MAY retry its request.
エラーコード2は、「内部サーバーエラー」を意味します。内部条件のために正しく応答できない場合、サーバーはこのエラーで応答する必要があります。クライアントはその要求を再試行することができます。
The Warning record has a Record Type number of 3. Its body is exactly two octets long, consisting of an unsigned 16-bit integer in network byte order, denoting a warning code. The Critical Bit MUST be set.
警告レコードにはレコードタイプ数が3あります。そのボディは正確に2オクテットの長さです。クリティカルビットを設定する必要があります。
Clients MUST NOT include Warning records in their request. If clients receive a server response that includes a Warning record, they MAY discard any negotiated key material and abort without proceeding to the Next Protocol. Unrecognized warning codes MUST be treated as errors.
クライアントには、要求に警告レコードを含めないでください。クライアントが警告レコードを含むサーバーの応答を受信した場合、それらは次のプロトコルに進むことなくネゴシエートされたキーマテリアルを破棄して中止される可能性があります。認識されていない警告コードはエラーとして扱う必要があります。
This memo defines no warning codes.
このメモは警告コードを定義していません。
The AEAD Algorithm Negotiation record has a Record Type number of 4. Its body consists of a sequence of unsigned 16-bit integers in network byte order, denoting Numeric Identifiers from the IANA "AEAD Algorithms" registry [IANA-AEAD]. The Critical Bit MAY be set.
AEDアルゴリズムネゴシエーションレコードには4のレコードタイプ数があります。その本体は、IANA "AEAD Algorithms"レジストリ[IANA-AEAD]からの数値識別子を表す、ネットワークバイト順に一連の符号なし16ビット整数で構成されています。クリティカルビットを設定できます。
If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for NTPv4), then this record MUST be included exactly once. Other protocols MAY require it as well.
NTS次のプロトコルネゴシエーションレコードがプロトコルID 0（NTPv4用）を提供する場合、このレコードは正確に一度だけ含める必要があります。他のプロトコルも同様に必要になるかもしれません。
When included in a request, this record denotes which AEAD algorithms the client is willing to use to secure the Next Protocol, in decreasing preference order. When included in a response, this record denotes which algorithm the server chooses to use. It is empty if the server supports none of the algorithms offered. In requests, the list MUST include at least one algorithm. In responses, it MUST include at most one. Honoring the client's preference order is OPTIONAL: servers may select among any of the client's offered choices, even if they are able to support some other algorithm that the client prefers more.
要求に含まれる場合、このレコードは、クライアントが次のプロトコルを保護するためにどのAEDアルゴリズムが使用されているか、嗜好順序を減らすことを望んでいます。応答に含まれる場合、このレコードはサーバーが使用することを選択したアルゴリズムを表します。サーバーが提供されているアルゴリズムのどれもサポートしていない場合は空です。要求では、リストには少なくとも1つのアルゴリズムを含める必要があります。回答では、それは最大のものを含める必要があります。クライアントの嗜好命令を称えることはオプションです。サーバーは、クライアントがより多くのものを好む他のアルゴリズムをサポートできる場合でも、クライアントの提供された選択肢の中から選択することができます。
Server implementations of NTS Extension Fields for NTPv4 (Section 5) MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15). That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD Algorithm Negotiation record, and the server accepts Protocol ID 0 (NTPv4) in its NTS Next Protocol Negotiation record, then the server's AEAD Algorithm Negotiation record MUST NOT be empty.
NTS拡張フィールドのサーバ実装NTPv4（セクション5）は、AED_AES_SIV_CMAC_256 [RFC5297]（数値識別子15）をサポートしている必要があります。すなわち、クライアントがそのAEDアルゴリズムネゴシエーションレコードにAEAD_AES_SIV_CMAC_256を含む場合、サーバはNTS次のプロトコルネゴシエーションレコードでプロトコルID 0（NTPv4）を受け入れてから、サーバのAEDアルゴリズムネゴシエーションレコードを空にしてはいけません。
The New Cookie for NTPv4 record has a Record Type number of 5. The contents of its body SHALL be implementation-defined, and clients MUST NOT attempt to interpret them. See Section 6 for a suggested construction.
NTPv4レコードの新しいCookieには、レコードタイプ番号があります。そのボディの内容は実装定義され、クライアントはそれらを解釈しようとしてはいけません。提案された構造については6節を参照してください。
Clients MUST NOT send records of this type. Servers MUST send at least one record of this type, and SHOULD send eight of them, if the Next Protocol Negotiation response record contains Protocol ID 0 (NTPv4) and the AEAD Algorithm Negotiation response record is not empty. The Critical Bit SHOULD NOT be set.
クライアントはこのタイプのレコードを送信してはいけません。サーバーはこのタイプの少なくとも1つのレコードを送信しなければならず、次のプロトコルネゴシエーション応答レコードにプロトコルID 0（NTPV4）が含まれていて、AEDアルゴリズムネゴシエーションレスポンスレコードが空でない場合は、それらの8つを送信する必要があります。クリティカルビットを設定しないでください。
The NTPv4 Server Negotiation record has a Record Type number of 6. Its body consists of an ASCII-encoded [RFC0020] string. The contents of the string SHALL be either an IPv4 address, an IPv6 address, or a fully qualified domain name (FQDN). IPv4 addresses MUST be in dotted decimal notation. IPv6 addresses MUST conform to the "Text Representation of Addresses" as specified in RFC 4291 [RFC4291] and MUST NOT include zone identifiers [RFC6874]. If a label contains at least one non-ASCII character, it is an internationalized domain name, and an A-LABEL MUST be used as defined in Section 2.3.2.1 of RFC 5890 [RFC5890]. If the record contains a domain name, the recipient MUST treat it as a FQDN, e.g., by making sure it ends with a dot.
NTPv4サーバーネゴシエーションレコードには、レコードタイプ番号が6です。その本体はASCIIエンコードされた[RFC0020]文字列で構成されています。文字列の内容は、IPv4アドレス、IPv6アドレス、または完全修飾ドメイン名（FQDN）のいずれかです。IPv4アドレスは小数点以下の表記法でなければなりません。IPv6アドレスは、RFC 4291 [RFC4291]で指定されている「アドレスのテキスト表現」に準拠し、ゾーン識別子[RFC6874]を含めてはいけません。ラベルに少なくとも1つのASCII文字が含まれている場合、それは国際化されたドメイン名であり、RFC 5890 [RFC5890]のセクション2.3.2.1で定義されているようにAラベルを使用する必要があります。レコードにドメイン名が含まれている場合、受信者はそれをFQDNとして扱う必要があります。これは、それがドットで終わることを確認します。
When NTPv4 is negotiated as a Next Protocol and this record is sent by the server, the body specifies the hostname or IP address of the NTPv4 server with which the client should associate and that will accept the supplied cookies. If no record of this type is sent, the client SHALL interpret this as a directive to associate with an NTPv4 server at the same IP address as the NTS-KE server. Servers MUST NOT send more than one record of this type.
NTPv4が次のプロトコルとしてネゴシエートされており、このレコードがサーバーによって送信されると、本体はクライアントが関連付けるNTPv4サーバーのホスト名またはIPアドレスを指定し、提供されているCookieを受け入れます。このタイプのレコードが送信されていない場合、クライアントはこれをNTPV4サーバーと同じIPアドレスでNTS-KEサーバーと関連付けるディレクティブとして解釈します。サーバーはこのタイプの複数のレコードを送信してはいけません。
When this record is sent by the client, it indicates that the client wishes to associate with the specified NTP server. The NTS-KE server MAY incorporate this request when deciding which NTPv4 Server Negotiation records to respond with, but honoring the client's preference is OPTIONAL. The client MUST NOT send more than one record of this type.
このレコードがクライアントによって送信されると、クライアントが指定されたNTPサーバーと関連付けることを示します。NTS-KEサーバーは、どのNTPv4サーバーネゴシエーションレコードを応答するかを決定するときにこの要求を組み込んでも、クライアントの設定を尊重することはオプションです。クライアントはこのタイプの複数のレコードを送信してはいけません。
If the client has sent a record of this type, the NTS-KE server SHOULD reply with the same record if it is valid and the server is able to supply cookies for it. If the client has not sent any record of this type, the NTS-KE server SHOULD respond with either an NTP server address in the same family as the NTS-KE session or a FQDN that can be resolved to an address in that family, if such alternatives are available.
クライアントがこのタイプのレコードを送信した場合、NTS-KEサーバーは有効である場合は同じレコードで返信し、サーバーがCookieを供給できます。クライアントがこのタイプのレコードを送信していない場合、NTS-KEサーバーはNTS-keセッションと同じファミリ内のNTPサーバーアドレスまたはそのファミリ内のアドレスに解決できるFQDNで応答する必要があります。そのような代替案が利用可能です。
Servers MAY set the Critical Bit on records of this type; clients SHOULD NOT.
サーバーはこのタイプのレコードに重要なビットを設定できます。クライアントはしてはいけません。
The NTPv4 Port Negotiation record has a Record Type number of 7. Its body consists of a 16-bit unsigned integer in network byte order, denoting a UDP port number.
NTPv4ポートネゴシエーションレコードには、レコードタイプ数が7です。そのボディは、ネットワークバイト順に16ビットの符号なし整数で構成され、UDPポート番号を示します。
When NTPv4 is negotiated as a Next Protocol, and this record is sent by the server, the body specifies the port number of the NTPv4 server with which the client should associate and that will accept the supplied cookies. If no record of this type is sent, the client SHALL assume a default of 123 (the registered port number for NTP).
NTPv4が次のプロトコルとしてネゴシエートされ、このレコードがサーバーによって送信されると、その本文はクライアントが関連付ける必要があるNTPv4サーバーのポート番号を指定し、それが提供されたCookieを受け入れます。このタイプのレコードが送信されていない場合、クライアントはデフォルトの123（NTPの登録ポート番号）を仮定します。
When this record is sent by the client in conjunction with a NTPv4 Server Negotiation record, it indicates that the client wishes to associate with the NTP server at the specified port. The NTS-KE server MAY incorporate this request when deciding what NTPv4 Server Negotiation and NTPv4 Port Negotiation records to respond with, but honoring the client's preference is OPTIONAL.
このレコードがNTPv4サーバーネゴシエーションレコードと組み合わせてクライアントによって送信されると、クライアントが指定されたポートでNTPサーバーと関連付けることを示します。NTS-KEサーバーは、どのNTPv4サーバーネゴシエーションとNTPv4ポートネゴシエーションレコードを決定するときにこの要求を組み込んでも、クライアントの好みを尊重することはオプションです。
Servers MAY set the Critical Bit on records of this type; clients SHOULD NOT.
サーバーはこのタイプのレコードに重要なビットを設定できます。クライアントはしてはいけません。
A mechanism for not unnecessarily overloading the NTS-KE server is REQUIRED when retrying the key establishment process due to protocol, communication, or other errors. The exact workings of this will be dependent on the application and operational experience gathered over time. Until such experience is available, this memo provides the following suggestion.
プロトコル、通信、またはその他のエラーにより、キー確立プロセスを再試行するときにNTS-KEサーバーを不必要に過負荷にするメカニズムが必要です。これの正確な働きは、経時的に収集されたアプリケーションと運用経験に依存します。そのような経験が利用可能になるまで、このメモは以下の提案を提供します。
Clients SHOULD use exponential backoff, with an initial and minimum retry interval of 10 seconds, a maximum retry interval of 5 days, and a base of 1.5. Thus, the minimum interval in seconds, 't', for the nth retry is calculated with the following:
クライアントは10秒の初期および最小リトライ間隔、最大リトライ間隔、5日間の最小リトライ間隔、および1.5のベースで、指数バックオフを使用する必要があります。したがって、N番目のリトライのための最小間隔、 't'は次のように計算されます。
t = min(10 * 1.5^(n-1), 432000).
t = min（10 * 1.5 ^（n-1）、432000）。
Clients MUST NOT reset the retry interval until they have performed a successful key establishment with the NTS-KE server, followed by a successful use of the negotiated Next Protocol with the keys and data established during that transaction.
クライアントは、NTS-KEサーバーを使用した正常な重要な確立を行ったまでの再試行間隔をリセットしないでください。その後、そのトランザクション中に確立されたキーとデータを使用してネゴシエートされた次のプロトコルを正しく使用する必要があります。
Following a successful run of the NTS-KE protocol, key material SHALL be extracted using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) [RFC5869] in accordance with Section 7.5 of RFC 8446 [RFC8446]. Inputs to the exporter function are to be constructed in a manner specific to the negotiated Next Protocol. However, all protocols that utilize NTS-KE MUST conform to the following two rules:
NTS-KEプロトコルの実行に続いて、RFC 8446 [RFC8446]のセクション7.5に従って、HMACベースの抽出および拡張キー派生機能（hkdf）[RFC5869]を使用して鍵素材を抽出する。輸出業者機能への入力は、ネゴシエートされた次のプロトコルに固有の方法で構築されます。ただし、NTS-KEを利用するすべてのプロトコルは、次の2つの規則に準拠している必要があります。
The disambiguating label string [RFC5705] MUST be "EXPORTER-network-time-security".
曖昧さ格納ラベル文字列[RFC5705]は、「exporter-network-time-security」でなければなりません。
The per-association context value [RFC5705] MUST be provided and MUST begin with the two-octet Protocol ID that was negotiated as a Next Protocol.
協会ごとのコンテキスト値[RFC5705]は、次のプロトコルとしてネゴシエートされた2オクテットプロトコルIDで開始する必要があります。
Following a successful run of the NTS-KE protocol wherein Protocol ID 0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be extracted: a client-to-server (C2S) key and a server-to-client (S2C) key. These keys SHALL be computed with the HKDF defined in Section 7.5 of RFC 8446 [RFC8446] using the following inputs:
プロトコルID 0（NTPv4）が次のプロトコルとして選択されたNTS-KEプロトコルの実行に続いて、2つのAEADキーを抽出します。クライアントからサーバー（C2S）キーとサーバー間の鍵（S2C）を抽出します。）キー。これらのキーは、次の入力を使用して、RFC 8446 [RFC8446]のセクション7.5で定義されているHKDFで計算されます。
The disambiguating label string [RFC5705] SHALL be "EXPORTER-network-time-security".
曖昧さを伴うラベル文字列[RFC5705]は、「輸出業者ネットワーク - Time-Security」とする。
The per-association context value [RFC5705] SHALL consist of the following five octets:
協会ごとのコンテキスト値[RFC5705]は、次の5オクテットで構成されます。
- The first two octets SHALL be zero (the Protocol ID for NTPv4).
- 最初の2つのオクテットはゼロ（NTPv4のプロトコルID）とする。
- The next two octets SHALL be the Numeric Identifier of the negotiated AEAD algorithm in network byte order.
- 次の2つのオクテットは、ネットワークバイト順でネゴシエートされたAEADアルゴリズムの数値識別子とする。
- The final octet SHALL be 0x00 for the C2S key and 0x01 for the S2C key.
- 最後のオクテットは、C2Sキーの場合は0x00、S2Cキーの0x01です。
Implementations wishing to derive additional keys for private or experimental use MUST NOT do so by extending the above-specified syntax for per-association context values. Instead, they SHOULD use their own disambiguating label string. Note that RFC 5705 [RFC5705] provides that disambiguating label strings beginning with "EXPERIMENTAL" MAY be used without IANA registration.
プライベートまたは実験的な使用のための追加のキーを導出することを望む実装は、関連付けられたコンテキスト値について上記の構文を拡張することによってそうしてはいけません。代わりに、彼らは彼ら自身の曖昧さを曖昧にするラベル文字列を使うべきです。RFC 5705 [RFC5705]は、IANA登録なしで「実験的」で始まる曖昧さを解除することができることに注意してください。
In general, an NTS-protected NTPv4 packet consists of the following:
一般に、NTS保護されたNTPv4パケットは次のもので構成されています。
The usual 48-octet NTP header, which is authenticated but not encrypted.
認証されているが暗号化されていない通常の48オクテットNTPヘッダー。
Some extension fields, which are authenticated but not encrypted.
認証されているが暗号化されていない拡張フィールド。
An extension field that contains AEAD output (i.e., an authentication tag and possible ciphertext). The corresponding plaintext, if non-empty, consists of some extension fields that benefit from both encryption and authentication.
AED出力を含む拡張フィールド（すなわち、認証タグと可能な暗号文）。対応する平文は、空でない場合は、暗号化と認証の両方から利益を得る一部の拡張フィールドで構成されています。
Possibly, some additional extension fields that are neither encrypted nor authenticated. In general, these are discarded by the receiver.
おそらく、暗号化されても認証もされていないいくつかの追加の拡張フィールド。一般に、これらは受信機によって破棄されます。
Always included among the authenticated or authenticated-and-encrypted extension fields are a cookie extension field and a unique identifier extension field, as described in Section 5.7. The purpose of the cookie extension field is to enable the server to offload storage of session state onto the client. The purpose of the unique identifier extension field is to protect the client from replay attacks.
常に認証されたまたは認証された拡張フィールドの間に含まれている、セクション5.7で説明されているように、Cookie拡張フィールドと一意の識別子拡張フィールドが含まれています。Cookie拡張フィールドの目的は、サーバーがセッション状態のストレージをクライアントにオフロードできるようにすることです。一意の識別子拡張フィールドの目的は、クライアントを再生攻撃から保護することです。
The Unique Identifier extension field provides the client with a cryptographically strong means of detecting replayed packets. It has a Field Type of 0x0104. When the extension field is included in a client packet (mode 3), its body SHALL consist of a string of octets generated by a cryptographically secure random number generator [RFC4086]. The string MUST be at least 32 octets long. When the extension field is included in a server packet (mode 4), its body SHALL contain the same octet string as was provided in the client packet to which the server is responding. All server packets generated by NTS-implementing servers in response to client packets containing this extension field MUST also contain this field with the same content as in the client's request. The field's use in modes other than client-server is not defined.
一意の識別子拡張フィールドは、再生されたパケットを検出するための暗号的に強い手段をクライアントに提供します。それは0x0104のフィールド型を持っています。拡張フィールドがクライアントパケットに含まれている場合（モード3）、その本体は、暗号的に安全な乱数ジェネレータ[RFC4086]によって生成されたオクテットの文字列で構成されます。文字列は少なくとも32オクテットの長さでなければなりません。拡張フィールドがサーバパケットに含まれている場合（モード4）、その本体は、サーバが応答しているクライアントパケットに提供されたのと同じオクテット文字列を含むものとします。この拡張フィールドを含むクライアントパケットに応答してNTS実装サーバーによって生成されたすべてのサーバーパケットには、クライアントの要求と同じコンテンツを持つこのフィールドも含まれている必要があります。クライアントサーバー以外のモードでのフィールドの使用は定義されていません。
This extension field MAY also be used standalone, without NTS, in which case it provides the client with a means of detecting spoofed packets from off-path attackers. Historically, NTP's origin timestamp field has played both these roles, but this is suboptimal for cryptographic purposes because it is only 64 bits long, and depending on implementation details, most of those bits may be predictable. In contrast, the Unique Identifier extension field enables a degree of unpredictability and collision resistance more consistent with cryptographic best practice.
この拡張フィールドはまた、NTSなしでスタンドアロンを使用することもでき、その場合、オフパス攻撃者からなりすましたパケットを検出する手段をクライアントに提供する。歴史的に、NTPのOrigin Timestampフィールドはこれらの役割の両方を再生しましたが、これは暗号化の目的では64ビットの長さで、実装の詳細によっては、これらのビットのほとんどが予測可能である可能性があります。対照的に、一意の識別子拡張フィールドは、暗号化されたベストプラクティスとより一致する程度の予測不可能性および衝突性をより整合的にすることを可能にする。
The NTS Cookie extension field has a Field Type of 0x0204. Its purpose is to carry information that enables the server to recompute keys and other session state without having to store any per-client state. The contents of its body SHALL be implementation-defined, and clients MUST NOT attempt to interpret them. See Section 6 for a suggested construction. The NTS Cookie extension field MUST NOT be included in NTP packets whose mode is other than 3 (client) or 4 (server).
NTS Cookie拡張フィールドには、フィールドタイプが0x0204です。その目的は、クライアントごとの状態を保存せずにサーバーがキーやその他のセッション状態を再計算できるようにすることです。その体の内容は実装定義され、クライアントはそれらを解釈しようとしてはいけません。提案された構造については6節を参照してください。NTS Cookie拡張フィールドは、3（クライアント）または4（サーバ）以外のモードがNTPパケットに含めてはいけません。
The NTS Cookie Placeholder extension field has a Field Type of 0x0304. When this extension field is included in a client packet (mode 3), it communicates to the server that the client wishes it to send additional cookies in its response. This extension field MUST NOT be included in NTP packets whose mode is other than 3.
NTS Cookieプレースホルダ拡張フィールドには、フィールドタイプが0x0304です。この拡張フィールドがクライアントパケットに含まれている場合（モード3）、クライアントがその応答に追加のクッキーを送信したいサーバーと通信します。この拡張フィールドは、モードが3以外のNTPパケットに含めてはいけません。
Whenever an NTS Cookie Placeholder extension field is present, it MUST be accompanied by an NTS Cookie extension field. The body length of the NTS Cookie Placeholder extension field MUST be the same as the body length of the NTS Cookie extension field. This length requirement serves to ensure that the response will not be larger than the request, in order to improve timekeeping precision and prevent DDoS amplification. The contents of the NTS Cookie Placeholder extension field's body SHOULD be all zeros and, aside from checking its length, MUST be ignored by the server.
NTS Cookieプレースホルダ拡張フィールドが存在するときはいつでも、それはNTS Cookie拡張フィールドを伴う必要があります。NTS Cookieプレースホルダ拡張フィールドのボディ長は、NTSクッキー拡張フィールドのボディ長と同じでなければなりません。この長さの要件は、計時の精度を向上させ、DDOS増幅を防ぐために、応答が要求よりも大きくないことを保証するのに役立ちます。NTS Cookieプレースホルダ拡張フィールドの内容はすべてゼロであるべきであり、その長さを確認する以外に、サーバーによって無視される必要があります。
5.6. The NTS Authenticator and Encrypted Extension Fields Extension Field
5.6. NTS AuthenticatorおよびEncrypted Extensionフィールド拡張フィールド
The NTS Authenticator and Encrypted Extension Fields extension field is the central cryptographic element of an NTS-protected NTP packet. Its Field Type is 0x0404. It SHALL be formatted according to Figure 4 and include the following fields:
NTS AuthenticatorおよびEncrypted Extension Fields拡張フィールドは、NTS保護されたNTPパケットの中央暗号化要素です。そのフィールドタイプは0x0404です。図4に従ってフォーマットされ、次のフィールドを含めます。
Nonce Length: Two octets in network byte order, giving the length of the Nonce field, excluding any padding, interpreted as an unsigned integer.
Nonce Length：ネットワークバイトオーダーの2つのオクテットは、任意のパディングを除く、符号なし整数として解釈され、Nonceフィールドの長さを与えます。
Ciphertext Length: Two octets in network byte order, giving the length of the Ciphertext field, excluding any padding, interpreted as an unsigned integer.
暗号文の長さ：ネットワークバイトの2つのオクテットは、任意のパディングを除く、暗号化された整数として解釈され、暗号文の長さを与えます。
Nonce: A nonce as required by the negotiated AEAD algorithm. The end of the field is zero-padded to a word (four octets) boundary.
Nonce：ネゴシエートされたAEADアルゴリズムによって要求されるような非通信。フィールドの終わりはワード（4オクテット）境界にゼロパッドされています。
Ciphertext: The output of the negotiated AEAD algorithm. The structure of this field is determined by the negotiated algorithm, but it typically contains an authentication tag in addition to the actual ciphertext. The end of the field is zero-padded to a word (four octets) boundary.
暗号文：ネゴシエートされたAEADアルゴリズムの出力このフィールドの構造は、ネゴシエートされたアルゴリズムによって決定されますが、通常は実際の暗号文に加えて認証タグが含まれています。フィールドの終わりはワード（4オクテット）境界にゼロパッドされています。
Additional Padding: Clients that use a nonce length shorter than the maximum allowed by the negotiated AEAD algorithm may be required to include additional zero-padding. The necessary length of this field is specified below.
追加のパディング：ネゴシエートされたAEADアルゴリズムによって許容される最大値よりも短いNONCE長を使用するクライアントは、追加のゼロパディングを含めることが要求されるかもしれません。このフィールドの必要な長さは以下のとおりです。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Length | Ciphertext Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Nonce, including up to 3 octets padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Ciphertext, including up to 3 octets padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Additional Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NTS Authenticator and Encrypted Extension Fields Extension Field Format
図4：NTSオーセンティケータと暗号化拡張フィールド拡張フィールドフォーマット
The Ciphertext field SHALL be formed by providing the following inputs to the negotiated AEAD algorithm:
暗号文のフィールドは、ネゴシエートされたAEADアルゴリズムに次の入力を提供することによって形成されます。
K: For packets sent from the client to the server, the C2S key SHALL be used. For packets sent from the server to the client, the S2C key SHALL be used.
K：クライアントからサーバーに送信されたパケットの場合、C2Sキーを使用します。サーバーからクライアントに送信されたパケットの場合、S2Cキーを使用します。
A: The associated data SHALL consist of the portion of the NTP packet beginning from the start of the NTP header and ending at the end of the last extension field that precedes the NTS Authenticator and Encrypted Extension Fields extension field.
A：関連データは、NTPヘッダの開始から始まり、NTS AuthenticatorおよびEncrepted Extension Fields拡張フィールドの前にある最後の拡張フィールドの終わりから終了するNTPパケットの部分からなるものとします。
P: The plaintext SHALL consist of all (if any) NTP extension fields to be encrypted; if multiple extension fields are present, they SHALL be joined by concatenation. Each such field SHALL be formatted in accordance with RFC 7822 [RFC7822], except that, contrary to the RFC 7822 requirement that fields have a minimum length of 16 or 28 octets, encrypted extension fields MAY be arbitrarily short (but still MUST be a multiple of 4 octets in length).
P：平文は、暗号化されるべきすべてのNTP拡張フィールドで構成されます。複数の拡張フィールドが存在する場合、それらは連結によって結合されなければならない。そのような各フィールドは、RFC 7822 [RFC7822]に従って、RFC 7822 [RFC7822]に従って、フィールドが最小長さ16または28オクテットの要件とは反対に、暗号化された拡張フィールドは任意に短くなる可能性があります（ただし倍数でなければなりません）。長さ4オクテットのうち）。
N: The nonce SHALL be formed however required by the negotiated AEAD algorithm.
n：しかしながら、交渉されたAEADアルゴリズムによって必要とされる。
The purpose of the Additional Padding field is to ensure that servers can always choose a nonce whose length is adequate to ensure its uniqueness, even if the client chooses a shorter one, and still ensure that the overall length of the server's response packet does not exceed the length of the request. For mode 4 (server) packets, no Additional Padding field is ever required. For mode 3 (client) packets, the length of the Additional Padding field SHALL be computed as follows. Let 'N_LEN' be the padded length of the Nonce field. Let 'N_MAX' be, as specified by RFC 5116 [RFC5116], the maximum permitted nonce length for the negotiated AEAD algorithm. Let 'N_REQ' be the lesser of 16 and N_MAX, rounded up to the nearest multiple of 4. If N_LEN is greater than or equal to N_REQ, then no Additional Padding field is required. Otherwise, the Additional Padding field SHALL be at least N_REQ - N_LEN octets in length. Servers MUST enforce this requirement by discarding any packet that does not conform to it.
追加のパディングフィールドの目的は、クライアントがより短い方を選択していても、その長さが短く、サーバーの応答パケットの全体の長さが超えていないことを確認するために、サーバーがその長さを確保するために常に1つの長さが十分であることを確実に選択できるようにすることです。要求の長さモード4（サーバー）パケットの場合、追加のパディングフィールドは必要ありません。モード3（クライアント）パケットの場合、追加のパディングフィールドの長さは次のように計算されます。 n_len 'を非CCEフィールドの埋め込み長さにする。 RFC 5116 [RFC5116]で指定されているように、ネゴシエートされたAEADアルゴリズムの最大許容されていない長さで指定されている。 N_LENがN_REQ以上である場合は、追加のパディングフィールドは必要ない場合は、 'N_REQ'が16とN_MAXのより少ないです。そうでなければ、追加のパディングフィールドは少なくともn_req - n_lenの長さでなければならない。サーバーは、それに準拠していないパケットを破棄することによってこの要件を強制する必要があります。
Senders are always free to include more Additional Padding than mandated by the above paragraph. Theoretically, it could be necessary to do so in order to bring the extension field to the minimum length required by RFC 7822 [RFC7822]. This should never happen in practice because any reasonable AEAD algorithm will have a nonce and an authenticator long enough to bring the extension field to its required length already. Nonetheless, implementers are advised to explicitly handle this case and ensure that the extension field they emit is of legal length.
送信者は上記の段落で義務付けられているよりも多くの追加のパディングを含めることができます。理論的には、伸展場をRFC 7822 [RFC7822]に必要な最小長さにするためにそうすることが必要になるかもしれません。合理的なAEDアルゴリズムは、既存のフィールドをすでに必要な長さにするのに十分な長さとオーセンティケータを持つことになるため、これは実際には起こりません。それにもかかわらず、実装者はこのケースを明示的に処理し、それらが発信する拡張フィールドが正当な長さであることを確認しています。
The NTS Authenticator and Encrypted Extension Fields extension field MUST NOT be included in NTP packets whose mode is other than 3 (client) or 4 (server).
[NTS AuthenticatorおよびEncrypted Extension Fields Extension]フィールドは、モードが3（クライアント）または4（サーバー）以外のNTPパケットに含める必要があります。
A client sending an NTS-protected request SHALL include the following extension fields as displayed in Figure 5:
NTS保護要求を送信するクライアントには、図5に表示されているような次の拡張フィールドが含まれます。
Exactly one Unique Identifier extension field that MUST be authenticated, MUST NOT be encrypted, and whose contents MUST be the output of a cryptographically secure random number generator [RFC4086].
認証されなければならない一意の識別子拡張フィールドは、暗号化されてはならず、その内容は暗号的に安全な乱数発生器[RFC4086]の出力でなければなりません。
Exactly one NTS Cookie extension field that MUST be authenticated and MUST NOT be encrypted. The cookie MUST be one which has been previously provided to the client, either from the key establishment server during the NTS-KE handshake or from the NTP server in response to a previous NTS-protected NTP request.
認証されなければならず、暗号化されてはならないNTS Cookie拡張フィールドは正確にあります。Cookieは、NTS-KEハンドシェイク中、または以前のNTS保護されたNTP要求に応答してNTPサーバーからのキー設立サーバーから、クライアントに以前に提供されているものでなければなりません。
Exactly one NTS Authenticator and Encrypted Extension Fields extension field, generated using an AEAD algorithm and C2S key established through NTS-KE.
NTS-keを介して確立されたAEADアルゴリズムとC2Sキーを使用して生成されたExension Field Extensionフィールドは、正確に1つのNTSオーセンティケータと暗号化された拡張フィールド拡張フィールドです。
To protect the client's privacy, the client SHOULD avoid reusing a cookie. If the client does not have any cookies that it has not already sent, it SHOULD initiate a rerun of the NTS-KE protocol. The client MAY reuse cookies in order to prioritize resilience over unlinkability. Which of the two that should be prioritized in any particular case is dependent on the application and the user's preference. Section 9.1 describes the privacy considerations of this in further detail.
クライアントのプライバシーを保護するために、クライアントはクッキーを再利用しないようにしてください。クライアントにまだ送信されていないクッキーがない場合は、NTS-KEプロトコルの再実行を開始する必要があります。リンク不能に対する回復力を優先するために、クライアントはクッキーを再利用することができます。特定の場合に優先されるべき2つのうちのどれがアプリケーションとユーザーの好みに依存します。セクション9.1はこれについてのプライバシーの考慮事項をさらに詳細に説明しています。
The client MAY include one or more NTS Cookie Placeholder extension fields that MUST be authenticated and MAY be encrypted. The number of NTS Cookie Placeholder extension fields that the client includes SHOULD be such that if the client includes N placeholders and the server sends back N+1 cookies, the number of unused cookies stored by the client will come to eight. The client SHOULD NOT include more than seven NTS Cookie Placeholder extension fields in a request. When both the client and server adhere to all cookie-management guidance provided in this memo, the number of placeholder extension fields will equal the number of dropped packets since the last successful volley.
クライアントは、認証されなければならず暗号化され得る1つまたは複数のNTS Cookieプレースホルダ拡張フィールドを含み得る。クライアントが含まれているNTS Cookieプレースホルダ拡張フィールドの数は、クライアントにN個のプレースホルダが含まれ、サーバーがN 1 Cookieを送信すると、クライアントによって保存されている未使用のクッキーの数が8になるようにする必要があります。クライアントには、リクエスト内の7つ以上のNTS Cookieプレースホルダ拡張フィールドを含めるべきではありません。クライアントとサーバーの両方がこのメモに提供されているすべてのCookie管理ガイダンスに準拠している場合、プレースホルダ拡張フィールドの数は最後の成功したバレー以降のドロップされたパケットの数と同じです。
In rare circumstances, it may be necessary to include fewer NTS Cookie Placeholder extensions than recommended above in order to prevent datagram fragmentation. When cookies adhere to the format recommended in Section 6 and the AEAD in use is the mandatory-to-implement AEAD_AES_SIV_CMAC_256, senders can include a cookie and seven placeholders and still have packet size fall comfortably below 1280 octets if no non-NTS-related extensions are used; 1280 octets is the minimum prescribed MTU for IPv6 and is generally safe for avoiding IPv4 fragmentation. Nonetheless, senders SHOULD include fewer cookies and placeholders than otherwise indicated if doing so is necessary to prevent fragmentation.
まれな状況では、データグラムの断片化を防ぐために、上記のように推奨されるよりも少ないNTSクッキープレースホルダー拡張を含める必要があるかもしれません。Cookieがセクション6で推奨されているフォーマットに準拠していて、使用中のAEADが必須のAED_AES_SIV_CMAC_256である場合、送信者はCookieと7つのプレースホルダーを含めることができ、それでもNTS関連の拡張がない場合は1280オクテットを快適に快適に低下させることができます。使用されています;1280オクテットはIPv6のための最小規定のMTUであり、一般的にIPv4の断片化を避けるために安全です。それにもかかわらず、断片化を防ぐために必要な場合は、他に指示されるよりも、受信者には少ないクッキーとプレースホルダーが含まれるべきです。
+---------------------------------------+
| - Verify time request message. |
| - Generate time response message. |
| - Included NTPv4 extension fields: |
| o Unique Identifier EF |
| o NTS Authentication and |
| Encrypted Extension Fields EF |
| - NTS Cookie EF |
| - <NTS Cookie EF> |
| - Transmit time request packet. |
+-----------------+---------------------+
|
|
Server -----------+---------------+-----+----------------------->
^ \
/ \
Time request / \ Time response
(mode 3) / \ (mode 4)
/ \
/ V
Client -----+---------------------------------+----------------->
| |
| |
| |
+-----------+-----------------------+ +-----+------------------+
|- Generate time request message. | |- Verify time response |
| - Include NTPv4 Extension fields: | | message. |
| o Unique Identifier EF | |- Extract cookie(s). |
| o NTS Cookie EF | |- Time synchronization |
| o <NTS Cookie Placeholder EF> | | processing. |
| | +------------------------+
|- Generate AEAD tag of NTP message.|
|- Add NTS Authentication and |
| Encrypted Extension Fields EF. |
|- Transmit time request packet. |
+-----------------------------------+
Figure 5: NTS-Protected NTP Time Synchronization Messages
図5：NTS保護されたNTP時間同期メッセージ
The client MAY include additional (non-NTS-related) extension fields that MAY appear prior to the NTS Authenticator and Encrypted Extension Fields extension fields (therefore authenticated but not encrypted), within it (therefore encrypted and authenticated), or after it (therefore neither encrypted nor authenticated). The server MUST discard any unauthenticated extension fields. Future specifications of extension fields MAY provide exceptions to this rule.
クライアントは、NTS認証者および暗号化された拡張フィールド拡張フィールド（したがって認証されているが暗号化されていない）、内部（したがって暗号化され認証されていない）、またはその後に表示される可能性がある追加の（NTS関連）拡張フィールドを含み得る。暗号化も認証もしていません。サーバーは、認証されていない拡張フィールドを破棄する必要があります。拡張フィールドの将来の仕様は、この規則に例外を提供する可能性があります。
Upon receiving an NTS-protected request, the server SHALL (through some implementation-defined mechanism) use the cookie to recover the AEAD algorithm, C2S key, and S2C key associated with the request, and then use the C2S key to authenticate the packet and decrypt the ciphertext. If the cookie is valid and authentication and decryption succeed, the server SHALL include the following extension fields in its response:
NTS保護された要求を受信すると、サーバは（一部の実装定義のメカニズムを介して）Cookieを使用して、要求に関連したAEDアルゴリズム、C2Sキー、およびS2Cキーを回復してから、C2Sキーを使用してパケットを認証します。暗号文を復号化します。Cookieが有効で認証および復号化が成功した場合、サーバーはその応答に次の拡張フィールドを含めなければならない。
Exactly one Unique Identifier extension field that MUST be authenticated, MUST NOT be encrypted, and whose contents SHALL echo those provided by the client.
認証されなければならない一意の識別子拡張フィールドは、暗号化されてはならず、その内容はクライアントによって提供されるものをエコーしなければならない。
Exactly one NTS Authenticator and Encrypted Extension Fields extension field, generated using the AEAD algorithm and S2C key recovered from the cookie provided by the client.
クライアントから提供されたCookieからリカバリされたAEDアルゴリズムとS2Cキーを使用して生成されたExpending Field Extensionフィールドは、正確に1つのNTSオーセンティケータと暗号化された拡張フィールド拡張フィールド。
One or more NTS Cookie extension fields that MUST be authenticated and encrypted. The number of NTS Cookie extension fields included SHOULD be equal to, and MUST NOT exceed, one plus the number of valid NTS Cookie Placeholder extension fields included in the request. The cookies returned in those fields MUST be valid for use with the NTP server that sent them. They MAY be valid for other NTP servers as well, but there is no way for the server to indicate this.
認証され暗号化されなければならない1つ以上のNTS Cookie拡張フィールド。含まれているNTS Cookie拡張フィールドの数は、要求に含まれる有効なNTS Cookieプレースホルダ拡張フィールドの数と等しくなければならない、1つ、プラスを超えてはいけません。それらのフィールドに返されたクッキーは、送信されたNTPサーバーで使用するために有効でなければなりません。それらは他のNTPサーバーにも有効であるかもしれませんが、サーバーはこれを示す方法はありません。
We emphasize the contrast that NTS Cookie extension fields MUST NOT be encrypted when sent from client to server but MUST be encrypted when sent from server to client. The former is necessary in order for the server to be able to recover the C2S and S2C keys, while the latter is necessary to satisfy the unlinkability goals discussed in Section 9.1. We emphasize also that "encrypted" means encapsulated within the NTS Authenticator and Encrypted Extensions extension field. While the body of an NTS Cookie extension field will generally consist of some sort of AEAD output (regardless of whether the recommendations of Section 6 are precisely followed), this is not sufficient to make the extension field "encrypted".
Cookie拡張フィールドは、クライアントからサーバーに送信されたときにNTS Cookie拡張フィールドを暗号化しないでくださいが、サーバーからクライアントに送信されたときに暗号化されている必要があります。サーバーがC2SキーとS2Cキーを回復できるようにするために前者は必要ですが、後者はセクション9.1で説明したアンリンク許可の目標を満たすために必要です。「暗号化された」とは、NTS AuthenticatorおよびEncrypted Extensions拡張フィールド内にカプセル化されていることを意味することを強調します。NTS Cookieエクステンションフィールドの本体は一般に（セクション6の推奨事項が正確に従うかどうかにかかわらず）、ある種のAEAD出力からなるが、これは拡張フィールドを「暗号化」にするのに十分ではない。
The server MAY include additional (non-NTS-related) extension fields that MAY appear prior to the NTS Authenticator and Encrypted Extension Fields extension field (therefore authenticated but not encrypted), within it (therefore encrypted and authenticated), or after it (therefore neither encrypted nor authenticated). The client MUST discard any unauthenticated extension fields. Future specifications of extension fields MAY provide exceptions to this rule.
サーバは、NTS認証者および暗号化された拡張フィールド拡張フィールド（したがって暗号化されていないが暗号化されていない）、その中、またはその後に表示される可能性がある追加の（NTS関連）拡張フィールドを含むことができる。暗号化も認証もしていません。クライアントは、未認証されていない拡張フィールドを破棄する必要があります。拡張フィールドの将来の仕様は、この規則に例外を提供する可能性があります。
Upon receiving an NTS-protected response, the client MUST verify that the Unique Identifier matches that of an outstanding request, and that the packet is authentic under the S2C key associated with that request. If either of these checks fails, the packet MUST be discarded without further processing. In particular, the client MUST discard unprotected responses to NTS-protected requests.
NTS保護された応答を受信すると、クライアントは、一意の識別子が未処理の要求と一致すること、およびその要求に関連したS2Cキーの下で本物のパケットが認証されていることを確認する必要があります。これらのチェックのいずれかが失敗した場合は、それ以上の処理なしにパケットを破棄する必要があります。特に、クライアントは、保護されていない応答をNTS保護要求に廃棄する必要があります。
If the server is unable to validate the cookie or authenticate the request, it SHOULD respond with a Kiss-o'-Death (KoD) packet (see Section 7.4 of RFC 5905 [RFC5905]) with kiss code "NTSN", meaning "NTS NAK" (NTS negative-acknowledgment). It MUST NOT include any NTS Cookie or NTS Authenticator and Encrypted Extension Fields extension fields.
サーバーがCookieを検証できないか、要求を認証できない場合は、Kiss-O'-Death（KOD）パケット（RFC 5905 [RFC5905]のセクション7.4を参照）で応答する必要があります。NAK "（NTS否定応答）。それはNTS CookieまたはNTS AuthenticatorおよびEncrypted Extensionフィールド拡張フィールドを含めてはいけません。
If the NTP server has previously responded with authentic NTS-protected NTP packets, the client MUST verify that any KoD packets received from the server contain the Unique Identifier extension field and that the Unique Identifier matches that of an outstanding request. If this check fails, the packet MUST be discarded without further processing. If this check passes, the client MUST comply with Section 7.4 of RFC 5905 [RFC5905] where required.
NTPサーバが以前に認証されたNTS - Protected NTPパケットで以前に応答した場合、クライアントは、サーバから受信したKODパケットが一意の識別子拡張フィールドを含み、一意の識別子が未処理の要求の一致と一致することを検証する必要があります。このチェックが失敗した場合、パケットはそれ以上処理せずに破棄する必要があります。このチェックが合格した場合、クライアントはRFC 5905 [RFC5905]のセクション7.4に準拠している必要があります。
A client MAY automatically rerun the NTS-KE protocol upon forced disassociation from an NTP server. In that case, it MUST avoid quickly looping between the NTS-KE and NTP servers by rate limiting the retries. Requirements for retry intervals in NTS-KE are described in Section 4.2.
NTPサーバーからの強制的な解離後にNTS-KEプロトコルを自動的に再実行することができます。その場合、Retriesを制限するレートでNTS-KEとNTPサーバーをすばやくループするのを避ける必要があります。NTS-KEにおけるリトライ間隔の要件は4.2節で説明されています。
Upon reception of the NTS NAK kiss code, the client SHOULD wait until the next poll for a valid NTS-protected response, and if none is received, initiate a fresh NTS-KE handshake to try to renegotiate new cookies, AEAD keys, and parameters. If the NTS-KE handshake succeeds, the client MUST discard all old cookies and parameters and use the new ones instead. As long as the NTS-KE handshake has not succeeded, the client SHOULD continue polling the NTP server using the cookies and parameters it has.
NTS NAKキスコードを受信すると、クライアントは有効なNTS保護応答に対する次のポーリングを待つ必要があります。。NTS-KEハンドシェイクが成功した場合、クライアントは古いCookieとパラメータをすべて破棄し、代わりに新しいものを使用する必要があります。NTS-KEハンドシェイクが成功していない限り、クライアントはCookieとパラメータを使用してNTPサーバをポーリングし続けるべきです。
To allow for NTP session restart when the NTS-KE server is unavailable and to reduce NTS-KE server load, the client SHOULD keep at least one unused but recent cookie, AEAD keys, negotiated AEAD algorithm, and other necessary parameters in persistent storage. This way, the client is able to resume the NTP session without performing renewed NTS-KE negotiation.
NTS-KEサーバーが利用できず、NTS-KEサーバーのロードを削減すると、NTPセッションの再起動を許可するために、クライアントは少なくとも1つの未使用であるが最近のCookie、AEADキー、ネゴシエートされたAEDアルゴリズム、および永続的なストレージで必要なパラメータを保持する必要があります。このようにして、クライアントは更新されたNTS-KEネゴシエーションを実行せずにNTPセッションを再開することができます。
This section is non-normative. It gives a suggested way for servers to construct NTS cookies. All normative requirements are stated in Section 4.1.6 and Section 5.4.
このセクションは非規範です。それはサーバーがNTSクッキーを構築するための提案された方法を与えます。すべての規範的要件はセクション4.1.6およびセクション5.4に記載されています。
The role of cookies in NTS is closely analogous to that of session tickets in TLS. Accordingly, the thematic resemblance of this section to RFC 5077 [RFC5077] is deliberate, and the reader should likewise take heed of its security considerations.
NTSにおけるクッキーの役割は、TLSのセッションチケットの役割と密接に似ています。したがって、このセクションの主題のRFC 5077 [RFC5077]は故意になり、読者は同様にそのセキュリティ上の考慮事項を取り上げる必要があります。
Servers should select an AEAD algorithm that they will use to encrypt and authenticate cookies. The chosen algorithm should be one such as AEAD_AES_SIV_CMAC_256 [RFC5297], which resists accidental nonce reuse. It need not be the same as the one that was negotiated with the client. Servers should randomly generate and store a secret master AEAD key 'K'. Servers should additionally choose a non-secret, unique value 'I' as key identifier for 'K'.
サーバーは、Cookieの暗号化および認証に使用するAEDアルゴリズムを選択する必要があります。選択されたアルゴリズムは、偶発的なノンスの再利用に抵抗するaead_aes_siv_cmac_256 [RFC5297]のようなものでなければなりません。クライアントと交渉されたものと同じである必要はありません。サーバーはランダムに秘密マスターAEADキー 'k'を生成して保存する必要があります。サーバーは、「k」のキー識別子として、非秘密の固有値 'i'をさらに選択する必要があります。
Servers should periodically (e.g., once daily) generate a new pair '(I,K)' and immediately switch to using these values for all newly-generated cookies. Following each such key rotation, servers should securely erase any previously generated keys that should now be expired. Servers should continue to accept any cookie generated using keys that they have not yet erased, even if those keys are no longer current. Erasing old keys provides for forward secrecy, limiting the scope of what old information can be stolen if a master key is somehow compromised. Holding on to a limited number of old keys allows clients to seamlessly transition from one generation to the next without having to perform a new NTS-KE handshake.
サーバーは定期的に（例えば、1日1回）新しいペア '（i、k）'を生成し、直ちに新しく生成されたすべてのCookieについてこれらの値を使用するように切り替えます。そのようなキー回転ごとに、サーバーは、現在までに期限切れになる予定のキーをしっかりと消去する必要があります。サーバーは、それらのキーが電流でなくても、まだ消去されていないキーを使用して生成されたクッキーを受け入れ続けるべきです。古いキーを消すと、マスターキーが侵害されている場合、古い情報を盗まれる可能性があるものの範囲を制限することができます。限られた数の古いキーに保持することで、クライアントは新しいNTS-KEハンドシェイクを実行する必要なしに1世代から次の世代にシームレスに移行することができます。
The need to keep keys synchronized between NTS-KE and NTP servers as well as across load-balanced clusters can make automatic key rotation challenging. However, the task can be accomplished without the need for central key-management infrastructure by using a ratchet, i.e., making each new key a deterministic, cryptographically pseudorandom function of its predecessor. A recommended concrete implementation of this approach is to use HKDF [RFC5869] to derive new keys, using the key's predecessor as Input Keying Material and its key identifier as a salt.
NTS-KEおよびNTPサーバー間でキーを同期させ続ける必要性は、負荷分散クラスタを越えて、自動キー回転の困難を行うことができます。しかしながら、タスクは、ラチェットを使用することによって中心的な鍵管理インフラストラクチャを必要とせずに、すなわちそれぞれの新たな鍵をその前任者の決定論的暗号的に疑似乱数関数にすることができる。このアプローチの推奨される具体的な実装は、鍵の先行者を入力キーイング材料として使用し、塩としてのキー識別子を使用して、HKDF [RFC5869]を使用して新しいキーを導出することです。
To form a cookie, servers should first form a plaintext 'P' consisting of the following fields:
クッキーを形成するには、サーバーは最初に次のフィールドからなる平文 'P'を作成する必要があります。
The AEAD algorithm negotiated during NTS-KE.
NTS-KEの間にネゴシエートされたAEDアルゴリズム。
The S2C key.
S2Cキー。
The C2S key.
C2Sキー。
Servers should then generate a nonce 'N' uniformly at random, and form AEAD output 'C' by encrypting 'P' under key 'K' with nonce 'N' and no associated data.
その後、サーバーはランダムに無作為にノンス「N」を生成し、キー 'k'の下に 'P'を非CEN 'N'で暗号化し、関連付けられていないデータを暗号化することによって、AED出力 'C'を形成する必要があります。
The cookie should consist of the tuple '(I,N,C)'.
クッキーはタプル '（i、n、c）からなるべきです。
To verify and decrypt a cookie provided by the client, first parse it into its components 'I', 'N', and 'C'. Use 'I' to look up its decryption key 'K'. If the key whose identifier is 'I' has been erased or never existed, decryption fails; reply with an NTS NAK. Otherwise, attempt to decrypt and verify ciphertext 'C' using key 'K' and nonce 'N' with no associated data. If decryption or verification fails, reply with an NTS NAK. Otherwise, parse out the contents of the resulting plaintext 'P' to obtain the negotiated AEAD algorithm, S2C key, and C2S key.
クライアントによって提供されるクッキーを検証し復号化するには、まずそれをそのコンポーネント 'i'、 'n'、および 'c'に解析します。復号化キー 'k'を調べるには 'i'を使用してください。識別子が「i」の鍵が消去されたか存在しなかった場合、復号化は失敗します。NTS NAKで返信。それ以外の場合は、キー 'k'を使用して暗号文 'C'を復号化して検証してください。復号化または検証が失敗した場合は、NTS NAKで返信してください。それ以外の場合は、結果の平文 'P'の内容を解析して、ネゴシエートされたAEDアルゴリズム、S2Cキー、およびC2Sキーを取得します。
IANA has allocated the following entry in the "Service Name and Transport Protocol Port Number Registry" [RFC6335]:
IANAは、「サービス名とトランスポートプロトコルポート番号レジストリ」（RFC6335]に次のエントリを割り当てました。
Service Name: ntske
サービス名：NTSKE
Port Number: 4460
ポート番号：4460
Transport Protocol: tcp
トランスポートプロトコル：TCP.
Description: Network Time Security Key Establishment
説明：ネットワークタイムセキュリティキーの確立
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Registration Date: 2020-04-07
登録日：2020-04-07
Reference: RFC 8915
参照：RFC 8915
7.2. TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs Registry
7.2. TLSアプリケーション層プロトコルネゴシエーション（ALPN）プロトコルIDレジストリ
IANA has allocated the following entry in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry [RFC7301]:
IANAは、「TLSアプリケーション層プロトコルネゴシエーション（ALPN）プロトコルID」レジストリ[RFC7301]に次のエントリを割り当てました。
Protocol: Network Time Security Key Establishment, version 1
プロトコル：ネットワークタイムセキュリティキー設立、バージョン1
Identification Sequence: 0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1")
識別シーケンス：0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31（「NTSKE / 1」）
Reference: RFC 8915, Section 4
参照：RFC 8915、セクション4
IANA has allocated the following entry in the TLS Exporter Labels registry [RFC5705]:
IANAはTLSエクスポータのラベルレジストリ[RFC5705]に次のエントリを割り当てました。
+================================+=======+===========+=========+====+
| Value |DTLS-OK|Recommended|Reference|Note|
+================================+=======+===========+=========+====+
| EXPORTER-network-time-security |Y |Y |RFC 8915,| |
| | | |Section | |
| | | |4.3 | |
+--------------------------------+-------+-----------+---------+----+
Table 1
表1
IANA has allocated the following entry in the "NTP Kiss-o'-Death Codes" registry [RFC5905]:
IANAは、「NTP Kiss-O'-Death Codes」レジストリ[RFC5905]に次のエントリを割り当てました。
+======+===============================+=============+
| Code | Meaning | Reference |
+======+===============================+=============+
| NTSN | Network Time Security (NTS) | RFC 8915, |
| | negative-acknowledgment (NAK) | Section 5.7 |
+------+-------------------------------+-------------+
Table 2
表2.
IANA has allocated the following entries in the "NTP Extension Field Types" registry [RFC5905]:
IANAは、「NTP拡張フィールドタイプ」レジストリ[RFC5905]に次のエントリを割り当てました。
+============+============================+=======================+
| Field Type | Meaning | Reference |
+============+============================+=======================+
| 0x0104 | Unique Identifier | RFC 8915, Section 5.3 |
+------------+----------------------------+-----------------------+
| 0x0204 | NTS Cookie | RFC 8915, Section 5.4 |
+------------+----------------------------+-----------------------+
| 0x0304 | NTS Cookie Placeholder | RFC 8915, Section 5.5 |
+------------+----------------------------+-----------------------+
| 0x0404 | NTS Authenticator and | RFC 8915, Section 5.6 |
| | Encrypted Extension Fields | |
+------------+----------------------------+-----------------------+
Table 3
表3.
IANA has created a new registry entitled "Network Time Security Key Establishment Record Types". Entries have the following fields:
IANAは、「ネットワークタイムセキュリティキー設立レコードタイプ」と題された新しいレジストリを作成しました。エントリには次のフィールドがあります。
Record Type Number (REQUIRED): An integer in the range 0-32767 inclusive.
レコードタイプ番号（必須）：0~32767の範囲の整数。
Description (REQUIRED): A short text description of the purpose of the field.
説明（必須）：フィールドの目的の短いテキスト説明。
Reference (REQUIRED): A reference to a document specifying the semantics of the record.
参照（必須）：レコードのセマンティクスを指定する文書への参照。
The registration policy varies by Record Type Number, as follows:
登録ポリシーは、次のようにレコードタイプ番号によって異なります。
0-1023: IETF Review
0-1023：IETFの確認
1024-16383: Specification Required
1024-16383：仕様が必要です
16384-32767: Private or Experimental Use
16384-32767：民間または実験的な用途
The initial contents of this registry are as follows:
このレジストリの初期内容は次のとおりです。
+====================+======================+===============+
| Record Type Number | Description | Reference |
+====================+======================+===============+
| 0 | End of Message | RFC 8915, |
| | | Section 4.1.1 |
+--------------------+----------------------+---------------+
| 1 | NTS Next Protocol | RFC 8915, |
| | Negotiation | Section 4.1.2 |
+--------------------+----------------------+---------------+
| 2 | Error | RFC 8915, |
| | | Section 4.1.3 |
+--------------------+----------------------+---------------+
| 3 | Warning | RFC 8915, |
| | | Section 4.1.4 |
+--------------------+----------------------+---------------+
| 4 | AEAD Algorithm | RFC 8915, |
| | Negotiation | Section 4.1.5 |
+--------------------+----------------------+---------------+
| 5 | New Cookie for NTPv4 | RFC 8915, |
| | | Section 4.1.6 |
+--------------------+----------------------+---------------+
| 6 | NTPv4 Server | RFC 8915, |
| | Negotiation | Section 4.1.7 |
+--------------------+----------------------+---------------+
| 7 | NTPv4 Port | RFC 8915, |
| | Negotiation | Section 4.1.8 |
+--------------------+----------------------+---------------+
| 8-16383 | Unassigned | |
+--------------------+----------------------+---------------+
| 16384-32767 | Reserved for Private | RFC 8915 |
| | or Experimental Use | |
+--------------------+----------------------+---------------+
Table 4
表4.
IANA has created a new registry entitled "Network Time Security Next Protocols". Entries have the following fields:
IANAは、「ネットワークタイムセキュリティ次のプロトコル」と題された新しいレジストリを作成しました。エントリには次のフィールドがあります。
Protocol ID (REQUIRED): An integer in the range 0-65535 inclusive, functioning as an identifier.
プロトコルID（必須）：識別子として機能する範囲0~65535の範囲内の整数。
Protocol Name (REQUIRED): A short text string naming the protocol being identified.
プロトコル名（必須）：識別されているプロトコルの短いテキスト文字列。
Reference (REQUIRED): A reference to a relevant specification document.
参照（必須）：関連仕様書への参照。
The registration policy varies by Protocol ID, as follows:
登録ポリシーは、次のようにプロトコルIDによって異なります。
0-1023: IETF Review
0-1023：IETFの確認
1024-32767: Specification Required
1024-32767：仕様が必要です
32768-65535: Private or Experimental Use
32768-65535：民間または実験的な使用
The initial contents of this registry are as follows:
このレジストリの初期内容は次のとおりです。
+=============+=========================================+===========+
| Protocol ID | Protocol Name | Reference |
+=============+=========================================+===========+
| 0 | Network Time Protocol | RFC 8915 |
| | version 4 (NTPv4) | |
+-------------+-----------------------------------------+-----------+
| 1-32767 | Unassigned | |
+-------------+-----------------------------------------+-----------+
| 32768-65535 | Reserved for Private | RFC 8915 |
| | or Experimental Use | |
+-------------+-----------------------------------------+-----------+
Table 5
表5.
IANA has created two new registries entitled "Network Time Security Error Codes" and "Network Time Security Warning Codes". Entries in each have the following fields:
IANAは、「ネットワークタイムセキュリティエラーコード」と「ネットワークタイムセキュリティ警告コード」というタイミング2つの新しいレジストリを作成しました。各エントリには、次のフィールドがあります。
Number (REQUIRED): An integer in the range 0-65535 inclusive
番号（必須）：0~65535の範囲の整数
Description (REQUIRED): A short text description of the condition.
説明（必須）：条件の短いテキストの説明。
Reference (REQUIRED): A reference to a relevant specification document.
参照（必須）：関連仕様書への参照。
The registration policy varies by Number, as follows:
次のように、登録ポリシーは数によって異なります。
0-1023: IETF Review
0-1023：IETFの確認
1024-32767: Specification Required
1024-32767：仕様が必要です
32768-65535: Private or Experimental Use
32768-65535：民間または実験的な使用
The initial contents of the "Network Time Security Error Codes" registry are as follows:
「ネットワークタイムセキュリティエラーコード」レジストリの初期内容は次のとおりです。
+=============+==============================+===============+
| Number | Description | Reference |
+=============+==============================+===============+
| 0 | Unrecognized Critical Record | RFC 8915, |
| | | Section 4.1.3 |
+-------------+------------------------------+---------------+
| 1 | Bad Request | RFC 8915, |
| | | Section 4.1.3 |
+-------------+------------------------------+---------------+
| 2 | Internal Server Error | RFC 8915, |
| | | Section 4.1.3 |
+-------------+------------------------------+---------------+
| 3-32767 | Unassigned | |
+-------------+------------------------------+---------------+
| 32768-65535 | Reserved for Private or | RFC 8915 |
| | Experimental Use | |
+-------------+------------------------------+---------------+
Table 6
表6.
The "Network Time Security Warning Codes" registry is initially empty except for the reserved range, i.e.:
「ネットワークタイムセキュリティ警告コード」レジストリは、予約範囲を除いて最初に空です。
+=============+======================+===========+
| Number | Description | Reference |
+=============+======================+===========+
| 0-32767 | Unassigned | |
+-------------+----------------------+-----------+
| 32768-65535 | Reserved for Private | RFC 8915 |
| | or Experimental Use | |
+-------------+----------------------+-----------+
Table 7
表7.
NTP provides many different operating modes in order to support different network topologies and to adapt to various requirements. This memo only specifies NTS for NTP modes 3 (client) and 4 (server) (see Section 1.3). The best current practice for authenticating the other NTP modes is using the symmetric message authentication code feature as described in RFC 5905 [RFC5905] and RFC 8573 [RFC8573].
NTPは、さまざまなネットワークトポロジをサポートし、さまざまな要件に適応するために、さまざまな動作モードを提供します。このメモは、NTPモード3（クライアント）と4（サーバー）のNTSのみを指定します（セクション1.3を参照）。他のNTPモードを認証するための最良の現在の慣行は、RFC 5905 [RFC5905]およびRFC 8573 [RFC8573]に記載されているように、対称メッセージ認証コード機能を使用しています。
If the suggested format for NTS cookies in Section 6 of this document is used, an attacker who has gained access to the secret cookie encryption key 'K' can impersonate the NTP server, including generating new cookies. NTP and NTS-KE server operators SHOULD remove compromised keys as soon as the compromise is discovered. This will cause the NTP servers to respond with NTS NAK, thus forcing key renegotiation. Note that this measure does not protect against MITM attacks where the attacker has access to a compromised cookie encryption key. If another cookie scheme is used, there are likely similar considerations for that particular scheme.
このドキュメントのセクション6のNTS Cookieの推奨フォーマットが使用されている場合、Secret Cookie暗号化キー 'k'へのアクセスを得た攻撃者は、新しいCookieの生成を含むNTPサーバーを偽装することができます。NTPおよびNTS-KEサーバーのオペレータは、妥協が発見されるとすぐに侵入先のキーを削除する必要があります。これにより、NTPサーバーはNTS NAKで応答するため、キーの再交渉を強制します。このメジャーは、攻撃者が侵入したCookie暗号化キーにアクセスできるMITM攻撃から保護されません。別のCookieスキームが使用されている場合、その特定のスキームについても同様の考慮事項があります。
The introduction of NTS brings with it the introduction of asymmetric cryptography to NTP. Asymmetric cryptography is necessary for initial server authentication and AEAD key extraction. Asymmetric cryptosystems are generally orders of magnitude slower than their symmetric counterparts. This makes it much harder to build systems that can serve requests at a rate corresponding to the full line speed of the network connection. This, in turn, opens up a new possibility for DDoS attacks on NTP services.
NTSの導入は、NTPへの非対称暗号化の導入をもたらします。非対称暗号化は、初期サーバ認証とAEDキー抽出に必要です。非対称暗号システムは一般に、それらの対称的な対応物よりも桁違いに遅い。これにより、ネットワーク接続の全回線速度に対応するレートで要求を処理できるシステムを構築することがはるかに困難になります。これにより、NTPサービスに対するDDOS攻撃が新しい可能性があります。
The main protection against these attacks in NTS lies in that the use of asymmetric cryptosystems is only necessary in the initial NTS-KE phase of the protocol. Since the protocol design enables separation of the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE server separated from the NTP service it supports will not affect NTP users that have already performed initial authentication, AEAD key extraction, and cookie exchange.
NTSにおけるこれらの攻撃に対する主な保護は、非対称暗号システムの使用がプロトコルの初期NTS-KEフェーズでのみ必要であるという点である。プロトコル設計はNTS-KEおよびNTPサーバーの分離を可能にするため、NTPサービスITサポートから区切られたNTS-KEサーバーに対するDDOS攻撃を成功させることは、最初の認証、AEDキー抽出、およびCookieを実行しているNTPユーザーに影響を与えません。両替。
NTS users should also consider that they are not fully protected against DoS attacks by on-path adversaries. In addition to dropping packets and attacks such as those described in Section 8.6, an on-path attacker can send spoofed Kiss-o'-Death replies, which are not authenticated, in response to NTP requests. This could result in significantly increased load on the NTS-KE server. Implementers have to weigh the user's need for unlinkability against the added resilience that comes with cookie reuse in cases of NTS-KE server unavailability.
NTSユーザーはまた、オンパスの敵対者によるDOS攻撃に対して完全に保護されていないと考える必要があります。セクション8.6に記載されているパケットや攻撃をドロップすることに加えて、On-Path攻撃者は、NTP要求に応答して、認証されていない偽のキスO'- Deathの返信を送信できます。これにより、NTS-KEサーバーの負荷が大幅に増加する可能性があります。NTS-keサーバーの使用可能性の場合にCookieの再利用が付属している追加の回復力に対するユーザーの必要性のためのユーザーの必要性をユーザーの不安定にする必要があります。
Certain nonstandard and/or deprecated features of the Network Time Protocol enable clients to send a request to a server that causes the server to send a response much larger than the request. Servers that enable these features can be abused in order to amplify traffic volume in DDoS attacks by sending them a request with a spoofed source IP address. In recent years, attacks of this nature have become an endemic nuisance.
ネットワークタイムプロトコルの特定の非標準および/または非推奨の機能は、クライアントがサーバーに要求を要求よりもはるかに大きい応答を送信させるサーバーに要求を送信することを可能にします。偽造された送信元IPアドレスで要求を送信することで、DDOS攻撃でトラフィックボリュームを増幅するために、これらの機能を有効にするサーバーを廃棄することができます。近年、この性質の攻撃は流行の迷惑となっています。
NTS is designed to avoid contributing any further to this problem by ensuring that NTS-related extension fields included in server responses will be the same size as the NTS-related extension fields sent by the client. In particular, this is why the client is required to send a separate and appropriately padded-out NTS Cookie Placeholder extension field for every cookie it wants to get back, rather than being permitted simply to specify a desired quantity.
NTSは、サーバー応答に含まれるNTS関連の拡張フィールドがクライアントによって送信されたNTS関連の拡張フィールドと同じサイズになることを確認することで、この問題にさらなる貢献を回避するように設計されています。特に、このクライアントが、希望の数量を指定することを許可されるのではなく、戻ることが許可されているのではなく、クライアントが別のクッキーのPlaceHolder Extenseフィールドを別々のパディアアウト・アウト・拡張フィールドを送信する必要がある理由です。
Due to the RFC 7822 [RFC7822] requirement that extensions be padded and aligned to four-octet boundaries, response size may still in some cases exceed request size by up to three octets. This is sufficiently inconsequential that we have declined to address it.
RFC 7822 [RFC7822]の要件の要件により、拡張子が4オクテット境界に埋め込まれて位置合わせする必要があるため、応答サイズは依然として最大3オクテットで要求サイズを超える可能性があります。これは私たちがそれに対処することを拒否したほど十分に重要ではありません。
NTS's security goals are undermined if the client fails to verify that the X.509 certificate chain presented by the NTS-KE server is valid and rooted in a trusted certificate authority. RFC 5280 [RFC5280] and RFC 6125 [RFC6125] specify how such verification is to be performed in general. However, the expectation that the client does not yet have a correctly-set system clock at the time of certificate verification presents difficulties with verifying that the certificate is within its validity period, i.e., that the current time lies between the times specified in the certificate's notBefore and notAfter fields. It may be operationally necessary in some cases for a client to accept a certificate that appears to be expired or not yet valid. While there is no perfect solution to this problem, there are several mitigations the client can implement to make it more difficult for an adversary to successfully present an expired certificate:
クライアントがNTS-KEサーバーによって提示されたX.509証明書チェーンが有効で信頼できる認証局に根ざしていることを確認できない場合、NTSのセキュリティの目標は損なわれています。RFC 5280 [RFC5280]とRFC 6125 [RFC6125]このような検証を一般的に実行する方法を指定します。ただし、証明書の検証時にクライアントが正しく設定されていないという期待は、証明書がその有効期間内にあること、つまり、現在の時刻が証明書に指定された時間の間にあることを確認することで困難を示しています。フィールド以外のフィールドとノーマ。場合によっては、クライアントが期限切れまたは有効ではないと思われる証明書を受け入れるためには、操作上必要とされている可能性があります。この問題に対する完璧な解決策はありませんが、敵対者が期限切れの証明書を正常に提示することをより困難にするためにクライアントが実装できるいくつかの軽減があります。
Check whether the system time is in fact unreliable. On systems with the ntp_adjtime() system call, a return code other than TIME_ERROR indicates that some trusted software has already set the time and certificates can be strictly validated.
システムの時間が実際には信頼できないかどうかを確認してください。ntp_adjtime（）システムコールを持つシステムでは、time_error以外の戻りコードは、いくつかの信頼できるソフトウェアがすでに時間を設定していることを示し、証明書を厳密に検証できることを示します。
Allow the system administrator to specify that certificates should _always_ be strictly validated. Such a configuration is appropriate on systems that have a battery-backed clock or that can reasonably prompt the user to manually set an approximately correct time if it appears to be needed.
システム管理者が証明書を_always_を厳密に検証するように指定できるようにします。このような構成は、バッテリバッククロックを持つシステムに適しています。または、必要に応じてほぼ正しい時間を手動で設定するようにユーザーに手動で設定できるシステムに適しています。
Once the clock has been synchronized, periodically write the current system time to persistent storage. Do not accept any certificate whose notAfter field is earlier than the last recorded time.
クロックが同期されたら、定期的に現在のシステム時間を永続ストレージに書き込みます。最後の記録された時間より早い、NOTMAFTERフィールドが早い証明書を受け付けないでください。
NTP time replies are expected to be consistent with the NTS-KE TLS certificate validity period, i.e. time replies received immediately after an NTS-KE handshake are expected to lie within the certificate validity period. Implementations are recommended to check that this is the case. Performing a new NTS-KE handshake based solely on the fact that the certificate used by the NTS-KE server in a previous handshake has expired is normally not necessary. Clients that still wish to do this must take care not to cause an inadvertent denial-of-service attack on the NTS-KE server, for example by picking a random time in the week preceding certificate expiry to perform the new handshake.
NTP時間の返信は、NTS-KE TLS証明書の有効期間、すなわちNTS-KEハンドシェイクが証明書の有効期間内にあると予想されると予想される時間返信が予想されます。これが事実であることを確認するために実装をお勧めします。前回のハンドシェイクでNTS-KEサーバーが使用する証明書が期限切れになっているという事実に基づいて、新しいNTS-KEハンドシェイクを実行することは通常必要ありません。これを行いたいクライアントは、新しいハンドシェイクを実行するために証明書の有効期限の前にある週にランダムな時間を選ぶことによって、NTS-KEサーバーに対して不注意によるサービス拒否攻撃を引き起こさないように注意しなければなりません。
Use multiple time sources. The ability to pass off an expired certificate is only useful to an adversary who has compromised the corresponding private key. If the adversary has compromised only a minority of servers, NTP's selection algorithm (Section 11.2.1 of RFC 5905 [RFC5905]) will protect the client from accepting bad time from the adversary-controlled servers.
複数のタイムソースを使用してください。期限切れの証明書を停止する能力は、対応する秘密鍵を危険にさらした敵対者にのみ役立ちます。敵対者が少数派のサーバーのみを侵害した場合、NTPの選択アルゴリズム（RFC 5905 [RFC5905]のセクション11.2.1）は、クライアントが有害管理サーバーから悪い時間を受け入れることを保証します。
In a packet delay attack, an adversary with the ability to act as a man-in-the-middle delays time synchronization packets between client and server asymmetrically [RFC7384]. Since NTP's formula for computing time offset relies on the assumption that network latency is roughly symmetrical, this leads to the client to compute an inaccurate value [Mizrahi]. The delay attack does not reorder or modify the content of the exchanged synchronization packets. Therefore, cryptographic means do not provide a feasible way to mitigate this attack. However, the maximum error that an adversary can introduce is bounded by half of the round-trip delay.
パケット遅延攻撃では、クライアントとサーバー間の時間同期パケットを非対称的に遅延に遅らせる能力を持つ能力を守ることができます[RFC7384]。計算時間オフセットのためのNTPの式は、ネットワークの待ち時間が大まかに対称的であるという仮定に依存しているので、これはクライアントに不正確な値を計算することがあります[Mizrahi]。遅延攻撃は、交換された同期パケットの内容を並べ替えまたは変更しません。したがって、暗号化手段はこの攻撃を軽減するための実行可能な方法を提供しない。ただし、敵対的な敵が導入できる最大誤差は、往復遅延の半分に囲まれています。
RFC 5905 [RFC5905] specifies a parameter called MAXDIST, which denotes the maximum round-trip latency (including not only the immediate round trip between client and server, but the whole distance back to the reference clock as reported in the Root Delay field) that a client will tolerate before concluding that the server is unsuitable for synchronization. The standard value for MAXDIST is one second, although some implementations use larger values. Whatever value a client chooses, the maximum error that can be introduced by a delay attack is MAXDIST/2.
RFC 5905 [RFC5905] MaxDistと呼ばれるパラメータを指定します。これは最大往復レイテンシを表します（クライアントとサーバー間の即時の往復だけでなく、ルート遅延フィールドに報告されている基準クロックに戻る全距離）。サーバーが同期には不適切であることを締めくくる前に、クライアントは許容されます。MAXDISTの標準値は1秒ですが、一部の実装はより大きな値を使用します。クライアントが選択したとしても、遅延攻撃によって導入できる最大エラーはMAXDIST / 2です。
Usage of multiple time sources, or multiple network paths to a given time source [Shpiner], may also serve to mitigate delay attacks if the adversary is in control of only some of the paths.
複数のタイムソースの使用、または特定の時間源[SHPINER]への複数のネットワークパスの使用は、敵対者がいくつかのパスのみを管理している場合、遅延攻撃を軽減するのに役立ちます。
Implementers must be aware of the possibility of "NTS stripping" attacks, where an attacker attempts to trick clients into reverting to plain NTP. Naive client implementations might, for example, revert automatically to plain NTP if the NTS-KE handshake fails. A man-in-the-middle attacker can easily cause this to happen. Even clients that already hold valid cookies can be vulnerable, since an attacker can force a client to repeat the NTS-KE handshake by sending faked NTP mode 4 replies with the NTS NAK kiss code. Forcing a client to repeat the NTS-KE handshake can also be the first step in more advanced attacks.
実装者は、「NTSストリッピング」攻撃の可能性を認識しており、攻撃者は顧客がプレーンNTPに戻るようにトリックしようとします。NTS-KEハンドシェイクが失敗した場合は、たとえば、NAIVEクライアントの実装は自動的にPlain NTPに戻る可能性があります。中間攻撃者がこれを簡単に起こる可能性があります。攻撃者は、Kaked NTPモード4の返信をNTS NAK Kissコードで送信することで、クライアントにNTS-KEハンドシェイクを繰り返すことができるため、攻撃者がクライアントにNTS-KEハンドシェイクを繰り返すことができるため、攻撃者に脆弱なクライアントを脆弱にすることができます。クライアントを強制するためにNTS-KEハンドシェイクを繰り返すことも、より高度な攻撃の最初のステップになります。
For the reasons described here, implementations SHOULD NOT revert from NTS-protected to unprotected NTP with any server without explicit user action.
ここで説明されている理由で、実装はNTS保護されたNTPから明示的なユーザアクションなしで任意のサーバーとの間で元に戻されないNTPから元に戻すべきではありません。
Unlinkability prevents a device from being tracked when it changes network addresses (e.g., because said device moved between different networks). In other words, unlinkability thwarts an attacker that seeks to link a new network address used by a device with a network address that it was formerly using because of recognizable data that the device persistently sends as part of an NTS-secured NTP association. This is the justification for continually supplying the client with fresh cookies, so that a cookie never represents recognizable data in the sense outlined above.
リンク不能は、ネットワークアドレスを変更したときに装置が追跡されるのを防ぎ（例えば、前記装置は異なるネットワーク間で移動されたため）。言い換えれば、無効ネルは、デバイスが使用するネットワークアドレスと、そのデバイスがNTSセキュアNTPアソシエーションの一部として送信する認識可能なデータのために使用されていたネットワークアドレスを持つネットワークアドレスとをリンクしようとしている攻撃者を妨げます。これは、クッキーが上記の意味で認識可能なデータを決して表さないように、新鮮なクッキーを継続的に供給するための正当化です。
NTS's unlinkability objective is merely to not leak any additional data that could be used to link a device's network address. NTS does not rectify legacy linkability issues that are already present in NTP. Thus, a client that requires unlinkability must also minimize information transmitted in a client query (mode 3) packet as described in the document NTP Client Data Minimization [NTP-DATA-MIN].
NTSのリンク無効性の目的は、デバイスのネットワークアドレスをリンクするために使用できる追加のデータを漏らすだけではありません。NTSは、すでにNTPに存在している従来のリンク性の問題を修正しません。したがって、リンク許可を必要とするクライアントはまた、文書NTPクライアントデータ最小化[NTP - DATA - MIN]に記載されているように、クライアントクエリ（モード3）パケットで送信された情報を最小化する必要があります。
The unlinkability objective only holds for time synchronization traffic, as opposed to key establishment traffic. This implies that it cannot be guaranteed for devices that function not only as time clients, but also as time servers (because the latter can be externally triggered to send linkable data, such as the TLS certificate).
アンリンク許可の目的は、鍵設立トラフィックとは対照的に、時間同期トラフィックを保持しています。これは、時間クライアントとしてだけでなく時間サーバとしても機能するデバイスに対しては保証できないことを意味します（TLS証明書などのリンク可能データを送信するために外部からトリガーすることができるため）。
It should also be noted that it could be possible to link devices that operate as time servers from their time synchronization traffic, using information exposed in (mode 4) server response packets (e.g. reference ID, reference time, stratum, poll). Also, devices that respond to NTP control queries could be linked using the information revealed by control queries.
また、（モード4）サーバ応答パケット（例えば、参照ID、基準時間、層、投票）で情報を使用して、時間サーバとして動作するデバイスをそれらの時間同期トラフィックからリンクすることも可能であることにも留意されたい。また、NTP制御クエリに応答するデバイスは、制御クエリによって明らかにされた情報を使用してリンクすることができます。
Note that the unlinkability objective does not prevent a client device from being tracked by its time servers.
なお、アンリンク許可の目的は、クライアントデバイスがそのタイムサーバによって追跡されないようにしていないことに注意してください。
NTS does not protect the confidentiality of information in NTP's header fields. When clients implement NTP Client Data Minimization [NTP-DATA-MIN], client packet headers do not contain any information that the client could conceivably wish to keep secret: one field is random, and all others are fixed. Information in server packet headers is likewise public: the origin timestamp is copied from the client's (random) transmit timestamp, and all other fields are set the same regardless of the identity of the client making the request.
NTSは、NTPのヘッダーフィールド内の情報の機密性を保護しません。クライアントがNTPクライアントデータの最小化[NTP-DATA-MIN]を実装すると、クライアントパケットヘッダーには、クライアントが秘密を保つことをお勧めしたい情報が含まれていません.1フィールドはランダムで、他のすべてが固定されています。サーバーパケットヘッダーの情報も同様に公開されています。オリジンタイムスタンプはクライアントの（ランダム）送信タイムスタンプからコピーされ、その他すべてのフィールドはリクエストを行うクライアントのIDに関係なく同じように設定されます。
Future extension fields could hypothetically contain sensitive information, in which case NTS provides a mechanism for encrypting them.
将来の拡張フィールドは、機密情報を仮定的に含めることができ、その場合NTSはそれらを暗号化するためのメカニズムを提供します。
[IANA-AEAD] IANA, "Authenticated Encryption with Associated Data (AEAD) Parameters", <https://www.iana.org/assignments/aead-parameters/>.
[IANA AEAD] IANA、「関連するデータ（AED）パラメータ（AED）パラメータを使用した認証された暗号化」、<https：//www.iana.org/assignments/aead-parameters/>。
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC0020] CERF、V.、ネットワークインターチェンジの「ASCIIフォーマット」、STD 80、RFC 20、DOI 10.17487 / RFC0020、<https：//www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116] MCGREW、D。、「認証済み暗号化のためのインタフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https：//www.rfc-editor.org/info/rfc5116>。
[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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 2008, <https://www.rfc-editor.org/info/rfc5297>.
[RFC5297] Harkins、D。、「高度な暗号化規格（AES）」、RFC 5297、DOI 10.17487 / RFC5297、DOI 10.17487 / RFC5297、<https：//ww.rfc-editor.org/ info / rfc5297>。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5705] Rescorla、E。、「トランスポート層セキュリティ（TLS）のキーイング輸出業者（TLS）」、RFC 5705、DOI 10.17487 / RFC5705、2010年3月、<https://www.rfc-editor.org/info/rfc5705>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H.およびP. Eronen、「HMACベースの抽出と拡張キー派生機能（HKDF）」、RFC 5869、DOI 10.17487 / RFC 5869、2010年5月、<https：//www.rfc-編集者.org / info / rfc5869>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J.、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https：//www.rfc-editor.org/info/RFC5890>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M.、Eggert、L.、Touch、J.、Westerlund、M.、S. Cheshire、「インターネット割り当て番号局（IANA）サービス名とトランスポートプロトコルポート番号レジストリの管理の手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https：//www.rfc-editor.org/info/rfc6335>。
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, February 2013, <https://www.rfc-editor.org/info/rfc6874>.
[RFC6874] Carpenter、B.、Cheshire、S.およびR.hinden、「アドレスリテラルおよび統一リソース識別子のIPv6ゾーン識別子の表現」、RFC 6874、DOI 10.17487 / RFC6874、2013年2月、<https：// www。rfc-editor.org/info/rfc6874>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A.、およびE.Stethan、「トランスポート層セキュリティ（TLS）アプリケーション層プロトコルネゴシエーション拡張」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, March 2016, <https://www.rfc-editor.org/info/rfc7822>.
[RFC7822] Mizrahi、T.およびD. Mayer、 "Network Time Protocol Version Fields"、RFC 7822、DOI 10.17487 / RFC7822、2016年3月、<https：//www.rfc-editor.org/info/ RFC7822>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[Mizrahi] Mizrahi, T., "A game theoretic analysis of delay attacks against time synchronization protocols", 2012 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication Proceedings, pp. 1-6, DOI 10.1109/ISPCS.2012.6336612, September 2012, <https://doi.org/10.1109/ISPCS.2012.6336612>.
[Mizrahi] Mizrahi、T.、「時間同期プロトコルに対する遅延攻撃のゲーム理論的解析」、2012年IEEE PREEE SCRPOSIUM測定、制御、通信手続、PP。1-6、DOI 10.1109 / ISPCS.2012.6336612、2012年9月、<https://doi.org/10.1109/ISPCS.2012.633612>。
[NTP-DATA-MIN] Franke, D. F. and A. Malhotra, "NTP Client Data Minimization", Work in Progress, Internet-Draft, draft-ietf-ntp-data-minimization-04, 25 March 2019, <https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04>.
[NTP-Data-Min] Frankke、DF、A. Malhotra、 "NTPクライアントデータ最小化"、進行中の作業、インターネットドラフト、ドラフト-IETF-NTP-Data-Minimization-04,2019,2019、<https：//tools.ietf.org/html/draft-ietf-ntp-data-minimization-04>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.org / info / rfc4086>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P.、およびH。Tschofenig、「サーバー側の状態なしのトランスポート層セキュリティ（TLS）セッション再開」、RFC 5077、DOI 10.17487 / RFC5077、2008年1月、<https://www.rfc-editor.org/info/rfc5077>。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384] Mizrahi、T.、「パケット交換ネットワークにおける時間プロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https：//www.rfc-editor.org/info/rfc7384>。
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code for the Network Time Protocol", RFC 8573, DOI 10.17487/RFC8573, June 2019, <https://www.rfc-editor.org/info/rfc8573>.
[RFC8573] Malhotra、A.およびS.goldberg、「ネットワークタイムプロトコルのメッセージ認証コード」、RFC 8573、DOI 10.17487 / RFC8573、2019年6月、<https：//www.rfc-editor.org/info/rfc8573>。
[Shpiner] Shpiner, A., Revah, Y., and T. Mizrahi, "Multi-path Time Protocols", 2013 IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS) Proceedings, pp. 1-6, DOI 10.1109/ISPCS.2013.6644754, September 2013, <https://doi.org/10.1109/ISPCS.2013.6644754>.
[Shpiner] Shpiner、A.、Revah、Y.、T.Mizrahi、「マルチパスタイムプロトコル」、2013年IEEE国際シンポジウム測定、制御、通信（ISPCS）議事録（ISPC）議事録、PP。1-6、DOI 10.1109 / ISPCS.2013.664754、2013年9月、<https：//doi.org/10.1109/ISPCS.2013.6644755>。
Acknowledgments
謝辞
The authors would like to thank Richard Barnes, Steven Bellovin, Scott Fluhrer, Patrik Fältström, Sharon Goldberg, Russ Housley, Benjamin Kaduk, Suresh Krishnan, Mirja Kühlewind, Martin Langer, Barry Leiba, Miroslav Lichvar, Aanchal Malhotra, Danny Mayer, Dave Mills, Sandra Murphy, Hal Murray, Karen O'Donoghue, Eric K. Rescorla, Kurt Roeckx, Stephen Roettger, Dan Romascanu, Kyle Rose, Rich Salz, Brian Sniffen, Susan Sons, Douglas Stebila, Harlan Stenn, Joachim Strömbergsson, Martin Thomson, Éric Vyncke, Richard Welty, Christer Weinigel, and Magnus Westerlund for contributions to this document and comments on the design of NTS.
著者らは、Richard Barnes、Steven Bellovin、Scott Fluhrer、Scott Fluhrer、Sharon Goldberg、Russ Housle、Russ Housle、Benjamin Kaduk、MirjanKühlewind、Martin Langer、Miroslav Lichvar、Miroslav Lichvar、Danay Murs、Dave Mills、Sandra Murphy、Halray、Karen K. Rescora、Kurt Roeckx、Stephen Roettger、Dan Romascanu、Kyle Rose、Rich Salz、Brian Sniffen、Susan Sonsn、Harlan Stenn、Martin Thomson、Susan Stenn、Joachim Strembergsson、éricVyncke、Richard Weinigel、Christer Weinigel、およびMagnus Westerlundこの文書への貢献とNTSの設計に関するコメント。
Authors' Addresses
著者の住所
Daniel Fox Franke Akamai Technologies 145 Broadway Cambridge, MA 02142 United States of America
Daniel Fox Franke Akamai Technologies 145 Broadway Cambridge、MA 02142アメリカ合衆国
Email: dafranke@akamai.com
Dieter Sibold Physikalisch-Technische Bundesanstalt Bundesallee 100 D-38116 Braunschweig Germany
Dieter Sibold Physikalisch-Technische Bundesanstalt Bundesallee 100 D-38116 Braunschweigドイツ
Phone: +49-(0)531-592-8462
Email: dieter.sibold@ptb.de
Kristof Teichel Physikalisch-Technische Bundesanstalt Bundesallee 100 D-38116 Braunschweig Germany
Kristof Teichel Physikalisch-Technische Bundesanstalt Bundesallee 100 D-38116 Braunschweigドイツ
Phone: +49-(0)531-592-4471
Email: kristof.teichel@ptb.de
Marcus Dansarie Sweden
Marcus Dansarieスウェーデン
Email: marcus@dansarie.se
URI: https://orcid.org/0000-0001-9246-0263
Ragnar Sundblad Netnod Sweden
Ragnar Sundblad Netnodスウェーデン
Email: ragge@netnod.se