SECDIR review of draft-ietf-ntp-ntpv4-proto-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]