How does EMSK break intermediate AAA servers？ Regards~~~
-Sujing Zhou emu-boun...@ietf.org 写于 2012-06-29 02:25:44: > >>>>> "Hao" == Hao Zhou <hz...@cisco.com> writes: > > Hao> Sam: > Hao> This is a well thought and well written draft, it covers a > lot of background > Hao> and aspect of the attacks and mitigations. However, I have > few comments: > Thanks! > > You listed a set of drawbacks to EMSK-based crypto binding. > > Hao> A. Mutual crypto-binding required the use of EMSK, not all > existing EAP > Hao> method generate and export EMSK. It will also break intermediate AAA > Hao> servers. More importantly, it would only work for an EAP method that > Hao> generates keys. Part of the goal of Tunnel Method is to protect weak > Hao> authentication or EAP method, this would not benefits them. > > These drawbacks to EMSK-based cryptographic binding are documented; > thanks. > > Hao> D. Enforcing server policy would be another good way to go, > if server can > Hao> demand tunnel method only, eliminate the chance of inner > method MSK being > Hao> sent to the attacker. > > As discussed in the draft, you actually need a number of conditions > beyond just that. > However I agree server policy is another important mitigation, which is > why the draft recommends it. > > Hao> 2. I am not sure "Mutual Crypto-binding" is a good term, as > the existing > Hao> crypto-binding is already mutually authenticating the peer > and the server. > Hao> Maybe more accurate to be called "Crypto-binding based on > EMSK" or "Extended > Hao> Crypto-binding" etc. > > I think of mutual cryptographic binding as crypto binding that provides > defense against these sort of attacks (and personally don't consider > existing cryptographic binding to really qualify as "mutual".) > I think though that describing this new mechanism as EMSK-based > cryptographic binding is good. We may have other mechanisms that meet > the security goals of mutual cryptographic binding and it is always > desirable to separate mechanism from abstraction. > I've tried to start that transition in the next version of the > draft. Thanks very much for pointing this out. > Doubtless we'll have another round of improving terminology. > > Again, thanks so much for your comments. > _______________________________________________ > 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
