emu-boun...@ietf.org 写于 2012-05-19 06:10:19: > The last paragraph of section 9.1 points out a security problem > with implementing channel bindings using EAP tunnel methods. If > the EAP tunnel method terminates on the authenticator, the channel > bindings can easily be defeated by the authenticator. While that's > true, nobody terminates the EAP tunnel method on the authenticator > today. In the EAP model, the authenticator is not trusted so > terminating the EAP tunnel method on the authenticator is a bad > idea for many reasons. For example, the authenticator would then > have the ability to bypass protected result indications and to > bypass all the cryptographic protections provided by the tunnel. > Sometimes there is value in having the inner and outer methods > terminate on different servers but both servers must be trusted. > The authenticator is not. So there is no big security hole here, > unless you have already opened an enormous security hole. It's > ironic that this document which attempts to close vulnerabilities > caused by malicious authenticators ends up subtly suggesting that > people open a much larger vulnerability! > > I would recommend deleting the end of this paragraph, starting > with the sentence that starts "Even when cryptographic binding". > If you choose to keep this strange text, I suggest that you at > least note that terminating an EAP tunnel method on the > authenticator is unusual. For example, you could add a > parenthetical comment like "(rare)" after the clause "if the > outer method tunnel terminates on the authenticator".
Cann't be more agree. The logic and goal of the last paragraph is suspicious. It gives an impression that channel binding on tunnel method is not applicable just because the specific (rare) example shown is no good. What about a good crypto binding in tunnel method?
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
