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

From: Hal Murray <[email-masked]>
Date: Mon, 25 May 2020 00:56:06 -0700

I'm assuming the answer is "Yes" since RFC 8573 updated the idea to use AES 
and it was issued less than a year ago.  It seems like a good idea to have an 
alternative to NTS/TLS.

RFC 7822 from March 2016 describes the restrictions on extension lengths 
required to grandfather in the old non-extension MACs.  I think we should move 
MACs to an extension.

What that RFC doesn't describe is that shared keys require an explicit setup 
step by the server operator.  If the operator chooses as policy, not to 
support old style MACs, there is no reason for the code on her server to 
support them.  (or even know about them)

Is there any interest in an RFC for shared-key MACs in extensions?  I'm 
willing to do most of the editing if somebody will guide me through the 
process.

-------

Perhaps this should wait until NTPv5.  I'd rather get started now.

---

NTPsec has code that we inherited from the NTF/reference/Mills package to TCP 
out to a a Microsoft Samba/AD server to sign/check NTP packets.  Does anybody 
use that?

-- 
These are my opinions.  I hate spam.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 25 May 2020 10:30:46 +0200

> and it was issued less than a year ago.  It seems like a good idea to have an 

Definitely. It can be easily implemented and in local networks it is
practical.

> willing to do most of the editing if somebody will guide me through the 

There were at least two drafts that specified an extension field for
MAC:
https://datatracker.ietf.org/doc/draft-mayer-ntp-mac-extension-field/
https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/

Do we need a new draft?

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Mon, 25 May 2020 09:29:09 -0400

Yes, shared-key authentication is still interesting.

Putting the MAC in an extension field is clearly how NTPv4 should have done
things from the start, but I don't see any benefit in changing until the
legacy MAC field can be killed off entirely. So I would rather just pursue
this as part of NTPv5 than adopt a MAC EF draft for NTPv4.

I would like NTPv5's shared key authentication to be a little more closely
integrated with NTS. Either accomplish it by doing a PSK TLS handshake for
NTS-KE, or skip NTS-KE and have pre-shared S2C/C2S keys and a shorter
cookie giving just a key ID.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 25 May 2020 14:22:21 -0700

On 5/25/2020 6:29 AM, Daniel Franke wrote:
> Putting the MAC in an extension field is clearly how NTPv4 should have
> done things from the start,

Wow.  Exactly how would that have worked?

> but I don't see any benefit in changing
> until the legacy MAC field can be killed off entirely. So I would rather
> just pursue this as part of NTPv5 than adopt a MAC EF draft for NTPv4.
>
> I would like NTPv5's shared key authentication to be a little more
> closely integrated with NTS. Either accomplish it by doing a PSK TLS
> handshake for NTS-KE, or skip NTS-KE and have pre-shared S2C/C2S keys
> and a shorter cookie giving just a key ID.
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

---

From: Daniel Franke <[email-masked]>
Date: Mon, 25 May 2020 17:45:01 -0400

> Wow.  Exactly how would that have worked?

 This is a bizarre question coming from a co-author of
draft-mayer-ntp-mac-extension-field. What do you think would have been
troublesome? If NTPv4 — the same version which introduced extension fields
— had specified that everything following the header is an extension field,
specified one such extension field containing a key-id and MAC, and
forbidden NTPv3-style legacy MACs from appearing in v4 packets, then
everything would be straightforward, there would be no syntactic ambiguity,
and RFC 7822 would not have been needed.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 25 May 2020 14:47:04 -0700

On 5/25/2020 2:45 PM, Daniel Franke wrote:
> On Mon, May 25, 2020 at 5:22 PM Harlan Stenn <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> troublesome? If NTPv4 — the same version which introduced extension
> fields — had specified that everything following the header is an
> extension field, specified one such extension field containing a key-id
> and MAC, and forbidden NTPv3-style legacy MACs from appearing in v4
> packets, then everything would be straightforward, there would be no
> syntactic ambiguity, and RFC 7822 would not have been needed.

I stand in awe of your hubris.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 26 May 2020 10:55:41 -0400

On Mon, May 25, 2020 at 9:29 AM Daniel Franke <[email-masked]> wrote:
> Putting the MAC in an extension field is clearly how NTPv4 should have done things from the start, but I don't see any benefit in changing until the legacy MAC field can be killed off entirely. So I would rather just pursue this as part of NTPv5 than adopt a MAC EF draft for NTPv4.
>
> I would like NTPv5's shared key authentication to be a little more closely integrated with NTS. Either accomplish it by doing a PSK TLS handshake for NTS-KE, or skip NTS-KE and have pre-shared S2C/C2S keys and a shorter cookie giving just a key ID.

I think PSK TLS is a better idea: all the complexity gets dumped on
the TLS stack, while the NTP specific parts don't change.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 May 2020 17:23:28 +0200

> the TLS stack, while the NTP specific parts don't change.

A different point of view would be to avoid exposing the NTS+TLS stack
to attackers if not necessary. The complexity of the NTP MAC is
minimal when compared to that.

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 May 2020 11:34:31 -0400

I could go either way on this. What moves me a bit toward Miroslav's point
of view is that the PSK handshakes in TLS 1.3 unfortunately did not get the
same care and attention from the TLS WG as the rest of the protocol did,
and as a result we got things like https://eprint.iacr.org/2019/347.pdf.
This particular attack doesn't harm us since we distinguish between client
and server packets at the application level, but it suggests that if we're
considering relying on TLS-PSK we can't simply assume that the TLS WG has
given us an adequate foundation to build on; we need to check their work
and make that assessment ourselves.

On Tue, May 26, 2020 at 11:23 AM Miroslav Lichvar <[email-masked]>
wrote:

> handshake for NTS-KE, or skip NTS-KE and have pre-shared S2C/C2S keys and a
> shorter cookie giving just a key ID.
> >

---

From: Hal Murray <[email-masked]>
Date: Tue, 26 May 2020 09:47:06 -0700

[email-masked] said:
> A different point of view would be to avoid exposing the NTS+TLS stack to
> attackers if not necessary. The complexity of the NTP MAC is minimal when
> compared to that. 

Indeed.  The external dependencies are reduced to an AES package and test 
vectors are available for that.

In addition to the complexity and exposure of the code, there is also the 
documentation.

RFC 8573, MAC for NTP (AES), is 5 pages, mostly boilerplate.
NTS for NTP (draft 26) is 44 pages.

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 26 May 2020 19:06:16 +0200

Also, NTS is not designed for NTP’s symmetric mode, which will be well 
served by the old approach.

Dieter

---

From: Hal Murray <[email-masked]>
Date: Tue, 26 May 2020 11:37:14 -0700

[email-masked] said:
> There were at least two drafts that specified an extension field for MAC:

> Do we need a new draft? 

Thanks.

They are both written by the same people and are quite similar so I'll only 
discuss the second one which is several years newer.

It describes 3 new extensions.
  The first is a last-extension extension, so anything following must be a MAC.
  The second is what I was looking for - just an extension header (4 bytes) 
with the body being the MAC.
  The third has multiple MACs.  They might be useful for broadcast.

There are several other ideas in there (or the previous draft).

A 4 byte MAC of all 0s is a Crypto-NAC.  (The earlier draft had type 0, length 
0 being a NAC.)

The length of the MAC provides the attacker with some information about the 
algorithm being used.  Perhaps the MAC should be padded to 68 bytes in order 
to hide that.

-----------

I wasn't clear in my initial message.  I'm trying to simplify the code and 
documentation.  I think we should avoid multiple ways to do the same thing.

I prefer the wrapper rather than the last-extension.  It seems more extension 
like.  I'd be happy with either.

-----------

Is broadcast interesting?  Is there a sane way to secure it?

I'm only a second class crypto geek, but I expect the real geeks have a term 
for sharing a key with many users.  (as well as a culture that says 
don't-do-that)

Again, I'm interested in simplifying things so I don't like this option.

-----------

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?

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?  ...

-----------

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?

-----------

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.