Regards~~~ -Sujing Zhou
"Hao Zhou (hzhou)" <[email protected]> 写于 2012-07-10 00:33:21: > We are talking about the case of separation of outer EAP method and > inner method (intermediate AAA terminates the EAP tunnel and have a > separate AAA server for the inner method). Since EMSK from the inner > method never leaves the AAA server where it is generated, (nor it is > designed to be transported or a protocol exists to transport the > EMSK or key derived from it between AAA servers), EMSK based crypto- > binding will potentially break this use case. Well，in this case where tunnel server and EAP authentication server are separated, and it is required to combine TK and EMSK together, cann't it resolved by either specifying how to transport EMSK to another AAA or specifying how to transport TK to another AAA? > > From: "[email protected]" <[email protected]> > Date: Tuesday, July 3, 2012 12:04 AM > To: "Zhangdacheng (Dacheng)" <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" <emu- > [email protected]>, Sam Hartman <[email protected]>, Cisco Employee < > [email protected]> > Subject: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem > > > 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
