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

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 02 November 2010 11:20 UTC

Return-Path: <yaronf.ietf@gmail.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 0CD493A68B1; Tue, 2 Nov 2010 04:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.888
X-Spam-Level:
X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=0.711, 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 XW51hWVFWr4B; Tue, 2 Nov 2010 04:20:15 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8B9D328C113; Tue, 2 Nov 2010 04:20:12 -0700 (PDT)
Received: by wwe15 with SMTP id 15so6819033wwe.13 for <multiple recipients>; Tue, 02 Nov 2010 04:20:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=o6JgBjUhLpehs5Q/EAm2j4GI/FQD69Iw+JPLxLbAlWw=; b=dLMelhbtELV6Sc4ct7ep2te5i9jvLFvTt1VvXhLy7A1bfgr0IRuN/aIe9yA9jzMLZ1 zl7PF5PY1qj1HHS8Ai9sXJj7AWuC93KkXyG0AmXZsfpNCFwd0E5Nxp8IGbuxxJfxhedi ebvbIKbVyTZDezta6sG5PLOriVV+r6JhRK3J4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cInOD4CKTFMAPTpZaW0v8OCjmW0yFkDrugGySmYrJImYlN/gcXPOQPTFj2hCceUQ3G 75Na1+rAJpTuYGkA7w6itF7DY9uMmOA60HPlus0rZ9ErxpxVQ45Yh/xuQulfBhVBzMpv a5z6/ZRFYVlPs7YhTrvv5cEvEjX7ffF07rDYk=
Received: by 10.227.132.209 with SMTP id c17mr3780789wbt.24.1288696811638; Tue, 02 Nov 2010 04:20:11 -0700 (PDT)
Received: from [10.0.0.2] (bzq-79-181-26-165.red.bezeqint.net [79.181.26.165]) by mx.google.com with ESMTPS id a17sm6205467wbe.6.2010.11.02.04.20.08 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 04:20:10 -0700 (PDT)
Message-ID: <4CCFF3E6.7040800@gmail.com>
Date: Tue, 02 Nov 2010 13:20:06 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
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>
In-Reply-To: <4CCF9776.5060207@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Dave Cridland <dave@cridland.net>
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 11:20:17 -0000

I'm OK with this text, including (sigh) PLAIN.

On 11/02/2010 06:45 AM, Peter Saint-Andre wrote:
> On 11/1/10 8:59 PM, Peter Saint-Andre wrote:
>
> > As mentioned, I'll work to capture these considerations in proposed 
> text.
>
> Here is proposed text. Please review and provide feedback.
>
> ###
>
> 13.8.  Mandatory-to-Implement Technologies
>
>     The following TLS ciphersuites and SASL mechanisms are mandatory-to-
>     implement (naturally, implementations MAY support other ciphersuites
>     and mechanisms as well).  For security considerations related to TLS
>     ciphersuites, see Section 13.9.4 and [TLS].  For security
>     considerations related to SASL mechanisms, Section 13.9.4, [SASL],
>     and specifications for particular SASL mechanisms such as [SCRAM],
>     [DIGEST-MD5], and [PLAIN].
>
> 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 (REQUIRED) and SCRAM-SHA-1-PLUS variant (RECOMMENDED if
>     channel binding is possible).
>
>        Security Note: Even though it is possible to complete
>        authentication only without confidentiality, it is RECOMMENDED for
>        servers and clients to protect the stream with TLS before
>        attempting authentication with SASL, both to help protect the
>        information exchanged during SASL negotiation and to help prevent
>        certain downgrade attacks; see also Section 13.9.4 and
>        Section 13.9.5.
>
>        Interoperability Note: The use of the SCRAM-SHA-1 or SASL-SCRAM-
>        SHA-1-PLUS mechanism replaces the SASL DIGEST-MD5 mechanism as
>        XMPP's mandatory-to-implement password-based method for
>        authentication only.  For backward-compatibility with existing
>        deployed infrastructure, implementations are encouraged to
>        continue supporting the DIGEST-MD5 mechanism as specified in
>        [DIGEST-MD5]; however, there are known interoperability issues
>        with DIGEST-MD5 that make it impractical in the long term.
>
> 13.8.2.  For Confidentiality Only
>
>     For confidentiality only, servers SHOULD support TLS with the
>     TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.
>
>        Security Note: Because a connection with confidentiality only has
>        weaker security properties than a connection with both
>        confidentiality and authentication, it is RECOMMENDED for servers
>        and clients to prefer connections with both qualities (e.g., by
>        protecting the stream with TLS before attempting authentication
>        with SASL).  In practice, confidentiality only is employed merely
>        for server-to-server connections when the peer server does not
>        present a certificate and the servers use Server Dialback
>        [XEP-0220] for weak identity verification, but TLS is still
>        desirable to protect the connection against casual eavesdropping.
>
> 13.8.3.  For Confidentiality and Authentication With Passwords
>
>     For both confidentiality and authentication with passwords, servers
>     and clients MUST support TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
>     ciphersuite plus SCRAM-SHA-1 and (when channel binding is possible)
>     SCRAM-SHA-1-PLUS.
>
>     As a fallback when SCRAM is not available, servers MAY offer and
>     clients MAY use TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite
>     plus SASL PLAIN.
>
>        Security Note: The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS mechanisms are
>        strongly preferred over the SASL PLAIN mechanism because of their
>        superior security properties.  TLS plus SASL PLAIN is primarily
>        intended to be a fallback for implementations that do not yet
>        support SCRAM.  However, in certain deployment scenarios it can be
>        difficult for a server to offer SCRAM-based mechanisms (e.g.,
>        because the XMPP service depends for authentication purposes on a
>        database or directory that is not under the control of the XMPP
>        administrators).  Furthermore, it can be appropriate for an XMPP
>        service to offer the SASL PLAIN mechanism when it upgrades
>        security mechanisms and needs the plaintext password in order to
>        seed user credentials (see Section 6.5.12).  A client needs to
>        treat all such uses of the SASL PLAIN mechanism with caution, MUST
>        prefer other mechanisms (e.g., SCRAM-SHA-1, SCRAM-SHA-1-PLUS, and
>        EXTERNAL) to the PLAIN mechanism, and MUST NOT use the PLAIN
>        mechanism without confidentiality and integrity protection via
>        TLS.
>
> 13.8.4.  For Confidentiality and Authentication Without Passwords
>
>     For both confidentiality and authentication without passwords,
>     servers MUST and clients SHOULD support TLS with the
>     TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL
>     mechanism (see Appendix A of [SASL]) supporting PKIX certificates.
>
> ###
>
> Peter
>