Subject: [MMUSIC] Review: draft-ietf-mmusic-sdp-uks

From: Adam Roach <[email-masked]>
Date: Mon, 27 Aug 2018 18:16:00 -0500

I was asked by the MMUSIC chairs to review draft-ietf-mmusic-sdp-uks.

At a high level, I don't think the proposed fix works for SIP in current
deployments; but I also doubt that the described attack can be credibly
mounted in SIP. Specific details below.

To be clear, I think there is utility in defining TLS extensions to 
perform the
kind of identity binding proposed by this document -- but rather than 
describing
the situation using relatively implausible attack scenarios, I think the
document needs to be more up-front about this being a belt-and-suspenders
preventative measure for a class of attacks that we don't yet know an 
exploit
for, but for which we can certainly imagine an exploit being developed.

---------------------------------------------------------------------------

i-d nits reports an RFC 2119 issue and several outdated references. See
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mmusic-sdp-uks-02.txt

---------------------------------------------------------------------------

§2:

 >  When the identity of communicating peers is established by higher-
 >  layer signaling constructs, such as those in SIP [RFC4474]

s/4474/8224/

---------------------------------------------------------------------------

§2:

 >  This attack is an aspect of SDP-based protocols that the technique
 >  known as third-party call control (3PCC) relies on.

Maybe cite RFC 3725?

---------------------------------------------------------------------------

§2.1:

 >  A SIP endpoint or WebRTC endpoint that is configured to reuse a
 >  certificate can be attacked if it is willing to conduct two
 >  concurrent calls, one of which is with an attacker.

Concurrent calls -- such as a "hold and take incoming call" -- are pretty
common. The attack described in this document, as far as I can tell, is
something much more esoteric than that: it's two outbound calls initiated at
approximately the same time.

---------------------------------------------------------------------------

§2.2:

 >  The use of TLS with SDP depends on the integrity of session
 >  signaling.  Assuming signaling integrity limits the capabilities of
 >  an attacker in several ways.

This is generally a bad assumption. The penetration of TLS in SIP 
deployments is
(by my understanding) incredibly low.

I'll also note that validation of certificates is performed hop-by-hop (as
each proxy in the chain terminates the TLS connection and re-initiates a new
one), so this assumption requires that all the proxies on the path are 
trusted
not to be corruptable by the attacker. Given that the attacker has already
demonstrated the extraordinary ability to not just intercept and inject 
traffic,
but to actually block valid traffic, it seems pretty likely that they 
would be
in a position to also alter validation of certificates at the proxy 
closest to
the calling user, giving them free reign to MITM the calling user and modify
arbitrary signaling fields.

---------------------------------------------------------------------------

§2.3:

The unnumbered figure in this section (consider adding figure numbers) 
doesn't
make sense to me.

      Norma               Mallory             Patsy
      (fp=N)               -----              (fp=P)
        |                    |                  |
      1 +---Offer1 (fp=N)--->|                  |
      2 +-----Offer2 (fp=N)-------------------->|
      3 |<--------------------Answer2 (fp=P)----+
      4 |<--Answer1 (fp=P)---+                  |
        |                    |                  |
      5 |======DTLS1====>(Forward)====DTLS1====>|
      6 |<=====DTLS2=====(Forward)<===DTLS2=====|
      7 |======Media1===>(Forward)====Media1===>|
      8 |<=====Media2====(Forward)<===Media2====|
        |                    |                  |
      9 |======DTLS2===========>(Drop)          |
        |                    |                  |

Presumably, DTLS1 corresponds to Offer1, while DLTS2 corresponds to Offer2?
Please make that explicit.  Also, it took me a few beats to figure out that
"fp=N" meant "Fingerprint = Norma," so it might be worth explaining that
notation.

Where I get lost, however, is around step 6 (refer to the step numbers 
above),
which is described as:

    Mallory also intercepts
    packets from Patsy and forwards those to Norma at the transport
    address that Norma associates with Mallory.

This seems to introduce a much stronger requirement on the attacker; namely
that they have the ability to intercept traffic bound for one of the 
victims.
This should be discussed in section 2.2. I'll note that, for step 9 to work,
the attacker must have the ability to cause packets to be dropped -- so 
merely
being able to observe and inject traffic isn't sufficient. Mallory has to
literally be on-path and effectively acting as network infrastructure.

The other thing that confuses me is that this scenario doesn't describe a
credible mechanism by which Mallory might compel Norma to engage in some
really strange call behavior; namely, the initiation of two outbound calls
simultaneously.

---------------------------------------------------------------------------

§3.1:

In general, I don't think this works because of the issues involving SIP
signaling integrity that I discuss above. I think you need to somehow 
bind the
PASSPoRT identity into the DTLS signaling, rather than using yet another
identifier that isn't bound to identity. I haven't worked through all the
details here, but it probably looks a lot like what you've proposed for 
WebRTC.

---------------------------------------------------------------------------

§3.1:

 >  Endpoints MUST check that the "id" parameter in the extension that
 >  they receive includes the "tls-id" attribute value that they received
 >  in their peer's session description.  Comparison can be performed
 >  with either the decoded ASCII string or the encoded octets.

What is the distinction being made here between "decoded" and "encoded" 
forms?

---------------------------------------------------------------------------

§4.1:

I'm a little surprised not to see a discussion of cryptoagility in here.

/a

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 31 Aug 2018 12:49:29 -0400

Thank you for the review Adam.

Based on the comments below, we will wait to hear from the authors 
before determining what is next for this draft.

Regards

-- Flemming (as MMUSIC co-chair)

On 8/27/18 7:16 PM, Adam Roach wrote:
> demonstrated the extraordinary ability to not just intercept and 
> inject traffic,
> the attacker must have the ability to cause packets to be dropped -- 
> so merely
> details here, but it probably looks a lot like what you've proposed 
> for WebRTC.
>
> What is the distinction being made here between "decoded" and 
> "encoded" forms?
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic