draft-ietf-tictoc-security-requirements-09.txt   draft-ietf-tictoc-security-requirements-10.txt 
TICTOC Working Group Tal Mizrahi TICTOC Working Group Tal Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Intended status: Informational
Expires: December 2014 June 16, 2014 Expires: January 2015 July 2, 2014
Security Requirements of Time Protocols Security Requirements of Time Protocols
in Packet Switched Networks in Packet Switched Networks
draft-ietf-tictoc-security-requirements-09.txt draft-ietf-tictoc-security-requirements-10.txt
Abstract Abstract
As time and frequency distribution protocols are becoming As time and frequency distribution protocols are becoming
increasingly common and widely deployed, concern about their exposure increasingly common and widely deployed, concern about their exposure
to various security threats is increasing. This document defines a to various security threats is increasing. This document defines a
set of security requirements for time protocols, focusing on the set of security requirements for time protocols, focusing on the
Precision Time Protocol (PTP) and the Network Time Protocol (NTP). Precision Time Protocol (PTP) and the Network Time Protocol (NTP).
This document also discusses the security impacts of time protocol This document also discusses the security impacts of time protocol
practices, the performance implications of external security practices, the 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 December 16, 2014. This Internet-Draft will expire on January 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 26 skipping to change at page 2, line 26
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 ............................ 5 2. Conventions Used in this Document ............................ 5
2.1. Terminology ............................................. 5 2.1. Terminology ............................................. 5
2.2. Abbreviations ........................................... 5 2.2. Abbreviations ........................................... 5
2.3. Common Terminology for PTP and NTP ...................... 5 2.3. Common Terminology for PTP and NTP ...................... 6
2.4. Terms used in this Document ............................. 6 2.4. Terms used in this Document ............................. 6
3. Security Threats ............................................. 7 3. Security Threats ............................................. 7
3.1. Threat Model ............................................ 7 3.1. Threat Model ............................................ 7
3.1.1. Internal vs. External Attackers .................... 7 3.1.1. Internal vs. External Attackers .................... 7
3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 8 3.1.2. Man in the Middle (MITM) vs. Packet Injector ....... 8
3.2. Threat Analysis.......................................... 8 3.2. Threat Analysis.......................................... 8
3.2.1. Packet Manipulation ................................ 8 3.2.1. Packet Manipulation ................................ 8
3.2.2. Spoofing ........................................... 8 3.2.2. Spoofing ........................................... 9
3.2.3. Replay Attack ...................................... 9 3.2.3. Replay Attack ...................................... 9
3.2.4. Rogue Master Attack ................................ 9 3.2.4. Rogue Master Attack ................................ 9
3.2.5. Packet Interception and Removal .................... 9 3.2.5. Packet Interception and Removal ................... 10
3.2.6. Packet Delay Manipulation .......................... 9 3.2.6. Packet Delay Manipulation ......................... 10
3.2.7. L2/L3 DoS Attacks .................................. 9 3.2.7. L2/L3 DoS Attacks ................................. 10
3.2.8. Cryptographic Performance Attacks ................. 10 3.2.8. Cryptographic Performance Attacks ................. 10
3.2.9. DoS Attacks against the Time Protocol ............. 10 3.2.9. DoS Attacks against the Time Protocol ............. 10
3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 10 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) . 11
3.3. Threat Analysis Summary ................................ 10 3.3. Threat Analysis Summary ................................ 11
4. Requirement Levels .......................................... 12 4. Requirement Levels .......................................... 13
5. Security Requirements ....................................... 13 5. Security Requirements ....................................... 13
5.1. Clock Identity Authentication and Authorization ........ 13 5.1. Clock Identity Authentication and Authorization ........ 14
5.1.1. Authentication and Authorization of Masters ....... 14 5.1.1. Authentication and Authorization of Masters ....... 15
5.1.2. Recursive Authentication and Authorization of Masters 5.1.2. Recursive Authentication and Authorization of Masters
(Chain of Trust) ......................................... 15 (Chain of Trust) ......................................... 15
5.1.3. Authentication and Authorization of Slaves ........ 15 5.1.3. Authentication and Authorization of Slaves ........ 16
5.1.4. PTP: Authentication and Authorization of P2P TCs by the 5.1.4. PTP: Authentication and Authorization of P2P TCs by the
Master ................................................... 16 Master ................................................... 17
5.1.5. PTP: Authentication and Authorization of Control 5.1.5. PTP: Authentication and Authorization of Control
Messages ................................................. 17 Messages ................................................. 18
5.2. Protocol Packet Integrity .............................. 18 5.2. Protocol Packet Integrity .............................. 19
5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19
5.2.1.1. Hop-by-Hop Integrity Protection .............. 19 5.2.1.1. Hop-by-Hop Integrity Protection .............. 19
5.2.1.2. End-to-End Integrity Protection .............. 19 5.2.1.2. End-to-End Integrity Protection .............. 20
5.3. Spoofing Prevention .................................... 20 5.3. Spoofing Prevention .................................... 20
5.4. Availability ........................................... 20 5.4. Availability ........................................... 21
5.5. Replay Protection ...................................... 21 5.5. Replay Protection ...................................... 22
5.6. Cryptographic Keys and Security Associations ........... 22 5.6. Cryptographic Keys and Security Associations ........... 22
5.6.1. Key Freshness ..................................... 22 5.6.1. Key Freshness ..................................... 22
5.6.2. Security Association .............................. 22 5.6.2. Security Association .............................. 23
5.6.3. Unicast and Multicast Associations ................ 23 5.6.3. Unicast and Multicast Associations ................ 23
5.7. Performance ............................................ 23 5.7. Performance ............................................ 24
5.8. Confidentiality......................................... 24 5.8. Confidentiality......................................... 25
5.9. Protection against Packet Delay and Interception Attacks 25 5.9. Protection against Packet Delay and Interception Attacks 25
5.10. Combining Secured with Unsecured Nodes ................ 25 5.10. Combining Secured with Unsecured Nodes ................ 26
5.10.1. Secure Mode ...................................... 26 5.10.1. Secure Mode ...................................... 26
5.10.2. Hybrid Mode ...................................... 26 5.10.2. Hybrid Mode ...................................... 27
6. Summary of Requirements ..................................... 27 6. Summary of Requirements ..................................... 28
7. Additional security implications ............................ 29 7. Additional security implications ............................ 30
7.1. Security and on-the-fly Timestamping ................... 29 7.1. Security and on-the-fly Timestamping ................... 30
7.2. PTP: Security and Two-Step Timestamping ................ 29 7.2. PTP: Security and Two-Step Timestamping ................ 30
7.3. Intermediate Clocks .................................... 30 7.3. Intermediate Clocks .................................... 31
7.4. External Security Protocols and Time Protocols.......... 30 7.4. External Security Protocols and Time Protocols.......... 31
7.5. External Security Services Requiring Time .............. 31 7.5. External Security Services Requiring Time .............. 32
7.5.1. Timestamped Certificates .......................... 31 7.5.1. Timestamped Certificates .......................... 32
7.5.2. Time Changes and Replay Attacks ................... 31 7.5.2. Time Changes and Replay Attacks ................... 32
8. Issues for Further Discussion ............................... 31 8. Issues for Further Discussion ............................... 32
9. Security Considerations ..................................... 32 9. Security Considerations ..................................... 33
10. IANA Considerations......................................... 32 10. IANA Considerations......................................... 33
11. Acknowledgments ............................................ 32 11. Acknowledgments ............................................ 33
12. References ................................................. 32 12. References ................................................. 33
12.1. Normative References .................................. 32 12.1. Normative References .................................. 33
12.2. Informative References ................................ 32 12.2. Informative References ................................ 33
13. Contributing Authors ....................................... 34 13. Contributing Authors ....................................... 35
1. Introduction 1. Introduction
As time protocols are becoming increasingly common and widely As time protocols are becoming increasingly common and widely
deployed, concern about the resulting exposure to various security deployed, concern about the resulting exposure to various security
threats is increasing. If a time protocol is compromised, the threats is increasing. If a time protocol is compromised, the
applications it serves are prone to a range of possible attacks applications it serves are prone to a range of possible attacks
including Denial-of-Service (DoS) or incorrect behavior. including Denial-of-Service (DoS) or incorrect behavior.
This document focuses on the security aspects of the Precision Time This document discusses the security aspects of time distribution
Protocol (PTP) [IEEE1588] and the Network Time Protocol [NTPv4]. The protocols in packet networks, and focuses on the two most common
Network Time Protocol was defined with an inherent security protocol, protocols, the Network Time Protocol [NTPv4] and the Precision Time
defined in [NTPv4] and in [AutoKey]. [IEEE1588] includes an Protocol (PTP) [IEEE1588]. Note, that although PTP was not defined by
experimental security protocol, defined in Annex K of the standard, the IETF, it is one of the two most common time protocols and hence
but this Annex was never formalized into a fully defined security it is included in the discussion.
protocol.
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 While NTP includes an inherent security protocol, the absence of a
standard security solution for PTP undoubtedly contributed to the standard security solution for PTP undoubtedly contributed to the
wide deployment of unsecured time synchronization solutions. However, wide deployment of unsecured time synchronization solutions. However,
in some cases security mechanisms may not be strictly necessary, in some cases security mechanisms may not be strictly necessary,
e.g., due to other security practices in place, or due to the e.g., due to other security practices in place, or due to the
architecture of the network. A time synchronization security architecture of the network. A time synchronization security
solution, much like any security solution, is comprised of various solution, much like any security solution, is comprised of various
building blocks, and must be carefully tailored for the specific building blocks, and must be carefully tailored for the specific
system it is deployed in. Based on a system-specific threat system it is deployed in. Based on a system-specific threat
skipping to change at page 7, line 45 skipping to change at page 8, line 10
Internal attackers either have access to a trusted segment of the Internal attackers either have access to a trusted segment of the
network, or possess the encryption or authentication keys. An network, or possess the encryption or authentication keys. An
internal attack can also be performed by exploiting vulnerabilities internal attack can also be performed by exploiting vulnerabilities
in devices; for example, by installing malware, or obtaining in devices; for example, by installing malware, or obtaining
credentials to reconfigure the device. Thus, an internal attacker can credentials to reconfigure the device. Thus, an internal attacker can
maliciously tamper with legitimate traffic in the network, as well as maliciously tamper with legitimate traffic in the network, as well as
generate its own traffic and make it appear legitimate to its generate its own traffic and make it appear legitimate to its
attacked nodes. 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 ommitting messages, or by malicious behavior. This document
focuses on nodes that demonstrate malicous behavior.
External attackers, on the other hand, do not have the keys, and have External attackers, on the other hand, do not have the keys, and have
access only to the encrypted or authenticated traffic. access only to the encrypted or authenticated traffic.
Obviously, in the absence of a security mechanism there is no Obviously, in the absence of a security mechanism there is no
distinction between internal and external attackers, since all distinction between internal and external attackers, since all
attackers are internal in practice. attackers are internal in practice.
3.1.2. Man in the Middle (MITM) vs. Packet Injector 3.1.2. Man in the Middle (MITM) vs. Packet Injector
MITM attackers are located in a position that allows interception and MITM attackers are located in a position that allows interception and
skipping to change at page 9, line 49 skipping to change at page 10, line 26
strategies; the added delay can be constant, jittered, or slowly strategies; the added delay can be constant, jittered, or slowly
wandering. Each of these strategies has a different impact, but they wandering. Each of these strategies has a different impact, but they
all effectively manipulate the attacked clock. all effectively manipulate the attacked clock.
Note that the victim still receives one copy of each packet, contrary 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 to the replay attack, where some or all of the packets may be
received by the victim more than once. received by the victim more than once.
3.2.7. L2/L3 DoS Attacks 3.2.7. L2/L3 DoS Attacks
There are many possible Layer 2 and Layer 3 DoS attacks. As the There are many possible Layer 2 and Layer 3 DoS attacks, e.g., IP
target's availability is compromised, the timing protocol is affected spoofing, ARP spoofing [Hack], MAC flooding [Anatomy], and many
accordingly. others. As the target's availability is compromised, the timing
protocol is affected accordingly.
3.2.8. Cryptographic Performance Attacks 3.2.8. Cryptographic Performance Attacks
In cryptographic performance attacks, an attacker transmits fake In cryptographic performance attacks, an attacker transmits fake
protocol packets, causing high utilization of the cryptographic protocol packets, causing high utilization of the cryptographic
engine at the receiver, which attempts to verify the integrity of engine at the receiver, which attempts to verify the integrity of
these fake packets. these fake packets.
This DoS attack is applicable to all encryption and authentication This DoS attack is applicable to all encryption and authentication
protocols. However, when the time protocol uses a dedicated security protocols. However, when the time protocol uses a dedicated security
mechanism implemented in a dedicated cryptographic engine, this mechanism implemented in a dedicated cryptographic engine, this
attack can be applied to cause DoS specifically to the time protocol attack can be applied to cause DoS specifically to the time protocol.
3.2.9. DoS Attacks against the Time Protocol 3.2.9. DoS Attacks against the Time Protocol
An attacker can attack a clock by sending an excessive number of time An attacker can attack a clock by sending an excessive number of time
protocol packets, thus degrading the victim's performance. This protocol packets, thus degrading the victim's performance. This
attack can be implemented, for example, using the attacks described attack can be implemented, for example, using the attacks described
in Section 3.2.2. and Section 3.2.4. in Section 3.2.2. and Section 3.2.4.
3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud) 3.2.10. Grandmaster Time Source Attack (e.g., GPS fraud)
skipping to change at page 11, line 31 skipping to change at page 12, line 13
time and frequency. time and frequency.
o False time - slaves align to a false time or frequency value due 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 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, it may cause DoS to other applications that rely on accurate
time. However, for the purpose of the analysis in this section we time. However, for the purpose of the analysis in this section we
distinguish this implication from 'DoS', which refers to a DoS distinguish this implication from 'DoS', which refers to a DoS
attack that is not necessarily aimed at the time protocol. attack that is not necessarily aimed at the time protocol.
All attacks that have a '+' for 'False Time' implicitly have a '+' All attacks that have a '+' for 'False Time' implicitly have a '+'
for 'Accuracy Degradation'. 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 columns refer to the 4 possible combinations of the The Attacker Type columns refer to the 4 possible combinations of the
attacker types defined in Section 3.1. attacker types defined in Section 3.1.
+-----------------------------+-------------------++-------------------+ +-----------------------------+-------------------++-------------------+
| Attack | Impact || Attacker Type | | Attack | Impact || Attacker Type |
| +-----+--------+----++---------+---------+ | +-----+--------+----++---------+---------+
| |False|Accuracy| ||Internal |External | | |False|Accuracy| ||Internal |External |
| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.| | |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|
+-----------------------------+-----+--------+----++----+----+----+----+ +-----------------------------+-----+--------+----++----+----+----+----+
skipping to change at page 14, line 4 skipping to change at page 14, line 31
The requirement level of these requirements is 'MUST' since in the The requirement level of these requirements is 'MUST' since in the
absence of these requirements the protocol is exposed to attacks that absence of these requirements the protocol is exposed to attacks that
are easy to implement and have a high impact. are easy to implement and have a high impact.
Discussion Discussion
Authentication refers to verifying the identity of the peer clock. Authentication refers to verifying the identity of the peer clock.
Authorization, on the other hand, refers to verifying that the peer Authorization, on the other hand, refers to verifying that the peer
clock is permitted to play the role that it plays in the protocol. 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 For example, some nodes may be permitted to be masters, while other
nodes are only permitted to be slaves or TCs. nodes are only permitted to be slaves or TCs.
Authentication is typically implemented by means of a cryptographic
signature, allowing to verify the identity of the sender.
Authorization requires clocks to maintain a list of authorized Authorization requires clocks to maintain a list of authorized
clocks, or a "black list" of clocks that should be denied service or clocks, or a "black list" of clocks that should be denied service or
revoked. revoked.
It is noted that while the security mechanism is required to provide It is noted that while the security mechanism is required to provide
an authorization mechanism, the deployment of such a mechanism an authorization mechanism, the deployment of such a mechanism
depends on the nature of the network. For example, a network that 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 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 are equally permitted to be a master. In such a network an
authorization mechanism may not be necessary. authorization mechanism may not be necessary.
skipping to change at page 19, line 7 skipping to change at page 19, line 35
are easy to implement and have high impact. are easy to implement and have high impact.
Discussion Discussion
While Section 5.1. refers to ensuring the identity an authorization While Section 5.1. refers to ensuring the identity an authorization
of the source of a protocol packet, this subsection refers to of the source of a protocol packet, this subsection refers to
ensuring that the packet arrived intact. The integrity protection ensuring that the packet arrived intact. The integrity protection
mechanism ensures the authenticity and completeness of data from the mechanism ensures the authenticity and completeness of data from the
data originator. data originator.
Integrity protection is typically impelmented 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 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection
Specifically in PTP, when protocol packets are subject to Specifically in PTP, when protocol packets are subject 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.
5.2.1.1. Hop-by-Hop Integrity Protection 5.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:
skipping to change at page 23, line 5 skipping to change at page 23, line 35
The requirement level of this requirement is 'SHOULD' since it may be The requirement level of this requirement is 'SHOULD' since it may be
expensive in terms of performance, especially in low-cost clocks. expensive in terms of performance, especially in low-cost clocks.
Discussion Discussion
The security requirements in Section 5.1. and Section 5.2. require The security requirements in Section 5.1. and Section 5.2. require
usage of cryptographic mechanisms, deploying cryptographic keys. A usage of cryptographic mechanisms, deploying cryptographic keys. A
security association is an important building block in these security association is an important building block in these
mechanisms. 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 5.6.3. Unicast and Multicast Associations
Requirement Requirement
The security mechanism SHOULD support security association protocols The security mechanism SHOULD support security association protocols
for unicast and for multicast associations. for unicast and for multicast associations.
Requirement Level Requirement Level
The requirement level of this requirement is 'SHOULD' since it may be The requirement level of this requirement is 'SHOULD' since it may be
expensive in terms of performance, especially for low-cost clocks. expensive in terms of performance, especially for low-cost clocks.
Discussion Discussion
A unicast protocol requires an association protocol between two A unicast protocol requires an association protocol between two
clocks, whereas a multicast protocol requires an association protocol clocks, whereas a multicast protocol requires an association protocol
among two or more clocks, where one of the clocks is a master. among two or more clocks, where one of the clocks is a master.
5.7. Performance 5.7. Performance
skipping to change at page 26, line 30 skipping to change at page 27, line 23
Discussion Discussion
While the requirement in this subsection is similar to the one in While the requirement in this subsection is similar to the one in
5.1. , it refers to the secure mode, as opposed to the hybrid mode 5.1. , it refers to the secure mode, as opposed to the hybrid mode
presented in the next subsection. presented in the next subsection.
5.10.2. Hybrid Mode 5.10.2. Hybrid Mode
Requirement Requirement
The security protocol MAY support a hybrid mode, where both secured The security protocol SHOULD support a hybrid mode, where both
and unsecured clocks are permitted to take part in the protocol. secured and unsecured clocks are permitted to take part in the
protocol.
Requirement Level Requirement Level
The requirement level of this requirement is a 'MAY', since it is not The requirement level of this requirement is a 'SHOULD'; on one hand
necessarily required in all systems. This document recommends to hybrid mode enables a gradual transition from unsecured to secured
deploy the 'Secure Mode' described in Section 5.10.1. where possible. mode, which is especially important in large-scaled deployments. On
the other hand, hybrid mode is not required in all systems; this
document recommends to deploy the 'Secure Mode' described in Section
5.10.1. where possible.
Discussion Discussion
The hybrid mode allows both secured and unsecured clocks to take part The hybrid mode allows both secured and unsecured clocks to take part
in the time protocol. NTP, for example, allows a mixture of secured in the time protocol. NTP, for example, allows a mixture of secured
and unsecured nodes. and unsecured nodes.
Requirement Requirement
A master in the hybrid mode SHOULD be a secured clock. A master in the hybrid mode SHOULD be a secured clock.
skipping to change at page 28, line 43 skipping to change at page 29, line 42
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Performance: bandwidth. | SHOULD | | | Performance: bandwidth. | SHOULD |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.8. | Confidentiality protection. | MAY | | 5.8. | Confidentiality protection. | MAY |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.9. | Protection against delay and interception | MUST | | 5.9. | Protection against delay and interception | MUST |
| | attacks. | | | | attacks. | |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.10. | Secure mode. | MUST | | 5.10. | Secure mode. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Hybrid mode. | MAY | | | Hybrid mode. | SHOULD |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
Table 2 Summary of Security Requirements Table 2 Summary of Security Requirements
7. Additional security implications 7. Additional security implications
This section discusses additional implications of the interaction This section discusses additional implications of the interaction
between time protocols and security mechanisms. between time protocols and security mechanisms.
This section refers to time protocol security mechanisms, as well as This section refers to time protocol security mechanisms, as well as
to "external" security mechanisms, i.e., security mechanisms that are to "external" security mechanisms, i.e., security mechanisms that are
skipping to change at page 32, line 33 skipping to change at page 33, line 33
12. References 12. References
12.1. Normative References 12.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References 12.2. Informative References
[NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., [1588IPsec] A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec
"Network Time Protocol Version 4: Protocol and tunnels - An analysis", in Proceedings of 2010
Algorithms Specification", RFC 5905, June 2010. International Symposium for Precision Clock
Synchronization for Measurement, Control and
Communication, ISPCS 2010, pp. 83-90, 2010.
[3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved
Node B (HeNB)", 3GPP TS 33.320 10.4.0 (work in
progress), 2011.
[Anatomy] C. Nachreiner, "Anatomy of an ARP Poisoning Attack",
2003.
[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.
[AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions",
IEEE 802.1 AVB Plenary, work in progress, May 2012.
[DelayAtt] T. Mizrahi, "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, 2012.
[Hack] S. McClure, J. Scambray, G. Kurtz, Kurtz, "Hacking
exposed: network security secrets and solutions",
McGraw-Hill, 2009.
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
"1588 IEEE Standard for a Precision Clock "1588 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems Version 2", IEEE Standard, 2008. Control Systems Version 2", IEEE Standard, 2008.
[Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., [IPsec] S. Kent, K. Seo, "Security Architecture for the
"Traps and pitfalls in secure clock synchronization" Internet Protocol", IETF, RFC 4301, 2005.
in Proceedings of 2007 International Symposium for
Precision Clock Synchronization for Measurement,
Control and Communication, ISPCS 2007, pp. 18-24,
2007.
[TM] T. Mizrahi, "Time synchronization security using IPsec [IPsecSync] Y. Xu, "IPsec security for packet based
and MACsec", ISPCS 2011, pp. 38-43, 2011. synchronization", IETF, draft-xu-tictoc-ipsec-
security-for-synchronization (work in progress), 2011.
[MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and
Metropolitan Area Networks - Media Access Control
(MAC) Security", 2006.
[NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
[SecPTP] J. Tsang, K. Beznosov, "A security analysis of the [SecPTP] J. Tsang, K. Beznosov, "A security analysis of the
precise time protocol (short paper)," 8th precise time protocol (short paper)," 8th
International Conference on Information and International Conference on Information and
Communication Security (ICICS 2006), pp. 50-59, 2006. Communication Security (ICICS 2006), pp. 50-59, 2006.
[SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava, [SecSen] S. Ganeriwal, C. Popper, S. Capkun, M. B. Srivastava,
"Secure Time Synchronization in Sensor Networks", ACM "Secure Time Synchronization in Sensor Networks", ACM
Trans. Info. and Sys. Sec., Volume 11, Issue 4, July Trans. Info. and Sys. Sec., Volume 11, Issue 4, July
2008. 2008.
[AvbAssum] D. Pannell, "Audio Video Bridging Gen 2 Assumptions", [TM] T. Mizrahi, "Time synchronization security using IPsec
IEEE 802.1 AVB Plenary, work in progress, May 2012. and MACsec", ISPCS 2011, pp. 38-43, 2011.
[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 [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R.,
tunnels - An analysis", in Proceedings of 2010 "Traps and pitfalls in secure clock synchronization"
International Symposium for Precision Clock in Proceedings of 2007 International Symposium for
Synchronization for Measurement, Control and Precision Clock Synchronization for Measurement,
Communication, ISPCS 2010, pp. 83-90, 2010. Control and Communication, ISPCS 2007, pp. 18-24,
2007.
[Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure [Tunnel] A. Treytl, B. Hirschler, and T. Sauter, "Secure
tunneling of high precision clock synchronisation tunneling of high precision clock synchronisation
protocols and other timestamped data", in Proceedings protocols and other timestamped data", in Proceedings
of the 8th IEEE International Workshop on Factory of the 8th IEEE International Workshop on Factory
Communication Systems (WFCS), vol. ISBN 978-1-4244- Communication Systems (WFCS), vol. ISBN 978-1-4244-
5461-7, pp. 303-313, 2010. 5461-7, pp. 303-313, 2010.
[DelayAtt] T. Mizrahi, "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, 2012.
[MACsec] IEEE 802.1AE-2006, "IEEE Standard for Local and
Metropolitan Area Networks - Media Access Control
(MAC) Security", 2006.
[IPsec] S. Kent, K. Seo, "Security Architecture for the
Internet Protocol", IETF, RFC 4301, 2005.
13. Contributing Authors 13. Contributing Authors
Karen O'Donoghue Karen O'Donoghue
ISOC ISOC
Email: odonoghue@isoc.org Email: odonoghue@isoc.org
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
 End of changes. 37 change blocks. 
101 lines changed or deleted 140 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/