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

Peter Saint-Andre <stpeter@stpeter.im> Tue, 02 November 2010 16:37 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 E3A1C3A69DE; Tue, 2 Nov 2010 09:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.888
X-Spam-Level:
X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=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 yYgj7eEQ-39h; Tue, 2 Nov 2010 09:37:08 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4F97D3A679C; Tue, 2 Nov 2010 09:37:08 -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 7613540D1E; Tue, 2 Nov 2010 10:45:48 -0600 (MDT)
Message-ID: <4CD03E36.3020304@stpeter.im>
Date: Tue, 02 Nov 2010 10:37:10 -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>
In-Reply-To: <706C109C-A2D2-4E17-B5AA-6B881F7E0334@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="------------ms000106070902070709080102"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.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 16:37:11 -0000

On 11/2/10 8:13 AM, Kurt Zeilenga wrote:
> 
> On Nov 2, 2010, at 5:12 AM, Peter Saint-Andre wrote:
> 
>> On 11/2/10 5:20 AM, Yaron Sheffer wrote:
>>> I'm OK with this text, including (sigh) PLAIN.
>> 
>> If it's any consolation, I'm sighing along with you. :)
>> 
>> Two points:
>> 
>> 1. Eventually, we should be able to drop PLAIN in a future revision
>> of the MTI technologies spec that we'll pull out of 3920bis in 1+
>> years.
> 
> Good luck with that.  The arguments used now for its inclusion is
> likely to be repeated and, again, win.
> 
> Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it
> does offer good interoperability, it does [NOT offer] good enough security for
> today's, and more importantly, tomorrow's Internet.

IMHO the point of moving the MTI list out of the core spec is that we
can revise it more frequently. I think we'll be in a stronger position
to discard PLAIN once we have more SCRAM implementations in our world.

> I think we actually should be mandating a SCRAM-*-PLUS mechanism,
> because channeling bindings are really needed due to 'user click
> through' of TLS warnings, downgrade attack warnings, etc..   I do
> suspect that it will take time for this mechanism to be come
> ubiquitous, but I fear that without a MUST, it will never become
> ubiquitous.   But I do suspect well have multiple independently
> developed implementations of SCRAM-*-PLUS in XMPP within a few months
> of publication of this revision of XMPP.

I think the section on "Mandatory-to-Implement Technologies" is not
quite right, because it needs to say that SCRAM-SHA1-PLUS shall be
*implemented in code*:

###

13.8.1.  For Authentication Only

   For authentication only, servers and clients MUST support the SASL
   Salted Challenge Response mechanism [SCRAM], in particular the SCRAM-
   SHA-1 variant and SCRAM-SHA-1-PLUS variant.

###

Whereas the section on "Use of SASL" specifies when those MTI variants
are actually *used in deployment* by software that implements it:

###

13.9.4.  Use of SASL

   [...]

   The SASL framework itself does not provide a method for binding SASL
   authentication to a security layer providing confidentiality and
   integrity protection that was negotiated at a lower layer (e.g.,
   TLS).  Such a binding is known as a "channel binding" (see
   [CHANNEL]).  Some SASL mechanisms provide channel bindings, which in
   the case of XMPP would typically be a binding to TLS (see
   [CHANNEL-TLS]).  If a SASL mechanism provides a channel binding
   (e.g., this is true of [SCRAM]), then XMPP entities using that
   mechanism SHOULD prefer the channel binding variant (e.g., preferring
   "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1").  If a SASL mechanism does not
   provide a channel binding, then the mechanism cannot provide a way to
   verify that the source and destination end points to which the lower
   layer's security is bound are equivalent to the end points that SASL
   is authenticating; furthermore, if the end points are not identical,
   then the lower layer's security cannot be trusted to protect data
   transmitted between the SASL-authenticated entities.  In such a
   situation, a SASL security layer SHOULD be negotiated that
   effectively ignores the presence of the lower-layer security.

###

> 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. 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.

Peter

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