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

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Wed, 27 May 2020 09:33 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 443243A0C06 for <ntp@ietfa.amsl.com>; Wed, 27 May 2020 02:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aZgMdRhWJcfn for <ntp@ietfa.amsl.com>; Wed, 27 May 2020 02:33:29 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e7a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6453A0C05 for <ntp@ietf.org>; Wed, 27 May 2020 02:33:29 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id 94B7C6000053 for <ntp@ietf.org>; Wed, 27 May 2020 11:33:24 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx4.uni-regensburg.de (Postfix) with ESMTP id 80E2B6000052 for <ntp@ietf.org>; Wed, 27 May 2020 11:33:21 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 27 May 2020 11:33:21 +0200
Message-Id: <5ECE33E0020000A10003934B@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.1
Date: Wed, 27 May 2020 11:33:20 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "Hal Murray" <hmurray@megapathdsl.net>,<mlichvar@redhat.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <68248D4C020000916A6A8CFC@gwsmtp.uni-regensburg.de> <54A83DA70200003B43047E14@gwsmtp.uni-regensburg.de>
In-Reply-To: <54A83DA70200003B43047E14@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/VQvJAcS9KdqWTzyGkYlDzUIRwag>
Subject: [Ntp] Antw: [EXT] Re: 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: Wed, 27 May 2020 09:33:31 -0000

>>> Hal Murray <hmurray@megapathdsl.net> schrieb am 26.05.2020 um 20:37 in

> 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

> 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,

> ‑‑‑‑‑‑‑‑‑‑‑
> 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)?