[ntpwg] Autokey-Protocol Analysis
David L. Mills
mills at udel.edu
Thu Aug 4 16:13:26 UTC 2011
Thanks for your contributions in a security analysis of the Autokey
protocol, although it might have wider appeal in English. As it is, my
German is decidedly rusty, but I could translate if necessary.
Meanwhile, I have further refined my own analysis in the white paper
Security Analysis of the NTP Protocol
http://www.eecis.udel.edu/~mills/security.html, which includes probably
the same vulnerabilities as you report.
My analysis and most probably yours, identify two serious middleman
hazards, what I call the cookie snatcher and propaganda attacks. The
former is a tough one to fix and may yield to your insights, but I am
confused by your suggested fix. Any true fix has to consider both the
server private value and some sort of client private value, perhaps the
host encryption key.
For others that might be reading this message and for historical
context, the original Autokey design was circa 1996 as documented in an
internal report. Subsequently in the early 2000s the design was reviewed
by the STIME task force, which resulted in a revised specification in
late 2005. That document was submitted as an informational RFC and
eventually published five years later as RFC 5906. That RFC is intend as
target practice and a possible starting point for new algorithms. One
might observe this protocol is fifteen years old and the specification
was last reviewed in 2005. In any case, the existing code is
specifically designed in a modular fashion and can be removed and
replaced in whole or in part with evolved algorithms.
Note that our current discussion is on client/server mode that might be
used by a national time server network. However, the algorithms and
protocol also have to work in both basic and interleaved modes, and in
symmetric and broadcast modes. The algorithms and protocol also have to
support multiple security groups, as defined in the specification. I
suspect your analysis does not consider these modes, but mine does.
There continues to be issues in the initial volley in broadcast mode,
where the present code does not precisely calibrate the roundtrip delay.
Corrections for this are included, along with a careful analysis, in the
white paper Analysis and Simulation of the NTP On-Wire Protocols
There is a serious disconnect about the design intent of the protocol.
It was designed to operate with no assistive infrastructure at all. The
DNS is not necessary and there are no provision for certificate
verification other than the trusted host, for example a national time
server,. While not the original motivation for this model, it is
appropriate for the Mars spacecraft model suggested in Chapter 17 of my
book. Since the light time between Mars and Earth can be as much as 40
minutes, access to Earth infrastructure is highly awkward. Even so, the
certificate format conforms to X.500v3 and the certificate trail is
verified as in conformant PKI practice.
Your suggestion about signing the entire NTP packet has bee considered
before. However, a constraint you might have observed is that, except
for the glaring case of the cookie request, signatures are always
computed offline. Signing something in a flux of 3000 requests per
second is not an option..
Meanwhile, your suggestion on server cookie length and hash algorithm
are highly useful. Cookie length is easy to change, although it raises
backward compatibility issues. As you might have noticed in recent
documentation, selection of any hash algorithm supported by the OpenSSL
library is now possible.
I suspect there is not much more to say, so I recommend these issues be
raised and discussed by the working group at an upcoming IETF meeting. I
can't volunteer to do much, as my eyesight is dwindling to nothing and
messing with code is impractical.
Stephen Röttger wrote:
>Since the discussion about the Autokey-Protocol in June ended abruptly,
>we want to inform you, that we finished our analysis of the protocol and
>found several weaknesses, that render it completely useless.
>Our analysis is in German, but if you are interested in it, we can
>summarize the weaknesses for you.
>In addition, we came up with some changes to the protocol, that mitigate
>the vulnerabilities and would like to present you a revised
>The changes are:
>-Use the Clients Public Key used for cookie-encryption as input to the
>cookie calculation. For example, calculate the Cookie as
> C = H(PubKey, ServerSeed).
>-Change the length of Cookie and Server Seed from 32 to 128 bit.
>-Replace the Identity Schemes with a common X.509 PKI, where the Clients
>are in possession of certificates of Trusted Authorities
>-Let the Signature included in extension fields cover the whole NTP-packet
>-(optional) use HMAC for MAC-calculation and switch the used
>Hash-Algorithms to SHA-256
>Dieter Sibold and Stephen Röttger
>ntpwg mailing list
>ntpwg at lists.ntp.org
More information about the ntpwg