Subject: [Perc] Impersonation

From: Emil Ivov <[email-masked]>
Date: Wed, 15 Feb 2017 02:14:40 +0000

While looking at the specs it wasn't immediately obvious to me exactly what
would prevent participant A in a PERC call to impersonate participant B by
simply sending with their SSRC. Everyone's e2e key is known to everyone
else and all the keys are symmetric.

Have I missed something or is this a known limitation that we have stated
in the docs? If so could someone please point me to the relevant place?

Thanks,
Emil

-- 
https://jitsi.org
-- 
sent from my mobile

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 14 Feb 2017 19:37:36 -0800

Presumably the MDD would check the SSRC against the endpoint address so as to avoid forgery. 

> On Feb 14, 2017, at 6:14 PM, Emil Ivov <[email-masked]> wrote:
> 
> While looking at the specs it wasn't immediately obvious to me exactly what would prevent participant A in a PERC call to impersonate participant B by simply sending with their SSRC. Everyone's e2e key is known to everyone else and all the keys are symmetric.
> 
> Have I missed something or is this a known limitation that we have stated in the docs? If so could someone please point me to the relevant place?
> 
> Thanks,
> Emil
> 
> -- 
> https://jitsi.org
> -- 
> sent from my mobile
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Emil Ivov <[email-masked]>
Date: Wed, 15 Feb 2017 04:11:08 +0000

That would be one way, yeah, but then isn't the whole idea of PERC to not
trust the mdd?

If thats all we have then we are basicaly saying: we don't trust the mdd to
not attack us, but we surely trust it to prevent others from attacking us
...

On Tue, 14 Feb 2017 at 21:37, Bernard Aboba <[email-masked]> wrote:

> While looking at the specs it wasn't immediately obvious to me exactly
> what would prevent participant A in a PERC call to impersonate participant
> B by simply sending with their SSRC. Everyone's e2e key is known to
> everyone else and all the keys are symmetric.
>
sent from my mobile

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 14 Feb 2017 21:20:04 -0800

I’m under the impression that the whole identity topic has not been solved yet for a PERC call.

The KDD knows who is who in a PERC call, based on cert fingerprints and the DTLS connections it has established with each participant.

The MDD can also identify each participant based on the hop-by-hop keys. But as you pointed out the MDD should better not be trusted to forward that information correctly.

If we really want to prevent impersonation I guess we would have to have the clients sign their e2e SRTP packets with a private key.

Best
  Nils Ohlmeier

> On Feb 14, 2017, at 18:14, Emil Ivov <[email-masked]> wrote:
> 
> https://jitsi.org <https://jitsi.org/>
> --
> sent from my mobile

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Feb 2017 22:00:43 -0800

> That would be one way, yeah, but then isn't the whole idea of PERC to not

No. It's to have confidentiality against the MDD.

> not attack us, but we surely trust it to prevent others from attacking us

No, because the limit of the attack is allowing one member of the
conference (which the MDD cannot control) to impersonate another.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 14 Feb 2017 23:54:34 -0800

Comments below.

> On Feb 14, 2017, at 20:11, Emil Ivov <[email-masked]> wrote:
> 
> That would be one way, yeah, but then isn't the whole idea of PERC to not trust the mdd?

[BA] The MDD is not to obtain the payload in cleartext. But I do not believe that the design attempts to mitigate threats from a rogue MDD or even from passive surveillance which can obtain just about everything worth knowing other than the payload contents (the meeting participant locations, the discussion leaders, the format of the meeting, the interaction dynamics, etc.)

> 
> If thats all we have then we are basicaly saying: we don't trust the mdd to not attack us, but we surely trust it to prevent others from attacking us ...
>

---

From: Roni Even <[email-masked]>
Date: Wed, 15 Feb 2017 10:25:01 +0000

Emil,
My understanding is that the MDD is “mixer” as specified in the conferencing framework for SIP RFC4353 section 4.3. It is not conference “aware”. The trust is about confidentiality of the media. The issue of knowing which SSRC belongs to each participant is not something the MDD can know. BTW: this information is available in the conference event package.
I think this is another reason to have a PERC signaling document that will discuss how conference participants know that they need to use PERC in the first place
Roni

From: Perc [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: יום ד 15 פברואר 2017 06:11
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [Perc] Impersonation

On Tue, 14 Feb 2017 at 21:37, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
Presumably the MDD would check the SSRC against the endpoint address so as to avoid forgery.

On Feb 14, 2017, at 6:14 PM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:
While looking at the specs it wasn't immediately obvious to me exactly what would prevent participant A in a PERC call to impersonate participant B by simply sending with their SSRC. Everyone's e2e key is known to everyone else and all the keys are symmetric.

Thanks,
Emil

--
https://jitsi.org
--
sent from my mobile
_______________________________________________
Perc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perc
--
sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Wed, 15 Feb 2017 11:56:06 -0600

On 2/15/17 12:00 AM, Eric Rescorla wrote:
>
>
> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     If thats all we have then we are basicaly saying: we don't trust the
>     mdd to not attack us, but we surely trust it to prevent others from
>     attacking us ...
>
>

You lost me. How do you know what the relationship is between the MDD 
and that participant and that they are not actually controlled by the 
same party?

Anyways, it is hard to argue how big of a deal this is without having a 
full implementation in mind (specifically without clearly knowing who 
owns the KD and how they operate it) but it sounds like we need to at 
least:

A) Mandate that MDDs watch out for that sort of thing (for at least the 
good-natured MDDs) and
B) Explicitly mentioning the possibility for this in Security 
Considerations.

Emil

>>         While looking at the specs it wasn't immediately obvious to me
>>         exactly what would prevent participant A in a PERC call to
>>         impersonate participant B by simply sending with their SSRC.
>>         Everyone's e2e key is known to everyone else and all the keys
>>         are symmetric.
>>
>>         Have I missed something or is this a known limitation that we
>>         have stated in the docs? If so could someone please point me
>>         to the relevant place?
>>
>>         Thanks,
>>         Emil
>>
>>         --
>>         https://jitsi.org
>>         --
>>         sent from my mobile
>>         [email-masked] <mailto:[email-masked]>
>>         <https://www.ietf.org/mailman/listinfo/perc>
>
>     --
>     sent from my mobile
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/perc>
>
>

-- 
Emil Ivov, Ph.D.                     303 Colorado Street, #1600
Chief Video Architect                Austin, TX, USA
Atlassian                            MOBILE:+1.512.420.6968
https://atlassian.com                [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Feb 2017 10:09:05 -0800

On Wed, Feb 15, 2017 at 9:56 AM, Emil Ivov <[email-masked]> wrote:

> You lost me. How do you know what the relationship is between the MDD and
> that participant and that they are not actually controlled by the same
> party?

That's largely outside the threat model here.

> full implementation in mind (specifically without clearly knowing who owns
> the KD and how they operate it) but it sounds like we need to at least:
>

Sure.

-Ekr

---

From: Roni Even <[email-masked]>
Date: Thu, 16 Feb 2017 06:22:50 +0000

Emil,
When I look at the MDD I see a decomposed entity. A application server and a media server (RFC5567). PERC MDD is only about the second entity (media server). The KDF will connect to the application server via signaling (can be part of the application server) and with the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual knowledge about the conference roster.
The MDD as a media server does not know about the participants, it only knows about which stream to receive and how to switch them.  
I think that the issue you raise about a participant using another user's SSRC can be identified by the MDD or probably by the participants through the RTCP receiver reports if they notices that wrong SSRC was used, I assume that also the attacking party will send the RTCP sender reports with the impersonating SSRC. BTW: wouldn't this cause an SSRC collision?

Roni

> -----Original Message-----
> Sent: יום ד 15 פברואר 2017 19:56
> To: Eric Rescorla
> Cc: [email-masked]; Bernard Aboba
> and that participant and that they are not actually controlled by the same
> party?
> 
> Anyways, it is hard to argue how big of a deal this is without having a full
> implementation in mind (specifically without clearly knowing who owns the
> KD and how they operate it) but it sounds like we need to at
> least:
> 
> A) Mandate that MDDs watch out for that sort of thing (for at least the good-
> natured MDDs) and
> B) Explicitly mentioning the possibility for this in Security Considerations.
> 
> Emil
> 
> >
> > -Ekr
> >
> >
> >
> >     On Tue, 14 Feb 2017 at 21:37, Bernard Aboba
> <[email-masked]
> >     <mailto:[email-masked]>> wrote:
> >

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 Feb 2017 09:49:14 -0600

Hey Roni,

On 2/16/17 12:22 AM, Roni Even wrote:
> Emil, When I look at the MDD I see a decomposed entity. A application
> server and a media server (RFC5567). PERC MDD is only about the
> second entity (media server). The KDF will connect to the application
> server via signaling (can be part of the application server) and with
> the MDD on the media path (e.g. tunneling DTLS SRTP) with no actual
> knowledge about the conference roster. The MDD as a media server does
> not know about the participants, it only knows about which stream to
> receive and how to switch them. I think that the issue you raise
> about a participant using another user's SSRC can be identified by
> the MDD

Yes, I agree, but then that weakens the promise of PERC as it makes it 
rely on servers to do the right thing.

The reason why this bothers me (and I know this is vague ... but then 
again so is PERC in many respects) is that, in an ideal world, PERC 
would provide generic clients, such as browsers, to tell their users: 
"you are safe!"

The same way browsers do with https. The same way some rich clients do 
with ZRTP.

A client/browser doesn't get to do a lot of explaining here. Basically 
any nuances beyond "you are" or "you aren't" are likely lost on users.

Relying on servers to do something, anything, in order for the 
conference to be safe, basically removes the option for a generic client 
(such as a browser) to certify a conference as safe.

That might still be just fine for a bunch of other use cases, like for 
example corporate deployments or people who just want to be able to not 
answer certain subpoenas.

I am just pointing out that in this case we don't get to have the case 
that is most relevant to generic users.

> or probably by the participants through the RTCP receiver
> reports if they notices that wrong SSRC was used, I assume that also
> the attacking party will send the RTCP sender reports with the
> impersonating SSRC. BTW: wouldn't this cause an SSRC collision?

Well ... potentially, and that's a good thought, but that still depends 
on what the MDD/SFU does. So same points apply. First we need to mandate 
what the servers have to do and second clients are now dependent on 
servers to do the right thing.

Emil

> Roni
>
>
>> -----Original Message----- From: Perc
>> [mailto:[email-masked]] On Behalf Of Emil Ivov Sent: יום ד
>> 15 פברואר 2017 19:56 To: Eric Rescorla Cc: [email-masked]; Bernard
>> Aboba Subject: Re: [Perc] Impersonation
>>
>>
>>
>>> If thats all we have then we are basicaly saying: we don't trust
>>> the mdd to not attack us, but we surely trust it to prevent
>>> others from attacking us ...
>>>
>>>
>>> No, because the limit of the attack is allowing one member of
>>> the conference (which the MDD cannot control) to impersonate
>>> another.
>>
>> You lost me. How do you know what the relationship is between the
>> MDD and that participant and that they are not actually controlled
>> by the same party?
>>
>> Anyways, it is hard to argue how big of a deal this is without
>> having a full implementation in mind (specifically without clearly
>> knowing who owns the KD and how they operate it) but it sounds like
>> we need to at least:
>>
>> A) Mandate that MDDs watch out for that sort of thing (for at least
>> the good- natured MDDs) and B) Explicitly mentioning the
>> possibility for this in Security Considerations.
>>
>> Emil
>>
>>>
>>> -Ekr
>>>
>>>
>>>
>>>> have stated in the docs? If so could someone please point me to
>>>> the relevant place?
>>>>
>>>> Thanks, Emil
>>>>
>>>> -- https://jitsi.org -- sent from my mobile
>>>> _______________________________________________ Perc mailing
>>>> list [email-masked] <mailto:[email-masked]>
>>> -- sent from my mobile
>>> _______________________________________________ Perc mailing
>>> list [email-masked] <mailto:[email-masked]>
>> -- Emil Ivov, Ph.D.                     303 Colorado Street, #1600
>> Chief Video Architect                Austin, TX, USA Atlassian
>> MOBILE:+1.512.420.6968 https://atlassian.com
>> [email-masked]
>>
>> _______________________________________________ Perc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/perc
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 07:54:32 -0800

This property has been known about from the very beginning of PERC. The
only way to deal with this AFAICT, is to digitally sign the packets (or use
TESLA). I'm pretty sure I made this point in some early meeting.

"Safe" isn't a meaningful security property. Think of PERC as rather trying
to approximate the security properties you would have if you had a giant
shared conference in which the MDD were replaced with broadcast transport.

-Ekr

On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov <[email-masked]> wrote:

> again so is PERC in many respects) is that, in an ideal world, PERC would
> provide generic clients, such as browsers, to tell their users: "you are
> safe!"
>
> A client/browser doesn't get to do a lot of explaining here. Basically any
> nuances beyond "you are" or "you aren't" are likely lost on users.
>
> Relying on servers to do something, anything, in order for the conference
> to be safe, basically removes the option for a generic client (such as a
> browser) to certify a conference as safe.
>
> Well ... potentially, and that's a good thought, but that still depends on
> what the MDD/SFU does. So same points apply. First we need to mandate what
> the servers have to do and second clients are now dependent on servers to
> do the right thing.
>
> Emil
>
>
> Roni
>>
>>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 Feb 2017 10:23:53 -0600

> TESLA). I'm pretty sure I made this point in some early meeting.

Could be, it wasn't crystal clear to me. That's fine.

> "Safe" isn't a meaningful security property.

No one is claiming that it is. (Not from a protocol design perspective).

"Safe" however is an indication that users expect from RTC clients.

> Think of PERC as rather trying

Well, if I think of it that way, then the giant full mess call
definitely seems prone to providing significantly better security
properties than what PERC is describing.

And to be clear, I don't mean to steer this thread in the direction of
rethinking PERC.

I am more interested in making sure that at least some parts of it
(such as double) can be re-used for something more ambitious.

Emil

>> the servers have to do and second clients are now dependent on servers to do
>> the right thing.
>>
>> Emil
>>
>>
>>> Roni
>>>
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 08:29:39 -0800

> properties than what PERC is describing.

Yes, a full mesh call has better security properties. I thought that was
clear.
PERC is a compromise design that is intended to have the dataflow
properties of an MCU/SFU with as good privacy properties as we can get.

> (such as double) can be re-used for something more ambitious.

Well, the design in which double is embedded basically has this property. As
noted above, you would need something other than double.

-Ekr

> would
> any
> conference
> on

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 Feb 2017 14:06:12 -0600

On 2/16/17 10:29 AM, Eric Rescorla wrote:
>
>
> On Thu, Feb 16, 2017 at 8:23 AM, Emil Ivov <[email-masked]
>     On Thu, Feb 16, 2017 at 9:54 AM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:

Didn't you just say, the goal of PERC is to approximate that?

> noted above, you would need something other than double.

I don't believe that this is a requirement that stems from the design or 
goals of PERC, but I also don't have an exact change I am ready to 
debate now, so I'd rather postpone this discussion until later.

Emil

>
> -Ekr
>
>
>
>     Emil
>
>     > -Ekr
>     >
>     >
>     > On Thu, Feb 16, 2017 at 7:49 AM, Emil Ivov <[email-masked]
>     >>>> [mailto:[email-masked] <mailto:[email-masked]>]
>     On Behalf Of Emil Ivov Sent: יום ד
>     >>>> 15 פברואר 2017 19:56 To: Eric Rescorla Cc: [email-masked]
>     <mailto:[email-masked]>; Bernard
>     >>>>> On Tue, Feb 14, 2017 at 8:11 PM, Emil Ivov
>     <[email-masked] <mailto:[email-masked]>
>     >>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>>>>
>     >>>> <[email-masked] <mailto:[email-masked]>
>     >>>>>
>     >>>>> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >>>>>
>     >>>>> On Feb 14, 2017, at 6:14 PM, Emil Ivov <[email-masked]
>     <mailto:[email-masked]>
>     >>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>>>>> <https://www.ietf.org/mailman/listinfo/perc
>     <https://www.ietf.org/mailman/listinfo/perc>>
>     >>>>>
>     >>>>>
>     >>>>> -- sent from my mobile
>     >>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >>>>> <https://www.ietf.org/mailman/listinfo/perc
>     <https://www.ietf.org/mailman/listinfo/perc>>
>     >>>>>
>     >>>>>
>     >>>>
>     >>>> MOBILE:+1.512.420.6968 <tel:%2B1.512.420.6968>
>     https://atlassian.com
>     >>>> [email-masked] <mailto:[email-masked]>
>     >>>>
>     <tel:%2B1.512.420.6968>
>     <mailto:[email-masked]>
>     >
>     >
>
>
>
>     --
>     <tel:%2B1.512.420.6968>
>     <mailto:[email-masked]>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 12:33:30 -0800

> Didn't you just say, the goal of PERC is to approximate that?

No. It's an approximation to broadcast.

-Ekr

> goals of PERC, but I also don't have an exact change I am ready to debate
> now, so I'd rather postpone this discussion until later.
>
> Emil
>
>
>> -Ekr
>>
>>
>>
>>     Emil
>>
>>     > -Ekr
>>     >
>>     >

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 16 Feb 2017 22:39:47 +0000

Emil,

The endpoint is a trusted entity in the current design.  As it's 
trusted, the assumption is Alice would not put Bob's audio into her flow 
or pretend to be Bob by misappropriating his SSRC or other information 
(e.g., CNAME).

Paul

------ Original Message ------
From: "Emil Ivov" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 2/14/2017 9:14:40 PM
Subject: [Perc] Impersonation

>what would prevent participant A in a PERC call to impersonate 
>participant B by simply sending with their SSRC. Everyone's e2e key is 
>known to everyone else and all the keys are symmetric.
>
>Have I missed something or is this a known limitation that we have 
>stated in the docs? If so could someone please point me to the relevant 
>place?
>
>Thanks,
>Emil
>
>--
>https://jitsi.org
>--
>sent from my mobile