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

"Peter Saint-Andre (psaintan)" <psaintan@cisco.com> Wed, 17 July 2013 19:56 UTC

Return-Path: <psaintan@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E616E21E808F for <secdir@ietfa.amsl.com>; Wed, 17 Jul 2013 12:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUZICmewZv9a for <secdir@ietfa.amsl.com>; Wed, 17 Jul 2013 12:56:54 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 56CA621E808E for <secdir@ietf.org>; Wed, 17 Jul 2013 12:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3079; q=dns/txt; s=iport; t=1374091014; x=1375300614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wyDLnm4xAuydEL5/v2cPfG4EUbCsA8m9mtzjxF/gBWg=; b=Rsk/6TUuxuKnW1TcPREHX9z72BYuINP7/m7DJjf/XD19D/QYBTaGGrQd It/drQzl/B7/1KOgcnCfGq2mJC85XA73SBXF4F+KR1ZwQGzeIja4tZt7b ayJzBURLpb/4q2sEaaGzjRFXzRQiShIgPqLAF6QUFxxUmRJx77etM3yI3 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAIP15lGtJV2c/2dsb2JhbABagwaBBMB/gRIWdIIjAQEBAwE6PwULAgEIIg4GEDIlAgQOBQiIAga2Do9HAjEHGIJ1bgOpKYMSgig
X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="236108111"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2013 19:56:53 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HJurwe016543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 19:56:53 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 14:56:53 -0500
From: "Peter Saint-Andre (psaintan)" <psaintan@cisco.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Thread-Topic: Secdir review of draft-ivov-xmpp-cusax
Thread-Index: AQHOgwBB/5UCzShgO0ORdAU4etqp25lpnWAA
Date: Wed, 17 Jul 2013 19:56:52 +0000
Message-ID: <1670FE635C32C34AAD005D960F1C501115CA4D2B@xmb-aln-x11.cisco.com>
References: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org>
In-Reply-To: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.129.24.116]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E9BF1E32BEB74B46A99B5C87503142FA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ivov-xmpp-cusax.all@tools.ietf.org" <draft-ivov-xmpp-cusax.all@tools.ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>, secdir <secdir@ietf.org>
Subject: Re: [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 19:57:00 -0000

Hi Paul, thank you for the review.

On Jul 17, 2013, at 9:13 AM, Paul Hoffman <paul.hoffman@vpnc.org>; wrote:

> 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".

Agreed. Thanks for the text suggestion.

> 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.

The two examples in the Security Considerations are (1) authentication and (2) channel encryption. Do you think we need a full new paragraph about authentication mechanism mismatches, or would it be acceptable to expand upon the text that's there now?

> 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.


Yes, that would be helpful.

The authors will put their heads together and come back with proposed text changes.

--
Peter Saint-Andre