[ntpwg] Autokey-Protocol Analysis

[Stephen Röttger]

On 08/03/11 06:00, Danny Mayer wrote:
> On 8/2/2011 4:11 PM, Stephen Röttger wrote:
[...]
>> 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).
> 
> Why do you think that it is necessary to go to all this trouble and
Please see my third point in my mail to greg.
Since the server holds no state about clients, he has no way of checking
that consecutive requests from an IP-address belong to the same client.
Therefor, an attacker can spoof his IP to that of a client and can
request the corresponding cookie from the server.
If the public key is included in this calculation, he will either not
get the same cookie as the client does or he will not be able to decrypt it.
> Where would the server get the client's public key?
The Client would have to attach it's public key to every request.
As a side note:
Since the length of the public key would cause the MAC calculation to
use at least one additional Round of the used hash-function, it could be
switched to the hash of the public key:
	C = H(H(PubKey), ServerSeed)
In this case there would be no additional overhead to the MAC-calculation.
> 
>>
>> -Change the length of Cookie and Server Seed from 32 to 128 bit.
>>
> Fine but what does it really buy us?
Again, please see point 1 in my mail to greg.
A 32-bit cookie and server seed can be easily brute-forced by an attacker.
> 
>> -Replace the Identity Schemes with a common X.509 PKI, where the Clients
>> are in possession of certificates of Trusted Authorities
>>
> 
> Does the PKI depend on reliable timm?
That is an interesting question.
The public key infrastructure used by SSL/TLS relies on certificate
revocation lists and expiration dates.
Expiration Dates can obviously not be verified before having doing the
time synchronisation, but that seems to be a chicken-or-egg problem.
> 
>> -Let the Signature included in extension fields cover the whole NTP-packet
>>
> 
> You need a way to signal this.
> 
>> -(optional) use HMAC for MAC-calculation and switch the used
>> Hash-Algorithms to SHA-256
> 
> This has already been raised as an issue. We believe it's just a minor
> issue in the reference implementation and the protocol already supports
> this. We don't believe that it is necessary to change the protocool for
> this.
Yes, we also think that this is not critical.
> 
> Danny
>>
>> Regards,
>> Dieter Sibold and Stephen Röttger