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

Peter Saint-Andre <stpeter@stpeter.im> Tue, 02 November 2010 02:59 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 CAA0F3A6868; Mon, 1 Nov 2010 19:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 0Ztdf8neE2gI; Mon, 1 Nov 2010 19:59:08 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 46FB43A682A; Mon, 1 Nov 2010 19:59:08 -0700 (PDT)
Received: from squire.local (dsl-175-35.dynamic-dsl.frii.net [216.17.175.35]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3799340D1E; Mon, 1 Nov 2010 21:07:43 -0600 (MDT)
Message-ID: <4CCF7E7A.5050303@stpeter.im>
Date: Mon, 01 Nov 2010 20:59:06 -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: Dave Cridland <dave@cridland.net>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture>
In-Reply-To: <2761.1288645043.347835@puncture>
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="------------ms000309080307060705020302"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Florian Zeitz <florob@babelmonkeys.de>, 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>
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 02:59:10 -0000

On 11/1/10 2:57 PM, Dave Cridland wrote:
> On Mon Nov  1 18:20:03 2010, Florian Zeitz wrote:
>> >> I think it's better to remove TLS plus SASL PLAIN from the list of
>> >> mandatory-to-implement technologies.
>> >>
>> > OK.
>> >
>> FWIW, I'm not entirely content with that for two reasons:
> 
> I'll scrap yours, and add a third.
> 
> 
>> a) Even if TLS+SASL PLAIN is not MTI people still will and do implement
>> it. I think it would therefore make sense to still specify that PLAIN
>> shall only be used as a "last resort".
>>
>>
> I think SASL PLAIN should be specifying this. There's nothing special in
> XMPP which makes PLAIN a poor choice.

I disagree -- it's our job to specify how we use the tools we've been given.

>> b) (which is my bigger concern) As strange as that may sound, we need
>> PLAIN in order to upgrade to a new mechanism. I though this was also
>> explicit in 3920bis, but I can't find it right now.
>> Consider a case where a server only stores the MD5 hash of the password.
>> This is sufficient to do PLAIN and DIGEST MD5 auth. But for SCRAM a
>> different representation is needed.
>> The common way for the server to upgrade is to once offer only PLAIN as
>> a mechanism. If that is not possible (clients can choose not to support
>> PLAIN) some deployments might be stuck with DIGEST MD5...
>> We could mandate that PLAIN is only MTI for clients (servers would
>> implement it when they need to), but that would allow for the same
>> down-grade attacks that are already possible now (i.e. hopefully none
>> ;) ).
> 
> You're thinking of transition-needed, which was IIRC removed from the
> bis drafts.
> 
> It's pretty scary itself, as it provides an easy path to a downgrade
> attack.

If the stream is already TLS-protected, the attacker would need to have
control over the server (in which case the server wouldn't offer TLS in
the first place, of course). It seems to me that the client can take
appropriate protective measures to avoid this attack (just always force
TLS).

> But here's another compelling (in my view) reason to keep PLAIN, quoted
> from the opening lines of RFC 4616:
> 
>   Clear-text, multiple-use passwords are simple, interoperate with
>   almost all existing operating system authentication databases
> 
> In particular, where we use an Active Directory, or other third-party
> LDAP directory, we more or less have to drop down to only offering
> PLAIN. (With AD we can also offer GSSAPI sometimes, but this isn't an
> ideal choice for an MTI, and with any LDAP directory we could provide
> SCRAM secrets to some extent).
> 
> Requiring clients and servers to be capable of using PLAIN, whilst
> advising (and providing) better alternatives to cover other cases, seems
> to be the best choice for interoperability.

IMHO that's been the experience of the XMPP community so far.

As mentioned, I'll work to capture these considerations in proposed text.

Peter

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