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

Dan Harkins <> Fri, 30 August 2019 08:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9901C1202A0 for <>; Fri, 30 Aug 2019 01:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1PXegSnjLOkV for <>; Fri, 30 Aug 2019 01:13:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2FB5120113 for <>; Fri, 30 Aug 2019 01:13:38 -0700 (PDT)
Received: from ( []) by (PMDF V6.8-0 #1001) with ESMTP id <> for; Fri, 30 Aug 2019 03:13:38 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([]) by (PMDF V6.7-x01 #1001) with ESMTPSA id <> for; Fri, 30 Aug 2019 01:13:37 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by ([]) (PreciseMail V3.3); Fri, 30 Aug 2019 01:13:37 -0700
Date: Fri, 30 Aug 2019 01:13:33 -0700
From: Dan Harkins <>
In-reply-to: <9537.1567133709@localhost>
To: Michael Richardson <>
Message-id: <>
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 (, send-ip=
X-PMAS-External-Auth: [] (EHLO Dans-MacBook-Pro.local)
References: <> <> <9537.1567133709@localhost>
X-PMAS-Software: PreciseMail V3.3 [190828c] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>; 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 
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 
data is shared. Both sides prove they know the secret without exposing it.