[要約] RFC 7384は、パケットスイッチングネットワークにおける時間プロトコルのセキュリティ要件についてのガイドラインです。このRFCの目的は、時間プロトコルのセキュリティを向上させ、ネットワーク上のタイムサービスの信頼性と安全性を確保することです。
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7384 Marvell
Category: Informational October 2014
ISSN: 2070-1721
Security Requirements of Time Protocols in Packet Switched Networks
パケット交換ネットワークにおけるタイムプロトコルのセキュリティ要件
Abstract
概要
As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.
時間と周波数の配信プロトコルがますます一般的になり、広く配備されるようになるにつれて、さまざまなセキュリティ脅威への暴露に関する懸念が高まっています。このドキュメントでは、プレシジョンタイムプロトコル（PTP）とネットワークタイムプロトコル（NTP）を中心に、タイムプロトコルの一連のセキュリティ要件を定義します。このドキュメントでは、時間プロトコルプラクティスのセキュリティへの影響、時間プロトコルに対する外部セキュリティプラクティスのパフォーマンスの影響、および他のセキュリティサービスと時間同期の間の依存関係についても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7384.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7384で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Requirements Language ......................................5
2.2. Abbreviations ..............................................6
2.3. Common Terminology for PTP and NTP .........................6
2.4. Terms Used in This Document ................................6
3. Security Threats ................................................7
3.1. Threat Model ...............................................8
3.1.1. Internal vs. External Attackers .....................8
3.1.2. Man in the Middle (MITM) vs. Packet Injector ........8
3.2. Threat Analysis ............................................9
3.2.1. Packet Manipulation .................................9
3.2.2. Spoofing ............................................9
3.2.3. Replay Attack .......................................9
3.2.4. Rogue Master Attack .................................9
3.2.5. Packet Interception and Removal ....................10
3.2.6. Packet Delay Manipulation ..........................10
3.2.7. L2/L3 DoS Attacks ..................................10
3.2.8. Cryptographic Performance Attacks ..................10
3.2.9. DoS Attacks against the Time Protocol ..............11
3.2.10. Grandmaster Time Source Attack (e.g., GPS Fraud) ..11
3.2.11. Exploiting Vulnerabilities in the Time Protocol ...11
3.2.12. Network Reconnaissance ............................11
3.3. Threat Analysis Summary ...................................12
4. Requirement Levels .............................................13
5. Security Requirements ..........................................14
5.1. Clock Identity Authentication and Authorization ...........14
5.1.1. Authentication and Authorization of Masters ........15
5.1.2. Recursive Authentication and Authorization
of Masters (Chain of Trust) ........................16
5.1.3. Authentication and Authorization of Slaves .........17
5.1.4. PTP: Authentication and Authorization of
P2P TCs by the Master ..............................18
5.1.5. PTP: Authentication and Authorization of
Control Messages ...................................18
5.2. Protocol Packet Integrity .................................19
5.2.1. PTP: Hop-by-Hop vs. End-to-End Integrity
Protection .........................................20
5.2.1.1. Hop-by-Hop Integrity Protection ...........20
5.2.1.2. End-to-End Integrity Protection ...........21
5.3. Spoofing Prevention .......................................21
5.4. Availability ..............................................22
5.5. Replay Protection .........................................23
5.6. Cryptographic Keys and Security Associations ..............23
5.6.1. Key Freshness ......................................23
5.6.2. Security Association ...............................24
5.6.3. Unicast and Multicast Associations .................24
5.7. Performance ...............................................25
5.8. Confidentiality ...........................................26
5.9. Protection against Packet Delay and Interception Attacks ..27
5.10. Combining Secured with Unsecured Nodes ...................27
5.10.1. Secure Mode .......................................28
5.10.2. Hybrid Mode .......................................28
6. Summary of Requirements ........................................29
7. Additional Security Implications ...............................31
7.1. Security and On-the-Fly Timestamping ......................31
7.2. PTP: Security and Two-Step Timestamping ...................31
7.3. Intermediate Clocks .......................................32
7.4. External Security Protocols and Time Protocols ............32
7.5. External Security Services Requiring Time .................33
7.5.1. Timestamped Certificates ...........................33
7.5.2. Time Changes and Replay Attacks ....................33
8. Issues for Further Discussion ..................................34
9. Security Considerations ........................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................34
Acknowledgments ...................................................36
Contributors ......................................................36
Author's Address ..................................................36
As time protocols are becoming increasingly common and widely deployed, concern about the resulting exposure to various security threats is increasing. If a time protocol is compromised, the applications it serves are prone to a range of possible attacks including Denial of Service (DoS) or incorrect behavior.
時間プロトコルがますます一般的になり、広く展開されるようになるにつれて、さまざまなセキュリティの脅威にさらされることに対する懸念が高まっています。タイムプロトコルが危険にさらされると、サービスを提供するアプリケーションは、サービス拒否（DoS）や不正な動作など、さまざまな攻撃を受ける可能性があります。
This document discusses the security aspects of time distribution protocols in packet networks and focuses on the two most common protocols: the Network Time Protocol [NTPv4] and the Precision Time Protocol (PTP) [IEEE1588]. Note that although PTP was not defined by the IETF, it is one of the two most common time protocols; hence, it is included in the discussion.
このドキュメントでは、パケットネットワークの時間配信プロトコルのセキュリティ面について説明し、最も一般的な2つのプロトコルであるネットワークタイムプロトコル[NTPv4]と高精度時間プロトコル（PTP）[IEEE1588]に焦点を当てています。 PTPはIETFで定義されていませんが、2つの最も一般的な時間プロトコルの1つであることに注意してください。したがって、それは議論に含まれています。
The Network Time Protocol was defined with an inherent security protocol; [NTPv4] defines a security protocol that is based on a symmetric key authentication scheme, and [AutoKey] presents an alternative security protocol, based on a public key authentication scheme. [IEEE1588] includes an experimental security protocol, defined in Annex K of the standard, but this Annex was never formalized into a fully defined security protocol.
ネットワークタイムプロトコルは、固有のセキュリティプロトコルで定義されました。 [NTPv4]は対称鍵認証方式に基づくセキュリティプロトコルを定義し、[AutoKey]は公開鍵認証方式に基づく代替セキュリティプロトコルを提示します。 [IEEE1588]には、標準の附属書Kで定義された実験的なセキュリティプロトコルが含まれていますが、この附属書は、完全に定義されたセキュリティプロトコルに形式化されていません。
While NTP includes an inherent security protocol, the absence of a standard security solution for PTP undoubtedly contributed to the wide deployment of unsecured time synchronization solutions. However, in some cases, security mechanisms may not be strictly necessary, e.g., due to other security practices in place or due to the architecture of the network. A time synchronization security solution, much like any security solution, is comprised of various building blocks and must be carefully tailored for the specific system in which it is deployed. Based on a system-specific threat assessment, the benefits of a security solution must be weighed against the potential risks, and based on this trade-off an optimal security solution can be selected.
NTPには固有のセキュリティプロトコルが含まれていますが、PTP用の標準のセキュリティソリューションがないことは、セキュリティで保護されていない時間同期ソリューションの幅広い展開に貢献したことは間違いありません。ただし、場合によっては、他のセキュリティ対策が実施されていたり、ネットワークのアーキテクチャが原因であったりするなど、セキュリティメカニズムが厳密に必要でない場合もあります。時間同期セキュリティソリューションは、他のセキュリティソリューションと同様に、さまざまなビルディングブロックで構成されており、展開される特定のシステムに合わせて注意深く調整する必要があります。システム固有の脅威評価に基づいて、セキュリティソリューションの利点を潜在的なリスクと比較検討する必要があり、このトレードオフに基づいて最適なセキュリティソリューションを選択できます。
The target audience of this document includes:
このドキュメントの対象読者は次のとおりです。
o Timing and networking equipment vendors - can benefit from this document by deriving the security features that should be supported in the time/networking equipment.
o タイミングおよびネットワーク機器ベンダー-時間/ネットワーク機器でサポートされるべきセキュリティ機能を導出することにより、このドキュメントから利益を得ることができます。
o Standards development organizations - can use the requirements defined in this document when specifying security mechanisms for a time protocol.
o 標準開発組織-時間プロトコルのセキュリティメカニズムを指定するときに、このドキュメントで定義されている要件を使用できます。
o Network operators - can use this document as a reference when designing a network and its security architecture. As stated above, the requirements in this document may be deployed selectively based on a careful per-system threat analysis.
o ネットワークオペレーター-このドキュメントは、ネットワークとそのセキュリティアーキテクチャを設計する際の参考資料として使用できます。上記のように、このドキュメントの要件は、システムごとの注意深い脅威分析に基づいて選択的に展開できます。
This document attempts to add clarity to the time protocol security requirements discussion by addressing a series of questions:
このドキュメントは、一連の質問に対処することにより、時間プロトコルのセキュリティ要件の議論を明確にすることを試みています。
(1) What are the threats that need to be addressed for the time protocol and what security services need to be provided (e.g., a malicious NTP server or PTP master)?
（1）時間プロトコルで対処する必要のある脅威と、提供する必要のあるセキュリティサービス（悪意のあるNTPサーバーやPTPマスターなど）は何ですか？
(2) What external security practices impact the security and performance of time keeping and what can be done to mitigate these impacts (e.g., an IPsec tunnel in the time protocol traffic path)?
（2）どの外部セキュリティプラクティスが時間管理のセキュリティとパフォーマンスに影響を与え、これらの影響を軽減するために何ができるか（たとえば、時間プロトコルトラフィックパスのIPsecトンネル）？
(3) What are the security impacts of time protocol practices (e.g., on-the-fly modification of timestamps)?
（3）時間プロトコルの実践（タイムスタンプのオンザフライ修正など）のセキュリティへの影響は何ですか？
(4) What are the dependencies between other security services and time protocols? (For example, which comes first - the certificate or the timestamp?)
（4）他のセキュリティサービスと時間プロトコルの間の依存関係は何ですか？ （たとえば、どちらが最初に来るか-証明書またはタイムスタンプ？）
In light of the questions above, this document defines a set of requirements for security solutions for time protocols, focusing on PTP and NTP.
上記の質問に照らして、このドキュメントでは、PTPとNTPに重点を置いて、時間プロトコルのセキュリティソリューションに対する一連の要件を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
This document describes security requirements; thus, requirements are phrased in the document in the form "the security mechanism MUST/SHOULD/...". Note that the phrasing does not imply that this document defines a specific security mechanism, but that it defines the requirements with which every security mechanism should comply.
このドキュメントでは、セキュリティ要件について説明します。したがって、要件はドキュメント内で「セキュリティメカニズムは必須/必須/ ...」の形式で表現されます。言い回しは、このドキュメントが特定のセキュリティメカニズムを定義することを意味するのではなく、すべてのセキュリティメカニズムが準拠する必要がある要件を定義することに注意してください。
BC Boundary Clock [IEEE1588]
BC境界クロック[IEEE1588]
BMCA Best Master Clock Algorithm [IEEE1588]
BMCAベストマスタークロックアルゴリズム[IEEE1588]
DoS Denial of Service
DoSサービス拒否
MITM Man in the Middle
MITMマン・イン・ザ・ミドル
NTP Network Time Protocol [NTPv4]
NTPネットワークタイムプロトコル[NTPv4]
OC Ordinary Clock [IEEE1588]
OC普通の時計[IEEE1588]
P2P TC Peer-to-Peer Transparent Clock [IEEE1588]
P2P TCピアツーピアトランスペアレントクロック[IEEE1588]
PTP Precision Time Protocol [IEEE1588]
PTP精度時間プロトコル[IEEE1588]
TC Transparent Clock [IEEE1588]
TC透過クロック[IEEE1588]
This document refers to both PTP and NTP. For the sake of consistency, throughout the document the term "master" applies to both a PTP master and an NTP server. Similarly, the term "slave" applies to both PTP slaves and NTP clients. The term "protocol packets" refers generically to PTP and NTP messages.
このドキュメントでは、PTPとNTPの両方を参照しています。一貫性を保つために、ドキュメント全体で「マスター」という用語は、PTPマスターとNTPサーバーの両方に適用されます。同様に、「スレーブ」という用語は、PTPスレーブとNTPクライアントの両方に適用されます。 「プロトコルパケット」という用語は、一般的にPTPおよびNTPメッセージを指します。
o Clock - A node participating in the protocol (either PTP or NTP). A clock can be a master, a slave, or an intermediate clock (see corresponding definitions below).
o クロック-プロトコルに参加しているノード（PTPまたはNTP）。クロックは、マスター、スレーブ、または中間クロックにすることができます（以下の対応する定義を参照）。
o Control packets - Packets used by the protocol to exchange information between clocks that is not strictly related to the time. NTP uses NTP Control Messages. PTP uses Announce, Signaling, and Management messages.
o 制御パケット-時間に厳密に関連していないクロック間で情報を交換するためにプロトコルによって使用されるパケット。 NTPはNTP制御メッセージを使用します。 PTPは、アナウンス、シグナリング、および管理メッセージを使用します。
o End-to-end security - A security approach where secured packets sent from a source to a destination are not modified by intermediate nodes, allowing the destination to authenticate the source of the packets and to verify their integrity. In the context of confidentiality, end-to-end encryption guarantees that intermediate nodes cannot eavesdrop to en route packets. However, as discussed in Section 5, confidentiality is not a strict requirement in this document.
o エンドツーエンドのセキュリティ-送信元から宛先に送信されたセキュリティで保護されたパケットが中間ノードによって変更されないセキュリティアプローチ。宛先がパケットの送信元を認証し、整合性を検証できるようにします。機密性のコンテキストでは、エンドツーエンドの暗号化により、中間ノードがパケットを転送するために盗聴できないことが保証されます。ただし、セクション5で説明したように、このドキュメントでは機密性は厳密な要件ではありません。
o Grandmaster - A master that receives time information from a locally attached clock device and not through the network. A grandmaster distributes its time to other clocks in the network.
o グランドマスター-ネットワーク経由ではなく、ローカルに接続された時計デバイスから時刻情報を受信するマスター。グランドマスターはその時間をネットワーク内の他の時計に分配します。
o Hop-by-hop security - A security approach where secured packets sent from a source to a destination may be modified by intermediate nodes. In this approach intermediate nodes share the encryption key with the source and destination, allowing them to re-encrypt or re-authenticate modified packets before relaying them to the destination.
o ホップバイホップセキュリティ-送信元から宛先に送信される保護されたパケットが中間ノードによって変更される可能性があるセキュリティアプローチ。このアプローチでは、中間ノードは暗号化キーをソースと宛先と共有し、変更されたパケットを宛先にリレーする前に再暗号化または再認証できるようにします。
o Intermediate clock - A clock that receives timing information from a master and sends timing information to other clocks. In NTP, this term refers to an NTP server that is not a Stratum 1 server. In PTP, this term refers to a BC or a TC.
o 中間クロック-マスターからタイミング情報を受け取り、他のクロックにタイミング情報を送信するクロック。 NTPでは、この用語はStratum 1サーバーではないNTPサーバーを指します。 PTPでは、この用語はBCまたはTCを指します。
o Master - A clock that generates timing information to other clocks in the network. In NTP, 'master' refers to an NTP server. In PTP, 'master' refers to a master OC (aka grandmaster) or to a port of a BC that is in the master state.
o マスター-ネットワーク内の他のクロックにタイミング情報を生成するクロック。 NTPでは、「マスター」はNTPサーバーを指します。 PTPでは、「マスター」はマスターOC（別名グランドマスター）またはマスター状態のBCのポートを指します。
o Protocol packets - Packets used by the time protocol. The terminology used in this document distinguishes between time packets and control packets.
o プロトコルパケット-時間プロトコルで使用されるパケット。このドキュメントで使用されている用語は、時間パケットと制御パケットを区別しています。
o Secured clock - A clock that supports a security mechanism that complies to the requirements in this document.
o 保護されたクロック-このドキュメントの要件に準拠するセキュリティメカニズムをサポートするクロック。
o Slave - A clock that receives timing information from a master. In NTP, 'slave' refers to an NTP client. In PTP, 'slave' refers to a slave OC or to a port of a BC that is in the slave state.
o スレーブ-マスターからタイミング情報を受け取るクロック。 NTPでは、「スレーブ」はNTPクライアントを指します。 PTPでは、「スレーブ」はスレーブOCまたはスレーブ状態のBCのポートを指します。
o Time packets - Protocol packets carrying time information.
o 時間パケット-時間情報を運ぶプロトコルパケット。
o Unsecured clock - A clock that does not support a security mechanism according to the requirements in this document.
o 安全でないクロック-このドキュメントの要件によるセキュリティメカニズムをサポートしないクロック。
This section discusses the possible attacker types and analyzes various attacks against time protocols.
このセクションでは、考えられる攻撃者のタイプについて説明し、時間プロトコルに対するさまざまな攻撃を分析します。
The literature is rich with security threats of time protocols, e.g., [Traps], [AutoKey], [TimeSec], [SecPTP], and [SecSen]. The threat analysis in this document is mostly based on [TimeSec].
文献には、[トラップ]、[AutoKey]、[TimeSec]、[SecPTP]、[SecSen]などのタイムプロトコルのセキュリティ脅威が豊富に含まれています。このドキュメントの脅威分析は、主に[TimeSec]に基づいています。
A time protocol can be attacked by various types of attackers.
時間プロトコルは、さまざまなタイプの攻撃者に攻撃される可能性があります。
The analysis in this document classifies attackers according to two criteria, as described in Sections 3.1.1 and 3.1.2.
このドキュメントの分析では、セクション3.1.1および3.1.2で説明されているように、2つの基準に従って攻撃者を分類します。
In the context of internal and external attackers, the underlying assumption is that the time protocol is secured by either an encryption mechanism, an authentication mechanism, or both.
内部および外部の攻撃者のコンテキストでは、根本的な前提は、時間プロトコルが暗号化メカニズム、認証メカニズム、またはその両方によって保護されていることです。
Internal attackers either have access to a trusted segment of the network or possess the encryption or authentication keys. An internal attack can also be performed by exploiting vulnerabilities in devices; for example, by installing malware or obtaining credentials to reconfigure the device. Thus, an internal attacker can maliciously tamper with legitimate traffic in the network as well as generate its own traffic and make it appear legitimate to its attacked nodes.
内部の攻撃者は、ネットワークの信頼されたセグメントにアクセスするか、暗号化キーまたは認証キーを所持しています。内部の攻撃は、デバイスの脆弱性を悪用することによっても実行できます。たとえば、マルウェアをインストールするか、デバイスを再構成するための資格情報を取得します。したがって、内部の攻撃者は、ネットワーク内の正当なトラフィックを悪意を持って改ざんしたり、独自のトラフィックを生成したりして、攻撃されたノードに対して正当に見せかけることができます。
Note that internal attacks are a special case of Byzantine failures, where a node in the system may fail in arbitrary ways; by crashing, by omitting messages, or by malicious behavior. This document focuses on nodes that demonstrate malicious behavior.
内部攻撃はビザンチン障害の特別なケースであり、システム内のノードが任意の方法で失敗する可能性があることに注意してください。クラッシュ、メッセージの省略、または悪意のある動作。このドキュメントでは、悪意のある動作を示すノードに焦点を当てています。
External attackers, on the other hand, do not have the keys and have access only to the encrypted or authenticated traffic.
一方、外部の攻撃者はキーを持たず、暗号化または認証されたトラフィックにのみアクセスできます。
Obviously, in the absence of a security mechanism, there is no distinction between internal and external attackers, since all attackers are internal in practice.
明らかに、セキュリティメカニズムがない場合、実際にはすべての攻撃者が内部にいるため、内部と外部の攻撃者の区別はありません。
MITM attackers are located in a position that allows interception and modification of in-flight protocol packets. It is assumed that an MITM attacker has physical access to a segment of the network or has gained control of one of the nodes in the network.
MITM攻撃者は、機内プロトコルパケットの傍受と変更を可能にする位置に配置されています。 MITM攻撃者がネットワークのセグメントに物理的にアクセスするか、ネットワーク内のノードの1つを制御していると想定されています。
A traffic injector is not located in an MITM position, but can attack by generating protocol packets. An injector can reside either within the attacked network or on an external network that is connected to the attacked network. An injector can also potentially eavesdrop on protocol packets sent as multicast, record them, and replay them later.
トラフィックインジェクタはMITM位置にありませんが、プロトコルパケットを生成することにより攻撃できます。インジェクタは、攻撃されたネットワーク内、または攻撃されたネットワークに接続されている外部ネットワーク上に存在できます。インジェクタは、マルチキャストとして送信されたプロトコルパケットを盗聴し、記録し、後で再生することもできます。
A packet manipulation attack results when an MITM attacker receives timing protocol packets, alters them, and relays them to their destination, allowing the attacker to maliciously tamper with the protocol. This can result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information.
パケット操作攻撃は、MITM攻撃者がタイミングプロトコルパケットを受信し、それらを変更して宛先に中継するときに発生し、攻撃者が悪意を持ってプロトコルを改ざんすることを可能にします。これは、時間プロトコルが明らかに動作しているが、意図的に不正確な情報を提供している状況になる可能性があります。
In spoofing, an injector masquerades as a legitimate node in the network by generating and transmitting protocol packets or control packets. Two typical examples of spoofing attacks:
スプーフィングでは、インジェクタは、プロトコルパケットまたは制御パケットを生成して送信することにより、ネットワーク内の正当なノードになりすまします。なりすまし攻撃の2つの典型的な例：
o An attacker can impersonate the master, allowing malicious distribution of false timing information.
o 攻撃者はマスターになりすまして、不正なタイミング情報を悪意を持って配布することができます。
o An attacker can impersonate a legitimate clock, a slave, or an intermediate clock, by sending malicious messages to the master, causing the master to respond to the legitimate clock with protocol packets that are based on the spoofed messages. Consequently, the delay computations of the legitimate clock are based on false information.
o 攻撃者は、悪意のあるメッセージをマスターに送信し、マスターになりすましメッセージに基づくプロトコルパケットを使用して正当なクロックに応答させることにより、正当なクロック、スレーブ、または中間クロックを偽装できます。その結果、正当なクロックの遅延計算は誤った情報に基づいています。
As with packet manipulation, this attack can result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information.
パケット操作と同様に、この攻撃は、タイムプロトコルが明らかに動作しているが、意図的に不正確な情報を提供している状況を引き起こす可能性があります。
In a replay attack, an attacker records protocol packets and replays them at a later time without any modification. This can also result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information.
リプレイ攻撃では、攻撃者はプロトコルパケットを記録し、変更せずに後でリプレイします。これはまた、時間プロトコルが明らかに動作しているが、意図的に不正確な情報を提供している状況をもたらす可能性があります。
In a rogue master attack, an attacker causes other nodes in the network to believe it is a legitimate master. As opposed to the spoofing attack, in the rogue master attack the attacker does not fake its identity, but rather manipulates the master election process using malicious control packets. For example, in PTP, an attacker can manipulate the Best Master Clock Algorithm (BMCA) and cause other nodes in the network to believe it is the most eligible candidate to be a grandmaster.
不正なマスター攻撃では、攻撃者はネットワーク内の他のノードに、それを正当なマスターであると信じ込ませます。なりすまし攻撃とは対照的に、不正なマスター攻撃では、攻撃者はそのIDを偽造せず、悪意のある制御パケットを使用してマスター選出プロセスを操作します。たとえば、PTPでは、攻撃者はベストマスタークロックアルゴリズム（BMCA）を操作して、ネットワーク内の他のノードに、グランドマスターの候補として最も適格であると信じ込ませることができます。
In PTP, a possible variant of this attack is the rogue TC/BC attack. Similar to the rogue master attack, an attacker can cause victims to believe it is a legitimate TC or BC, allowing the attacker to manipulate the time information forwarded to the victims.
PTPでは、この攻撃の変形の可能性は不正なTC / BC攻撃です。不正なマスター攻撃と同様に、攻撃者は被害者に正当なTCまたはBCであると信じ込ませ、被害者に転送された時間情報を操作することができます。
A packet interception and removal attack results when an MITM attacker intercepts and drops protocol packets, preventing the destination node from receiving some or all of the protocol packets.
MITM攻撃者がプロトコルパケットを傍受してドロップすると、パケット傍受および削除攻撃が発生し、宛先ノードがプロトコルパケットの一部またはすべてを受信できなくなります。
In a packet delay manipulation scenario, an MITM attacker receives protocol packets and relays them to their destination after adding a maliciously computed delay. The attacker can use various delay attack strategies; the added delay can be constant, jittered, or slowly wandering. Each of these strategies has a different impact, but they all effectively manipulate the attacked clock.
パケット遅延操作シナリオでは、MITM攻撃者はプロトコルパケットを受信し、悪意を持って計算された遅延を追加した後、それらを宛先に中継します。攻撃者はさまざまな遅延攻撃戦略を使用できます。追加される遅延は、一定、ジッター、またはゆっくりとさまよっている可能性があります。これらの戦略にはそれぞれ異なる影響がありますが、攻撃されたクロックを効果的に操作します。
Note that the victim still receives one copy of each packet, contrary to the replay attack, where some or all of the packets may be received by the victim more than once.
リプレイ攻撃とは対照的に、犠牲者は依然として各パケットの1つのコピーを受信することに注意してください。この場合、一部またはすべてのパケットが犠牲者によって複数回受信される可能性があります。
There are many possible Layer 2 and Layer 3 DoS attacks, e.g., IP spoofing, ARP spoofing [Hack], MAC flooding [Anatomy], and many others. As the target's availability is compromised, the timing protocol is affected accordingly.
レイヤー2およびレイヤー3のDoS攻撃には、IPスプーフィング、ARPスプーフィング[ハック]、MACフラッディング[アナトミー]など、多くの可能性があります。ターゲットの可用性が損なわれると、それに応じてタイミングプロトコルが影響を受けます。
In cryptographic performance attacks, an attacker transmits fake protocol packets, causing high utilization of the cryptographic engine at the receiver, which attempts to verify the integrity of these fake packets.
暗号パフォーマンス攻撃では、攻撃者は偽のプロトコルパケットを送信します。これにより、受信側で暗号エンジンが高利用され、これらの偽のパケットの整合性を検証しようとします。
This DoS attack is applicable to all encryption and authentication protocols. However, when the time protocol uses a dedicated security mechanism implemented in a dedicated cryptographic engine, this attack can be applied to cause DoS specifically to the time protocol.
このDoS攻撃は、すべての暗号化および認証プロトコルに適用されます。ただし、時間プロトコルが専用の暗号化エンジンに実装された専用のセキュリティメカニズムを使用している場合、この攻撃を適用して、特に時間プロトコルにDoSを引き起こすことができます。
An attacker can attack a clock by sending an excessive number of time protocol packets, thus degrading the victim's performance. This attack can be implemented, for example, using the attacks described in Sections 3.2.2 and 3.2.4.
攻撃者は、過剰な数の時間プロトコルパケットを送信してクロックを攻撃し、被害者のパフォーマンスを低下させる可能性があります。この攻撃は、たとえば、セクション3.2.2および3.2.4で説明されている攻撃を使用して実装できます。
Grandmasters receive their time from an external accurate time source, such as an atomic clock or a GPS clock, and then distribute this time to the slaves using the time protocol.
グランドマスターは、原子時計やGPS時計などの外部の正確な時刻源から時刻を受け取り、時刻プロトコルを使用してこの時刻をスレーブに配信します。
Time source attacks are aimed at the accurate time source of the grandmaster. For example, if the grandmaster uses a GPS-based clock as its reference source, an attacker can jam the reception of the GPS signal, or transmit a signal similar to one from a GPS satellite, causing the grandmaster to use a false reference time.
タイムソース攻撃は、グランドマスターの正確なタイムソースを狙っています。たとえば、グランドマスターがGPSベースのクロックを参照ソースとして使用している場合、攻撃者はGPS信号の受信を妨害したり、GPS衛星からの信号と同様の信号を送信したりして、グランドマスターに誤った参照時間を使用させる可能性があります。
Note that this attack is outside the scope of the time protocol. While various security measures can be taken to mitigate this attack, these measures are outside the scope of the security requirements defined in this document.
この攻撃はタイムプロトコルの範囲外であることに注意してください。この攻撃を緩和するためにさまざまなセキュリティ対策を講じることができますが、これらの対策は、このドキュメントで定義されているセキュリティ要件の範囲外です。
Time protocols can be attacked by exploiting vulnerabilities in the protocol, implementation bugs, or misconfigurations (e.g., [NTPDDoS]). It should be noted that such attacks cannot typically be mitigated by security mechanisms. However, when a new vulnerability is discovered, operators should react as soon as possible, and take the necessary measures to address it.
時間プロトコルは、プロトコルの脆弱性、実装のバグ、または設定ミス（[NTPDDoS]など）を悪用することで攻撃される可能性があります。このような攻撃は、通常、セキュリティメカニズムでは軽減できないことに注意してください。ただし、新しい脆弱性が発見された場合、オペレーターはできるだけ早く対応し、必要な対策を講じて対処する必要があります。
An attacker can exploit the time protocol to collect information such as addresses and locations of nodes that take part in the protocol. Reconnaissance can be applied by either passively eavesdropping on protocol packets or sending malicious packets and gathering information from the responses. By eavesdropping on a time protocol, an attacker can learn the network latencies, which provide information about the network topology and node locations.
攻撃者は、時間プロトコルを悪用して、プロトコルに参加するノードのアドレスや場所などの情報を収集できます。偵察は、プロトコルパケットを受動的に盗聴するか、悪意のあるパケットを送信して応答から情報を収集することによって適用できます。攻撃者は、タイムプロトコルを盗聴することにより、ネットワークレイテンシを知ることができます。これにより、ネットワークトポロジとノードの場所に関する情報が提供されます。
Moreover, properties such as the frequency of the protocol packets, or the exact times at which they are sent, can allow fingerprinting of specific nodes; thus, protocol packets from a node can be identified even if network addresses are hidden or encrypted.
さらに、プロトコルパケットの頻度や、パケットが送信される正確な時間などのプロパティにより、特定のノードのフィンガープリントが可能になります。したがって、ネットワークアドレスが非表示または暗号化されている場合でも、ノードからのプロトコルパケットを識別できます。
The two key factors to a threat analysis are the impact and the likelihood of each of the analyzed attacks.
脅威分析の2つの重要な要素は、分析された各攻撃の影響と可能性です。
Table 1 summarizes the security attacks presented in Section 3.2. For each attack, the table specifies its impact, and its applicability to each of the attacker types presented in Section 3.1.
表1は、セクション3.2で提示されたセキュリティ攻撃をまとめたものです。この表では、各攻撃について、その影響と、セクション3.1で示した各攻撃者タイプへの適用性を示しています。
Table 1 clearly shows the distinction between external and internal attackers, and motivates the usage of authentication and integrity protection, significantly reducing the impact of external attackers.
表1は、外部の攻撃者と内部の攻撃者の違いを明確に示しており、認証と整合性保護の使用に動機を与え、外部の攻撃者の影響を大幅に減らします。
The Impact column provides an intuitive measure of the severity of each attack, and the relevant Attacker Type column provides an intuition about how difficult each attack is to implement and, hence, about the likelihood of each attack.
「影響」列は、各攻撃の重大度の直感的な測定値を提供し、関連する「攻撃者タイプ」列は、各攻撃の実装の難しさ、したがって各攻撃の可能性についての直感を提供します。
The Impact column in Table 1 can have one of three values:
表1のImpact列には、次の3つの値のいずれかを指定できます。
o DoS - the attack causes denial of service to the attacked node, the impact of which is not restricted to the time protocol.
o DoS-攻撃は攻撃されたノードにサービス拒否を引き起こし、その影響は時間プロトコルに限定されません。
o Accuracy degradation - the attack yields a degradation in the slave accuracy, but does not completely compromise the slaves' time and frequency.
o 精度の低下-攻撃によりスレーブの精度が低下しますが、スレーブの時間と周波数が完全に損なわれるわけではありません。
o False time - slaves align to a false time or frequency value due to the attack. Note that if the time protocol aligns to a false time, it may cause DoS to other applications that rely on accurate time. However, for the purpose of the analysis in this section, we distinguish this implication from 'DoS', which refers to a DoS attack that is not necessarily aimed at the time protocol. All attacks that have a '+' for 'False Time' implicitly have a '+' for 'Accuracy Degradation'. Note that 'False Time' necessarily implies 'Accuracy Degradation'. However, two different terms are used, indicating two levels of severity.
o 偽の時間-スレーブは、攻撃のために偽の時間または周波数の値に合わせます。時間プロトコルが誤った時間に合わせると、正確な時間に依存する他のアプリケーションにDoSが発生する可能性があることに注意してください。ただし、このセクションの分析のために、この意味を「DoS」と区別します。「DoS」は、必ずしも時間プロトコルを目的としたものではないDoS攻撃を指します。 「False Time」に「+」が付いているすべての攻撃には、「Accuracy Degradation」に「+」が暗黙的に含まれています。 「False Time」は必ず「Accuracy Degradation」を意味することに注意してください。ただし、2つの異なる用語が使用されており、2つのレベルの重大度を示しています。
The Attacker Type column refers to the four possible combinations of the attacker types defined in Section 3.1.
「攻撃者タイプ」列は、セクション3.1で定義された攻撃者タイプの4つの可能な組み合わせを示しています。
+-----------------------------+-------------------++-------------------+
| Attack | Impact || Attacker Type |
| +-----+--------+----++---------+---------+
| |False|Accuracy| ||Internal |External |
| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|
+-----------------------------+-----+--------+----++----+----+----+----+
|Manipulation | + | | || + | | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Spoofing | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Replay attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Rogue master attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Interception and removal | | + | + || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Packet delay manipulation | + | | || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|L2/L3 DoS attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|Crypt. performance attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|Time protocol DoS attacks | | | + || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Master time source attack | + | | || + | + | + | + |
|(e.g., GPS spoofing) | | | || | | | |
+-----------------------------+-----+--------+----++----+----+----+----+
Table 1: Threat Analysis - Summary
表1：脅威分析-概要
The threats discussed in this section provide the background for the security requirements presented in Section 5.
このセクションで説明する脅威は、セクション5で提示したセキュリティ要件の背景を提供します。
The security requirements are presented in Section 5. Each requirement is defined with a requirement level, in accordance with the requirement levels defined in Section 2.1.
セキュリティ要件はセクション5に示されています。各要件は、セクション2.1で定義された要件レベルに従って、要件レベルで定義されています。
The requirement levels in this document are affected by the following factors:
このドキュメントの要件レベルは、次の要因の影響を受けます。
o Impact: The possible impact of not implementing the requirement, as illustrated in the Impact column of Table 1. For example, a requirement that addresses a threat that can be implemented by an external injector is typically a 'MUST', since the threat can be implemented by all the attacker types analyzed in Section 3.1.
o 影響：表1の「影響」列に示されているように、要件を実装しないことによる影響の可能性。たとえば、外部インジェクターによって実装できる脅威に対処する要件は、脅威である可能性があるため、通常「必須」です。セクション3.1で分析されたすべての攻撃者タイプによって実装されます。
o Difficulty of the corresponding attack: The level of difficulty of the possible attacks that become possible by not implementing the requirement. The level of difficulty is reflected in the Attacker Type column of Table 1. For example, a requirement that addresses a threat that only compromises the availability of the protocol is typically no more than a 'SHOULD'.
o 対応する攻撃の難易度：要件を実装しないことで可能になる攻撃の難易度。難易度は表1の「攻撃者の種類」列に反映されています。たとえば、プロトコルの可用性を損なうだけの脅威に対処する要件は、通常「SHOULD」にすぎません。
o Practical considerations: Various practical factors that may affect the requirement. For example, if a requirement is very difficult to implement, or is applicable to very specific scenarios, these factors may reduce the requirement level.
o 実用的な考慮事項：要件に影響を与える可能性のあるさまざまな実用的な要因。たとえば、要件の実装が非常に難しい場合、または非常に特定のシナリオに適用できる場合、これらの要因によって要件レベルが低下する可能性があります。
Section 5 lists the requirements. For each requirement, there is a short explanation detailing the reason for its requirement level.
セクション5に要件を示します。各要件について、その要件レベルの理由を詳細に説明した短い説明があります。
This section defines a set of security requirements. These requirements are phrased in the form "the security mechanism MUST/SHOULD/MAY...". However, this document does not specify how these requirements can be met. While these requirements can be satisfied by defining explicit security mechanisms for time protocols, at least a subset of the requirements can be met by applying common security practices to the network or by using existing security protocols, such as [IPsec] or [MACsec]. Thus, security solutions that address these requirements are outside the scope of this document.
このセクションでは、一連のセキュリティ要件を定義します。これらの要件は、「セキュリティメカニズムは必須/必須/必須...」の形式で表現されます。ただし、このドキュメントでは、これらの要件を満たす方法を指定していません。これらの要件は時間プロトコルの明示的なセキュリティメカニズムを定義することで満たすことができますが、少なくとも一部の要件は、ネットワークに一般的なセキュリティ手法を適用するか、[IPsec]や[MACsec]などの既存のセキュリティプロトコルを使用することで満たすことができます。したがって、これらの要件に対処するセキュリティソリューションは、このドキュメントの範囲外です。
Requirement
要件
The security mechanism MUST support authentication.
セキュリティメカニズムは、認証をサポートする必要があります。
Requirement
要件
The security mechanism MUST support authorization.
セキュリティメカニズムは承認をサポートする必要があります。
Requirement Level
要件レベル
The requirements in this subsection address the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
このサブセクションの要件は、スプーフィング攻撃（セクション3.2.2）およびローグマスター攻撃（セクション3.2.4）に対応しています。
The requirement level of these requirements is 'MUST' since, in the absence of these requirements, the protocol is exposed to attacks that are easy to implement and have a high impact.
これらの要件が存在しない場合、プロトコルは実装が容易で影響が大きい攻撃にさらされるため、これらの要件の要件レベルは「必須」です。
Discussion
討論
Authentication refers to verifying the identity of the peer clock. Authorization, on the other hand, refers to verifying that the peer clock is permitted to play the role that it plays in the protocol. For example, some nodes may be permitted to be masters, while other nodes are only permitted to be slaves or TCs.
認証とは、ピアクロックのIDを確認することです。一方、認可とは、ピアクロックがプロトコルで果たす役割の実行を許可されていることを確認することを指します。たとえば、一部のノードはマスターになることを許可され、他のノードはスレーブまたはTCになることのみが許可されます。
Authentication is typically implemented by means of a cryptographic signature, allowing the verification of the identity of the sender. Authorization requires clocks to maintain a list of authorized clocks, or a "black list" of clocks that should be denied service or revoked.
認証は通常、暗号署名によって実装され、送信者のIDの検証を可能にします。承認には、承認されたクロックのリスト、またはサービスを拒否または取り消す必要があるクロックの「ブラックリスト」を維持するためのクロックが必要です。
It is noted that while the security mechanism is required to provide an authorization mechanism, the deployment of such a mechanism depends on the nature of the network. For example, a network that deploys PTP may consist of a set of identical OCs, where all clocks are equally permitted to be a master. In such a network, an authorization mechanism may not be necessary.
承認メカニズムを提供するにはセキュリティメカニズムが必要ですが、そのようなメカニズムの展開はネットワークの性質に依存することに注意してください。たとえば、PTPを展開するネットワークは、すべてのクロックがマスターとして等しく許可されている一連の同一のOCで構成されている場合があります。このようなネットワークでは、認証メカニズムは必要ない場合があります。
The following subsections describe five distinct cases of clock authentication.
次のサブセクションでは、クロック認証の5つの異なるケースについて説明します。
Requirement
要件
The security mechanism MUST support an authentication mechanism, allowing slaves to authenticate the identity of masters.
セキュリティ機構は認証機構をサポートしなければならず（MUST）、スレーブがマスターのアイデンティティを認証できるようにします。
Requirement
要件
The authentication mechanism MUST allow slaves to verify that the authenticated master is authorized to be a master.
認証メカニズムは、スレーブが認証されたマスターがマスターであることを承認されていることを検証することを許可しなければなりません。
Requirement Level
要件レベル
The requirements in this subsection address the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
このサブセクションの要件は、スプーフィング攻撃（セクション3.2.2）およびローグマスター攻撃（セクション3.2.4）に対応しています。
The requirement level of these requirements is 'MUST' since, in the absence of these requirements, the protocol is exposed to attacks that are easy to implement and have a high impact.
これらの要件が存在しない場合、プロトコルは実装が容易で影響が大きい攻撃にさらされるため、これらの要件の要件レベルは「必須」です。
Discussion
討論
Clocks authenticate masters in order to ensure the authenticity of the time source. It is important for a slave to verify the identity of the master, as well as to verify that the master is indeed authorized to be a master.
クロックは、時刻源の信頼性を保証するためにマスターを認証します。スレーブがマスターの身元を確認すること、およびマスターが実際にマスターとして承認されていることを確認することは重要です。
5.1.2. Recursive Authentication and Authorization of Masters (Chain of Trust)
5.1.2. マスターの再帰的な認証と承認（Chain of Trust）
Requirement
要件
The security mechanism MUST support recursive authentication and authorization of the master, to be used in cases where time information is conveyed through intermediate clocks.
セキュリティメカニズムは、時間情報が中間クロックを介して伝えられる場合に使用される、マスターの再帰的な認証と承認をサポートする必要があります。
Requirement Level
要件レベル
The requirement in this subsection addresses the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
このサブセクションの要件は、スプーフィング攻撃（セクション3.2.2）およびローグマスター攻撃（セクション3.2.4）に対応しています。
The requirement level of this requirement is 'MUST' since, in the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have a high impact.
この要件が存在しない場合、プロトコルは実装が簡単で影響が大きい攻撃にさらされるため、この要件の要件レベルは「必須」です。
Discussion
討論
In some cases, a slave is connected to an intermediate clock that is not the primary time source. For example, in PTP, a slave can be connected to a Boundary Clock (BC) or a Transparent Clock (TC), which in turn is connected to a grandmaster. A similar example in NTP is when a client is connected to a Stratum 2 server, which is connected to a Stratum 1 server. In both the PTP and the NTP cases, the slave authenticates the intermediate clock, and the intermediate clock authenticates the grandmaster. This recursive authentication process is referred to in [AutoKey] as proventication.
場合によっては、スレーブはプライマリタイムソースではない中間クロックに接続されます。たとえば、PTPでは、スレーブを境界クロック（BC）またはトランスペアレントクロック（TC）に接続できます。これらのクロックはグランドマスターに接続されます。 NTPでの同様の例は、クライアントがStratum 1サーバーに接続されているStratum 2サーバーに接続されている場合です。 PTPとNTPのどちらの場合でも、スレーブは中間クロックを認証し、中間クロックはグランドマスターを認証します。この再帰的な認証プロセスは、[AutoKey]で証明と呼ばれています。
Specifically in PTP, this requirement implies that if a slave receives time information through a TC, it must authenticate the TC to which it is attached, as well as authenticate the master from which it receives the time information, as per Section 5.1.1. Similarly, if a TC receives time information through an attached TC, it must authenticate the attached TC.
特にPTPでは、この要件は、スレーブがTCを介して時間情報を受信する場合、接続されているTCを認証し、セクション5.1.1に従って時間情報を受信するマスターを認証する必要があることを意味します。同様に、TCが接続されたTCを介して時間情報を受信する場合、接続されたTCを認証する必要があります。
Requirement
要件
The security mechanism MAY provide a means for a master to authenticate its slaves.
セキュリティメカニズムは、マスターがスレーブを認証する手段を提供する場合があります。
Requirement
要件
The security mechanism MAY provide a means for a master to verify that the sender of a protocol packet is authorized to send a packet of this type.
セキュリティメカニズムは、プロトコルパケットの送信者がこのタイプのパケットの送信を許可されていることをマスターが確認するための手段を提供する場合があります。
Requirement Level
要件レベル
The requirement in this subsection prevents DoS attacks against the master (Section 3.2.9).
このサブセクションの要件は、マスターに対するDoS攻撃を防止します（セクション3.2.9）。
The requirement level of this requirement is 'MAY' since:
この要件の要件レベルは、次の理由から「MAY」です。
o Its impact is low, i.e., in the absence of this requirement the protocol is only exposed to DoS.
o その影響は小さい、つまり、この要件がない場合、プロトコルはDoSにのみ公開されます。
o Practical considerations: requiring an NTP server to authenticate its clients may significantly impose on the server's performance.
o 実際の考慮事項：NTPサーバーにクライアントの認証を要求すると、サーバーのパフォーマンスが大幅に低下する可能性があります。
Note that while the requirement level of this requirement is 'MAY', the requirement in Section 5.1.1 is 'MUST'; the security mechanism must provide a means for authentication and authorization, with an emphasis on the master. Authentication and authorization of slaves are specified in this subsection as 'MAY'.
この要件の要件レベルは「MAY」ですが、セクション5.1.1の要件は「MUST」です。セキュリティメカニズムは、マスターに重点を置いた認証と承認の手段を提供する必要があります。スレーブの認証と承認は、このサブセクションでは「MAY」と指定されています。
Discussion
討論
Slaves and intermediate clocks are authenticated by masters in order to verify that they are authorized to receive timing services from the master.
スレーブと中間クロックは、マスターからタイミングサービスを受信する権限があることを確認するために、マスターによって認証されます。
Authentication of slaves prevents unauthorized clocks from receiving time services. Preventing the master from serving unauthorized clocks can help in mitigating DoS attacks against the master. Note that the authentication of slaves might put a higher load on the master than serving the unauthorized clock; hence, this requirement is 'MAY'.
スレーブの認証により、不正なクロックがタイムサービスを受信するのを防ぎます。マスターが許可されていないクロックを提供しないようにすると、マスターに対するDoS攻撃を軽減するのに役立ちます。スレーブの認証は、許可されていないクロックを提供するよりもマスターに高い負荷をかける可能性があることに注意してください。したがって、この要件は「MAY」です。
Requirement
要件
The security mechanism for PTP MAY provide a means for a master to authenticate the identity of the P2P TCs directly connected to it.
PTPのセキュリティメカニズムは、マスターが直接接続されているP2P TCのIDを認証する手段を提供する場合があります。
Requirement
要件
The security mechanism for PTP MAY provide a means for a master to verify that P2P TCs directly connected to it are authorized to be TCs.
PTPのセキュリティメカニズムは、マスターに直接接続されているP2P TCがTCとして承認されていることをマスターが確認できる手段を提供する場合があります。
Requirement Level
要件レベル
The requirement in this subsection prevents DoS attacks against the master (Section 3.2.9).
このサブセクションの要件は、マスターに対するDoS攻撃を防止します（セクション3.2.9）。
The requirement level of this requirement is 'MAY' for the same reasons specified in Section 5.1.3.
この要件の要件レベルは、セクション5.1.3で指定されたのと同じ理由で「MAY」です。
Discussion
討論
P2P TCs that are one hop from the master use the PDelay_Req and PDelay_Resp handshake to compute the link delay between the master and TC. These TCs are authenticated by the master.
マスターから1ホップのP2P TCは、PDelay_ReqおよびPDelay_Respハンドシェイクを使用して、マスターとTC間のリンク遅延を計算します。これらのTCはマスターによって認証されます。
Authentication of TCs, much like authentication of slaves, reduces unnecessary load on the master and peer TCs, by preventing the master from serving unauthorized clocks.
TCの認証は、スレーブの認証と同様に、マスターが不正なクロックを提供しないようにすることで、マスターおよびピアTCに不要な負荷を軽減します。
Requirement
要件
The security mechanism for PTP MUST support authentication of Announce messages. The authentication mechanism MUST also verify that the sender is authorized to be a master.
PTPのセキュリティメカニズムは、アナウンスメッセージの認証をサポートする必要があります。認証メカニズムは、送信者がマスターであることを承認されていることも検証する必要があります。
Requirement
要件
The security mechanism for PTP MUST support authentication and authorization of Management messages.
PTPのセキュリティメカニズムは、管理メッセージの認証と承認をサポートする必要があります。
Requirement
要件
The security mechanism MAY support authentication and authorization of Signaling messages.
セキュリティメカニズムは、シグナリングメッセージの認証と承認をサポートする場合があります。
Requirement Level
要件レベル
The requirements in this subsection address the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
このサブセクションの要件は、スプーフィング攻撃（セクション3.2.2）およびローグマスター攻撃（セクション3.2.4）に対応しています。
The requirement level of the first two requirements is 'MUST' since, in the absence of these requirements, the protocol is exposed to attacks that are easy to implement and have a high impact.
最初の2つの要件の要件レベルは「必須」です。これらの要件がない場合、プロトコルは実装が容易で影響が大きい攻撃にさらされるためです。
The requirement level of the third requirement is 'MAY' since its impact greatly depends on the application for which the Signaling messages are used.
3番目の要件の要件レベルは、その影響がシグナリングメッセージが使用されるアプリケーションに大きく依存するため、「MAY」です。
Discussion
討論
Master election is performed in PTP using the Best Master Clock Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock attributes using Announce messages, and the best master is elected based on the information gathered from all the candidates. Announce messages must be authenticated in order to prevent rogue master attacks (Section 3.2.4). Note that this subsection specifies a requirement that is not necessarily included in Sections 5.1.1 or 5.1.3, since the BMCA is initiated before clocks have been defined as masters or slaves.
マスター選定は、Best Master Clock Algorithm（BMCA）を使用してPTPで実行されます。各通常クロック（OC）は、アナウンスメッセージを使用してクロック属性をアナウンスし、すべての候補から収集された情報に基づいて最適なマスターが選出されます。アナウンスメッセージは、不正なマスター攻撃を防ぐために認証される必要があります（セクション3.2.4）。クロックがマスターまたはスレーブとして定義される前にBMCAが開始されるため、このサブセクションは、セクション5.1.1または5.1.3に必ずしも含まれていない要件を指定することに注意してください。
Management messages are used to monitor or configure PTP clocks. Malicious usage of Management messages enables various attacks, such as the rogue master attack or DoS attack.
管理メッセージは、PTPクロックを監視または設定するために使用されます。管理メッセージの悪意のある使用は、不正なマスター攻撃やDoS攻撃などのさまざまな攻撃を可能にします。
Signaling messages are used by PTP clocks to exchange information that is not strictly related to time information or to master selection, such as unicast negotiation. Authentication and authorization of Signaling messages may be required in some systems, depending on the application for which these messages are used.
シグナリングメッセージはPTPクロックで使用され、厳密には時間情報やユニキャストネゴシエーションなどのマスター選択に関連しない情報を交換します。一部のシステムでは、これらのメッセージが使用されるアプリケーションによっては、シグナリングメッセージの認証と承認が必要になる場合があります。
Requirement
要件
The security mechanism MUST protect the integrity of protocol packets.
セキュリティメカニズムは、プロトコルパケットの整合性を保護する必要があります。
Requirement Level
要件レベル
The requirement in this subsection addresses the packet manipulation attack (Section 3.2.1).
このサブセクションの要件は、パケット操作攻撃（セクション3.2.1）に対応しています。
The requirement level of this requirement is 'MUST' since, in the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have high impact.
この要件がない場合、プロトコルは実装が容易で影響が大きい攻撃にさらされるため、この要件の要件レベルは「必須」です。
Discussion
討論
While Section 5.1 refers to ensuring the identity an authorization of the source of a protocol packet, this subsection refers to ensuring that the packet arrived intact. The integrity protection mechanism ensures the authenticity and completeness of data from the data originator.
セクション5.1は、プロトコルパケットの送信元のIDと認証を確認することを指しますが、このサブセクションは、パケットがそのまま到着したことを確認することを指します。完全性保護メカニズムは、データ発信者からのデータの信頼性と完全性を保証します。
Integrity protection is typically implemented by means of an Integrity Check Value (ICV) that is included in protocol packets and is verified by the receiver.
完全性保護は、通常、プロトコルパケットに含まれ、受信者によって検証される完全性チェック値（ICV）によって実装されます。
Specifically in PTP, when protocol packets are subject to modification by TCs, the integrity protection can be enforced in one of two approaches: end-to-end or hop-by-hop.
特にPTPでは、プロトコルパケットがTCによって変更される場合、完全性保護をエンドツーエンドまたはホップバイホップの2つのアプローチのいずれかで実施できます。
Each hop that needs to modify a protocol packet:
プロトコルパケットを変更する必要がある各ホップ：
o Verifies its integrity.
o その整合性を検証します。
o Modifies the packet, i.e., modifies the correctionField. Note: TCs improve the end-to-end accuracy by updating a correctionField (Clause 6.5 in [IEEE1588]) in the PTP packet by adding the latency caused by the current TC.
o パケットを変更します。つまり、correctionFieldを変更します。注：TCは、現在のTCによって引き起こされる遅延を追加することにより、PTPパケットのcorrectionField（[IEEE1588]の条項6.5）を更新することにより、エンドツーエンドの精度を向上させます。
o Re-generates the integrity protection, e.g., re-computes a Message Authentication Code (MAC).
o 完全性保護を再生成します。たとえば、メッセージ認証コード（MAC）を再計算します。
In the hop-by-hop approach, the integrity of protocol packets is protected by induction on the path from the originator to the receiver.
ホップバイホップアプローチでは、プロトコルパケットの整合性は、発信者から受信者へのパス上の誘導によって保護されます。
This approach is simple, but allows rogue TCs to modify protocol packets.
このアプローチは単純ですが、不正なTCがプロトコルパケットを変更することを可能にします。
In this approach, the integrity protection is maintained on the path from the originator of a protocol packet to the receiver. This allows the receiver to directly validate the protocol packet without the ability of intermediate TCs to manipulate the packet.
このアプローチでは、プロトコルパケットの発信者から受信者へのパスで整合性保護が維持されます。これにより、レシーバーは、中間TCがパケットを操作することなく、プロトコルパケットを直接検証できます。
Since TCs need to modify the correctionField, a separate integrity protection mechanism is used specifically for the correctionField.
TCはcorrectionFieldを変更する必要があるので、個別の整合性保護メカニズムが特にcorrectionFieldに使用されます。
The end-to-end approach limits the TC's impact to the correctionField alone, while the rest of the protocol packet is protected on an end-to-end basis. It should be noted that this approach is more difficult to implement than the hop-by-hop approach, as it requires the correctionField to be protected separately from the other fields of the packet, possibly using different cryptographic mechanisms and keys.
エンドツーエンドのアプローチでは、TCの影響を修正フィールドのみに制限し、残りのプロトコルパケットはエンドツーエンドで保護します。このアプローチは、ホップバイホップアプローチよりも実装が難しいことに注意してください。これは、おそらく別の暗号化メカニズムとキーを使用して、パケットのその他のフィールドとは別にCorrectionFieldを保護する必要があるためです。
Requirement
要件
The security mechanism MUST provide a means to prevent master spoofing.
セキュリティメカニズムは、マスタースプーフィングを防止する手段を提供する必要があります。
Requirement
要件
The security mechanism MUST provide a means to prevent slave spoofing.
セキュリティメカニズムは、スレーブスプーフィングを防止する手段を提供する必要があります。
Requirement
要件
PTP: The security mechanism MUST provide a means to prevent P2P TC spoofing.
PTP：セキュリティメカニズムは、P2P TCスプーフィングを防止する手段を提供する必要があります。
Requirement Level
要件レベル
The requirements in this subsection address spoofing attacks. As described in Section 3.2.2, when these requirements are not met, the attack may have a high impact, causing slaves to rely on false time information. Thus, the requirement level is 'MUST'.
このサブセクションの要件は、なりすまし攻撃に対処します。セクション3.2.2で説明されているように、これらの要件が満たされていない場合、攻撃が大きな影響を及ぼし、スレーブが誤った時間情報に依存する可能性があります。したがって、要件レベルは「必須」です。
Discussion
討論
Spoofing attacks may take various forms, and they can potentially cause significant impact. In a master spoofing attack, the attacker causes slaves to receive false information about the current time by masquerading as the master.
なりすまし攻撃にはさまざまな形態があり、重大な影響を与える可能性があります。マスタースプーフィング攻撃では、攻撃者はスレーブに、マスターになりすまして現在の時刻に関する誤った情報を受信させます。
By spoofing a slave or an intermediate node (the second example of Section 3.2.2), an attacker can tamper with the slaves' delay computations. These attacks can be mitigated by an authentication mechanism (Sections 5.1.3 and 5.1.4) or by other means, for example, a PTP Delay_Req can include a MAC that is included in the corresponding Delay_Resp message, allowing the slave to verify that the Delay_Resp was not sent in response to a spoofed message.
スレーブまたは中間ノードをスプーフィングすることで（セクション3.2.2の2番目の例）、攻撃者はスレーブの遅延計算を改ざんできます。これらの攻撃は、認証メカニズム（セクション5.1.3および5.1.4）または他の手段によって軽減できます。たとえば、PTP Delay_Reqには、対応するDelay_Respメッセージに含まれるMACを含めることができ、スレーブがDelay_Respは、スプーフィングされたメッセージへの応答として送信されませんでした。
Requirement
要件
The security mechanism SHOULD include measures to mitigate DoS attacks against the time protocol.
セキュリティメカニズムには、時間プロトコルに対するDoS攻撃を軽減するための対策を含める必要があります（SHOULD）。
Requirement Level
要件レベル
The requirement in this subsection prevents DoS attacks against the protocol (Section 3.2.9).
このサブセクションの要件は、プロトコルに対するDoS攻撃を防止します（セクション3.2.9）。
The requirement level of this requirement is 'SHOULD' due to its low impact, i.e., in the absence of this requirement the protocol is only exposed to DoS.
この要件の要件レベルは影響が小さいため、「SHOULD」です。つまり、この要件がない場合、プロトコルはDoSにのみ公開されます。
Discussion
討論
The protocol availability can be compromised by several different attacks. An attacker can inject protocol packets to implement the spoofing attack (Section 3.2.2) or the rogue master attack (Section 3.2.4), causing DoS to the victim (Section 3.2.9).
プロトコルの可用性は、いくつかの異なる攻撃によって損なわれる可能性があります。攻撃者はプロトコルパケットを注入して、スプーフィング攻撃（セクション3.2.2）またはローグマスター攻撃（セクション3.2.4）を実装し、被害者にDoSを引き起こします（セクション3.2.9）。
An authentication mechanism (Section 5.1) limits these attacks strictly to internal attackers; thus, it prevents external attackers from performing them. Hence, the requirements of Section 5.1 can be used to mitigate this attack. Note that Section 5.1 addresses a wider range of threats, whereas the current section is focused on availability.
認証メカニズム（セクション5.1）は、これらの攻撃を内部の攻撃者に厳しく制限します。したがって、外部の攻撃者がそれらを実行するのを防ぎます。したがって、セクション5.1の要件を使用して、この攻撃を緩和できます。現在のセクションは可用性に焦点を当てているのに対し、セクション5.1はより広範な脅威に対処していることに注意してください。
The DoS attacks described in Section 3.2.7 are performed at lower layers than the time protocol layer, and they are thus outside the scope of the security requirements defined in this document.
セクション3.2.7で説明されているDoS攻撃は、タイムプロトコルレイヤーよりも低いレイヤーで実行されるため、このドキュメントで定義されているセキュリティ要件の範囲外です。
Requirement
要件
The security mechanism MUST include a replay prevention mechanism.
セキュリティメカニズムには、リプレイ防止メカニズムを含める必要があります。
Requirement Level
要件レベル
The requirement in this subsection prevents replay attacks (Section 3.2.3).
このサブセクションの要件は、リプレイ攻撃を防止します（セクション3.2.3）。
The requirement level of this requirement is 'MUST' since, in the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have a high impact.
この要件が存在しない場合、プロトコルは実装が簡単で影響が大きい攻撃にさらされるため、この要件の要件レベルは「必須」です。
Discussion
討論
The replay attack (Section 3.2.3) can compromise both the integrity and availability of the protocol. Common encryption and authentication mechanisms include replay prevention mechanisms that typically use a monotonously increasing packet sequence number.
リプレイ攻撃（セクション3.2.3）は、プロトコルの整合性と可用性の両方を危険にさらす可能性があります。一般的な暗号化および認証メカニズムには、通常単調に増加するパケットシーケンス番号を使用するリプレイ防止メカニズムが含まれます。
Requirement
要件
The security mechanism MUST provide a means to refresh the cryptographic keys.
セキュリティメカニズムは、暗号化キーを更新する手段を提供する必要があります。
The cryptographic keys MUST be refreshed frequently.
暗号化キーは頻繁に更新する必要があります。
Requirement Level
要件レベル
The requirement level of this requirement is 'MUST' since key freshness is an essential property for cryptographic algorithms, as discussed below.
以下で説明するように、キーの鮮度は暗号アルゴリズムの必須プロパティであるため、この要件の要件レベルは「必須」です。
Discussion
討論
Key freshness guarantees that both sides share a common updated secret key. It also helps in preventing replay attacks. Thus, it is important for keys to be refreshed frequently. Note that the term 'frequently' is used without a quantitative requirement, as the precise frequency requirement should be considered on a per-system basis, based on the threats and system requirements.
鍵の鮮度は、双方が更新された共通の秘密鍵を共有することを保証します。また、リプレイ攻撃の防止にも役立ちます。したがって、キーを頻繁に更新することが重要です。正確な頻度要件は、脅威とシステム要件に基づいてシステムごとに考慮する必要があるため、「頻繁に」という用語は定量的要件なしで使用されることに注意してください。
Requirement
要件
The security protocol SHOULD support a security association protocol where:
セキュリティプロトコルは、セキュリティアソシエーションプロトコルをサポートする必要があります（SHOULD）。
o Two or more clocks authenticate each other.
o 2つ以上のクロックが相互に認証します。
o The clocks generate and agree on a cryptographic session key.
o クロックは、暗号化セッションキーを生成して同意します。
Requirement
要件
Each instance of the association protocol SHOULD produce a different session key.
アソシエーションプロトコルの各インスタンスは、異なるセッションキーを生成する必要があります（SHOULD）。
Requirement Level
要件レベル
The requirement level of this requirement is 'SHOULD' since it may be expensive in terms of performance, especially in low-cost clocks.
この要件の要件レベルは、パフォーマンスの点で、特に低コストのクロックでは高価になる可能性があるため、「SHOULD」です。
Discussion
討論
The security requirements in Sections 5.1 and 5.2 require usage of cryptographic mechanisms, deploying cryptographic keys. A security association (e.g., [IPsec]) is an important building block in these mechanisms.
セクション5.1および5.2のセキュリティ要件では、暗号化メカニズムを使用し、暗号化キーを展開する必要があります。セキュリティアソシエーション（[IPsec]など）は、これらのメカニズムの重要な構成要素です。
It should be noted that in some cases, different security association mechanisms may be used at different levels of clock hierarchies. For example, the association between a Stratum 2 clock and a Stratum 3 clock in NTP may have different characteristics than an association between two clocks at the same stratum level. On a related note, in some cases, a hybrid solution may be used, where a subset of the network is not secured at all (see Section 5.10.2).
場合によっては、クロック階層の異なるレベルで異なるセキュリティアソシエーションメカニズムが使用される場合があることに注意してください。たとえば、NTPのStratum 2クロックとStratum 3クロック間の関連付けには、同じ階層レベルの2つのクロック間の関連付けとは異なる特性がある場合があります。関連する注記として、場合によっては、ネットワークのサブセットがまったく保護されていないハイブリッドソリューションが使用されることがあります（セクション5.10.2を参照）。
Requirement
要件
The security mechanism SHOULD support security association protocols for unicast and for multicast associations.
セキュリティメカニズムは、ユニキャストおよびマルチキャストアソシエーションのセキュリティアソシエーションプロトコルをサポートする必要があります（SHOULD）。
Requirement Level
要件レベル
The requirement level of this requirement is 'SHOULD' since it may be expensive in terms of performance, especially for low-cost clocks.
この要件の要件レベルは、特に低コストのクロックの場合、パフォーマンスの点で高価になる可能性があるため、「SHOULD」です。
Discussion
討論
A unicast protocol requires an association protocol between two clocks, whereas a multicast protocol requires an association protocol among two or more clocks, where one of the clocks is a master.
ユニキャストプロトコルは2つのクロック間のアソシエーションプロトコルを必要としますが、マルチキャストプロトコルは2つ以上のクロック間のアソシエーションプロトコルを必要とし、クロックの1つはマスターです。
Requirement
要件
The security mechanism MUST be designed in such a way that it does not significantly degrade the quality of the time transfer.
セキュリティメカニズムは、時間転送の品質を大幅に低下させないように設計する必要があります。
Requirement
要件
The mechanism SHOULD minimize computational load.
このメカニズムは、計算負荷を最小化する必要があります（SHOULD）。
Requirement
要件
The mechanism SHOULD minimize storage requirements of client state in the master.
このメカニズムは、マスターでのクライアント状態のストレージ要件を最小化する必要があります（SHOULD）。
Requirement
要件
The mechanism SHOULD minimize the bandwidth overhead required by the security protocol.
このメカニズムは、セキュリティプロトコルが必要とする帯域幅のオーバーヘッドを最小限に抑える必要があります（SHOULD）。
Requirement Level
要件レベル
While the quality of the time transfer is clearly a 'MUST', the other three performance requirements are 'SHOULD', since some systems may be more sensitive to resource consumption than others; hence, these requirements should be considered on a per-system basis.
時間転送の品質は明らかに「必須」ですが、他の3つのパフォーマンス要件は「SHOULD」です。これは、一部のシステムは他のシステムよりもリソース消費に敏感な場合があるためです。したがって、これらの要件はシステムごとに考慮する必要があります。
Discussion
討論
Performance efficiency is important since client restrictions often dictate a low processing and memory footprint and because the server may have extensive fan-out.
多くの場合、クライアントの制限によって処理とメモリのフットプリントが低くなるため、サーバーのファンアウトが広範囲になる可能性があるため、パフォーマンス効率は重要です。
Note that the performance requirements refer to a time-protocol-specific security mechanism. In systems where a security protocol is used for other types of traffic as well, this document does not place any performance requirements on the security protocol performance. For example, if IPsec encryption is used for securing all information between the master and slave node, including information that is not part of the time protocol, the requirements in this subsection are not necessarily applicable.
パフォーマンス要件は、時間プロトコル固有のセキュリティメカニズムを指すことに注意してください。セキュリティプロトコルが他のタイプのトラフィックにも使用されるシステムでは、このドキュメントはセキュリティプロトコルのパフォーマンスにパフォーマンス要件を課しません。たとえば、IPsec暗号化を使用して、マスターとスレーブノード間のすべての情報（タイムプロトコルの一部ではない情報を含む）を保護する場合、このサブセクションの要件は必ずしも適用されません。
Requirement
要件
The security mechanism MAY provide confidentiality protection of the protocol packets.
セキュリティメカニズムは、プロトコルパケットの機密保護を提供するかもしれません。
Requirement Level
要件レベル
The requirement level of this requirement is 'MAY' since the absence of this requirement does not expose the protocol to severe threats, as discussed below.
以下で説明するように、この要件がなくてもプロトコルが深刻な脅威にさらされることはないため、この要件の要件レベルは「MAY」です。
Discussion
討論
In the context of time protocols, confidentiality is typically of low importance, since timing information is usually not considered secret information.
時間プロトコルのコンテキストでは、タイミング情報は通常秘密情報と見なされないため、機密性は通常重要度が低いです。
Confidentiality can play an important role when service providers charge their customers for time synchronization services; thus, an encryption mechanism can prevent eavesdroppers from obtaining the service without payment. Note that these cases are, for now, rather esoteric.
サービスプロバイダーが顧客に時間同期サービスの料金を請求する場合、機密性は重要な役割を果たす可能性があります。したがって、暗号化メカニズムは、盗聴者が支払いなしでサービスを取得することを防ぐことができます。現在のところ、これらのケースはかなり難解であることに注意してください。
Confidentiality can also prevent an MITM attacker from identifying protocol packets. Thus, confidentiality can assist in protecting the timing protocol against MITM attacks such as packet delay (Section 3.2.6), manipulation and interception, and removal attacks. Note that time protocols have predictable behavior even after encryption, such as packet transmission rates and packet lengths. Additional measures can be taken to mitigate encrypted traffic analysis by random padding of encrypted packets and by adding random dummy packets. Nevertheless, encryption does not prevent such MITM attacks, but rather makes these attacks more difficult to implement.
機密性により、MITM攻撃者がプロトコルパケットを識別することもできなくなります。したがって、機密性は、パケット遅延（セクション3.2.6）、操作と傍受、および削除攻撃などのMITM攻撃からタイミングプロトコルを保護するのに役立ちます。タイムプロトコルは、パケット転送レートやパケット長など、暗号化後でも予測可能な動作をすることに注意してください。暗号化されたパケットのランダムパディングとランダムなダミーパケットの追加により、暗号化されたトラフィック分析を軽減するための追加の対策を講じることができます。それにもかかわらず、暗号化はそのようなMITM攻撃を防止しませんが、むしろこれらの攻撃の実装をより困難にします。
Requirement
要件
The security mechanism MUST include means to protect the protocol from MITM attacks that degrade the clock accuracy.
セキュリティメカニズムには、クロックの精度を低下させるMITM攻撃からプロトコルを保護する手段を含める必要があります。
Requirement Level
要件レベル
The requirements in this subsection address MITM attacks such as the packet delay attack (Section 3.2.6) and packet interception attacks (Sections 3.2.5 and 3.2.1).
このサブセクションの要件は、パケット遅延攻撃（セクション3.2.6）やパケット傍受攻撃（セクション3.2.5および3.2.1）などのMITM攻撃に対応しています。
The requirement level of this requirement is 'MUST'. In the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have a high impact. Note that in the absence of this requirement, the impact is similar to packet manipulation attacks (Section 3.2.1); thus, this requirement has the same requirement level as integrity protection (Section 5.2).
この要件の要件レベルは「必須」です。この要件がない場合、プロトコルは実装が簡単で影響が大きい攻撃にさらされます。この要件がない場合、影響はパケット操作攻撃（セクション3.2.1）に似ていることに注意してください。したがって、この要件は、整合性保護（セクション5.2）と同じ要件レベルを持っています。
It is noted that the implementation of this requirement depends on the topology and properties of the system.
この要件の実装は、システムのトポロジとプロパティに依存することに注意してください。
Discussion
討論
While this document does not define specific security solutions, we note that common practices for protection against MITM attacks use redundant masters (e.g., [NTPv4]) or redundant paths between the master and slave (e.g., [DelayAtt]). If one of the time sources indicates a time value that is significantly different than the other sources, it is assumed to be erroneous or under attack and is therefore ignored.
このドキュメントでは特定のセキュリティソリューションを定義していませんが、MITM攻撃に対する保護の一般的な慣行では、冗長マスター（[NTPv4]など）またはマスターとスレーブ間の冗長パス（[DelayAtt]など）を使用することに注意してください。タイムソースの1つが他のソースと大幅に異なる時間値を示している場合、エラーであるか攻撃されていると見なされ、無視されます。
Thus, MITM attack prevention derives a requirement from the security mechanism and a requirement from the network topology. While the security mechanism should support the ability to detect delay attacks, it is noted that in some networks it is not possible to provide the redundancy needed for such a detection mechanism.
したがって、MITM攻撃防止は、セキュリティメカニズムからの要件とネットワークトポロジからの要件を導き出します。セキュリティメカニズムは遅延攻撃を検出する機能をサポートする必要がありますが、一部のネットワークでは、そのような検出メカニズムに必要な冗長性を提供することができないことに注意してください。
Integrating a security mechanism into a time-synchronized system is a complex and expensive process, and hence in some cases may require incremental deployment, where new equipment supports the security mechanism, and is required to interoperate with legacy equipment without the security features.
セキュリティメカニズムを時刻同期システムに統合することは複雑で費用のかかるプロセスであるため、場合によっては、新しい機器がセキュリティメカニズムをサポートし、セキュリティ機能なしでレガシー機器と相互運用するために段階的に導入する必要があります。
Requirement
要件
The security mechanism MUST support a secure mode, where only secured clocks are permitted to take part in the time protocol. In this mode every protocol packet received from an unsecured clock MUST be discarded.
セキュリティ機構は、セキュアモードをサポートする必要があります。セキュアモードでは、タイムプロトコルへの参加が許可されています。このモードでは、保護されていないクロックから受信したすべてのプロトコルパケットを破棄する必要があります。
Requirement Level
要件レベル
The requirement level of this requirement is 'MUST' since the full capacity of the security requirements defined in this document can only be achieved in secure mode.
このドキュメントで定義されているセキュリティ要件の全容量はセキュアモードでのみ達成できるため、この要件の要件レベルは「必須」です。
Discussion
討論
While the requirement in this subsection is similar to the one in Section 5.1, it refers to the secure mode, as opposed to the hybrid mode presented in the next subsection.
このサブセクションの要件はセクション5.1の要件と同様ですが、次のサブセクションで提示するハイブリッドモードとは対照的に、セキュアモードを指します。
Requirement
要件
The security protocol SHOULD support a hybrid mode, where both secured and unsecured clocks are permitted to take part in the protocol.
セキュリティプロトコルは、セキュアモードと非セキュアクロックの両方がプロトコルに参加することが許可されるハイブリッドモードをサポートする必要があります（SHOULD）。
Requirement Level
要件レベル
The requirement level of this requirement is 'SHOULD'; on one hand, hybrid mode enables a gradual transition from unsecured to secured mode, which is especially important in large-scaled deployments. On the other hand, hybrid mode is not required in all systems; this document recommends deployment of the 'secure mode' described in Section 5.10.1, where possible.
この要件の要件レベルは「SHOULD」です。一方、ハイブリッドモードでは、非セキュアモードからセキュアモードに段階的に移行できます。これは、大規模な展開で特に重要です。一方、ハイブリッドモードはすべてのシステムで必要なわけではありません。このドキュメントでは、可能な場合、セクション5.10.1で説明されている「セキュアモード」の配備を推奨しています。
Discussion
討論
The hybrid mode allows both secured and unsecured clocks to take part in the time protocol. NTP, for example, allows a mixture of secured and unsecured nodes.
ハイブリッドモードでは、保護されたクロックと保護されていないクロックの両方が時間プロトコルに参加できます。たとえば、NTPでは、保護されたノードと保護されていないノードを混在させることができます。
Requirement
要件
A master in the hybrid mode SHOULD be a secured clock.
ハイブリッドモードのマスターは、セキュリティで保護されたクロックである必要があります。
A secured slave in the hybrid mode SHOULD discard all protocol packets received from unsecured clocks.
ハイブリッドモードのセキュアスレーブは、非セキュアクロックから受信したすべてのプロトコルパケットを破棄する必要があります（SHOULD）。
Requirement Level
要件レベル
The requirement level of this requirement is 'SHOULD' since it may not be applicable to all deployments. For example, a hybrid network may require the usage of unsecured masters or TCs.
この要件の要件レベルは、すべての展開に適用できるわけではないため、「SHOULD」です。たとえば、ハイブリッドネットワークでは、セキュリティで保護されていないマスターまたはTCの使用が必要になる場合があります。
Discussion
討論
This requirement ensures that the existence of unsecured clocks does not compromise the security provided to secured clocks. Hence, secured slaves only "trust" protocol packets received from a secured clock.
この要件により、セキュリティで保護されていないクロックが存在しても、セキュリティで保護されたクロックに提供されるセキュリティが損なわれないことが保証されます。したがって、保護されたスレーブは、保護されたクロックから受信したプロトコルパケットのみを「信頼」します。
An unsecured slave can receive protocol packets from either unsecured clocks or secured clocks. Note that the latter does not apply when encryption is used. When integrity protection is used, the unsecured slave can receive secured packets ignoring the integrity protection.
安全でないスレーブは、安全でないクロックまたは安全なクロックからプロトコルパケットを受信できます。暗号化が使用されている場合、後者は適用されないことに注意してください。完全性保護が使用されている場合、安全でないスレーブは、完全性保護を無視して安全なパケットを受信できます。
Note that the security scheme in [NTPv4] with [AutoKey] does not satisfy this requirement, since nodes prefer the server with the most accurate clock, which is not necessarily the server that supports authentication. For example, a Stratum 2 server is connected to two Stratum 1 servers: Server A, supporting authentication, and Server B, without authentication. If Server B has a more accurate clock than A, the Stratum 2 server chooses Server B, in spite of the fact it does not support authentication.
[AutoKey]を使用した[NTPv4]のセキュリティスキームはこの要件を満たさないことに注意してください。ノードは最も正確なクロックを持つサーバーを優先しますが、これは認証をサポートするサーバーとは限りません。たとえば、Stratum 2サーバーは、認証をサポートするサーバーAと認証なしのサーバーBの2つのStratum 1サーバーに接続されています。サーバーBのクロックがAより正確な場合、Stratum 2サーバーは認証をサポートしていないにもかかわらず、サーバーBを選択します。
+-----------+---------------------------------------------+--------+
| Section | Requirement | Type |
+-----------+---------------------------------------------+--------+
| 5.1 | Authentication & authorization of sender | MUST |
| +---------------------------------------------+--------+
| | Authentication & authorization of master | MUST |
| +---------------------------------------------+--------+
| | Recursive authentication & authorization | MUST |
| +---------------------------------------------+--------+
| | Authentication & authorization of slaves | MAY |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY |
| | P2P TCs by master | |
+-----------+---------------------------------------------+--------+
+-----------+---------------------------------------------+--------+
|5.1 (cont) | PTP: Authentication & authorization of | MUST |
| | Announce messages | |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MUST |
| | Management messages | |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY |
| | Signaling messages | |
+-----------+---------------------------------------------+--------+
| 5.2 | Integrity protection | MUST |
+-----------+---------------------------------------------+--------+
| 5.3 | Spoofing prevention | MUST |
+-----------+---------------------------------------------+--------+
| 5.4 | Protection from DoS attacks against the | SHOULD |
| | time protocol | |
+-----------+---------------------------------------------+--------+
| 5.5 | Replay protection | MUST |
+-----------+---------------------------------------------+--------+
| 5.6 | Key freshness | MUST |
| +---------------------------------------------+--------+
| | Security association | SHOULD |
| +---------------------------------------------+--------+
| | Unicast and multicast associations | SHOULD |
+-----------+---------------------------------------------+--------+
| 5.7 | Performance: no degradation in quality of | MUST |
| | time transfer | |
| +---------------------------------------------+--------+
| | Performance: computation load | SHOULD |
| +---------------------------------------------+--------+
| | Performance: storage | SHOULD |
| +---------------------------------------------+--------+
| | Performance: bandwidth | SHOULD |
+-----------+---------------------------------------------+--------+
| 5.8 | Confidentiality protection | MAY |
+-----------+---------------------------------------------+--------+
| 5.9 | Protection against delay and interception | MUST |
| | attacks | |
+-----------+---------------------------------------------+--------+
| 5.10 | Secure mode | MUST |
| +---------------------------------------------+--------+
| | Hybrid mode | SHOULD |
+-----------+---------------------------------------------+--------+
Table 2: Summary of Security Requirements
表2：セキュリティ要件の概要
This section discusses additional implications of the interaction between time protocols and security mechanisms.
このセクションでは、時間プロトコルとセキュリティメカニズム間の相互作用のその他の影響について説明します。
This section refers to time protocol security mechanisms, as well as to "external" security mechanisms, i.e., security mechanisms that are not strictly related to the time protocol.
このセクションでは、タイムプロトコルのセキュリティメカニズム、および「外部」セキュリティメカニズム、つまりタイムプロトコルに厳密には関連していないセキュリティメカニズムについて説明します。
Time protocols often require that protocol packets be modified during transmission. Both NTP and PTP in one-step mode require clocks to modify protocol packets based on the time of transmission and/or reception.
時間プロトコルでは、多くの場合、送信中にプロトコルパケットを変更する必要があります。ワンステップモードのNTPとPTPはどちらも、送受信の時間に基づいてプロトコルパケットを変更するためにクロックを必要とします。
In the presence of a security mechanism, whether encryption or integrity protection:
暗号化か完全性保護かにかかわらず、セキュリティメカニズムが存在する場合：
o During transmission the encryption and/or integrity protection MUST be applied after integrating the timestamp into the packet.
o 送信中、タイムスタンプをパケットに統合した後、暗号化および/または完全性保護を適用する必要があります。
To allow high accuracy, timestamping is typically performed as close to the transmission or reception time as possible. However, since the security engine must be placed between the timestamping function and the physical interface, it may introduce non-deterministic latency that causes accuracy degradation. These performance aspects have been analyzed in literature, e.g., [1588IPsec] and [Tunnel].
高い精度を可能にするために、タイムスタンプは通常、送信または受信時刻に可能な限り近く実行されます。ただし、セキュリティエンジンはタイムスタンプ機能と物理インターフェイスの間に配置する必要があるため、非決定的なレイテンシが発生し、精度が低下する可能性があります。これらのパフォーマンスの側面は、[1588IPsec]や[Tunnel]などの文献で分析されています。
PTP supports a two-step mode of operation, where the time of transmission of protocol packets is communicated without modifying the packets. As opposed to one-step mode, two-step timestamping can be performed without the requirement to encrypt after timestamping.
PTPは2段階の動作モードをサポートしており、プロトコルパケットの送信時間がパケットを変更せずに通信されます。ワンステップモードとは異なり、タイムスタンプ後に暗号化する必要なく、2ステップのタイムスタンプを実行できます。
Note that if an encryption mechanism such as IPsec is used, it presents a challenge to the timestamping mechanism, since time protocol packets are encrypted when traversing the physical interface, and are thus impossible to identify. A possible solution to this problem [IPsecSync] is to include an indication in the encryption header that identifies time protocol packets.
IPsecなどの暗号化メカニズムが使用されている場合、タイムプロトコルパケットは物理インターフェイスを通過するときに暗号化され、識別できないため、タイムスタンプメカニズムに問題が生じることに注意してください。この問題[IPsecSync]の可能な解決策は、時間プロトコルパケットを識別する表示を暗号化ヘッダーに含めることです。
A time protocol allows slaves to receive time information from an accurate time source. Time information is sent over a path that often traverses one or more intermediate clocks.
時間プロトコルにより、スレーブは正確な時間ソースから時間情報を受信できます。時間情報は、1つ以上の中間クロックを通過することが多いパスを介して送信されます。
o In NTP, time information originated from a Stratum 1 server can be distributed to Stratum 2 servers and, in turn, distributed from the Stratum 2 servers to NTP clients. In this case, the Stratum 2 servers are a layer of intermediate clocks. These intermediate clocks are referred to as "secondary servers" in [NTPv4].
o NTPでは、Stratum 1サーバーから発信された時刻情報をStratum 2サーバーに配信し、Stratum 2サーバーからNTPクライアントに配信できます。この場合、Stratum 2サーバーは中間クロックのレイヤーです。これらの中間クロックは、[NTPv4]では「セカンダリサーバー」と呼ばれます。
o In PTP, BCs and TCs are intermediate nodes used to improve the accuracy of time information conveyed between the grandmaster and the slaves.
o PTPでは、BCとTCは中間ノードであり、グランドマスターとスレーブ間で伝達される時間情報の精度を向上させるために使用されます。
A common rule of thumb in network security is that end-to-end security is the best policy, as it secures the entire path between the data originator and its receiver. The usage of intermediate nodes implies that if a security mechanism is deployed in the network, a hop-by-hop security scheme must be used, since intermediate nodes must be able to send time information to the slaves, or to modify time information sent through them.
ネットワークセキュリティの一般的な経験則は、エンドツーエンドセキュリティがデータ発信者と受信者の間のパス全体を保護するため、最良のポリシーであるということです。中間ノードの使用は、セキュリティメカニズムがネットワークに展開されている場合、ホップバイホップセキュリティスキームを使用する必要があることを意味します。中間ノードは、スレーブに時間情報を送信したり、送信された時間情報を変更したりできる必要があるためですそれら。
This inherent property of using intermediate clocks increases the system's exposure to internal threats, as a large number of nodes possess the security keys.
多数のノードがセキュリティキーを所有しているため、中間クロックを使用するこの固有の特性により、システムが内部の脅威にさらされる可能性が高くなります。
Thus, there is a trade-off between the achievable clock accuracy of a system, and the robustness of its security solution. On one hand, high clock accuracy calls for hop-by-hop involvement in the protocol, also known as on-path support. On the other hand, a robust security solution calls for end-to-end data protection.
したがって、システムの達成可能なクロック精度とセキュリティソリューションの堅牢性の間にはトレードオフがあります。一方、高いクロック精度は、プロトコルへのホップバイホップの関与を必要とします。これは、オンパスサポートとも呼ばれます。一方、堅牢なセキュリティソリューションには、エンドツーエンドのデータ保護が必要です。
Time protocols are often deployed in systems that use security mechanisms and protocols.
時間プロトコルは、セキュリティメカニズムとプロトコルを使用するシステムに配備されることがよくあります。
A typical example is the 3GPP Femtocell network [3GPP], where IPsec is used for securing traffic between a Femtocell and the Femto Gateway. In some cases, all traffic between these two nodes may be secured by IPsec, including the time protocol traffic. This use-case is thoroughly discussed in [IPsecSync].
典型的な例は3GPPフェムトセルネットワーク[3GPP]で、IPsecはフェムトセルとフェムトゲートウェイ間のトラフィックを保護するために使用されます。場合によっては、これら2つのノード間のすべてのトラフィックが、タイムプロトコルトラフィックを含め、IPsecによって保護されることがあります。この使用例は、[IPsecSync]で徹底的に議論されています。
Another typical example is the usage of MACsec encryption ([MACsec]) in L2 networks that deploy time synchronization [AvbAssum].
別の典型的な例は、時間同期[AvbAssum]を展開するL2ネットワークでのMACsec暗号化（[MACsec]）の使用です。
The usage of external security mechanisms may affect time protocols as follows:
外部セキュリティメカニズムの使用は、次のようにタイムプロトコルに影響を与える可能性があります。
o Timestamping accuracy can be affected, as described in Section 7.1.
o セクション7.1で説明されているように、タイムスタンプの精度が影響を受ける可能性があります。
o If traffic is secured between two nodes in the network, no intermediate clocks can be used between these two nodes. In the [3GPP] example, if traffic between the Femtocell and the Femto Gateway is encrypted, then time protocol packets are necessarily transported over the underlying network without modification and, thus, cannot enjoy the improved accuracy provided by intermediate clock nodes.
o ネットワーク内の2つのノード間でトラフィックが保護されている場合、これらの2つのノード間で中間クロックを使用することはできません。 [3GPP]の例では、フェムトセルとフェムトゲートウェイの間のトラフィックが暗号化されている場合、タイムプロトコルパケットは変更せずに基盤のネットワークを介して必ず転送されるため、中間クロックノードによって提供される改善された精度を享受できません。
Cryptographic protocols often use time as an important factor in the cryptographic algorithm. If a time protocol is compromised, it may consequently expose the security protocols that rely on it to various attacks. Two examples are presented in this section.
暗号化プロトコルは、多くの場合、暗号化アルゴリズムの重要な要素として時間を使用します。タイムプロトコルが危険にさらされると、それに依存するセキュリティプロトコルがさまざまな攻撃にさらされる可能性があります。このセクションでは、2つの例を示します。
Certificate validation requires the sender and receiver to be roughly time synchronized. Thus, synchronization is required for establishing security protocols such as Internet Key Exchange Protocol version 2 (IKEv2) and Transport Layer Security (TLS). Other authentication and key exchange mechanisms, such as Kerberos, also require the parties involved to be synchronized [Kerb].
証明書の検証では、送信者と受信者がおおまかに時間を同期する必要があります。したがって、インターネットキー交換プロトコルバージョン2（IKEv2）やトランスポート層セキュリティ（TLS）などのセキュリティプロトコルを確立するには同期が必要です。 Kerberosなどの他の認証および鍵交換メカニズムでも、関係者を同期する必要があります[Kerb]。
An even stronger interdependence between a time protocol and a security mechanism is defined in [AutoKey], which defines mutual dependence between the acquired time information, and the authentication protocol that secures it. This bootstrapping behavior results from the fact that trusting the received time information requires a valid certificate, and validating a certificate requires knowledge of the time.
タイムプロトコルとセキュリティメカニズムの間のさらに強い相互依存は、[AutoKey]で定義されています。[AutoKey]は、取得した時間情報とそれを保護する認証プロトコルの間の相互依存を定義します。このブートストラップ動作は、受信した時刻情報を信頼するには有効な証明書が必要であり、証明書の検証には時刻の知識が必要であるという事実が原因です。
A successful attack on a time protocol may cause the attacked clocks to go back in time. The erroneous time may expose cryptographic algorithms that rely on time, as a node may use a key that was already used in the past and has expired.
時間プロトコルに対する攻撃が成功すると、攻撃されたクロックが時間を遡る可能性があります。ノードは過去にすでに使用されていて期限が切れているキーを使用する可能性があるため、誤った時間は時間に依存する暗号アルゴリズムを公開する可能性があります。
The Key distribution is outside the scope of this document. Although this is an essential element of any security system, it is outside the scope of this document.
キーの配布はこのドキュメントの範囲外です。これはセキュリティシステムの重要な要素ですが、このドキュメントの範囲外です。
The security considerations of network timing protocols are presented throughout this document.
ネットワークタイミングプロトコルのセキュリティに関する考慮事項は、このドキュメント全体に記載されています。
[IEEE1588] IEEE, "1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588-2008, July 2008.
[IEEE1588] IEEE、「1588-2008-ネットワーク化された測定および制御システム用の高精度クロック同期プロトコルのIEEE標準」、IEEE標準1588-2008、2008年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[NTPv4] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[NTPv4] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月、<http：// www.rfc-editor.org/info/rfc5905>。
[1588IPsec] Treytl, A. and B. Hirschler, "Securing IEEE 1588 by IPsec tunnels - An analysis", in Proceedings of 2010 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2010, pp. 83-90, September 2010.
[1588IPsec] Treytl、A。およびB. Hirschler、「IPsecトンネルによるIEEE 1588の保護-分析」、測定、制御、通信のための2010年国際時計シンポジウム、ISPCS 2010、pp。83-90のプロシーディングス2010年9月。
[3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 11.6.0, November 2012.
[3GPP] 3GPP、「ホームノードB（HNB）のセキュリティ/ホーム進化型ノードB（HeNB）」、3GPP TS 33.320 11.6.0、2012年11月。
[Anatomy] Nachreiner, C., "Anatomy of an ARP Poisoning Attack", 2003.
[解剖学] Nachreiner、C。、「ARP中毒攻撃の解剖学」、2003年。
[AutoKey] Haberman, B., Ed., and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010, <http://www.rfc-editor.org/info/rfc5906>.
[AutoKey] Haberman、B.、Ed。、およびD. Mills、「Network Time Protocol Version 4：Autokey Specification」、RFC 5906、2010年6月、<http://www.rfc-editor.org/info/rfc5906> 。
[AvbAssum] Pannell, D., "Audio Video Bridging Gen 2 Assumptions", IEEE 802.1 AVB Plenary, Work in Progress, May 2012.
[AvbAssum] Pannell、D。、「Audio Video Bridging Gen 2 Assumptions」、IEEE 802.1 AVB Plenary、Work in Progress、2012年5月。
[DelayAtt] Mizrahi, T., "A game theoretic analysis of delay attacks against time synchronization protocols", accepted, to appear in Proceedings of the International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication, ISPCS, September 2012.
[DelayAtt] Mizrahi、T。、「時間同期プロトコルに対する遅延攻撃のゲーム理論的分析」が承認され、2012年9月のISPCSの計測、制御、通信のための高精度クロック同期に関する国際IEEEシンポジウムのプロシーディングスに掲載されました。
[Hack] McClure, S., Scambray, J., and G. Kurtz, "Hacking Exposed: Network Security Secrets and Solutions", McGraw-Hill, 2009.
[ハック] McClure、S.、Scambray、J。、およびG. Kurtz、「公開されたハッキング：ネットワークセキュリティの秘密とソリューション」、McGraw-Hill、2009年。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[IPsec] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[IPsecSync] Xu, Y., "IPsec security for packet based synchronization", Work in Progress, draft-xu-tictoc-ipsec-security-for-synchronization-02, September 2011.
[IPsecSync] Xu、Y。、「パケットベースの同期のためのIPsecセキュリティ」、作業中、draft-xu-tictoc-ipsec-security-for-synchronization-02、2011年9月。
[Kerb] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006, <http://www.rfc-editor.org/info/rfc4430>.
[Kerb]坂根S.、鎌田K.、トーマスM.、およびJ.ビルハブ、「キーのKerberosインターネットネゴシエーション（KINK）」、RFC 4430、2006年3月、<http：//www.rfc-editor .org / info / rfc4430>。
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Security", IEEE Standard 802.1AE, August 2006.
[MACsec] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Security」、IEEE Standard 802.1AE、2006年8月。
[NTPDDoS] "Attackers use NTP reflection in huge DDoS attack", TICTOC mail archive, 2014.
[NTPDDoS]「攻撃者は巨大なDDoS攻撃でNTPリフレクションを使用する」、TICTOCメールアーカイブ、2014年。
[SecPTP] Tsang, J. and K. Beznosov, "A Security Analysis of the Precise Time Protocol (Short Paper)," 8th International Conference on Information and Communication Security (ICICS) Lecture Notes in Computer Science Volume 4307, pp. 50-59, 2006.
[SecPTP] Tsang、J。およびK. Beznosov、「A Precisise Time Protocol（Short Paper）のセキュリティ分析」、第8回情報通信セキュリティに関する国際会議（ICICS）講義ノート、コンピュータサイエンス第4307巻、50- 59、2006。
[SecSen] Ganeriwal, S., Popper, C., Capkun, S., and M. B. Srivastava, "Secure Time Synchronization in Sensor Networks", ACM Trans. Inf. Syst. Secur., Volume 11, Issue 4, Article 23, July 2008.
[SecSen] Ganeriwal、S.、Popper、C.、Capkun、S。、およびM. B. Srivastava、「センサーネットワークでの安全な時刻同期」、ACM Trans。 INFシステム。 Secur。、Volume 11、Issue 4、Article 23、2008年7月。
[TimeSec] Mizrahi, T., "Time synchronization security using IPsec and MACsec", ISPCS 2011, pp. 38-43, September 2011.
[TimeSec] Mizrahi、T。、「IPsecおよびMACsecを使用した時刻同期セキュリティ」、ISPCS 2011、pp。38-43、2011年9月。
[Traps] Treytl, A., Gaderer, G., Hirschler, B., and R. Cohen, "Traps and pitfalls in secure clock synchronization" in Proceedings of 2007 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2007, pp. 18-24, October 2007.
[トラップ] Treytl、A.、Gaderer、G.、Hirschler、B。、およびR. Cohen、「Proceedings of 2007 International Symposium for Precision Clock Synchronization for Measurement、Control and Communication、ISPCS」の「安全なクロック同期におけるトラップと落とし穴」 2007年、18〜24ページ、2007年10月。
[Tunnel] Treytl, A., Hirschler, B., and T. Sauter, "Secure tunneling of high-precision clock synchronisation protocols and other time-stamped data", in Proceedings of the 8th IEEE International Workshop on Factory Communication Systems (WFCS), pp. 303-313, May 2010.
[トンネル] Treytl、A.、Hirschler、B。、およびT. Sauter、「高精度クロック同期プロトコルおよびその他のタイムスタンプ付きデータの安全なトンネリング」、第8回IEEE国際ワークショップに関する国際ワークショップ（WFCS）の議事録）、pp.303-313、2010年5月。
Acknowledgments
謝辞
The author gratefully acknowledges Stefano Ruffini, Doug Arnold, Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell Smiley, Shawn Emery, Dan Romascanu, Stephen Farrell, Kathleen Moriarty, and Joel Jaeggli for their thorough review and helpful comments. The author would also like to thank members of the TICTOC WG for providing feedback on the TICTOC mailing list.
著者は、徹底的なレビューと有益なコメントを提供してくれたStefano Ruffini、Doug Arnold、Kevin Gross、Dieter Sibold、Dan Grossman、Laurent Montini、Russell Smiley、Shawn Emery、Dan Romascanu、Stephen Farrell、Kathleen Moriarty、Joel Jaeggliに感謝します。 TICTOCメーリングリストに関するフィードバックを提供してくださったTICTOC WGのメンバーにも感謝します。
Contributors
貢献者
Karen O'Donoghue ISOC
かれん お’どのｇふえ いそＣ
EMail: odonoghue@isoc.org
Author's Address
著者のアドレス
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St. Yokneam、20692 Israel
EMail: talmi@marvell.com