On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen <kivi...@iki.fi> wrote: > As we all know we (as a wg) did fail to pick one secure password > authentication method, and the latest count seems to be that we are > going to have 4 of them. > > All of them seem to be mostly same from the IKEv2 protocol point of > view, but each of them are implemented differently. All of the > proposals do have very common structure, i.e. they add some new > payloads and round trips to the IKE_AUTH step and in the end when the > secure password exchange finishes they will send (differently created) > auth payloads and finish the negotiation. > > When looking at the protocols it seems to me that we could create one > generic framework for all of the methods, i.e. we could make it so > that all of the methods can co-exists in the same implementation and > they can be configured to be used just like any other feature. I do > not see any point of allocating separate payload numbers, exchange > types, error codes etc for each of them, as that will add much more > complexity to the implementations.
We already have three generic authentication frameworks: SASL, GSS-API, and EAP. Must we add a fourth one? (We also have a number of less generic ones, such as the ones in SSHv2, TLS, ...). Considering that: a) we have EAP in IKEv2, b) there are reserved numbers for using the GSS-API in IKEv1, and we could make it usable in IKEv2, c) we have a plethora of EAP methods and GSS-API mechanisms available now or soon, ... why create a new framework? Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
