Sam: This is a well thought and well written draft, it covers a lot of background and aspect of the attacks and mitigations. However, I have few comments:
1. I don't agree that Mutual crypto-binding is the recommended mitigation and should be added to TEAP. I actually think proper server authentication or server policy is better mitigation. Reasons: A. Mutual crypto-binding required the use of EMSK, not all existing EAP method generate and export EMSK. It will also break intermediate AAA servers. More importantly, it would only work for an EAP method that generates keys. Part of the goal of Tunnel Method is to protect weak authentication or EAP method, this would not benefits them. B. The root of the problem is a legitimate NAS acting as something it shouldn't be. If the peer can detect that from the beginning, that will prevent further damages such as leaking of credentials, sensitive data etc. Thus I strong recommend we emphasize on server cert validation and introduce the concept of authorization to the server authentication. Certain server can be only used for the services that are authorized. If the peer is seeking certain services and encounter a server that is not on the authorized server offering this type of service, despite it is a legit server for other services, it should refuse to connect to it. It's like you don't log onto Facebook to do your bank transactions:) I don't think Standard cert naming is enough, we need some sort of authorization built into the cert name or a peer side policy, what service the holder can offer. C. Adding Crypto-binding to TEAP would complicate things, we will need to try to negotiate that and fall back to the case where inner method doesn't generate EMSK. And it doesn't protect the methods that doesn't generate keys. D. Enforcing server policy would be another good way to go, if server can demand tunnel method only, eliminate the chance of inner method MSK being sent to the attacker. 2. I am not sure "Mutual Crypto-binding" is a good term, as the existing crypto-binding is already mutually authenticating the peer and the server. Maybe more accurate to be called "Crypto-binding based on EMSK" or "Extended Crypto-binding" etc. Some small nits: 1. In introduction, EAP RFC is 3748, not 3778. 2. In abstract, "[RFC3748]" probably should be "Cryptographic binding defined in [RFC3748]". On 3/5/12 6:32 PM, "Sam Hartman" <hartmans-i...@mit.edu> wrote: > > Folks, I'd like to draw your attention to a draft we've put together > describing the crypto binding interaction with channel binding and other > peer-focused EAP services that I posted back in January. Please see > draft-hartman-emu-mutual-crypto-bind-00.txt. > > there are a few rough edges. A couple of figures need to be added. we'd > also like to describe where existing tunnel methods are in terms of > vulnerability to these issues and where inner methods are in terms of > providing keys and EMSKS. > Dacheng zhang has compiled a lot of this data but I didn't get a chance > to integrate it today. > > I'd like to thank all those who have helped with this so far and > welcome any feedback. > > We'd like to request time at the EMU session to discuss this attack and > the implications for our ongoing work. > _______________________________________________ > 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
