Glen asked me to explain my tunnel related comments more.
It would be desirable to reduce the number of methods we need to add channel binding to. For example if eap-ttls supports channel binding [1] and I'm running some other method inside it, then I may not care whether that method supports channel binding. Similarly, if I wish I had channel binding in some method that does not have channel binding, I can always tunnel it. [1] I think it does, but I'm not sure it is in alignment with draft-ietf-emu-chbind at the moment. This seems like such a good idea we wrote it into the charter. 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. This model depends on the server being able to confirm that the channel binding statements are actually from the client. Clearly, if an attacker could change channel binding, then the system will not work. However, typically tunnel methods authenticate the server to the client but depend on the inner method to authenticate the client to the server. Let me give a concrete attack. Consider an EAP server that takes the channel binding data from the outer method if present otherwise the inner method. A client intends to use GPSK and includes channel binding data there. An attacker acts as a man-in-the-middle, receives the GPSK lower layer messages and replaces them with lower layer messages tunneling GPSK in TTLS. So, the TTLS tunnel runs from the attacker to the EAP server, while the inner GPSK runs from the client to the EAP server. If this is starting to look a lot like the standard set of EAP tunnel attacks, you're absolutely right. The attacker inserts channel binding data in the outer tunnel and thus replaces the channel binding. 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. * Cryptographic binding is used to prove that the outer tunnel party knows the inner tunnel key. Note that proving that the inner tunnel party knows the outer key would not generally be sufficient mostly because a lot of the inner methods you might want won't ever support this. * Never except the same equivalence class of EAP methods both inside an outside a tunnel. That is, in a given configuration require that if GPSK is to be used it either always appears in a given tunnel for a specific user or never does. I say equivalence class because it's possible that an attacker might be able to transform the messages of one method into another. For example I'm not sure whether an attacker can turn one of the TLS-related methods into another. * Assuming that adding channel binding information can never make a request that would fail succeed, take channel binding attributes from the inner method first. --Sam _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
