From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sun Jul 7 15:11:54 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5C11E8130 for ; Sun, 7 Jul 2013 15:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 iFQcMjNopZee for ; Sun, 7 Jul 2013 15:11:51 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFDD11E814E for ; Sun, 7 Jul 2013 15:11:47 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D1FEB86DAB3 for ; Sun, 7 Jul 2013 22:11:46 +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 3855186D4E3 for ; Sun, 7 Jul 2013 22:11:27 +0000 (UTC) Received: from mail.ietf.org ([2001:1890:123a::1:1e]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UvxB0-0006Ds-2y for ntpwg@lists.ntp.org; Sun, 07 Jul 2013 22:11:27 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771A911E814E for ; Sun, 7 Jul 2013 15:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 QzDWVB3X8Vcn; Sun, 7 Jul 2013 15:11:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1484911E813B; Sun, 7 Jul 2013 15:11:20 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2013 15:11:19 -0700 X-SA-Exim-Connect-IP: 2001:1890:123a::1:1e X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: internet-drafts@ietf.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol Working Group of the IETF. Title : Network Time Security Author(s) : Dieter Sibold Stephen Roettger Filename : draft-ietf-ntp-network-time-security-00.txt Pages : 12 Date : 2013-06-28 Abstract: This document describes the Network Time Security (NTS) protocol that enables secure authentication of time servers using Network Time Protocol (NTP) or Precision Time Protocol (PTP). Its design considers the special requirements of precise timekeeping, which are described in Security Requirements of Time Protocols in Packet Switched Network [I-D.ietf-tictoc-security-requirements]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ntp-network-time-security-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sun Jul 7 16:19:10 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A4711E814C for ; Sun, 7 Jul 2013 16:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] 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 0RM2Sh711Adb for ; Sun, 7 Jul 2013 16:19:05 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9557221F9B45 for ; Sun, 7 Jul 2013 16:19:05 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C664086D763 for ; Sun, 7 Jul 2013 23:19:02 +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 0E64486D4E3 for ; Sun, 7 Jul 2013 23:18:53 +0000 (UTC) Received: from georges.telenet-ops.be ([195.130.137.68]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UvyEF-0006Y6-9h for ntpwg@lists.ntp.org; Sun, 07 Jul 2013 23:18:53 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by georges.telenet-ops.be with bizsmtp id xbJo1l00F0zFtyu06bJoE9; Mon, 08 Jul 2013 01:18:48 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 92FC0EB341; Mon, 8 Jul 2013 01:18:48 +0200 (CEST) Date: Mon, 8 Jul 2013 01:18:48 +0200 From: Kurt Roeckx Cc: ntpwg@lists.ntp.org Message-ID: <20130707231848.GA32053@roeckx.be> References: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.137.68 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Sun, Jul 07, 2013 at 03:11:19PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Time Protocol Working Group of the IETF. > > Title : Network Time Security > Author(s) : Dieter Sibold > Stephen Roettger > Filename : draft-ietf-ntp-network-time-security-00.txt > Pages : 12 > Date : 2013-06-28 > > Abstract: > This document describes the Network Time Security (NTS) protocol that > enables secure authentication of time servers using Network Time > Protocol (NTP) or Precision Time Protocol (PTP). Its design > considers the special requirements of precise timekeeping, which are > described in Security Requirements of Time Protocols in Packet > Switched Network [I-D.ietf-tictoc-security-requirements]. Doing a quick reading of this draft, I have a few questions: - Why isn't this just: - Request the X509 certificate of the server - Request a signed reply? I guess that you feel that an RSA signature is too expensive and that you instead want create a session key (cookie) between the client and server and just use a MAC function. - Why does the client need a public key? It doesn't seem to make sense to me to need a key for each client. This is only needed for the cookie generation? Why isn't there something simular to a Diffie-Hellman key exchange used instead? Kurt _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sun Jul 7 17:10:11 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D1411E8160 for ; Sun, 7 Jul 2013 17:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 hZVELTFavXfq for ; Sun, 7 Jul 2013 17:10:06 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1850A21F9FEA for ; Sun, 7 Jul 2013 17:10:05 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id F417686D560 for ; Mon, 8 Jul 2013 00:10:03 +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 1E0F286D4E3 for ; Mon, 8 Jul 2013 00:09:57 +0000 (UTC) Received: from mailfront1.rz.tu-bs.de ([134.169.12.132] helo=tu-bs.de) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uvz1f-0006pT-24 for ntpwg@lists.ntp.org; Mon, 08 Jul 2013 00:09:57 +0000 Received: from [93.223.217.59] (account y0034674@tu-braunschweig.de HELO [192.168.178.89]) by rz.tu-bs.de (CommuniGate Pro SMTP 5.4.9) with ESMTPA id 39299262; Mon, 08 Jul 2013 02:09:48 +0200 Message-ID: <51DA0349.3040501@tu-bs.de> Date: Mon, 08 Jul 2013 02:09:45 +0200 From: =?ISO-8859-1?Q?Stephen_R=F6ttger?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kurt Roeckx References: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> <20130707231848.GA32053@roeckx.be> In-Reply-To: <20130707231848.GA32053@roeckx.be> X-TagToolbar-Keys: D20130708020945763 X-SA-Exim-Connect-IP: 134.169.12.132 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: s.roettger@tu-bs.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Hi Kurt, > - Why isn't this just: > - Request the X509 certificate of the server > - Request a signed reply? The time used to create the MAC/Signature for a time packet will directly affect its precision. Thus I see two alternatives: 1. Keep the authentication overhead as low as possible by using a message authentication code (this is our approach) 2. Let the server send the time synchronization packet twice: first without authentication and afterwards with a signature attached. The client will note the time of arrival of the first packet, but buffer it until the second packet arrives and he can verify the signature. In this approach we could use RSA since the time used for the signature creation will not affect the precision. We chose the symmetric approach to keep the load on the server as low as possible since this might affect the precision of time requests arriving from different clients. > - Why does the client need a public key? In the common NTP mode, the client/server mode, the NTP server is stateless and we wanted to keep it that way. Thus, we need a shared secret between client and server for the MAC generation that can be calculated newly by the server every time a request arrives. We need the public key at the client in order that the server can encrypt the secret and send it to the client. The public key is also used as input to the shared secret to prevent an attacker to request the same secret from the client. This means, the client is identified by his public key and the shared secret calculated from this key will only be send to the client in encrypted form. The specific parts of the protocol look like this: 1. C PubKey_C -> S 2. Server calculates secret (cookie): MSB_128 (H(server seed || H(public key of client))) 3. C <- Sign(Enc(PubKey_C, cookie)) S 4. C TimeRequest, PubKey_C -> S 5. Server again calculates the secret (no state available) 5. C <- MAC(TimeResponse, cookie) S Regards, Stephen _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 8 13:09:18 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7E221F9B5C for ; Mon, 8 Jul 2013 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.803 X-Spam-Level: X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 XePE5OcCNskw for ; Mon, 8 Jul 2013 13:09:12 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 7037C21F9DED for ; Mon, 8 Jul 2013 13:09:04 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id DFC5286D55B for ; Mon, 8 Jul 2013 20:09:01 +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 04E5186D422 for ; Mon, 8 Jul 2013 20:08:49 +0000 (UTC) Received: from georges.telenet-ops.be ([195.130.137.68]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UwHjq-000HnE-QT for ntpwg@lists.ntp.org; Mon, 08 Jul 2013 20:08:48 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by georges.telenet-ops.be with bizsmtp id xw8i1l01L0zFtyu06w8iFv; Mon, 08 Jul 2013 22:08:42 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 302EAEAC44; Mon, 8 Jul 2013 22:08:42 +0200 (CEST) Date: Mon, 8 Jul 2013 22:08:42 +0200 From: Kurt Roeckx To: Stephen =?iso-8859-1?Q?R=F6ttger?= Message-ID: <20130708200842.GA13521@roeckx.be> References: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> <20130707231848.GA32053@roeckx.be> <51DA0349.3040501@tu-bs.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51DA0349.3040501@tu-bs.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.137.68 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Mon, Jul 08, 2013 at 02:09:45AM +0200, Stephen R=F6ttger wrote: > Hi Kurt, > = > > - Why isn't this just: > > - Request the X509 certificate of the server > > - Request a signed reply? > The time used to create the MAC/Signature for a time packet will > directly affect its precision. I would think it would have more effect on the accuracy that on the precision. > We chose the symmetric approach to keep the load on the server as low as > possible since this might affect the precision of time requests arriving > from different clients. I can really see that you want an as low as possible overhead per packet, and want to assume that a clients sends a large amount of packets with the same cookie. If a client has an interval of 1024, and you generate a new seed every hour, that would mean basicly have 3/4 packets before it needs to start again. But the draft currently doesn't mention anything about how often it needs to change. > > - Why does the client need a public key? > In the common NTP mode, the client/server mode, the NTP server is > stateless and we wanted to keep it that way. Thus, we need a shared > secret between client and server for the MAC generation that can be > calculated newly by the server every time a request arrives. > We need the public key at the client in order that the server can > encrypt the secret and send it to the client. The public key is also > used as input to the shared secret to prevent an attacker to request the > same secret from the client. There are various methods to establish a shared secret between the server and the client don't don't require the client to have a public rsa key. I'm concerned about people inventing new ways to do something that's already been done many times, without fully understanding the security consequences. For instance, you now have a secret (cookie) that's based on the concatantion of an other secret (seed) and a public part. Which kind of existing attaks can be used to get the either secret from that? I understand that not keeping state in the server complicates things. But I would really like to see an overview of the possiblities and the pros and cons for the various options. Kurt _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 8 13:53:55 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE94F21F9E2D for ; Mon, 8 Jul 2013 13:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 hwLcj+UT9o8Q for ; Mon, 8 Jul 2013 13:53:50 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 656B421F9E26 for ; Mon, 8 Jul 2013 13:53:50 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 5CB8486D55B for ; Mon, 8 Jul 2013 20:53:34 +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 29C4086D422 for ; Mon, 8 Jul 2013 20:53:29 +0000 (UTC) Received: from mailfront1.rz.tu-bs.de ([134.169.12.132] helo=tu-bs.de) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UwIR5-000IXa-Gp for ntpwg@lists.ntp.org; Mon, 08 Jul 2013 20:53:29 +0000 Received: from [92.63.173.118] (account y0034674@tu-braunschweig.de HELO [0.0.0.0]) by rz.tu-bs.de (CommuniGate Pro SMTP 5.4.9) with ESMTPA id 39313389; Mon, 08 Jul 2013 22:53:19 +0200 Message-ID: <51DB26BD.3020202@tu-bs.de> Date: Mon, 08 Jul 2013 22:53:17 +0200 From: =?ISO-8859-1?Q?Stephen_R=F6ttger?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kurt Roeckx References: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> <20130707231848.GA32053@roeckx.be> <51DA0349.3040501@tu-bs.de> <20130708200842.GA13521@roeckx.be> In-Reply-To: <20130708200842.GA13521@roeckx.be> X-TagToolbar-Keys: D20130708225317307 X-SA-Exim-Connect-IP: 134.169.12.132 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: s.roettger@tu-bs.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org > I would think it would have more effect on the accuracy that on the > precision. You're right, I didn't know there is a difference. We don't make that distinction in my mother tongue. > There are various methods to establish a shared secret between the > server and the client don't don't require the client to have a > public rsa key. Yes that's right, but there is no method that I'm aware of in which the server is not required to keep a state for the client and to remember the secret. > For instance, you now have a secret (cookie) that's based on the > concatantion of an other secret (seed) and a public part. Which > kind of existing attaks can be used to get the either secret from > that? The security of this depends on the security of the cryptographic hash function that is used. In particular the pre-image resistance and the second pre-image resistance. Pre-image resistance guarantees, that we will not be able to find an input that produces the given output. This means, that we will not be able to find a value for the server secret that will produce a given cookie. Second pre-image resistance on the other hand guarantees that while given a fixed hash input, we will not be able to find a second input that produces the same hash. Thus, it will not be possible to find a second RSA key that will result in the same cookie (which is further complicated since an attacker will not know the cookie itself). I understand your concerns and I would probably see it the same way: don't invent something new if there is already a solution for the problem, especially with cryptography. But as long as we keep the server stateless and still want to use symmetric cryptography, I don't see any alternatives. In my opinion, the protocol itself is relatively simple and I would really appreciate it if a few people with cryptographic experience would take a look at it (especially the part summarized in my last email). Stephen _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 10 07:34:06 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2892511E8180 for ; Wed, 10 Jul 2013 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ZBHTyEEv8RD0 for ; Wed, 10 Jul 2013 07:34:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 278CD21F9E5C for ; Wed, 10 Jul 2013 07:33:56 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 0A21286DAAE for ; Wed, 10 Jul 2013 14:33:55 +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 58A9786D4F1 for ; Wed, 10 Jul 2013 14:33:39 +0000 (UTC) Received: from mail-gg0-x230.google.com ([2607:f8b0:4002:c02::230]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UwvRr-000Fz7-UH for ntpwg@lists.ntp.org; Wed, 10 Jul 2013 14:33:39 +0000 Received: by mail-gg0-f176.google.com with SMTP id i2so2343205ggk.7 for ; Wed, 10 Jul 2013 07:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-forwarded-message-id:content-type; bh=MLQPVCqPh+SHakRvHIietIOYGO5ynQU82YqO9jmnvKU=; b=J+7Q3m1aG1bZ2VltPTqfLOrmz4DxZIWocFNCB1683KUNohNw9E3qMc2PH8WBebYwQC 6s5noOV8b9DkM8x6zTedwFAA+XrqL6LthGXRDHaD7UEaLvDyJzwtppZxkIJxEXglzXyg xToZHlLFF8NaPa9Ddw63ixj4G+CdTfviZ3wGUlHZrmLr7pH09vf5mfLbid7Zz/7PrTCy wOFvIOWPYb7kMiXQqt4BWjDRRrQgHxhqT4xbhTpsjEkFguTrY9lVL1JL6gr8aHuoFi+5 x0XnOxduyZHQ3hj5IB4F8KlRyNJrsZXSD5hga23YuupfNDVOniQWFwYSfvaebs1Fddow aodw== X-Received: by 10.236.130.180 with SMTP id k40mr18214815yhi.70.1373466765699; Wed, 10 Jul 2013 07:32:45 -0700 (PDT) Received: from kodonog-mac.local (ip-64-134-174-185.public.wayport.net. [64.134.174.185]) by mx.google.com with ESMTPSA id b48sm53021464yhc.8.2013.07.10.07.32.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 07:32:44 -0700 (PDT) Message-ID: <51DD7084.7040501@pobox.com> Date: Wed, 10 Jul 2013 10:32:36 -0400 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "tictoc@ietf.org" References: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> In-Reply-To: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> X-SA-Exim-Connect-IP: 2607:f8b0:4002:c02::230 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kodonog@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group Subject: [ntpwg] Fwd: I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: kodonog@pobox.com List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1334399787072378997==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============1334399787072378997== Content-Type: multipart/alternative; boundary="------------060403070909090305060002" This is a multi-part message in MIME format. --------------060403070909090305060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, I meant to cross post this to tictoc for your information as well. Please review and comment. Karen -------- Original Message -------- Subject: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt Date: Sun, 07 Jul 2013 15:11:19 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ntpwg@lists.ntp.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol Working Group of the IETF. Title : Network Time Security Author(s) : Dieter Sibold Stephen Roettger Filename : draft-ietf-ntp-network-time-security-00.txt Pages : 12 Date : 2013-06-28 Abstract: This document describes the Network Time Security (NTS) protocol that enables secure authentication of time servers using Network Time Protocol (NTP) or Precision Time Protocol (PTP). Its design considers the special requirements of precise timekeeping, which are described in Security Requirements of Time Protocols in Packet Switched Network [I-D.ietf-tictoc-security-requirements]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ntp-network-time-security-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --------------060403070909090305060002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,

I meant to cross post this to tictoc for your information as well. Please review and comment.

Karen


-------- Original Message --------
Subject: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt
Date: Sun, 07 Jul 2013 15:11:19 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: ntpwg@lists.ntp.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network Time Protocol Working Group of the IETF.

	Title           : Network Time Security
	Author(s)       : Dieter Sibold
                          Stephen Roettger
	Filename        : draft-ietf-ntp-network-time-security-00.txt
	Pages           : 12
	Date            : 2013-06-28

Abstract:
   This document describes the Network Time Security (NTS) protocol that
   enables secure authentication of time servers using Network Time
   Protocol (NTP) or Precision Time Protocol (PTP).  Its design
   considers the special requirements of precise timekeeping, which are
   described in Security Requirements of Time Protocols in Packet
   Switched Network [I-D.ietf-tictoc-security-requirements].



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ntp-network-time-security-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


--------------060403070909090305060002-- --===============1334399787072378997== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1334399787072378997==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 10 22:10:32 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCDE21F8EB2 for ; Wed, 10 Jul 2013 22:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 4SQImczR8NV6 for ; Wed, 10 Jul 2013 22:10:28 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3291521F9BE5 for ; Wed, 10 Jul 2013 22:10:28 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C015086DAD8 for ; Thu, 11 Jul 2013 05:10:26 +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 4A3BD86D4F1 for ; Thu, 11 Jul 2013 05:10:08 +0000 (UTC) Received: from na3sys009aog127.obsmtp.com ([74.125.149.107]) by mail1.ntp.org with smtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ux98o-000L4H-2G for ntpwg@lists.ntp.org; Thu, 11 Jul 2013 05:10:08 +0000 Received: from SC-OWA01.marvell.com ([199.233.58.136]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKUd4+LCG+FlGRwtRZw9KD5CpFnljT+hXX@postini.com; Wed, 10 Jul 2013 22:10:05 PDT Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Jul 2013 22:04:03 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Thu, 11 Jul 2013 08:04:00 +0300 From: Tal Mizrahi To: "ntpwg@lists.ntp.org" , "odonoghue@isoc.org" , "Danny Mayer (mayer@ntp.org)" Date: Thu, 11 Jul 2013 08:03:59 +0300 Thread-Topic: Updated draft-mizrahi-ntp-extension-field Thread-Index: Ac5984NQr0GTPccuTd+QdtySM0QuPQ== Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9F93987@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-SA-Exim-Connect-IP: 74.125.149.107 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: talmi@marvell.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Updated draft-mizrahi-ntp-extension-field X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0967286383112168137==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============0967286383112168137== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F9F93987ILMB01marve_" --_000_74470498B659FA4687F0B0018C19A89C01A0F9F93987ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have posted an updated draft: http://tools.ietf.org/html/draft-mizrahi-ntp-extension-field-02 What has changed since the last draft? - We revised the section "MAC in the absence of an Extension field= ". - We issued an erratum for RFC 5905 regarding the description of e= xtension fields in the absence of a MAC (http://www.rfc-editor.org/errata_search.php?rfc=3D5905&eid=3D3627) Comments will be welcome. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F9F93987ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have po= sted an updated draft:

http://tools.iet= f.org/html/draft-mizrahi-ntp-extension-field-02

 

What has changed sin= ce the last draft?

-  =         We revised the section “MAC in the absence of an Exten= sion field”.

-  =         We issued an erratum for RFC 5905 regarding the description = of extension fields in the absence of a MAC
(http://www.rfc-edito= r.org/errata_search.php?rfc=3D5905&eid=3D3627)

 

Comments will be w= elcome.

 

Thanks,

Tal.

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F9F93987ILMB01marve_-- --===============0967286383112168137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============0967286383112168137==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jul 12 12:12:50 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6757A21F9C16 for ; Fri, 12 Jul 2013 12:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 vk2X9eZRw-oB for ; Fri, 12 Jul 2013 12:12:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDA421F9C65 for ; Fri, 12 Jul 2013 12:12:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 916F286DAD2 for ; Fri, 12 Jul 2013 19:12:40 +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 11B7386D4E3 for ; Fri, 12 Jul 2013 19:12:23 +0000 (UTC) Received: from host-4-31-12.nss.udel.edu ([128.4.31.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uxil7-000HSM-Ad for ntpwg@lists.ntp.org; Fri, 12 Jul 2013 19:12:23 +0000 Received: from [192.168.1.2] (pool-74-109-13-78.phlapa.fios.verizon.net [74.109.13.78]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 0F9271ABE; Fri, 12 Jul 2013 15:11:59 -0400 (EDT) Message-ID: <51E05502.2050703@udel.edu> Date: Fri, 12 Jul 2013 19:12:02 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stephen_R=F6ttger?= References: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> <20130707231848.GA32053@roeckx.be> <51DA0349.3040501@tu-bs.de> <20130708200842.GA13521@roeckx.be> <51DB26BD.3020202@tu-bs.de> In-Reply-To: <51DB26BD.3020202@tu-bs.de> X-SA-Exim-Connect-IP: 128.4.31.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7399454891686009229==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============7399454891686009229== Content-Type: multipart/alternative; boundary="------------090905000308080409000306" This is a multi-part message in MIME format. --------------090905000308080409000306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stephen, I may have missed the beginning of this thread. I looked at the=20 document, but some of the details are missing. There is a long history=20 of NTP security algorithms beginning with a technical report in 1996. The document was updated in 2006, but was delayed in the IETF=20 publication process for several years, and finally published as=20 RFC5906. There have been several enhancements to the autokey protocol=20 described in RFC5906 since then, as documented in the NTP software=20 release notes. One of these was to augment the hash algorithms to=20 include SHA and all of the other algorithms provided in the OpenSSL libra= ry. One of the messages on this thread suggested sending an unsecured=20 message followed by a secured copy. The idea apparently is to provide=20 accurate time with the first message as verified by the second. This=20 feature has already been implemented in the NTP software, now called=20 interleave mode. The interleave modes are documented on the NTP=20 project page linked from the NTP home page and in the software release=20 notes. There is a good deal of information and position papers at the NTP=20 project page linked from the NTP home page. One of these contains a=20 security analysis of NTP, including the "cookie snatchers" and related=20 hazzards. The NTP security model is designed for stateless servers. =20 One of the goals of the present work described on this thread is to=20 eliminate these hazzards while preserving the stateless model. There is=20 in priciple a capability to change this model and allow some state=20 peculier to each client. If so, one or another of the=20 station-to-station (STS) protocol or one of its derivitives. This=20 protocol involves public certificates and the Diffie-Hellman agreement=20 algorithm. In any case, it would be advisable to use this protocol in=20 the NTP symmetric modes. There was a discussion on this thread about validating the public=20 certificate valid time interval. This is not possible unless the=20 recipient has a reliable clock. However, a reliable clock requires two=20 things: a valid signature on the cookie response, and a reliable time=20 confirmed by the NTP algorithms and possibly several servers.=20 A further requirement in the security model. is to reduce or eliminate=20 errors due to dropped or replicated packets, or packets crossed in=20 flight. This might be due to a middleman attack or DoS attack. There is=20 an extensive discussion on these issues together with serious=20 simulations in the white paper about the on-wire protocol on the NTP=20 project page. This applies to both the RFC5906 protocol, as well as the=20 protocol discussed in this thread. It is important that whatever protocol is adopted, that the resources=20 required of NTP or PTP for that matter, be absolutely minimal. In=20 RFC5906 there is no requirement for DNS or TCP or any protocol dependent=20 on either of these protocols. It would seem that using SSH to retrieve=20 certificates is not a good idea. In the NTP implementation,=20 certificates are stored in a cache so that certificates can be replaced=20 with new ones or from different sources as they become available. Thus,=20 it is possible only to verify continuity of the valid ranges as=20 certificates are retrieved. Absolute validity can be determined only=20 after the client clock has been synchronized. I'm very glad that this discussion has flourished. I hope that RFC5906,=20 or some part of it, can be useful. In any case, it is important to=20 discuss the architecture issues and assumptions of the supporting=20 services. This is especially important for national time servers with=20 upwards of several thousands client requests per second.=20 Dave Stephen R=F6ttger wrote: >>I would think it would have more effect on the accuracy that on the >>precision. >> =20 >> >You're right, I didn't know there is a difference. We don't make that >distinction in my mother tongue. > > =20 > >>There are various methods to establish a shared secret between the >>server and the client don't don't require the client to have a >>public rsa key. >> =20 >> >Yes that's right, but there is no method that I'm aware of in which the >server is not required to keep a state for the client and to remember >the secret. > > =20 > >>For instance, you now have a secret (cookie) that's based on the >>concatantion of an other secret (seed) and a public part. Which >>kind of existing attaks can be used to get the either secret from >>that? >> =20 >> >The security of this depends on the security of the cryptographic hash >function that is used. In particular the pre-image resistance and the >second pre-image resistance. >Pre-image resistance guarantees, that we will not be able to find an >input that produces the given output. This means, that we will not be >able to find a value for the server secret that will produce a given coo= kie. >Second pre-image resistance on the other hand guarantees that while >given a fixed hash input, we will not be able to find a second input >that produces the same hash. Thus, it will not be possible to find a >second RSA key that will result in the same cookie (which is further >complicated since an attacker will not know the cookie itself). > >I understand your concerns and I would probably see it the same way: >don't invent something new if there is already a solution for the >problem, especially with cryptography. But as long as we keep the server >stateless and still want to use symmetric cryptography, I don't see any >alternatives. >In my opinion, the protocol itself is relatively simple and I would >really appreciate it if a few people with cryptographic experience would >take a look at it (especially the part summarized in my last email). > >Stephen >_______________________________________________ >ntpwg mailing list >ntpwg@lists.ntp.org >http://lists.ntp.org/listinfo/ntpwg > =20 > --------------090905000308080409000306 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen,

I may have missed the beginning of this thread.  I  looked at the document, but some of the details are missing.  There is a long history of NTP security algorithms beginning with a technical report in 1996.
The document was updated in 2006, but was delayed in the IETF publication process for several years, and finally published as RFC5906.  There have been several enhancements to the autokey protocol described in RFC5906  since then, as documented in the NTP software release notes.  One of these was to augment the hash algorithms to include SHA and all of the other algorithms provided in the OpenSSL library.

One of the messages on this thread suggested sending an unsecured message followed by a secured copy.  The idea apparently is to provide accurate time with the first message as verified by the second.  This feature has already been implemented in the NTP software, now called interleave mode.  The interleave modes are documented on  the  NTP project page linked from the  NTP home page and in the software release notes.

There is a good deal of information and position papers at the NTP project page linked from the NTP home page.  One of these contains a security analysis of NTP, including the "cookie snatchers" and related hazzards.  The NTP security model is designed for stateless servers.  One of the goals of the present work described on this thread is to eliminate these hazzards while preserving the stateless model.  There is in priciple a capability to change this model and allow some state peculier to each client.  If so, one or another of the station-to-station (STS) protocol or one of its derivitives.  This protocol involves public certificates and the Diffie-Hellman agreement algorithm.  In any case, it would be advisable to use this protocol in the NTP symmetric modes.

There was a discussion on this thread about validating the public certificate valid time interval.  This is not possible unless the recipient has a reliable clock.  However, a reliable clock requires two things:  a valid signature on the cookie response, and a reliable time confirmed by the NTP algorithms and possibly several servers. 

A further requirement in the security model. is to reduce or eliminate errors due to dropped or replicated packets, or packets crossed in flight. This might be due to a middleman attack or DoS attack. There is an extensive discussion on these issues together with serious simulations in the white paper about the on-wire protocol on the NTP project page.  This applies to both the RFC5906 protocol, as well as the protocol discussed in this thread.

It is important that whatever protocol is adopted, that the resources required of  NTP or PTP for that matter, be absolutely minimal.  In RFC5906 there is no requirement for DNS or TCP or any protocol dependent on either of these protocols.  It would seem that using SSH to retrieve certificates is not a good idea.  In the NTP implementation, certificates are stored in a cache so that certificates can be replaced with new ones or from different sources as they become available.  Thus, it is possible only to verify continuity of the valid ranges as certificates are retrieved.  Absolute validity can be determined only after the client clock has been synchronized.

I'm very glad that this discussion has flourished.  I hope that RFC5906, or some part of it, can be useful.  In any case, it is important to discuss the architecture issues and assumptions of the supporting services.  This is especially important for national time servers with upwards of several thousands client requests per second. 

Dave

Stephen Röttger wrote:
I would think it would have more effect on the accuracy that on the
precision.
    
You're right, I didn't know there is a difference. We don't make that
distinction in my mother tongue.

  
There are various methods to establish a shared secret between the
server and the client don't don't require the client to have a
public rsa key.
    
Yes that's right, but there is no method that I'm aware of in which the
server is not required to keep a state for the client and to remember
the secret.

  
For instance, you now have a secret (cookie) that's based on the
concatantion of an other secret (seed) and a public part.  Which
kind of existing attaks can be used to get the either secret from
that?
    
The security of this depends on the security of the cryptographic hash
function that is used. In particular the pre-image resistance and the
second pre-image resistance.
Pre-image resistance guarantees, that we will not be able to find an
input that produces the given output. This means, that we will not be
able to find a value for the server secret that will produce a given cookie.
Second pre-image resistance on the other hand guarantees that while
given a fixed hash input, we will not be able to find a second input
that produces the same hash. Thus, it will not be possible to find a
second RSA key that will result in the same cookie (which is further
complicated since an attacker will not know the cookie itself).

I understand your concerns and I would probably see it the same way:
don't invent something new if there is already a solution for the
problem, especially with cryptography. But as long as we keep the server
stateless and still want to use symmetric cryptography, I don't see any
alternatives.
In my opinion, the protocol itself is relatively simple and I would
really appreciate it if a few people with cryptographic experience would
take a look at it (especially the part summarized in my last email).

Stephen
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

--------------090905000308080409000306-- --===============7399454891686009229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============7399454891686009229==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jul 17 12:47:55 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6EE21F9644 for ; Wed, 17 Jul 2013 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 vHewe38zRtJH for ; Wed, 17 Jul 2013 12:47:50 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id A656621F84A8 for ; Wed, 17 Jul 2013 12:47:50 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id DE00586D778 for ; Wed, 17 Jul 2013 19:47:42 +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 AAD6B86D333 for ; Wed, 17 Jul 2013 19:47:23 +0000 (UTC) Received: from mail-by2lp0236.outbound.protection.outlook.com ([207.46.163.236] helo=na01-by2-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzXh2-0000fN-IV for ntpwg@lists.ntp.org; Wed, 17 Jul 2013 19:47:23 +0000 Received: from BLUPR06MB180.namprd06.prod.outlook.com (10.242.190.27) by BLUPR06MB178.namprd06.prod.outlook.com (10.242.190.18) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 17 Jul 2013 19:47:12 +0000 Received: from BLUPR06MB180.namprd06.prod.outlook.com ([169.254.7.5]) by BLUPR06MB180.namprd06.prod.outlook.com ([169.254.7.231]) with mapi id 15.00.0731.000; Wed, 17 Jul 2013 19:47:11 +0000 From: Karen O'Donoghue To: "tictoc@ietf.org" , "ntpwg@lists.ntp.org" Thread-Topic: Draft agenda for upcoming IETF87 meeting Thread-Index: AQHOgyZtKyIcg0yKVkOlkAEar4iueQ== Date: Wed, 17 Jul 2013 19:47:11 +0000 Message-ID: <8F4FCCC4-555D-4266-8F8C-A9833519BE11@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.193.154.223] x-forefront-prvs: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(4396001)(76482001)(74876001)(54356001)(69226001)(66066001)(63696002)(76176001)(56816003)(33656001)(83072001)(59766001)(77982001)(47446002)(65816001)(46102001)(36756003)(50986001)(74502001)(76786001)(16406001)(79102001)(74662001)(31966008)(47736001)(49866001)(54316002)(74366001)(47976001)(53806001)(77096001)(56776001)(80022001)(74706001)(76796001)(81542001)(81342001)(83322001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB178; H:BLUPR06MB180.namprd06.prod.outlook.com; CLIP:71.193.154.223; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-ID: MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-SA-Exim-Connect-IP: 207.46.163.236 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Draft agenda for upcoming IETF87 meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Please send any corrections or additions. Regards, Karen Agenda for joint meeting of TICTOC and NTP WGs - IETF 87 ======================================================== Tuesday, 30 July 2013, 0900-1130 CEST (0700-0930 UTC) 1. Administrivia and Agenda Bashing (Chairs) 2. TICTOC WG status and update on WGLC documents (Chairs) draft-ietf-tictoc-security-requirements draft-ietf-tictoc-ptp-mib draft-shpiner-multi-path-synchronization-01 3. Enterprise profile for IEEE 1588 (Gerstung) draft-ietf-tictoc-ptp-enterprise-profile-00 4. Transporting Timing messages over MPLS Networks (TBD) draft-ietf-tictoc-1588overmpls 5. NTP WG status and update (Chairs) draft-mizrahi-ntp-extension-field-02 6. Network Time Security (autokey replacement) (Sibold) draft-ietf-ntp-network-time-security-00 7. Using UDP Checksum Trailers in the Network Time Protocol (NTP) (Mizrahi) draft-mizrahi-ntp-checksum-trailer-00 8. IEEE 1588 update (TBD) 9. ITU-T SG15/Q13 update (Ruffini) 10. Wrap-up (Chairs) _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sun Jul 28 07:41:02 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC03B21F9CC6 for ; Sun, 28 Jul 2013 07:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 GrBwtNQv5-aZ for ; Sun, 28 Jul 2013 07:40:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 854D321F9CA9 for ; Sun, 28 Jul 2013 07:40:54 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 876A686D773 for ; Sun, 28 Jul 2013 14:40:53 +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 07C0686D333 for ; Sun, 28 Jul 2013 14:40:35 +0000 (UTC) Received: from juliette.telenet-ops.be ([195.130.137.74]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V3S9C-0000GY-LH for ntpwg@lists.ntp.org; Sun, 28 Jul 2013 14:40:35 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by juliette.telenet-ops.be with bizsmtp id 5qgX1m00k0zFtyu06qgXhn; Sun, 28 Jul 2013 16:40:32 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id B4F54EAF41; Sun, 28 Jul 2013 16:40:31 +0200 (CEST) Date: Sun, 28 Jul 2013 16:40:31 +0200 From: Kurt Roeckx To: Stephen =?iso-8859-1?Q?R=F6ttger?= Message-ID: <20130728144031.GA20742@roeckx.be> References: <20130707221119.2435.9116.idtracker@ietfa.amsl.com> <20130707231848.GA32053@roeckx.be> <51DA0349.3040501@tu-bs.de> <20130708200842.GA13521@roeckx.be> <51DB26BD.3020202@tu-bs.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51DB26BD.3020202@tu-bs.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.137.74 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-network-time-security-00.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Mon, Jul 08, 2013 at 10:53:17PM +0200, Stephen R=F6ttger wrote: > In my opinion, the protocol itself is relatively simple and I would > really appreciate it if a few people with cryptographic experience would > take a look at it (especially the part summarized in my last email). I can't see anything obvious wrong with it, but would also really like to see feedback from people who have more expierence with this than I do. Kurt _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 29 10:02:32 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0910711E80D9 for ; Mon, 29 Jul 2013 10:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tnlLkJPCM0uw for ; Mon, 29 Jul 2013 10:02:13 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id EDA2D21E8092 for ; Mon, 29 Jul 2013 09:55:55 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4203D86DAAD for ; Mon, 29 Jul 2013 16:55:14 +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 64D0686D33D for ; Mon, 29 Jul 2013 16:54:57 +0000 (UTC) Received: from [198.22.153.36] (helo=[10.2.64.39]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V3qil-000EFa-MD; Mon, 29 Jul 2013 16:54:56 +0000 Message-ID: <51F69E59.9010403@ntp.org> Date: Mon, 29 Jul 2013 12:54:49 -0400 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tal Mizrahi References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380F@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9C9380F@IL-MB01.marvell.com> X-Enigmail-Version: 1.5.2 X-SA-Exim-Connect-IP: 198.22.153.36 X-SA-Exim-Rcpt-To: talmi@marvell.com, ntpwg@lists.ntp.org, tictoc@ietf.org, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Subject: Re: [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mayer@ntp.org List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org I have serious concerns about this draft. I effect it seems to say that any intermediate mode can alter the contents of the packet in flight and thus encourage a MIM attack. Furthermore it recommends recomputing the MAC. Why bother to do it this way if you can just recompute the MAC (if any) and then UDP checksum and place it in the UDP checksum field. I'd rather have the new timestamp placed in the extension field so that the receiving server can use it or not. The security considerations makes no mention of these issues. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 29 13:47:16 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE88D21E80B5 for ; Mon, 29 Jul 2013 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2lpwn8kQDi4S for ; Mon, 29 Jul 2013 13:47:11 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0474621E80BB for ; Mon, 29 Jul 2013 13:47:10 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id DD4C286DAA5 for ; Mon, 29 Jul 2013 20:47:08 +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 E735586D33D for ; Mon, 29 Jul 2013 20:46:57 +0000 (UTC) Received: from na3sys009aog130.obsmtp.com ([74.125.149.143]) by mail1.ntp.org with smtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V3uLG-000FKI-2h for ntpwg@lists.ntp.org; Mon, 29 Jul 2013 20:46:57 +0000 Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUfbUqu+6CC+fcdlrICBhYUm7QwV/gJYt@postini.com; Mon, 29 Jul 2013 13:46:54 PDT Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 29 Jul 2013 13:46:25 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Mon, 29 Jul 2013 23:46:22 +0300 From: Tal Mizrahi To: "mayer@ntp.org" Date: Mon, 29 Jul 2013 23:46:18 +0300 Thread-Topic: [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00 Thread-Index: Ac6MfF2W1x+yez/FRUqrWDIU8z4VJgAHyJaA Message-ID: <74470498B659FA4687F0B0018C19A89C01A0FA109DCC@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380F@IL-MB01.marvell.com> <51F69E59.9010403@ntp.org> In-Reply-To: <51F69E59.9010403@ntp.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-SA-Exim-Connect-IP: 74.125.149.143 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: talmi@marvell.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Subject: Re: [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Hi Danny, I understand your concern, and I would like to clarify an important point: I believe the functionality described in this draft is useful in unauthenticated mode, and not useful in authenticated mode. In authenticated mode, an intermediate entity that changes the packet would have to re-compute the MAC, so re-computing the UDP checksum as well does not significantly complicate the intermediate entity. I tried to explain this point in the draft (the text is quoted below), but if the working group feels strongly about it I am willing to make it a stronger statement - that the checksum trailer is only relevant to unauthenticated mode, and is not to be used in authenticated mode. Danny, does this make sense? Quoting from section 3.4 of the draft: While a Checksum Trailer MAY be used when authentication is enabled, in practice the Checksum Trailer is more useful in unauthenticated mode, allowing the intermediate entity to perform serial processing of the packet without storing-and-forwarding it. Tal. -----Original Message----- From: Danny Mayer [mailto:mayer@ntp.org] Sent: Monday, July 29, 2013 6:55 PM To: Tal Mizrahi Cc: ntpwg@lists.ntp.org; tictoc@ietf.org; David L. Mills Subject: Re: [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00 I have serious concerns about this draft. I effect it seems to say that any intermediate mode can alter the contents of the packet in flight and thus encourage a MIM attack. Furthermore it recommends recomputing the MAC. Why bother to do it this way if you can just recompute the MAC (if any) and then UDP checksum and place it in the UDP checksum field. I'd rather have the new timestamp placed in the extension field so that the receiving server can use it or not. The security considerations makes no mention of these issues. Danny _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jul 29 14:15:40 2013 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096A311E813A for ; Mon, 29 Jul 2013 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 18lzOJ229d2L for ; Mon, 29 Jul 2013 14:15:35 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id EA9A711E815B for ; Mon, 29 Jul 2013 14:15:30 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D68A386DAE8 for ; Mon, 29 Jul 2013 21:15:29 +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 0305586D33D for ; Mon, 29 Jul 2013 21:15:24 +0000 (UTC) Received: from [198.22.153.36] (helo=[10.2.64.39]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V3ump-000FTs-0Z; Mon, 29 Jul 2013 21:15:24 +0000 Message-ID: <51F6DB63.9090208@ntp.org> Date: Mon, 29 Jul 2013 17:15:15 -0400 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tal Mizrahi References: <74470498B659FA4687F0B0018C19A89C01A0F9C9380F@IL-MB01.marvell.com> <51F69E59.9010403@ntp.org> <74470498B659FA4687F0B0018C19A89C01A0FA109DCC@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0FA109DCC@IL-MB01.marvell.com> X-Enigmail-Version: 1.5.2 X-SA-Exim-Connect-IP: 198.22.153.36 X-SA-Exim-Rcpt-To: talmi@marvell.com, ntpwg@lists.ntp.org, tictoc@ietf.org, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ntpwg@lists.ntp.org" , "tictoc@ietf.org" Subject: Re: [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mayer@ntp.org List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 7/29/2013 4:46 PM, Tal Mizrahi wrote: > Hi Danny, > > I understand your concern, and I would like to clarify an important point: I believe the functionality described in this draft is useful in unauthenticated mode, and not useful in authenticated mode. In authenticated mode, an intermediate entity that changes the packet would have to re-compute the MAC, so re-computing the UDP checksum as well does not significantly complicate the intermediate entity. > > I tried to explain this point in the draft (the text is quoted below), but if the working group feels strongly about it I am willing to make it a stronger statement - that the checksum trailer is only relevant to unauthenticated mode, and is not to be used in authenticated mode. > > Danny, does this make sense? > Not to me. If you are already changing the packet directly why not change the packet UDP checksum as well while you're at it? I'd rather see the corrected time in an extension field rather than changing the packet itself. Danny > Quoting from section 3.4 of the draft: > While a Checksum Trailer MAY be used when authentication is enabled, > in practice the Checksum Trailer is more useful in unauthenticated > mode, allowing the intermediate entity to perform serial processing > of the packet without storing-and-forwarding it. > > > Tal. > > > -----Original Message----- > From: Danny Mayer [mailto:mayer@ntp.org] > Sent: Monday, July 29, 2013 6:55 PM > To: Tal Mizrahi > Cc: ntpwg@lists.ntp.org; tictoc@ietf.org; David L. Mills > Subject: Re: [ntpwg] New Draft: draft-mizrahi-ntp-checksum-trailer-00 > > I have serious concerns about this draft. I effect it seems to say that any intermediate mode can alter the contents of the packet in flight and thus encourage a MIM attack. Furthermore it recommends recomputing the MAC. Why bother to do it this way if you can just recompute the MAC (if > any) and then UDP checksum and place it in the UDP checksum field. I'd rather have the new timestamp placed in the extension field so that the receiving server can use it or not. > > The security considerations makes no mention of these issues. > > Danny > > _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg