[secdir] 答复: [Emu] Updated secdir review of draft-ietf-emu-chbind-15.txt

zhou.sujing@zte.com.cn Sat, 19 May 2012 01:48 UTC

Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333CE21F863E; Fri, 18 May 2012 18:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.79
X-Spam-Level:
X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, 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 oAy2CkJTgyuZ; Fri, 18 May 2012 18:48: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 B40F121F863C; Fri, 18 May 2012 18:48:44 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286203063883180; Sat, 19 May 2012 09:04:15 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 61163.4283112824; Sat, 19 May 2012 09:48:20 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q4J1mVee009060; Sat, 19 May 2012 09:48:31 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB82F8758EF@EMBX01-WF.jnpr.net>
To: Stephen Hanna <shanna@juniper.net>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF210EB9D3.3CA75468-ON48257A03.000960E1-48257A03.0009F8CC@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Sat, 19 May 2012 09:48:13 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-19 09:48:32, Serialize complete at 2012-05-19 09:48:32
Content-Type: multipart/alternative; boundary="=_alternative 0009F8CB48257A03_="
X-MAIL: mse02.zte.com.cn q4J1mVee009060
X-Mailman-Approved-At: Sat, 19 May 2012 08:07:54 -0700
Cc: emu-bounces@ietf.org, "secdir@ietf.org" <secdir@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>, "emu@ietf.org" <emu@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: [secdir] =?gb2312?b?tPC4tDogW0VtdV0gVXBkYXRlZCBzZWNkaXIgcmV2aWV3?= =?gb2312?b?IG9mIGRyYWZ0LWlldGYtZW11LWNoYmluZC0xNS50eHQ=?=
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 May 2012 01:48:46 -0000

emu-bounces@ietf.org 写于 2012-05-19 06:10:19:

> The last paragraph of section 9.1 points out a security problem
> with implementing channel bindings using EAP tunnel methods. If
> the EAP tunnel method terminates on the authenticator, the channel
> bindings can easily be defeated by the authenticator. While that's
> true, nobody terminates the EAP tunnel method on the authenticator
> today. In the EAP model, the authenticator is not trusted so
> terminating the EAP tunnel method on the authenticator is a bad
> idea for many reasons. For example, the authenticator would then
> have the ability to bypass protected result indications and to
> bypass all the cryptographic protections provided by the tunnel.
> Sometimes there is value in having the inner and outer methods
> terminate on different servers but both servers must be trusted.
> The authenticator is not. So there is no big security hole here,
> unless you have already opened an enormous security hole. It's
> ironic that this document which attempts to close vulnerabilities
> caused by malicious authenticators ends up subtly suggesting that
> people open a much larger vulnerability!
> 
> I would recommend deleting the end of this paragraph, starting
> with the sentence that starts "Even when cryptographic binding".
> If you choose to keep this strange text, I suggest that you at
> least note that terminating an EAP tunnel method on the
> authenticator is unusual. For example, you could add a
> parenthetical comment like "(rare)" after the clause "if the
> outer method tunnel terminates on the authenticator".

Cann't be more agree.
The logic and goal of the last paragraph is suspicious.
It gives an impression that channel binding on tunnel method is 
not applicable just because the specific (rare) example  shown is 
no good.
What about a good crypto binding in tunnel method?