Hi Martin, On Tue, December 1, 2009 1:27 am, Martin Willi wrote: > Hi Dan, > >> And in that case EAP encapsulation of the underlying key exchange would >> be completely pointless and extraneous, would double the number of >> messages required to complete the exchange, and would increase the >> amount >> of security-critical code. > > EAP authentication was not primarily included in IKEv2 to implement some > kind of password authentication on top if IKEv2, but to reuse existing > EAP methods and infrastructure.
I understand. I'm not talking about EAP authentication in IKEv2 today. Please, don't misunderstand me. I'm not proposing to do away with EAP authentication in IKEv2, I'm proposing a more efficient, more secure, and simpler way of doing password-only authentication in IKEv2. > The most demanding user of IKEv2 currently is the mobile/telco industry; > There are several specs in 3GPP and 3GPP2 using it. Many of them have > chosen IKEv2 because they can use their existing EAP-AKA/SIM > infrastructure for authentication. > >> It seems to me that EAP-only authentication in IKEv2: >> 1. does not solve a general problem; > > It does. It allows to omit public key authentication in cases where > mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2 > spec that already uses EAP-AKA/TLS only authentication, but does not > follow this draft. I really see a need for this WG item. I guess I was just saying that certificate-less, password-based authentication is not general. It's specific to the problem of authenticating with only a password and no certificate. If 3GPP2 has a need for authentication with only a password and no certificate please take a look at EAP-pwd! That will, apparently, solve your problem. If it doesn't then the singular use of EAP-only IKEv2 authentication will not either. Furthermore, doing pointless encapsulations and doubling of messages does not really seem to solve _any_ problem. Keep in mind that IKE/IPsec is, fundamentally, a peer-to-peer protocol. While your client-server application is a very valid use case, it is not the only one and it is important to solve problems generally, with utility to all use cases, if possible. >> 2. solves the specific problem it is aimed at poorly-- doubling of >> the number of messages, requiring writing and testing of new >> state EAP state machines that are, otherwise, unnecessary > > If you're just talking about password authentication, yes. But this > allows IKEv2 to work in existing infrastructures (EAP over > RADIUS/DIAMETER). We currently see a strong demand for such solutions. IKEv2 already works in such infrastructure. Yes, I'm talking about password authentication. That's the only use for EAP-only authentication in IKEv2. Any other EAP authentication can already be handled in IKEv2 today. I'm glad you have a strong desire for using existing EAP authentication of IKEv2. But please understand that that is not what the topic under discussion is. >> To provide the benefits of EAP-only authentication [...] it would be >> much better to support the inclusion of "Secure PSK authentication" as >> a work item. > > Implementing password authentication on top of EAP may be one reason for > this draft, but there are several others. And the separated EAP layer > allows you to forward authentication to an existing AAA server. > Further, many vendors already have generic EAP support. Implementing PSK > authentication on top of it is probably simpler and more flexible than > integrating it in IKEv2 directly. Please tell me what other reasons there are for this draft. This draft solves one problem only-- using only a password to authenticate, with both sides requiring plaintext access to the password-- and that problem can be solved more simply and more securely than EAP-only, and in a way that is applicable to all use cases of IKE. Note that the EAP methods being used to justify EAP-only authentication in IKEv2 (the ones mentioned by the Yaron) DO NOT allow for forwarding of authentication to a AAA server. Other EAP methods might but, as I stated earlier, those are already handled today in IKEv2. The benefit you want to apply to this proposal is not valid and what you seem to be requiring is already provided for. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
