Sam Hartman said:
"Unfortunately, it's never that simple. Channel binding data is a statement from the client to the EAP server about the client's understanding of the entity the client is authenticating to/the environment that the client is gaining access to. the EAP server's job is to verify that the channel binding is consistent and if not, reject the access request." [BA] The server's job is not only to verify that the channel binding is consistent, but also that it is correct. It is possible for the NAS to lie to both the peer and the server, in which case the channel binding info would be consistent with the AAA information, but both would be wrong. For example, in the SSID case, the NAS/AP could advertise an incorrect SSID, as well as including that incorrect SSID in the AAA conversation (e.g. spoofed Called-Station-Id). If the AAA server were more than one hop away from the NAS, and an AP that could legitimately assert that SSID were using the same proxy as the rogue AP/NAS, then unless the proxy performed a check and noted the inconsistency, there is no way for the AAA server to figure this out. The problem is that the first hop proxy is typically within the same administrative domain as the rogue AP/NAS. As a result, it can be difficult for channel bindings to provide protection in situations where both the NAS and the first hop proxy are controlled by the attacker. "This is not a practical attack. I'm not sure there are particularly practical attacks in this space. However, I think we have an obligation to specify constraints such that the system is secure. Here are examples of constraints that would be sufficient." [BA] Assuming that crypto-binding is used, then this attack can be thwarted. If not, then it might be possible, depending on the peer policy. First hop proxies can terminate virtually any existing EAP tunnel method. The only real protection against this is crypto-binding as well as constraints imposed by the peer on what server certificates will be accepted. For example, if the peer is connecting to SSID "example", then it might expect the server certificate to chain to the "example.com" trust anchor. If there are no such constraints, and crypto-binding isn't required by the client, then a first hop proxy controlled by an attacker could terminate the EAP tunnel, rewrite the channel bindings, and then re-tunnel the inner method. "I'm not sure whether an attacker can turn one of the TLS-related methods into another." If two TLS-related methods use the same key derivation label, then this is possible.
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
