Re: [TICTOC] [ntpwg] security ID submitted for review
dieter.sibold@ptb.de Wed, 07 August 2013 12:45 UTC
Return-Path: <dieter.sibold@ptb.de>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2363D21F9808 for <tictoc@ietfa.amsl.com>; Wed, 7 Aug 2013 05:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.336
X-Spam-Level:
X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC1mg2xzDb4b for <tictoc@ietfa.amsl.com>; Wed, 7 Aug 2013 05:45:24 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.106]) by ietfa.amsl.com (Postfix) with ESMTP id D7CF011E811E for <tictoc@ietf.org>; Wed, 7 Aug 2013 05:45:23 -0700 (PDT)
Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A71EECE709A; Wed, 7 Aug 2013 14:45:22 +0200 (CEST)
Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by mx1.bs.ptb.de (Postfix) with ESMTP id 916E9CE7082; Wed, 7 Aug 2013 14:45:22 +0200 (CEST)
In-Reply-To: <20130807102324.GA17618@roeckx.be>
References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <52019C7B.9070602@udel.edu> <20130807102324.GA17618@roeckx.be>
To: Kurt Roeckx <kurt@roeckx.be>
MIME-Version: 1.0
X-KeepSent: 0D16CB83:CE739C1F-C1257BC0:0045BC00; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: <OF0D16CB83.CE739C1F-ONC1257BC0.0045BC00-C1257BC0.004610E0@ptb.de>
From: dieter.sibold@ptb.de
Date: Wed, 07 Aug 2013 14:45:18 +0200
X-MIMETrack: S/MIME Sign by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:45:18, Serialize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:45:18, Serialize complete at 07.08.2013 14:45:18, Itemize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:45:20, S/MIME Sign complete at 07.08.2013 14:45:20, Serialize by Router on ROSE/PTB(Release 8.5.3FP3HF370 | April 24, 2013) at 08/07/2013 14:45:22, Serialize complete at 08/07/2013 14:45:22
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="-------z21885_boundary_sign"
Cc: NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>, ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org, "David L. Mills" <mills@udel.edu>
Subject: Re: [TICTOC] [ntpwg] security ID submitted for review
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2013 12:45:29 -0000
Hello Kurt, thanks for your comments. Your are right that the draft currently does not specifies that the server has to sign the message during cookie message exchange. We shall add this to the next version of the draft. Dieter ---------------------------------- Physikalisch-Technische Bundesanstalt Dr. Dieter Sibold Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT-Infrastruktur Bundesallee 100 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de Von: Kurt Roeckx <kurt@roeckx.be> An: "David L. Mills" <mills@udel.edu> Kopie: NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org> Datum: 07.08.2013 12:23 Betreff: Re: [ntpwg] security ID submitted for review Gesendet von: ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org Hi Dave, On Wed, Aug 07, 2013 at 01:01:47AM +0000, David L. Mills wrote: > Kurt, > > Thanks for your reply. As a window of history, the Autokey protocol > was devised during several walks in Regents Park, London, in 1996. > I thought the most significant hazzard was the replay of client > messages requiring extensive server cryptographic computations. At > that time, I did not think that a middle-man attack would be > significant. Both of those assumptions are probably inadvisable > today. > > One problem with Autokey is the assumption that secret keys for each > client can be manufactured using packet header fields and a hash of > a server private value. A middle-man can manipulate the header > fields compromising the client private key. There does not seem to > be a solution for this problem other than requiring server state. This proposal also generates a cookie based on the something the client sends and a secret in the server, which is then encrypted using the client's public key. The ID does not mention that this message is signed by the server, but Stephen's mail said it was. This part is important to avoid the man in the middle attack. So as result the client got a unique secret for him, and only the client and the server known it. It can also be sure that it really comes from the server, so that there can be no man in the middle attack. And the server doesn't need to keep state since it can calculate it again based on what the client sends him. > In the current Autokey design, the MAC computation covers the header > and all extension fields. However, the key used for the MAC > computation in packets with extension fields is not private. > Therefore, in a cut-and-paste attack, an intruder could mix and > match extension fields and simply recalculate the MAC. If the key is not private, by adding extentions to a packet an attacker can just generate anything he wants? > RFC 5906 defines the extension field including the filestamp and > timestamp. The filestamp was designed to reliably associate the > cryptographic media with the current version, as it can be > frequently changed. This might not be useful in current designs. > The timestamp field was designed to detect replays requiring > expensive cryptographic computations which could take up to a > second. However, the "call gap" (minimum headway) provisions nicely > deflect such attacks, so the timestamp field might not be useful in > current designs. Lastly, in the current design, each extension > field is separately signed at the time the data were constructed. > In current designs the signature might be computed at the time of I'm not sure I understand what you're trying to say. I'm not sure what the filestamps are used for. But I assume that for instance for the leap seconds you send when it was last updates. I guess you can sign this once and always send this signed in an extension, even when you're otherwise not using any encryption. Since you already signed it, the overhead of adding that extension is small. The problem I see with only sending the MAC over the ntp headers and not over the extensions is that the extensions can be removed or added and the client can't tell. So it could for instance be replaced with an old version of the extension. I think it's important that the MAC covers everything. Kurt _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg
- [TICTOC] security ID submitted for review David L. Mills
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… David L. Mills
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… dieter.sibold
- Re: [TICTOC] [ntpwg] security ID submitted for re… dieter.sibold
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… David L. Mills
- Re: [TICTOC] [ntpwg] security ID submitted for re… Danny Mayer
- Re: [TICTOC] [ntpwg] security ID submitted for re… Greg Dowd