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.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf