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

kristof.teichel@ptb.de Wed, 30 March 2016 08:14 UTC

Return-Path: <kristof.teichel@ptb.de>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C6412DE79 for <tictoc@ietfa.amsl.com>; Wed, 30 Mar 2016 01:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.809
X-Spam-Level:
X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Qoj28ERQEqjQ for <tictoc@ietfa.amsl.com>; Wed, 30 Mar 2016 01:14:57 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1ED12DE03 for <tictoc@ietf.org>; Wed, 30 Mar 2016 01:14:22 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id u2U8EJ0E032522-u2U8EJ0G032522 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2016 10:14:19 +0200
Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTP id 6B597C33A2; Wed, 30 Mar 2016 10:14:19 +0200 (CEST)
X-Disclaimed: 1
MIME-Version: 1.0
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: <4613980CFC78314ABFD7F85CC3027721018447013B@DAG-EX10.ad.checkpoint.com>
References: <4613980CFC78314ABFD7F85CC3027721018447013B@DAG-EX10.ad.checkpoint.com>, <CAJHGrrR=xrxQaXqLz9vzHN=w-i0ji_WCa-=FYLaYgZATZ-nXkg@mail.gmail.com>
From: kristof.teichel@ptb.de
To: Yoav Nir <ynir@checkpoint.com>, ntpwg@lists.ntp.org, tictoc@ietf.org
Message-ID: <OFAFA01462.1493B5BE-ONC1257F86.002D4154-C1257F86.002D4157@ptb.de>
Date: Wed, 30 Mar 2016 10:14:18 +0200
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="ISO-8859-1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/sU-t5pPUIFrcgCAC0yFKlE_elAs>
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: Wed, 30 Mar 2016 08:14:59 -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].

My opinion is that we are not interested in pursuing this in our capacity as authors of the NTS documents.

However, it might still be overall advisable to pursue this.
Maybe someone would be interested in following up on this and write up a paragraph about how best to use/configure IPsec to secure NTP traffic (and possibly some pros and cons about doing this, too). This text might, for example, be added to the Security Considerations of the NTP BCP document.

What do people think about this?


>Yoav

>>PPS: 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.