[secdir] Secdir review of draft-ivov-xmpp-cusax

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 17 July 2013 15:13 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AC9AC11E80F9 for <secdir@ietfa.amsl.com>; Wed, 17 Jul 2013 08:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xxma67TGY83K for <secdir@ietfa.amsl.com>; Wed, 17 Jul 2013 08:13:47 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 16B9E11E80FA for <secdir@ietf.org>; Wed, 17 Jul 2013 08:13:42 -0700 (PDT)
Received: from [] (50-1-98-228.dsl.dynamic.sonic.net []) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6HFDe30060696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jul 2013 08:13:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [] claimed to be []
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org>
Date: Wed, 17 Jul 2013 08:13:42 -0700
To: secdir <secdir@ietf.org>, draft-ivov-xmpp-cusax.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [secdir] Secdir review of draft-ivov-xmpp-cusax
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 17 Jul 2013 15:13:47 -0000

Greetings. I have reviewed this document for security issues, and have mixed feelings. I apologize for the lateness of this review.

The draft specifies a non-normative way to make clients (and to a small extent, servers) mostly-transparently combine the use of SIP for voice and video with XMPP for instant messaging. It is informational, and talks about the various things that applications developers of software that makes this combination should think about.

Security is barely discussed, likely because a client that is presenting two different protocols that each have their own security frameworks is not going to make the security of either protocol worse. However, user perception of security will be significantly affected by the combination. There is one paragraph that alludes to this in the Security Considerations, but there should be more.

The first sentence of that one paragraph describes mis-matched crypto between the SIP part and the XMPP part, which is fine but mostly invisible to users.

The second sentence is much more worrying: it describes the case where one of the protocols is cryptographically protected and the other has none. This is an all-too-common case with IETF protocols: the user doesn't have to turn on crypto, and once it is not turned on, that fact is forgotten. The document blithely says that the application developer should ensure that such mis-matches are avoided to prevent downgrade attacks, but says nothing about how that could be avoided. A stronger statement would be "if both protocols are not protected by similar levels of cryptographic protection, the user MUST be informed of that and given the opportunity to bring both up to the same level".

There should also be at least a paragraph describing the difference in commonly-used authentication mechanisms for SIP and XMPP. A user may have authenticated one of the two channels with an easily-attacked password, but the other channel with a strong cryptographic mechanism such as TLS client certificates. When you combine two similar functions into one application without making that clear, a user might assume that their IM and voice communications are similarly protected when in fact they are not.

It would also be valuable if the document mentioned the possibility of security mis-match in the introduction, given the high chance for user confusion on the issue.

--Paul Hoffman