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

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

On 7/17/13 1:56 PM, Peter Saint-Andre (psaintan) wrote:
> Hi Paul, thank you for the review.

Thanks again and apologies for the delayed processing. Proposed text
changes inline.

> On Jul 17, 2013, at 9:13 AM, Paul Hoffman <[e-mail]>
> 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?

OLD

7. Security Considerations


   Use of the same user agent with two different accounts providing
   complementary features introduces the possibility of mismatches
   between the security profiles of those accounts or features.  For
   example, the SIP aspect and XMPP aspect of the CUSAX service might
   offer different authentication options (e.g., digest authentication
   for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802]
   for XMPP as specified in [RFC6120]).  Similarly, a CUSAX client might
   successfully negotiate Transport Layer Security (TLS) [RFC5246] when
   connecting to the XMPP aspect of the service but not when connecting
   to the SIP aspect.  Such mismatches could introduce the possibility
   of downgrade attacks.  User agent developers and service providers
   ought to ensure that such mismatches are avoided as much as possible.

   Refer to the specifications for the relevant SIP and XMPP features
   for detailed security considerations applying to each "stack" in a
   CUSAX client.

NEW

7.  Security Considerations

   Use of the same user agent with two different accounts providing
   complementary features introduces the possibility of mismatches
   between the security profiles of those accounts or features.  Two
   security mismatches of particular concern are:

   o  The SIP aspect and XMPP aspect of a CUSAX service might offer
      different authentication options (e.g., digest authentication for
      SIP as specified in [RFC3261] and SCRAM authentication [RFC5802]
      for XMPP as specified in [RFC6120]).  Because SIP uses a password-
      based method (digest) and XMPP uses a pluggable framework for
      authentication via the Simple Authentication and Security Layer
      (SASL) technology [RFC4422], it is also possible that the XMPP
      connection could be authenticated using a password-free method
      such as client certificates with SASL EXTERNAL even though a
      username and password is used for the SIP connection.

   o  The Transport Layer Security (TLS) [RFC5246] ciphersuites offered
      or negotiated on the XMPP side might be different from those on
      the SIP side because of implementation or configuration
      differences between the SIP server and the XMPP server.  Even more
      seriously, a CUSAX client might successfully negotiate TLS when
      connecting to the XMPP aspect of the service but not when
      connecting to the SIP aspect, or vice-versa.  In this situation an
      end user might think that the combined CUSAX session with the
      service is protected by TLS, even though only one aspect is
      protected.

   Security mismatches such as these (as well as others related to end-
   to-end encryption of messages or media) introduce the possibility of
   downgrade attacks, eavesdropping, information leakage, and other
   security vulnerabilities.  User agent developers and service
   providers MUST ensure that such mismatches are avoided as much as
   possible (e.g., by enforcing common and strong security
   configurations and policies across protocols).  Specifically, if both
   protocols are not safeguarded by similar levels of cryptographic
   protection, the user MUST be informed of that fact and given the
   opportunity to bring both up to the same level.

   Section 5 discusses potential issues that may arise due to a mismatch
   between client capabilities, such as calls being initiated with costs
   contrary to the expectation of the end user.  Such issues could be
   triggered maliciously, as well as by accident.  Implementers
   therefore need to provide necessary cues to raise user awareness as
   suggested in Section 5.

   Refer to the specifications for the relevant SIP and XMPP features
   for detailed security considerations applying to each "stack" in a
   CUSAX client.

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

OLD

   This document explains how such hybrid offerings can be achieved with
   a minimum of modifications to existing software while providing an
   optimal user experience.  It covers server discovery, determining a
   SIP Address of Record (AOR) while using XMPP, and determining an XMPP
   Jabber Identifier ("JID") from incoming SIP requests.  Most of the
   text here pertains to client behavior but it also recommends certain
   server-side configurations.

NEW

   This document explains how such hybrid offerings can be achieved with
   a minimum of modifications to existing software while providing an
   optimal user experience.  It covers server discovery, determining a
   SIP Address of Record (AOR) while using XMPP, and determining an XMPP
   Jabber Identifier ("JID") from incoming SIP requests.  Most of the
   text here pertains to client behavior but it also recommends certain
   server-side configurations and operational practices.  The document
   also discusses significant security considerations that can arise
   when offering a dual-protocol solution, and provides advice for
   avoiding security mismatches that would result in degraded
   communications security for end users.

Let us know what you think of the proposed modifications.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/