Hi,
I'd like to skip through the architectural bits in a hurry, and then
come back to Tero's proposal. All while rapidly flipping hats :-)
In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC
5998) could get us all we need for password authentication, and
eliminate the use of insecure "shortened shared secrets" (abused PSK) in
IKEv2. An implementer could use Dan's EAP-pwd or my EAP-EKE (now both
published as RFCs) and be done. The WG consensus was that we need
specific IKE auth methods, because implementing EAP is a pain in some
situations. I have accepted this consensus and I see no reason to reopen
this discussion.
[WG co-chair hat off:]
Unfortunately we had just enough energy to decide that we want a "native
IKEv2" way to do authentication with short secrets; we did not have
enough energy to pick a winner method. And I don't think we as a WG, or
the authors of the individual proposals, have the energy to go through a
"framework" exercise at this point in time. The documents are now in
IETF LC after having been held up for more than half a year.
Now to Tero's proposal: I'm afraid it is too much of an abstraction for
what we really need to achieve. I am as unhappy as anybody that we could
not settle on a single method, but this is water under the bridge. Given
this situation, we want to minimize the pain for implementors who
implement 1-2 of these methods (I have abandoned HUSH in favor of PACE a
while ago, and I somehow don't see anybody implementing all three).
So I don't think we need a whole framework. We just need a way for the
two peers to negotiate which method(s) they support early enough, i.e.
in IKE_SA_INIT. In PACE we use a notification, and I strongly urge the
two other documents' authors to do the same. But I'm willing to be
convinced to switch to another method if that's the group's preference.
Other than that, I really don't see the value in uniform "meta-payloads"
and "super-notifications", or how they would simplify implementations.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
