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

[Peter Saint-Andre <[e-mail]>]

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/