Hi Michael, On Thu, December 3, 2009 7:18 pm, Michael Richardson wrote: > Dan Harkins wrote: >> 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; and, > > Does it double, or does it really just "n+1", which is doubling if the > rest of the protocol has "n=1"? I also wonder if this is really a > sufficiently compelling reason to have two sets of code.
For the proposed EAP methods, EAP-EKE and EAP-PWD, it really is double. I don't think it's possible to do the kind of exchange that's required-- mutual authentication, key generation-- in n=1 messages. If you look at the SPSK draft, it is doing essentially the same exchange as EAP-PWD and doing it in 6 messages total. If you do EAP-only plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't matter) it's 12 messages total. >> 3. is insecure (unless something used nowhere today is employed: >> EAP >> channel bindings). > > We can, and must solve this. We can and we must. That's the easy part :-) The hard part is coming up with a way to do it. One of the big problems with EAP is that it is a completely underspecified shim. That's why every EAP method needs to roll-its-own identity exchange (the identity obtained by EAP is not suitable for authentication purposes) and roll-its-own fragmentation/reassembly code. So the obvious, and in my opinion wrong, solution for channel bindings is to just have each EAP method roll-its-own security capabilities negotiation plus definition of TLV message exchange and a cryptographic protection of that TLV message exchange as a way to solve channel bindings. Another option is to have it done generally as some sort of extension to EAP that every EAP method can "inherit". But mention that and people who wear hats start saying what can and cannot be done and what's in a charter and blah blah blah. Keep in mind, though, that however channel bindings gets solved, it is only going to further increase the number of messages necessary to get what you can get in SPSK in 6, and only 6, messages :-) Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
