Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer

Miroslav Lichvar <mlichvar@redhat.com> Mon, 07 March 2016 09:53 UTC

Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9F1B3DA0 for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Mon, 7 Mar 2016 01:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 8ase1cQoKe-L for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Mon, 7 Mar 2016 01:53:22 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id A40041B3D9E for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 7 Mar 2016 01:53:22 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 71BEA86DB56 for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 7 Mar 2016 09:53:22 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 466FB86D4A6 for <ntpwg@lists.ntp.org>; Mon, 7 Mar 2016 09:32:15 +0000 (UTC)
Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <mlichvar@redhat.com>) id 1acrWG-0006Zj-4u for ntpwg@lists.ntp.org; Mon, 07 Mar 2016 09:32:15 +0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 93BF872088; Mon, 7 Mar 2016 09:32:03 +0000 (UTC)
Received: from localhost (dhcp-24-154.brq.redhat.com [10.34.24.154]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u279W2wC022303; Mon, 7 Mar 2016 04:32:03 -0500
Date: Mon, 07 Mar 2016 10:32:02 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Harlan Stenn <stenn@ntp.org>
Message-ID: <20160307093202.GJ20222@localhost>
References: <4569da98236441699fb26aebb71f90a7@IL-EXCH01.marvell.com> <E1acVNL-000CK8-RW@stenn.ntp.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <E1acVNL-000CK8-RW@stenn.ntp.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 07 Mar 2016 09:32:03 +0000 (UTC)
X-SA-Exim-Connect-IP: 209.132.183.28
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org
X-SA-Exim-Mail-From: mlichvar@redhat.com
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Subject: Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <http://lists.ntp.org/pipermail/ntpwg/>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Cc: "'ntpwg@lists.ntp.org'" <ntpwg@lists.ntp.org>, "Karen ODonoghue (odonoghue@isoc.org)" <odonoghue@isoc.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Sender: ntpwg <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>

On Sun, Mar 06, 2016 at 09:53:23AM +0000, Harlan Stenn wrote:
> Autokey was defined with the requirement that its extension field be
> protected by a MAC.  The revising language in Errata 3627 does not
> address this at all.  One immediate recommendation is that 3627 be
> amended to say that a MAC SHOULD be present in any packet that includes
> any extension fields.

Why? I think presence of MAC should be required by individual
extension fields which implement some form of authentication, it
shouldn't be a general suggestion. Hopefully in future we will have
extension fields for other things than authentication, and they can be
used without authentication.

> If we're really that concerned about this problem, then all we need to
> do is to create a new extension field, 8 bytes long, which indicates "I am
> the last extension field", so any data after that would be an old-style
> MAC. 

What would prevent a server from misinterpreting a random MAC in a
client packet that doesn't include this extension field as some
extension field?

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg