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

Dan Harkins <dharkins@lounge.org> Fri, 30 August 2019 16:48 UTC

Return-Path: <dharkins@lounge.org>
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 74C3812098D for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 09:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 jGtNIZawWVD6 for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 09:48:17 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 A44AE12093E for <ipsec@ietf.org>; Fri, 30 Aug 2019 09:48:17 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PX2007FZ6OGD8@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 30 Aug 2019 11:48:17 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX200NA56ODJV@trixy.bergandi.net> for ipsec@ietf.org; Fri, 30 Aug 2019 09:48:13 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 30 Aug 2019 09:48:13 -0700
Date: Fri, 30 Aug 2019 09:48:14 -0700
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <alpine.LRH.2.21.1908301154530.23965@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
Cc: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org
Message-id: <d1462c55-57a0-403d-ac3c-e24d481d9398@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local)
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>
X-PMAS-Software: PreciseMail V3.3 [190828c] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/I-zthMe_MqLg92mKtF9-dQpz9K0>
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 16:48:20 -0000

On 8/30/19 9:16 AM, Paul Wouters wrote:
> On Fri, 30 Aug 2019, Dan Harkins wrote:
>
>>   Sure we can. We could do the thing that was done in TLS-pwd. When the
>> client registers his username and password she gets a static DH public
>> key of the server (TLS-pwd made this be a p256 curve for its compact
>> representation and adequate strength for the purpose of identity
>> protection). The scheme then is if the client wants to protect its
>> identity it uses the server's DH public key and does a static-ephemeral
>> exchange, gets a secret, encrypts its identity and sends its ephemeral
>> DH key (in compact representation, it's 33 octets) plus the encrypted
>> identity in one "identity payload". If it doesn't care about identity
>> protection it just sends its identity.
>
> EAPTLS already uses like 8 round trips. So anything that has PAKE using
> less than 8 seems like a win already :P So I am fine adding a few
> roundtrips for whatever PAKE we come up with if that avoids all of this
> extra complexity. Especially if this complexity is something that is 
> added
> to the client provisioning.
>
> Remember this PAKE stuff is meant for those scenarios where we have an
> enduser with _only_ a username/password. If this requires installing
> additional client configuration, those clients might as well go to
> X.509/EAPTLS or even something weird like PSK/EAPTLS, or an EAP method
> supporting OTPs.

   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?

   EAP is an abomination. It includes an identity request/response roundtrip
that generates an identity that the EAP RFC says is unsuitable for any
authentication purpose. Imagine that, an "authentication" protocol that
wastes a roundtrip getting a useless identity and then punts off the job
of getting a usable identity to another authentication protocol that has
to wrap itself in an EAP encapsulation. Putting EAP into IKE was a bad idea
and it seems doubly bad to put a PAKE (or PSK or OTP) into EAP inside IKE.

> 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?

   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.
They're not weak.

   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.

   regards,

   Dan.