Last Call Review of draft-ietf-ntp-ntpv4-proto-

Request Review of draft-ietf-ntp-ntpv4-proto
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-03-10
Requested 2009-02-26
Authors Jim Martin, Jack Burbank, William Kasch, David Mills
Draft last updated 2009-03-13
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Review review-ietf-ntp-ntpv4-proto-secdir-lc-barnes-2009-03-13
Review completed: 2009-03-13


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 


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.