IETF Logo Mail Archive

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

Hal Murray <hmurray@megapathdsl.net> Sat, 29 August 2020 08:46 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 717E93A1229; Sat, 29 Aug 2020 01:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 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, 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 SOiALK2WG_qt; Sat, 29 Aug 2020 01:46:34 -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 777AA3A1228; Sat, 29 Aug 2020 01:46:31 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id C0F2E40605C; Sat, 29 Aug 2020 01:46:26 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
cc: Hal Murray <hmurray@megapathdsl.net>, kaduk@mit.edu, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>, draft-ietf-ntp-mode-6-cmds@ietf.org, odonoghue@isoc.org, The IESG <iesg@ietf.org>, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> of "Fri, 28 Aug 2020 08:30:49 +0200." <5F48A499020000A10003AF47@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 29 Aug 2020 01:46:26 -0700
Message-Id: <20200829084626.C0F2E40605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/mSSzieAUbKbNe3uohiTscQY2NlI>
Subject: Re: [Ntp] Antw: [EXT] Re: 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: Sat, 29 Aug 2020 08:46:37 -0000

Ulrich.Windl@rz.uni-regensburg.de said:
> While many decisions in the past were made to keep up backwards
> compatibility, the encryption type is set up indirectly vie the ntp.keys
> file. However (AFAIR) the file is not part of the NTP specification, so for
> the on-wire protocol there's no change to get the encryption type. One might
> guess, however.

> Probably this was an omission after the only encryption type (DES) had been
> extended to allow MD5 also (in NTPv3 AFAIR). The later on it was still
> forgotten. 

No, it's not an omission.  There is no need for the encryption type to be on 
the wire.  The admins for the client and server agree on the type while they 
are agreeing on the key and keyid.

The backwards compatibility was just good luck.


> Actually I don't understand the part: "The client and server or peer can use
> different values, but they must map to the same key." 

I think it's a bug.


-- 
These are my opinions.  I hate spam.

v2.23.0 | Report a Bug | By Email