draft-ietf-tictoc-security-requirements-01.txt   draft-ietf-tictoc-security-requirements-02.txt 
TICTOC Working Group Tal Mizrahi TICTOC Working Group Tal Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Karen O'Donoghue Intended status: Informational Karen O'Donoghue
Expires: September 2012 ISOC Expires: December 2012 ISOC
March 12, 2012 June 17, 2012
TICTOC Security Requirements TICTOC Security Requirements
draft-ietf-tictoc-security-requirements-01.txt draft-ietf-tictoc-security-requirements-02.txt
Abstract Abstract
As time synchronization protocols are becoming increasingly common As time synchronization protocols are becoming increasingly common
and widely deployed, concern about their exposure to various security and widely deployed, concern about their exposure to various security
threats is increasing. This document defines a set of requirements threats is increasing. This document defines a set of requirements
for security solutions for time synchronization protocols, focusing for security solutions for time synchronization protocols, focusing
on the IEEE 1588 and NTP. This document also discusses the security on the IEEE 1588 and NTP. This document also discusses the security
impacts of time synchronization protocol practices, the time impacts of time synchronization protocol practices, the time
synchronization performance implications of external security synchronization performance implications of external security
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 12, 2012. This Internet-Draft will expire on December 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 3
2. Conventions Used in this Document ............................ 4 2. Conventions Used in this Document ............................ 4
2.1. Terminology ............................................. 4 2.1. Terminology ............................................. 4
2.2. Abbreviations ........................................... 4 2.2. Terms & Abbreviations ................................... 5
3. Security Threats ............................................. 5 3. Security Threats ............................................. 5
3.1. Packet interception and manipulation .................... 5 3.1. Threat Model ............................................ 5
3.2. Spoofing ................................................ 5 3.1.1. Internal vs. External Attackers .................... 5
3.3. Replay attack ........................................... 5 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 6
3.4. Rogue master attack ..................................... 5 3.2. Threat Analysis.......................................... 6
3.5. Packet Interception and Removal ......................... 6 3.2.1. Packet Interception and Manipulation ............... 6
3.6. Packet delay manipulation ............................... 6 3.2.2. Spoofing ........................................... 6
3.7. Cryptographic performance attacks ....................... 6 3.2.3. Replay Attack ...................................... 6
3.8. DoS attacks ............................................. 6 3.2.4. Rogue Master Attack ................................ 6
3.9. Time source spoofing (e.g. GPS fraud) ................... 6 3.2.5. Packet Interception and Removal .................... 7
4. Security Requirements ........................................ 6 3.2.6. Packet Delay Manipulation .......................... 7
4.1. Clock Identity Authentication ........................... 6 3.2.7. Cryptographic Performance Attacks .................. 7
4.1.1. Authentication of Masters .......................... 7 3.2.8. L2/L3 DoS Attacks .................................. 7
4.1.2. Proventication of Masters .......................... 7 3.2.9. Master Time Source Spoofing (e.g. GPS fraud) ....... 7
4.1.3. Authentication of Slaves ........................... 7 3.3. Threat Analysis Summary ................................. 7
4.1.4. PTP: Authentication of Transparent Clocks........... 8 4. Security Requirements ........................................ 9
4.1.5. PTP: Authentication of Announce Messages ........... 8 4.1. Clock Identity Authentication ........................... 9
4.2. Data integrity .......................................... 9 4.1.1. Authentication of Masters .......................... 9
4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 9 4.1.2. Proventication of Masters .......................... 9
4.2.1.1. Hop by Hop Integrity Protection ............... 9 4.1.3. Authentication of Slaves .......................... 10
4.2.1.2. End to End Integrity Protection .............. 10 4.1.4. PTP: Authentication of Transparent Clocks.......... 10
4.3. Availability ........................................... 10 4.1.5. PTP: Authentication of Announce Messages .......... 11
4.4. Replay Protection ...................................... 10 4.2. Data integrity ......................................... 11
4.5. Cryptographic Keys & Security Associations ............. 10 4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 11
4.5.1. Security Association .............................. 10 4.2.1.1. Hop by Hop Integrity Protection .............. 12
4.5.2. Unicast and Multicast ............................. 11 4.2.1.2. End to End Integrity Protection .............. 12
4.5.3. Key Freshness ..................................... 11
4.6. Performance ............................................ 11 4.3. Availability ........................................... 12
4.7. Confidentiality......................................... 12 4.4. Replay Protection ...................................... 13
4.8. Protection against packet delay attacks ................ 12 4.5. Cryptographic Keys & Security Associations ............. 13
4.9. Combining Secured with Unsecured Nodes ................. 12 4.5.1. Security Association .............................. 13
4.9.1. Secure Mode ....................................... 13 4.5.2. Unicast and Multicast ............................. 13
4.9.2. Hybrid Mode ....................................... 13 4.5.3. Key Freshness ..................................... 14
5. Summary of Requirements ..................................... 13 4.6. Performance ............................................ 14
6. Additional security implications ............................ 14 4.7. Confidentiality......................................... 14
7. Issues for Further Discussion ............................... 15 4.8. Protection against packet delay attacks ................ 15
8. Security Considerations ..................................... 15 4.9. Combining Secured with Unsecured Nodes ................. 15
9. IANA Considerations ......................................... 15 4.9.1. Secure Mode ....................................... 15
10. Acknowledgments ............................................ 15 4.9.2. Hybrid Mode ....................................... 16
11. References ................................................. 15 5. Summary of Requirements ..................................... 16
11.1. Normative References .................................. 15 6. Additional security implications ............................ 18
11.2. Informative References ................................ 16 6.1. Security and on-the-fly Timestamping ................... 18
6.2. Security and Two-Step Timestamping ..................... 18
6.3. Intermediate Clocks .................................... 19
6.4. The Effect of External Security Protocols on Time
Synchronization ............................................. 19
6.5. External Security Services Requiring Time Synchronization20
7. Issues for Further Discussion ............................... 20
8. Security Considerations ..................................... 20
9. IANA Considerations ......................................... 20
10. Acknowledgments ............................................ 20
11. References ................................................. 21
11.1. Normative References .................................. 21
11.2. Informative References ................................ 21
1. Introduction 1. Introduction
As time synchronization protocols are becoming increasingly common As time synchronization protocols are becoming increasingly common
and widely deployed, concern about the resulting exposure to various and widely deployed, concern about the resulting exposure to various
security threats is increasing. If a time synchronization protocol is security threats is increasing. If a time synchronization protocol is
compromised, the applications it serves are prone to a range of compromised, the applications it serves are prone to a range of
possible attacks including Denial-of-Service or incorrect behavior. possible attacks including Denial-of-Service or incorrect behavior.
This document focuses on the security aspects of the Precision Time This document focuses on the security aspects of the Precision Time
skipping to change at page 5, line 14 skipping to change at page 5, line 27
Secured clock A clock that supports a security mechanism that Secured clock A clock that supports a security mechanism that
complies to the requirements in this document complies to the requirements in this document
TC Transparent Clock TC Transparent Clock
Unsecured clock A clock that does not support a security mechanism Unsecured clock A clock that does not support a security mechanism
according to the requirments in this document according to the requirments in this document
3. Security Threats 3. Security Threats
The following section defines the security threats that are discussed This section discusses the possible attacker types, and analyzes
in subsequent sections. various attacks against time synchronization protocols.
3.1. Packet interception and manipulation The literature is rich with security threats of time synchronization
protocols, e.g., [Traps], [AutoKey], [TM], [SecPTP], and [SecSen].
The threat analysis in this document is mostly based on [TM].
3.1. Threat Model
A time synchronization protocol can be attacked by various types of
attackers.
The analysis in this documents classifies attackers according to 2
criteria, as described in 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 synchronization protocol is secured
either by an encryption or an authentication mechanism.
Internal attackers either have access to a trusted segment of the
network, or possess the encryption or authentication keys. External
attackers, on the other hand, do not have the keys, and are exposed
only to the encrypted or authenticated traffic. 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.
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, while a traffic injector
cannot intercept legitimate packets, but can record them, replay old
messages, and generate its own traffic.
3.2. Threat Analysis
3.2.1. Packet Interception and Manipulation
A packet interception and manipulation attack results when a Man-In- A packet interception and manipulation attack results when a Man-In-
The-Middle (MITM) attacker intercepts timing protocol packets, alters The-Middle (MITM) attacker intercepts timing protocol packets, alters
them and relays them to their destination, allowing the attacker to them and relays them to their destination, allowing the attacker to
maliciously tamper with the protocol. This can result in a situation maliciously tamper with the protocol. This can result in a situation
where the time protocol is apparently operational but providing where the time protocol is apparently operational but providing
intentionally inaccurate information. intentionally inaccurate information.
3.2. Spoofing 3.2.2. Spoofing
In spoofing, an attacker masquerades as a legitimate node in the In spoofing, an attacker masquerades as a legitimate node in the
network. For example, an attacker can impersonate the master, network. For example, an attacker can impersonate the master,
allowing malicious distribution of false timing information. As with allowing malicious distribution of false timing information. As with
packet interception and manipulation, this can result in a situation packet interception and manipulation, this can result in a situation
where the time protocol is apparently operational but providing where the time protocol is apparently operational but providing
intentionally inaccurate information. intentionally inaccurate information.
3.3. Replay attack 3.2.3. Replay Attack
In a replay attack, an attacker records protocol packets and replays In a replay attack, an attacker records protocol packets and replays
them at a later time. This can also result in a situation where the them at a later time. This can also result in a situation where the
time protocol is apparently operational but providing intentionally time protocol is apparently operational but providing intentionally
inaccurate information. inaccurate information.
3.4. Rogue master attack 3.2.4. Rogue Master Attack
In a rogue master attack, an attacker causes other nodes in the In a rogue master attack, an attacker causes other nodes in the
network to believe it is a legitimate master. As opposed to the network to believe it is a legitimate master. As opposed to the
spoofing attack, in the Rouge Master attack the attacker does not spoofing attack, in the Rouge Master attack the attacker does not
fake its identity, but rather manipulates the master election fake its identity, but rather manipulates the master election
process. For example, in PTP, an attacker can manipulate the Best process. For example, in PTP, an attacker can manipulate the Best
Master Clock Algorithm (BMCA), and cause other nodes in the network Master Clock Algorithm (BMCA), and cause other nodes in the network
to believe it is the most eligible candidate to be a grandmaster. to believe it is the most eligible candidate to be a grandmaster.
3.5. Packet Interception and Removal 3.2.5. Packet Interception and Removal
A packet interception and removal attack results when a Man-In-The- A packet interception and removal attack results when a Man-In-The-
Middle attacker intercepts and drops protocol packets, preventing the Middle attacker intercepts and drops protocol packets, preventing the
destination node from receiving the timing information. destination node from receiving the timing information.
3.6. Packet delay manipulation 3.2.6. Packet Delay Manipulation
In a packet delay manipulation scenario, a Man-In-The-Middle attacker In a packet delay manipulation scenario, a Man-In-The-Middle attacker
intercepts protocol packets, and relays them to their destination intercepts protocol packets, and relays them to their destination
after adding a maliciously computed delay. after adding a maliciously computed delay.
3.7. Cryptographic performance attacks 3.2.7. Cryptographic Performance Attacks
In cryptographic performance attacks, an attacker transmits fake In cryptographic performance attacks, an attacker transmits fake
protocol packet, causing high utilization of the cryptographic engine protocol packet, causing high utilization of the cryptographic engine
at the receiver, which attempts to verify the integrity of these fake at the receiver, which attempts to verify the integrity of these fake
packets. packets.
3.8. DoS attacks 3.2.8. L2/L3 DoS Attacks
There are many possible Layer 2 and Layer 3 Denial of Service There are many possible Layer 2 and Layer 3 Denial of Service
attacks. As the target's availability is compromised, the timing attacks. As the target's availability is compromised, the timing
protocol is affected accordingly. protocol is affected accordingly.
3.9. Time source spoofing (e.g. GPS fraud) 3.2.9. Master Time Source Spoofing (e.g. GPS fraud)
In time source spoofing, an attacker spoofs the accurate time source In time source spoofing, an attacker spoofs the accurate time source
of the master. For example, if the master uses a GPS based clock as of the master. For example, if the master uses a GPS based clock as
its reference source, an attacker can spoof the GPS satellites, its reference source, an attacker can spoof the GPS satellites,
causing the master to use a false reference time. causing the master to use a false reference time.
3.3. Threat Analysis Summary
The two key factors to a threat analysis are the severity and the
likelihood of each of the analyzed attacks.
Table 1 summarizes the security attacks presented in 3.2. For each
attack, the table specifies its impact, and its applicability to each
of the attacker types presented in 3.1.
The Impact column provides an intuition to the severity of each
attack, and the relevant Attacker Type columns provide an intuition
about the 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 3 values:
o False time - slaves align to a false time or frequency value due
to the attack.
o Accuracy degradation - the attack yields a degradation in the
slave accuracy, but does not completely compromise the slaves'
time and frequency.
o DoS - the attack causes a denial of service to the attacked node,
whose impact is not restricted to the time synchronization
protocol.
The Attacket Type columns refer to the 4 possible combinations of the
attacker types defined in 3.1.
+-----------------------------+-------------------++-------------------+
| Attack | Impact || Attacker Type |
| +-----+--------+----++---------+---------+
| |False|Accuracy| ||Internal | Extenal |
| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|
+-----------------------------+-----+--------+----++----+----+----+----+
|Interception and manipulation| + | | || + | | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Spoofing | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Replay attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Rogue master attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Interception and Removal | | + | || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Packet delay manipulation | + | | || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Crypt. performance attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|DoS attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|Master Time source spoofing | + | | || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
Table 1 Threat Analysis - Summary
4. Security Requirements 4. Security Requirements
4.1. Clock Identity Authentication 4.1. Clock Identity Authentication
Requirement Requirement
The security mechanism MUST provide a means for each clock to The security mechanism MUST provide a means for each clock to
authenticate the sender of a protocol packet. authenticate the sender of a protocol packet.
Discussion Discussion
skipping to change at page 9, line 36 skipping to change at page 12, line 4
A security mechanism for PTP MUST support hop-by-hop integrity A security mechanism for PTP MUST support hop-by-hop integrity
protection. protection.
Requirement Requirement
A security mechanism for PTP SHOULD support end-to-end integrity A security mechanism for PTP SHOULD support end-to-end integrity
protection. protection.
Discussion Discussion
Specifically in PTP, when protocol packets are subject to
Specifically in PTP, when protocol packets are subjected to
modification by TCs, the integrity protection can be enforced in one modification by TCs, the integrity protection can be enforced in one
of two approaches, end-to-end or hop-by-hop. of two approaches, end-to-end or hop-by-hop.
4.2.1.1. Hop by Hop Integrity Protection 4.2.1.1. Hop by Hop Integrity Protection
Each hop that needs to modify a protocol packet: Each hop that needs to modify a protocol packet:
o Verifies its integrity. o Verifies its integrity.
o Modifies the packet, i.e., modifies the correctionField. o Modifies the packet, i.e., modifies the correctionField.
skipping to change at page 10, line 30 skipping to change at page 12, line 44
protection mechanism is used specifically for the correctionField. protection mechanism is used specifically for the correctionField.
The end-to-end approach limits the TC's impact to 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- alone, while the rest of the protocol packet is protected on an end-
to-end basis. to-end basis.
4.3. Availability 4.3. Availability
Requirement Requirement
The security mechanism MUST be resistant to DoS attacks from an The security mechanism MUST protect the time synchronization protocol
external attacker. from DoS attacks by external attackers.
Discussion Discussion
This requirement is attained by clock authentication, as described in The protocol availability can be compromised by several different
4.1. . attacks. An attacker can inject protocol messages to implement the
spoofing attack (3.2.2. ) or the rogue master attack (3.2.4. ),
causing denial of service to the attackee. An authentication
mechanism (4.1. ) limits these attacks strictly to internal
attackers, and thus prevents external attackers from performing them.
DoS attacks at lower layers of the protocol stack (3.2.8. ) can still
be implemented by external attackers even in the presence of an
authentication mechanism.
4.4. Replay Protection 4.4. Replay Protection
Requirement Requirement
Protocol messages MUST be resistant to replay attacks. Protocol messages MUST be resistant to replay attacks.
4.5. Cryptographic Keys & Security Associations 4.5. Cryptographic Keys & Security Associations
4.5.1. Security Association 4.5.1. Security Association
skipping to change at page 11, line 11 skipping to change at page 13, line 33
Requirement Requirement
The security protocol MUST support an association protocol where: The security protocol MUST support an association protocol where:
o Two or more clocks authenticate each other. o Two or more clocks authenticate each other.
o The clocks generate and agree on a cryptographic session key. o The clocks generate and agree on a cryptographic session key.
Discussion Discussion
The security requirements in 4.1. and 4 .2. require usage of The security requirements in 4.1. and 4.2. require usage of
cryptographich mechanisms, deploying cryptographic keys. A security cryptographich mechanisms, deploying cryptographic keys. A security
association is an essential building block in these mechanisms. association is an essential building block in these mechanisms.
4.5.2. Unicast and Multicast 4.5.2. Unicast and Multicast
Requirement Requirement
The security mechanism MUST support security association protocols The security mechanism MUST support security association protocols
for unicast and for multicast associations. for unicast and for multicast associations.
skipping to change at page 12, line 11 skipping to change at page 14, line 36
The mechanism SHOULD be relatively lightweight, as client The mechanism SHOULD be relatively lightweight, as client
restrictions often dictate a low processing and memory footprint, and restrictions often dictate a low processing and memory footprint, and
because the server may have extensive fan-out. because the server may have extensive fan-out.
Requirement Requirement
The mechanism also SHOULD not require excessive storage of client The mechanism also SHOULD not require excessive storage of client
state in the master, nor significantly increase bandwidth state in the master, nor significantly increase bandwidth
consumption. consumption.
Discussion
Note that the performance requirements refer to a time-
synchronization-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.
4.7. Confidentiality 4.7. Confidentiality
Requirement Requirement
The security mechanism MAY provide confidentiality protection of the The security mechanism MAY provide confidentiality protection of the
protocol packets. protocol packets.
Discussion Discussion
In the context of time synchronization, confidentiality is typically In the context of time synchronization, confidentiality is typically
of low importance, since timing information is typically not of low importance, since timing information is typically not
considered secret information. considered secret information.
Confidentiality can play an important role when service providers Confidentiality can play an important role when service providers
skipping to change at page 13, line 13 skipping to change at page 15, line 50
to interoperate with legacy equipment without the security features. to interoperate with legacy equipment without the security features.
4.9.1. Secure Mode 4.9.1. Secure Mode
Requirement Requirement
The security mechanism MUST support a secure mode, where only secured The security mechanism MUST support a secure mode, where only secured
clocks are permitted to take part in the synchronization protocol. A clocks are permitted to take part in the synchronization protocol. A
protocol packet received from an unsecured clock MUST be discarded. protocol packet received from an unsecured clock MUST be discarded.
Discussion
While the requirement in this subsection is a bit similar to the one
in 4.1. , it explicitly defines the secure mode, as opposed to the
hybrid mode presented in the next subsection.
4.9.2. Hybrid Mode 4.9.2. Hybrid Mode
Requirement Requirement
The security protocol MAY support a hybrid mode, where both secured The security protocol MAY support a hybrid mode, where both secured
and unsecured clocks are permitted to take part in the protocol. and unsecured clocks are permitted to take part in the protocol.
A master in the hybrid mode MUST be a secured clock. Discussion
A secured slave in the hybrid mode MUST discard all protocol packets The hybrid mode allows both secured and unsecured clocks to take part
received from unsecured clocks. in the synchronization protocol.
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.
Discussion Discussion
The hybrid mode allows both secured and unsecured clocks to take part This requirement ensures that the existence of unsecured clocks does
in the synchronization protocol. It is essential that the existence not compromise the security provided to secured clocks. Hence,
of unsecured clocks does not compromise the security provided to secured slaves only "trust" protocol packets received from a secured
secured clocks. Hence, secured slaves only "trust" protocol packets clock. An unsecured clock can receive protocol packets from either
received from a secured clock. An unsecured clock can receive secured clocks, or unsecured clocks.
protocol packets from either secured clocks, or unsecured clocks.
Note that the security scheme in [NTPv4] with [AutoKey] does not
satisfy this requirement, since nodes prefer the server with the best
clock, and 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.
5. Summary of Requirements 5. Summary of Requirements
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| Section | Requirement | Type | | Section | Requirement | Type |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.1. | Authentication of sender. | MUST | | 4.1. | Authentication of sender. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Authentication of master. | MUST | | | Authentication of master. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
skipping to change at page 14, line 37 skipping to change at page 18, line 6
| | Performance: storage, bandwidth. | MUST | | | Performance: storage, bandwidth. | MUST |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.7. | Confidentiality protection. | MAY | | 4.7. | Confidentiality protection. | MAY |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.8. | Protection against delay attacks. | MAY | | 4.8. | Protection against delay attacks. | MAY |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.9. | Secure mode. | MUST | | 4.9. | Secure mode. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Hybrid mode. | MAY | | | Hybrid mode. | MAY |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
Table 1 Summary of Security Requirements Table 2 Summary of Security Requirements
6. Additional security implications 6. Additional security implications
This section will discuss additional security implications as This section discusses additional implications of the interaction
outlined in the questions below. Contributions are welcome and between time synchronization protocols and security mechanisms.
encouraged.
o What external security practices impact the security and This section refers to time synchronization security mechanisms, as
performance of time keeping? (and what can be done to mitigate well as to "external" security mechanisms, i.e., security mechanisms
these impacts?) that are not strictly related to the time synchronization protocol.
o What are the security impacts of time synchronization protocol 6.1. Security and on-the-fly Timestamping
practices? (e.g. on-the-fly modification of timestamps)
o What are the dependencies between other security services and time Time synchronization protocols often require protocol packets to be
synchronization? modified during transmission and reception. Both NTP and PTP in one-
step mode require clocks to modify protocol packets with the time of
transmission or reception.
7. Issues for Further Discussion In the presence of a security mechanism, whether encryption or
integrity protection:
This section will discuss additional issues as identified below. o During transmission the security protocol must be applied after
integrating the timestamp into the packet.
o During reception, the encryption or integrity check must be
performed before modifying the packet with the time of reception.
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, in some cases it may introduce non-
deterministic latency that causes accuracy degradation. These
performance aspects have been analyzed in the literature, e.g., in
[1588IPsec] and [Tunnel].
6.2. Security and Two-Step Timestamping
PTP supports a two-step mode of operation, where the time of
transmission and the time of reception of protocol packets are
measured without modifying the packets. As opposed to one-step mode,
two step timestamping can be performed at the physical interface even
in the presence of a security mechanism.
Note that if an encryption mechanism 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 synchronization packets.
6.3. Intermediate Clocks
A time synchronization 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.
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, all
intermediate nodes must be exposed to the security key since they
must be able to send time information to the slaves, or to modify
time information sent through them.
This inhehrent property of using intermediate clocks increases the
system's exposure to internal threats, as there is a large number of
nodes that are exposed to the security keys.
6.4. The Effect of External Security Protocols on Time Synchronization
Time synchronization 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. All traffic between these two nodes is secured by IPsec,
including the time synchronization protocol traffic. This use-case is
thoroughly discussed in [IPsecSync].
Another typical example is the usage of MACsec encryption in L2
networks that deploy time synchronization [AvbAssum].
The usage of external security mechanisms may affect time
synchronization protocols as follows:
o Timestamping accuracy can be affected, as described in 6.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 sent over the
underlying network without modification, and thus cannot enjoy the
improved accuracy provided by intermediate clock nodes.
6.5. External Security Services Requiring Time Synchronization
Certificate validation requires the sender and receiver to be time
synchronized. Thus, synchronization is required for establishing
security protocols such as IKEv2 and TLS.
An even stronger interdependence between a time synchronization
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.
7. Issues for Further Discussion
o The key distribution is outside the scope of this document. o The key distribution is outside the scope of this document.
Although this is a cardinal element in any security system, it is Although this is a cardinal element in any security system, it is
not a security requirement, and is thus not described here. not a security requirement, and is thus not described here.
8. Security Considerations 8. Security Considerations
The security considerations of network timing protocols are presented The security considerations of network timing protocols are presented
throughout this document. throughout this document.
skipping to change at page 16, line 5 skipping to change at page 21, line 20
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[NTPv4] Mills, D., Delaware, U., Martin, J., Burbank, J., [NTPv4] Mills, D., Delaware, U., Martin, J., Burbank, J.,
Kasch, W., "Network Time Protocol Version 4: Protocol Kasch, W., "Network Time Protocol Version 4: Protocol
and Algorithms Specification", RFC 5905, June 2010. and Algorithms Specification", RFC 5905, June 2010.
[AutoKey] Haberman, B., Mills, D., "Network Time Protocol [AutoKey] Haberman, B., Mills, D., "Network Time Protocol
Version 4: Autokey Specification", RFC 5906, June Version 4: Autokey Specification", RFC 5906, June
2010. 2010.
11.2. Informative References
[IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588
IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems
Version 2", IEEE Standard, 2008.
[Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R.,
"Traps and pitfalls in secure clock synchronization" "Traps and pitfalls in secure clock synchronization"
in Proceedings of 2007 International Symposium for in Proceedings of 2007 International Symposium for
Precision Clock Synchronization for Measurement, Precision Clock Synchronization for Measurement,
Control and Communication, ISPCS 2007, pp. 18-24, Control and Communication, ISPCS 2007, pp. 18-24,
2007. 2007.
11.2. Informative References [TM] T. Mizrahi, "Time synchronization security using IPsec
and MACsec", ISPCS 2011, pp. 38-43, 2011.
[IEEE 1588] IEEE TC 9 Test and Measurement Society 2000, "1588 [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the
IEEE Standard for a Precision Clock Synchronization precise time protocol (short paper)," 8th
Protocol for Networked Measurement and Control Systems International Conference on Information and
Version 2", IEEE Standard, 2008. Communication Security (ICICS 2006), pp. 50-59, 2006.
[SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava,
"Secure Time Synchronization in Sensor Networks", ACM
Trans. Info. and Sys. Sec., Volume 11, Issue 4, July
2008.
[AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions",
IEEE 802.1 AVB Plenary, work in progress, May 2012.
[IPsecSync] Y. Xu, "IPsec security for packet based
synchronization", IETF, draft-xu-tictoc-ipsec-
security-for-synchronization (work in progress), 2011.
[3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved
Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in
progress), 2011.
[1588IPsec] A. Treytl, 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, 2010.
[Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure
tunneling of high precision clock synchronisation
protocols and other timestamped data", in Proceedings
of the 8th IEEE International Workshop on Factory
Communication Systems (WFCS), vol. ISBN 978-1-4244-
5461-7, pp. 303-313, 2010.
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam, 20692 Israel Yokneam, 20692 Israel
Email: talmi@marvell.com Email: talmi@marvell.com
 End of changes. 36 change blocks. 
92 lines changed or deleted 367 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/