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

[Danny Mayer]

I'm including Richard on this reply as I don't believe that he's on the
WG mailing list. My apologies to Richard if I have the wrong person. I'm
also including Dave's response for Richard.

The MAC issue is really a red herring. It is not there to provide any
type of authentication or proof that the packet has not been tampered
with but as an additional sanity check. In addition it is optional when
you don't have any extension fields. The size of the MAC field is
variable and can be changed. I have discussed with Dave the possibility
of having a way of indicating the type of digest being used but we have
not yet come to agreement on that.

In client/server mode the client sends a packet with a timestamp in it
and it will check the same timestamp and the responding IP address when
it is returned to ensure that it is the reply to the request. MIM
attacks are possible of course, but if the timestamps in a response are
too far off, they get discarded. A MIM attack would have to catch all
packets meant for different servers every time to be successful in any
way and that's without authentication mechanisms. Authentication is
described in a separate document and that draft is informational at this
point because there are questions that need to be answered on the
authentication protocol.

The issue of broadcast servers (in NTP terms broadcast means both
broadcast and multicast) is due to the packet not being solicited by the
receiving client so any system can be set up to broadcast bad packets.
The solution to this is to use an authentication mechanism like autokey
so that the client can check to see whether or not the broadcaster is
authentic having been given keys OOB for such a broadcaster.

As Dave says, authentication is done by the client of the server and not
the other way round. The server does not have a need to authenticate the
client, it's just handing out timestamps and is not acting as a consumer
of the client packets.

The autokey protocol document is informational at this time and
describes several different authentication schemes. The extra complexity
in the scheme is due to the fact that, unlike most authentication
schemes, it cannot rely on the clock being valid at any point during the
authentication exchange. You cannot check for example to see if a
certificate has expired, you have no way of knowing that.

The two documents together give people ways of adding new authentication
mechanisms in a way that will allow for interoperability and we welcome
other methods of authenticating servers.

I hope this clarifies matters.

Danny


David Mills wrote:
> 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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.