GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7384

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.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 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.

Mizrahi Informational [Page 1] RFC 7384 Time Protocol Security Requirements October 2014

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 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.

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

Mizrahi Informational [Page 2] RFC 7384 Time Protocol Security Requirements October 2014

         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

Mizrahi Informational [Page 3] RFC 7384 Time Protocol Security Requirements October 2014

1. Introduction

 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.
 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.
 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.
 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.
 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  Standards development organizations - can use the requirements
    defined in this document when specifying security mechanisms for a
    time protocol.

Mizrahi Informational [Page 4] RFC 7384 Time Protocol Security Requirements October 2014

 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.
 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)?
 (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)?
 (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?)
 In light of the questions above, this document 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
 document are to be interpreted as described in [KEYWORDS].
 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.

Mizrahi Informational [Page 5] RFC 7384 Time Protocol Security Requirements October 2014

2.2. Abbreviations

 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

 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.

2.4. Terms Used in This Document

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

Mizrahi Informational [Page 6] RFC 7384 Time Protocol Security Requirements October 2014

 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  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  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  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  Protocol packets - Packets used by the time protocol.  The
    terminology used in this document distinguishes between time
    packets and control packets.
 o  Secured clock - A clock that supports a security mechanism that
    complies to the requirements in this document.
 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  Time packets - Protocol packets carrying time information.
 o  Unsecured clock - A clock that does not support a security
    mechanism according to the requirements in this document.

3. Security Threats

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

Mizrahi Informational [Page 7] RFC 7384 Time Protocol Security Requirements October 2014

3.1. Threat Model

 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. Internal vs. External Attackers

 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.

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

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

Mizrahi Informational [Page 8] RFC 7384 Time Protocol Security Requirements October 2014

3.2. Threat Analysis

3.2.1. Packet Manipulation

 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.

3.2.2. Spoofing

 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:
 o  An attacker can impersonate the master, allowing malicious
    distribution of false timing information.
 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.
 As with packet manipulation, this attack can result in a situation
 where the time protocol is apparently operational but providing
 intentionally inaccurate information.

3.2.3. Replay Attack

 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.

3.2.4. Rogue Master Attack

 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.

Mizrahi Informational [Page 9] RFC 7384 Time Protocol Security Requirements October 2014

 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.

3.2.5. Packet Interception and Removal

 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.

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

3.2.7. L2/L3 DoS Attacks

 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.

3.2.8. Cryptographic Performance Attacks

 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.

Mizrahi Informational [Page 10] RFC 7384 Time Protocol Security Requirements October 2014

3.2.9. DoS Attacks against the Time Protocol

 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.10. Grandmaster Time Source Attack (e.g., GPS Fraud)

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

3.2.11. Exploiting Vulnerabilities in the Time Protocol

 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.

3.2.12. Network Reconnaissance

 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.

Mizrahi Informational [Page 11] RFC 7384 Time Protocol Security Requirements October 2014

3.3. Threat Analysis Summary

 The two key factors to a threat analysis are the impact and the
 likelihood of each of the analyzed attacks.
 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.
 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.
 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:
 o  DoS - the attack causes denial of service to the attacked node,
    the impact of which is not restricted to the time protocol.
 o  Accuracy degradation - the attack yields a degradation in the
    slave accuracy, but does not completely compromise the slaves'
    time and frequency.
 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.
 The Attacker Type column refers to the four possible combinations of
 the attacker types defined in Section 3.1.

Mizrahi Informational [Page 12] RFC 7384 Time Protocol Security Requirements October 2014

+—————————–+——————-++——————-+

Attack Impact Attacker Type
FalseAccuracy Internal External
Time Degrad. DoS MITMInj.MITMInj.

+—————————–+—–+——–+—-++—-+—-+—-+—-+

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 discussed in this section provide the background for the
 security requirements presented in Section 5.

4. Requirement Levels

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

Mizrahi Informational [Page 13] RFC 7384 Time Protocol Security Requirements October 2014

 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  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.  For each requirement, there is a
 short explanation detailing the reason for its requirement level.

5. Security Requirements

 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.

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.

Mizrahi Informational [Page 14] RFC 7384 Time Protocol Security Requirements October 2014

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

Mizrahi Informational [Page 15] RFC 7384 Time Protocol Security Requirements October 2014

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

Mizrahi Informational [Page 16] RFC 7384 Time Protocol Security Requirements October 2014

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:
    o  Its impact is low, i.e., in the absence of this requirement the
       protocol is only exposed to DoS.
    o  Practical considerations: requiring an NTP server to
       authenticate its clients may significantly impose on 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 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'.
 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'.

Mizrahi Informational [Page 17] RFC 7384 Time Protocol Security Requirements October 2014

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 specified in Section 5.1.3.
 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.
    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.

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.

Mizrahi Informational [Page 18] RFC 7384 Time Protocol Security Requirements October 2014

 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, in the absence of these requirements, the protocol is
    exposed to attacks that are easy to implement and have a high
    impact.
    The requirement level of the third requirement is 'MAY' since its
    impact greatly depends on the application for which the Signaling
    messages are used.
 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.
    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.
    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.

5.2. Protocol Packet Integrity

 Requirement
    The security mechanism MUST protect the integrity of protocol
    packets.

Mizrahi Informational [Page 19] RFC 7384 Time Protocol Security Requirements October 2014

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

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

 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.

5.2.1.1. Hop-by-Hop Integrity Protection

 Each hop that needs to modify a protocol packet:
 o  Verifies its integrity.
 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  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 allows rogue TCs to modify protocol
 packets.

Mizrahi Informational [Page 20] RFC 7384 Time Protocol Security Requirements October 2014

5.2.1.2. End-to-End Integrity Protection

 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.
 Since TCs need to modify the correctionField, a separate integrity
 protection mechanism is used specifically for the 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.

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 are not met,
    the attack may have a high impact, causing slaves to rely on false
    time information.  Thus, the requirement level is 'MUST'.
 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.

Mizrahi Informational [Page 21] RFC 7384 Time Protocol Security Requirements October 2014

    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.

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' due to its
    low impact, i.e., in the absence of this requirement the protocol
    is only exposed to 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).
    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.
    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.

Mizrahi Informational [Page 22] RFC 7384 Time Protocol Security Requirements October 2014

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

5.6. Cryptographic Keys and Security Associations

5.6.1. Key Freshness

 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.

Mizrahi Informational [Page 23] RFC 7384 Time Protocol Security Requirements October 2014

5.6.2. Security Association

 Requirement
    The security protocol SHOULD support a security association
    protocol where:
       o  Two or more clocks authenticate each other.
       o  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
    The requirement level of this requirement is 'SHOULD' since it may
    be expensive in terms of performance, especially in low-cost
    clocks.
 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.
    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).

5.6.3. Unicast and Multicast Associations

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

Mizrahi Informational [Page 24] RFC 7384 Time Protocol Security Requirements October 2014

 Requirement Level
    The requirement level of this requirement is 'SHOULD' since it may
    be expensive in terms of performance, especially for low-cost
    clocks.
 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.

5.7. Performance

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

Mizrahi Informational [Page 25] RFC 7384 Time Protocol Security Requirements October 2014

    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.

5.8. Confidentiality

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

Mizrahi Informational [Page 26] RFC 7384 Time Protocol Security Requirements October 2014

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

5.10. Combining Secured with Unsecured Nodes

 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.

Mizrahi Informational [Page 27] RFC 7384 Time Protocol Security Requirements October 2014

5.10.1. Secure Mode

 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.10.2. Hybrid Mode

 Requirement
    The security protocol SHOULD support a hybrid mode, where both
    secured and unsecured clocks are permitted to take part in the
    protocol.
 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.
 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.
 Requirement
    A master in the hybrid mode SHOULD be a secured clock.

Mizrahi Informational [Page 28] RFC 7384 Time Protocol Security Requirements October 2014

    A secured slave in the hybrid mode SHOULD discard all protocol
    packets received from unsecured clocks.
 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.
 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.

6. Summary of Requirements

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

Mizrahi Informational [Page 29] RFC 7384 Time Protocol Security Requirements October 2014

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

Mizrahi Informational [Page 30] RFC 7384 Time Protocol Security Requirements October 2014

7. Additional Security Implications

 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.

7.1. Security and On-the-Fly Timestamping

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

7.2. PTP: Security and Two-Step Timestamping

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

Mizrahi Informational [Page 31] RFC 7384 Time Protocol Security Requirements October 2014

7.3. Intermediate Clocks

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

7.4. External Security Protocols and Time Protocols

 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].
 Another typical example is the usage of MACsec encryption ([MACsec])
 in L2 networks that deploy time synchronization [AvbAssum].

Mizrahi Informational [Page 32] RFC 7384 Time Protocol Security Requirements October 2014

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

7.5.1. Timestamped Certificates

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

7.5.2. Time Changes and Replay Attacks

 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.

Mizrahi Informational [Page 33] RFC 7384 Time Protocol Security Requirements October 2014

8. Issues for Further Discussion

 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.

9. Security Considerations

 The security considerations of network timing protocols are presented
 throughout this document.

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

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

Mizrahi Informational [Page 34] RFC 7384 Time Protocol Security Requirements October 2014

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

Mizrahi Informational [Page 35] RFC 7384 Time Protocol Security Requirements October 2014

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

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

Mizrahi Informational [Page 36]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7384.txt · Last modified: 2014/10/17 00:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki