Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer
Harlan Stenn <stenn@ntp.org> Mon, 07 March 2016 23:11 UTC
Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfc.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 172BA1CDD85 for <ietfarch-ntp-archives-ahFae6za@ietfc.amsl.com>; Mon, 7 Mar 2016 15:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hlIU_Xk5PBU for <ietfarch-ntp-archives-ahFae6za@ietfc.amsl.com>; Mon, 7 Mar 2016 15:11:08 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfc.amsl.com (Postfix) with ESMTP id E9B8C1CDD7B for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 7 Mar 2016 15:11:08 -0800 (PST)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7A09F86DB25 for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 7 Mar 2016 23:11:08 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from stenn.ntp.org (stenn.ntp.org [IPv6:2001:4f8:fff7:1::30]) by lists.ntp.org (Postfix) with ESMTP id E096586D764 for <ntpwg@lists.ntp.org>; Mon, 7 Mar 2016 22:47:23 +0000 (UTC)
Received: from [::1] (helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.86 (FreeBSD)) (envelope-from <stenn@stenn.ntp.org>) id 1ad3uf-000EcV-1I; Mon, 07 Mar 2016 22:46:05 +0000
From: Harlan Stenn <stenn@ntp.org>
To: Miroslav Lichvar <mlichvar@redhat.com>
In-reply-to: <20160307131625.GA3209@localhost>
References: <4569da98236441699fb26aebb71f90a7@IL-EXCH01.marvell.com> <E1acVNL-000CK8-RW@stenn.ntp.org> <20160307093202.GJ20222@localhost> <E1acsHr-000Dmy-Bf@stenn.ntp.org> <20160307112840.GK20222@localhost> <E1acuOC-000Dwm-SV@stenn.ntp.org> <20160307131625.GA3209@localhost>
Comments: In-reply-to Miroslav Lichvar <mlichvar@redhat.com> message dated "Mon, 07 Mar 2016 14:16:25 +0100."
X-Mailer: MH-E 7.4.2; nmh 1.6; XEmacs 21.4 (patch 24)
Mime-Version: 1.0 (generated by tm-edit 1.8)
Date: Mon, 07 Mar 2016 22:46:04 +0000
Message-Id: <E1ad3uf-000EcV-1I@stenn.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>
Miroslav Lichvar writes: > On Mon, Mar 07, 2016 at 12:35:56PM +0000, Harlan Stenn wrote: > > Originally, if there was an extension field there MUST be a MAC. > > Right. That requirement was not necessary and it was later removed. Really? Please say more. Where can I learn about this? > > Tal wrrote Errata 3627 (or whatever) and removed that requirement. > > Yes, but why is that a problem? Because one can legislate the value of pi to be 3 since that would make so many things easier. That doesn't mean it's going to work in the real world. >> MAC protection is good. NTS uses a 'single' Field Type, but the first >> few packets have no MAC protection. Therefore, the first few packets of >> an NTS exchange arguably MUST have MAC protection outside the NTS >> packet > > With what key would that MAC be generated? Unless I misunderstood how > NTS is supposed to work, the first few packets are simply not > authenticated and can't be used for anything except initialization of > the NTS association. Symmetric key would be an OK choice here. Preferably using the "MAC in an EF". >> We're getting ready to publish a "MAC in an Extension Field", and >> arguably this is how it should have been originally done. So in keeping >> with the above logic, there are 2 pieces of information we want to see >> for an extension field. One is "SHOULD or MAY have MAC protection after >> this field," and the other is "This extension field provides MAC >> protection." > > What will the receiver of this information do with it? Whatever it wants. This goes to giving the client basic information that is useful in deciding what to do in case the client gets EFs it doesn't understand. > The client must > have its own policy on what extension fields has to be covered with > MAC in order to accept the packet. The server can't dictate that. Of course. > Normally, the client will require all fields to be covered by MAC if > authentication is enabled. Yes. So where is the confusion here? >>>> - Use a flag bit in the Field Type that says "My extension field does >>>> not require a following MAC." >>> >>> Meaning the field is not related to authentication? >> >> Meaning "My extension field does not require a MAC after it". This is >> the "MAY" case as opposed to the "SHOULD" case. An example of this is >> Tal's checksum complement proposal, as currently written. If ntpd sends >> out an unauthenticated packet, the FPGA engine is free to rewrite the >> transmit timestamp, but since the OS has already computed a UDP >> checksum, if the transmit timestamp in the packet is changed it's almost >> certain that a checksum complement will be needed to make sure the >> existing UDP checksum will still be correct. That's what Tal's proposal >> is all about, and it's the first time we've seen a proposal for an >> extension field where one MUST NOT have a MAC at the end of the packet. > > Ok, but that information is already included in the specification. The > client or server that generates that field needs to know that. The >sender< needs to know. The >recipient< might be running old software, current software, or software that's aware of these new EFs. This all goes to what happens down the road when a newer sender is talking to an older recipient. If a recipient gets data it does not understand, it may benefit from a hint as to what's going on with that unknown EF. >>> The SHA1 MAC is 24 octets, that's why there is a requirement for the >>> last extension field to be at least 28 octets. >> >> 4 byte keyid plus 24 octets. So 28 bytes is clearly potentially >> ambiguous. > > A SHA1 MAC has 160 bits for the digest and 32 bit for the key ID. > That's 192 bits or 24 octets total. OK. What I remember is hearing that we were seeing 3 sizes of old-style MACs, and they were 20, 24, and 28 bytes' long. I'll see what I can find out. >> Extension fields of 4, 8, 12, or 16 bytes are also unambiguous. Why >> prohibit these lengths? > > Because MAC in a packet from an old client could be parsed as one or > multiple extension fields. An old client will ONLY send autokey. So this is a non-issue, right? It's pretty easy to parse an EF and make sure it's sane. If the current spot in the extended payload parses as a good EF, then one can do a quick check on any following data in the payload and get a good idea as to what's going on. At worst, you have a packet that CORRECTLY parses as both "a bunch of EFs" and "an old-style MAC in a packet that either has no extension field or is an autokey packet". If only one of those interpretations is correct, then we can dance on the head of the false-negative or false-positive pin. Remember, this is *only* a POTENTIAL problem when mixing new and old implementations. In that case folks may need to administratively segregate these machines. We can certainly solve this problem in NTPv5. >>>> - a MAC consists of a 4-byte keyid and a payload. If there is no >>>> autokey extension field, the keyid MUST be <65535, and we SHOULD have >>> >>> Isn't that restriction for keyid just for the autokey RFC? There are >>> NTP implementations that allow any keyid with symmetric keys. >> >> Originally: >> >> - any extension field meant there MUST be a MAC. >> - the only defined extention field as been autokey. >> - if no extension field was present, then no autokey, and a MAC meant >> symmetric key was being used. keyid < 65535. >> - if an extension field was present, the autokey was being used, there >> MUST be a MAC, and keyid > 65535. > > That applies to the reference implementation, but not necessarily for > other NTPv4 implementations. They can parse extension fields, but they > don't have to know anything about autokey and can authenticate with > MACs using key IDs above 65535. The RFCs have clear requirements on the keyids. If an implementation chooses to be non-compliant that's the implementer's choice. An implementation that makes this choice has no leg to stand on if it doesn't interoperate with compliant implementations. And in this case it's not really that bad either - this older and non-compliant implementation simply has to see if the 32-bit keyid is a valid key in order to disambiguate the packet. But we're back to the point where if you're running NTP networks where you have both old and new NTP instances, you may need to have a way to identify which machines are "old" and which are "new" and communicate accordingly. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg
- [ntpwg] The next step of draft-ietf-ntp-checksum-… Tal Mizrahi
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Harlan Stenn
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Miroslav Lichvar
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Tal Mizrahi
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Harlan Stenn
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Miroslav Lichvar
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Harlan Stenn
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Miroslav Lichvar
- Re: [ntpwg] The next step of draft-ietf-ntp-check… dieter.sibold
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Harlan Stenn
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Harlan Stenn
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Danny Mayer
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Danny Mayer
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Harlan Stenn
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Harlan Stenn
- Re: [ntpwg] The next step of draft-ietf-ntp-check… kristof.teichel
- Re: [ntpwg] The next step of draft-ietf-ntp-check… Danny Mayer