Re: [Emu] Updated secdir review of draft-ietf-emu-chbind-15.txt
Sam Hartman <hartmans-ietf@mit.edu> Mon, 21 May 2012 21:51 UTC
Return-Path: <hartmans@mit.edu>
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 178B621F84D9; Mon, 21 May 2012 14:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 X5NvhxAskfQy; Mon, 21 May 2012 14:51:12 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7954721F8493; Mon, 21 May 2012 14:51:12 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (unknown [217.28.191.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2982420463; Mon, 21 May 2012 17:51:04 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E1BC44151; Mon, 21 May 2012 17:50:57 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Stephen Hanna <shanna@juniper.net>
References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> <tslvcjy37fi.fsf@mit.edu> <AC6674AB7BC78549BB231821ABF7A9AEB82F8758EF@EMBX01-WF.jnpr.net>
Date: Mon, 21 May 2012 17:50:57 -0400
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB82F8758EF@EMBX01-WF.jnpr.net> (Stephen Hanna's message of "Fri, 18 May 2012 18:10:19 -0400")
Message-ID: <tslr4udmce6.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "ietf@ietf.org" <ietf@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>, "emu@ietf.org" <emu@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [Emu] Updated secdir review of draft-ietf-emu-chbind-15.txt
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: Mon, 21 May 2012 21:51:13 -0000
>>>>> "Stephen" == Stephen Hanna <shanna@juniper.net> writes: Stephen> The changes in draft-ietf-emu-chbind-15.txt satisfactorily Stephen> address almost all of the comments in my April 13, 2012 Stephen> secdir review. I do have one remaining substantive comment Stephen> on this latest draft and two non-substantive ones. Stephen> Substantive Comment ------------------- Stephen> The last paragraph of section 9.1 points out a security Stephen> problem with implementing channel bindings using EAP tunnel Stephen> methods. If the EAP tunnel method terminates on the Stephen> authenticator, the channel bindings can easily be defeated Stephen> by the authenticator. While that's true, nobody terminates Stephen> the EAP tunnel method on the authenticator today. In the Stephen> EAP model, the authenticator is not trusted so terminating Stephen> the EAP tunnel method on the authenticator is a bad idea Stephen> for many reasons. For example, the authenticator would then Stephen> have the ability to bypass protected result indications and Stephen> to bypass all the cryptographic protections provided by the Stephen> tunnel. Sometimes there is value in having the inner and Stephen> outer methods terminate on different servers but both Stephen> servers must be trusted. The authenticator is not. So Stephen> there is no big security hole here, unless you have already Stephen> opened an enormous security hole. It's ironic that this Stephen> document which attempts to close vulnerabilities caused by Stephen> malicious authenticators ends up subtly suggesting that Stephen> people open a much larger vulnerability! Stephen> I would recommend deleting the end of this paragraph, Stephen> starting with the sentence that starts "Even when Stephen> cryptographic binding".> I disagree very strongly with this proposed change. It's possible that the text is not clear and I'd be happy to work for a round or two to see if we can clarify the text, but ending the paragraph as you propose would defeate the point of text we added after a WG consensus call. I agree with you that authenticators are not trusted. The issue is that you cannot trust attackers to act within a specification. If an attacker can gain benefit from doing something, they may do so. So, if an attacker can create a tunnel terminating at an authenticator and gain advantage from doing so, then they will do so. Remember that we're talking about crypto binding. If crypto binding is relevant for confirming there are no extra servers, then we're in a threat model space where we're trusting the inner method to authenticate the server, not the outer method. You can't say "you should only establish trusted tunnels," because we're hoping that crypto binding will give us that trust. So, the issue here is that once you add channel bindings and the associated changes to the threat model to EAP, an authenticator can gain advantage through convincing a client to trust a tunnel that terminates at an authenticator. That is, an authenticator can mount an attack. Yes, the authenticator needs to convince the peer to trust the extra tunnel. However, as I discuss in draft-hartman-emu-mutual-crypto-binding and in my presentation at last IETF, that's often fairly easy. So, how can we make the text more clear?
- [Emu] I-D Action: draft-ietf-emu-chbind-15.txt internet-drafts
- Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt Sam Hartman
- Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt Joe Salowey
- Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt zhou.sujing
- Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt Sam Hartman
- Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt zhou.sujing
- Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt Sam Hartman
- [Emu] 答复: Re: I-D Action: draft-ietf-emu-chbind-1… zhou.sujing
- [Emu] 答复: Re: I-D Action: draft-ietf-emu-chbind-1… zhou.sujing
- [Emu] 答复: Re: I-D Action: draft-ietf-emu-chbind-1… zhou.sujing
- Re: [Emu] ð´: Re: I-D Action: draft-ietf-emu-chbi… Sam Hartman
- [Emu] Updated secdir review of draft-ietf-emu-chb… Stephen Hanna
- [Emu] 答复: Updated secdir review of draft-ietf-emu… zhou.sujing
- Re: [Emu] Updated secdir review of draft-ietf-emu… Sam Hartman
- Re: [Emu] Updated secdir review of draft-ietf-emu… Stephen Hanna
- [Emu] Updated secdir review of draft-ietf-emu-chb… Stephen Hanna
- Re: [Emu] Updated secdir review of draft-ietf-emu… Sean Turner