Subject: [Emu] 答复: Re: New draft on mutual crypto binding problem

From: [email-masked]
Date: Tue, 3 Jul 2012 11:26:54 +0800

How does EMSK break intermediate AAA servers？

Regards~~~

-Sujing Zhou

[email-masked] 写于 2012-06-29 02:25:44:

> >>>>> "Hao" == Hao Zhou <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/emu
>