Re: [btns] rfc 5387

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 05 May 2009 20:38 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 9B2083A6CE1 for <btns@core3.amsl.com>; Tue, 5 May 2009 13:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.885
X-Spam-Level:
X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.161, 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 bCCWlqpvVujm for <btns@core3.amsl.com>; Tue, 5 May 2009 13:38:43 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 63D023A6BC4 for <btns@ietf.org>; Tue, 5 May 2009 13:38:43 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n45KeACn023300 for <btns@ietf.org>; Tue, 5 May 2009 20:40:10 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n45Ke9kF064566 for <btns@ietf.org>; Tue, 5 May 2009 14:40:10 -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 n45KFUeA025682; Tue, 5 May 2009 15:15:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n45KFTar025681; Tue, 5 May 2009 15:15:29 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 5 May 2009 15:15:29 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: jb27@cec.wustl.edu
Message-ID: <20090505201529.GP1500@Sun.COM>
References: <8ab37b7001d3c3eb657cf4094244ccdc.squirrel@webmail.cec.wustl.edu> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <023070630846bf76af405743608d413b.squirrel@webmail.cec.wustl.edu>
User-Agent: Mutt/1.5.7i
Cc: Alan Johnston <alan@ese.wustl.edu>, btns@ietf.org
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 20:38:44 -0000

On Thu, Apr 23, 2009 at 04:15:59PM -0500, jb27@cec.wustl.edu wrote:
> Hello!  I am a student taking Internet Communications and our class is
> just finishing up our "security" section and I have a few questions about
> rfc 5387.
> 
> 
> -In the section 1.1 (Authentication) it is mentioned that is possible to
> use a trusted third party, could this be a third “peer”, proxy, and or
> STUN server?

The "trusted third party" thing wasn't the important thing -- what was
relevant in that sentence was "[o]ut-of-band authentication can be
done".  The particular method by which out-of-band authentication is
done is not terribly important because there's an enormous variety of
mechanisms that you could use.

> -Could BTNS use Chords?

What is Chords?

> -In section 1.2, it is mentioned “the peer's identity is the same for the
> lifetime of the packet flow”, can this identity be reused so it is open to
> attacks?

The identity can be reused, of course, but I don't understand the "so it
is open to attacks" part.

> -In this RFC it is mentioned that obtaining a security certificate could
> take a while.  I’ve never had to get one, so how long does it take?  Why
> would it be necessary to skip?

That's unfortunate.  The problem isn't how long it takes to get a
certificate (it could be as little as seconds with an online CA using
something else for authentication -- think "kca", a kerberized CA), but
the fact that deploying a PKI is usually difficult for a variety of
reasones.

> -MitM attacks are mentioned frequently, how are users detecting them to
> ensure they can use BTNS?

If BTNS is used like SSH leap-of-faith, then there's no protection on
the first connection, but there is thereafter if there was no MITM on
that first connection.

If channel binding is used then channel binding detects MITMs.

> -Although it can be cumbersome, what’s wrong with having redundancy?
> “. . . authentication at both the network layer and a higher layer for the
>    same connection.”  Or is this where one authentication might fail?

This isn't about authentication redundancy.  It's about pushing session
cryptographic protection to lower layers.

The canonical example for the IPsec channel case would be any protocol
that uses RDMA/RDDP.  In such protocols you have a header between the
transport (TCP, SCTP, UDP, ...) and the application protocol, and that
header tells the "RNIC" (RDDP-capable NIC) that some parts of the
application data payloads should be delivered directly into pre-arranged
RDMA buffers.  In order to make RNICs + session security feasible while
still retaining the performance benefits of RDDP you need the
application layer to be in cleartext relative to the RDDP header, which
means that session cryptographic protection has to be done below it,
either at the transport layer or IP.

In the case of other apps, like, say, IMAP, you can also benefit from
pushing crypto to lower layers, such as TLS.  In the TLS case the
benefit comes from having already-deployed TLS concentrators that can be
used to offload the crypto from the server.

> -Is BTNS a form of best effort encryption?

If used alone, yes.  If used with channel binding or out-of-band
authentication, no.

> -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.

Nico
--