Subject: [Ntp] Duration of authentication

From: Kurt Roeckx <[email-masked]>
Date: Tue, 17 Mar 2020 17:50:31 +0100

Hi,

It's my understanding that once the peer is authenticated using
NTS-KE, it can keep using that peer forever without having to check
that it's still actually talking to the correct peer.

I would like to place a limit on the validity, like 7 days. NTS-KE
should then be repeated.

The key can be compromised, and the only way I see to check that
it's still valid is to do NTS-KE again.

I'm wondering if we should at least suggest OCSP stapling.

Kurt

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 17 Mar 2020 18:48:14 +0100

Hi Kurt!

I am one of the authors of the NTS draft. The IETF Last Call for it
ended on February 28. That was technically the last opportunity to come
with suggestions for changes to the draft. This does not mean that your
comments aren't valid and I will try to answer them as best as I can below.

> that it's still actually talking to the correct peer.

That is true and a deliberate design decision.

> I would like to place a limit on the validity, like 7 days. NTS-KE

It is already possible to implement that functionality on both the
client and server side. On the client side, it would just be a question
of making it repeat the NTS-KE exchange every seven days.

An NTP and NTS-KE server pair that wishes to require a seven-day forced
renegotiation could place a timestamp inside the encrypted cookie which
indicates when the original NTS key exchange took place. NTP requests
with cookies that have timestamps older than a set limit (seven days in
this case) could then be replied to with an NTS NAK kiss code instead of
a valid time response. This would force a key renegotiation.

> it's still valid is to do NTS-KE again.

Indeed, but this is a deliberate design decision. NTP and NTS-KE server
operators are expected to remove compromised keys as soon as the
compromise is discovered. This would cause the NTP servers to respond
with NTS NAK, thus forcing key renegotiation. I am aware that this does
not protect against MITM attacks where the attacker has access to a
compromised cookie encryption key.

> I'm wondering if we should at least suggest OCSP stapling.

It's too late to suggest technical changes at this point unfortunately,
but there's nothing preventing NTS-KE operators from doing this.

Kind regards,
Marcus Dansarie