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 protected]] Sent: Thursday, August 02, 2012 12:49 PM To: Tal Mizrahi Cc: [email protected] 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 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/840 >> b >> 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
