Re: [TICTOC] Comments on draft-ietf-tictoc-security-requirements-03

[Doug Arnold <[e-mail]>]

I agree with Kevin Gross that this document on security requirements is welll written, organized and informative. The background material is comprehensive, and yet very concise.  It is potentially useful to the IEEE 1588 committee as well as to the IETF.  I have some comments on the choices for SHALL (required), SHOULD (recommended) and MAY (allowed) amongst the various requirements.

The authentication of PTP slaves and NTP clients a aught to be allowed, but not required or recommend (MAY).  There are likely many applications where authentication of slaves is undesirable or unimportant.  This is especially true for the design of an Ordinary Clock, which is master capable, but is not usually in that mode.  Such devices often have less processing resources than Preferred Grandmasters. It is likely also true for NTP servers when there are a large number of clients, and the policy is for servers to answer them all, to the best of their ability.  Note that the draft calls for low storage and bandwidth demands for NTP servers.  That could be challenging if there are thousands of clients to authenticate.

I suggest demanding that Announce Messages SHALL be authenticated since these are crucial to proper functioning of the PTP Best Master Clock Algorithm in multicast mode.

I second the comments of Kevin Gross on DoS security (see below).

Protection against delay attacks is too important a topic only to be a MAY.  I suggest that this be recommended (SHOULD).  Realistically it might be that the protocol only makes this possible, and doesn't solve it.  Part of the solution might be in the end device clock control software which, at least for PTP, is outside of the scope of the standard.

//Doug Arnold


________________________________
From: [e-mail] [[e-mail]] on behalf of Kevin Gross [[e-mail]]
Sent: Friday, November 16, 2012 3:01 PM
To: [e-mail]
Subject: [TICTOC] Comments on draft-ietf-tictoc-security-requirements-03

Thanks for putting this draft together. I found it to be well written, well organized and very informative. I have some comments.

General:

Use MITM acronym defined in 2.2 instead of spelling it out many times

By sections:

1 - Add playback to the list of attacks when synchronization is compromised.

1 - s/The IEEE 1588 includes/IEEE 1588 includes/

1 - Provide definition or example for "packet timing deployments"

2.1 - s/"protocol packets" is refers/"protocol packets" refers/

3.1 - s/documents/document/

3.1.1 - Authentication and encryption can be used together. s/by an encryption or an authentication mechanism./by an encryption or an authentication mechanism or both.

3.1.2 - s/eavesdrop to protocol/eavesdrop on protocol/

3.2 - Other threats to consider:
Rogue transparent clock. A remedy is discussed in 4.1.4 but it is not documented as a threat.
Rogue boundary clock
Unauthorized receipt

3.2.9 - s/spoof the GPS satellites/spoof GPS satellite signals/

3.3 s/Attacket/Attacker/

Table 1 - Add a couple +'s:
Replay attack can be perpetrated by an external injector
Packet delay manipulation can cause accuracy degradation

4 - Add references for IPsec and MACsec

4.1.4 - Discuss TC authentication can prevent rogue TC from degrading accuracy. Mention that this whole section is not applicable to NTP.

4.1.5 - Repeats discussion in 4.1. These two sections should at least acknowledge each other.

4.1.5 - s/prevent malicious master/prevent rogue master/

4.2 - s/ensures the authenticity and completeness/ensures the integrity and completeness/

4.2.1.1 - s/Hop by Hop Integrity Protection/Hop-by-Hop Integrity Protection

4.2.1.1 - s/allows malicious TCs/allows rogue TCs/

4.2.1.1 - a/End to End Integrity Protection/End-to-End Integrity Protection/

4.3 - I guess depends on the scope of these recommendations but I don't think is it feasible to require DoS protection. Also, you don't protect a protocol from DoS you protect a device or a service. We SHOULD be protecting the device and its network stack from DoS. Or the device and its network interface MUST recover once a DoS has resolved.

4.4 - "MUST be resistant" is not a well-defined requirement

4.4 - This section is missing a Discussion sub-section

4.5.3 - This section is missing a Discussion sub-section

4.6 - "SHOULD be relatively lightweight" is not a well-defined requirement. Suggestion: "SHOULD minimize computational load".

4.6 - "SHOULD not require excessive storage" is not a well-defined requirement. Suggestion: "SHOULD minimize storage requirements".

4.6 - Move "as client restrictions often dictate a low processing and memory footprint, and    because the server may have extensive fan-out." from requirements to discussion sub-section

4.7 - s/against packet delay attacks/against packet delay, manipulation and interception and removal attacks/

4.9 - s/a gradual process/incremental deployment/

6.1 - No packets are required to be modified on reception. The requirement is to record and associate an arrival timestamp with received packets. Remove discussion of reception modifications. Suggested modified text:

   Time synchronization protocols often require protocol packets to be
   modified during transmission. Both NTP and PTP in one-
   step mode require clocks to modify protocol packets with the time of
   transmission.

   In the presence of a security mechanism, whether encryption or
   integrity protection:

   o During transmission the security protocol must be applied after
      integrating the timestamp into the packet.

   To allow high accuracy, timestamping is typically performed as close
   to the transmission time as possible. However, since the
   security engine must be placed between the timestamping function and
   the physical interface, it may introduce non-
   deterministic latency that causes accuracy degradation. These
   performance aspects have been analyzed in the literature, e.g., in
   [1588IPsec] and [Tunnel].

6.2 - Two-step pertains only to transmission times. Suggested modified text:

   PTP supports a two-step mode of operation, where the time of
   transmission of protocol packets are
   communicated without modifying the packets. As opposed to one-step mode,
   two step timestamping can be performed without the requirement to encrypt after timestamping.

6.5 - Discuss bootstrapping issue. You need a certificate to receive time. You need time to validate a certificate.


Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.AVAnw.com>, www.X192.org<http://www.X192.org>