Joe Salowey said: "[Joe] Based on RFC 5216 the server could fail the finished message or as
section 2.1.3 shows it could send the finish and then it can send an Alert and result in EAP-Failure. In this case it would be possible for an attacker to remove the Alert and send a success. Whether your implementation ends up in this scenario or not probably depends upon why the auth failed and the behavior of your TLS library. I do not believe that RFC 5216 provides protected result indications. It would be a fine thing to add, but it is new to the specification and I'm not sure that is why the commitment message was added to begin with." [BA] EAP-TLS implementations do provide protected result indications. Due to injection attacks, implementations were modified to support RFC 4137 so as to protect against spoofed EAP-Success and EAP-Failure messages. For example, implementations of the EAP-TLS state machine should not be driven by EAP-Success and EAP-Failure messages, which are unprotected. This ensures that an Alert sent after Finish will be correctly recognized as an alternate failure indication, regardless of whether an attacker injected an EAP-Success message in between.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
