Hi. I'm posting a new version of the channel bindings draft in response to AD review comments. I've been requested to develop security considerations text in response to attacks I wrote about on the list.
Here's the text I'm including in the new draft. Comments are welcome. I don't know if Sean will simply issue the IETF last call and allow us to comment on this text during the last call or if he'll seek comments on this text before the last call. Either way, you should send comments on this new security considerations text now if you have some. At the bottom of section 9.1 I've added: This trust model is a significant departure from the standard EAP model. In many EAP deployments today attacks where one NAS can impersonate another are out of scope. Channel bindings brings these attacks into scope; the system as a whole needs to be analyzed to evaluate cases where one NAS may impersonate another and to evaluate the impact of this impersonation. One attractive implementation strategy for channel binding is to add channel binding support to a tunnel method which can tunnel an inner EAP authentication. This way, channel binding can be achieved with any method that can act as an inner method even if that inner method does not have native channel binding support. The requirement for mutual authentication and key derivation is at the layer of EAP that actually performs the channel binding. Tunnel methods sometimes use cryptographic binding, a process where a peer proves that the peer for the outer method is the same as the peer for an inner method to tie authentication at one layer together with an inner layer. Cryptographic binding does not always provide mutual authentication; its definition does not require the server to prove that the inner server and outer server are the same. Even when cryptographic binding does attempt to confirm that the inner and outer server are the same, the Master Session Key (MSK) is typically used to protect the binding. However, the MSK is disclosed to the NAS, which can typically attack cryptographic binding if it terminates the tunnel at the NAS instead of the EAP server. This attack was not in scope for existing threat models for cryptographic binding because one NAS impersonating another is considered out of scope. Thus, existing cryptographic binding does not typically provide mutual authentication required for channel binding. I've added a new section 9.3: 9.3. Bid-Down Attacks EAP methods that add channel binding will typically negotiate its use. Even for entirely new EAP methods designed with channel binding from the first version, some deployments may not use it. It is desirable to protect against attacks on the negotiation of channel bindings. An attacker including the NAS SHOULD NOT be able to prevent a peer and server who support channel bindings from using it. Unfortunately existing EAP methods may make it difficult or impossible to protect against attacks on negotiation. For example, many EAP state machines will accept a success message at any point after key derivation to terminate authentication. EAP success methods are not integrity protected; an attacker who could insert a message can generate one. The NAS is always in a position to generate a success message. Common EAP servers take advantage of state machines accepting success messages even in cases where an EAP method might support a protected indication of success. It may be challenging to define channel binding support for existing EAP methods in a manner that permits peers to distinguish an old EAP server that sends a success indication and does not support channel binding from an attacker injecting a success indication. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
