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

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Jun 2012 14:25:44 -0400

>>>>> "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.