All, Karen has urgently requested comments to draft-mizrahi-tictoc-security-requirements. So here are my comments. They are based on version 01 from March 12, 2012.
This draft is meant to be for PTP and NTP. Yet please note that I'm not very familar with PTP. So my comments are formulated with NTP in mind. (i) Section 1., question (3). I don't understand this question. Please expressed it more clearly? (ii) Section 4.1.2 (Proventication of Masters) This requirement might be natural in PTP. However in NTP - as far as I understand it - the root of the time sychronization tree and the authentication tree can be different. To illustrate this: consider the case in which a stratum 2 server is connected to two stratum 1 servers: let the first be the end of the authority tree, the so-called trusted authority (TA) and let us assume the second one does not provide authentication at all. If we further assume that the first stratum 1 server has the better clock then eventually the stratum 2 server will choose the first stratum 1 server as system peer because NTP's selection algorithm does not consider authentication. Now we end up in a situation that for a NTP client that is connected to the stratum 2 server the time synchronization tree ends at the second stratum 1 server whereas his authorization tree ends at the first stratum 1 server. This requirement therefore would conflict with the current specification of autokey. So, an alternative formulation could be: Proventication of the authentication root. So the authentication root and time sync root can but have not to be on the same clock. Furthermore, I think this requirement is somewhat redundant to 4.9.1/2. (iii) Section 4.3 In your discussion to this requirement you claim, that authentication of clocks is sufficient to achieve this goal. This presumes that all authenticated clocks behave well which you can only assure if you have control over these clocks. But this is not always the case. E.g., if an organization like an National Metrology institute would provide an authenticated NTP service to the public it won't have control over these client. (iv) Section 4.6 I agree with the performance requirements in the case if we consider security requirements for a security protocol for PTP or NTP. But coming back to section 1., question (2) this draft also considers external security practices for which the requirements in 4.6 are probably to strong. So, the title of section 4 should make clear, that it considers time specific security protocols only. (v) Section 4.9.1 That is an adequate requirement. I'm just asking myself if this could also be accomplished by authentication, which is already required in 4.1. (vi) Section 4.9.2 4.9.1 together with 4.9.2 ensures requirement 4.1.2 (proventication) if I see it right. But keep in mind, that 4.9.2 conflicts with autokey. (vii) Section 6 Section 6 is in parts a duplication of the introduction. I'd like to emphazise on the second bullet (the question regarding the external security mechanism). I believe, that tunnel solutions, like IPSec or OpenVPN are used a lot, because in many use cases people need an authorized time source for legal reasons or for the purpose of traceability but without high demands on accuracy. Just as Karen mentioned yesterday in the case of smart grids which is also the case in Germany. Therefore, it might be reasonable to add a list of available external security practices together with their influence on time synchronization to this draft. So people would be able to decide if they timing requirements they have are still met if an external security mechanism is applied. Hope this is useful Regards Dieter
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
