Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17

Peter Saint-Andre <stpeter@stpeter.im> Wed, 03 November 2010 21:53 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1292B3A690A; Wed, 3 Nov 2010 14:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level:
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 FQ7chxOLHGVd; Wed, 3 Nov 2010 14:53:26 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D92123A68E8; Wed, 3 Nov 2010 14:53:25 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0DD7D40D1E; Wed, 3 Nov 2010 16:02:14 -0600 (MDT)
Message-ID: <4CD1D9DA.9020400@stpeter.im>
Date: Wed, 03 Nov 2010 15:53:30 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Kurt Zeilenga <Kurt.Zeilenga@isode.com>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im> <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM> <4CD151F7.6060809@stpeter.im> <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM> <4CD19C81.9050509@stpeter.im> <AANLkTinmSdGN2D1ZzwCQy9iYTTfSfXoF+T+nBOxcLkPv@mail.gmail.com> <28590B36-877A-47AF-9B7A-D5A3FA3B2079@isode.com>
In-Reply-To: <28590B36-877A-47AF-9B7A-D5A3FA3B2079@isode.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010106010101030308050604"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>, Matthew Wild <mwild1@gmail.com>
Subject: Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Nov 2010 21:53:27 -0000

On 11/3/10 3:03 PM, Kurt Zeilenga wrote:
> 
> On Nov 3, 2010, at 11:10 AM, Matthew Wild wrote:
> 
>> On 3 November 2010 17:31, Peter Saint-Andre <stpeter@stpeter.im>
>> wrote:
>>> 
>> 
>>> as described under Section 13.7.2.1 (however, the lack of
>>> channel binding in the PLAIN mechanism implies that even
>>> authenticated TLS cannot fully protect the SASL negotiation and
>>> subsequent communications when PLAIN is used).
>>> 
>> 
>> I'm no expert on this, but is this text technically true? I
>> thought channel binding would only be beneficial where there is not
>> full TLS authentication.
> 
> Channel binding is beneficial regardless of whether there the client
> performed TLS server cert/subject checks.  Note that the server has
> no clue what checks, if any, the client (or its user) performed.
> With channel bindings, it becomes irrelevant to the server whether
> the client performed these checks or not.  That is, (amongst other
> things) channel bindings provide a means for the server itself to
> protect against MITM attacks.
> 
> I do agree, however, that he wording of the however comment is
> confusing and seems should either be removed or replaced.

Removed in my working copy.

> My main concern is that Unauthenticated TLS is subject to downgrade
> to PLAIN by two vectors, spoofing mechanisms and spoofing transition
> required.
> 
> Removing <transition-needed/> (in favor of a yet to be specified
> extension) addresses one vector.
> 
> There seems no good way to address the other vector at this time.  I
> do suggest however that the 13.9.4 text: To help prevent this attack,
> the parties SHOULD protect the channel using TLS before attempting
> SASL negotiation. be replaced with: To mitigate this attack, the
> partied SHOULD protect the channel using TLS before attempting SASL
> negotiation and either perform full certificate validation as
> described in Section 13.7.2.1 or utilize a mechanism which provides
> channel bindings, such as SCRAM-SHA-1-PLUS.

Text incorporated, with minor tweaks.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/