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
On 8/2/2012 5:48 PM, Tal Mizrahi wrote:
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
