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:image002.jpg@01CDC41A.21180AF0]
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: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Thursday, April 25, 2013 9:50 AM
To: tictoc@ietf.org; odonoghue@isoc.org; Yaakov Stein (yaakov_s@rad.com)
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.