Re: [TICTOC] [ntpwg] security ID submitted for review
dieter.sibold@ptb.de Wed, 07 August 2013 12:19 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 B049D11E8129 for <tictoc@ietfa.amsl.com>; Wed, 7 Aug 2013 05:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 ezuAaqQhKjip for <tictoc@ietfa.amsl.com>; Wed, 7 Aug 2013 05:19:39 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.106]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7FF21E80D7 for <tictoc@ietf.org>; Wed, 7 Aug 2013 05:19:39 -0700 (PDT)
Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF793CE67F1; Wed, 7 Aug 2013 14:19:37 +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 D3BF2CE2DEB; Wed, 7 Aug 2013 14:19:37 +0200 (CEST)
In-Reply-To: <20130803174008.GA17578@roeckx.be>
References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be>
To: Kurt Roeckx <kurt@roeckx.be>
MIME-Version: 1.0
X-KeepSent: CF046B68:1B709B01-C1257BC0:002ECD08; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: <OFCF046B68.1B709B01-ONC1257BC0.002ECD08-C1257BC0.0043B5D5@ptb.de>
From: dieter.sibold@ptb.de
Date: Wed, 07 Aug 2013 14:19:33 +0200
X-MIMETrack: S/MIME Sign by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:19:34, Serialize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:19:34, Serialize complete at 07.08.2013 14:19:34, Itemize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:19:36, S/MIME Sign complete at 07.08.2013 14:19:36, Serialize by Router on ROSE/PTB(Release 8.5.3FP3HF370 | April 24, 2013) at 08/07/2013 14:19:36, Serialize complete at 08/07/2013 14:19:36
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="-------z50770_boundary_sign"
Cc: NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.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:19:44 -0000
Hello Dave and Kurt, thanks for your comments: As Kurt already pointed out. Currently the ID specifies only the design of the security protocol. We believe that we need to be clear about the design questions before specifying the technical details. The private key of the client is not needed for the MAC. Instead the calculation of the MAC includes the cookie and the whole NTP packet (i.e. the extension fields also). The cookie is calculated from the server seed and the client's public key, which the client attaches to each time request (which requires a new extension field as pointed out in the draft). During cookie exchange the server encrypts the cookie with the client's public key before transmission. An adversary is therefore not able to abuse a cookie which he requests in behalf of the client. As Kurt pointed out the certificate exchange works as in a standard PKI. I emphasize that this is different to autokey. In autokey the chain of trust and time are equal whereas in this ID chain of trust and time might be disjunct. Regarding the broadcast mode. I agree with Dave that the use of TESLA for the broadcast mode adds additional complexity. It also has the disadvantage that the authenticity of a packet can only be verified in retrospect. But I don't see security vulnerabilities. Dave's suggestion to use a combination of interleave mode with asymmetric cryptography is interesting. We should consider this. The argument that asymmetric cryptography might be feasible because of modern power of CPUs is okay for traditional computer systems but I'm not sure whether this assumption also applies for small devices with constrained resources. Regards 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: 03.08.2013 20:04 Betreff: Re: [ntpwg] security ID submitted for review Gesendet von: ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote: > Guys, > > Here are some general comments on the ID. I apologize if they are a > little rough as I have to dictate this message instead of my usual > polished wordsmithing. > > format. > The ID does not specify an extension field format. The draft only seems to specify the the general idea of how it should work and doesn't seem to go into detail how this should work at the protocol level. I assume he first wants to know if the solution is something that can work and that others see as a good solution before he works out the details. > In particular, the private key for the message > authentication code (MAC) , if used, must be known beforehand. This > is where the "cookie snatcher" issue comes up as described in > previous messages. In particular, an important constraint for > normal operation is that extension fields are not used unless > required for cookie determination. I'm not sure I understand your remark. As far as I know the "cookie snatcher" you talk about is the normal "man in the middle" attack. As I understand we would change the verification by replacing it by the normal X.509 verification as done for instance SSL/TLS. I assume you meant public key and note private key. > Glaring vulnerability exists when using extension fields, as the key > value is public and must be known in advance. This invites a > cut-and-paste attack, as well as header changes, even if > subsequently detected by the on-wire protocol. I've seen this cut-and-paste attack mentioned before, but I've never really understood it. As I understand things, the MAC is generated over the NTP + extensions. I don't see how you can take the extension from 1 packet into an other and still have a valid MAC. Or are you saying that you do something with a packet even when it doesn't have a valid MAC? > certificate. > Both RFC 5906 and the ID require the server certificate. The server > certificate can be conveyed, either off-line, or directly or > indirectly via a certificate trail as described in RFC 5906 or the > ID. If obtained via the trail, there is a hazzard due to a > middle-man attack and masquerade. I really don't understand how such a man in the middle attack can work. Either the certificate + the chain validate, or they don't. It is of course important to you check that the CommonName in the certificate matches the server you're trying to reach, and that the root CA is in your list of trusted CAs. But there really isn't anything new or hard about this. > In broadcast mode, the protocols described in RFC 5906 and the ID > are messy and with several possible vulnerabilities. Here is a > suggestion that might be useful. Define a new broadcast packet > format as the NTP header followed by one extension field > representing the MAC. The extension field represents the signature > of the header computed using the private key of the server and can > be verified by the client using the public key in the server > certificate. Originally, this was considered an unacceptable > dilution of accuracy due to the variability of the signature > computing time and the length of the signature. However, at least > in modern NTP, the interleaved broadcast mode can be used to correct > for this overhead. This assumes that the overhead for either the > server or client is reduced using fast modern processors. I think that in all cases where it's no problem to keep track of all clients you should use the interleaved mode, and we can use something like the Diffie-Hellman key agreement for those. But there clearly is also a need for servers that can't keep the state of each client, and we need something else for that. So maybe we need to define 2 ways of working. 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