Regards~~~ -Sujing Zhou
"Zhangdacheng (Dacheng)" <[email protected]> 写于 2012-07-03 11:41:49: > I think you try to ask why ESMK can be used to detect the attackers > who try to impersonate other honest servers. > > Unlike MSK, EMSK will never be transported over the network and then > cannot be accessed by attackers. Therefore, it is possible for a > peer to use EMSK to detect an attacker who tries to perform the > attacks illustrated in the draft. That is what I understand, but EMSK-based crypto binding can still be transported through intermediate AAA servers between home AAA server and peer, right? Ｉdon't understand Hao Zhou's concern here. > > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, July 03, 2012 11:27 AM > To: Sam Hartman > Cc: [email protected]; emu@ietf. > org; [email protected]; Sam Hartman; Hao Zhou > Subject: 答复: Re: [Emu] New draft on mutual crypto binding problem > > > How does EMSK break intermediate AAA servers？ > > Regards~~~ > > -Sujing Zhou > > [email protected] 写于 2012-06-29 02:25:44: > > > >>>>> "Hao" == Hao Zhou <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/emu > >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
