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

Hal Murray <hmurray@megapathdsl.net> Tue, 26 May 2020 18:37 UTC

Return-Path: <hmurray@megapathdsl.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34F33A0B05 for <ntp@ietfa.amsl.com>; Tue, 26 May 2020 11:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.036
X-Spam-Level: *
X-Spam-Status: No, score=1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n-6krxUxBxH for <ntp@ietfa.amsl.com>; Tue, 26 May 2020 11:37:19 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 870783A0AF0 for <ntp@ietf.org>; Tue, 26 May 2020 11:37:18 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 6514740605C; Tue, 26 May 2020 11:37:14 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Miroslav Lichvar <mlichvar@redhat.com>
cc: ntp@ietf.org, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Miroslav Lichvar <mlichvar@redhat.com> of "Mon, 25 May 2020 10:30:46 +0200." <20200525083046.GB25987@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 26 May 2020 11:37:14 -0700
Message-Id: <20200526183714.6514740605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/N365_0nLuv83obE_XpOd16-XkSM>
Subject: Re: [Ntp] Post NTS, Is shared key authentication interesting?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2020 18:37:21 -0000

mlichvar@redhat.com said:
> 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? 

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.


-- 
These are my opinions.  I hate spam.