From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 2 08:03:45 2017 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 60DF8129407 for ; Fri, 2 Jun 2017 08:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-4fifemMt6a for ; Fri, 2 Jun 2017 08:03:43 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 61CC8128D3E for ; Fri, 2 Jun 2017 08:03:43 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id E7AC886DB9B for ; Fri, 2 Jun 2017 15:03:41 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 5467F86DAB6 for ; Fri, 2 Jun 2017 15:03:39 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dGo6r-0000qg-Sg for ntpwg@lists.ntp.org; Fri, 02 Jun 2017 15:03:39 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A0C8B7E9C2 for ; Fri, 2 Jun 2017 15:03:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A0C8B7E9C2 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mlichvar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A0C8B7E9C2 Received: from localhost (holly.brq.redhat.com [10.34.24.121]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 20DB95C883 for ; Fri, 2 Jun 2017 15:03:27 +0000 (UTC) Date: Fri, 2 Jun 2017 17:03:26 +0200 From: Miroslav Lichvar To: ntpwg@lists.ntp.org Message-ID: <20170602150326.GH25331@localhost> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 02 Jun 2017 15:03:28 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Symmetric mode in NTS X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 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" I was reading the current text of nts-for-ntp about DTLS and the symmetric mode, but it's not obvious to me how exactly it's supposed to work. I have few questions: - Do the peers use separate ports for DTLS client and server? - What should happen when both peers are active and are started at the same time? Should each have its own DTLS connection? - How should be handled the case when a passive peer doesn't mobilize an association? This is normally a stateless mode of operation. Should the peer reject the connection and let the other peer figure out that it needs to use the client mode and maybe try symmetric mode again later? To be honest, I don't like that the symmetric mode has a completely different protocol. Why not use the same NTS-KE over TLS and NTP extensions as the client/server mode? I think the issue with replay attacks can be solved by requiring both ends of the NTS association to save unused cookies. Are there any other issues? -- Miroslav Lichvar _______________________________________________ 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 Fri Jun 2 09:59:05 2017 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 EDFBA126B71 for ; Fri, 2 Jun 2017 09:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwNZohnSoZk5 for ; Fri, 2 Jun 2017 09:59:03 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 37520128CD5 for ; Fri, 2 Jun 2017 09:59:02 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 701E786DB9D for ; Fri, 2 Jun 2017 16:59:01 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 2E77386DAB6 for ; Fri, 2 Jun 2017 16:58:58 +0000 (UTC) Received: from mail-wm0-f41.google.com ([74.125.82.41]) by mail1.ntp.org with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dGpuS-0004pz-Qw for ntpwg@lists.ntp.org; Fri, 02 Jun 2017 16:58:58 +0000 Received: by mail-wm0-f41.google.com with SMTP id b84so30252242wmh.0 for ; Fri, 02 Jun 2017 09:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n/uydH8txzW/yUL1CDzmtSXhfWc7rlNOuSQWQwHUBxU=; b=affri4rKJM0HEZyj3UnW9VRFa6VfqAftNv9ZSYAUUu4FEGEOppRaRLFB0ZAyvWXLrD zAP5H3223X6Er7KgQCuPaDJ6S5LF7nGbC14LG7w2N52P9On6ylMH9h5q16LA5EZzdo3y ClXvPgOPUa4InoBLOnVjtVxfM2jj4RwfF+DNwXfc7Ua+MuDpP1dfdVvAGOvlTX9Pjpwd 68RbMqRIo7itdKuaS/In4hX4tIcCfHuPYg0W0b8+LYfPTdoMiuZ/npnEb4ASE+zloeqj jX/pqux31tgFlZ8+Y2LAtmLjAQM6WEhDzjqGuxZLXKTPNe4ozWteE0tenz58PMWEd/tv OS3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n/uydH8txzW/yUL1CDzmtSXhfWc7rlNOuSQWQwHUBxU=; b=ShA5sN+bFhggIp0QlVzXENLgqkbK50tj+PCStWrbbiJJhyVBUwSh7PNKJj/hj54TsY ECECvx0wHg++pVyGYPwSoFeW9IsxJ7v+6kfJ8S6/dWhh4vN2QU4Z6C+p+9v/x5Pc1su8 whbxqCEa0xxBtileKG3RIQs75h0UOpTf5XemKjKUq0x1mvyyqTLOnc7lAIKxvbNusAYz 5u8ccEdxb/0KNFqK6iyGLaMjBdLW3wetkmk/l/HRflvOiW+n8AV52J71zkEMnfcITZ4T JWp6X+BQwsebRoaT7x3hBHqc1U7u+/hMulRHRFsDphdvkTrSBtnk5+8Odfw9Cnrp3Ieg Wzag== X-Gm-Message-State: AODbwcAXlgbg6quPSUeDY6p8Y98CZdMXc+Mjx6ds+tbTG8A7ODVodZ4L hYXMu82jzGXRSJk6MBlnMjZoEmEQsw== X-Received: by 10.80.167.163 with SMTP id i32mr7054202edc.101.1496422727614; Fri, 02 Jun 2017 09:58:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.140.67 with HTTP; Fri, 2 Jun 2017 09:58:46 -0700 (PDT) In-Reply-To: <20170602150326.GH25331@localhost> References: <20170602150326.GH25331@localhost> From: Daniel Franke Date: Fri, 2 Jun 2017 12:58:46 -0400 Message-ID: To: Miroslav Lichvar X-SA-Exim-Connect-IP: 74.125.82.41 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dfoxfranke@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Symmetric mode in NTS X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org 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" On 6/2/17, Miroslav Lichvar wrote: > I was reading the current text of nts-for-ntp about DTLS and the > symmetric mode, but it's not obvious to me how exactly it's supposed > to work. I have few questions: > > - Do the peers use separate ports for DTLS client and server? Servers use the IANA-allocated NTS port. Clients can use whatever they want. > - What should happen when both peers are active and are started at the > same time? Should each have its own DTLS connection? Good question, I'll add a paragraph clarifying this. I think the answer is necessarily yes. Peers configured as active don't necessarily know whether the other peer is active or passive, so they each would need to at least attempt to initiate their own DTLS session. Only one session is needed, but if two get established then I think it's easier to just keep them both open than to attempt to somehow break the symmetry and figure out which one to close. > - How should be handled the case when a passive peer doesn't mobilize > an association? This is normally a stateless mode of operation. > Should the peer reject the connection and let the other peer figure > out that it needs to use the client mode and maybe try symmetric > mode again later? I think this is a policy question and it's up to implementers. Servers may choose to answer mode 1 packets over DTLS without standing up an association, but if they do so they'll incur the overhead of keeping the DTLS session open. Clients which try to peer with a server but find that it's not accepting DTLS handshakes can implement whatever fallback behavior seems appropriate. > To be honest, I don't like that the symmetric mode has a completely > different protocol. Why not use the same NTS-KE over TLS and NTP > extensions as the client/server mode? I think the issue with replay > attacks can be solved by requiring both ends of the NTS association to > save unused cookies. Are there any other issues? Remember, cookies are opaque. When a client gets cookies from a server all it can do is pass them back; it can't decode them. So to get symmetric mode working over NTS Extensions for NTPv4, you'd have to exchange cookies in both directions during the NTS-KE handshake, and then every packet would have to have two cookie extensions as well as well as unique identifier extensions, one for each direction. This is all possible, but it's a pretty radical change this late in the game. The other issue is that we still need DTLS anyhow in order to secure mode 6, where there are stronger confidentiality requirements and the packets don't follow the normal structure so there's no well-defined way to include extension fields. _______________________________________________ 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 Fri Jun 2 11:15:41 2017 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 1AC90129544 for ; Fri, 2 Jun 2017 11:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGQnGCZ18IWe for ; Fri, 2 Jun 2017 11:15:40 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id D7577129401 for ; Fri, 2 Jun 2017 11:15:39 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 2775B86DB9A for ; Fri, 2 Jun 2017 18:15:39 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 192F186DAB6 for ; Fri, 2 Jun 2017 18:15:36 +0000 (UTC) Received: from mail-wm0-f52.google.com ([74.125.82.52]) by mail1.ntp.org with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dGr6c-0007RS-O1 for ntpwg@lists.ntp.org; Fri, 02 Jun 2017 18:15:36 +0000 Received: by mail-wm0-f52.google.com with SMTP id n195so32990052wmg.1 for ; Fri, 02 Jun 2017 11:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uNHoTsPK+XWM0gKcxOy3Zu1lGcH9JS0WSExTlwmEY2M=; b=qgqA6s8oEC/mGch7xPdFx+JCcWiCB9d9sOEKICaIvhxFYI5905drdEi4wo5UKcKjYG KLBp39F1iCP8xZXl4bCBJL/RMFfPO3Vo8lx/Losh7JpiVDEDm1lXZP2PNpyL6GTMIipJ ifsJwT9ZeNzDRIcM1z8mspF4v0gJBPqzil9a3yTqtKp1LBWJ8kS8uEgHToMjY4RRi/m6 uAB9r2FPO6pp3h6/Tfu5QMGJrBRn0pgQC5kMI8Ldir7Z+S8PSVuIZEzH54qtJD1ZOw4V /cEbOZcoOkTJp865KMMzDTWMjrS2C5lDU9a+Gooa3sEbOvNJCoJXpM7DcSaeQL4DnCt9 6ITA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uNHoTsPK+XWM0gKcxOy3Zu1lGcH9JS0WSExTlwmEY2M=; b=l2b1Dk2+lu/PZdhx26O3AAJYpc6S69aL/7ZVqb/j5KwWAiKq632KWT4/rxPISVdtLx +eXvwkTWlSjVKWi+Uz/LyRb1ZKcbZs9h6bRn1VI+twURa5bHdwep49tpJPC6bNCv4g/g 4a0C7o8lzy8LQDXDfCJmhqFF3HQbbaB05LfMfSjBsA+kxnMrXllE8IUATxxrlnrOGf8A dL9MT/hmFR1mfOHm56f6Qu29ftJTSMsNGN1Ri62JOxKvi2fP5O5PGys392SjA6ur1WFE G/C0c6G5U+jXn8Lcyz42yzHEYeHu6YGv9T8WDE3jhFZGWXxsDDJRghSnGZzLVENAvjV7 IGag== X-Gm-Message-State: AODbwcDvsdBIfg6uWSNE2ePPi2VFCcxiP3fQwNTCxcG5jtTMnP95DUQR 5DDnxW+8xCWY+HgDhr+k+DyviBSGqg== X-Received: by 10.80.172.134 with SMTP id x6mr7113148edc.12.1496427324637; Fri, 02 Jun 2017 11:15:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.140.67 with HTTP; Fri, 2 Jun 2017 11:15:23 -0700 (PDT) In-Reply-To: References: <20170602150326.GH25331@localhost> From: Daniel Franke Date: Fri, 2 Jun 2017 14:15:23 -0400 Message-ID: To: Miroslav Lichvar X-SA-Exim-Connect-IP: 74.125.82.52 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dfoxfranke@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Symmetric mode in NTS X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org 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" How about this text? Since DTLS-encapulated NTPv4 sessions may carry arbitrary NTP packets, there is no prescribed implication from an implementation's role as a DTLS client vs. DTLS server, to its role in the application-level Network Time Protocol. For example, it is entirely permissible, albeit perverse, for an implementation to initiate a DTLS handshake (thus acting in the role of DTLS client), and then once the handshake is completed, act as an NTP server with the DTLS server acting as an NTP client. However, in the name of practicality, the following guidelines are offered for what constitutes sensible default behavior. Implementations may depart from this guidance if the user configures them to do so. Implementations typically should not use DTLS-encapsulated NTPv4 for client/server mode, instead preferring to use NTS-KE and NTS Extensions for NTPv4. If DTLS-encapsulated NTPv4 is used for client/server mode, then the NTP client (mode 3) should be the DTLS client and the NTP server (mode 4) should be the DTLS server. For control mode (6), the party sending queries should be the DTLS client and the party responding to the queries should be the DTLS server. For symmetric operation between an active (mode 1) and passive (mode 2) peer, the active peer should be the DTLS client and the passive peer should be the DTLS server. For symmetric operation between two active (mode 1) peers, both parties should attempt to initiate a DTLS session with their peer. If one handshake fails and the other succeeds, the successfully-established session should be used for traffic in both directions. If both handshakes succeed, either session may be used and packets should receive identical dispositon regardless of which of the two sessions they arrived over. Inactive sessions may be timed out but the redundant session should not be proactively closed. If, likely as a result of user error, party A is configured as a symmetry active peer of party B, but party B is neither accepting DTLS handshakes from party A nor initiating one with it, then after a suitable number of failed attempts, party A may fall back to acting as an NTP client (mode 3) of party B using NTS-KE and NTS Extensions for NTPv4. On 6/2/17, Daniel Franke wrote: > On 6/2/17, Miroslav Lichvar wrote: >> I was reading the current text of nts-for-ntp about DTLS and the >> symmetric mode, but it's not obvious to me how exactly it's supposed >> to work. I have few questions: >> >> - Do the peers use separate ports for DTLS client and server? > > Servers use the IANA-allocated NTS port. Clients can use whatever they > want. > >> - What should happen when both peers are active and are started at the >> same time? Should each have its own DTLS connection? > > Good question, I'll add a paragraph clarifying this. I think the > answer is necessarily yes. Peers configured as active don't > necessarily know whether the other peer is active or passive, so they > each would need to at least attempt to initiate their own DTLS > session. Only one session is needed, but if two get established then I > think it's easier to just keep them both open than to attempt to > somehow break the symmetry and figure out which one to close. > >> - How should be handled the case when a passive peer doesn't mobilize >> an association? This is normally a stateless mode of operation. >> Should the peer reject the connection and let the other peer figure >> out that it needs to use the client mode and maybe try symmetric >> mode again later? > > I think this is a policy question and it's up to implementers. Servers > may choose to answer mode 1 packets over DTLS without standing up an > association, but if they do so they'll incur the overhead of keeping > the DTLS session open. Clients which try to peer with a server but > find that it's not accepting DTLS handshakes can implement whatever > fallback behavior seems appropriate. > >> To be honest, I don't like that the symmetric mode has a completely >> different protocol. Why not use the same NTS-KE over TLS and NTP >> extensions as the client/server mode? I think the issue with replay >> attacks can be solved by requiring both ends of the NTS association to >> save unused cookies. Are there any other issues? > > Remember, cookies are opaque. When a client gets cookies from a server > all it can do is pass them back; it can't decode them. So to get > symmetric mode working over NTS Extensions for NTPv4, you'd have to > exchange cookies in both directions during the NTS-KE handshake, and > then every packet would have to have two cookie extensions as well as > well as unique identifier extensions, one for each direction. This is > all possible, but it's a pretty radical change this late in the game. > > The other issue is that we still need DTLS anyhow in order to secure > mode 6, where there are stronger confidentiality requirements and the > packets don't follow the normal structure so there's no well-defined > way to include extension fields. > _______________________________________________ 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 Sat Jun 3 12:57:46 2017 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 5803C1293DB for ; Sat, 3 Jun 2017 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtVBqGNKf2ex for ; Sat, 3 Jun 2017 12:57:43 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id D7FED128D2E for ; Sat, 3 Jun 2017 12:57:42 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 1F98A86DB96 for ; Sat, 3 Jun 2017 19:57:42 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 3177186D83B for ; Sat, 3 Jun 2017 19:57:38 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dHFAv-000GHX-1D for ntpwg@lists.ntp.org; Sat, 03 Jun 2017 19:57:38 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v53JvQ4i015095-v53JvQ4k015095 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 3 Jun 2017 21:57:26 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id A7B8633194C; Sat, 3 Jun 2017 21:57:26 +0200 (CEST) MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <20170602150326.GH25331@localhost> From: dieter.sibold@ptb.de To: Daniel Franke Message-ID: Date: Sat, 3 Jun 2017 21:57:25 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Symmetric mode in NTS X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org Content-Type: multipart/mixed; boundary="===============4724616224638276648==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============4724616224638276648== Content-Type: multipart/alternative; boundary="=_alternative 006DA09CC1258134_=" --=_alternative 006DA09CC1258134_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with the text, but would like to have slight changes to the first p= aragraph. Since DTLS-encapsulated NTPv4 sessions may carry arbitrary NTP packets, there is no prescribed implication from an implementation's role as a DTLS client vs. DTLS server, to its role in the application-level Network Time Protocol. For example, it is entirely permissible for an=20 implementation to initiate a DTLS handshake (thus acting in the role of DTLS client), and then once the handshake is completed, act as an NTP server with the DTLS server acting as an NTP client. The following guidelines are offered as sensible default behavior. Implementations may depart from this guidance if the user configures them to do so. Dieter ------------------------------------- Dr. Dieter Sibold Physikalisch-Technische Bundesanstalt Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT Bundesallee 100=20 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de -----"ntpwg" wrote: --= --- To: Miroslav Lichvar From: Daniel Franke=20 Sent by: "ntpwg"=20 Date: 06/02/2017 20:15 Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] Symmetric mode in NTS How about this text? Since DTLS-encapulated NTPv4 sessions may carry arbitrary NTP packets, there is no prescribed implication from an implementation's role as a DTLS client vs. DTLS server, to its role in the application-level Network Time Protocol. For example, it is entirely permissible, albeit perverse, for an implementation to initiate a DTLS handshake (thus acting in the role of DTLS client), and then once the handshake is completed, act as an NTP server with the DTLS server acting as an NTP client. However, in the name of practicality, the following guidelines are offered for what constitutes sensible default behavior. Implementations may depart from this guidance if the user configures them to do so. Implementations typically should not use DTLS-encapsulated NTPv4 for client/server mode, instead preferring to use NTS-KE and NTS Extensions for NTPv4. If DTLS-encapsulated NTPv4 is used for client/server mode, then the NTP client (mode 3) should be the DTLS client and the NTP server (mode 4) should be the DTLS server. For control mode (6), the party sending queries should be the DTLS client and the party responding to the queries should be the DTLS server. For symmetric operation between an active (mode 1) and passive (mode 2) peer, the active peer should be the DTLS client and the passive peer should be the DTLS server. For symmetric operation between two active (mode 1) peers, both parties should attempt to initiate a DTLS session with their peer. If one handshake fails and the other succeeds, the successfully-established session should be used for traffic in both directions. If both handshakes succeed, either session may be used and packets should receive identical dispositon regardless of which of the two sessions they arrived over. Inactive sessions may be timed out but the redundant session should not be proactively closed. If, likely as a result of user error, party A is configured as a symmetry active peer of party B, but party B is neither accepting DTLS handshakes from party A nor initiating one with it, then after a suitable number of failed attempts, party A may fall back to acting as an NTP client (mode 3) of party B using NTS-KE and NTS Extensions for NTPv4. On 6/2/17, Daniel Franke wrote: > On 6/2/17, Miroslav Lichvar wrote: >> I was reading the current text of nts-for-ntp about DTLS and the >> symmetric mode, but it's not obvious to me how exactly it's supposed >> to work. I have few questions: >> >> - Do the peers use separate ports for DTLS client and server? > > Servers use the IANA-allocated NTS port. Clients can use whatever they > want. > >> - What should happen when both peers are active and are started at the >> same time? Should each have its own DTLS connection? > > Good question, I'll add a paragraph clarifying this. I think the > answer is necessarily yes. Peers configured as active don't > necessarily know whether the other peer is active or passive, so they > each would need to at least attempt to initiate their own DTLS > session. Only one session is needed, but if two get established then I > think it's easier to just keep them both open than to attempt to > somehow break the symmetry and figure out which one to close. > >> - How should be handled the case when a passive peer doesn't mobilize >> an association? This is normally a stateless mode of operation. >> Should the peer reject the connection and let the other peer figure >> out that it needs to use the client mode and maybe try symmetric >> mode again later? > > I think this is a policy question and it's up to implementers. Servers > may choose to answer mode 1 packets over DTLS without standing up an > association, but if they do so they'll incur the overhead of keeping > the DTLS session open. Clients which try to peer with a server but > find that it's not accepting DTLS handshakes can implement whatever > fallback behavior seems appropriate. > >> To be honest, I don't like that the symmetric mode has a completely >> different protocol. Why not use the same NTS-KE over TLS and NTP >> extensions as the client/server mode? I think the issue with replay >> attacks can be solved by requiring both ends of the NTS association to >> save unused cookies. Are there any other issues? > > Remember, cookies are opaque. When a client gets cookies from a server > all it can do is pass them back; it can't decode them. So to get > symmetric mode working over NTS Extensions for NTPv4, you'd have to > exchange cookies in both directions during the NTS-KE handshake, and > then every packet would have to have two cookie extensions as well as > well as unique identifier extensions, one for each direction. This is > all possible, but it's a pretty radical change this late in the game. > > The other issue is that we still need DTLS anyhow in order to secure > mode 6, where there are stronger confidentiality requirements and the > packets don't follow the normal structure so there's no well-defined > way to include extension fields. > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --=_alternative 006DA09CC1258134_= Content-Type: text/html; charset=UTF-8 Content-ID: <> Content-Transfer-Encoding: quoted-printable
I= agree with the text, but would like to have slight changes to the first pa= ragraph.

Since DTLS-encapsulated NTPv4 sessions may carry arbitrary NTP pack= ets,
= there is no prescribed implication from an implementation's role as a
DTLS clien= t vs. DTLS server, to its role in the application-level
Network Time Protocol. F= or example, it is entirely permissible for an 
implementation to initiate a= DTLS handshake (thus
acting in the role of DTLS client), and then once the hand= shake is
completed, act as an NTP server with the DTLS server acting as an NTP
client= . The following guidelines are offered as sensible default behavior.=
Implementat= ions may depart from this guidance if the user
configures them to do so.=

Dieter

-------------------------------------
Dr. Dieter Sibold
Physi= kalisch-Technische Bundesanstalt
Q.42 - Serversysteme und Datenhaltung
=
QM= -Verantwortlicher der Stelle IT
Bundesallee 100
D-38116 Braunschweig
=
Te= l:    +49-531-592-84 20

To: Miroslav Lichvar <mlichvar@redhat.com>
From: Daniel Fr= anke
Sent by: "ntpwg"
Date: 06/02/2017 20:15
Cc: <= a href=3D"mailto:ntpwg@lists.ntp.org" target=3D"=5Fblank">ntpwg@lists.ntp.o= rg
Subject: Re: [ntpwg] Symmetric mode in NTS

How about this text?

Since DTLS-encapulated NTPv4 sessions = may carry arbitrary NTP packets,
there is no prescribed implication from = an implementation's role as a
DTLS client vs. DTLS server, to its role in= the application-level
Network Time Protocol. For example, it is entirely= permissible, albeit
perverse, for an implementation to initiate a DTLS h= andshake (thus
acting in the role of DTLS client), and then once the hand= shake is
completed, act as an NTP server with the DTLS server acting as a= n NTP
client. However, in the name of practicality, the following guideli= nes
are offered for what constitutes sensible default
behavior. Implem= entations may depart from this guidance if the user
configures them to do= so.

Implementations typically should not use DTLS-encapsulated NTPv4 = for
client/server mode, instead preferring to use NTS-KE and NTS
Exten= sions for NTPv4. If DTLS-encapsulated NTPv4 is used for
client/server mod= e, then the NTP client (mode 3) should be the DTLS
client and the NTP ser= ver (mode 4) should be the DTLS server.

For control mode (6), the par= ty sending queries should be the DTLS
client and the party responding to = the queries should be the DTLS
server.

For symmetric operation betwe= en an active (mode 1) and passive (mode
2) peer, the active peer should b= e the DTLS client and the passive
peer should be the DTLS server.

<= /font>
Fo= r symmetric operation between two active (mode 1) peers, both
parties sho= uld attempt to initiate a DTLS session with their peer. If
=
one handshake = fails and the other succeeds, the
successfully-established session should= be used for traffic in both
directions. If both handshakes succeed, eith= er session may be used and
packets should receive identical dispositon re= gardless of which of the
two sessions they arrived over. Inactive session= s may be timed out but
the redundant session should not be proactively cl= osed.

If, likely as a result of user error, party A is configured as a=
symmetry active peer of party B, but party B is neither accepting DTLS
handshakes from party A nor initiating one with it, then after a
suitabl= e number of failed attempts, party A may fall back to acting as
<= /div>
an NTP cl= ient (mode 3) of party B using NTS-KE and NTS Extensions for
NTPv4.
= On 6/2/17, Daniel Franke <dfoxfranke@gmail.com> wrote:
> On 6/2/17, Mirosla= v Lichvar <ml= ichvar@redhat.com> wrote:
>> I was reading the current text = of nts-for-ntp about DTLS and the
>> symmetric mode, but it's not o= bvious to me how exactly it's supposed
>> to work. I have few quest= ions:
>>
>> - Do the peers use separate ports for DTLS clie= nt and server?
>
> Servers use the IANA-allocated NTS port. Clien= ts can use whatever they
> want.
>
>> - What should happe= n when both peers are active and are started at the
>>   same = time? Should each have its own DTLS connection?
>
> Good question= , I'll add a paragraph clarifying this. I think the
> answer is necess= arily yes. Peers configured as active don't
> necessarily know whether= the other peer is active or passive, so they
> each would need to at = least attempt to initiate their own DTLS
> session. Only one session i= s needed, but if two get established then I
> think it's easier to jus= t keep them both open than to attempt to
> somehow break the symmetry = and figure out which one to close.
>
>> - How should be hand= led the case when a passive peer doesn't mobilize
>>   an asso= ciation? This is normally a stateless mode of operation.
>>   = Should the peer reject the connection and let the other peer figure
>&= gt;   out that it needs to use the client mode and maybe try symmetric=
>>   mode again later?
>
> I think this is a policy= question and it's up to implementers. Servers
> may choose to answer = mode 1 packets over DTLS without standing up an
> association, but if = they do so they'll incur the overhead of keeping
> the DTLS session op= en. Clients which try to peer with a server but
> find that it's not a= ccepting DTLS handshakes can implement whatever
> fallback behavior se= ems appropriate.
>
>> To be honest, I don't like that the symm= etric mode has a completely
>> different protocol. Why not use the = same NTS-KE over TLS and NTP
>> extensions as the client/server mod= e? I think the issue with replay
>> attacks can be solved by requir= ing both ends of the NTS association to
>> save unused cookies. Are= there any other issues?
>
> Remember, cookies are opaque. When a= client gets cookies from a server
> all it can do is pass them back; = it can't decode them. So to get
> symmetric mode working over NTS Exte= nsions for NTPv4, you'd have to
> exchange cookies in both directions = during the NTS-KE handshake, and
> then every packet would have to hav= e two cookie extensions as well as
> well as unique identifier extensi= ons, one for each direction. This is
> all possible, but it's a pretty= radical change this late in the game.
>
> The other issue is tha= t we still need DTLS anyhow in order to secure
> mode 6, where there a= re stronger confidentiality requirements and the
> packets don't follo= w the normal structure so there's no well-defined
> way to include ext= ension fields.
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
ntpwg mailing list
--=_alternative 006DA09CC1258134_=-- --===============4724616224638276648== 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 --===============4724616224638276648==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jun 5 07:01:24 2017 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 BB0B1129553 for ; Mon, 5 Jun 2017 07:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52agX-aX9mpM for ; Mon, 5 Jun 2017 07:01:23 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAEB12951F for ; Mon, 5 Jun 2017 07:01:23 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 47CFB86DB84 for ; Mon, 5 Jun 2017 14:01:22 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id C707586D83B for ; Mon, 5 Jun 2017 14:01:18 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dHsZB-0009L4-8w for ntpwg@lists.ntp.org; Mon, 05 Jun 2017 14:01:18 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E19233D95C; Mon, 5 Jun 2017 14:01:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E19233D95C Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mlichvar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E19233D95C Received: from localhost (holly.brq.redhat.com [10.34.24.121]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3205617DFB; Mon, 5 Jun 2017 14:01:07 +0000 (UTC) Date: Mon, 5 Jun 2017 16:00:55 +0200 From: Miroslav Lichvar To: Daniel Franke Message-ID: <20170605140055.GK25331@localhost> References: <20170602150326.GH25331@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 05 Jun 2017 14:01:08 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Symmetric mode in NTS X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org 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" On Fri, Jun 02, 2017 at 02:15:23PM -0400, Daniel Franke wrote: > How about this text? Thanks, it does help. I have few more questions below. > For symmetric operation between two active (mode 1) peers, both > parties should attempt to initiate a DTLS session with their peer. If > one handshake fails and the other succeeds, the > successfully-established session should be used for traffic in both > directions. If both handshakes succeed, either session may be used and > packets should receive identical dispositon regardless of which of the > two sessions they arrived over. Inactive sessions may be timed out but > the redundant session should not be proactively closed. How will the peers know which two DTLS sessions belong together? Should they assume all connections with an IP address belong to the same server instance? That would probably create a new limitation. In normal NTP it is possible to peer with multiple instances on one IP address, e.g. multiple computers behind NAT, as there is only one UDP connection per symmetric association and both ports of an active-active association are known. If NTS needs four ports and only two are known for each peer, that won't work. > If, likely as a result of user error, party A is configured as a > symmetry active peer of party B, but party B is neither accepting DTLS > handshakes from party A nor initiating one with it, then after a > suitable number of failed attempts, party A may fall back to acting as > an NTP client (mode 3) of party B using NTS-KE and NTS Extensions for > NTPv4. The trouble with this is when B is reconfigured to accept symmetric associations with A, A will likely need to be restarted in order to switch to the symmetric mode. -- Miroslav Lichvar _______________________________________________ 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 Jun 5 08:11:11 2017 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 E9614128B4E for ; Mon, 5 Jun 2017 08:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI_zguiyMXqg for ; Mon, 5 Jun 2017 08:11:08 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id BE4E512947E for ; Mon, 5 Jun 2017 08:11:08 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 4081486DB88 for ; Mon, 5 Jun 2017 15:11:07 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id E493786D83B for ; Mon, 5 Jun 2017 15:11:03 +0000 (UTC) Received: from mx1.redhat.com ([209.132.183.28]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dHteg-000BiE-4Y for ntpwg@lists.ntp.org; Mon, 05 Jun 2017 15:11:03 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E0EBD3B716; Mon, 5 Jun 2017 15:10:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E0EBD3B716 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mlichvar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E0EBD3B716 Received: from localhost (holly.brq.redhat.com [10.34.24.121]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 353F617986; Mon, 5 Jun 2017 15:10:52 +0000 (UTC) Date: Mon, 5 Jun 2017 17:10:40 +0200 From: Miroslav Lichvar To: Daniel Franke Message-ID: <20170605151040.GA18917@localhost> References: <20170602150326.GH25331@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 05 Jun 2017 15:10:53 +0000 (UTC) X-SA-Exim-Connect-IP: 209.132.183.28 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mlichvar@redhat.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Symmetric mode in NTS X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org 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" On Fri, Jun 02, 2017 at 12:58:46PM -0400, Daniel Franke wrote: > On 6/2/17, Miroslav Lichvar wrote: > > To be honest, I don't like that the symmetric mode has a completely > > different protocol. Why not use the same NTS-KE over TLS and NTP > > extensions as the client/server mode? I think the issue with replay > > attacks can be solved by requiring both ends of the NTS association to > > save unused cookies. Are there any other issues? > > Remember, cookies are opaque. When a client gets cookies from a server > all it can do is pass them back; it can't decode them. So to get > symmetric mode working over NTS Extensions for NTPv4, you'd have to > exchange cookies in both directions during the NTS-KE handshake, and > then every packet would have to have two cookie extensions as well as > well as unique identifier extensions, one for each direction. This is > all possible, but it's a pretty radical change this late in the game. Making the protocol fully symmetric in active-active associations would be nice, but I'm not sure if it's necessary. I think it could work using just one client/server NTS association, except the server needs to save cookies issued to the client and allow only one update per cookie. The server would be checking cookies and the client would be checking unique identifiers in order to protect against replay attacks. As I understand it, the client doesn't need to decode the cookies. The question is how to determine the direction of the NTS client/server association when both peers are active. One solution that comes to my mind would be to include an ID of the peer in the NTS-KE. Each peer has a random ID. A new record would be added to NTS-KE to request a symmetric association, which would include the ID. An active peer will compare the ID with its own and allow the KE to succeed only if it's smaller. If it's not smaller it will return a specific error code. That way, if both are trying to make an NTS-KE association, only one will succeed. A passive peer will create the association and ignore the ID. I can try to look into the details and prepare changes for the document if there is interest. > The other issue is that we still need DTLS anyhow in order to secure > mode 6, where there are stronger confidentiality requirements and the > packets don't follow the normal structure so there's no well-defined > way to include extension fields. For mode 6 it makes perfect sense. With modes 1 and 2 not so much. It will probably be good enough for most cases, but it's not a full replacement of the older authententication protocols. So far, I noticed the following issues: - no stateless passive mode - problematic pairing of DTLS sessions - requires timestamping of messages on a new port - won't work with HW which can timestamp only packets on port 123 (or 319) - will require changes in QoS classification on routers/switches - won't work with future NTP extensions for delay corrections in routers/switches I think this would all disappear if we used NTS-KE and NTP extensions. -- Miroslav Lichvar _______________________________________________ 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 Tue Jun 13 12:56:15 2017 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 A6541129A99 for ; Tue, 13 Jun 2017 12:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CXlIKTJuYI2 for ; Tue, 13 Jun 2017 12:56:14 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9A327129A8F for ; Tue, 13 Jun 2017 12:56:12 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 4C28886DB79 for ; Tue, 13 Jun 2017 19:56:12 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id AE44386D831 for ; Tue, 13 Jun 2017 19:56:08 +0000 (UTC) Received: from mail.ietf.org ([4.31.198.44]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dKruy-000G02-PS for ntpwg@lists.ntp.org; Tue, 13 Jun 2017 19:56:08 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC71294DB; Tue, 13 Jun 2017 12:55:59 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149738375960.7563.16825469722667148743@ietfa.amsl.com> Date: Tue, 13 Jun 2017 12:55:59 -0700 X-SA-Exim-Connect-IP: 4.31.198.44 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) Subject: [ntpwg] I-D Action: draft-ietf-ntp-bcp-05.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org 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" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol of the IETF. Title : Network Time Protocol Best Current Practices Authors : Denis Reilly Harlan Stenn Dieter Sibold Filename : draft-ietf-ntp-bcp-05.txt Pages : 22 Date : 2017-06-13 Abstract: NTP Version 4 (NTPv4) has been widely used since its publication as RFC 5905 [RFC5905]. This documentation is a collection of Best Practices from across the NTP community. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-bcp-05 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-bcp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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 Tue Jun 13 13:00:29 2017 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 6FE5012969E for ; Tue, 13 Jun 2017 13:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=oroliagroup.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWOFXrveMCoz for ; Tue, 13 Jun 2017 13:00:27 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 759BD1294DB for ; Tue, 13 Jun 2017 13:00:27 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 340A986DB79 for ; Tue, 13 Jun 2017 20:00:27 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 948D286D831 for ; Tue, 13 Jun 2017 20:00:23 +0000 (UTC) Received: from mail-eopbgr50085.outbound.protection.outlook.com ([40.107.5.85] helo=EUR03-VE1-obe.outbound.protection.outlook.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dKrz6-000GCa-3b for ntpwg@lists.ntp.org; Tue, 13 Jun 2017 20:00:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=OROLIAGROUP.onmicrosoft.com; s=selector1-spectracom-orolia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Uv4Kiklxkgxf/1jvexTxxc3jZJa3HBl+Mp7jHuDJwyo=; b=g7CuUXk6aTWicAmtYnCuBLlxhc3Z/0CUoUblVnfl+cvndQRjzjLQB88p7qcaHkJAy0njRGXKDMUHxL4ox1kYuFKuC7xoehN+FC8i4+PASbPwdTt+zS8rPeRUm37zbejTKcxKkpILAaX3gAMrlmt5HkTEcqbstEkhJIGim2q+qYo= Received: from AM3PR06MB1202.eurprd06.prod.outlook.com (10.163.60.28) by AM3PR06MB1204.eurprd06.prod.outlook.com (10.163.60.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Tue, 13 Jun 2017 20:00:13 +0000 Received: from AM3PR06MB1202.eurprd06.prod.outlook.com ([fe80::789e:de7:298c:1753]) by AM3PR06MB1202.eurprd06.prod.outlook.com ([fe80::789e:de7:298c:1753%14]) with mapi id 15.01.1157.017; Tue, 13 Jun 2017 20:00:13 +0000 From: Denis Reilly To: "ntpwg@lists.ntp.org" Thread-Topic: New rev of NTP BCP Thread-Index: AdLkfxzw5I5xRpjmTlO8ksnA9AJUKw== Date: Tue, 13 Jun 2017 20:00:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=denis.reilly@spectracom.orolia.com; x-originating-ip: [66.193.84.98] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR06MB1204; 7:gdNdjK6ew920ZJ1FQ+xMVJpvsex6Kxs32Rvq30MGde90o5XJ1emKA2265/iksoY2uJ2DueVx+9/LGhRtfjPpFAqIXo4bvJxL/IPa6q9scpiiLkfBn51z6FPEJkN2jbGj1f7GKlqUgs6UEUmmEaCSHZL/AGyPdyC/rIhpqBYdQITAaxEEa0fMu6HnwhrAa7HWawFs77+b6X4GZeqxcT8d9f1mokJtp/yWiUz/xYeMyziSTZjiDGOZxxu6/IhFvwsGLLoWbRt+ki33dW54fWH6m8H751h06r0aXQst7qJGNmNHv85gkpLsKSFOyVUIZD+6kAivURXh9r/2+rkVj3Tb6w== x-ms-traffictypediagnostic: AM3PR06MB1204: x-ms-office365-filtering-correlation-id: 8cfbb1ed-2129-47e5-3eda-08d4b296cdb5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR06MB1204; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR06MB1204; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR06MB1204; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(189002)(41584004)(199003)(3280700002)(478600001)(3660700001)(97736004)(6916009)(50986999)(54356999)(99286003)(6506006)(6436002)(66066001)(25786009)(2351001)(42882006)(2501003)(15974865002)(55016002)(966005)(7696004)(5250100002)(14454004)(2906002)(110136004)(8676002)(53936002)(6116002)(3846002)(1730700003)(9686003)(68736007)(33656002)(105586002)(102836003)(86362001)(6306002)(8936002)(189998001)(305945005)(106356001)(38730400002)(101416001)(7736002)(74316002)(5640700003)(81166006)(81156014)(5660300001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR06MB1204; H:AM3PR06MB1202.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: spectracom.orolia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: spectracom.orolia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 20:00:13.1190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a263030c-9c1b-421f-9471-1dec0b29c664 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB1204 X-SA-Exim-Connect-IP: 40.107.5.85 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: denis.reilly@spectracom.orolia.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] New rev of NTP BCP X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 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" The latest rev of the NTP BCP has been submitted, incorporating all the rem= aining WGLC feedback. https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/ The section on KoD packets has been reworked and moved out of the Embedded = Device section into the Security Best Practices section. Some changes were also made to the "Broadcast Mode Should Only Be Used On T= rusted Networks" section. Best Regards, -- Denis Reilly=A0=A0=A0 dreilly@spectracom.com Lead Engineer, Spectracom www.spectracomcorp.com Office: (585) 321-5837 Fax:=A0=A0=A0 (585) 321-5219 An Orolia Group Business: www.orolia.com This e-mail and any files transmitted with it are confidential and are inte= nded solely for the use of the individual or entity to which they are addre= ssed. If you received this e-mail in error please note that any use, dissem= ination, forwarding, printing, or copying of this e-mail is strictly prohib= ited. _______________________________________________ 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 Jun 18 09:08:22 2017 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 58DEB129481 for ; Sun, 18 Jun 2017 09:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqA_7toLAboU for ; Sun, 18 Jun 2017 09:08:09 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 32B2312947C for ; Sun, 18 Jun 2017 09:08:09 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id DA5CF86DB78 for ; Sun, 18 Jun 2017 16:08:08 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 78D1986DABA for ; Sun, 18 Jun 2017 16:08:04 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.120]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dMcjy-000Itk-Sc for ntpwg@lists.ntp.org; Sun, 18 Jun 2017 16:08:04 +0000 Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id v5IG7nGI011281-v5IG7nGK011281 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 18 Jun 2017 18:07:49 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 72EC03B0786; Sun, 18 Jun 2017 18:07:48 +0200 (CEST) MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: dieter.sibold@ptb.de To: ntpwg@lists.ntp.org, tictoc@ietf.org Message-ID: Date: Sun, 18 Jun 2017 18:07:48 +0200 X-SA-Exim-Connect-IP: 192.53.103.120 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Minutes from last NTP WG Interim Meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 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="===============6326753066864233326==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============6326753066864233326== Content-Type: multipart/alternative; boundary="=_alternative 00589ACEC1258143_=" --=_alternative 00589ACEC1258143_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, here are the minutes from the last virtual NTP interim meeting at 25th May.= You may also find it under: https://www.ietf.org/proceedings/interim-2017-ntp-01/minutes/minutes-interi= m-2017-ntp-01-201705251500-00 Dieter NTP WG INTERIM MEETING 25 May 2017, 3 pm UTC PARTICIPANTS: Aanchal Malhotra, Ankit Kumar Sinha, Daniel Franke, Danny Meyer, Dave Mills, Denis Reilly, Dhruv Dhody, Dieter Sibold, Harlan Stenn, Karen O=E2=80=99Donoghue, Kristof Teichel, Kyle Rose, Miroslav Lichvar, Peter Mey= er, Richard Welty, Robert Nay, Robert Annessie, Ronan Flood, Sharon Goldberg, Steward Bryant, Sue Graves, Tal Mizrahi, Yaakov Stein, Scott Fluhrer - Karen: Presentation of IETF Note Well - Nobody opposed to record this meeting AGENDA - Network Time Security - BCP - Data Minimization - Message Authentication Code - Extension fields and RefID - YANG Data Model - AOB OVERVIEW/SUMMARY/NEXT STEPS FOR THE NTS DOCUMENTS. draft-ietf-ntp-network-time-security draft-ietf-ntp-network-time-security - Daniel reported on the draft 'draft-ietf-ntp-network-time-security'. - The normative parts of the draft are more or less final. - The Security Consideration section will be extended before the next submission. - Daniel plans to submit the changed version by the end of March and will request the WGLC for it immediately after. The WGLC will cover the draft 'draft-ietf-ntp-network-time-security' only. It will not cover the other NTS related specifications. - Summary of the changes: - Reduction of the size of the NTS next protocol negotiation record - Changes to the IANA Consideration section - Corrections of some inconsistencies which results from the removal of the DLTS packet smuggling - Management of keys and cookies for load balanced servers - Karen proposes to give the working group a one week time frame to comment on the draft. After that period the the WGLC shall be issued if there is no objections against it. She would like to have a virtual interim meeting by the end of June to discuss the results from the WGLC. Because this interim meeting would take place just two weeks before the next IETF meeting all participants agreed to not have it. - Kristof will update the generic draft 'draft-ietf-ntp-network-time-security' by the end of June. Summary - Daniel to publish update by 26 May. - WG has until 31 May to indicate that the document is NOT ready for working group last call (WGLC) - If no strong opposition, document will go to WGLC in early June. - Kristof will work on updating the generic NTS document by the end of June. BCP: OVERVIEW/SUMMARY/ NEXT STEPS FROM THE WGLC draft-ietf-ntp-bcp - In April Denis submitted an update of the document. The changes were based on the comments received during the WGLC period. - An additional update of the documents were submitted last Monday (version 4), based on some additional feedback. It contains text changes for the leap seconds, autokey, anycast sections. - Denis points out that even when the document talks about the reference implementation it brings up ideas that are applicable to other implementations as well. - Denis makes clear that all the feedback of the WGLC are incorporated into the latest version of the draft. - Karen asks if we received feedback that indicates that the draft is not ready for publication if this feedback is not incorporated. - Denis: Daniel suggested mandatory changes to the autokey section in order to approve the document. The draft was updated accordingly. This was the only feedback that was requested to be fixed. - Daniel indicates no objection to the changes made. - Karen: if there are no opposition by tomorrow it can be submitted for publication. - Karen describes the next steps necessary for publication of the document. Next steps include approval by the AD, a IETF Last Call, IESG review. - Sharon ask for the appropriate time to sum minor comments on the draft. - Denis ask for a dead line for minor changes. - Karen: Minor changes until May 31th. Summary - Update addressing all WGLC comments has been published. - WG has until 31 May to indicate that the updated document should NOT be forwarded to the IESG. - Chairs will forward to IESG in early June if there is no strong opposition. WAY FORWARD FOR draft-dfranke-ntp-data-minimization-02 - Karen: There have been no objections to adopt this draft. It will be approved as a WG document - Daniel will submit a new version of the draft. It will contain a change regarding the precision field which was requested by Harlan. - Sharon points out that with regard to data minimization it makes sense to also minimize the information leak in the refid field. Together with Harlan she is working on this subject, e.g. in the not-you draft. Should this work go into this draft also? - Daniel points out that his data minimization draft pertain only to client and not server packets. He assumes that his draft and the not-you draft are orthogonal. - Sharon points out that an adversary can easily request information from a server that can be utilized for an attack. Data minimization should minimize this also for the server packets. Why mode 1 and mode 2 packets are not addressed by the draft? - Daniel: The goals of this draft are to solve the unlinkability issue with NTP and strengthened the unpredictability of the origin timestamp. - Sharon: NTP is a hierarchical protocol. Clients may also be server. Therefore, data minimization should consider client and server packets also. - Daniel will submit the new version of his draft and will wait for further comments about what should go into it. - Harlan expresses that it is fine to allow this draft to be applied in WAN environments but it should not be required to be applied in LAN environments. As Daniel points out, this draft requires only that a server must not reject packets which comply with this document. There are no additional hard requirments. - Karen: The time line for this document is about one month to do an initial review before a WGLC is issued. Next steps will be discussed during the Prag meeting. Summary - Adopted as a WG document, Daniel will publish as a wg document - Working group will have about a month to review, if no major issues identified will proceed to WGLC in early July. WAY FORWARD FOR draft-ietf-ntp-mac-00 - Aanchal reports that there were no comments or objections to this draft. Consequently, there are no changes. She recommend to issue a WGLC for it. - Karen: This is a short and straight forward draft. She would like to issue a WGLC. Any objections should be placed before 31th May. - No opposition. - Short discussion about agility of applied algorithms between Danny, Harlan and Karen. - Daniel: no objections for WGLC. He will place an feedback during WGLC. Summary - Document is stds track updating RFC 5905 - WG has until 31 May to indicate that the document is NOT ready for working group last call (WGLC) - If no strong opposition, document will go to WGLC in early June WAY FORWARD FOR DRAFTS RELATED TO EXTENSION FIELDS AND REFID STUFF draft-ietf-ntp-refid-updates draft-stenn-ntp-suggest-refid draft-stenn-ntp-i-do - Karen: There has been a lot of discussion which of the drafts should go on and which should be combined. - Danny suggest only to publish one refid draft only. - Harlan opposes. He already combined different refid drafts. - The refid-update draft is moving forward although it is currently expired (Sharon is working on this draft) - Sharon regards the not-you-refid draft as very important especially in the context of data minimization and unlinkability (it will be re-submitted by Harlan and Sharon) - Karen asks Harlan to submit a roadmap for the extension field and refid drafts to the WG, so that the WG knows what is currently on the agenda. - Tal supports Karen's suggestion to separate new features from RFC 7822bis. In case we decide to do a RFC 7822bis he proposes to use 'pseudo code' to clarify the changes. - Karen supports Tal's suggestion. - Harlan opens the discussion of having a single documents for each extension field or one document for all extension fields. - Daniel opposes to both extremes. He suggest to combine logically related extension fields into a single document. Like for example NTS. - Karen points at that set of extension fields may be publish as single RFCs and over time these RFCs can be rolled into a master documents. - Daniel suggest that such an consolidation should be done with a new NTP version. - At this point Karen interrupts this discussion. The rules of the consolidations can be defined later. - Karen reiterates that documents should be re-submitted for the meeting in Prag. Summary - Harlan/Sharon will republish https://datatracker.ietf.org/doc/draft-ietf-ntp-refid-updates/ - Harlan will provide a summary/roadmap for the remaining expired drafts (near term plan) - Harlan/Danny will insure that https://datatracker.ietf.org/doc/draft-mayer-ntp-mac-extension-field/ is covered somewhere OVERVIEW/SUMMARY/NEXT STEPS FOR THE YANG MODEL draft-wu-ntp-ntp-cfg - Ankit presents changes in the YANG data model between version 2 and 3 of the draft. The changes are (details see presentation: https://www.ietf.org/proceedings/interim-2017-ntp-01/slides/slides-inte= rim-2017-ntp-01-sessa-a-yang-data-model-for-ntp-00.pdf) - Yang tree rearranged as per - NTP Interface - Use of presence - Yang Data-type correction - Removed autokey - No changs to the peer mode. - Ankit asks for WG adoption and more review comments - Danny points out a problem with the Yang date and time format of timestamps. NTP timestamps are 64 bit decimal. They are data no timestamps. - Tal supports the usage of decimal. Date and time does not make sense in this case. - Dhruv suggest to use both date and time and probably decimal. From the management point of view it would be helpful to have also data and time. They will clarify this. - The Yang Model must be adjusted if new extension fields are published. - Harlan ask for the concept of authorization. YANG and Netconf have a security concept for authorization, which is not yet adopted. This can and should be done in future versions. - No opposition to adopt this as a WG document. Summary - Karen will issue a WG call for adoption of the draft AOB - Danny: will revises the mac-extension-field draft. Harlan indicates that this is already incorporated by Harlan in one of his drafts. - Denis: TICTOC staff: What is the status of the Enterprise profile? - Karen: the plan is to publish the draft. She will remind Doug to proceed with it. - Kyle: ask for the purpose of the draft-ietf-ntp-mac draft because there is not much normative language. It should be more descriptive. It also needs test vectors. - Aanachal makes clear that the main purpose of this draft is do deprecate the MD5 legacy MAC. To use it for NTP packets it needs more descriptive language. - The draft 'draft-ietf-ntp-mac' will be a standard track update to RFC 5905. ------------------------------------- Dr. Dieter Sibold Physikalisch-Technische Bundesanstalt Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT Bundesallee 100=20 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de --=_alternative 00589ACEC1258143_= Content-Type: text/html; charset=UTF-8 Content-ID: <> Content-Transfer-Encoding: quoted-printable

Hi all,

here are the minutes from = the last virtual NTP interim meeting at 25th May. You may also find it unde= r:

Dieter


NTP WG INTERIM MEETING

25 May 2017, 3 pm UTC

= PARTICIPA= NTS:

Aanchal Malhotra, Ankit Kumar Sinha, Daniel Frank= e, Danny Meyer, Dave
Mills, Denis Reilly, Dhruv Dhody, Dieter Sibol= d, Harlan Stenn, Karen
O=E2=80=99Donoghue, Kristof Teichel, Kyle Ro= se, Miroslav Lichvar, Peter Meyer,
Richard Welty, Robert Nay, Rober= t Annessie, Ronan Flood, Sharon
Goldberg, Steward Bryant, Sue Grave= s, Tal Mizrahi, Yaakov Stein, Scott
Fluhrer

- =   Karen: Presentation of IETF Note Well
-   Nobody oppose= d to record this meeting



AGE= NDA


-   Network Time Security=
-   Data Minimization
-   Message = Authentication Code
-   Extension fields and RefID
- &= nbsp; YANG Data Model
-   AOB


=
OVERVIEW/SUMMARY/NEXT STEPS FOR THE NTS DOCUMENTS.
<= br>

draft-ietf-ntp-network-time-security
<= div>draft= -ietf-ntp-network-time-security

-   Daniel report= ed on the draft 'draft-ietf-ntp-network-time-security'.
  &nbs= p; -   The normative parts of the draft are more or less final.=
        next submission.
&= nbsp;   -   Daniel plans to submit the changed version by the end= of March
        and will request the WGLC for= it immediately after. The WGLC
        will co= ver the draft 'draft-ietf-ntp-network-time-security'
    =     only. It will not cover the other NTS related specifications.=
    -   Summary of the changes:
  &nbs= p;     -   Reduction of the size of the NTS next protocol ne= gotiation
            record
=         -   Changes to the IANA Consideration sect= ion
        -   Corrections of some incons= istencies which results from the
         =   removal of the DLTS packet smuggling
      &= nbsp; -   Management of keys and cookies for load balanced servers
-   Karen proposes to give the working group a one week time fram= e to
    comment on the draft. After that period the the = WGLC shall be issued
    if there is no objections agains= t it. She would like to have a
    virtual interim meetin= g by the end of June to discuss the results
    from the = WGLC. Because this interim meeting would take place just
<= font face=3D"Default Monospace, Courier New, Courier, monospace">  &nb= sp; two weeks before the next IETF meeting all participants agreed to
    not have it.
-   Kristof will update the gene= ric draft
    'draft-ietf-ntp-network-time-security' by t= he end of June.


Summary
=
-   Daniel to publish update by 26 May.
-   WG has un= til 31 May to indicate that the document is NOT ready for
=   &n= bsp; working group last call (WGLC)
-   If no strong oppositio= n, document will go to WGLC in early June.
-   Kristof will wo= rk on updating the generic NTS document by the end of
   = June.



BCP: OVERVIEW/SUMMA= RY/ NEXT STEPS FROM THE WGLC


draft-ietf-n= tp-bcp

-   In April Denis submitted an update of = the document. The changes were
    based on the comments = received during the WGLC period.
-   An additional update of t= he documents were submitted last Monday
    (version 4), = based on some additional feedback. It contains text
    c= hanges for the leap seconds, autokey, anycast sections.
-   De= nis points out that even when the document talks about the
  &= nbsp; reference implementation it brings up ideas that are applicable to
    other implementations as well.
-   Denis m= akes clear that all the feedback of the WGLC are incorporated
<= div> = ;   into the latest version of the draft.
-   Karen asks= if we received feedback that indicates that the draft is
=   &n= bsp; not ready for publication if this feedback is not incorporated.=
    order to approve the document. The draft was upda= ted accordingly.
    This was the only feedback that was = requested to be fixed.
-   Daniel indicates no objection to th= e changes made.
-   Karen: if there are no opposition by tomor= row it can be submitted
    for publication.
=
- &n= bsp; Karen describes the next steps necessary for publication of the=
    IESG review.
-   Sharon ask for = the appropriate time to sum minor comments on the
    dra= ft.
-   Denis ask for a dead line for minor changes.
-=   Karen: Minor changes until May 31th.

=
Summary

-   Update addressing all WGLC commen= ts has been published.
-   WG has until 31 May to indicate tha= t the updated document should NOT
    be forwarded to the= IESG.
-   Chairs will forward to IESG in early June if there = is no strong
    opposition.



WAY FORWARD FOR


<= div>draft= -dfranke-ntp-data-minimization-02

-   Karen: The= re have been no objections to adopt this draft. It will be
  &= nbsp; approved as a WG document
-   Daniel will submit a new v= ersion of the draft. It will contain a
    change regardi= ng the precision field which was requested by Harlan.
-   Shar= on points out that with regard to data minimization it makes
 =   sense to also minimize the information leak in the refid field.
    Together with Harlan she is working on this subject, e.g= . in the
    not-you draft. Should this work go into this= draft also?
-   Daniel points out that his data minimization = draft pertain only to
    client and not server packets. = He assumes that his draft and the
    not-you draft are o= rthogonal.
-   Sharon points out that an adversary can easily = request information
    from a server that can be utilize= d for an attack. Data minimization
    should minimize th= is also for the server packets. Why mode 1 and
    mode = 2 packets are not addressed by the draft?
-   Daniel: The goal= s of this draft are to solve the unlinkability issue
    = with NTP and strengthened the unpredictability of the origin
 =   timestamp.
-   Sharon: NTP is a hierarchical protocol.= Clients may also be server.
    Therefore, data minimiza= tion should consider client and server
    packets also.<= /font>
-   Daniel will submit the new version of his draft and will w= ait for
    further comments about what should go into it= .
-   Harlan expresses that it is fine to allow this draft to = be applied
    in WAN environments but it should not be r= equired to be applied in
    LAN environments. As Daniel = points out, this draft requires only
    that a server mu= st not reject packets which comply with this
    document= . There are no additional hard requirments.
-   Karen: The tim= e line for this document is about one month to do an
    = initial review before a WGLC is issued. Next steps will be discussed=


= Summary

-   Adopted as a WG document, Daniel will= publish as a wg document
-   Working group will have about a = month to review, if no major issues
    identified will p= roceed to WGLC in early July.



=


draft-ietf-ntp-mac-00

-   Aanchal reports that there were no comments or= objections to this
    draft. Consequently, there are no= changes. She recommend to issue a
    WGLC for it.
-   Karen: This is a short and straight forward draft. She would li= ke to
    issue a WGLC. Any objections should be placed b= efore 31th May.
-   No opposition.
-   Short disc= ussion about agility of applied algorithms between Danny,
=   &n= bsp; Harlan and Karen.
-   Daniel: no objections for WGLC. He = will place an feedback during
    WGLC.
=

Summary

-   Document is stds tra= ck updating RFC 5905
-   WG has until 31 May to indicate that = the document is NOT ready for
    working group last call= (WGLC)
-   If no strong opposition, document will go to WGLC = in early June



WAY FORWARD FO= R DRAFTS RELATED TO EXTENSION FIELDS AND REFID STUFF

<= br>
draft-ietf-ntp-refid-updates
draft-stenn-ntp-suggest-re= fid
draft-stenn-ntp-i-do

-   Karen: The= re has been a lot of discussion which of the drafts should
  &= nbsp; go on and which should be combined.
-   Danny suggest on= ly to publish one refid draft only.
-   Harlan opposes. He alr= eady combined different refid drafts.
-   The refid-update dra= ft is moving forward although it is currently
    expir= ed (Sharon is working on this draft)
-   Sharon regards the no= t-you-refid draft as very important especially
    in th= e context of data minimization and unlinkability (it will be
 =   re-submitted by Harlan and Sharon)
-   Karen asks Harl= an to submit a roadmap for the extension field and
    re= fid drafts to the WG, so that the WG knows what is currently on
&nb= sp;   the agenda.
-   Tal supports Karen's suggestion to = separate new features from RFC
    7822bis. In case we de= cide to do a RFC 7822bis he proposes to use
    'pseudo c= ode' to clarify the changes.
-   Karen supports Tal's suggesti= on.
-   Harlan opens the discussion of having a single documen= ts for each
    extension field or one document for all e= xtension fields.
    -   Daniel opposes to both extr= emes. He suggest to combine logically
        r= elated extension fields into a single document. Like for
<= font face=3D"Default Monospace, Courier New, Courier, monospace">  &nb= sp;     example NTS.
    -   Karen points = at that set of extension fields may be publish as
    &nb= sp;   single RFCs and over time these RFCs can be rolled into a master=
        documents.
    - &nb= sp; Daniel suggest that such an consolidation should be done with a<= /div>
        new NTP version.
    - &nb= sp; At this point Karen interrupts this discussion. The rules of the=
= -   Karen reiterates that documents should be re-submitted for the
    meeting in Prag.


<= div>Summa= ry

-   Harlan/Sharon will republish
<= div> = ;   https://datatracker.ietf.org/doc/draft-ietf-nt= p-refid-updates/
-   Harlan will provide a summary/roadmap= for the remaining expired
    drafts (near term plan)
-   Harlan/Danny will insure that
    is covered somewhere
<= div>
<= /font>


OVERVIEW/SUMMARY/NEXT STEPS FOR THE YANG = MODEL


draft-wu-ntp-ntp-cfg

-   Ankit presents changes in the YANG data model between versi= on 2 and
    3 of the draft. The changes are (details see= presentation:
    -   Yang tree rearran= ged as per
    -   NTP Interface
  &nbs= p; -   Use of presence
    -   Yang Data-type c= orrection
    -   Removed autokey
<= font face=3D"Default Monospace, Courier New, Courier, monospace">-   N= o changs to the peer mode.
-   Ankit asks for WG adoption and = more review comments
-   Danny points out a problem with the Y= ang date and time format of
    timestamps. NTP timestamp= s are 64 bit decimal. They are data no
    timestamps.
    -   Tal supports the usage of decimal. Date and ti= me does not make
        sense in this case.
    -   Dhruv suggest to use both date and time and pr= obably decimal.
        From the management poi= nt of view it would be helpful to have
        = also data and time. They will clarify this.
-   The Yang Model= must be adjusted if new extension fields are
    publi= shed.
-   Harlan ask for the concept of authorization. YANG an= d Netconf have a
    security concept for authorization, = which is not yet adopted. This
    can and should be done= in future versions.
-   No opposition to adopt this as a WG d= ocument.


Summary

- &= nbsp; Karen will issue a WG call for adoption of the draft



AOB


- &nbs= p; Danny: will revises the mac-extension-field draft. Harlan indicates
    that this is already incorporated by Harlan in one of his= drafts.
-   Denis: TICTOC staff: What is the status of the En= terprise profile?
    -   Karen: the plan is to publ= ish the draft. She will remind Doug to
        = proceed with it.
-   Kyle: ask for the purpose of the draft-ie= tf-ntp-mac draft because
    there is not much normative = language. It should be more descriptive.
    It also need= s test vectors.
    -   Aanachal makes clear that th= e main purpose of this draft is do
        depr= ecate the MD5 legacy MAC. To use it for NTP packets it needs
 =       more descriptive language.
    - &n= bsp; The draft 'draft-ietf-ntp-mac' will be a standard track update<= /div>
        to RFC 5905.


-------------------------------------
Dr. Dieter Sibold<= br>
Physikalisch-Technische Bundesanstalt
Q.42 - Server= systeme und Datenhaltung
QM-Verantwortlicher der Stelle IT
<= /font>
Bundesallee 100
D-38116 Braunschweig
<= div>Tel:&= nbsp;   +49-531-592-84 20
--=_alternative 00589ACEC1258143_=-- --===============6326753066864233326== 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 --===============6326753066864233326==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 23 17:07:48 2017 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 F06EC12EB3E for ; Fri, 23 Jun 2017 17:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcXx8r-h0BRK for ; Fri, 23 Jun 2017 17:07:41 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB2E12EBB4 for ; Fri, 23 Jun 2017 17:07:23 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 106A486DB8B for ; Sat, 24 Jun 2017 00:07:23 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 561EE86D83B for ; Sat, 24 Jun 2017 00:07:19 +0000 (UTC) Received: from mail.ietf.org ([4.31.198.44]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dOYbV-000L6N-PK for ntpwg@lists.ntp.org; Sat, 24 Jun 2017 00:07:19 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC27129B62; Fri, 23 Jun 2017 17:07:01 -0700 (PDT) MIME-Version: 1.0 From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282131.7840.1903482682680992032.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:01 -0700 X-SA-Exim-Connect-IP: 4.31.198.44 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: agenda@ietf.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] ntp - Requested session has been scheduled for IETF 99 X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org, suresh.krishnan@gmail.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" Dear Karen O'Donoghue, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ntp Session 1 (2:00:00) Tuesday, Morning Session I 0930-1200 Room Name: Karlin III size: 60 --------------------------------------------- Special Note: Joint session with TICTOC Request Information: --------------------------------------------------------- Working Group Name: Network Time Protocol Area Name: Internet Area Session Requester: Karen O'Donoghue Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: oauth sacm saag cfrg tls trans ippm bmwg detnet People who must be present: Karen O'Donoghue Suresh Krishnan Dieter Sibold Resources Requested: Special Requests: Please schedule jointly with the tictoc wg. --------------------------------------------------------- _______________________________________________ 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 Jun 26 05:19:46 2017 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 12DB2129B46 for ; Mon, 26 Jun 2017 05:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNcF-j6OM1Bx for ; Mon, 26 Jun 2017 05:19:41 -0700 (PDT) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 82FA6129B42 for ; Mon, 26 Jun 2017 05:19:41 -0700 (PDT) Received: from psp3.ntp.org (localhost.ntp.org [127.0.0.1]) by lists.ntp.org (Postfix) with ESMTP id 365F686DB87 for ; Mon, 26 Jun 2017 12:19:41 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 7776D86DAB6 for ; Mon, 26 Jun 2017 12:19:38 +0000 (UTC) Received: from mail.ietf.org ([4.31.198.44]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1dPSzK-00043m-IW for ntpwg@lists.ntp.org; Mon, 26 Jun 2017 12:19:38 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B3129B36; Mon, 26 Jun 2017 05:19:29 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149847956964.31768.13609436307062398969@ietfa.amsl.com> Date: Mon, 26 Jun 2017 05:19:29 -0700 X-SA-Exim-Connect-IP: 4.31.198.44 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) Subject: [ntpwg] I-D Action: draft-ietf-ntp-using-nts-for-ntp-09.txt X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ntpwg@lists.ntp.org 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" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Time Protocol of the IETF. Title : Network Time Security for the Network Time Protocol Authors : Daniel Fox Franke Dieter Sibold Kristof Teichel Filename : draft-ietf-ntp-using-nts-for-ntp-09.txt Pages : 29 Date : 2017-06-26 Abstract: This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the Network Time Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-09 https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-using-nts-for-ntp-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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