[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [Cfrg] [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process
From:       Michael Richardson <mcr+ietf () sandelman ! ca>
Date:       2019-08-30 2:55:09
Message-ID: 9537.1567133709 () localhost
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

["signature.asc" (application/pgp-signature)]

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


[prev in list] [next in list] [prev in thread] [next in thread]