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 >
- [secdir] SecDir review of draft-ietf-xmpp-3920bis… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Florian Zeitz
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Jeffrey Hutzelman
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Matthew Wild
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Philipp Hancke
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre