On Tue, Feb 2, 2021 at 11:41 AM Bernard Aboba <bernard.ab...@gmail.com> wrote:
> 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. > > [Joe] Aha, It's coming back to me now and it does seem that implementations do this. Do you know if the implementation requirements were documented anywhere? > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
