Subject: Re: [ntpwg] Replay protection (was: Forward of NTS discussion #1)

From: [email-masked]
Date: Fri, 14 Mar 2014 10:04:07 +0100

Hello everyone,

I agree with Stephen in that I also think that a nonce protection of the
client_cook/server_cook message exchange  would be a good idea, to avoid
any immediate damage by leaking of old cookie/seed values.

For the client_cert/server_cert exchange, I am not sure if there is
anything further we need to do.
I agree with Stephen that it should not be important if the certificate
chain was in fact sent by the time server, or replayed by someone else, as
long as its contents are valid. The only attack scenario that I can come up
with here would be an attacker using an old leaked private key of the
server (which seems to me like it needs to be handled via Certificate
Revocation Lists or something along those lines). Am I missing anything
obvious?
I am wondering if, in server_cert, we would gain anything by having the
server sign a nonce with his private key that the message is certifying.
This would give some proof of liveness, but it does not seem to have any
real advantage.

No matter for which handshake message, I feel like signing the current time
might be an unreliable security measure (given that someone might connect
to an NTP server without the slightest idea if their clock is currently
even remotely correct). Involving nonces that need to be signed seems more
likely to succeed.

Kristof

> On Wed, Mar 5, 2014 at 14:20 PM, "Steven M. Bellovin"
<[email-masked]
>  wrote:
> > Looking further , there's a serious risk of replay of the server_cert
> > message. The best defense is to have a random challenge in the client
> > message; the reply should sign it. Alternatively, sign the current time
in
> > the reply.
>
> In the server_cert message we don't sign anything and thus we don't
> rely on the authenticity of the received information.
> However, there is a replay possibility in the cookie exchange since
> we don't protect it with a nonce yet.
>
> So there are two possible scenarios what an attacker can do:
>     1. The attacker replays a cookie message for a still valid cookie.
>     2. He replays an old cookie message after the server has changed its
seed.
>
> Number 1 is not an attack on this step since this would have been
> the real response of the server anyway, i.e. the attacker doesn't
> get new information and neither changes the information received by
> the client.
>
> In 2. the attacker can force the client to use an old cookie. This
> old cookie or the old server seed might have been leaked in some
> way, i.e. we shouldn't rely on this value being secret anymore. Thus
> I think we should introduce a nonce in this step as well.
>
> Stephen

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg