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

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Jul 2018 17:34:26 +1000

Thanks for the comments Dale, they helped clarify things a lot.

On Thu, Jun 21, 2018 at 1:07 PM Dale R. Worley <[email-masked]> wrote:
> (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 ...)

Yep, that's perfectly OK :)

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

Ahh, the 3PCC bugaboo continues to make everything worse :/

So yeah, the attack this describes and 3PCC are strangely
indistinguishable.  You are right that the controller can connect
arbitrary nodes, and that's what we understand as a feature when we
talk about 3PCC.

The (missing) assumption here is that there is often an assumed
identity for signaling that is assumed to also transfer to the media.
The assumption that a=fingerprint provides this is very common,
especially for people who are not so familiar with the ins and outs of
the actual guarantees the protocols provide.  Sadly, I was one of
these people, and we built the WebRTC identity system to rely on this
bad assumption.  That 3PCC sits neatly in this gap is something I find
interesting.

The main difference between the described attack and 3PCC, if my
understanding of 3PCC is correct, is that under 3PCC, the endpoints
are aware of the use of 3PCC.  That is, the controller makes no effort
to deceive the ultimate endpoints of the media session.  As long as
that holds and endpoints can be involved, the proposed mechanism can
still help.  Endpoints can use the TLS extension to bind media to
signaling.  For someone who does not expect 3PCC, the proposed defense
is mostly effective; for someone who is, the defense doesn't make
things worse other than maybe presenting a modest deployment
challenge.  That is, there is no expectation that the defense prevent
3PCC, just to prevent any mismatch between signaling and media in the
simple case.

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

Yes, that is one attack.

More seriously, the holder of EXAMPLE.COM can use the WebRTC identity
system to bestow their identity on any other entity.  That could
definitely be clearer in the draft.

The analogous attack might be EXAMPLE.COM getting a certificate from a
CA for use in HTTPS.  That certificate could cover the public key of
OTHER.EXAMPLE.  HTTPS isn't vulnerable to this because it carries the
identity in the handshake through the certificate itself and
OTHER.EXAMPLE wouldn't offer the EXAMPLE.COM certificate.  The draft
describes the same basic defense here.

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

I see where you are coming from.  I think that's a reasonable request.
No guarantee that you will see a draft before the cutoff, but I've
opened issues to track these points.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Jul 2018 06:16:39 +0000

Hi,

...

>The (missing) assumption here is that there is often an assumed identity for signaling that >assumed to also transfer to the media.
>The assumption that a=fingerprint provides this is very common, especially for people who >are not so familiar with the ins and outs of the actual guarantees the protocols provide.  >Sadly, I was one of these people, and we built the WebRTC identity system to rely on this bad >assumption.

In what way does the identity system rely on that assumption?

The reason I ask is to figure out whether some of this also apply to the SDP identity attribute.

>The main difference between the described attack and 3PCC, if my understanding of 3PCC is >correct, is that under 3PCC, the endpoints are aware of the use of 3PCC.

I am not sure we can make such assumption. The calling party may know that it is calling a controller, but whoever receives a call from the controller may not know.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Jul 2018 16:19:21 +1000

> I am not sure we can make such assumption. The calling party may know that it is calling a controller, but whoever receives a call from the controller may not know.

That being the case, 3PCC and attacks are indistinguishable.  We might
recommend against using this with 3PCC in that case (or, as I might
then prefer, recommend against 3PCC because it cannot be effectively
secured...)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Jul 2018 12:17:12 +0000

Hi,

>>> The main difference between the described attack and 3PCC, if my understanding of 3PCC is 
>>> correct, is that under 3PCC, the endpoints are aware of the use of 3PCC.
>>
>> I am not sure we can make such assumption. The calling party may know that it is calling a controller, 
>> but whoever receives a call from the controller may not know.
>
> That being the case, 3PCC and attacks are indistinguishable.  We might recommend against using this with 
> 3PCC in that case (or, as I might then prefer, recommend against 3PCC because it cannot be effectively
> secured...)

As we know, and as you also indicated earlier, 3PCC is causing problems all over. I don't think we can make it go away, but I wonder whether it somehow could be fixed...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 3 Jul 2018 10:38:18 -0400

>> I am not sure we can make such assumption. The calling party may know that it is calling a controller, but whoever receives a call from the controller may not know.

I think in many cases a person operating at least one of the endpoints 
is aware this is a 3pcc call, but the software controlling the endpoints 
is probably not aware.

For instance, in the click-to-dial case, the person clicking expects his 
phone to be called to join this call. And the callee is probably a call 
center that is integrated with the web site offering the click-to-dial.

In principle we could invent something new to put into the signaling for 
3pcc cases to indicate that this is a 3pcc call. Would there be any 
value to that?

> then prefer, recommend against 3PCC because it cannot be effectively

It is an important feature to give up. When security causes a reduction 
in functionality it is often the security that is given up.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jul 2018 10:39:39 +1000

> in functionality it is often the security that is given up.

Unfortunately, it's still a choice (people could choose not to deploy
this mitigation because they are too attached to 3PCC).  However, I
think that is fine, but this document doesn't need to do anything
other than mention its effect on 3PCC.  I've had an attempt at that
here:

https://github.com/martinthomson/sdp-uks/pull/4

This also attempts to make the identity-related aspects of this
clearer.  But, as the draft already said:

When the identity of communicating peers is established by higher-layer
signaling constructs, such as those in SIP {{?RFC4474}} or WebRTC
{{!WEBRTC-SEC}}, this allows an attacker to bind their own identity to a session
with any other entity.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 04 Jul 2018 16:37:04 -0400

> Thanks for the comments Dale, they helped clarify things a lot.

I'm sure that I don't grasp the essence of the problem that sdp-uks is
addressing.  I'm certainly no expert in SIP security/identity/etc.  But
let me retell an example I used maybe 10 years ago to show that the
concept of "identity" is complicated:

    Suppose I know Muhammad Chang(*), who is the loan officer at my bank
    who handles a loan I have with the bank.

    I call his number at the bank on my telephone.

    If I want to talk to *him*, the phone call doesn't ensure that I will
    talk to him, because he might be out or busy and the call might be
    routed to another bank employee.  So I have to wait until someone
    answers and identify him by voice.  (end-to-end authentication system!)

    If I want to talk to *my loan officer at the bank*, I can trust that
    whoever I am connected works for the bank, and as such is authorized
    to speak on behalf of the bank.  (I think the legal term is "is an
    agent of the bank".)  That is, the fact that I called the bank's
    number authenticates that I've reached the bank's PBX.  Since the
    bank's PBX is controlled by the bank, it is authenticating whoever
    it puts me in touch with as an agent of the bank.

    Note that if I call Muhammad Chang at his home number, while I am
    assured of talking to *him*, I am not assured that he still works at
    the bank and is authorized to do business on the bank's behalf.

    (*) Muhammad Chang is my choice for "null name":
    The most common given name in the world is Mohammad;
    the most common family name in the world is Chang.
    Can you imagine the enormous number of people in the
    world named Mohammad Chang?		-- Derek Wills

> identity for signaling that is assumed to also transfer to the media.

I guess what I'm not grasping is what the "identity for the media" *is*,
if it is not "some media source provided by the SIP UA that I exchanged
SDP with".  Because a=fingerprint does provide that authentication, and
prevents substitution of another media source than the one that the peer
UA intended.

In principle, a UA could connect me with a media source provided by
unknown persons.  But it would never want to do that, any more than I
would want to write my signature on a blank piece of paper, scatter it
in public, and then later say "I didn't write the text on that paper
above my signature."

> are aware of the use of 3PCC.

Of course, the "executing UA" has to be aware of 3PCC, but there is no
certain way for the other two UAs to be aware of it, and no need for
them to be.

> definitely be clearer in the draft.

OK, but why would it want to, unless there was a suitable trust
relationship in advance?  (Not that I understand the WebRTC identity
system.)

Dale