RFC 7384

Security Requirements of Time Protocols in Packet Switched Networks

📅 published October 2014, from ietf

Part 1 of 7 🎀

Security Requirements of Time Protocols in Packet Switched Networks 🕰️💖

Okay bestie, here's the title block tea ☕✨ This is RFC 7384, and its author is T. Mizrahi from Marvell 💅. It's an Informational doc, which means it's published for info and isn't a standards-track spec 📚. It's dated October 2014 🗓️, and its ISSN is 2070-1721 🔖. The title block doesn't list any RFCs it obsoletes or updates, so there's nothing to chase there 🙈.

Abstract 🌸

Time and frequency distribution protocols are everywhere now, so people are (rightly!) getting more worried about how exposed they are to security threats 😭. This doc sets out a bunch of security requirements for time protocols, mainly PTP and NTP 🧚. It also covers how time protocol practices affect security, how external security practices affect time protocol performance, and how other security services depend on time sync 🔥.

Status of This Memo 📜

This doc is not an Internet Standards Track spec. It's published for info only 🦋

It's a product of the IETF, so it reflects the consensus of the IETF community 👑. It got public review and was approved for publication by the IESG (Internet Engineering Steering Group) 💜. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you're curious 🤓.

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7384 🌈.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💖

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as in effect on the publication date 📖. Please read them carefully, because they spell out your rights and restrictions for this doc 🫶. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the 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

1. Introduction 🎀

Time protocols are getting more common and more widely deployed, so the security exposure they bring is a growing concern 😬. If a time protocol gets compromised, the apps it serves are open to all kinds of attacks, including Denial of Service (DoS) or just plain incorrect behavior 💀.

This doc digs into the security side of time distribution protocols in packet networks. It focuses on the two most common ones: the Network Time Protocol [NTPv4] and the Precision Time Protocol (PTP) [IEEE1588] 🧚. PTP wasn't defined by the IETF, but it's one of the two most common time protocols, so it's included here 💅.

NTP comes with an inherent security protocol. [NTPv4] defines one based on symmetric key authentication, and [AutoKey] offers an alternative based on public key authentication 🔑. [IEEE1588] has an experimental security protocol in Annex K of the standard, but that Annex never got formalized into a fully defined security protocol 🥲.

NTP has its security built in, but PTP doesn't have a standard security solution, and honestly that gap is a big reason so many unsecured time sync setups got deployed 😭. Sometimes security mechanisms aren't strictly necessary, though, for example because of other security practices in place or because of how the network is architected 🌸. A time sync security solution, like any security solution, is made of various building blocks and has to be carefully tailored to the specific system it's deployed in ✨. Based on a system-specific threat assessment, you weigh the benefits of a security solution against the potential risks, and from that trade-off you can pick an optimal solution 💖.

The target audience of this doc includes:

  • Timing and networking equipment vendors: they can get the security features that should be supported in their time/networking equipment from this doc 🏭.
  • Standards development organizations: they can use the requirements in this doc when specifying security mechanisms for a time protocol 📐.
  • Network operators: they can use this doc as a reference when designing a network and its security architecture. As mentioned above, the requirements in this doc may be deployed selectively, based on a careful per-system threat analysis 🫶.

This doc tries to add some clarity to the time protocol security requirements discussion by tackling four questions:

(1) What threats 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)? 👀

(2) What external security practices affect the security and performance of time keeping, and what can be done to mitigate those impacts (e.g., an IPsec tunnel in the time protocol traffic path)? 🛡️

(3) What are the security impacts of time protocol practices (e.g., on-the-fly modification of timestamps)? ⏱️

(4) What are the dependencies between other security services and time protocols? (For example, which comes first: the certificate or the timestamp?) 🤔

With those questions in mind, this doc defines a set of requirements for security solutions for time protocols, focusing on PTP and NTP 🦋.

2. Terminology 📚

2.1. Requirements Language 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [KEYWORDS] 🔥.

This doc describes security requirements, so requirements are phrased in the form the security mechanism MUST/SHOULD/... 📝. Just note that this phrasing doesn't mean the doc defines one specific security mechanism. It means the doc defines the requirements that every security mechanism should comply with 💜.

2.2. Abbreviations ✨

okay so before we get into the juicy stuff, here's the abbreviation cheat sheet 🎀 (the list is giving alphabet soup, lowkey iconic)

BC       Boundary Clock [IEEE1588]

BMCA     Best Master Clock Algorithm [IEEE1588]

DoS      Denial of Service

MITM     Man in the Middle

NTP      Network Time Protocol [NTPv4]

OC       Ordinary Clock [IEEE1588]

P2P TC   Peer-to-Peer Transparent Clock [IEEE1588]

PTP      Precision Time Protocol [IEEE1588]

TC       Transparent Clock [IEEE1588]

2.3. Common Terminology for PTP and NTP 🧚

bestie, PTP and NTP are both in this doc, so we need the same words for the same roles 💅. The term "master" covers both a PTP master and an NTP server. The term "slave" covers both PTP slaves and NTP clients. And "protocol packets" is the umbrella term for PTP and NTP messages 💖.

2.4. Terms Used in This Document 💜

here's the glossary, and it's SO important to get these right 🫶

  • 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). 🌸
  • 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. 💅
  • 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. 🔐 ngl this one is kind of a plot twist ✨
  • 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. 👑
  • 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. 🦋
  • 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. 🍓
  • 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. 👑
  • Protocol packets - Packets used by the time protocol. The terminology used in this document distinguishes between time packets and control packets. 🎀
  • Secured clock - A clock that supports a security mechanism that complies to the requirements in this document. 🔥
  • 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. 🌈
  • Time packets - Protocol packets carrying time information. ⭐
  • Unsecured clock - A clock that does not support a security mechanism according to the requirements in this document. 🙈

3. Security Threats 💀

okay this section is where it gets dramatic 😭 it talks about the kinds of attackers and the attacks they can pull off against time protocols. the literature is full of these, like [Traps], [AutoKey], [TimeSec], [SecPTP], and [SecSen]. the threat analysis here is mostly based on [TimeSec] 🧚

3.1. Threat Model 🌸

a time protocol can get attacked by all kinds of attackers, and we need to sort them out 💅

the analysis classifies attackers by two criteria, which are in Sections 3.1.1 and 3.1.2 💖

3.1.1. Internal vs. External Attackers 🔐

here the underlying assumption is that the time protocol is secured by 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. they can also get in by exploiting vulnerabilities in devices, like installing malware or getting credentials to reconfigure the device. so an internal attacker can tamper with legitimate traffic, and also generate its own traffic and make it look legit to the nodes it attacks 😭

note that internal attacks are a special case of Byzantine failures, where a node can fail in arbitrary ways: by crashing, by omitting messages, or by malicious behavior. this document focuses on nodes that show malicious behavior 👑

external attackers, on the other hand, do not have the keys and only have access to the encrypted or authenticated traffic 🦋

obviously, without a security mechanism there's no difference between internal and external attackers, since in practice all attackers are internal 💀

3.1.2. Man in the Middle (MITM) vs. Packet Injector 🍓

MITM attackers sit in a position where they can intercept and modify in-flight protocol packets. it's assumed that an MITM attacker has physical access to a segment of the network or has taken control of one of the nodes in the network 🕵️

a traffic injector is not in an MITM position, but it can attack by generating protocol packets. an injector can be inside the attacked network or on an external network connected to it. it can also potentially eavesdrop on protocol packets sent as multicast, record them, and replay them later 🌈

3.2. Threat Analysis ✨

3.2.1. Packet Manipulation 💅

a packet manipulation attack happens when an MITM attacker receives timing protocol packets, alters them, and relays them to their destination. this lets the attacker maliciously tamper with the protocol 😭 the result can be that the time protocol looks totally operational while giving intentionally inaccurate info 🙈

3.2.2. Spoofing 🎭

in spoofing, an injector pretends to be a legitimate node in the network by generating and transmitting protocol packets or control packets. two typical examples:

  • an attacker can impersonate the master, letting it hand out false timing info 💀
  • an attacker can impersonate a legitimate clock, a slave, or an intermediate clock by sending malicious messages to the master. the master then responds to the legit clock with protocol packets based on those spoofed messages, so the legit clock's delay computations are based on false info 😭

just like packet manipulation, this can make the time protocol look operational while it's really providing intentionally inaccurate info 🫠

3.2.3. Replay Attack 🔁

in a replay attack, an attacker records protocol packets and replays them later without modifying them. this can also make the time protocol look operational while it's providing intentionally inaccurate info 🙈

3.2.4. Rogue Master Attack 👑

in a rogue master attack, an attacker makes other nodes in the network believe it's a legitimate master. unlike spoofing, the attacker doesn't fake its identity. instead it messes with the master election process using malicious control packets. for example, in PTP an attacker can manipulate the Best Master Clock Algorithm (BMCA) so other nodes think it's the most eligible candidate to be a grandmaster 🔥

in PTP there's a possible variant called the rogue TC/BC attack. just like the rogue master attack, the attacker can convince victims that it's a legitimate TC or BC, letting it manipulate the time info forwarded to them 🦋

3.2.5. Packet Interception and Removal 🚫

a packet interception and removal attack happens when an MITM attacker intercepts and drops protocol packets, so the destination never gets some or all of them 😭

3.2.6. Packet Delay Manipulation 🐢

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 different delay strategies: the added delay can be constant, jittered, or slowly wandering. each has a different impact, but they all effectively manipulate the attacked clock 🌸

note that the victim still gets one copy of each packet, unlike the replay attack, where some or all packets may reach the victim more than once 🙃

3.2.7. L2/L3 DoS Attacks 🌐

there are lots of possible Layer 2 and Layer 3 DoS attacks, like IP spoofing, ARP spoofing [Hack], MAC flooding [Anatomy], and many others. since the target's availability is compromised, the timing protocol is affected too 💔

3.2.8. Cryptographic Performance Attacks 🔥

in cryptographic performance attacks, an attacker sends fake protocol packets, which makes the receiver's cryptographic engine work super hard trying to verify their integrity 🥵

this DoS attack applies to all encryption and authentication protocols. but when the time protocol uses a dedicated security mechanism in a dedicated cryptographic engine, the attack can be used to DoS the time protocol specifically 💀

3.2.9. DoS Attacks against the Time Protocol 💥

an attacker can attack a clock by sending an excessive number of time protocol packets, which degrades the victim's performance. this can be done with the attacks described in Sections 3.2.2 and 3.2.4, for example 😤

3.2.10. Grandmaster Time Source Attack (e.g., GPS Fraud) 🛰️

grandmasters get their time from an external accurate time source, like an atomic clock or a GPS clock, and then distribute it to the slaves using the time protocol 🧚

time source attacks target the accurate time source of the grandmaster. for example, if the grandmaster uses a GPS-based clock as its reference, an attacker can jam the GPS signal, or transmit a signal similar to one from a GPS satellite, so the grandmaster uses a false reference time 😱

note that this attack is outside the scope of the time protocol. various security measures can mitigate it, but those measures are outside the scope of the security requirements defined in this document 🙄

3.2.11. Exploiting Vulnerabilities in the Time Protocol 🐛

time protocols can be attacked by exploiting protocol vulnerabilities, implementation bugs, or misconfigurations (e.g., [NTPDDoS]). it should be noted that such attacks typically can't 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 🚨

3.2.12. Network Reconnaissance

Okay bestie, the time protocol can be used as a little scouting tool 🕵️‍♀️✨ An attacker can dig up the addresses and locations of the nodes taking part in it, and there are two ways to do that. They can quietly eavesdrop on the protocol packets, or they can send sneaky malicious packets and collect info from whatever comes back. 👀 Eavesdropping is especially sus because an attacker can learn the network latencies from it, and those latencies give hints about the network topology and where the nodes are sitting. 🗺️

It gets even wilder. The frequency of the protocol packets, or the exact moments they get sent, can be used to fingerprint specific nodes 🫣 So even if someone hides or encrypts the network addresses, the packets from a node can still be picked out. Not hiding in plain sight, no cap 🙈

3.3. Threat Analysis Summary

Two things decide how scary a threat is: the impact and the likelihood of each analyzed attack 📊 Table 1 sums up the security attacks from Section 3.2. For every attack, it shows the impact and how it applies to each attacker type from Section 3.1.

Table 1 makes the difference between external and internal attackers super clear 💅 It also shows why authentication and integrity protection are worth it, since they really cut down how much damage external attackers can do. 🛡️

The Impact column gives you a vibe check on how severe each attack is. The Attacker Type column tells you how hard each attack is to pull off, which hints at how likely it is. 🎯

The Impact column in Table 1 can have one of three values:

  • DoS - the attack causes denial of service to the attacked node, and the impact of which is not restricted to the time protocol. 💀
  • Accuracy degradation - the attack yields a degradation in the slave accuracy, but does not completely compromise the slaves' time and frequency. 📉
  • 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. 🚨

The Attacker Type column covers the four possible combinations of the attacker types defined in Section 3.1. 🧩

+-----------------------------+-------------------++-------------------+
| 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

The threats in this section are the background for the security requirements in Section 5 🌸 So this is the setup for everything that comes next, bestie. 🎀

4. Requirement Levels ✨

The security requirements are in Section 5. Each requirement gets a requirement level, following the requirement levels defined in Section 2.1 📝

These are the factors that affect the requirement levels:

  • Impact: The possible impact of not implementing the requirement, as shown 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. 🚨
  • 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'. 🧗‍♀️
  • 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. 🛠️

Section 5 lists the requirements, and each one comes with a short explanation of why it has its requirement level 💖

5. Security Requirements 🔐

This section defines a set of security requirements. They're written as "the security mechanism MUST/SHOULD/MAY...". But this document doesn't say how to meet them 🙅‍♀️ Some of them can be satisfied by defining explicit security mechanisms for time protocols. At least a few can be met by applying common security practices to the network, or by using existing security protocols like [IPsec] or [MACsec]. So solutions that address these requirements are out of scope for this document. 🫶

5.1. Clock Identity Authentication and Authorization

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).

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 means verifying the identity of the peer clock 🪪 Authorization means verifying that the peer clock is permitted to play the role 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.

Authentication is typically done with a cryptographic signature, which lets you verify who sent the message 🔏 Authorization requires clocks to keep a list of authorized clocks, or a "black list" of clocks that should be denied service or revoked.

It's worth noting that while the security mechanism is required to provide an authorization mechanism, how that gets deployed depends on 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 a network like that, an authorization mechanism may not be necessary. 🤷‍♀️

The following subsections describe five distinct cases of clock authentication. 🧁

5.1.1. Authentication and Authorization of Masters

Requirement

The security mechanism MUST support an authentication mechanism, allowing slaves to authenticate the identity of masters.

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).

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 so they can be sure the time source is legit 🕰️ It's important for a slave to verify the identity of the master, and also to check that the master is actually authorized to be a master. Main character verification energy 👑

5.1.2. Recursive Authentication and Authorization of Masters (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).

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

Sometimes a slave is connected to an intermediate clock that isn't 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. NTP has a similar setup 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 called proventication in [AutoKey] 🧠

Specifically in PTP, this requirement means that if a slave gets time information through a TC, it must authenticate the TC it's attached to, as well as the master it gets the time information from, as per Section 5.1.1. Likewise, if a TC gets time information through an attached TC, it must authenticate that attached TC. It's a whole chain of trust, bestie 🫶⛓️

5.1.3. Authentication and Authorization of Slaves

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). 🛡️

The requirement level of this requirement is 'MAY' since:

  • Its impact is low, i.e., without this requirement the protocol is only exposed to DoS. 🌸
  • Practical considerations: making an NTP server authenticate its clients could seriously hit the server's performance. 😭

Note that while the requirement level of this requirement is 'MAY', the requirement in Section 5.1.1 is 'MUST'. The security mechanism has to provide a means for authentication and authorization, with the emphasis on the master. Authentication and authorization of slaves are specified in this subsection as 'MAY'. 👑

Discussion 💬

Slaves and intermediate clocks get authenticated by masters so the master can check that they're authorized to receive timing services. 🧚

Authenticating slaves stops unauthorized clocks from getting time services, and not serving unauthorized clocks can help mitigate DoS attacks against the master. Just know that authenticating slaves might put a higher load on the master than serving the unauthorized clock would, which is exactly why this requirement is 'MAY'. 🤓

5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master

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.

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.

Requirement Level 💅

The requirement in this subsection prevents DoS attacks against the master (Section 3.2.9). 🛡️

The requirement level of this requirement is 'MAY' for the same reasons given in Section 5.1.3. ✨

Discussion 💬

P2P TCs that are one hop away from the master use the PDelay_Req and PDelay_Resp handshake to compute the link delay between the master and the TC. These TCs get authenticated by the master. 🦋

Authenticating TCs, much like authenticating slaves, cuts down on unnecessary load on the master and peer TCs, because the master stops serving unauthorized clocks. 💖

5.1.5. PTP: Authentication and Authorization of Control Messages

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. 🔥

Requirement 🎀

The security mechanism for PTP MUST support authentication and authorization of Management messages. 🔥

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). 🎭

The requirement level of the first two requirements is 'MUST' since, without these requirements, the protocol is exposed to attacks that are easy to pull off and have a high impact. 💀

The requirement level of the third requirement is 'MAY' since its impact depends heavily on the application the Signaling messages are used for. 🍓

Discussion 💬

PTP picks its master using the Best Master Clock Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock attributes using Announce messages, and the best master gets elected based on the info gathered from all the candidates. 👑

Announce messages need to be authenticated to prevent rogue master attacks (Section 3.2.4). This subsection specifies a requirement that isn't necessarily covered by Sections 5.1.1 or 5.1.3, since the BMCA kicks off before clocks have been defined as masters or slaves. 🧠

Management messages are used to monitor or configure PTP clocks. Malicious use of Management messages enables various attacks, such as the rogue master attack or a DoS attack. 😈

Signaling messages let PTP clocks exchange information that isn't strictly about time or master selection, like unicast negotiation. Authenticating and authorizing Signaling messages may be required in some systems, depending on the application these messages are used for. 🫶

5.2. Protocol Packet Integrity

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). ✂️

The requirement level of this requirement is 'MUST' since, without this requirement, the protocol is exposed to attacks that are easy to implement and have high impact. 💥

Discussion 💬

Section 5.1 is about making sure the identity and authorization of the source of a protocol packet check out, while this subsection is about making sure the packet arrived intact. 🎁 Integrity protection makes sure the data is authentic and complete from the data originator. 🫧

Integrity protection is typically done with an Integrity Check Value (ICV) that's included in protocol packets and gets verified by the receiver. ✅

5.2.1. PTP: Hop-by-Hop vs. End-to-End Integrity Protection

Specifically in PTP, when TCs are allowed to modify protocol packets, integrity protection can be enforced in one of two approaches: end-to-end or hop-by-hop. 🦋

5.2.1.1. Hop-by-Hop Integrity Protection

Each hop that needs to modify a protocol packet:

  • Verifies its integrity.
  • 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. ⏱️
  • Re-generates the integrity protection, e.g., re-computes a Message Authentication Code (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 it allows rogue TCs to modify protocol packets. 😬

5.2.1.2. End-to-End Integrity Protection

In this approach, integrity protection is maintained on the path from the originator of a protocol packet to the receiver. This lets the receiver validate the protocol packet directly, without intermediate TCs being able to manipulate it. 🔐

Since TCs need to modify the correctionField, a separate integrity protection mechanism is used specifically for the correctionField. 🧩

The end-to-end approach limits a TC's impact to the correctionField alone, while the rest of the protocol packet is protected end to end. It's worth noting that this approach is harder to implement than hop-by-hop, because the correctionField has to be protected separately from the other fields of the packet, possibly using different cryptographic mechanisms and keys. 🧑‍💻

5.3. Spoofing Prevention

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. 🚫

Requirement Level 💅

The requirements in this subsection address spoofing attacks. As described in Section 3.2.2, when these requirements aren't met, the attack may have a high impact, causing slaves to rely on false time information. So the requirement level is 'MUST'. 🚨

Discussion 💬

Spoofing attacks can take lots of different forms and can cause serious damage. 😱 In a master spoofing attack, the attacker tricks slaves into receiving false info about the current time by pretending to be the master. 🎭

By spoofing a slave or an intermediate node (the second example in Section 3.2.2), an attacker can mess 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's also included in the corresponding Delay_Resp message, so the slave can verify that the Delay_Resp wasn't sent in response to a spoofed message. 🧾✨

5.4. Availability

Requirement 🎀

The security mechanism SHOULD include measures to mitigate DoS attacks against the time protocol. 🛡️

Requirement Level 💅

The requirement in this subsection prevents DoS attacks against the protocol (Section 3.2.9). 🛑

The requirement level of this requirement is 'SHOULD' because its impact is low, i.e., without this requirement the protocol is only exposed to DoS. 🌤️

Discussion 💬

Protocol availability can be compromised by several different attacks. An attacker can inject protocol packets to carry out 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). 🥲

An authentication mechanism (Section 5.1) limits these attacks strictly to internal attackers, so it stops external attackers from pulling them off. That means the requirements of Section 5.1 can be used to mitigate this attack. Note that Section 5.1 covers a wider range of threats, whereas this section is focused on availability. 🧸

The DoS attacks described in Section 3.2.7 happen at lower layers than the time protocol layer, so they're outside the scope of the security requirements defined in this document. 📡

5.5. Replay Protection

Requirement 🎀

The security mechanism MUST include a replay prevention mechanism. 🔁

Requirement Level 💅

The requirement in this subsection prevents replay attacks (Section 3.2.3). 🎯

The requirement level of this requirement is 'MUST' since, without 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 the availability of the protocol. 😵 Common encryption and authentication mechanisms include replay prevention mechanisms that typically use a monotonously increasing packet sequence number. 🔢

5.6. Cryptographic Keys and Security Associations

5.6.1. Key Freshness

Requirement 🔑

The security mechanism MUST provide a way to refresh the cryptographic keys. ✨

The cryptographic keys MUST be refreshed frequently. 💖

Requirement Level 🎀

This one's a 'MUST' bc key freshness is an essential property for cryptographic algorithms, as we'll see below. 💅

Discussion 🦋

Key freshness means both sides share a common, updated secret key. ✨ It also helps prevent replay attacks, so it's super important that keys get refreshed frequently. ngl this is a big deal 😭 Note that the word 'frequently' has no number attached to it. The exact frequency should be figured out for each system on its own, based on the threats and the system's requirements. 🌸

5.6.2. Security Association

Requirement 🧚

The security protocol SHOULD support a security association protocol where:

  • Two or more clocks authenticate each other. 🫶
  • The clocks generate and agree on a cryptographic session key. 🔐

Requirement 💜

Each instance of the association protocol SHOULD produce a different session key. 🌈

Requirement Level 🌸

This is a 'SHOULD' bc it can be expensive in terms of performance, especially on low-cost clocks. 🙈

Discussion 💬

The security requirements in Sections 5.1 and 5.2 need cryptographic mechanisms, which means deploying cryptographic keys. 🔑 A security association (e.g., [IPsec]) is a big, important building block for all of this. 🧱

It's worth knowing that different security association mechanisms might be used at different levels of clock hierarchies. ✨ For example, the association between a Stratum 2 clock and a Stratum 3 clock in NTP can have different characteristics than an association between two clocks at the same stratum level. 🦋 On a related note, sometimes a hybrid solution is used, where part of the network isn't secured at all (see Section 5.10.2). 🫠

5.6.3. Unicast and Multicast Associations

Requirement 🎀

The security mechanism SHOULD support security association protocols for unicast and for multicast associations. 💖

Requirement Level ✨

This is a 'SHOULD' bc it can be expensive in terms of performance, especially for low-cost clocks. 🍓

Discussion 🌈

A unicast protocol needs an association protocol between two clocks. 👯 A multicast protocol needs an association protocol among two or more clocks, where one of the clocks is a master. 👑

5.7. Performance

Requirement 💅

The security mechanism MUST be designed so that it does not significantly degrade the quality of the time transfer. 🔥

Requirement 🧁

The mechanism SHOULD minimize computational load. 🧠

Requirement 🌷

The mechanism SHOULD minimize storage requirements of client state in the master. 🗄️

Requirement 🦄

The mechanism SHOULD minimize the bandwidth overhead required by the security protocol. 📶

Requirement Level 💫

Quality of the time transfer is clearly a 'MUST', no debate. 🙅‍♀️ The other three performance requirements are 'SHOULD', since some systems are more sensitive to resource consumption than others. 🤷‍♀️ So these should be considered on a per-system basis. 🎀

Discussion 🧠

Performance efficiency is a big deal bc client restrictions often call for a low processing and memory footprint, and the server may have a huge fan-out. 📣

Note that the performance requirements are about a time-protocol-specific security mechanism. ⏰ In systems where a security protocol also carries other types of traffic, this document doesn't place any performance requirements on the security protocol's performance. 🙌 For example, if IPsec encryption is used to secure all information between the master and slave node, including information that isn't part of the time protocol, the requirements in this subsection are not necessarily applicable. 🫶

5.8. Confidentiality

Requirement 🔒

The security mechanism MAY provide confidentiality protection of the protocol packets. 🫧

Requirement Level 🌙

This one is a 'MAY' bc not having it doesn't expose the protocol to severe threats, as we'll see below. 🙂

Discussion 💜

For time protocols, confidentiality is usually low-key not that important, since timing information is typically not considered secret. 🕰️

Confidentiality can matter a lot when service providers charge customers for time synchronization services. 💸 An encryption mechanism can stop eavesdroppers from getting the service for free. 🙅‍♀️ Note that these cases are, for now, rather esoteric. 🧐

Confidentiality can also stop a MITM attacker from identifying protocol packets. 🕵️‍♀️ So it can help protect the timing protocol against MITM attacks like packet delay (Section 3.2.6), manipulation and interception, and removal attacks. 🛡️ Note that time protocols still have predictable behavior after encryption, like packet transmission rates and packet lengths. 📈 Extra measures can help with encrypted traffic analysis, like random padding of encrypted packets and adding random dummy packets. 🎲 Still, encryption doesn't prevent these MITM attacks. It just makes them harder to pull off. 😤

5.9. Protection against Packet Delay and Interception Attacks

Requirement 🚨

The security mechanism MUST include means to protect the protocol from MITM attacks that degrade the clock accuracy. 🛑

Requirement Level ⚠️

This subsection covers MITM attacks like the packet delay attack (Section 3.2.6) and the packet interception attacks (Sections 3.2.5 and 3.2.1). 🕸️

The requirement level here is 'MUST'. Without this requirement, the protocol is open to attacks that are easy to pull off and have a high impact. 💀 Note that without it, the impact is similar to packet manipulation attacks (Section 3.2.1), so this requirement gets the same requirement level as integrity protection (Section 5.2). 🫶

It's noted that how you implement this requirement depends on the topology and properties of the system. 🗺️

Discussion 🕵️

While this document doesn't define specific security solutions, common practices for protecting against MITM attacks use redundant masters (e.g., [NTPv4]) or redundant paths between the master and slave (e.g., [DelayAtt]). 🛤️ If one time source reports a time value that's way different from the other sources, it's assumed to be erroneous or under attack, so it gets ignored. 🙅‍♀️

So MITM attack prevention pulls a requirement from the security mechanism and another from the network topology. 🧩 The security mechanism should support detecting delay attacks, but in some networks it isn't possible to have the redundancy needed for that kind of detection. 🥺

5.10. Combining Secured with Unsecured Nodes

Integrating a security mechanism into a time-synchronized system is a complex and expensive process. 🫠 So in some cases it needs incremental deployment, where new equipment supports the security mechanism and is required to interoperate with legacy equipment that doesn't have the security features. 🤝

5.10.1. Secure Mode

Requirement 🔐

The security mechanism MUST support a secure mode, where only secured clocks are allowed to take part in the time protocol. ✅ In this mode, every protocol packet received from an unsecured clock MUST be discarded. 🗑️

Requirement Level 👑

This is a 'MUST' bc the full power of the security requirements in this document can only be reached in secure mode. 💪

Discussion 💅

This requirement is similar to the one in Section 5.1, but it's about the secure mode, as opposed to the hybrid mode in the next subsection. 🦋

5.10.2. Hybrid Mode

Requirement 🌈

The security protocol SHOULD support a hybrid mode, where both secured and unsecured clocks are allowed to take part in the protocol. 🫂

Requirement Level 🎀

This is a 'SHOULD'. On one hand, hybrid mode allows a gradual move from unsecured to secured mode, which matters a ton in large-scale deployments. 📈 On the other hand, hybrid mode isn't required in every system. This document recommends the 'secure mode' from Section 5.10.1 wherever it's possible. ✨

Discussion 🧁

Hybrid mode lets both secured and unsecured clocks take part in the time protocol. NTP, for example, allows a mix of secured and unsecured nodes. 🍓

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. 🗑️

Requirement Level 🌸

This is a 'SHOULD' bc it might not apply to every deployment. For example, a hybrid network may need to use unsecured masters or TCs. 🤓

Discussion 🦄

This requirement makes sure the existence of unsecured clocks doesn't compromise the security given to secured clocks. 🛡️ So 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 doesn't apply when encryption is used. When integrity protection is used, the unsecured slave can receive secured packets while 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 isn't necessarily the server that supports authentication. 🤯 For example, a Stratum 2 server is connected to two Stratum 1 servers: Server A, which supports authentication, and Server B, which doesn't. 🖥️ If Server B has a more accurate clock than Server A, the Stratum 2 server picks Server B, even though it doesn't support authentication. 😭

6. Summary of Requirements ✨

okay bestie, this is the cheat sheet 💅 every single requirement from the whole doc, with its section number and how strict it is. Table 2 is the one to screenshot 📸

   +-----------+---------------------------------------------+--------+
   | 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

7. Additional Security Implications

okay so this section is about where time protocols and security mechanisms bump into each other 👀 it's giving tricky interaction energy 🔥

this section talks about the time protocol's own security stuff, and "external" security mechanisms, meaning the ones that aren't really about the time protocol at all 🧚

7.1. Security and On-the-Fly Timestamping

so time protocols often need packets to get changed while they're being sent 💅 both NTP and PTP in one-step mode make clocks edit protocol packets based on when they're sent and/or received ⏰

when there's a security mechanism involved, whether that's encryption or integrity protection:

  • During transmission the encryption and/or integrity protection MUST be applied after integrating the timestamp into the packet. 🔒

to get high accuracy, timestamping happens as close to the send or receive moment as possible 🎯 but the security engine has to sit between the timestamping part and the physical interface, so it can add non-deterministic latency and mess up accuracy 😭 people have looked into this already, e.g., [1588IPsec] and [Tunnel] 📚

7.2. PTP: Security and Two-Step Timestamping

PTP has a two-step mode 🦋 where the send time gets communicated without changing the packets themselves. unlike one-step mode, two-step timestamping doesn't need you to encrypt after timestamping, which is lowkey so convenient 💖

heads up though: if you use something like IPsec for encryption, it makes life hard for timestamping, since time protocol packets are encrypted on the way out the physical interface and become impossible to identify 🙈 one possible fix [IPsecSync] is to put an indication in the encryption header that marks time protocol packets 🎀

7.3. Intermediate Clocks

a time protocol lets slaves get time info from a super accurate time source ✨ that info usually travels a path that goes through one or more intermediate clocks 🛤️

  • 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]. 🌸
  • In PTP, BCs and TCs are intermediate nodes used to improve the accuracy of time information conveyed between the grandmaster and the slaves. 💜

the common rule of thumb in network security is that end-to-end security is the best policy 🏆 since it protects the entire path between the data originator and its receiver. but intermediate nodes mean that if a security mechanism is deployed in the network, a hop-by-hop security scheme must be used, because intermediate nodes have to be able to send time info to the slaves, or change time info sent through them 😬

this also makes the system more exposed to internal threats, since a bunch of nodes hold the security keys 🕵️

so there's a trade-off ⚖️ between how accurate your clocks can be and how robust your security is. high clock accuracy wants hop-by-hop involvement in the protocol (aka on-path support), but a robust security solution wants end-to-end data protection 🫶

7.4. External Security Protocols and Time Protocols

time protocols get deployed in systems that already use security mechanisms and protocols all the time 🌈

a classic example is the 3GPP Femtocell network [3GPP], where IPsec secures traffic between a Femtocell and the Femto Gateway. sometimes all traffic between those two, time protocol traffic included, gets secured by IPsec 🔐 this use-case is discussed in depth in [IPsecSync] 📖

another example is MACsec encryption ([MACsec]) in L2 networks that do time synchronization [AvbAssum] 🧦

the usage of external security mechanisms may affect time protocols in these ways:

  • Timestamping accuracy can be affected, as described in Section 7.1. ⏱️
  • 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. 😤

7.5. External Security Services Requiring Time

cryptographic protocols often use time as an important ingredient in the algorithm 🧁 so if a time protocol gets compromised, it can expose the security protocols that rely on it to all kinds of attacks 💀 two examples are coming up 👇

7.5.1. Timestamped Certificates

certificate validation needs the sender and receiver to be roughly time synchronized ⏳ so synchronization is needed for setting up security protocols like Internet Key Exchange Protocol version 2 (IKEv2) and Transport Layer Security (TLS). other authentication and key exchange mechanisms, like Kerberos, also need the parties to be synchronized [Kerb] 🔑

it gets even more tangled 🧶 [AutoKey] defines a mutual dependence between the acquired time information and the authentication protocol that secures it. this bootstrapping happens because trusting the received time info requires a valid certificate, and validating a certificate requires knowing the time 🔄 chicken, meet egg 🐔🥚

7.5.2. Time Changes and Replay Attacks

a successful attack on a time protocol can make attacked clocks go back in time ⏪ that wrong time can expose cryptographic algorithms that rely on time, because a node may use a key that was already used in the past and has expired 🥀

8. Issues for Further Discussion

the key distribution is outside the scope of this document 🗝️ it's an essential piece of any security system, but it's still outside the scope of this doc, so it's a different conversation bestie 💅

9. Security Considerations

the security considerations of network timing protocols are presented throughout this document 🛡️ so read the whole thing, it's not optional 😤✨

10. References

10.1. Normative References

  • [IEEE1588] IEEE, "1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588-2008, July 2008.
  • [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>.
  • [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>.

10.2. Informative References

okay bestie, these are the extra reads 💜 not required to implement anything, but they're where the security nerds go to get obsessed 🤓

  • [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. 🔐
  • [3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 11.6.0, November 2012. 📡
  • [Anatomy] Nachreiner, C., "Anatomy of an ARP Poisoning Attack", 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>. 🔑
  • [AvbAssum] Pannell, D., "Audio Video Bridging Gen 2 Assumptions", IEEE 802.1 AVB Plenary, Work in Progress, May 2012. 🎧
  • [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. 🎮
  • [Hack] McClure, S., Scambray, J., and G. Kurtz, "Hacking Exposed: Network Security Secrets and Solutions", 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>. 🛡️
  • [IPsecSync] Xu, Y., "IPsec security for packet based synchronization", Work in Progress, draft-xu-tictoc-ipsec-security-for-synchronization-02, September 2011. ⏱️
  • [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>. 🗝️
  • [MACsec] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Security", IEEE Standard 802.1AE, August 2006. 🧷
  • [NTPDDoS] "Attackers use NTP reflection in huge DDoS attack", TICTOC mail archive, 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. 🔍
  • [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. 📶
  • [TimeSec] Mizrahi, T., "Time synchronization security using IPsec and MACsec", ISPCS 2011, pp. 38-43, September 2011. 🧩
  • [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. 🪤
  • [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. 🚇

Acknowledgments 🫶

the author is so grateful to 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 💖 they really showed up for this one. the author would also like to thank members of the TICTOC WG for giving feedback on the TICTOC mailing list 📬

Contributors 🌸

Karen O'Donoghue
ISOC

EMail: odonoghue@isoc.org

Author's Address 🦋

Tal Mizrahi
Marvell
6 Hamada St.
Yokneam, 20692 Israel

EMail: talmi@marvell.com

the end, and what a ride ✨🌈✨

📦 where this page comes from