Subject: Re: [MMUSIC] Input wanted for draft-ietf-mmusic-sdp-uks

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Jun 2018 17:43:51 -0400

I took a look at the document and have a couple of comments:

I was initially expecting the unknown key share attack to be about what 
the document refers to as Session Concatenation (in Section 5), however 
the attack overview in Section 2.1 describes two other attack scenarios 
instead. I think it would be helpful to be clear on all the attack 
scenarios up front.

Secondly, I find it very difficult to follow the "two concurrent calls" 
attack scenario described. The overview is very high-level and the 
example in Section 2.3 omits too many details for me to fully understand 
the attack (there seems to be more going on between Mallory and Patsy 
than explained in the text and there are subtleties around what Mallory 
actually does with the respective SIP, DTLS and media packets for each 
session that are not entirely clear to me). Without a solid 
understanding of the attack, it is difficult to determine if the 
proposed solution truly mitigates it (I was in fact wondering about how 
the solution would work with session concatenation in the absence of 
somehow securely associating the session identifier with a particular 
SIP signaling session, which the document gets more into later in 
Section 5).

A similar concern applies to the WebRTC use case, since I'm not familiar 
with the details of how that works, and hence would benefit from more 
details.

On that note, there are solution elements here that span TLS/DTLS, SDP, 
and WebRTC/RTCWeb, and we should ensure those groups review the document 
as well. Have the authors circulated the document in those groups ?

Thanks

-- Flemming (as individual)

On 5/21/18 9:44 AM, Bo Burman wrote:
>
> WG,
>
> We have not seen any discussion on the list for this draft since it 
> was submitted late January 2018. Please consider reviewing and 
> commenting if you have interest in progressing the draft. It is a 
> short document (only 13 pages in total).
>
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-uks/
>
> Cheers,
>
> Bo
>
> MMUSIC co-chair
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Jun 2018 09:14:03 -0700

Thanks for reviewing this Flemming.

This is definitely a difficult attack to understand (and therefore
also explain).  I took a look at the description we have in the draft
and tried to improve it a little.  I pointed out that the basic attack
can be extended to session concatenation in the overview section, and
tweaked the wording in a few places.

However, I don't think that details of signaling would make this
clearer.  Though it's possible that this is eliding a few things that
seem obvious to me.  Of course, I'm too close to this to be sure.
Maybe we can discuss how this works and maybe we can figure out how to
improve the text.

This has been pretty widely reviewed, but I can provide another nudge
for the related working groups to have a look.

On Thu, Jun 14, 2018 at 2:43 PM Flemming Andreasen <[email-masked]> wrote:
> I was initially expecting the unknown key share attack to be about what the document refers to as Session Concatenation (in Section 5), however the attack overview in Section 2.1 describes two other attack scenarios instead. I think it would be helpful to be clear on all the attack scenarios up front.
>
> Secondly, I find it very difficult to follow the "two concurrent calls" attack scenario described. The overview is very high-level and the example in Section 2.3 omits too many details for me to fully understand the attack (there seems to be more going on between Mallory and Patsy than explained in the text and there are subtleties around what Mallory actually does with the respective SIP, DTLS and media packets for each session that are not entirely clear to me). Without a solid understanding of the attack, it is difficult to determine if the proposed solution truly mitigates it (I was in fact wondering about how the solution would work with session concatenation in the absence of somehow securely associating the session identifier with a particular SIP signaling session, which the document gets more into later in Section 5).
>
> A similar concern applies to the WebRTC use case, since I'm not familiar with the details of how that works, and hence would benefit from more details.
>
> On that note, there are solution elements here that span TLS/DTLS, SDP, and WebRTC/RTCWeb, and we should ensure those groups review the document as well. Have the authors circulated the document in those groups ?
>
> Thanks
>
> We have not seen any discussion on the list for this draft since it was submitted late January 2018. Please consider reviewing and commenting if you have interest in progressing the draft. It is a short document (only 13 pages in total).
>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 15 Jun 2018 14:10:58 -0400

> tweaked the wording in a few places.
Ok
> Maybe we can discuss how this works and maybe we can figure out how to
Sounds good - assuming you are in Montreal, maybe we can discuss further 
in person there.

> for the related working groups to have a look.
That would be great, since I do think we will need to hear from those 
groups as well (speaking with my chair hat on on this last point).

-- Flemming

> .

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Jun 2018 23:07:36 -0400

(My previous comments were limited to the request for discussion, and
the Abstract.  My comments were hastily written, but that's probably OK,
since the Abstract should be clear even if read hastily and without the
body of document ...)

My first look at the body of sdp-uks left me wondering exactly what the
problem is that this is defending against.  From a telephony point of
view, if the SDP peer sends me a fingerprint for establishing TLS, and I
establish a TLS session that matches the fingerprint, then clearly I am
communicating with the entity that the peer intended me to communicate
with.  To the degree I trust that I know the identity of the SDP peer, I
can trust the media session.

This logic shows up most clearly in 3PCC, when (from the point of view
of a non-executing UA) the SDP peer isn't the RTP peer; the 3PCC
controller is, effectively, authenticating each of the RTP peers to each
other by passing through their certificate fingerprints.

My guess is that the problem arises when the entity can independently
verify that the SDP peer has presented the fingerprint of a certificate
for EXAMPLE.COM, and the entity then establishes a TLS session whose
peer presents that certificate, and the entity then incorrectly
concludes that the *SDP* peer must be EXAMPLE.COM, because hey they
could arrange for a TLS session with an EXAMPLE.COM peer!

Looking again, I see this sentence in section 2.1:

   The attacker can
   arrange for the victim to incorrectly believe that is calling the
   attacker when it is in fact calling a second party.

This is subtly incorrect -- the victim doesn't *incorrectly* believe that
it is *calling* the attacker, because it *is* calling -- has a SIP
dialog with -- the attacker.  And the victim doesn't really incorrectly
believe that the media session is "with" the attacker, because (like
every SIP session), it has a media session with the media endpoint that
the SIP peer directed it to.

So, I think you're going to need to revise sectons 1 and 2 to clarify
what security assertion is getting violated in this situation -- it
seems that some people consider security assertions to be included that
I do not.

Dale