Re: [TICTOC] WGLC on NTS: Why not run over IPsec?

Yoav Nir <ynir@checkpoint.com> Sun, 27 March 2016 08:39 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D870312D124 for <tictoc@ietfa.amsl.com>; Sun, 27 Mar 2016 01:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.93
X-Spam-Level:
X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JseIGpfIIlyH for <tictoc@ietfa.amsl.com>; Sun, 27 Mar 2016 01:39:19 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751FA12D125 for <tictoc@ietf.org>; Sun, 27 Mar 2016 01:39:13 -0700 (PDT)
x-m-msg: CPCHECK
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id u2R8d50j004116; Sun, 27 Mar 2016 11:39:05 +0300
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.137]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.03.0248.002; Sun, 27 Mar 2016 11:39:04 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Sharon Goldberg <goldbe@cs.bu.edu>, "kristof.teichel@ptb.de" <kristof.teichel@ptb.de>
Thread-Topic: [TICTOC] WGLC on NTS: Why not run over IPsec?
Thread-Index: AQHRhh0M9Yww06J5gkqi671c584tzJ9s+H2g
Date: Sun, 27 Mar 2016 08:39:03 +0000
Message-ID: <4613980CFC78314ABFD7F85CC3027721018447013B@DAG-EX10.ad.checkpoint.com>
References: <CAJHGrrR=xrxQaXqLz9vzHN=w-i0ji_WCa-=FYLaYgZATZ-nXkg@mail.gmail.com>
In-Reply-To: <CAJHGrrR=xrxQaXqLz9vzHN=w-i0ji_WCa-=FYLaYgZATZ-nXkg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [194.29.34.193]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 119d2a52e474c0c6998d5d324e931fd76eb03a7015
Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC3027721018447013BDAGEX10adchec_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/qCzX4OJEjyzT7KwFiIQ-WOP2z9o>
Cc: NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Subject: Re: [TICTOC] WGLC on NTS: Why not run over IPsec?
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Mar 2016 08:39:22 -0000

Hi. IPsec guy here.

I’m sorry I haven’t been following this discussion, so I’m not sure what the requirements of NTS are.  Whatever they are, I’m pretty sure that AH is not the answer, because AH is being deprecated in many stacks (we’ve done it in 2003).

There are modes of IPsec that do not require per association state, but that depends on what kind of traffic you have and on your trust model (that’s like “threat model” only looking on the bright side of life). For example, there is GDOI where a single key is used for all associations. That’s fine as long as you trust the group members to not impersonate each other.

As for the complexity of IPsec, this is largely a myth. IPsec is no more or less complex then the record layer of TLS/DTLS. The IKE protocol has many more knobs than SSLv3, but by the current version of TLS (TLS 1.2) they’ve caught up with the complexity, offering PFS and non-PFS, PSKs, passwords and what have you. It seems simpler because most of us get to see TLS encased in a browser, while an IKE daemon is usually installed separately and configured through a text file or arcane command-lines.  All consumer operating systems these days have IPsec clients (either L2TP or IKEv2) that are extremely easy to configure.

If you’re really interested in pursuing this, I suggest you summarize the requirements and send a message to the ipsec list. Lots of IPsec people there, including the author of [2].

Yoav

From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Sharon Goldberg
Sent: Friday, March 25, 2016 12:32 AM
To: kristof.teichel@ptb.de
Cc: NTP Working Group; tictoc@ietf.org
Subject: Re: [TICTOC] WGLC on NTS: Why not run over IPsec?

PPS: Out of curiosity: is there a mode for IPsec which does what NTS is trying to achieve (namely requiring on the server side neither a per-association state nor classic asymmetric cryptography like digital signatures)? If so, some text might be in order somewhere (NTP BCP document?), stating that if IPsec is used for securing NTP, said mode would be the best one to use.

This is a really good question and I tried and failed to answer it so far. IPsec is amazingly complex and easy to configure wrongly.  One thing that I can tell so far is that traffic should be secured in "AH Transport" mode but I cannot figure out what IPsec KE is appropriate.  It does seem that by default IPsec uses mutual authentication of client and server, (while NTS "MUST" accommodate one-sided authentication).  I wonder if IPsec also supports one-sided authentication; at the moment I have not figured out if/how this works.

Maybe if folks from this WG go to IETF (sadly I am not) someone could ask one of the IPsec folks for advice on what KE they suggest?

Anyway I've talked to several friends who are who do research on crypto flaws in practice, and they say the complexity of IPsec is both a barrier to its adoption and also a security risk [1].

Sigh.

Sharon

[1] http://www.spiegel.de/media/media-35529.pdf
[2] https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-ipsec-just-yet/



Email secured by Check Point.