Re: [TICTOC] [ntpwg] security ID submitted for review

[Kurt Roeckx <[e-mail]>]

Hi Dave,

On Wed, Aug 07, 2013 at 01:01:47AM +0000, David L. Mills wrote:
> Kurt,
> 
> Thanks for your reply.  As a window of history, the Autokey protocol
> was devised during several walks in Regents Park, London, in 1996.
> I thought the most significant hazzard was the replay of client
> messages requiring extensive server cryptographic computations.  At
> that time, I did not think that a middle-man attack would be
> significant.  Both of those assumptions are probably inadvisable
> today.
> 
> One problem with Autokey is the assumption that secret keys for each
> client can be manufactured using packet header fields and a hash of
> a server private value.  A middle-man can manipulate the header
> fields compromising the client private key.  There does not seem to
> be a solution for this problem other than requiring server state.

This proposal also generates a cookie based on the something the
client sends and a secret in the server, which is then encrypted
using the client's public key.

The ID does not mention that this message is signed by the server,
but Stephen's mail said it was.  This part is important to avoid
the man in the middle attack.

So as result the client got a unique secret for him, and only
the client and the server known it.  It can also be sure that
it really comes from the server, so that there can be no man
in the middle attack.  And the server doesn't need to keep
state since it can calculate it again based on what the client
sends him.

> In the current Autokey design, the MAC computation covers the header
> and all extension fields.  However, the key used for the MAC
> computation in packets with extension fields is not private.
> Therefore, in a cut-and-paste attack, an intruder could mix and
> match extension fields and simply recalculate the MAC.

If the key is not private, by adding extentions to a packet an
attacker can just generate anything he wants?

> RFC 5906 defines the extension field including the filestamp and
> timestamp.  The filestamp was designed to reliably associate the
> cryptographic media with the current version, as it can be
> frequently changed.  This might not be useful in current designs.
> The timestamp field was designed to detect replays requiring
> expensive cryptographic computations which could take up to a
> second.  However, the "call gap" (minimum headway) provisions nicely
> deflect such attacks, so the timestamp field might not be useful in
> current designs.   Lastly, in the current design, each extension
> field is separately signed  at the time the data were constructed.
> In current designs the signature might be computed at the time of

I'm not sure I understand what you're trying to say.

I'm not sure what the filestamps are used for.  But I assume
that for instance for the leap seconds you send when it was
last updates.  I guess you can sign this once and always send
this signed in an extension, even when you're otherwise not
using any encryption.  Since you already signed it, the overhead
of adding that extension is small.

The problem I see with only sending the MAC over the ntp headers
and not over the extensions is that the extensions can be removed
or added and the client can't tell.  So it could for instance
be replaced with an old version of the extension. I think it's
important that the MAC covers everything.


Kurt