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

Paul Wouters <paul@nohats.ca> Fri, 30 August 2019 16:16 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 1E4A41208C8 for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 09:16:54 -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 gCiEu414OoRZ for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 09:16:53 -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 040AE12001E for <ipsec@ietf.org>; Fri, 30 Aug 2019 09:16:53 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46Kl3j4MMqzFd8; Fri, 30 Aug 2019 18:16:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1567181809; bh=jmp7P+Yzy/mOT8yYzGWbwR6MCJ7wHZFyxK3lrwc3FMw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TuWCNFJOUbjb3vq5SgC9HoRc6WSWR6+SYEhQgMtwSH+DcgcWVUsvV3oL8Rnco0p+6 w2NU/f76FG4zPVeH3UMTBq6+kAddVlb6zurVcZgY+JMDpqFkXo4oMpwyZg21W+Y4xx vII+P6EWv65nb/Ms1ei4RePsp15JQQA6TfSRBDcY=
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 ccAcgGK2fBSc; Fri, 30 Aug 2019 18:16:48 +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 18:16:47 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 42C9B322DE3; Fri, 30 Aug 2019 12:16:46 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 42C9B322DE3
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3684E401AFAF; Fri, 30 Aug 2019 12:16:46 -0400 (EDT)
Date: Fri, 30 Aug 2019 12:16:46 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Dan Harkins <dharkins@lounge.org>
cc: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org
In-Reply-To: <dcb51327-3a66-ba8c-431e-ee640ed7cdca@lounge.org>
Message-ID: <alpine.LRH.2.21.1908301154530.23965@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>
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/t0DRKnRUBIgjiUvR7jY8nGdZ3bw>
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:16:54 -0000

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.

Administrators doing site-to-site VPNs are better of using a true random
strong PSK instead of a weaker PAKE.

Paul