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

Peter Saint-Andre <stpeter@stpeter.im> Tue, 02 November 2010 20:17 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 1ABF13A69E1; Tue, 2 Nov 2010 13:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.932
X-Spam-Level:
X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 Y99I3FxLJuff; Tue, 2 Nov 2010 13:17:23 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EDCBC3A68E6; Tue, 2 Nov 2010 13:17:22 -0700 (PDT)
Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2CA4F40D1E; Tue, 2 Nov 2010 14:26:04 -0600 (MDT)
Message-ID: <4CD071D5.3080808@stpeter.im>
Date: Tue, 02 Nov 2010 14:17:25 -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>
In-Reply-To: <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@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="------------ms050800080302030503040007"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
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 20:17:24 -0000

On 11/2/10 1:03 PM, Kurt Zeilenga wrote:
> 
> 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.

What is the attack? If the client required negotiation of TLS before
moving on to SASL, the server has already authenticated to the client at
the stage. As I far as I understand, you are arguing that SASL
negotiation could result in establishment of a further security layer
that is bound to the TLS layer via channel binding, and that it is safe
for the client to send plaintext credentials to the server only after
channel binding has taken place. Correct? If so, then we'd need to
define a post-SASL protocol (that might include work on periodic
re-authentication requests sent from server to client). But IMHO that
work is out of scope for 3920bis. The question is: is it better to
remove the <transition-needed/> SASL condition pending work on the
future protocol extension?

Peter

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