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

[Dan Harkins <[e-mail]>]

On 8/29/19 7:55 PM, Michael Richardson wrote:
> Dan Harkins <[e-mail]> 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.