Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
Peter Saint-Andre <stpeter@stpeter.im> Tue, 02 November 2010 04:45 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 1233C3A66B4; Mon, 1 Nov 2010 21:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 HIGtOywWodG6; Mon, 1 Nov 2010 21:45:44 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9ED083A67CC; Mon, 1 Nov 2010 21:45:43 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77A3740D1E; Mon, 1 Nov 2010 22:54:18 -0600 (MDT)
Message-ID: <4CCF9776.5060207@stpeter.im>
Date: Mon, 01 Nov 2010 22:45:42 -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> <4CCF7E7A.5050303@stpeter.im>
In-Reply-To: <4CCF7E7A.5050303@stpeter.im>
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="------------ms000403000101040301060400"
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 04:45:50 -0000
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 -- Peter Saint-Andre https://stpeter.im/
- [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