[ntpwg] FW: SECDIR review of draft-ietf-ntp-ntpv4-proto-11

[David Mills]

Yaacov,

Thanks for passing along the review.

The original  text I wrote, including the statements on security, have 
been marked up many times by many others in response to comments from 
the security community. That community has evolved over the several 
years the ID has been in review and markup. I and/or the editors and 
maybe other volunteers can make what changes might be indicated, but at 
this late and critical stage we need specific and focussed direction.

To say that  the NTP security model is to "authenticate the endponts" is 
too strong. The intent is for a client  to authenticate the server. 
There is no intent for a server to authenticate the client, only the 
key. There are means in place to hand out keys in a secure way, but that 
does not belong in the spec.

I beg to differ on the view that the MD5 message digest is custom. As it 
says in the text, the algorithm is as specified in rfc1321. This was 
originally designed by RSA Labs, although some might prefer a stronger 
hash du jour. The packet format supports digests of 8-octet , 16-octet 
and 20-octet lengths. The future intent is to allow any digest algorithm 
supported by the OpenSSL library for each digest length, but that is 
intended for a future document. The MD5 is supported for current and 
legacy systems; changing it now would give heart attacks to the national 
labs of several countries.

It is indeed the view that  MD5 birthdays might be considered too 
frequent. However, it is not trivial at all to find a NTP message with 
the same digest and passes all the sanity checks built into the 
protocol. I don't think it makes sense to argue the point in the ID; I 
would rather raise it in a future document as mentioned above. Frankly, 
I don't believe advice should be in the documeng at all; others might 
not agree.

Autokey is not on the table here. That ID is not on a standards track; 
it is intended as informational. In any case it does not need S/MIME to 
distribute group keys; they are public values.

Dave

Yaakov Stein wrote:

>For all of you who are not subscribed to the IETF discussion list ...
>
>Y(J)S
>
>-----Original Message-----
>From: ietf-bounces at ietf.org [mailto:ietf-bounces at ietf.org] On Behalf Of Richard Barnes
>Sent: Wednesday, March 11, 2009 04:50
>To: IESG; SECDIR; IETF Discussion; draft-ietf-ntp-ntpv4-proto at tools.ietf.org
>Subject: SECDIR review of draft-ietf-ntp-ntpv4-proto-11
>
>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 mailing list
>Ietf at ietf.org
>https://www.ietf.org/mailman/listinfo/ietf
>_______________________________________________
>ntpwg mailing list
>ntpwg at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/ntpwg
>  
>