Subject: [TICTOC] TICTOC Security Requirements

From: Yaakov Stein <[email-masked]>
Date: Mon, 18 Mar 2013 14:37:19 +0000

The following is my review of the 04 version of this document.
(Actually I originally mistakenly reviewed 03 and only afterward went over this version.
  I was pleased that almost all of my comments were obsoleted by 04!)

General  I personally prefer "timing distribution protocols"  to  "time synchronization protocols",
as I think the protocol distributes the timing (time and/or frequency)
while the specific sync algorithm performs the synchronization.

General nit :  you have a lot of strange spaces near anchors that are probably due to some automatic mechanism
For example "Section 5 ." -> "Section 5." (twice)      "(Section 3.2.2  )" -> "(Section 3.2.2)", etc. etc. etc.
(I guess this is a Microsoft Word artifact)

Section 2.1
requirements that every security mechanism should comply to  -> requirements with which every security mechanism should comply

Section 2.4 I believe that "clock" means master clock OR intermediate clock OR slave clock.
Why only PTP intermediate clock. And why is the definition of clock separated from the other definitions.
I realize that it is more fundamental, but it makes it harder to find.

3.2.2  an attacker -> an injector
3.2.5 receiving the some or all -> receiving some or all
3.2.6 perhaps it is worthwhile calling out that the added delay may be constant, jittered, or slowly wandering (3 different attacks)
3.2.7 fake protocol packet -> fake protocol packets
3.2.8 shouldn't this section be before 3.2.7 ? (as it is more general)
3.2.9 using -> by sending it   3 .2.4 -> 3.2.4
3.2.10  e.g.  -> e.g.,
           An attacker can spoof the GPS -> an attacker can transmit a signal similar to one from a GPS satellite
3.2.11 <NEW> an additional attack is jamming the reception of GPS signals !!!!

3.3 are the severity -> are the impact
      provides an intuition -> provides an intuitive measure of

Table 1
I think we need a "+" in interception and removal DoS
I think we don't need "+"s in Master Time source spoofing MITM (both internal and external)

Section 4  about the reason -> detailing the reason
I liked the version 3 text for "security requirements" (other than 2 typos) more than the present text.
Here you quote 2119, which is actually not directly relevant for requirements documents.
Suggestion - point to your own section 2.1.

Section 5.1  I have a problem here. You say that the security mechanism MUST provide a means for each clock to authenticate
the sender of protocol packets. But afterwards you say that a master MAY authenticate its slaves.
But slaves send protocol packets to the master!

5.1.2  I don't believe that "inductive" is correct here. I suggest to continue using the term "recursive", or to use "iteration".

5.1.3  reduces -> induces (quite the opposite !)
It could be argued that the authentication of slaves could ...
I suggest
The authentication of slaves might put a higher computational load on
the master than serving an unauthorized clock, and hence this
requirement is a SHOULD.  <and note "than" not "then">

5.1.4 suggested title Authentication and Authorization of PTP TCs by the Master
5.1.5 Agreed. So why not add this attack to the list above, rather than apologizing here ?
5.2 Data -> Protocol Packet   a high impact -> high impact
5.2.1.1 please add reference to the appropriate 1588 section describing correctionField
            Also, induction -> tracing back or something similar
5.2.1.2  validate -> directly validate
5.5.1 periodically -> frequently  (as far as I see there is no real requirement for periodic updates,
         Just for updates before wrap-around that may provide crackers with additional information)
5.5.2 Security Associations  - Actually I have a problem with the reasoning here.
         Isn't the purpose of a non-ephemeral association to save time in generating symmetric keys ?
5.5.3 Unicast and Multicast timing protocols (?)
especially in -> especially for
strictly (I believe can be removed)
5.6 does not significantly degrade the quality, or does not degrade the quality to a noticeable degree ...
5.7 are rather esoteric -> are, for now, rather esoteric
does not prevent -> does not completely prevent
5.8 Packet Interception and Removal and Packet Delay attacks
Note: one of my consistent comments on 03 was that the mechanisms were not consistently mapped to the threats.
This version is much better, but still not complete. Could you please directly map each mechanism to the threat it prevents/ameliorates ?
5.9 possibly add "or is too expensive to implement"
5.9.1 A protocol packet received from -> In this mode any protocol packet received from
You can remove "a bit"
explicitly defines -> refers to
A master in the hybrid mode SHOULD be -  but there is a general requirement for ALL masters to be secure. No ?
and not -> which is not

Section 6
Authentication of sender - MUST :  as I already commented above, this can not be true in general since it would
mean that all clocks must support security mechanisms.
Similarly for Integrity protection.

7.1 often require protocol packets to be -> often require that protocol packets be
with the time of transmission -> based on the time of transmission and/or reception
During transmission the security protocol must be applied after ->
  During transmission encryption and authentication MUST be applied after
What happened to the second sentence from the 03 version ?

6.3 RFC 5905 uses the term "secondary server" . You can save a lot of writing about stratum 1 and 2 !

In the paragraph  A common rule, I think the first must should be a MUST, while the second is correctly a "must".

7.4 packets are sent over -> packets are necessarily transported over  (it is not the sending that is important here, it is the transport)

Section 8  The key distribution -> Key distribution (can add that it is an "implementation issue")

I am not sure that I understand the relationship between 7.5.1 and 7.5.2.
I believe that the "early time" in 7.5.2 is a case of the "mutual dependence" of 7.5.1.

Y(J)S

---

From: Kevin Gross <[email-masked]>
Date: Mon, 18 Mar 2013 09:47:48 -0600

"Timing distribution protocols" is flawed because protocols distribute
time, not timing. "Time synchronization protocols" is flawed because the
protocols synchronize clocks; only god synchronizes time. NTP defines
itself through self-reference. 1588 seems to get it right, "IEEE standard
for a precision *clock synchronization protocol *for..."

On Mon, Mar 18, 2013 at 8:37 AM, Yaakov Stein <[email-masked]> wrote:

>  General  I personally prefer “timing distribution protocols”  to  “time
> synchronization protocols”,
>
> **
>
> as I think the protocol distributes the timing (time and/or frequency)****
>
> while the specific sync algorithm performs the synchronization.****
>
>
> **
>

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 21 Mar 2013 08:41:43 +0000

Kevin,

I don't entirely agree.

I can use PTP or NTP to distributed frequency without looking at the ToD
(even if it is correct).

So I would claim that they distribute timing, where by "timing" I mean time or frequency.

What the protocols definitely don't do is synchronize.
I guess one could claim that NTP does synchronize, since in addition to a protocol it specifies an algorithm for synchronizing a clock.
But 1588 does not specify the control loop, and thus does no synchronization at all!

Y(JS

Yaakov (J) Stein
CTO
T: +972-3-645-5389, +972-2-588-9159 | F: +972-3-647-5924  | [email-masked]<mailto:[email-masked]>
RAD Data Communications Ltd., 24 Raoul Wallenberg St., Tel-Aviv 69719, Israel  | www.rad.com<http://www.rad.com> | www.raddata.blogspot.com

From: Kevin Gross [mailto:[email-masked]]
Sent: 18 March, 2013 17:48
To: Yaakov Stein
Cc: [email-masked]; Tal Mizrahi
Subject: Re: [TICTOC] TICTOC Security Requirements

"Timing distribution protocols" is flawed because protocols distribute time, not timing. "Time synchronization protocols" is flawed because the protocols synchronize clocks; only god synchronizes time. NTP defines itself through self-reference. 1588 seems to get it right, "IEEE standard for a precision clock synchronization protocol for..."

On Mon, Mar 18, 2013 at 8:37 AM, Yaakov Stein <[email-masked]<mailto:[email-masked]>> wrote:
General  I personally prefer "timing distribution protocols"  to  "time synchronization protocols",
as I think the protocol distributes the timing (time and/or frequency)
while the specific sync algorithm performs the synchronization.

---

From: Kevin Gross <[email-masked]>
Date: Thu, 21 Mar 2013 09:17:13 -0600

In case I was not clear in my previous response, I propose we resolve this
by reusing terminology already used in authoritative documents and
standards, as opposed to what we, as individuals, might argue (at length)
is most correct and proper. If the authors want to go a different
direction, I'm fine with that; it's an editorial issue as far as I'm
concerned.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Thu, Mar 21, 2013 at 2:41 AM, Yaakov Stein <[email-masked]> wrote:

>  Kevin, ****
>
> ** **
>
> I don’t entirely agree.****
>
> ** **
>
> I can use PTP or NTP to distributed frequency without looking at the ToD**
> **
>
> (even if it is correct).****
>
> ** **
>
> So I would claim that they distribute timing, where by “timing” I mean
> time or frequency.****
>
> ** **
>
> What the protocols definitely don’t do is synchronize.****
>
> I guess one could claim that NTP does synchronize, since in addition to a
> protocol it specifies an algorithm for synchronizing a clock.****
>
> But 1588 does not specify the control loop, and thus does no
> synchronization at all!****
>
> ** **
>
> Y(JS****
>
> ** **
>
> *Yaakov (J) Stein***
>
> CTO****
>
> T: +972-3-645-5389, +972-2-588-9159 | F: +972-3-647-5924  | *
> [email-masked]* ****
>
> RAD Data Communications Ltd., 24 Raoul Wallenberg St., Tel-Aviv 69719,
> Israel  | www.rad.com | www.raddata.blogspot.com****
>
> ** **
>
> *From:* Kevin Gross [mailto:[email-masked]]
> *Sent:* 18 March, 2013 17:48
> *To:* Yaakov Stein
> *Cc:* [email-masked]; Tal Mizrahi
> *Subject:* Re: [TICTOC] TICTOC Security Requirements****
>
> ** **
>
> for a precision *clock synchronization protocol *for..."****
>
> ** **
>
> On Mon, Mar 18, 2013 at 8:37 AM, Yaakov Stein <[email-masked]> wrote:***
> *
>
> synchronization protocols”,****
>
> ** **