Re: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-mode-6-cmds-09: (with DISCUSS and COMMENT)

Hal Murray <hmurray@megapathdsl.net> Thu, 27 August 2020 09:00 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 B847F3A0819; Thu, 27 Aug 2020 02:00:40 -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, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=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 kZ6WJpx1tQie; Thu, 27 Aug 2020 02:00:39 -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 D71F23A0818; Thu, 27 Aug 2020 02:00:38 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 87B9840605C; Thu, 27 Aug 2020 02:00:34 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Benjamin Kaduk <kaduk@mit.edu>
cc: The IESG <iesg@ietf.org>, ntp-chairs@ietf.org, ntp@ietf.org, draft-ietf-ntp-mode-6-cmds@ietf.org, odonoghue@isoc.org, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Benjamin Kaduk via Datatracker <noreply@ietf.org> of "Wed, 26 Aug 2020 14:29:00 PDT." <159847733996.28106.1103367714274362245@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 27 Aug 2020 02:00:34 -0700
Message-Id: <20200827090034.87B9840605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/5hbBXAi2QQ09HjRMEXUtgaCnyNg>
Subject: Re: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-mode-6-cmds-09: (with DISCUSS and COMMENT)
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: Thu, 27 Aug 2020 09:00:41 -0000

Benjamin Kaduk  said:
> The considerations of BCP 201 with respect to algorithm agility appear to be
> quite relevant, with the 96-bit authenticator format locking us into at best
> 64 bits of MAC, which is fairly weak for Internet use, and 32 bits of key
> identifier.  This presents its own problems, as 32 bits is too small for a
> value that is unilaterally assigned by many/all participants and expected to
> be globally unique, but is rather large for a key identifier space that is
> centrally managed for use within a single administrative domain.  (The
> currently specified DES-CBC checksum from RFC 1305 is, of course, considered
> insecure at this point, as with all things single-DES.) 

We are down in the weeds, but ...

The 32 bit Key-ID is not globally unique.  With existing code, it's per 
server.  There is no reason that it couldn't be per client-server.  (That is 
unlikely to work if the client is using DHCP.)

An additional complication is that Autokey (RFC 5906) uses the top 16 bits so that leaves only 16 bits for manual assignment.

----------

Thanks for pointing out the 64 bit MAC.  I've been working in this area for a long time and don't remember seeing any 8 byte MACs.  It would be an interesting archeology project to figure out when support for MD5 (16 bytes) and SHA-1 (20 bytes) was added to the code.

RFC 8573 added AES-128 CMACs.

RFC 7822 describes the results of a lot of discussion about how to make old MACs coexist with extension fields.   My memory is that the discussion focused on 16 and 20 byte MACs as used by MD5 and SHA-1.  I think the wording in the RFC supports 20 or shorter.  I don't think any code supports 8 byte MACs.

In practice, in addition to agreeing on the Key and Key-ID, you also have to agree on the algorithm.  There is nothing in the packet that tells you which algorithm to use.  A while ago, you could make a good guess between MD5 and SHA-1 based on the length.  But now, AES-128 is also 16 bytes.  


-- 
These are my opinions.  I hate spam.