Hi. EAP has a complex history of success indications over the years. Some methods have protected success indications; some don't.
Especially as channel bindings are being initially deployed it's going to be common to want to send channel bindings and possibly fail if they do not match but not to require the server to support them. So, bidding down attacks are a real concern. First, if you are using an EAP method where success indications are not protected then you have a kind of hopeless situation. I'm not entirely sure how things are defined, but that might be incompatible with providing mutual authentication as a security claim. Channel bindings already does require mutual authentication out of the method. But there's another issue. Howe carefully does the client look at this. >From a state machine standpoint is' really important that your client not just accept an eap success packet as success if the method does have an internal success indication. If a client does accept an eap success packet then a malicious NAS could inject such a packet. The value of the attack may be limited by a couple of factors: 1) The client may be expecting keying material. It's probably possible with some methods to get the client its keying material 2) If the NAS interrupts the conversation with the server, then it probably doesn't get its copy of the keying material. However form things that don't really use the keying material, this may be an issue. I think it's worth writing up a security consideration that clients implementing channel binding should be careful about their state machine in this regard. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
