Re: [btns] rfc 5387

Joe Touch <touch@ISI.EDU> Tue, 05 May 2009 21:42 UTC

Return-Path: <touch@ISI.EDU>
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 BB66D3A6B00 for <btns@core3.amsl.com>; Tue, 5 May 2009 14:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.637
X-Spam-Level:
X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
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 dihviO5PJRZs for <btns@core3.amsl.com>; Tue, 5 May 2009 14:42:37 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 05FB73A6D95 for <btns@ietf.org>; Tue, 5 May 2009 14:42:37 -0700 (PDT)
Received: from [128.9.176.218] (c2-vpn06.isi.edu [128.9.176.218]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n45LhGe2023786; Tue, 5 May 2009 14:43:18 -0700 (PDT)
Message-ID: <4A00B2F4.30009@isi.edu>
Date: Tue, 05 May 2009 14:43:16 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@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> <20090505201529.GP1500@Sun.COM>
In-Reply-To: <20090505201529.GP1500@Sun.COM>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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 21:42:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adding to Nico's response:

Nicolas Williams wrote:
> 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 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.

What it says is:

   ...Furthermore, obtaining and
   deploying credentials such as certificates signed by certification
   authorities (CA) involves additional protocol and administrative
   actions that may incur significant time and effort to perform.


The time and effort are related to the additional protocol and
administrative actions, i.e., setting up a PKI as Nico suggests above.
It's not just getting the certificate that takes time (it doesn't
particularly).

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

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoAsvQACgkQE5f5cImnZrslrACg3WxY5d9leCB1bUi1V7wwrGer
vd8AniqKtfL1TNYDU05ikdM4A6rK7d7e
=4nuR
-----END PGP SIGNATURE-----