Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

Paul Wouters <paul@nohats.ca> Fri, 30 August 2019 17:51 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8BD120944 for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 10:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 2xpaFE34zn9q for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 10:51:14 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6271200F6 for <ipsec@ietf.org>; Fri, 30 Aug 2019 10:51:14 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46Kn8c5ZXNzFfy; Fri, 30 Aug 2019 19:51:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1567187472; bh=CcNByTbftGALBGhuaIsRFdJ+bEfh9A1JteWJLARvvjw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eT20EeuZGmeHf+7rRfp9myvHCAdRWAonc2rkO4VytrMaJfPRCBdA61KRRXGgJuMOr 465pckOAhPypTeB1YDK0RypwVeZ69+Tkz6361+ICrvVuOPz/Xtk0A58amCu10tbc6k hL88ynnPXh5pFbJ+HeWhUSTmDCXTNP/9dzeVGPkQ=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id K-sT7urLKEnZ; Fri, 30 Aug 2019 19:51:11 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 30 Aug 2019 19:51:11 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 14C1D322DE3; Fri, 30 Aug 2019 13:51:10 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 14C1D322DE3
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0D46B401AFAF; Fri, 30 Aug 2019 13:51:10 -0400 (EDT)
Date: Fri, 30 Aug 2019 13:51:10 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Dan Harkins <dharkins@lounge.org>
cc: ipsec@ietf.org, Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <d1462c55-57a0-403d-ac3c-e24d481d9398@lounge.org>
Message-ID: <alpine.LRH.2.21.1908301346160.14173@bofh.nohats.ca>
References: <CAMr0u6mVev6HmaV259FP8=bcSj89o9xhzAu_81A5VOfR1NiPRA@mail.gmail.com> <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> <dcb51327-3a66-ba8c-431e-ee640ed7cdca@lounge.org> <alpine.LRH.2.21.1908301154530.23965@bofh.nohats.ca> <d1462c55-57a0-403d-ac3c-e24d481d9398@lounge.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/rzbqnO4scBn4ADmpiqIr25h8UbU>
Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2019 17:51:17 -0000

On Fri, 30 Aug 2019, Dan Harkins wrote:

>   Doing EAPTLS seems pointless. If your "additional client configuration"
> involved a new trust anchor and an EST exchange and an X.509 certificate
> then why not just use IKE?

Because "just use IKE" with Machine Certificates on Windows requires
Administrator priviledge, while using the exact same certificates for
EAPTLS only requires the user priviledges.

Is that worth 8 roundtrips? Our opinion does not matter, but Microsoft
thinks it does :(

>   EAP is an abomination.

I'll drink to that!


>>  Administrators doing site-to-site VPNs are better of using a true random
>>  strong PSK instead of a weaker PAKE.
>
>   Well how many administrators generate a nice string of 256-bits of "true
> random strong PSK"? Seriously, if administrators followed such advice then
> we would not continually adding another "die" on the "die die die IKEv1"
> routine we seem to do every 9 months. How many "dies" are we up to now?

I did not add killing PSKs to that draft, precisely because some
objected because strong PSK's are stronger than PAKEs.

>   Management of such "true random strong PSKs" is a pain which is why
> administrators use PSKs that are shorter, easier to remember, and easier to
> enter with a high probability of being correct. So a PAKE is just a robust
> solution for administrators that will do what we know they're gonna do 
> anyway.

Fair enough. Although people configuring Cisco's will use PSK for the
next 20 years even if we got an RFC tomorrow. I still regularly see
modp1024 flying by - in fact more so now because libreswan stopped
supporting it so people upgrading are finally finding out they have
a 15+ year old weak configuration.

>   For a site-to-site VPN something like "identity protection" might not be
> that big of a deal so there need not be any client provisioning. A simple
> phone call between the 2 parties could suffice. If identity protection is
> needed, then there's a provisioning step or we do an additional roundtrip.

True as well,

Paul