Subject: [Ntp] Antw: [EXT] Re: Post NTS, Is shared key authentication interesting?

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 27 May 2020 11:33:20 +0200

>>> Hal Murray <[email-masked]> schrieb am 26.05.2020 um 20:37 in
Nachricht
<15818_1590518253_5ECD61ED_15818_1499_1_20200526183714.6514740605C@ip-64-139-1-6
.sjc.megapath.net>:

[...]
> 
> Are crypto NACs interesting?  Is the added complexity worth the benefit?
> 
> If all you get is "NAC", what do you do next when trying to debug things?  
> What's different from what you would do if you didn't get any reaponse?

Just assume on any error that can happen for a https connection you don't get
a response...
I fyou are in control of client AND server, you may not need crypto NACs. If
you are in control of the server, you also may not need crypto nacs, but if you
only have access to the client and the responses, crypto nacs seem valuable
IMHO.

> 
> Should we have a separate extension type for Crypto NAC, possibly with a 
> text 
> payload.  How many sub‑types are there?  Will that leak information?  ...

I think it will not leak more information than before. An optional textual
description seems like a good idea. Maybe the server could be restricted to
provide such, or not. A model like SMTP's extended status codes sounds like a
good idea to me (codes for computers, messages for humans (and maybe computers,
too).

> 
> ‑‑‑‑‑‑‑‑‑‑‑
> 
> How important is it to hide the algorithm? Is padding good enough?  Is a min

> 
> length that we pick now going to cause problems tomorrow?

Security by obscurity is not the better security IMHO. At least not when
regarding the algorithm being used.

> 
> ‑‑‑‑‑‑‑‑‑‑‑
> 
> Note that "MAC" is slightly ambiguous in this context.  At the low level, it

> 
> is just some bits you get from a crypto routine.  At the NTP level (this 
> discussion), it is the combination of a key‑ID (4 bytes) and the low level 
> MAC.

Maybe call this "signature" in the future? Or X-MAC (eXtended MAC)?

Regards,
Ulrich

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 27 May 2020 11:55:36 +0200

> good idea to me (codes for computers, messages for humans (and maybe computers,

I'm not sure I fully understand what you're talking about, but
sending an error message that something with the crypto was bad
it a bad idea. You should pretend that everything was ok. An
attacker should not be able to see the difference between an ok
and a not ok message. Look for instance at the TLS RFCs what they
write about a Bleichenbacher attack.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 27 May 2020 12:02:32 +0200

> write about a Bleichenbacher attack.

Since we're talking about a shared (symatric) key, it's probably not
that important.

Kurt

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 27 May 2020 12:24:59 +0200

> write about a Bleichenbacher attack.

That doesn't look to me like it would apply to the NTP authentication
using a crypto hash function or AES-(SIV-)CMAC. With Autokey and NTS
the server can respond with a NAK message to let the client know it is
using an old key/cookie. The client doesn't need to guess what is
wrong and can quickly start a new key establishment.

With a symmetric key, there is not much the client can do when it
receives a NAK, except maybe log an error message. I'm not sure how
useful that would be. The admin should be able to figure it out what's
wrong even with no error message.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 27 May 2020 03:34:06 -0700

> wrong even with no error message.

The admin will figure out there is a problem sooner if there is an
explicit indication of a problem.

Why should this not be a mechanism/policy choice?

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 27 May 2020 14:45:09 +0200

>>> Kurt Roeckx <[email-masked]> schrieb am 27.05.2020 um 12:02 in Nachricht
>> > >>> Hal Murray <[email-masked]> schrieb am 26.05.2020 um 20:37
in
<15818_1590518253_5ECD61ED_15818_1499_1_20200526183714.6514740605C@ip-64-139-
> 1-6
>> > Just assume on any error that can happen for a https connection you don't

> get
>> > a response...
>> > I fyou are in control of client AND server, you may not need crypto NACs.

> If
>> > you are in control of the server, you also may not need crypto nacs, but
if 
> you
>> > provide such, or not. A model like SMTP's extended status codes sounds
like 
> a

OK, I thought the discussion was more general. AFAIR there's no response if
improper authentication was supplied for symmetric keys.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 27 May 2020 14:49:40 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 27.05.2020 um 12:24 in
Nachricht <20200527102459.GA1749@localhost>:
> using a crypto hash function or AES‑(SIV‑)CMAC. With Autokey and NTS

Whether a server ignores  a non-authentic message or responds with a more or
less verbose error diagnostic should be configurable by the server admin. In
general ignoring would be OK for public servers, but in more controlled
environments an error response can be helpful to debug problems. The protocol
specification should allow receipt of error responses (in a format to be
defined).

> ‑‑

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 May 2020 13:33:00 +0000

Yes!

This is known as an oracle, and from this kind of thing, it is possible to do pretty fine-grain timings and figure out keys.  This is often surprising to folks, but look up "Lucky Thirteen" as an example.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 27 May 2020 06:37:35 -0700

> This is known as an oracle, and from this kind of thing, it is possible to do pretty fine-grain timings and figure out keys.  This is often surprising to folks, but look up "Lucky Thirteen" as an e…

So where is this attacker?

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 May 2020 13:41:46 +0000

>    So where is this attacker?

On the network.  Anywhere on the Internet.

Maybe for this case it doesn't matter (I am not convinced), but it is worth reinforcing as a design principle.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 27 May 2020 09:44:33 -0400

On Wed, May 27, 2020 at 9:33 AM Salz, Rich <rsalz=
[email-masked]> wrote:

>
> This is known as an oracle, and from this kind of thing, it is possible to
> do pretty fine-grain timings and figure out keys.  This is often surprising
> to folks, but look up "Lucky Thirteen" as an example.
>

While this is certainly a thing to keep in mind whenever designed error
responses in crypto protocols, the crypto-NAKs in legacy NTP and NTS are
both fine. The reason this is so incredibly hairy in TLS (prior to 1.3) is
that the protocol asks the server to accept malleable ciphertext from an
untrusted source and then take actions based on the corresponding
plaintext. All NTP has to do is send an error message if a MAC doesn't
validate. This is much safer, because the MACed message is not secret and
is non-malleable.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 27 May 2020 06:46:33 -0700

> Maybe for this case it doesn't matter (I am not convinced), but it is worth reinforcing as a design principle.

I think one could easily implement a bad system where this would be a
problem.

In the normal use-case and with a "normal" implementation, I'm not
seeing how this can be a problem.  I'm open to seeing that I'm missing
something, however.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 27 May 2020 09:50:57 -0400

> seeing how this can be a problem.  I'm open to seeing that I'm missing

Rich is correct that error oracles and timing oracles are a big, scary
problem in a lot of crypto protocols, and you're correct that in the
particular context we're discussing, there's nothing to worry about.