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

From: [email-masked]
Date: Tue, 3 Jul 2012 12:04:18 +0800

Regards~~~

-Sujing Zhou

"Zhangdacheng (Dacheng)" <[email-masked]> 写于 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: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2012 11:27 AM
> To: Sam Hartman
> Cc: [email-masked]; emu@ietf.
> org; [email-masked]; Sam Hartman; Hao Zhou
> Subject: 答复: Re: [Emu] New draft on mutual crypto binding problem
> 
> 
> 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
> >

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Mon, 9 Jul 2012 16:33:21 +0000

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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 3, 2012 12:04 AM
To: "Zhangdacheng (Dacheng)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Sam Hartman <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>
Subject: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem

Regards~~~

-Sujing Zhou

> 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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> Cc: [email-masked]<mailto:[email-masked]>; emu@ietf.
> org; [email-masked]<mailto:[email-masked]>; Sam Hartman; Hao Zhou
> [email-masked]<mailto:[email-masked]> 写于 2012-06-29 02:25:44:
>
> > >>>>> "Hao" == Hao Zhou <[email-masked]<mailto:[email-masked]>> writes:
> >
> >     Hao> Sam:
> > However I agree server policy is another important mitigation, which is
> > I think of mutual cryptographic binding as crypto binding that provides
> > [email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Tue, 10 Jul 2012 10:57:34 +0800

Regards~~~

-Sujing Zhou

"Hao Zhou (hzhou)" <[email-masked]> 写于 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: "[email-masked]" <[email-masked]>
> To: "Zhangdacheng (Dacheng)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <emu-
> [email-masked]>, Sam Hartman <[email-masked]>, Cisco Employee <
> [email-masked]>
11:41:49:
> That is what I understand, but EMSK-based crypto binding can still 
> be transported through intermediate AAA servers 
is
provides

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Tue, 10 Jul 2012 18:05:26 +0000

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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 9, 2012 10:57 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Sam Hartman <[email-masked]<mailto:[email-masked]>>, "Zhangdacheng (Dacheng)" <[email-masked]<mailto:[email-masked]>>
Subject: 答复: Re: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem

Regards~~~

-Sujing Zhou

> 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?

> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <emu-
> [email-masked]<mailto:[email-masked]>>, Sam Hartman <[email-masked]<mailto:[email-masked]>>, Cisco Employee <
> [email-masked]<mailto:[email-masked]>>