I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines an update to the Network Time Protocol, a
mechanism that Internet hosts can use to synchronize their clocks.  I


have strong reservations about the security mechanisms specified in this 


document.




The central security requirement for this protocol is that protocol
endpoints be authenticated and that messages be integrity-protected.
These protections are provided primarily by signing messages with a
custom MD5-based MAC (i.e., not HMAC-MD5), as in NTPv3, although
extensions are included to enable the use of the Autokey scheme for


using X.509 certificates to authenticate digital signatures.  Both of 


these schemes are a little bit troubling.






For the MAC scheme: In addition to using a custom MAC instead of a more 


standard one, the MAC relies on the MD5 hash function, for which there 


are known algorithms to find collisions.  I would expect the document to 


either or both of:



1. Replace MD5 with a stronger hash
2. Argue that the weaknesses in MD5 do not lead to MAC vulnerabilities


The document seems to take the latter approach by referring to an NDSS 


paper on hash transitions.  However, this paper does not address the 


vulnerabilities of MD5-based MACs in any detail (the closest it comes is 


to say that "because TLS uses HMAC, the current collision-only attacks 


most likely do not represent a threat"), much less consider the special 


MAC used by NTP (v3 and v4).  I would suggest the authors find a better, 


more specific reference, or incorporate a mechanism for hash agility.






For the Autokey scheme: I have not reviewed Autokey thoroughly, but my 


initial impression is that it is a far more complicated scheme than is 


necessary for the simple distribution and revocation of keys for NTP. 


(ISTM that it would suffice to have, e.g., a simple format for 


specifying keys and KEYIDs, encapsulated in S/MIME and distributed 


either out of band or in a special payload type.)  In any case, it seems 


inappropriate for a Standards-track document to refer to a cryptographic 


protocol described only in a university-internal technical report.  Such 


a scheme should be subject to the same standard of review as other 


cryptographic systems used within IETF protocols.






The document properly notes that as specified, broadcast clients are 


vulnerable to DoS attacks from some broadcast servers, but only says 


that "Access controls and/or cryptographic authentication means should 


be provided for additional security in such cases."  This text should be 


replaced with something more precise, even if only to say "Protections 


against these attacks is left to future work" without specifying what 


the solution would look like.