On 8/29/19 7:55 PM, Michael Richardson wrote:
Dan Harkins <[email protected]> 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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
