draft-ietf-tictoc-security-requirements-06.txt   draft-ietf-tictoc-security-requirements-07.txt 
TICTOC Working Group Tal Mizrahi TICTOC Working Group Tal Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Intended status: Informational
Expires: April 2014 October 21, 2013 Expires: October 2014 April 23, 2014
Security Requirements of Time Protocols Security Requirements of Time Protocols
in Packet Switched Networks in Packet Switched Networks
draft-ietf-tictoc-security-requirements-06.txt draft-ietf-tictoc-security-requirements-07.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 April 21, 2014. This Internet-Draft will expire on October 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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 ...................... 5
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 ........................................... 8
3.2.3. Replay Attack ...................................... 8 3.2.3. Replay Attack ...................................... 9
3.2.4. Rogue Master Attack ................................ 8 3.2.4. Rogue Master Attack ................................ 9
3.2.5. Packet Interception and Removal .................... 9 3.2.5. Packet Interception and Removal .................... 9
3.2.6. Packet Delay Manipulation .......................... 9 3.2.6. Packet Delay Manipulation .......................... 9
3.2.7. L2/L3 DoS Attacks .................................. 9 3.2.7. L2/L3 DoS Attacks .................................. 9
3.2.8. Cryptographic Performance Attacks .................. 9 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) . 10
3.3. Threat Analysis Summary ................................ 10 3.3. Threat Analysis Summary ................................ 10
4. Requirement Levels .......................................... 12 4. Requirement Levels .......................................... 12
5. Security Requirements ....................................... 12 5. Security Requirements ....................................... 13
5.1. Clock Identity Authentication and Authorization ........ 13 5.1. Clock Identity Authentication and Authorization ........ 13
5.1.1. Authentication and Authorization of Masters ....... 14 5.1.1. Authentication and Authorization of Masters ....... 14
5.1.2. Recursive Authentication and Authorization of Masters 5.1.2. Recursive Authentication and Authorization of Masters
(Chain of Trust) ......................................... 14 (Chain of Trust) ......................................... 15
5.1.3. Authentication and Authorization of Slaves ........ 15 5.1.3. Authentication and Authorization of Slaves ........ 15
5.1.4. PTP: Authentication and Authorization of PTP TCs by the 5.1.4. PTP: Authentication and Authorization of P2P TCs by the
Master ................................................... 16 Master ................................................... 16
5.1.5. PTP: Authentication and Authorization of Control 5.1.5. PTP: Authentication and Authorization of Control
Messages ................................................. 17 Messages ................................................. 17
5.2. Protocol Packet Integrity .............................. 18 5.2. Protocol Packet Integrity .............................. 18
5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 18 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 .............. 19
5.3. Availability ........................................... 20 5.3. Availability ........................................... 20
5.4. Replay Protection ...................................... 20 5.4. Replay Protection ...................................... 20
5.5. Cryptographic Keys and Security Associations ........... 21 5.5. Cryptographic Keys and Security Associations ........... 21
5.5.1. Key Freshness ..................................... 21 5.5.1. Key Freshness ..................................... 21
5.5.2. Security Association .............................. 21 5.5.2. Security Association .............................. 21
5.5.3. Unicast and Multicast Associations ................ 22 5.5.3. Unicast and Multicast Associations ................ 22
5.6. Performance ............................................ 22 5.6. Performance ............................................ 22
5.7. Confidentiality......................................... 23 5.7. Confidentiality......................................... 23
5.8. Protection against Packet Delay and Interception Attacks 24 5.8. Protection against Packet Delay and Interception Attacks 24
5.9. Combining Secured with Unsecured Nodes ................. 25 5.9. Combining Secured with Unsecured Nodes ................. 25
5.9.1. Secure Mode ....................................... 25 5.9.1. Secure Mode ....................................... 25
5.9.2. Hybrid Mode ....................................... 25 5.9.2. Hybrid Mode ....................................... 25
6. Summary of Requirements ..................................... 27 6. Summary of Requirements ..................................... 26
7. Additional security implications ............................ 28 7. Additional security implications ............................ 28
7.1. Security and on-the-fly Timestamping ................... 28 7.1. Security and on-the-fly Timestamping ................... 28
7.2. PTP: Security and Two-Step Timestamping ................ 29 7.2. PTP: Security and Two-Step Timestamping ................ 28
7.3. Intermediate Clocks .................................... 29 7.3. Intermediate Clocks .................................... 29
7.4. External Security Protocols and Time Protocols.......... 30 7.4. External Security Protocols and Time Protocols.......... 29
7.5. External Security Services Requiring Time .............. 30 7.5. External Security Services Requiring Time .............. 30
7.5.1. Timestamped Certificates .......................... 30 7.5.1. Timestamped Certificates .......................... 30
7.5.2. Time Changes and Replay Attacks ................... 31 7.5.2. Time Changes and Replay Attacks ................... 30
8. Issues for Further Discussion ............................... 31 8. Issues for Further Discussion ............................... 31
9. Security Considerations ..................................... 31 9. Security Considerations ..................................... 31
10. IANA Considerations......................................... 31 10. IANA Considerations......................................... 31
11. Acknowledgments ............................................ 31 11. Acknowledgments ............................................ 31
12. References ................................................. 31 12. References ................................................. 31
12.1. Normative References .................................. 31 12.1. Normative References .................................. 31
12.2. Informative References ................................ 32 12.2. Informative References ................................ 32
13. Contributing Authors ....................................... 33 13. Contributing Authors ....................................... 33
1. Introduction 1. Introduction
skipping to change at page 5, line 31 skipping to change at page 5, line 31
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
This document describes security requirements, and thus requirements This document describes security requirements, and thus requirements
are phrased in the document in the form "the security mechanism are phrased in the document in the form "the security mechanism
MUST/SHOULD/...". Note, that the phrasing does not imply that this MUST/SHOULD/...". Note, that the phrasing does not imply that this
document defines a specific security mechanism, but defines the document defines a specific security mechanism, but defines the
requirements with which every security mechanism should comply. requirements with which every security mechanism should comply.
2.2. Abbreviations 2.2. Abbreviations
BC Boundary Clock BC Boundary Clock [IEEE1588]
DoS Denial of Service DoS Denial of Service
MITM Man In The Middle MITM Man In The Middle
NTP Network Time Protocol NTP Network Time Protocol [NTPv4]
OC Ordinary Clock OC Ordinary Clock [IEEE1588]
PTP Precision Time Protocol P2P TC Peer-to-Peer Transparent Clock [IEEE1588]
TC Transparent Clock PTP Precision Time Protocol [IEEE1588]
TC Transparent Clock [IEEE1588]
2.3. Common Terminology for PTP and NTP 2.3. Common Terminology for PTP and NTP
This document refers to both PTP and NTP. For the sake of This document refers to both PTP and NTP. For the sake of
consistency, throughout the document the term "master" applies to consistency, throughout the document the term "master" applies to
both a PTP master and an NTP server. Similarly, the term "slave" both a PTP master and an NTP server. Similarly, the term "slave"
applies to both PTP slaves and NTP clients. The term "protocol applies to both PTP slaves and NTP clients. The term "protocol
packets" refers generically to PTP and NTP messages. packets" refers generically to PTP and NTP messages.
2.4. Terms used in this Document 2.4. Terms used in this Document
skipping to change at page 8, line 34 skipping to change at page 8, line 34
timing protocol packets, alters them and relays them to their timing protocol packets, alters them and relays them to their
destination, allowing the attacker to maliciously tamper with the destination, allowing the attacker to maliciously tamper with the
protocol. This can result in a situation where the time protocol is protocol. This can result in a situation where the time protocol is
apparently operational but providing intentionally inaccurate apparently operational but providing intentionally inaccurate
information. information.
3.2.2. Spoofing 3.2.2. Spoofing
In spoofing, an injector masquerades as a legitimate node in the In spoofing, an injector masquerades as a legitimate node in the
network by generating and transmitting protocol packets or control network by generating and transmitting protocol packets or control
packets. For example, an attacker can impersonate the master, packets. Two typical examples of spoofing attacks:
allowing malicious distribution of false timing information. As with
packet manipulation, this can result in a situation where the time o An attacker can impersonate the master, allowing malicious
protocol is apparently operational but providing intentionally distribution of false timing information.
inaccurate 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 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 without any modification. This can also result them at a later time without any modification. This can also result
in a situation where the time protocol is apparently operational but in a situation where the time protocol is apparently operational but
providing intentionally inaccurate information. providing intentionally inaccurate information.
3.2.4. Rogue Master Attack 3.2.4. Rogue Master Attack
skipping to change at page 13, line 47 skipping to change at page 14, line 19
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.
The following subsections describe 4 distinct cases of clock The following subsections describe 5 distinct cases of clock
authentication. authentication.
5.1.1. Authentication and Authorization of Masters 5.1.1. Authentication and Authorization of Masters
Requirement Requirement
The security mechanism MUST support an authentication mechanism, The security mechanism MUST support an authentication mechanism,
allowing slaves to authenticate the identity of masters. allowing slaves to authenticate the identity of masters.
Requirement Requirement
skipping to change at page 15, line 25 skipping to change at page 15, line 46
receives time information through a TC, it must authenticate the TC receives time information through a TC, it must authenticate the TC
it is attached to, as well as authenticate the master it receives the it is attached to, as well as authenticate the master it receives the
time information from, as per Section 5.1.1. Similarly, if a TC time information from, as per Section 5.1.1. Similarly, if a TC
receives time information through an attached TC, it must receives time information through an attached TC, it must
authenticate the attached TC. authenticate the attached TC.
5.1.3. Authentication and Authorization of Slaves 5.1.3. Authentication and Authorization of Slaves
Requirement Requirement
The security mechanism MAY provide a means for a master to The security mechanism MUST provide a means for a master to
authenticate its slaves. authenticate its slaves.
Requirement Requirement
The security mechanism MAY provide a means for a master to verify 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 that the sender of a protocol packet is authorized to send a packet
of this type. of this type.
Requirement Level Requirement Level
The requirement in this subsection prevents DoS attacks against the The authentication requirement in this subsection prevents DoS
master (Section 3.2.9.). attacks against the master (Section 3.2.9.), as well as spoofing
attacks (Section 3.2.2.). A spoofing attack, such as the second
The requirement level of this requirement is 'MAY' since: example in Section 3.2.2. , is easy to implement and has a high
impact, and therefore the requirement level is 'MUST'.
o Its low impact, 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 authorization requirement in this subsection only mitigates DoS
the requirement in Section 5.1.1. is 'MUST'; the security mechanism attacks against the master (Section 3.2.9.). The requirement level
must provide a means for authentication and authorization, with an is 'MAY', since the absence of this requirement has a relatively low
emphasis on the master. Authentication and authorization of slaves is impact, i.e., in the absence of this requirement the protocol is only
specified in this subsection as 'MAY'. exposed to DoS. Note that Section 5.1.1. specifies authorization as
a 'MUST', i.e., the security mechanism must provide a means for
authorization, with an emphasis on the master. Authentication and
authorization of slaves is specified in this subsection as 'MAY'.
Discussion Discussion
Slaves and intermediate clocks are authenticated by masters in order Slaves and intermediate clocks are authenticated by masters in order
to verify that they are authorized to receive timing services from to verify their identity, thus preventing attackers from sending
the master. unauthorized protocol packets to the master, and preventing
unauthorized clocks from receiving time services.
Authentication of slaves prevents unauthorized clocks from receiving Note that the authentication of slaves might put a higher load on the
time services. Preventing the master from serving unauthorized clocks master than serving the unauthorized clock, and thus the decision of
can help in mitigating DoS attacks against the master. Note that the whether to deploy slave authentication and/or authorization should be
authentication of slaves might put a higher load on the master than based on the environment in which the master and slaves are deployed.
serving the unauthorized clock, and hence this requirement is a MAY.
5.1.4. PTP: Authentication and Authorization of PTP TCs by the Master 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master
Requirement Requirement
The security mechanism for PTP MAY provide a means for a master to The security mechanism for PTP MUST provide a means for a master to
authenticate the identity of the P2P TCs directly connected to it. authenticate the identity of the P2P TCs directly connected to it.
Requirement Requirement
The security mechanism for PTP MAY provide a means for a master to 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 verify that P2P TCs directly connected to it are authorized to be
TCs. TCs.
Requirement Level Requirement Level
As in Section 5.1.3. , authentication and authorization can help in
preventing DoS attacks against the master (Section 3.2.9.).
Authentication also mitigates spoofing attacks (Section 3.2.2.).
The requirement in this subsection prevents DoS attacks against the The requirement levels of the authentication and authorization
master (Section 3.2.9.). requirements in this subsection are 'MUST' and 'MAY' respectively,
for the same reasons specified in Section 5.1.3.
The requirement level of this requirement is 'MAY' for the same
reasons specified in Section 5.1.3.
Discussion Discussion
P2P TCs that are one hop from the master use the PDelay_Req and 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 PDelay_Resp handshake to compute the link delay between the master
and TC. These TCs are authenticated by the master. and TC. These TCs are authenticated by the master.
Authentication of TCs, much like authentication of slaves, reduces Authentication of TCs, much like authentication of slaves, prevents
unnecessary load on the master and peer TCs, by preventing the master external attackers from sending spoofed messages to the master, as
from serving unauthorized clocks. well as 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 5.1.5. PTP: Authentication and Authorization of Control Messages
Requirement Requirement
The security mechanism for PTP MUST support authentication of The security mechanism for PTP MUST support authentication of
Announce messages. The authentication mechanism MUST also verify that Announce messages. The authentication mechanism MUST also verify that
the sender is authorized to be a master. the sender is authorized to be a master.
Requirement Requirement
skipping to change at page 18, line 37 skipping to change at page 19, line 9
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.
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
Requirement
A security mechanism for PTP MUST support hop-by-hop integrity
protection.
Requirement
A security mechanism for PTP SHOULD support end-to-end integrity
protection.
Requirement Level
The requirement in this subsection addresses the packet manipulation
attack (Section 3.2.1.).
The requirement level of the first 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.
The requirement level of the first requirement is 'SHOULD' since in
the presence of recursive authentication (Section 5.1.2.) this
requirement may be redundant.
Discussion
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:
o Verifies its integrity. o Verifies its integrity.
skipping to change at page 20, line 31 skipping to change at page 20, line 26
The requirement level of this requirement is 'SHOULD' due to its low 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 impact, i.e., in the absence of this requirement the protocol is only
exposed to DoS. exposed to DoS.
Discussion Discussion
The protocol availability can be compromised by several different The protocol availability can be compromised by several different
attacks. attacks.
An attacker can inject protocol messages to implement the spoofing An attacker can inject protocol packets to implement the spoofing
attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4. 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 ), causing DoS to the victim (Section 3.2.9.). An authentication
mechanism (Section 5.1.) limits these attacks strictly to internal mechanism (Section 5.1.) limits these attacks strictly to internal
attackers, and thus prevents external attackers from performing them. attackers, and thus prevents external attackers from performing them.
The DoS attacks described in Section 3.2.7. are performed at lower The DoS attacks described in Section 3.2.7. are performed at lower
layers than the time protocol layer, and are thus outside the scope layers than the time protocol layer, and are thus outside the scope
of the security requirements defined in this document. of the security requirements defined in this document.
5.4. Replay Protection 5.4. Replay Protection
skipping to change at page 21, line 33 skipping to change at page 21, line 26
Requirement Level Requirement Level
The requirement level of this requirement is 'MUST' since key The requirement level of this requirement is 'MUST' since key
freshness is an essential property for cryptographic algorithms, as freshness is an essential property for cryptographic algorithms, as
discussed below. discussed below.
Discussion Discussion
Key freshness guarantees that both sides share a common updated Key freshness guarantees that both sides share a common updated
secret key. It also helps in preventing replay and playback attacks. secret key. It also helps in preventing replay attacks. Thus, it is
Thus, it is important for keys to be refreshed frequently. important for keys to be refreshed frequently.
5.5.2. Security Association 5.5.2. Security Association
Requirement Requirement
The security protocol SHOULD support an association protocol where: The security protocol SHOULD 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.
skipping to change at page 24, line 13 skipping to change at page 24, line 7
encryption mechanism can prevent eavesdroppers from obtaining the encryption mechanism can prevent eavesdroppers from obtaining the
service without payment. Note that these cases are, for now, rather service without payment. Note that these cases are, for now, rather
esoteric. esoteric.
Confidentiality can also prevent an MITM attacker from identifying Confidentiality can also prevent an MITM attacker from identifying
protocol packets. Thus, confidentiality can assist in protecting the protocol packets. Thus, confidentiality can assist in protecting the
timing protocol against MITM attacks such as packet delay (Section timing protocol against MITM attacks such as packet delay (Section
3.2.6.), manipulation and interception and removal attacks. Note, 3.2.6.), manipulation and interception and removal attacks. Note,
that time protocols have predictable behavior even after encryption, that time protocols have predictable behavior even after encryption,
such as packet transmission rates and packet lengths. Additional such as packet transmission rates and packet lengths. Additional
measure can be taken to mitigate encrypted traffic analysis by random measures can be taken to mitigate encrypted traffic analysis by
padding of encrypted packets and by adding random dummy packets. random padding of encrypted packets and by adding random dummy
Nevertheless, encryption does not prevent such MITM attacks, but packets. Nevertheless, encryption does not prevent such MITM attacks,
rather makes these attacks more difficult to implement. but rather makes these attacks more difficult to implement.
5.8. Protection against Packet Delay and Interception Attacks 5.8. Protection against Packet Delay and Interception Attacks
Requirement Requirement
The security mechanism SHOULD include means to protect the protocol The security mechanism MUST include means to protect the protocol
from MITM attacks that degrade the clock accuracy. from MITM attacks that degrade the clock accuracy.
Requirement Level Requirement Level
The requirements in this subsection address MITM attacks such as the The requirements in this subsection address MITM attacks such as the
3.2.1.). packet delay attack (Section 3.2.6.) and packet interception attacks
(Section 3.2.5. and Section 3.2.1.).
The requirement level of this requirement is 'SHOULD'. In the absence The requirement level of this requirement is 'MUST'. In the absence
of this requirement the protocol is exposed to attacks that are easy 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 to implement and have a high impact. Note that in the absence of this
requirement, the impact is similar to packet manipulation attacks requirement, the impact is similar to packet manipulation attacks
(Section 3.2.1.), and thus this requirement has the same requirement (Section 3.2.1.), and thus this requirement has the same requirement
level as integrity protection (Section 5.2.). level as integrity protection (Section 5.2.).
It is noted that the implementation of this requirement depends on It is noted that the implementation of this requirement depends on
the topology and properties of the system. the topology and properties of the system.
Discussion Discussion
skipping to change at page 25, line 8 skipping to change at page 24, line 48
note that common practices for protection against MITM attacks use note that common practices for protection against MITM attacks use
redundant masters (e.g. [NTPv4]), or redundant paths between the redundant masters (e.g. [NTPv4]), or redundant paths between the
master and slave (e.g. [DelayAtt]). If one of the time sources master and slave (e.g. [DelayAtt]). If one of the time sources
indicates a time value that is significantly different than the other indicates a time value that is significantly different than the other
sources, it is assumed to be erroneous or under attack, and is sources, it is assumed to be erroneous or under attack, and is
therefore ignored. therefore ignored.
Thus, MITM attack prevention derives a requirement from the security Thus, MITM attack prevention derives a requirement from the security
mechanism, and a requirement from the network topology. While the mechanism, and a requirement from the network topology. While the
security mechanism should support the ability to detect delay security mechanism should support the ability to detect delay
attacks, it is noted that in some networks it is not necessarily attacks, it is noted that in some networks it is not possible to
possible to provide the redundancy needed for such a detection provide the redundancy needed for such a detection mechanism.
mechanism.
5.9. Combining Secured with Unsecured Nodes 5.9. Combining Secured with Unsecured Nodes
Integrating a security mechanism into a time synchronized system is a Integrating a security mechanism into a time synchronized system is a
complex and expensive process, and hence in some cases may require complex and expensive process, and hence in some cases may require
incremental deployment, where new equipment supports the security incremental deployment, where new equipment supports the security
mechanism, and is required to interoperate with legacy equipment mechanism, and is required to interoperate with legacy equipment
without the security features. without the security features.
5.9.1. Secure Mode 5.9.1. Secure Mode
skipping to change at page 27, line 16 skipping to change at page 27, line 5
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| Section | Requirement | Type | | Section | Requirement | Type |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.1. | Authentication & authorization of sender. | MUST | | 5.1. | Authentication & authorization of sender. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Authentication & authorization of master. | MUST | | | Authentication & authorization of master. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Recursive authentication & authorization. | MUST | | | Recursive authentication & authorization. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Authentication & authorization of slaves. | MAY | | | Authentication of slaves. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authentication of TCs by master. | MAY | | | Authorization of slaves. | MAY |
| +---------------------------------------------+--------+
| | PTP: Authentication of P2P TCs by master. | MUST |
| +---------------------------------------------+--------+
| | PTP: Authorization of P2P TCs by master. | MAY |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MUST | | | PTP: Authentication & authorization of | MUST |
| | Announce messages. | | | | Announce messages. | |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MUST | | | PTP: Authentication & authorization of | MUST |
| | Management messages. | | | | Management messages. | |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY | | | PTP: Authentication & authorization of | MAY |
| | Signaling messages. | | | | Signaling messages. | |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.2. | Integrity protection. | MUST | | 5.2. | Integrity protection. | MUST |
| +---------------------------------------------+--------+
| | PTP: hop-by-hop integrity protection. | MUST |
| +---------------------------------------------+--------+
| | PTP: end-to-end integrity protection. | SHOULD |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.3. | Protection against DoS attacks. | SHOULD | | 5.3. | Protection from DoS attacks against the | SHOULD |
| | time protocol. | |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.4. | Replay protection. | MUST | | 5.4. | Replay protection. | MUST |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.5. | Key freshness. | MUST | | 5.5. | Key freshness. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Security association. | SHOULD | | | Security association. | SHOULD |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Unicast and multicast associations. | SHOULD | | | Unicast and multicast associations. | SHOULD |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.6. | Performance: no degradation in quality of | MUST | | 5.6. | Performance: no degradation in quality of | MUST |
| | time transfer. | | | | time transfer. | |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Performance: computation load. | SHOULD | | | Performance: computation load. | SHOULD |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Performance: storage. | SHOULD | | | Performance: storage. | SHOULD |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Performance: bandwidth. | SHOULD | | | Performance: bandwidth. | SHOULD |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.7. | Confidentiality protection. | MAY | | 5.7. | Confidentiality protection. | MAY |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.8. | Protection against delay and interception | SHOULD | | 5.8. | Protection against delay and interception | MUST |
| | attacks. | | | | attacks. | |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.9. | Secure mode. | MUST | | 5.9. | Secure mode. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Hybrid mode. | MAY | | | Hybrid mode. | MAY |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
Table 2 Summary of Security Requirements Table 2 Summary of Security Requirements
7. Additional security implications 7. Additional security implications
skipping to change at page 29, line 6 skipping to change at page 28, line 41
integrity protection: integrity protection:
o During transmission the encryption and/or integrity protection o During transmission the encryption and/or integrity protection
MUST be applied after integrating the timestamp into the packet. MUST be applied after integrating the timestamp into the packet.
To allow high accuracy, timestamping is typically performed as close To allow high accuracy, timestamping is typically performed as close
to the transmission or reception time as possible. However, since the to the transmission or reception time as possible. However, since the
security engine must be placed between the timestamping function and security engine must be placed between the timestamping function and
the physical interface, it may introduce non-deterministic latency the physical interface, it may introduce non-deterministic latency
that causes accuracy degradation. These performance aspects have been that causes accuracy degradation. These performance aspects have been
analyzed in the literature, e.g., in [1588IPsec] and [Tunnel]. analyzed in literature, e.g., [1588IPsec] and [Tunnel].
7.2. PTP: Security and Two-Step Timestamping 7.2. PTP: Security and Two-Step Timestamping
PTP supports a two-step mode of operation, where the time of PTP supports a two-step mode of operation, where the time of
transmission of protocol packets is communicated without modifying transmission of protocol packets is communicated without modifying
the packets. As opposed to one-step mode, two-step timestamping can the packets. As opposed to one-step mode, two-step timestamping can
be performed without the requirement to encrypt after timestamping. be performed without the requirement to encrypt after timestamping.
Note that if an encryption mechanism such as IPsec is used, it Note that if an encryption mechanism such as IPsec is used, it
presents a challenge to the timestamping mechanism, since time presents a challenge to the timestamping mechanism, since time
skipping to change at page 31, line 17 skipping to change at page 31, line 4
dependence between the acquired time information, and the dependence between the acquired time information, and the
authentication protocol that secures it. This bootstrapping behavior authentication protocol that secures it. This bootstrapping behavior
results from the fact that trusting the received time information results from the fact that trusting the received time information
requires a valid certificate, and validating a certificate requires requires a valid certificate, and validating a certificate requires
knowledge of the time. knowledge of the time.
7.5.2. Time Changes and Replay Attacks 7.5.2. Time Changes and Replay Attacks
A successful attack on a time protocol may cause the attacked clocks A successful attack on a time protocol may cause the attacked clocks
to go back in time. The erroneous time may expose cryptographic to go back in time. The erroneous time may expose cryptographic
algorithms that rely on time to prevent replay attacks. algorithms that rely on time, as a node may use a key that was
already used in the past and has expired.
8. Issues for Further Discussion 8. Issues for Further Discussion
The Key distribution is outside the scope of this document. Although The Key distribution is outside the scope of this document. Although
this is an essential element of any security system, it is outside this is an essential element of any security system, it is outside
the scope of this document. the scope of this document.
9. Security Considerations 9. 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.
10. IANA Considerations 10. IANA Considerations
There are no new IANA considerations implied by this document. There are no new IANA considerations implied by this document.
11. Acknowledgments 11. Acknowledgments
The authors gratefully acknowledge Stefano Ruffini, Doug Arnold, The authors gratefully acknowledge Stefano Ruffini, Doug Arnold,
Kevin Gross, Dieter Sibold, Dan Grossman and Laurent Montini for Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell
their thorough review and helpful comments. The authors would also Smiley, and Shawn Emery for their thorough review and helpful
like to thank members of the TICTOC WG for providing feedback on the comments. The authors would also like to thank members of the TICTOC
TICTOC mailing list. WG for providing feedback on the TICTOC mailing list.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
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.
 End of changes. 48 change blocks. 
112 lines changed or deleted 100 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/