Re: [btns] rfc 5387

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 05 May 2009 22:11 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: btns@core3.amsl.com
Delivered-To: btns@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46293A6DD6 for <btns@core3.amsl.com>; Tue, 5 May 2009 15:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.886
X-Spam-Level:
X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGm4pnCoPhJP for <btns@core3.amsl.com>; Tue, 5 May 2009 15:11:42 -0700 (PDT)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id AB75128C23D for <btns@ietf.org>; Tue, 5 May 2009 15:11:18 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n45MChxh002566 for <btns@ietf.org>; Tue, 5 May 2009 22:12:43 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n45MChLO043369 for <btns@ietf.org>; Tue, 5 May 2009 16:12:43 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n45Lm5Hb025802; Tue, 5 May 2009 16:48:05 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n45Lm4rV025801; Tue, 5 May 2009 16:48:04 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 05 May 2009 16:48:04 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Joe Touch <touch@ISI.EDU>
Message-ID: <20090505214804.GX1500@Sun.COM>
References: <49A4CDFF.3050907@ese.wustl.edu> <4c1c9a1604e5bb3ac960f4dfff3c88e0.squirrel@webmail.cec.wustl.edu> <49C3A0C3.8000303@ese.wustl.edu> <7610b87c95062b678eaf5b91da2e2670.squirrel@webmail.cec.wustl.edu> <49D9EFAC.7010602@ese.wustl.edu> <9568b97276e9e104429445829e257532.squirrel@webmail.cec.wustl.edu> <49ECADDD.9060204@ese.wustl.edu> <023070630846bf76af405743608d413b.squirrel@webmail.cec.wustl.edu> <20090505201529.GP1500@Sun.COM> <4A00B2F4.30009@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4A00B2F4.30009@isi.edu>
User-Agent: Mutt/1.5.7i
Cc: Alan Johnston <alan@ese.wustl.edu>, btns@ietf.org, jb27@cec.wustl.edu
Subject: Re: [btns] rfc 5387
X-BeenThere: btns@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <btns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/btns>
List-Post: <mailto:btns@ietf.org>
List-Help: <mailto:btns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2009 22:11:43 -0000

On Tue, May 05, 2009 at 02:43:16PM -0700, Joe Touch wrote:
> Nicolas Williams wrote:
> > On Thu, Apr 23, 2009 at 04:15:59PM -0500, jb27@cec.wustl.edu wrote:
> >> -From section 4, BTNS protects security associations after they are
> >> established by reducing vulnerability to attacks from parties that are not
> >> participants in the association.?  Doest this include MitM attacks?
> > 
> > Yes.
> 
> Agreed - *after* the BTNS association is established, it does protect
> from further MITM attacks.

I should clarify one more thing: BTNS protects against MITMs after the
initial exchange IFF either leap-of-faith (PAD updates) is done, and/or
connection-latching is used.  If you do neither then you get no MITM
protection at all.

BTNS protects against MITMs in the initial connection IFF either
out-of-band authentication of peer ID is done, and/or in-band
authentication + channel binding is done.  If you do neither then you
get no MITM protection on the initial connection.

Nico
--