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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 30 August 2019 02:55 UTC

Return-Path: <mcr+ietf@sandelman.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 39563120888 for <ipsec@ietfa.amsl.com>; Thu, 29 Aug 2019 19:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KUHdDyatnuO4 for <ipsec@ietfa.amsl.com>; Thu, 29 Aug 2019 19:55:11 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2061C12021D for <ipsec@ietf.org>; Thu, 29 Aug 2019 19:55:10 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F18403808A; Thu, 29 Aug 2019 22:53:57 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5D8BFD8C; Thu, 29 Aug 2019 22:55:09 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dan Harkins <dharkins@lounge.org>
cc: ipsec@ietf.org, "cfrg\@irtf.org" <cfrg@irtf.org>
In-Reply-To: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org>
References: <CAMr0u6mVev6HmaV259FP8=bcSj89o9xhzAu_81A5VOfR1NiPRA@mail.gmail.com> <7538495e-258d-1927-cbba-eb783675c83f@lounge.org>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Thu, 29 Aug 2019 22:55:09 -0400
Message-ID: <9537.1567133709@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/NAdMWszd84WTODhUpVpgi6sum4o>
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 02:55:13 -0000

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

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

--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-