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

Dan Harkins <dharkins@lounge.org> Fri, 30 August 2019 08:13 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 9901C1202A0 for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 01:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, URIBL_BLOCKED=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 1PXegSnjLOkV for <ipsec@ietfa.amsl.com>; Fri, 30 Aug 2019 01:13:39 -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 F2FB5120113 for <ipsec@ietf.org>; Fri, 30 Aug 2019 01:13:38 -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 <0PX100637IUQTX@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 30 Aug 2019 03:13:38 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX100N2OIUOJV@trixy.bergandi.net> for ipsec@ietf.org; Fri, 30 Aug 2019 01:13:37 -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 01:13:37 -0700
Date: Fri, 30 Aug 2019 01:13:33 -0700
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <9537.1567133709@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: ipsec@ietf.org
Message-id: <7f6a806a-ac96-dc20-ce6b-12499c04c271@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> <9537.1567133709@localhost>
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/MIzS0pCp8BiaZkDinZupeGAS9S4>
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 08:13:41 -0000

On 8/29/19 7:55 PM, Michael Richardson wrote:
> Dan Harkins <dharkins@lounge.org>; wrote:
>      >   I had some discussions with several people in Montreal on the subject of
>      > using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is
>      > quite cumbersome. I was told I should bring it up on the IPsec list so
>
> Understood, but could you say, despite that, why it's worth it for SPEKE?
> Afterall, we adopted EAP, which could also be said to be quite cumbersome
> rather than build all sorts of username/password and 3GPP/SIM integrations..

   The "PAKE framework" is complicated and unnecessary. Around the time 
that I
was proposing a PAKE for IKE, "EAP-only" IKE was also being proposed. As it
turns out the only reason to use EAP-only IKE was with a PAKE-- server-side
cert was taken care of by normal EAP-IKE and if both sides have a cert then
just do plain jane IKE. But the chairs at the time had a vested interest in
doing EAP-only and in making PAKE, the alternative to EAP-only, be as
cumbersome as possible. And so we got this mess that no one implements.

   SPEKE can just fall straight into the IKE_SA_INIT exchange (with a 
username
indicator as Tero pointed out) and it is authenticated with the IKE_AUTH
exchange. There is no additional framework messaging and there is no EAP
messaging and overhead. It's clean.

>      > In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE
>      > where either side can initiate. The PAKE I'm describing here is SPEKE,
>      > a balance PAKE.
>
> Got it.
>
>      >   This would require a new Auth Method defined for SPEKE/PAKE to indicate
>      > that the SPEKE shared secret is used. And that should be all that's needed.
>      > It should be that simple. The protocol shouldn't have to change, no new
>      > messages, no new payloads, no new nuthin. If I'm missing something please
>      > let me know.
>
> As I understand you, it's basically PSK authentication, but the PSK is
> no longer directly shared.  Would the QM "augmentation" of PSK have any value
> here?

   Yes, that's a way of thinking of it. The PSK is not shared and no 
PSK-derived
data is shared. Both sides prove they know the secret without exposing it.

   regards,

   Dan.