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.
From: "zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>" <zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>> Date: Tuesday, July 3, 2012 12:04 AM To: "Zhangdacheng (Dacheng)" <zhangdach...@huawei.com<mailto:zhangdach...@huawei.com>> Cc: "emu@ietf.org<mailto:emu@ietf.org>" <emu@ietf.org<mailto:emu@ietf.org>>, "emu-boun...@ietf.org<mailto:emu-boun...@ietf.org>" <emu-boun...@ietf.org<mailto:emu-boun...@ietf.org>>, Sam Hartman <hartmans-i...@mit.edu<mailto:hartmans-i...@mit.edu>>, Cisco Employee <hz...@cisco.com<mailto:hz...@cisco.com>> Subject: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem Regards~~~ -Sujing Zhou "Zhangdacheng (Dacheng)" <zhangdach...@huawei.com<mailto:zhangdach...@huawei.com>> 写于 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: zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn> > [mailto:zhou.suj...@zte.com.cn] > Sent: Tuesday, July 03, 2012 11:27 AM > To: Sam Hartman > Cc: > draft-hartman-emu-mutual-crypto-b...@tools.ietf.org<mailto:draft-hartman-emu-mutual-crypto-b...@tools.ietf.org>; > emu@ietf. > org; emu-boun...@ietf.org<mailto:emu-boun...@ietf.org>; Sam Hartman; Hao Zhou > Subject: 答复: Re: [Emu] New draft on mutual crypto binding problem > > > How does EMSK break intermediate AAA servers？ > > Regards~~~ > > -Sujing Zhou > > emu-boun...@ietf.org<mailto:emu-boun...@ietf.org> 写于 2012-06-29 02:25:44: > > > >>>>> "Hao" == Hao Zhou <hz...@cisco.com<mailto: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<mailto:Emu@ietf.org> > > https://www.ietf.org/mailman/listinfo/emu > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
