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

Kurt Zeilenga <Kurt.Zeilenga@isode.com> Wed, 03 November 2010 21:03 UTC

Return-Path: <Kurt.Zeilenga@isode.com>
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 666E23A688D; Wed, 3 Nov 2010 14:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.374
X-Spam-Level:
X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 HAlsPV3b8SUt; Wed, 3 Nov 2010 14:03:41 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3F6EF3A66B4; Wed, 3 Nov 2010 14:03:41 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TNHOMQAEebuE@rufus.isode.com>; Wed, 3 Nov 2010 21:03:47 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@isode.com>
In-Reply-To: <AANLkTinmSdGN2D1ZzwCQy9iYTTfSfXoF+T+nBOxcLkPv@mail.gmail.com>
Date: Wed, 3 Nov 2010 14:03:42 -0700
Message-Id: <28590B36-877A-47AF-9B7A-D5A3FA3B2079@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>
To: Matthew Wild <mwild1@gmail.com>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
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>, Peter Saint-Andre <stpeter@stpeter.im>
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:03:42 -0000

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.

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. 

-- Kurt