[ntpwg] Autokey-Protocol Analysis

[David L. Mills]

Stephen,

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 
http://www.eecis.udel.edu/~mills/onwire.html.

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.

Dave

Stephen Röttger wrote:

>Hello everyone,
>
>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
>Autokey-protocol.
>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
>
>Regards,
>Dieter Sibold and Stephen Röttger
>_______________________________________________
>ntpwg mailing list
>ntpwg at lists.ntp.org
>http://lists.ntp.org/listinfo/ntpwg
>  
>