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

From: Yaakov Stein <[email-masked]>
Date: Thu, 12 Mar 2009 09:37:40 +0200

For all of you who are not subscribed to the IETF discussion list ...

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, March 11, 2009 04:50
To: IESG; SECDIR; IETF Discussion; [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "Greg Dowd" <[email-masked]>
Date: Thu, 12 Mar 2009 08:40:35 -0700

Would the specification of RFC4270 as a cited reference for the
continued use of MD5 MAC scheme be preferable.  In that rfc, there is a
note that the currently available techniques are collision attack which
primarily effect the use of MD5 mac in signatures for non-repudiation
and certificates.  

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
Yaakov Stein
Sent: Thursday, March 12, 2009 1:38 AM
To: [email-masked]
Subject: [ntpwg] FW: SECDIR review of draft-ietf-ntp-ntpv4-proto-11

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Wednesday, March 11, 2009 04:50
To: IESG; SECDIR; IETF Discussion;
[email-masked]
Subject: SECDIR review of draft-ietf-ntp-ntpv4-proto-11

document.

either or both of:

---

From: David Mills <[email-masked]>
Date: Thu, 12 Mar 2009 23:16:03 +0000

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

---

From: Danny Mayer <[email-masked]>
Date: Fri, 13 Mar 2009 09:38:39 -0400

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

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