draft-ietf-tictoc-security-requirements-00.txt   draft-ietf-tictoc-security-requirements-01.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: May 2012 ISOC Expires: September 2012 ISOC
November 30, 2011 March 12, 2012
TICTOC Security Requirements TICTOC Security Requirements
draft-ietf-tictoc-security-requirements-00.txt draft-ietf-tictoc-security-requirements-01.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 May 30, 2012. This Internet-Draft will expire on September 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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
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. Abbreviations ........................................... 4
3. Security Threats ............................................. 4 3. Security Threats ............................................. 5
3.1. Packet interception and manipulation .................... 5 3.1. Packet interception and manipulation .................... 5
3.2. Spoofing ................................................ 5 3.2. Spoofing ................................................ 5
3.3. Replay attack ........................................... 5 3.3. Replay attack ........................................... 5
3.4. Rogue master attack ..................................... 5 3.4. Rogue master attack ..................................... 5
3.5. Packet Interception and Removal ......................... 5 3.5. Packet Interception and Removal ......................... 6
3.6. Packet delay manipulation ............................... 5 3.6. Packet delay manipulation ............................... 6
3.7. Cryptographic performance attacks ....................... 6 3.7. Cryptographic performance attacks ....................... 6
3.8. DoS attacks ............................................. 6 3.8. DoS attacks ............................................. 6
3.9. Time source spoofing (e.g. GPS fraud) ................... 6 3.9. Time source spoofing (e.g. GPS fraud) ................... 6
4. Security Requirements ........................................ 6 4. Security Requirements ........................................ 6
4.1. Clock Identity Authentication ........................... 6 4.1. Clock Identity Authentication ........................... 6
4.1.1. Authentication and Proventication of Masters ....... 6 4.1.1. Authentication of Masters .......................... 7
4.1.2. Authentication of Slaves ........................... 7 4.1.2. Proventication of Masters .......................... 7
4.1.3. PTP: Authentication of Transparent Clocks........... 7 4.1.3. Authentication of Slaves ........................... 7
4.1.4. PTP: Authentication of Announce Messages ........... 8 4.1.4. PTP: Authentication of Transparent Clocks........... 8
4.2. Data integrity .......................................... 8 4.1.5. PTP: Authentication of Announce Messages ........... 8
4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 8 4.2. Data integrity .......................................... 9
4.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 9
4.2.1.1. Hop by Hop Integrity Protection ............... 9 4.2.1.1. Hop by Hop Integrity Protection ............... 9
4.2.1.2. End to End Integrity Protection ............... 9 4.2.1.2. End to End Integrity Protection .............. 10
4.3. Availability ........................................... 10 4.3. Availability ........................................... 10
4.4. Replay Protection ...................................... 10 4.4. Replay Protection ...................................... 10
4.5. Cryptographic Keys & Security Associations ............. 10 4.5. Cryptographic Keys & Security Associations ............. 10
4.5.1. Security Association .............................. 10 4.5.1. Security Association .............................. 10
4.5.2. Unicast and Multicast ............................. 10 4.5.2. Unicast and Multicast ............................. 11
4.5.3. Key Freshness ..................................... 11 4.5.3. Key Freshness ..................................... 11
4.6. Performance ............................................ 11 4.6. Performance ............................................ 11
4.7. Confidentiality......................................... 11 4.7. Confidentiality......................................... 12
4.8. Protection against packet delay attacks ................ 12 4.8. Protection against packet delay attacks ................ 12
5. Summary of Requirements ..................................... 12 4.9. Combining Secured with Unsecured Nodes ................. 12
6. Additional security implications ............................ 13 4.9.1. Secure Mode ....................................... 13
7. Issues for Further Discussion ............................... 13 4.9.2. Hybrid Mode ....................................... 13
8. Security Considerations ..................................... 14 5. Summary of Requirements ..................................... 13
9. IANA Considerations ......................................... 14 6. Additional security implications ............................ 14
10. Acknowledgments ............................................ 14 7. Issues for Further Discussion ............................... 15
11. References ................................................. 14 8. Security Considerations ..................................... 15
11.1. Normative References .................................. 14 9. IANA Considerations ......................................... 15
11.2. Informative References ................................ 15 10. Acknowledgments ............................................ 15
11. References ................................................. 15
11.1. Normative References .................................. 15
11.2. Informative References ................................ 16
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 4, line 33 skipping to change at page 4, line 40
document defines a specific security mechanism, but defines the document defines a specific security mechanism, but defines the
requirements that every security mechanism should comply to. requirements that every security mechanism should comply to.
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 general term "clock" applies to both PTP slaves and NTP clients. The general term "clock"
refers to masters, slaves and PTP Transparent Clocks (TC). The term refers to masters, slaves and PTP Transparent Clocks (TC). The term
"protocol packets" is refers generically to PTP and NTP messages. "protocol packets" is refers generically to PTP and NTP messages.
2.2. Abbreviations 2.2. Terms & Abbreviations
BC Boundary Clock BC Boundary Clock
MITM Man In The Middle MITM Man In The Middle
NTP Network Time Protocol NTP Network Time Protocol
OC Ordinary Clock OC Ordinary Clock
PTP Precision Time Protocol PTP Precision Time Protocol
Secured clock A clock that supports a security mechanism that
complies to the requirements in this document
TC Transparent Clock TC Transparent Clock
Unsecured clock A clock that does not support a security mechanism
according to the requirments in this document
3. Security Threats 3. Security Threats
The following section defines the security threats that are discussed The following section defines the security threats that are discussed
in subsequent sections. in subsequent sections.
3.1. Packet interception and manipulation 3.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
skipping to change at page 6, line 48 skipping to change at page 7, line 13
o Identification: verifying the identity of the peer clock. o Identification: verifying the identity of the peer clock.
o Authorization: verifying that the peer clock is permitted to play o Authorization: verifying that the peer clock is permitted to play
the role that it plays in the protocol. For example, some nodes the role that it plays in the protocol. For example, some nodes
may be permitted to be masters, while other nodes are only may be permitted to be masters, while other nodes are only
permitted to be slaves or TCs. permitted to be slaves or TCs.
The following subsections describe 4 distinct cases of clock The following subsections describe 4 distinct cases of clock
authentication. authentication.
4.1.1. Authentication and Proventication of Masters 4.1.1. Authentication of Masters
Requirement Requirement
The security mechanism MUST support an authentication mechanism,
allowing slave clocks to authenticate the identity of master clocks.
4.1.2. Proventication of Masters
Requirement
The security mechanism MUST support a proventication mechanism, to be The security mechanism MUST support a proventication mechanism, to be
used in cases where end-to-end authentication is not possible. used in cases where end-to-end authentication is not possible.
Discussion Discussion
Slaves and transparent clocks authenticate masters in order to ensure Slaves and transparent clocks authenticate masters in order to ensure
the authenticity of the time source. the authenticity of the time source.
In some cases a slave is connected to an intermediate master, that is In some cases a slave is connected to an intermediate master, that is
not the primary time source. For example, in PTP a slave can be not the primary time source. For example, in PTP a slave can be
connected to a Boundary Clock (BC), which in turn is connected to a connected to a Boundary Clock (BC), which in turn is connected to a
grandmaster. A similar example in NTP is when a client is connected grandmaster. A similar example in NTP is when a client is connected
to a stratum 2 server, which is connected to a stratum 1 server. In to a stratum 2 server, which is connected to a stratum 1 server. In
both the PTP and the NTP cases, the slave authenticates the both the PTP and the NTP cases, the slave authenticates the
intermediate master, and the intermediate master authenticates the intermediate master, and the intermediate master authenticates the
primary master. This inductive authentication process is referred to primary master. This inductive authentication process is referred to
in [AutoKey] as proventication. in [AutoKey] as proventication.
4.1.2. Authentication of Slaves 4.1.3. Authentication of Slaves
Requirement Requirement
The security mechanism SHOULD provide a means for a master to The security mechanism SHOULD provide a means for a master to
authenticate its slaves. authenticate its slaves.
Discussion Discussion
Slaves are authenticated by masters in order to verify that the slave Slaves are authenticated by masters in order to verify that the slave
is authorized to receive timing services from the master. is authorized to receive timing services from the master.
Authentication of slaves prevents unauthorized clocks from receiving Authentication of slaves prevents unauthorized clocks from receiving
time services, and also reduces unnecessary load on the master clock, time services, and also reduces unnecessary load on the master clock,
by preventing the master from serving unauthorized clocks. It could by preventing the master from serving unauthorized clocks. It could
be argued that the authentication of slaves could put a higher load be argued that the authentication of slaves could put a higher load
on the master then serving the unauthorized clock. This tradeoff will on the master then serving the unauthorized clock. This tradeoff will
need to be discussed further. need to be discussed further.
skipping to change at page 7, line 41 skipping to change at page 8, line 14
Slaves are authenticated by masters in order to verify that the slave Slaves are authenticated by masters in order to verify that the slave
is authorized to receive timing services from the master. is authorized to receive timing services from the master.
Authentication of slaves prevents unauthorized clocks from receiving Authentication of slaves prevents unauthorized clocks from receiving
time services, and also reduces unnecessary load on the master clock, time services, and also reduces unnecessary load on the master clock,
by preventing the master from serving unauthorized clocks. It could by preventing the master from serving unauthorized clocks. It could
be argued that the authentication of slaves could put a higher load be argued that the authentication of slaves could put a higher load
on the master then serving the unauthorized clock. This tradeoff will on the master then serving the unauthorized clock. This tradeoff will
need to be discussed further. need to be discussed further.
4.1.3. PTP: Authentication of Transparent Clocks 4.1.4. PTP: Authentication of Transparent Clocks
Requirement Requirement
The security mechanism for PTP SHOULD provide a means for a master to The security mechanism for PTP SHOULD provide a means for a master to
authenticate the TCs. authenticate the TCs.
Discussion Discussion
Transparent clocks are authenticated by peer masters, slaves and TCs. Transparent clocks are authenticated by peer masters, slaves and TCs.
Authentication of TCs, much like authentication of slaves, reduces Authentication of TCs, much like authentication of slaves, reduces
unnecessary load on the master clock and peer TCs, by preventing the unnecessary load on the master clock and peer TCs, by preventing the
master from serving unauthorized clocks. It also prevents malicious master from serving unauthorized clocks. It also prevents malicious
TCs from attacking the protocol by manipulating the correctionField. TCs from attacking the protocol by manipulating the correctionField.
It could also be argued that the authentication could result in a It could also be argued that the authentication could result in a
higher load then merely serving the unauthorized devices. This higher load then merely serving the unauthorized devices. This
tradeoff will need to be discussed further. tradeoff will need to be discussed further.
4.1.4. PTP: Authentication of Announce Messages 4.1.5. PTP: Authentication of Announce Messages
Requirement Requirement
The security mechanism for PTP MUST support authentication of The security mechanism for PTP MUST support authentication of
Announce messages. Announce messages.
Discussion Discussion
Master election is performed in PTP using the Best Master Clock Master election is performed in PTP using the Best Master Clock
Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock
attributes using Announce messages, and the best master is elected attributes using Announce messages, and the best master is elected
based on the information gathered from all the candidates. Announce based on the information gathered from all the candidates. Announce
messages must be authenticated in order to prevent malicious master messages must be authenticated in order to prevent malicious master
attacks. attacks.
Note, that this subsection specifies a requirement that is not Note, that this subsection specifies a requirement that is not
necessarily included in 4.1.1. or in 4.1.2. , since the BMCA is necessarily included in 4.1.1. or in 4.1.3. , since the BMCA is
initiated before clocks have been defined as masters or slaves. initiated before clocks have been defined as masters or slaves.
4.2. Data integrity 4.2. Data integrity
Requirement Requirement
The security mechanism MUST protect the integrity of protocol The security mechanism MUST protect the integrity of protocol
packets. packets.
Discussion Discussion
skipping to change at page 12, line 27 skipping to change at page 12, line 46
The security mechanism MAY include a means to detect packet delay The security mechanism MAY include a means to detect packet delay
attacks. attacks.
Requirement Requirement
The security mechanism MAY include a protection switching mechanism The security mechanism MAY include a protection switching mechanism
that allows a node that detects a delay attack to switch over to a that allows a node that detects a delay attack to switch over to a
secondary master. secondary master.
4.9. Combining Secured with Unsecured Nodes
Integrating a security mechanism into a time synchronized system is a
complex process, and in some cases may require a gradual process,
where new equipment supports the security mechanism, and is required
to interoperate with legacy equipment without the security features.
4.9.1. Secure Mode
Requirement
The security mechanism MUST support a secure mode, where only secured
clocks are permitted to take part in the synchronization protocol. A
protocol packet received from an unsecured clock MUST be discarded.
4.9.2. Hybrid Mode
Requirement
The security protocol MAY support a hybrid mode, where both secured
and unsecured clocks are permitted to take part in the protocol.
A master in the hybrid mode MUST be a secured clock.
A secured slave in the hybrid mode MUST discard all protocol packets
received from unsecured clocks.
Discussion
The hybrid mode allows both secured and unsecured clocks to take part
in the synchronization protocol. It is essential that the existence
of unsecured clocks does not compromise the security provided to
secured clocks. Hence, secured slaves only "trust" protocol packets
received from a secured clock. An unsecured clock can receive
protocol packets from either secured clocks, or unsecured clocks.
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 |
| +--------------------------------------+---------------+
| | Proventication. | MUST | | | Proventication. | MUST |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Authentication of slaves. | SHOULD | | | Authentication of slaves. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | PTP: Authentication of TCs. | SHOULD | | | PTP: Authentication of TCs. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | PTP: Authentication of Announce | SHOULD | | | PTP: Authentication of Announce | SHOULD |
| | messages. | | | | messages. | |
+-----------+--------------------------------------+---------------+ +-----------+--------------------------------------+---------------+
| 4.2. | Integrity protection. | MUST | | 4.2. | Integrity protection. | MUST |
skipping to change at page 13, line 25 skipping to change at page 14, line 33
| | quality of time transfer. | | | | quality of time transfer. | |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | Performance: lightweight. | SHOULD | | | Performance: lightweight. | SHOULD |
| +--------------------------------------+---------------+ | +--------------------------------------+---------------+
| | 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 |
| +--------------------------------------+---------------+
| | Hybrid mode. | MAY |
+-----------+--------------------------------------+---------------+
Table 1 Summary of Security Requirements Table 1 Summary of Security Requirements
6. Additional security implications 6. Additional security implications
This section will discuss additional security implications as This section will discuss additional security implications as
outlined in the questions below. Contributions are welcome and outlined in the questions below. Contributions are welcome and
encouraged. encouraged.
o What external security practices impact the security and o What external security practices impact the security and
performance of time keeping? (and what can be done to mitigate performance of time keeping? (and what can be done to mitigate
skipping to change at page 13, line 46 skipping to change at page 15, line 18
o What are the security impacts of time synchronization protocol o What are the security impacts of time synchronization protocol
practices? (e.g. on-the-fly modification of timestamps) practices? (e.g. on-the-fly modification of timestamps)
o What are the dependencies between other security services and time o What are the dependencies between other security services and time
synchronization? synchronization?
7. Issues for Further Discussion 7. Issues for Further Discussion
This section will discuss additional issues as identified below. This section will discuss additional issues as identified below.
Again, contributions are welcome and encouraged.
o Integrity - end-to-end vs. hop-by-hop.
o Supporting a hybrid network, where some nodes are security enabled
and others are not.
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.
 End of changes. 30 change blocks. 
46 lines changed or deleted 97 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/