[secdir] SECDIR review of draft-ietf-ntp-ntpv4-proto-11

[Richard Barnes <[e-mail]>]

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.