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

Dan Harkins <> Thu, 29 August 2019 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 832E2120059 for <>; Thu, 29 Aug 2019 15:48:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yUPo1LdGUCib for <>; Thu, 29 Aug 2019 15:48:11 -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 47A1D120089 for <>; Thu, 29 Aug 2019 15:48:11 -0700 (PDT)
Received: from ( []) by (PMDF V6.8-0 #1001) with ESMTP id <> for; Thu, 29 Aug 2019 17:48:10 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([]) by (PMDF V6.7-x01 #1001) with ESMTPSA id <> for; Thu, 29 Aug 2019 15:46:12 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by ([]) (PreciseMail V3.3); Thu, 29 Aug 2019 15:46:12 -0700
Date: Thu, 29 Aug 2019 15:48:08 -0700
From: Dan Harkins <>
In-reply-to: <>
Cc: "" <>
Message-id: <>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Uu8RA29dFL+5pz0Oniw0GQ)"
Content-language: en-US
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: <>
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: Thu, 29 Aug 2019 22:48:15 -0000


   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
here goes (copying CFRG since that's where the PAKE work is being done).

   First of all this suggestion is for a particular PAKE and I'm not
suggesting that any of the other candidates would slide in so effortlessly.
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.

   SPEKE does a simple Diffie-Hellman but uses a secret generator that is
deterministically obtained from the password. This technique is basically
one of the hash-to-curve functions from the CFRG's hash-to-curve I-D
or a simple hashing and exponentiation for MODP groups. All this happens
at password provisioning time prior to IKE being run.

   Then when IKE is run the secret generator for the negotiated group is
used to do the D-H, the IKE_SA_INIT exchange is basically SPEKE. The
result is, if they both have the same generator (which means they had the
same password), an authenticated shared secret. This secret is verified in
the IKE_AUTH exchange.

   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.



On 8/8/19 12:30 AM, Stanislav V. Smyshlyaev wrote:
> Dear ipsecme,
> I am writing this message on behalf of the CFRG chairs.
> Currently there is an ongoing PAKE selection process in the CFRG.
> According to the plan of the PAKE selection process, the CFRG chairs 
> have selected a number of PAKE-related topics that require independent 
> reviews from experts deeply involved in several particular areas of 
> IETF work: TLS and IPsec protocols, constrained environments and privacy.
> The chairs would like to announce the call for reviewers, who will be 
> asked to prepare their reviews regarding one or more of the following 
> topics about the nominated PAKEs:
> - Convenience for usage within/together with TLS 1.3 Handshake.
> *- Convenience for usage within/together with IKEv2.*
> - Convenience for usage in M2M/IoT protocols (i.e., with corresponding 
> constrains on hardware).
> - Privacy considerations (e.g., recommendations to prevent user 
> enumeration).
> The experts who would like to volunteer to do such a review are kindly 
> asked to choose:
> 1) which topics from the provided list will be considered by them;
> 2) whether they could prepare their reviews for
> - all four balanced PAKEs,
> - all four augmented PAKEs or
> - all eight candidate PAKEs.
> We ask each of the expert to prepare reviews for all PAKEs (or at 
> least all balanced/all augmented ones) to be sure that each of the 
> PAKEs will be studied from the same points of view.
> *The call for reviewers will last until the 15th of August. Please 
> send a message to <> or 
> <>, if you could help. *
> Deadline for the reviews is 15th of September.
> The reviews will later be provided to Crypto Review Panel experts, who 
> will prepare their overall reviews during Stage 5.
> Best regards,
> Stanislav Smyshlyaev,
> CFRG Secretary
> _______________________________________________
> IPsec mailing list