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

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Jul 2013 08:13:42 -0700

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

---

From: "Peter Saint-Andre (psaintan)" <[email-masked]>
Date: Wed, 17 Jul 2013 19:56:52 +0000

Hi Paul, thank you for the review.

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

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…

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Jul 2013 13:33:00 -0700

On Jul 17, 2013, at 12:56 PM, Peter Saint-Andre (psaintan) <[email-masked]> wrote:

> The two examples in the Security Considerations are (1) authentication and (2) channel encryption.

But they are not called out as such, and they are in a single paragraph.

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

Full new paragraph. And maybe split out the previous two.

--Paul Hoffman