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

Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Tue, 02 November 2010 19: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 E05D03A6A07; Tue, 2 Nov 2010 12:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Level:
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 pg4uDaYCc9q4; Tue, 2 Nov 2010 12:03:36 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CEF823A69D8; Tue, 2 Nov 2010 12:03:35 -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 <TNBghgAEeSve@rufus.isode.com>; Tue, 2 Nov 2010 19:03:39 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD03E36.3020304@stpeter.im>
Date: Tue, 02 Nov 2010 12:03:31 -0700
Message-Id: <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@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>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
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: Tue, 02 Nov 2010 19:03:37 -0000

On Nov 2, 2010, at 9:37 AM, Peter Saint-Andre wrote:

>> 
>> I suspect I'm in the rough on both points.  Oh well.
>> 
>>> 2. The technology that the XMPP community uses for account
>>> registration (XEP-0077) could benefit from an update, or even a
>>> replacement, and when that work is completed I'd like to include a
>>> method by which a client could register a key or cert with the
>>> server, thus smoothing the path toward password-less
>>> authentication. IMHO that will be the best approach in the longer
>>> term, instead of continually tweaking the password-based methods.
>>> But that's a topic for another time...
>> 
>> I also think transition-needed needs to be deprecated in favor of
>> transition within the bound channel (e.g., today via XEP 77, tomorrow
>> ?).
> 
> I'm not sure exactly what "transition within the bound channel" is, but
> it sounds worthy of discussion when we work on 3920ter.

The problem with transition-needed is that the error is sent outside the bound channel.

By "within the bound channel", I mean a transitioning method, including any necessary signaling, would be performed inside the bound channel, that is, within the new <stream:stream/> protected by the SASL exchange.

> At this point I
> don't think the XMPP community has a great deal of experience with, or
> even understanding of, channel binding, so it's difficult for us to make
> strong recommendations that depend on channel binding.

It would be same issue of doing transition outside of a SASL negotiated security layer.  It's prone to attack.  And the fix is the same.

-- Kurt