Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-00
> "Jim" == Jim Schaad writes: Before the outer MSK has been computed, yes. Before the inner MSK (the one you need to attack crypto binding) has been computed no. Also, note that the RADIUS server only knows about the inner method, so it will transport the inner MSK as soon as it believes the inner method succeeds. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-00
> -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Sam Hartman > Sent: Thursday, June 28, 2012 11:06 AM > To: zhou.suj...@zte.com.cn > Cc: hartmans-i...@mit.edu; emu@ietf.org > Subject: Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-00 > > > "zhou" == zhou sujing writes: > > zhou> To my understanding, right prior to finishing tunnel establishement, > EAP peer > zhou> and EAP Server(print server in the server insertion attack case) > should have > zhou> exchanged channel binding with integrity protection by key only > known to EAP > zhou> peer and EAP server (MSK in this case), > > well, I actually think this happens after tunnel establishment and after the > inner method. > So, after the print server learns the MSK. > As I read draft-ietf-emu-chbind nothing forbids this. Certainly the existing > implementations of channel binding I'm aware of work that way. I think that as I understand it, it would occur before the MSK has been computed. An "intermediate" value has been computed but a new channel binding method could be defined that adds to the MSK and other EAP methods could be run after the channel binding has been done. Jim > ___ > 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
Re: [Emu] New draft on mutual crypto binding problem
> "Hao" == Hao Zhou 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
Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-00
> "zhou" == zhou sujing writes: zhou> To my understanding, right prior to finishing tunnel establishement, EAP peer zhou> and EAP Server(print server in the server insertion attack case) should have zhou> exchanged channel binding with integrity protection by key only known to EAP zhou> peer and EAP server (MSK in this case), well, I actually think this happens after tunnel establishment and after the inner method. So, after the print server learns the MSK. As I read draft-ietf-emu-chbind nothing forbids this. Certainly the existing implementations of channel binding I'm aware of work that way. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
