Matthew Cini Sarreo writes: > From a developer point of view, I share the same opinion as Yaron about this > issue. Instead of creating new solutions, I personally think that it would > be better to offer guidlines on how to implement current solutions (i.e EAP) > and provide documents targeting implementers. This would create less > confusion and keep IKEv2 a clean, easy to understand and use protocol.
I think it would be much more complicated to try to turn EAP from client / server protocol to symmetric protocol, than to add new exchange to IKEv2. Note, that I do not comment anything about how the current SPKS draft is done, as I have not really read it, but I think we should add secure password protocol to the IKEv2 and not use EAP for that when using symmetric site to site, or host to host scenarios. If we had that clean secure password protocol, then we could leave out EAP in some environments, which would make protocol implementation much easier. Looking at the state machine of IKE_AUTH in our own implementation, EAP causes most of the complexity (mostly because EAP is open ended). On the other hand if we add multiple authentication support to the state machine pictures, then that is even more complex than EAP... Good thing with SPSK is that it is alternative for all other authentication modes, i.e. adds one to the shared key-shared key, shared key-public key, public key-shared key, and EAP-public key list. I.e. it does not multiply the test cases but just adds one to the list of current authentication modes, raising it from 4 to 5. EAP only authentication mode raises it by one more. Multiple authentication support raises it to power of n (depending how many different authentication rounds you support)... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
