Subject: [Perc] Review of draft-jones-perc-private-media-reqts-00

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Jul 2015 14:36:52 -0700

draft-jones-perc-private-media-reqts-00

I think this document is generally going in the right direction.

A few substantive comments below. If you have a github version, I can
send you a PR with editorial comments.

* I think it would help to be more precise about your threat model
and specifically the role of the MDD and Call Processing. Here's
how I would phrase things:

- PERC provides defense against a passive attacker at either the MDD
  and the Call Processing System, since they never come in contact
  with the keys.

- PERC prevents active attack by the MDD

- PERC allows active attack by the Call Processing System to be
  detectable to a great extent:

  - The client knows the identity (i.e., the certificate) of
    the KMF. If WebRTC identity or a valid certificate is
    used, then the client can determine whether the CPS has
    injected itself.

  - The KMF knows the number of participants in the call, but
    nothing prevents the CPS from injecting an extra participant
    since the KMF has no expectation of the caller's identities.

All this assumes the DTLS solution in
draft-jones-perc-private-media-framework, but since we know that's
achievable, it's a good goal to shoot for.

Does this sound correct to you.

* Section 7.1.2 is confusing when compared to 7.2.3.
I think that the issue is that 7.1.2 needs to be rewritten to
make clear that the guarantee is that the sending endpoint is
part of the group, not that it is a particular endpoint.

* The end of Section 6.2 should be rewritten to make clear that
while a switching MDD can do bad stuff, this shouldn't lead to
compromise of the basic comsec guarantees (i.e., forgery or
content disclosure).

* Section 7.1.5: the summary here is that addition to the group
has to be fast but removal can be slower, right? Including
retrospective removal.

* Section 7.2.2 You might mention that Tor has bad performance
properties here.

* Section 7.2.3 It's also probably worth mentioning that EC
signatures are starting to be within the plausible performance
boundaries. For example you can do about 1000 verifies/sec
(and 2000 signs/sec) with ECDSA P-256 on my Mac RetinaBook Pro
(OpenSSL).

* I am having trouble reading PM-03. Can you restate?

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 14 Jul 2015 05:30:17 +0000

Eric,

>send you a PR with editorial comments.

I don't, but I can.  However, I'll need to do that a couple of weeks 
following the IETF meeting.

But, if you send me comments in any form, I'll take them and incorporate 
them.

>     used, then the client can determine whether the CPS has

This would be true, but that is also true even if the attack is not on 
the CPS.

>     since the KMF has no expectation of the caller's identities.

Insofar as the PERC work goes, I think that is a correct statement.  
Some might build a KMF that does know endpoints and does  have access to 
a secure conference roster, but I don't think we want to force those 
requirements into PERC.

>Does this sound correct to you.

Yes, if you can also agree with my small interventions above.

>part of the group, not that it is a particular endpoint.

We might want to know that it is a particular endpoint or even a 
particular human user, and we get this by checking the client 
certificate and validating it.  However, insofar as this goal goes, I 
think that was the intent.  John Mattsson contributed this one, I think. 
  If you don't have particular suggestions for wording changes, perhaps 
he might weigh in?

>compromise of the basic comsec guarantees (i.e., forgery or

Are you suggesting we add something else or modify that last paragraph?

>has to be fast but removal can be slower, right? Including

Re-keying can take time, so I think the intent is to leave it open to 
implementations whether they want to re-key or not.  However, it was 
stated as a goal to make it possible to re-key the conference on roster 
changes.

>* Section 7.2.2 You might mention that Tor has bad performance

That's really orthogonal to the security characteristics, which are the 
focus of that. However, I'm not opposed to saying that, particularly if 
you think it helps to make a point.  What did you have in mind, exactly?

>(and 2000 signs/sec) with ECDSA P-256 on my Mac RetinaBook Pro

This is a non-goals section.  Are you suggesting we re-consider that in 
light of EC performance?

>* I am having trouble reading PM-03. Can you restate?

Perhaps you can help with the wording.  The intent was  the following 
points:
* Replay protection must be enabled at each hop so as to
   * Ensure that a received packet is intended for the recipient (e.g., 
the receiving endpoint is the correct recipient); and
   * Ensure that the packet is not a duplicated packet.

This boils down to:
  * If Bob receives a packet sent to Carol, Bob should detect it was not 
intended for him and discard it
  * If Bob receives a packet that he has already processed, he will know 
to discard it

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 09:36:23 +0200

Hi,

I reacted to this part of the discussion.

Paul E. Jones skrev den 2015-07-14 07:30:

> Insofar as the PERC work goes, I think that is a correct
> statement.  Some might build a KMF that does know endpoints and does
>   have access to a secure conference roster, but I don't think we want
> to force those requirements into PERC.

Regarding these two bullets, I think we do need to aim at the security 
level that no one that can't assert an identity towards the KMF that the 
inviter in the conference has included in the conference 
invitation/rooster can retrieve the key. That verification can't be dune 
by the CPS, it needs to be part of the KMF or a stand alone but trusted 
entity.

 From a functional perspective the conference inviter will schedule a 
conference and create a rooster with identity. At the time of joining 
the conference the participant needs to assert its identity to the KMF. 
If that is done by talking to a secure rooster server that generates 
some credentials bound to the participants endpoint, and those are used 
to assert the identity when talking to the KMF, that is an open 
question. I have a tendency to favour the second as that will reduce the 
API surface on the KMF, and separate the authorization of the 
participant to this separate function, which then can be a bit more 
flexible to integrate the various identity systems used.

I also note if we are going to solve the SHOULD level goal of preventing 
a participant prior to joining and after leaving the conference to have 
an possibility to decrypt, including retrospective, the end-to-end 
security layer, then we will be forced to go into tracking who is 
currently active participants within a trusted function, i.e. not the 
CPS. The CPS can of course be an helper, but the security can't rely on 
the CPS.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jul 2015 10:03:59 +0100

Hiya,

>     since the KMF has no expectation of the caller's identities.

I'm not sure I've got all the context here but if perc conference
calls allow properly implemented infrastructure nodes to add a
silent monitoring participant without any of the other call
participants being able to detect that then I'd say we're not
meeting the chartered goals.

Yes, some nodes involved in call setup or the call might be able to
leak keys or media but that'd be a bad implementation and not really
a protocol design issue.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2015 05:59:26 -0700

On Mon, Jul 13, 2015 at 10:30 PM, Paul E. Jones <[email-masked]>
wrote:

> This would be true, but that is also true even if the attack is not on the
> CPS.
>

Yes, but the point is that the client can't automatically reject this case
(the user has to actually know what the expected identity of the KMF is).
By contrast, if the CPS isn't attacked but some network attacker tries
to inject themselves, the fingerprint check fails.

> Insofar as the PERC work goes, I think that is a correct statement.  Some
> might build a KMF that does know endpoints and does  have access to a
> secure conference roster, but I don't think we want to force those
> requirements into PERC.
>

Yes, that's fine.

> particular human user, and we get this by checking the client certificate
> and validating it.  However, insofar as this goal goes, I think that was
> the intent.  John Mattsson contributed this one, I think.  If you don't
> have particular suggestions for wording changes, perhaps he might weigh in?
>

That's fine as far as session establishment, but once the session is
established
everyone knows the sending key for Alice and so can impersonate Alice
unless the MDD tags each message with the identity using the H2H key.
Is that the plan?

> Are you suggesting we add something else or modify that last paragraph?

Yes. I can send new text at some point.

> implementations whether they want to re-key or not.  However, it was stated
> as a goal to make it possible to re-key the conference on roster changes.
>

OK.

> focus of that. However, I'm not opposed to saying that, particularly if you
> think it helps to make a point.  What did you have in mind, exactly?
>

Well, I thought that the point here was that it was out of scope. It's out
of scope because it may not have the desired security guarantees (which
you do say) and it's slow (which you don't say).

> This is a non-goals section.  Are you suggesting we re-consider that in

Not sure. Perhaps the WG should discuss.

>   * Ensure that a received packet is intended for the recipient (e.g., the
> receiving endpoint is the correct recipient); and
>  * If Bob receives a packet that he has already processed, he will know to
> discard it
>
> Yes, this sounds like a reasonable goal. Will see if I can rewrite.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2015 06:03:51 -0700

On Tue, Jul 14, 2015 at 12:36 AM, Magnus Westerlund <
[email-masked]> wrote:

> inviter in the conference has included in the conference invitation/rooster
> can retrieve the key. That verification can't be dune by the CPS, it needs
> to be part of the KMF or a stand alone but trusted entity.
>
> conference and create a rooster with identity. At the time of joining the
> conference the participant needs to assert its identity to the KMF. If that
> is done by talking to a secure rooster server that generates some
> credentials bound to the participants endpoint, and those are used to
> assert the identity when talking to the KMF, that is an open question. I
> have a tendency to favour the second as that will reduce the API surface on
> the KMF, and separate the authorization of the participant to this separate
> function, which then can be a bit more flexible to integrate the various
> identity systems used.
>

As far as I know, standardizing the control plane communication between the
KM
and the CPS is out of scope for this effort, right? So it certainly should
be possible
that the KMF will have an independent way of knowing which identities
should be
allowed into the conference, but it's not something we are required to
design.
And there are certainly valid designs where you don't provide this.

> I also note if we are going to solve the SHOULD level goal of preventing a
> participant prior to joining and after leaving the conference to have an
> possibility to decrypt, including retrospective, the end-to-end security
> layer, then we will be forced to go into tracking who is currently active
> participants within a trusted function, i.e. not the CPS. The CPS can of
> course be an helper, but the security can't rely on the CPS
>

See above.

-Ekr

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 18:51:46 +0200

> meeting the chartered goals.

The MDD can always forward copies of the end-to-end protected media to a 
recording device or store it locally. But, the E2E encryption is there 
to protect the confidentiality.

The whole issue resides around ensuring that only invited participants 
are getting access to the E2E keying material.

Cheers

Magnus Westerlund

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Tue, 14 Jul 2015 17:28:33 +0000

Magnus beat me to the reply, so I'll just pile on to say that this is actually an excellent case in which to claim victory eventually.   

In other words, we should assume an admin turned bad actor can and will, as they can today, configure an MDD not in the trusted domain (cloud conf provider or IaaS, etc) to send copies of all your conf's packets to another participant (eg, a capture device) without the rest of the legitimate participants knowing.   PERC will preserve the privacy of the media content despite such eavesdropping capture as the KMS would not provide E2E key material to that device.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, July 14, 2015 9:52 AM
> To: Stephen Farrell; Eric Rescorla; [email-masked]; draft-jones-perc-private-
> [email-masked]
> Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 20:12:20 +0200

Eric Rescorla skrev den 2015-07-14 15:03:
>
>
> On Tue, Jul 14, 2015 at 12:36 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>

>     Regarding these two bullets, I think we do need to aim at the
>     security level that no one that can't assert an identity towards the
>     KMF that the inviter in the conference has included in the
>     conference invitation/rooster can retrieve the key. That
>     verification can't be dune by the CPS, it needs to be part of the
>     KMF or a stand alone but trusted entity.
>
>      >From a functional perspective the conference inviter will schedule
>     a conference and create a rooster with identity. At the time of
>     joining the conference the participant needs to assert its identity
>     to the KMF. If that is done by talking to a secure rooster server
>     that generates some credentials bound to the participants endpoint,
>     and those are used to assert the identity when talking to the KMF,
>     that is an open question. I have a tendency to favour the second as
>     that will reduce the API surface on the KMF, and separate the
>     authorization of the participant to this separate function, which
>     then can be a bit more flexible to integrate the various identity
>     systems used.
>
>
> As far as I know, standardizing the control plane communication between
> the KM
> and the CPS is out of scope for this effort, right? So it certainly
> should be possible

Even if something is out of scope for standardizing it may not be out of 
scope to put requirement on the need for a particular functionality.

My main point is that the system as a whole need to ensure that only 
intended participants is capable of joining a particular conference. 
That we do need a solution for!

You might have additional ideas for this, but I have so far only thought 
of two ways of doing it. The first alternative is to provided the 
invited party with a secret. However that requires that you can safely 
distribute it to the invited party, and likely require them to store it 
confidential until the participant selects to join the conference. 
Something that is fairly difficult and vulnerable.
The second alternative is that the invited need to assert an identity 
toward the trusted part of the system. If that assertion is accepted 
then one give the participant's endpoint access to the conference group 
key.

And I have only semi trust in CPS and MDD. I only trust it as far as not 
preventing my conference from working, but I will not give it any way of 
compromising the confidentiality of the media content. It can clearly 
affect the view a particular conference

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2015 11:14:37 -0700

On Tue, Jul 14, 2015 at 11:12 AM, Magnus Westerlund <
[email-masked]> wrote:

> intended participants is capable of joining a particular conference. That
> we do need a solution for!
>

I don't think that's precisely true. I would say rather that it must be
possible to
implement a system that way.

You might have additional ideas for this, but I have so far only thought of
> two ways of doing it. The first alternative is to provided the invited
> party with a secret. However that requires that you can safely distribute
> it to the invited party, and likely require them to store it confidential
> until the participant selects to join the conference. Something that is
> fairly difficult and vulnerable.
> toward the trusted part of the system. If that assertion is accepted then
> one give the participant's endpoint access to the conference group key.
>

The second is the natural design, since you can use existing public key
identity mechanisms
for it.

-Ekr

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 18 Jul 2015 04:13:41 +0000

Eric,

Other text I think we're in agreement on (and need to work on).

I did want to respond to your one question.

There will be a HBH key that is shared between Alice and the MDD.  The 
intent is that the MDD will process the SRTP packets and check for the 
authentication tag created with that key that is known only to Alice and 
the MDD (and the KMF, but we trust it).  The MDD will reject any packet 
that is authenticated with Alice's key and purportedly coming from 
Alice.

When the MDD forwards media, it will re-authenticate the packet using 
the shared key between itself and Bob (or Carol or ...).  Each hop will 
receive a copy of Alice's packet, each hop being authenticated with that 
hop's key.

However, there is no particular identifying information that we've 
proposed to put into Alice's packet so that Bob would know that was 
originally sourced from Alice.  All Bob would know is that an apparently 
valid packet is received from the MDD.  The endpoint will also check to 
ensure that any received EKT tag is not corrupted and it will verify 
that the encrypted payload authenticates with the key associated with 
the sender's SSRC.  Still, Bob does not know the SSRC belongs to Alice 
or anyone else, is no other identifying info in the packet.  And I think 
that's OK.  We can prevent packet packets coming in from untrusted 
entities, but we're not trying to prevent a trusted endpoint from being 
malicious.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 18 Jul 2015 04:18:10 +0000

Magnus,

I think we agree on the security requirements.  I only meant that some 
systems may not maintain a roster of who is presently in a conference.  
It would certainly have a list of who is allowed to be in the 
conference.

Paul

------ Original Message ------
From: "Magnus Westerlund" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "Eric Rescorla" 
<[email-masked]>; [email-masked]; 
[email-masked]
Sent: 7/14/2015 3:36:23 AM
Subject: Re: [Perc] Review of draft-jones-perc-private-media-reqts-00

>level that no one that can't assert an identity towards the KMF that 
>the inviter in the conference has included in the conference 
>invitation/rooster can retrieve the key. That verification can't be 
>dune by the CPS, it needs to be part of the KMF or a stand alone but 
>trusted entity.
>
>question. I have a tendency to favour the second as that will reduce 
>the API surface on the KMF, and separate the authorization of the 
>I also note if we are going to solve the SHOULD level goal of 
>preventing a participant prior to joining and after leaving the 
>conference to have an possibility to decrypt, including retrospective, 
>the end-to-end security layer, then we will be forced to go into 
>tracking who is currently active participants within a trusted 
>function, i.e. not the CPS. The CPS can of course be an helper, but the 
>security can't rely on the CPS.
>
>Cheers
>
>Magnus Westerlund
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Jul 2015 21:21:30 -0700

On Fri, Jul 17, 2015 at 9:13 PM, Paul E. Jones <[email-masked]>
wrote:

> that is authenticated with Alice's key and purportedly coming from Alice.
>
> When the MDD forwards media, it will re-authenticate the packet using the
> shared key between itself and Bob (or Carol or ...).  Each hop will receive
> a copy of Alice's packet, each hop being authenticated with that hop's key.
>
> ensure that any received EKT tag is not corrupted and it will verify that
> the encrypted payload authenticates with the key associated with the
> sender's SSRC.  Still, Bob does not know the SSRC belongs to Alice or
> anyone else, is no other identifying info in the packet.  And I think

So to be clear,  the endpoint recipient of a packet has no way of
determining
the sender of the packet? I don't think that's necessarily bad, but that's
ot how I read 7.1.2.

-Ekr

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 18 Jul 2015 04:26:26 +0000

Eric,

>>think that was the intent.  John Mattsson contributed this one, I 
>>think.  If you don't have particular suggestions for wording changes, 
>>perhaps he might weigh in?
>>

So to be clear,  the endpoint recipient of a packet has no way of 
determining
the sender of the packet? I don't think that's necessarily bad, but 
that's ot how I read 7.1.2.

Yes, I think that's the intent with that original text.

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jul 2015 09:28:13 +0200

Den 2015-07-18 kl. 06:18, skrev Paul E. Jones:
> It would certainly have a list of who is allowed to be in the conference.
>

Yes, for the basic security level that is all fine. But for the higher 
security level where you want to prevent participants to get to media 
prior or after having joined or left I don't see an alternative to 
maintaining a rooster.

/Magnus

>> the conference the participant needs to assert its identity to the
>> KMF. If that is done by talking to a secure rooster server that
>> generates some credentials bound to the participants endpoint, and
>> those are used to assert the identity when talking to the KMF, that is
>> an open question. I have a tendency to favour the second as that will
>> reduce the API surface on the KMF, and separate the authorization of
>> the participant to this separate function, which then can be a bit
>> more flexible to integrate the various identity systems used.
>>
>> function, i.e. not the CPS. The CPS can of course be an helper, but
>> the security can't rely on the CPS.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jul 2015 09:35:55 +0200

Den 2015-07-18 kl. 06:26, skrev Paul E. Jones:
>>     certificate and validating it.  However, insofar as this goal
>>     goes, I think that was the intent.  John Mattsson contributed this
>>     one, I think.  If you don't have particular suggestions for
>>     wording changes, perhaps he might weigh in?
>>
>>     That's fine as far as session establishment, but once the session
>>     is established
>>     There will be a HBH key that is shared between Alice and the MDD.
>>     The intent is that the MDD will process the SRTP packets and check
>>     for the authentication tag created with that key that is known
>>     only to Alice and the MDD (and the KMF, but we trust it).  The MDD
>>     will reject any packet that is authenticated with Alice's key and
>>     purportedly coming from Alice.
>>     When the MDD forwards media, it will re-authenticate the packet
>>     using the shared key between itself and Bob (or Carol or ...).
>>     Each hop will receive a copy of Alice's packet, each hop being
>>     authenticated with that hop's key.
>>     proposed to put into Alice's packet so that Bob would know that
>>     was originally sourced from Alice.  All Bob would know is that an
>>     apparently valid packet is received from the MDD.  The endpoint
>>     will also check to ensure that any received EKT tag is not
>>     corrupted and it will verify that the encrypted payload
>>     authenticates with the key associated with the sender's SSRC.
>>     Still, Bob does not know the SSRC belongs to Alice or anyone else,
>>     is no other identifying info in the packet.  And I think that's
>>     OK.  We can prevent packet packets coming in from untrusted
>>     entities, but we're not trying to prevent a trusted endpoint from
>>     being malicious.
>>
>>

My view is that we need a way to at least reference who the original 
sender is. I am fine with this information only being protected to the 
level of that it is one among the participants that provided this. At 
the same time I expect that this can be used such that it is not 
revealing the peers identity to another peer, i.e. there need to be a 
configuration/usage option.

Cheers

Magnus Westerlund