[Emu] 答复: Re: on draft-hartman-emu-mutual-crypto-bind-00

zhou.sujing@zte.com.cn Tue, 03 July 2012 01:43 UTC

Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00B311E80EC for <emu@ietfa.amsl.com>; Mon, 2 Jul 2012 18:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.19
X-Spam-Level:
X-Spam-Status: No, score=-92.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tJoldWz8z+G for <emu@ietfa.amsl.com>; Mon, 2 Jul 2012 18:43:45 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 619D421F85B5 for <emu@ietf.org>; Mon, 2 Jul 2012 18:43:44 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201794749335; Tue, 3 Jul 2012 09:38:08 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 66221.2827933790; Tue, 3 Jul 2012 09:43:46 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q631heqL076067; Tue, 3 Jul 2012 09:43:40 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <tslipebxqev.fsf@mit.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFB4490607.60385663-ON48257A30.0009421C-48257A30.00098993@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Tue, 03 Jul 2012 09:43:39 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-03 09:43:41, Serialize complete at 2012-07-03 09:43:41
Content-Type: multipart/alternative; boundary="=_alternative 0009899148257A30_="
X-MAIL: mse01.zte.com.cn q631heqL076067
Cc: hartmans-ietf@mit.edu, emu@ietf.org
Subject: [Emu] 答复: Re: on draft-hartman-emu-mutual-crypto-bind-00
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2012 01:43:46 -0000

Regards~~~

-Sujing Zhou

Sam Hartman <hartmans-ietf@mit.edu> 写于 2012-06-29 02:06:00:

> >>>>> "zhou" == zhou sujing <zhou.sujing@zte.com.cn> 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.
> 

Since tunnel method is also an EAP method, and used for protecting the 
inner EAP method,
why cann't put channel binding right after the tunnel method? So that 
adverse affects can 
be prevented more effectively.
 There is a paragraph in  draft-ietf-emu-chbind
" The channel binding protocol defined in this document must be
   transported after keying material has been derived between the EAP
   peer and server, and before the peer would suffer adverse affects
   from joining an adversarial network.  "