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
On 8/2/2012 1:17 PM, Tal Mizrahi wrote:
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 protected] [mailto:[email protected]] On Behalf Of Dan
Grossman
Sent: Thursday, August 02, 2012 9:50 AM
To: [email protected]
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 protected] wrote:
Date: Thu, 2 Aug 2012 19:10:39 +0300
From: Tal Mizrahi <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [TICTOC] TICTOC Security Requirements
Message-ID:
<[email protected]>
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/840b
451f/attachment.htm>
------------------------------
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
End of TICTOC Digest, Vol 68, Issue 10
**************************************
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
