Subject: [TICTOC] TICTOC Security Requirements

From: Dan Grossman <[email-masked]>
Date: Thu, 02 Aug 2012 12:49:53 -0400

Tal,
I wasn't able to get meeting audio, so don't know whether this was 
discussed.

My main concern with the draft concerns transparent clocks, as in 
section 4.1.4.  A  PTP transparent clock is really just a Layer 2 or IP 
forwarder with a timestamping mechanism based on a syntonized timebase.  
Every forwarder on the master-slave path with significant queueing and 
other variable delays must have the transparent clock mechanism, else 
there will be loss of accuracy.   Any forwarder can mount a MITM DOS 
attack on a secured clock correction field by corrupting it. To say 
nothing of greatly complicating the forwarding process and perhaps even 
adding inaccuracy.

Which leads me to suggest that perhaps rather than trying to 
authenticate the TC and protect the clock correction field as security 
mechanisms in the PTP or its encapsulation  might cause more problems 
and risks than the threats they eliminates.    Maybe it would be better 
to think about this as a secure routing or signaling problem, and use 
signaling or routing to constrain the set of feasible paths to those 
which have a trusted, authenticated TC on each hop.  This becomes a 
problem for RSVP or LDP for the MPLS encapsulation, and OSPF and ISIS 
for IP tunneling.   I suspect (have not dug into it, though) that most 
of the mechanisms we'd need already exist.

Dan

On 8/2/2012 12:10 PM, [email-masked] wrote:
>
>
> Date: Thu, 2 Aug 2012 19:10:39 +0300
> From: Tal Mizrahi <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [TICTOC] TICTOC Security Requirements
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-02
>
> Following this week's TICTOC meeting:
>
> 1.       We plan to release draft 03 within a month, and proceed to WG last call.
>
> 2.       Therefore, I will appreciate if people can send any comments they may have by Aug 22.
>
> 3.       There was some discussion about the "proventication" requirement. I would like to suggest to change the terminology in the document, since I understand this term is not very popular.
> However, I believe that the requirement for a chain of trust is still an important and valid requirement. Please comment if you think otherwise.
>
> Thanks,
> Tal.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/tictoc/attachments/20120802/840b451f/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>
>
> End of TICTOC Digest, Vol 68, Issue 10
> **************************************
>

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 2 Aug 2012 20:17:07 +0300

Hi Dan,

I understand your concern: basically the synchronization protocol can be compromised by a MITM attack even if the TCs are authenticated.
However, it sounds like you are suggesting a solution, and this document attempts to focus on requirements and not solutions.
Authenticating the TC prevents simple attacks that can be performed by "weak" attackers, referred to in the document as external injector attackers. It does not prevent more advanced attacks from "advanced" attackers, e.g., internal attackers, or MITM delay attacks. I find it essential to require that the security mechanism prevents the easiest-to-implement attacks, as these are the most likely ones.

I suggest to add a description to this section in the document, and clarify the point above.

Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Grossman
Sent: Thursday, August 02, 2012 9:50 AM
To: [email-masked]
Subject: [TICTOC] TICTOC Security Requirements

Tal,
I wasn't able to get meeting audio, so don't know whether this was discussed.

My main concern with the draft concerns transparent clocks, as in section 4.1.4.  A  PTP transparent clock is really just a Layer 2 or IP forwarder with a timestamping mechanism based on a syntonized timebase.  
Every forwarder on the master-slave path with significant queueing and other variable delays must have the transparent clock mechanism, else 
there will be loss of accuracy.   Any forwarder can mount a MITM DOS 
attack on a secured clock correction field by corrupting it. To say nothing of greatly complicating the forwarding process and perhaps even adding inaccuracy.

Which leads me to suggest that perhaps rather than trying to authenticate the TC and protect the clock correction field as security mechanisms in the PTP or its encapsulation  might cause more problems 
and risks than the threats they eliminates.    Maybe it would be better 
to think about this as a secure routing or signaling problem, and use signaling or routing to constrain the set of feasible paths to those which have a trusted, authenticated TC on each hop.  This becomes a problem for RSVP or LDP for the MPLS encapsulation, and OSPF and ISIS 
for IP tunneling.   I suspect (have not dug into it, though) that most 
of the mechanisms we'd need already exist.

Dan

On 8/2/2012 12:10 PM, [email-masked] wrote:
> -------------- next part -------------- An HTML attachment was 
> scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/tictoc/attachments/20120802/840b
> 451f/attachment.htm>
>

---

From: Dan Grossman <[email-masked]>
Date: Thu, 02 Aug 2012 15:48:43 -0400

Hi Tal,

I appreciate the need to avoid crossing the line between requirements 
and mechanisms, and was trying hard not to.  If anything, I had the 
sense that Section 4.1.4 was hinting at particular mechanisms.

Thanks for explaining your rationale for  TC authentication.  It makes 
more sense to me now. You're right, more detail is needed here.  
However, I'm wondering if it wouldn't be redundant with Master 
authentication, at least for end-to-end transparent clocks.  After all, 
an injection attack would also have to spoof an authenticated master.  
Am I missing something?

Rgds
Dan

---

From: Tal Mizrahi <[email-masked]>
Date: Fri, 3 Aug 2012 00:48:48 +0300

Dan,

> However, I'm wondering if it wouldn't be redundant with Master authentication, at least for end-to-end transparent clocks.  
>After all, an injection attack would also have to spoof an authenticated master.

Your point is well taken. An external injector cannot masquerade an E2E TC.
I suggest to elaborate the description, and emphasize the difference between an E2E TC and a P2P TC in this aspect.

Your point referred to section 4.1.4, which is currently a SHOULD (not a MUST). Do you see a problem to leave it a SHOULD?

Tal.

-----Original Message-----
From: Dan Grossman [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 12:49 PM
To: Tal Mizrahi
Cc: [email-masked]
Subject: Re: [TICTOC] TICTOC Security Requirements

Hi Tal,

I appreciate the need to avoid crossing the line between requirements and mechanisms, and was trying hard not to.  If anything, I had the sense that Section 4.1.4 was hinting at particular mechanisms.

Thanks for explaining your rationale for  TC authentication.  It makes more sense to me now. You're right, more detail is needed here.  
However, I'm wondering if it wouldn't be redundant with Master authentication, at least for end-to-end transparent clocks.  After all, an injection attack would also have to spoof an authenticated master.  
Am I missing something?

Rgds
Dan

---

From: Dan Grossman <[email-masked]>
Date: Mon, 06 Aug 2012 16:00:15 -0400

Tal,
Let me suggest some words.  This isn't exactly parallel construction 
with the rest of this section, but I think the subject is different 
enough to justify that:

4.1.4 
<http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-02#section-4.1.4>. 
PTP: Authentication of Transparent Clocks

Requirement

    The combination of security mechanisms for PTP, and routing and control plane mechanisms
    SHOULD provide a means to authenticate TCs along the Master-Slave path.

Discussion

    Correct PTP operation depends upon trusted transparent clocks at each hop along the
    Master-Slave path (except for hops which have negligible variable latency, such as hubs).
    The accuracy of the PTP can be attacked by malicious TCs which deliberately
    manipulate the correctionField, by inserting forwarders which are not TCs
    in the path, or (for Peer-to-Peer TCs) manipulate Pdelay_Req, Pdelay_Resp or
    Pdelay_Follow-up messages. Malicious TCs (and other forwarders) can also be used for MITM
    attacks, including DoS and accuracy attacks.

    Note that determination of the Master-Slave path is outside the scope of PTP.   Therefore,
    this requirement will need to be addressed at least in part by mechanisms congruent to
    path determination, i.e., routing and control plane.

Does this make sense?
Dan