From root@core3.amsl.com Tue May 5 10:30:01 2009 Return-Path: X-Original-To: btns@ietf.org Delivered-To: btns@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6926E3A71C1; Tue, 5 May 2009 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090505173001.6926E3A71C1@core3.amsl.com> Date: Tue, 5 May 2009 10:30:01 -0700 (PDT) Cc: btns@ietf.org Subject: [btns] I-D Action:draft-ietf-btns-channel-binding-api-00.txt X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF. Title : IPsec End-Point Channel Bindings and API Author(s) : N. Williams Filename : draft-ietf-btns-channel-binding-api-00.txt Pages : 8 Date : 2009-04-09 This document defines channel bindings for IPsec and describes an abstract API and a BSD sockets API extension for obtaining channel bindings of "connection latches". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-btns-channel-binding-api-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-btns-channel-binding-api-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-05102455.I-D@ietf.org> --NextPart-- From jb27@cec.wustl.edu Thu Apr 23 14:14:42 2009 Return-Path: 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 5C43F3A687C for ; Thu, 23 Apr 2009 14:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] 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 G4ekrV9DHJdZ for ; Thu, 23 Apr 2009 14:14:41 -0700 (PDT) Received: from mail.cec.wustl.edu (express.cec.wustl.edu [128.252.21.16]) by core3.amsl.com (Postfix) with ESMTP id 905DA3A681D for ; Thu, 23 Apr 2009 14:14:41 -0700 (PDT) Received: from webmail.cec.wustl.edu (localhost.localdomain [127.0.0.1]) by mail.cec.wustl.edu (Postfix) with ESMTP id 014F21E809F; Thu, 23 Apr 2009 16:15:59 -0500 (CDT) Received: from 172.16.1.131 (SquirrelMail authenticated user jb27) by webmail.cec.wustl.edu with HTTP; Thu, 23 Apr 2009 16:15:59 -0500 (CDT) Message-ID: <023070630846bf76af405743608d413b.squirrel@webmail.cec.wustl.edu> In-Reply-To: <49ECADDD.9060204@ese.wustl.edu> 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> Date: Thu, 23 Apr 2009 16:15:59 -0500 (CDT) From: jb27@cec.wustl.edu To: "Alan Johnston" , btns@ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 05 May 2009 10:32:08 -0700 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 21:22:30 -0000 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? -Could BTNS use 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? -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? -MitM attacks are mentioned frequently, how are users detecting them to ensure they can use BTNS? -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? -Is BTNS a form of best effort encryption? -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? From Nicolas.Williams@sun.com Tue May 5 13:38:44 2009 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 -- From touch@ISI.EDU Tue May 5 14:42:37 2009 Return-Path: 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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----- From touch@ISI.EDU Tue May 5 14:49:33 2009 Return-Path: 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 51C863A6D95 for ; Tue, 5 May 2009 14:49:33 -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 ZNWBBZmlpgpi for ; Tue, 5 May 2009 14:49:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2C84D3A6A1C for ; Tue, 5 May 2009 14:49:33 -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 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 21:49:33 -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----- From Nicolas.Williams@sun.com Tue May 5 15:11:43 2009 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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, 5 May 2009 16:48:04 -0500 From: Nicolas Williams To: Joe Touch 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --