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

Yaron Sheffer <> Tue, 02 November 2010 11:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CD493A68B1; Tue, 2 Nov 2010 04:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.888
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XW51hWVFWr4B; Tue, 2 Nov 2010 04:20:15 -0700 (PDT)
Received: from ( []) by (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;; 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;; 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 with SMTP id c17mr3780789wbt.24.1288696811638; Tue, 02 Nov 2010 04:20:11 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id a17sm6205467wbe.6.2010. (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 04:20:10 -0700 (PDT)
Message-ID: <>
Date: Tue, 02 Nov 2010 13:20:06 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <>
References: <> <> <> <> <2761.1288645043.347835@puncture> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>, Security Area Directorate <>, The IESG <>, XMPP Working Group <>, Dave Cridland <>
Subject: Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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)
>     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