Subject: [Perc] Additional security requirements for PERC

From: John Mattsson <[email-masked]>
Date: Wed, 14 Oct 2015 13:35:37 +0200

During the last IETF meeting and at the design team meetings, several
new attacks and security related requirements have been identified and
discussed. Below is a list of requirements I have collected and that I
think should be fulfilled by PERC:

- The e2e replay protection MUST be provided for the whole duration of
the conference.

- It SHALL be infeasible for the MDD to spoof the identity of a packet
sender, including making packets from two different sending endpoints
look like they originated from a single sending endpoint.

- The solution SHALL make it possible for a receiving endpoint to
detect if the MDD delays packets for significantly longer than the
network delay.

- The MDD MUST authenticate and authorize the endpoints joining the
conference, ensuring that the endpoint has been invited to the
conference.

- Endpoint joining the conference MUST authenticate the MDD.

- The e2e layer SHALL NOT be dependent on the hbh layer. It shall in
the future be possible to use e.g. hbh DTLS for increased
confidentiality and privacy.

- The service provider shall be able to enforce end-to-end security
using a specific key.

- The end-to-end keying material shall stored securely in the endpoint
and usage restricted so that it is infeasible to extracted or used the
key for anything else that EKT.

If agreeable, I suggest adding the above requirements to
draft-jones-perc-private-media-reqts.

Cheers,
John

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Oct 2015 06:04:51 -0700

> look like they originated from a single sending endpoint.

I assume you mean without collusion from one of the senders?

> conference, ensuring that the endpoint has been invited to the

I'm not convinced that this is a necessary requirement as stated. Someone
must, yes, but maybe not the MDD. Why is that needed?

-Ekr

> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Oct 2015 10:33:18 -0400

> must, yes, but maybe not the MDD. Why is that needed?

+1

That is an architecture statement, not requirements.

I don't want a trusted MDD. If you have to trust the service you haven't
got end-to-end by definition.

Each conference is set up by someone. Call them the administrator. Someone
wants to join, give them a key from the administrator machine. If the
administrator leaves, rekey to a new administrator.

If you want to have a standing chat room, there are techniques that allow
for multiparty key agreement based on a predetermined list of participants
set by an administrator. See Matt Blaze's proxy re-encryption.

-PHB

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Oct 2015 10:57:53 -0400

> got end-to-end by definition.

Surely you must trust it to *some* extent. In particular you trust it to 
allow the intended participants to connect, and to do the switching 
according to the policy you give it.

The issue is to properly divide up the responsibilities and trust in a 
reasonable way.

	Thanks,
	Paul

---

From: John Mattsson <[email-masked]>
Date: Wed, 14 Oct 2015 18:04:52 +0200

Another requirement that should be discussed and concluded upon is the
wish to have the KMF integrated in one of the endpoints (e.g. a WebRTC
browser). As this may have large impacts on the protocol used to the
KMF, it would be good to get an agreement early as well as listing any
consequences.

>I assume you mean without collusion from one of the senders?'

Yes. The agreement during the last design meeting was to use SSRC as
the e2e cryptographic identity. If the MDD in any can affect the SSRC
assignment, it can cause SSRC collision. Such collision would likely
enable the MDD to mix packets from different senders, making it look
like they originated from a single sender.

>must, yes, but maybe not the MDD. Why is that needed?

The attack would be an DoS attack where an external endpoint (not
invited) joins the conference and starts sending RTP packets with the
audio level RTP header saying "I AM SCREAMING". It the MDD is only
forwarding one audio stream, this would completely silence the
conference. I do not find it acceptable that anybody (even off-path)
so easily can perform an DoS attack.

The authentication protocol could be run by the party controlling the
KMF, is this what you mean? Improved text:
"Endpoints connecting to the MDD MUST be authenticated and authorized,
ensuring that the endpoint has been invited to the conference by a
trusted party."

Cheers,
John

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Oct 2015 09:08:36 -0700

On Wed, Oct 14, 2015 at 9:04 AM, John Mattsson <[email-masked]>
wrote:

> browser).

Yes, I think this is a requirement.

> like they originated from a single sender.

Right, but my point is that absent signature, you can't stop them if they
collude
with any user.

> audio level RTP header saying "I AM SCREAMING".

How does it get the keys to do that. Is that what you mean by "authorized"?

-Ekr

> It the MDD is only

---

From: John Mattsson <[email-masked]>
Date: Wed, 14 Oct 2015 18:09:42 +0200

>Surely you must trust it to *some* extent. In particular you trust it to allow the intended participants >to connect, and to do the switching according to the policy you give it.

>The issue is to properly divide up the responsibilities and trust in a reasonable way.

+1

On Wed, Oct 14, 2015 at 6:08 PM, John Mattsson <[email-masked]> wrote:
> Paul Kyzivat wrote:
>>Surely you must trust it to *some* extent. In particular you trust it to allow the intended participants >to connect, and to do the switching according to the policy you give it.
>
>>The issue is to properly divide up the responsibilities and trust in a reasonable way.
>
> +1
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Oct 2015 12:44:58 -0400

On 10/14/15 12:08 PM, Eric Rescorla wrote:
>
>
> On Wed, Oct 14, 2015 at 9:04 AM, John Mattsson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Right, but my point is that absent signature, you can't stop them if
> they collude
> with any user.

Do you mean that if the MDD collaborates with a user then it can 
impersonate *that* user?

I don't see that as a problem. In that case the MDD is acting properly 
as an agent of the user, just as the user's own UA is.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Oct 2015 10:04:11 -0700

> Do you mean that if the MDD collaborates with a user then it can

No. I mean that if the MDD collaborates as a user, it can impersonate any
user.

-Ekr

I don't see that as a problem. In that case the MDD is acting properly as
> an agent of the user, just as the user's own UA is.
>
>
>         Thanks,
>         Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Oct 2015 13:53:06 -0400

On 10/14/15 1:04 PM, Eric Rescorla wrote:

> No. I mean that if the MDD collaborates as a user, it can impersonate
> any user.

That is unfortunate! (It seems like a highly plausible scenario - that 
the operator of the MDD could arrange to get permitted to participate.) 
I don't understand how that works. If that is possible, doesn't it also 
mean than any user can impersonate any other user?

	Thanks,
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Oct 2015 20:06:40 +0200

> mean than any user can impersonate any other user?

Yes, that is downside of having to work with group keys. If I remember 
correctly it was EKR that brought up that with the improvements in 
processing and in crypto it is now feasible to provide identity 
signatures on RTP packet level, but there is of course overhead.

The security of the conference really hinges on that you perform secure 
authorization when handling out the EKT master key. However we already 
now know we will have multiple models for this.

One need the adhoc WebRTC conference to work, where everyone may only 
have a secret token as proof or rights to join.

We want to have cases where users have identities they can assert to be 
checked against a participant roster.

There are going to be differences here. But the actual security 
properties will depend on who you give the master key to.

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: Eric Rescorla <[email-masked]>
Date: Wed, 14 Oct 2015 11:40:15 -0700

On Wed, Oct 14, 2015 at 10:53 AM, Paul Kyzivat <[email-masked]>
wrote:

> That is unfortunate! (It seems like a highly plausible scenario - that the
> operator of the MDD could arrange to get permitted to participate.)

I thought it was common knowledge that this was a property of symmetric-key
systems.

> I don't understand how that works.

Because integrity is provided by MACs, in order to verify your message, I
also need to be able to generate a valid message. I therefore construct
a message with your identity (SSRC) in it and send it to the MDD who
forwards it.

If that is possible, doesn't it also mean than any user can impersonate any
> other user?

If the MDD has hop-by-hop authentication it can filter out messages with
bogus claimed identities. If not, then yes, this attack is possible.

-Ekr

        Thanks,

---

From: "Roni Even" <[email-masked]>
Date: Thu, 15 Oct 2015 17:39:05 +0300

On 10/14/15 10:33 AM, Phillip Hallam-Baker wrote:

> I don't want a trusted MDD. If you have to trust the service you 
> haven't got end-to-end by definition.

Roni: The MDD does not connect users, it is a media layer distribution point
using some policy from a conference management entity that should be trusted
to some extent, I feel that this part of the solution architecture is not
specified also in Paul Jones framework document.

	Thanks,
	Paul

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Fri, 16 Oct 2015 18:05:36 +0000

> look like they originated from a single sending endpoint.

What "identity" of the packet sender do you mean?

> detect if the MDD delays packets for significantly longer than the

By "significantly longer" you mean on the order of minutes or hours later?

> conference, ensuring that the endpoint has been invited to the

Per our charter, and language used in the requirements too, the MDD is NOT TRUSTED with private info / media.  The MDD an enterprise might be renting would not be trusted with knowing that John Camber's endpoint was invited/authorized to conference with Hans Vestberg's endpoint (nor can it have the keys to learn they were indeed talking about you, John).  

I agree with EKR and others that should NOT be a requirement as written.   Was this really about authenticating the packets or?

> - The service provider shall be able to enforce end-to-end security

"Service Provider" ?

> key for anything else that EKT.

While that's the correct goal as an implementer, I don't think we can assure or verify the tamper-or-theft-of-keys-resistance of an endpoint via our output here in PERC.    Is this better worded as a design criteria for PERC ... that we would avoid picking tech or approaches deemed or known to be vulnerable to theft of keying material?

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Oct 2015 23:27:37 +0300

> conference, ensuring that the endpoint has been invited to the 

Per our charter, and language used in the requirements too, the MDD is NOT
TRUSTED with private info / media.  The MDD an enterprise might be renting
would not be trusted with knowing that John Camber's endpoint was
invited/authorized to conference with Hans Vestberg's endpoint (nor can it
have the keys to learn they were indeed talking about you, John).  

I agree with EKR and others that should NOT be a requirement as written.
Was this really about authenticating the packets or?

Roni: I agree that this is not for the MDD but the KMF must provide the end
to end keys only to authorized users.  What is missing here is a
decomposition of an MCU to MDD and conference manager who manage the
conference roster and should have an interface with the KMF

---

From: John Mattsson <[email-masked]>
Date: Sat, 17 Oct 2015 08:56:07 +0200

>Was this really about authenticating the packets or?

David, you are the one talking about private info. Authentication is
about verifying claims (see for example RFC4949), the claims in this
case would be ”I am conference endpoint X” or maybe even “I am a
member in the group of invited conference endpoints”.

The ONLY thing I want is to mitigate the attack I described to EKR,
let me completely reformulate the suggested requirement to:
“The MDD SHALL not forward media from third parties.”

>conference roster and should have an interface with the KMF

Agree with you Roni, the group should agree on some common
architecture and terminology for the involved nodes. The abbreviations
MKF for the trusted key-management function and MDD for the
(semi-trusted / untrusted) Media distribution device seems to have
become established. Would MCU be the correct term for the
(semi-trusted / untrusted) conference manager?

---

From: John Mattsson <[email-masked]>
Date: Sun, 18 Oct 2015 08:56:02 +0200

Thanks David, good comments.

>What "identity" of the packet sender do you mean?

The unique e2e identity, the last design meeting decided the unique
e2e identity should be SSRC (but SSRC is not a good term to use as it
is also a RTP field that will be changed by some MDDs)

>By "significantly longer" you mean on the order of minutes or hours later?

The shorter the better. But I don’t have any answer on what can be
achieved. But only detecting delays of several hours would probably
not have that much value.

>"Service Provider" ?

Service provider was the term we used in
draft-westerlund-perc-webrtc-use-cases. Agree that service provider is
vague without a definition.

What about “The solution SHALL enforce end-end security using a specific key”.

What I want to state is that the trusted party controlling the
conference must be able to enforce this. With today’s mechanisms, it
is easy to see solutions where the semi-trusted parties could
influence the protection to ordinary hbh protection or e2e protection
using a different e2e key.

>While that's the correct goal as an implementer, I don't think we can assure or verify the tamper-
>or-theft-of-keys-resistance of an endpoint via our output here in PERC.    Is this better worded as
>a design criteria for PERC ... that we would avoid picking tech or approaches deemed or known
>to be vulnerable to theft of keying material?

Most key storage technologies are, and in this case the e2e key here
may have a longer lifetime than the DTLS PreMasterSecret. if we take a
WebRTC client, the semi-trusted parties are able to use the EKT key to
set up a peer connection, but they shall not be able to extract the
key nor use it for anything else. Letting a semi-trusted party use the
key for AES-CTR would e.g. reveal old plaintext. Most key storages
have flags controlling usage. In this case the key would need to have
the flags “not extractable” and “only ekt”. Even if the key is
delivered to the endpoint using DTLS when setting up the conference,
the key may be stored in the client with a keyID to resuse if the
endpoint lost connection and needed to reconnect.

I see now that PM-04 in draft-jones-perc-private-media-reqts is
covering some (but not all) parts of this.

PM-04:  Keys used for end-to-end encryption and authentication of RTP
payloads and other information deemed unsuitable for access
by the switching media distribution device MUST NOT be
generated by or accessible to any component that is not
trusted.

The requirement should be expanded to make clear that parties that are
not trusted must also not be able to use the end-to-end keying
material in any other way than expected.

---

From: John Mattsson <[email-masked]>
Date: Wed, 21 Oct 2015 00:06:38 +0200

Eric Rescorla wrote:

>Right, but my point is that absent signature, you can't stop them if they collude
>with any user.

Would be interesting to see when your signature based solution would
be feasible. But I think the processing and packet overhead makes in
unsuitable as the general solution. Maybe as a future extension?

With a fast algorithm like Ed25519 the processing could be acceptable
(assuming some normal bitrates) even for smartphones. The tag would be
64 bytes instead of 16 bytes and public keys would have to be
distributed. Assuming the KMF pushes out a participant list, SSRCs,
and participant <-> SSRC bindings to everybody, it could push out a
list of all the other participants fingerprints (and the MDD). If new
participants joined, the KMF would have to push out fingerprint/public
key to everybody before they could validate packets from the new
joiner.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Oct 2015 15:38:58 -0700

On Tue, Oct 20, 2015 at 3:06 PM, John Mattsson <[email-masked]>
wrote:

> be feasible.

Note, I'm not claiming that it's feasible, just that absent the signatures
you have this problem.

> But I think the processing and packet overhead makes in
> distributed.

Yep. Maybe there's some way to aggregate at the cost of increased
risk.

> Assuming the KMF pushes out a participant list, SSRCs,

Yep...

-Ekr

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 21 Oct 2015 10:17:08 +0000

John,

>ensuring that the endpoint has been invited to the conference by a

Since we have HBH auth, the MDD would fail to authenticate packets from 
a non-participant.  So, only invited participants could pull off this 
attack.  We don't have to explicitly authenticate endpoints at the MDD.  
The HBH auth should simply fail.

I guess this raises the question of how the MDD knows the HBH key.  It 
was our intent in our draft that the KMF would tell the MDD the HBH key 
for each participant.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 21 Oct 2015 10:21:40 +0000

John,

I'm OK with most of these and I've taken notes (I hope are accurate) 
where folks expressed concern on some.  But, I want to ask about one 

>look like they originated from a single sending endpoint.

The MDD could not do this unless, as EKR suggested, there is collusion 
with an endpoint.  In fact, there would have to be at least two 
endpoints colluding.  And if they are working together to present 
spoofed media, they could just as well do it at the endpoint.

I'm skeptical that this requirement is really useful.

Paul