Well, the AAA server terminates the tunnel is doing the crypto-binding, os it will need the EMSK key from the inner method AAA. However, EMSK, according to RFC5247, "is never shared with a third party". So, it is possible to transport some transient keys derived from the EMSK between the AAA servers. The TEAP draft-02 uses the transient key derived from inner method EMSK if available. However, no stander defined protocol exists today to do the transport. That's the missing piece.
From: "zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>" <zhou.suj...@zte.com.cn<mailto:zhou.suj...@zte.com.cn>> Date: Monday, July 9, 2012 10:57 PM To: Cisco Employee <hz...@cisco.com<mailto:hz...@cisco.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>>, "Zhangdacheng (Dacheng)" <zhangdach...@huawei.com<mailto:zhangdach...@huawei.com>> Subject: 答复: Re: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem Regards~~~ -Sujing Zhou "Hao Zhou (hzhou)" <hz...@cisco.com<mailto:hz...@cisco.com>> 写于 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: "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: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
