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

"Jim Schaad" <ietf@augustcellars.com> Fri, 29 June 2012 00:01 UTC

Return-Path: <ietf@augustcellars.com>
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 EE15221F85E6 for <emu@ietfa.amsl.com>; Thu, 28 Jun 2012 17:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.053
X-Spam-Level:
X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
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 IYW0F2qdx1vX for <emu@ietfa.amsl.com>; Thu, 28 Jun 2012 17:01:53 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4751A21F85E4 for <emu@ietf.org>; Thu, 28 Jun 2012 17:01:53 -0700 (PDT)
Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6AC6C38F2B; Thu, 28 Jun 2012 17:01:52 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Sam Hartman' <hartmans-ietf@mit.edu>, zhou.sujing@zte.com.cn
References: <OF11671240.F3BA4407-ON482579E3.00360329-482579E3.003638C2@zte.com.cn> <tslipebxqev.fsf@mit.edu>
In-Reply-To: <tslipebxqev.fsf@mit.edu>
Date: Thu, 28 Jun 2012 17:00:32 -0700
Message-ID: <020301cd558a$346451d0$9d2cf570$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIZlCmw5EqQI7j/Ty5VOkAgOabaxQI6+vG2lmYT9XA=
Content-Language: en-us
Cc: emu@ietf.org
Subject: Re: [Emu] 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: Fri, 29 Jun 2012 00:01:54 -0000

> -----Original Message-----
> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of
> Sam Hartman
> Sent: Thursday, June 28, 2012 11:06 AM
> To: zhou.sujing@zte.com.cn
> Cc: hartmans-ietf@mit.edu; emu@ietf.org
> Subject: Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-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.

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