Tal, Here are some comments on your draft. In general I find your idea of a framework for defining the necessary security support in timing protocols very helpful. I hope it will be a useful basis for the IEEE 1588 working group being convened when considering how to implement security functions in PTP.
Section 5.1
[Comment] It would be good to have each requirement statement uniquely numbered
to make it easy for implementors to reference the requirements directly.
Section 5.1.3
[Comment] Not clear here, if authorization is implicitly included in the
authentication requirement, or if it is implicitly excluded from the
authentication requirement and is not addressed in 5.1.3.
"(Requirement Level) Its low impact, i.e., in the absence of this requirement
the protocol is only exposed to DoS"
[Comment] Disagree. Absence of authentication of slaves may enable MITM attacks
delaying delay_req packets and thereby distorting the delay_req packet arrival
times and subsequent departure of delay_resp. The resulting asymmetry could
distort the subsequent slave clock offset calculations.
Slaves don't necessarily require authorization though.
"(Discussion)Slaves are authenticated by masters in order to verify that the
slave is authorized to receive timing services from the master."
[Comment] This conflation of authentication and authorization is not helpful.
Slaves could be authenticated to prevent MITM attacks against delay_req packets
without authorization. Authorization could be added for the purpose of
controlling master load and preventing DoS attacks as described in the text.
Suggest the following:
[Modify 'authenticate' to 'authorize']
Requirement
The security mechanism MAY provide a means for a master to authorize its
slaves.
[Add]
Requirement
The security mechanism MUST provide a means for a master to authenticate
its slaves.
Section 5.1.4
[Comment] Same motivation as 5.1.3 applies here. Suggest the same changes in
terms of MAY/MUST for authorization and authentication respectively.
Section 7.3
"The usage of intermediate nodes implies that if a security mechanism is
deployed in the network, all intermediate nodes must possess the security key"
[Comment] This is not true in the BC case since a BC fully terminates the sync
connection. A slave's master is just the next adjacent BC. In the BC case the
session key does not need to be shared across all nodes; each node can have a
unique key. In the TC case the nodes must have a shared session key, at least
for modification of the correction field as discussed earlier.
Hope this helps.
Russell.
Russell Smiley
Principal Systems Engineer
+1 613 592 0859 x1831 direct
+1 613 322 9433 mobile
[cid:[email protected]]
Integrated Device Technology, Canada Inc.
603 March Rd, Ottawa, Ontario Canada K2K 2M5
www.IDT.com NASDAQ: IDTI
CONFIDENTIAL COMMUNICATION: This email and any attachments thereto may contain
private and confidential material for the sole use of the intended recipient.
Any review, copying, or distribution of this email (or any attachments thereto)
by others is strictly prohibited. If you are not the intended recipient, please
contact the sender immediately and permanently delete the original and any
copies of this email and any attachments thereto.
From: [email protected] [mailto:[email protected]] On Behalf Of Tal
Mizrahi
Sent: Thursday, April 25, 2013 9:50 AM
To: [email protected]; [email protected]; Yaakov Stein ([email protected])
Subject: [TICTOC] Updated TICTOC Security Requirements
Hi,
Following the comments received on the WGLC I updated the draft - mostly minor
editorial updates.
The most notable changes compared to draft 04:
1. I added some text in the introduction about the target audience of the
document.
2. I changed "time synchronization protocols" to "time protocols", as
this seems to be the common grounds of NTP and PTP, both of which end with a TP
(Time Protocol). Seems like a fair compromise between Yaakov's suggestion and
Kevin's (http://www.ietf.org/mail-archive/web/tictoc/current/msg01382.html).
The current draft can be found in:
http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-05
Thanks,
Tal.
<<inline: image001.jpg>>
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
