Subject: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Tue, 14 May 2019 14:15:29 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-perc-private-media-framework-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Its is good to see that this document has continued to improve since I read the
early versions. However, there are some one issues we do need to discuss if
they should be better handled before this document is ready for publication.

A significant security vunerability in PERC that should be made more explicit
and is totally missing is the risks with compromised endpoints. Beyond the very
evident thing that this endpoint can decrypt all media it receives there are
far more sinister risk here. Namely the potential for injection of media that
attempts to impersonate another endpoints media stream. Most of SRTP's cipher
suits only use symmetric crypto functions, thus enabling anyone with the key to
send a packet with any SSRC, and have that being accepted as that source. Where
it is has no practical usage in point to point communication, in conferencing
it becomes an issue. It allows the usage of media level replay or deep fakes to
be used to create media streams that are injected into the media distributors
using an SSRC of another endpoint.

The mitiagations that are missing from this document. The fact that a media
distributor that is not compromised or collaborating with the compromised
endpoint could actually prevent such media injection by applying source
filtering of SSRCs and drop all that aren't associated with the endpoint. The
other potential mitigation is to introduce another cipher suit that uses a non
symmetric integrity protection mechanism, such as TESLA to prevent this type of
injection.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In addition I would appreciate if you really consider these issues, especially
A and B.

A. I think the relationship between the media distributors and the key
distributor needs to be clarified either already in section 3 or in 4. The fact
that the key distributor needs to know the full set or their group identity of
the media distributors to prevent impostering media distributors. That need is
not made clear early enough, only by the end of the security consideration
section is is made clear that this is the fact. I think it should be stated
explicitly early on.

B. Similar the endpoints relation to the key distributor also needs to be
clarified. Also, here diving into potential solutions in Section 5 without
making clear why this very fundamental requirement is needed is far from
optimal. Also here I think discussion in Section 3 or 4 would be good of their
relationship. Especially as this is really relying on mechanism outside of the
PERC framework. Thus, such requirements should be very explicit stated and
motivated.

C. Section 4.3:

If there is a need to encrypt one or more RTP header extensions end-
   to-end, the endpoint derives an encryption key from the E2E SRTP
   master key to encrypt header extensions as per [RFC6904].  The Media
   Distributor is unable use the information contained in those header
   extensions encrypted with an E2E key.

As RFC 6904 works on type of header extensions, all header extensions of
that type need to be encrypted independent of sender, that could be made
clearer.

D. Section 4.5:

   o  The E2E key that an endpoint uses to send SRTP media can either be
      set from DTLS or chosen by the endpoint.

          I think "set from DTLS" should be changed to make it clear that the
          DTLS is with the Key Distributor.

E. Section 4.5.1:

Wouldn't this sentence be clearer:

   Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP
   session's media ports for the purposes of key information exchange
   with the Key Distributor.

is worded like this:

   Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP
   session with the media distributor and it's media ports for the
   purposes of key information exchange with the Key Distributor.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 16 May 2019 00:21:07 -0600

> On May 14, 2019, at 3:15 PM, Magnus Westerlund via Datatracker <[email-masked]> wrote:
> 
> 

And the related issue that the main way this can happen is attacker manipulation of the fingerprint so the providing ways to protect that along with SSRC based signalling or TELSA  is the obvious solution space to this. And just to frame the discussion, let me point out the issue you raise is not so much about an SSRC but binding the identity of a member of the group to the audio received. 

As other have pointed out, which member inside the conference the media is from is not something PERC provides any information about. Many existing conference systems have existing approaches to solve this problem and they can add PERC as a tool with out breaking theses so it to be specified here. Something that used TESLA could work fine with PERC as well. I do think future work can look at what we need for rosters and active speakers and how to use things like STIR and fingerprints and SDP to tie identity to the media. However, I think that problem is fairly separable from the issue of making sure the operator of the media switch does not have access to the media content. 

But just to explore what solutions could be build on top of PERC to solve this, let me cary on. 

Early on the WG did consider one an Ericssons proposal that used SSRC based signalling for many things but the WG moved away from that at least partially over concerns of Ericsson IPR in this space. In trying to refresh some of the state on possible solutions to this I came across. 

https://patentimages.storage.googleapis.com/07/b2/6a/f34fd49f38a5a4/US20180205720A1.pdf

which has the following claim 

39) A method for a server for enabling setting up a secure peer - to - peer connection between a first peer and a second peer , wherein at least one of the first peer and the second peer is a web browser , the method comprising : receiving a request for a web application from the first peer ; sending a directive to the first peer requesting a fingerprint of a certificate of the first peer ; receiving a first fingerprint from the first peer ; and sending the first fingerprint to the second peer .

So just to make sure I understand this, if we have a case where a webapp sends an SDP offer that goes to the first peer, this requests the certificate and of the first peer and sends it in the SDP answer to the webapp that then sends that answer on to the second peer. It seems this claim surely covers a bunch stuff we are doing in WebRTC as well as PERC and needs to be disclosed. You agree ?

One thing that would work well is an approach like the CSP protection in the above patent mixed with the ability for the KD to bind the client to the web conference application as described in 

https://patentimages.storage.googleapis.com/d0/de/1a/5cbafd9903417b/WO2018063041A1.pdf

Actually claim 1 seems like that is pretty much perfect for solving this. Claim 1 reads 

1. A method for a server to bind a device application to a web service, wherein Web Real Time Control, WebRTC, functionality is provided to the server, the method comprises:
-receiving a request for the web service from the device application, wherein communication between the server and the device application is done via https and WebRTC and the device application has generated WebRTC credentials comprising a private key, certificate of the private key and a fingerprint of the certificate,
-receiving  the fingerprint and fingerprint generation algorithm of the certificate,
-storing  the fingerprint and fingerprint generation algorithm and associating the fingerprint with the device application, and
-using Datagram Transport Layer Security, DTLS, providing the certificate of the device application, in combination with the stored fingerprint to identify the device application to bind the device application to the web service.

So to walk thorough the parts of this claim. When a user joins the web conference that uses PERC, the request and responses for the fingerprints are send via the SDP offer and answers over HTTPS, the website learns the fingerprint for the user and then when the DTLS connection to the KD is formed, the way the KD correlates to the user to make sure they are the right one to authorize into the conference is by using that same fingerprint. Let me know if I am misunderstanding this or if a disclosure is needed. 

I think you should propose this stuff to dispatch as way to solve the problem of knowing who in a conference the media is coming from. Please let me know if I am misunderstanding theses claims and if disclosures need to be made.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 16 May 2019 06:41:10 +0000

Magnus,

Indeed, Trusted Endpoints need to be secure. There are places in the 
endpoint where an adversary could initiate an attack and it wouldn't 
require the sophistication of manipulating SSRCs, even. However, that is 
a valid attack vector. A challenge with employing a filter is that this 
could interfere with the normal SSRC collision detection logic in RTP 
stacks.

How about this as a new section?

## Endpoint Attacks

A Trusted Endpoint is so named because conference confidentiality relies
heavily on the security and integrity of the Endpoint. If an adversary
successfully exploits a vulnerability in an Endpoint, it might be 
possible
for the adversary to obtain all of the keying material used in the
conference. With that keying material, an adversary could decrypt any
of the media flows received from any other Endpoint, either in real-time
or at a later point in time (assuming the adversary makes a copy of the
media packets).

Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit to
whatever media the adversary wishes to send. This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an 
existing
endpoint.

However, attacks on the endpoint are not limited to the PERC-specific
software within the Endpoint. An attacker could inject media or record
media by manipulating the software that sits between the PERC-enabled
application and the hardware microphone of video camera, for example.
Likewise, an attacker could potentially access confidential media by
accessing memory, cache, disk storage, etc. if the endpoint is no 
secured.

I would suggest a new paragraph at the end of 3.2.2 as follows:

They Key Distributor needs to know which Endpoints and which Media
Distributors are authorized to participate in the conference.  How the
Key Distributor obtains this information is outside the scope of this
document.  However, Key Distributors **MUST** reject DTLS associations
with any unauthorized Endpoint of Media Distributor.

The relationship between these entities in terms of roster, 
certificates, identity, etc. are outside the scope of the framework.

>PERC framework. Thus, such requirements should be very explicit stated and

I think the above additional text should address this concern, too. 
However, it is probably important to keep in mind that PERC can work 
with many different types of conferences architectures and these 
associations is deliberately out scope as the PERC framework for this 
reason.

>that type need to be encrypted independent of sender, that could be made

I do not understand what you're saying here. The sender will create an 
encrypted stream and then AND that with the mask created over the header 
extensions. The mask will be over whatever extensions the sender wants 
to encrypt. There's nothing different in PERC from what is in RFC 6904.

Can you clarify what you are looking for here?

>           DTLS is with the Key Distributor.

I changed my local text to say that.

>    purposes of key information exchange with the Key Distributor.

Yep, sounds good. I changed "it's" to "its", but otherwise accepted your 
text as proposed.

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 May 2019 14:11:23 +0000

Hi Cullen,

> And the related issue that the main way this can happen is attacker manipulation of the fingerprint so the providing ways to protect that along with SSRC based signalling or TELSA  is the obvious s…

Yes, agree that the fundamental is to know which identity that create a
particular packet. How that is accomplished there are many solutions.

> As other have pointed out, which member inside the conference the media is from is not something PERC provides any information about. Many existing conference systems have existing approaches to so…

Yes, and to be clear I don't expect that base PERC solution should solve
the issue. I only requested that the security properties that exist are
made clear. 

Regarding your below questions I will reply to that separately and it
may take me a couple of days.

Cheers

Magnus

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 May 2019 14:54:28 +0000

Hi Paul,

Thanks for the rapid response. See my comments inline.

On 2019-05-16 08:41, Paul E. Jones wrote:
Magnus,

Indeed, Trusted Endpoints need to be secure. There are places in the endpoint where an adversary could initiate an attack and it wouldn't require the sophistication of manipulating SSRCs, even. However, that is a valid attack vector. A challenge with employing a filter is that this could interfere with the normal SSRC collision detection logic in RTP stacks.

## Endpoint Attacks

successfully exploits a vulnerability in an Endpoint, it might be possible

re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing
endpoint.

accessing memory, cache, disk storage, etc. if the endpoint is no secured.

I think this is mostly good, however not particular specific on the security properties of the system that the framework creates, that is dependent on the realization of the authentication tag added to the packet. So, the impersonation issue that are alluded is only possible given that there a no solution that allows specific identity assertions on a per packet basis.

Looks okay, I assume of/or.

The relationship between these entities in terms of roster, certificates, identity, etc. are outside the scope of the framework.

I think the above additional text should address this concern, too. However, it is probably important to keep in mind that PERC can work with many different types of conferences architectures and these associations is deliberately out scope as the PERC framework for this reason.

Yes, the above text do address the comment.

C. Section 4.3:

I do not understand what you're saying here. The sender will create an encrypted stream and then AND that with the mask created over the header extensions. The mask will be over whatever extensions the sender wants to encrypt. There's nothing different in PERC from what is in RFC 6904.

Yes, you are correct that this is an inherent property of RFC 6904 in that one defines on header extension ID level if it is to be encrypted or not. In the PERC situation it is not clear how one determines which should be end-to-end encrypted and which are only hop-by-hop. I think the later should normally be all header extensions. After having read double that fails to define how one performs the end-to-end encryption of header extensions I think there are more to dig into here.

So, one issue is clearly signalling that a particular type of header extensions are to be end-to-end encrypted.

D. Section 4.5:

Great!

E. Section 4.5.1:

is worded like this:

Yep, sounds good. I changed "it's" to "its", but otherwise accepted your text as proposed.

Thanks

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 16 May 2019 11:50:58 -0600

> On May 16, 2019, at 8:11 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Cullen,
> 

Yes, I agree with you that needs to be clear in the security section that PERC does not solve this. It’s a desirable property of a conferencing system so it would be bad if people expected it to be there. 

> may take me a couple of days.

No problem, I totally understand theses things take some time to sort out. Thank you for looking into it.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 17 May 2019 02:09:52 +0000

Magnus,

>>endpoint..
>I think this is mostly good, however not particular specific on the 
>security properties of the system that the framework creates, that is 
>dependent on the realization of the authentication tag added to the 
>packet. So, the impersonation issue that are alluded is only possible 
>given that there a no solution that allows specific identity assertions 
>on a per packet basis.
>

Yeah, PERC doesn't offer a defense against impersonation since there is 
no assignment of SSRC or sharing of user info or user-level auth info 
with other conference participants.  The assumption is that the 
endpoints are trusted and would not attempt to impersonate.  But, you 
made a valid point that we need to highlight that weakness.  I tried to 
make that clear by pointing out that a compromised endpoint could inject 
media in a variety of ways.

Do you have suggestions for other words or more words to clarify this?

>Looks okay, I assume of/or.

Cool, thanks... fixed that.

>Yes, the above text do address the comment.

Good.

>>encrypted stream and then AND that with the mask created over the 
>>header extensions. The mask will be over whatever extensions the 
>>sender wants to encrypt. There's nothing different in PERC from what 
>>is in RFC 6904.
>Yes, you are correct that this is an inherent property of RFC 6904 in 
>that one defines on header extension ID level if it is to be encrypted 
>or not.. In the PERC situation it is not clear how one determines which 
>should be end-to-end encrypted and which are only hop-by-hop. I think 
>the later should normally be all header extensions. After having read 
>double that fails to define how one performs the end-to-end encryption 
>of header extensions I think there are more to dig into here.
>
>So, one issue is clearly signalling that a particular type of header 
>extensions are to be end-to-end encrypted.
>

Oh, I see why there is confusion.  There are two things here and some 
erroneous residual text in the framework:

1) What is to be encrypted - that's outside the scope of PERC. Whatever 
signaling mechanism used with PERC will dictate this.

2) How is it done - the draft has an error.  Double (and therefore PERC) 
only allows HBH encryption of header extensions, but the framework still 
talks about both E2E and HBH (which was an original objective).  I've 
made some changes to clarify this.  Further, the details of how to 
encrypt/decrypt are only described in Double, so I've made a reference 
to that draft in the HBH Operations part of Framework.  (Double is still 
high level in that regard, but I think Sections 5.1 - 5.3 of Double will 
make sense now knowing that extensions are encrypted only HBH.)

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 May 2019 14:22:28 +0000

On 2019-05-17 04:10, Paul E. Jones wrote:
Magnus,

## Endpoint Attacks

Yeah, PERC doesn't offer a defense against impersonation since there is no assignment of SSRC or sharing of user info or user-level auth info with other conference participants.  The assumption is that the endpoints are trusted and would not attempt to impersonate.  But, you made a valid point that we need to highlight that weakness.  I tried to make that clear by pointing out that a compromised endpoint could inject media in a variety of ways.

Maybe if the second paragraph is somewhat expanded:

endpoint. So far only a single SRTP cipher suits defined provides source authentication properties that allow an endpoint to cryptographically assert that it sent a particular E2E protected packet. Instead, the common property is that one can determine only that any endpoint that has received the KEK has produced the packet.

C. Section 4.3:

Yes, you are correct that this is an inherent property of RFC 6904 in that one defines on header extension ID level if it is to be encrypted or not.. In the PERC situation it is not clear how one determines which should be end-to-end encrypted and which are only hop-by-hop. I think the later should normally be all header extensions. After having read double that fails to define how one performs the end-to-end encryption of header extensions I think there are more to dig into here.

Oh, I see why there is confusion.  There are two things here and some erroneous residual text in the framework:

1) What is to be encrypted - that's outside the scope of PERC. Whatever signaling mechanism used with PERC will dictate this.

>From my perspective it is up to the framework to discuss what needs to be encrypted in RTP to achieve the properties described by the framework. Actually I think it is unfortunate that PERC fails to provide E2E authentication of certain header extensions, and also end-to-end encryption. However, that is the WG's decision but I think that choice and the perils of that should be well documented.

2) How is it done - the draft has an error.  Double (and therefore PERC) only allows HBH encryption of header extensions, but the framework still talks about both E2E and HBH (which was an original objective).  I've made some changes to clarify this.  Further, the details of how to encrypt/decrypt are only described in Double, so I've made a reference to that draft in the HBH Operations part of Framework.  (Double is still high level in that regard, but I think Sections 5.1 - 5.3 of Double will make sense now knowing that extensions are encrypted only HBH.)

Double could easily support it, however it does require a signalling either inband or outband so that all end-points and the MD know which header extensions that it applies to. I think that signalling may be the bigger hurdle here, rather than double.

Anyway, the fact that there are neither possible to have E2E authentication nor encryption of header extension are potentially problematic. Looking at the available header extension several of them are of the nature that they should at least be E2E source authenticated. Those that I see no reason for an MD to change are:

urn:ietf:params:rtp-hdrext:smpte-tc SMPTE time-code mapping

urn:3gpp:video-orientation Coordination of video orientation (CVO) feature, see clause 6.2.3

urn:3gpp:video-orientation:6 Higher granularity (6-bit) coordination of video orientation (CVO) feature, see clause 6.2.3

urn:3gpp:roi-sent Signalling of the arbitrary region-of-interest (ROI) information for the sent video, see clause 6.2.3.4

urn:3gpp:predefined-roi-sent Signalling of the predefined region-of-interest (ROI) information for the sent video, see clause 6.2.3.4

These are all meta data directly associated with the media sent, can affect how it is presented at the receiver. These should be expected to be passed through a PERC system unchanged. However, the PERC proponents use case would normally not see these being used. Also I would not be surprised over future extensions with that property or at least proprietary extensions.

The set of header extensions that are related to how the endpoint bind and use the RTP Streams it receives, such as CNAME, rtp-stream-id, CaptId and mid are really hard to protect and be efficient at the same time as they are expected to be added when switching RTP streams.

Anyway I understand the choice to some degree. But I think the framework should discuss the possible need for E2E protection, and the risks of not providing it in DOUBLE.

Cheers

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 May 2019 12:24:08 -0600

> On May 17, 2019, at 8:22 AM, Magnus Westerlund <[email-masked]> wrote:
> 
>  So far only a single SRTP cipher suits defined provides source authentication properties that allow an endpoint to cryptographically assert that it sent a particular E2E protected packet. Instead, the common property is that one can determine only that any endpoint that has received the KEK has produced the packet.

Magnus, I’m just a bit confused on what the above two senses are trying to say - can you just expand it out a bit more so I get it. I think I am struggling with what cipher you refer to in the first sentense.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 May 2019 07:10:17 +0000

On 2019-05-17 20:24, Cullen Jennings wrote:

On May 17, 2019, at 8:22 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

The single SRTP cipher suit that exists that provides any stronger source authentication property than, one of those that have the key has generated this message, is to my knowledge TESLA (RFC  4383).

Let me cite one paragraph from Section 3.1 of RFC 7201:

   The source authentication guarantees provided by SRTP depend on the
   cryptographic transform and key management used.  Some transforms
   give strong source authentication even in multiparty sessions; others
   give weaker guarantees and can authenticate group membership but not
   sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
   [RFC4383] offers a complement to the regular symmetric keyed
   authentication transforms, like HMAC-SHA-1, and can provide
   per-source authentication in some group communication scenarios.  The
   downside is the need for buffering the packets for a while before
   authenticity can be verified.

So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or cryptographic transform as I think SRTP actually calls it, the only source authentication provided is that who ever generated the packet has the key. If one have the KEK, one will also receive all endpoints used master key and can derive the actual used key that protects the inner payload and generates the integrity tag. Thus, unless the involved parties has been compromised, the source authentication statement provide is: Someone that was given the KEK has generated this inner protected packet.

You are welcome to formulate this property however you want that you think makes sense.

Cheers

Magnus Westerlund

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 20 May 2019 16:11:38 +0000

Magnus,

How about this?

Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit
whatever media the adversary wishes to send.  This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an 
existing
endpoint.  Only a single SRTP cipher suite defined provides source
authentication properties that allow an endpoint to cryptographically
assert that it sent a particular E2E protected packet, and its usage is
presently not defined for PERC.  The suite defined in PERC only allows
an Endpoint to determine that whoever sent a packet had received the 
KEK.

I think that might capture the intent.  But, is this really useful to 
speak of the issue in terms of cipher suites?  The text already explains 
that an attacker could re-use another endpoint's SSRC.  It doesn't 
explain why, though?  Maybe that would be useful?  For example, saying 
right after "of an existing endpont" something like "This is made 
possible since all conference
participants share the same KEK.

Anyway, I'm OK with inserting whatever you wish.  I just want to convey 
what's most readily understood.

Paul

------ Original Message ------
From: "Magnus Westerlund" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>
Cc: "Paul Jones" <[email-masked]>; "The IESG" <[email-masked]>; 
"[email-masked]" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked]" <[email-masked]>; 
"[email-masked]" 
<[email-masked]>
Sent: 5/20/2019 3:10:17 AM
Subject: Re: [Perc] Magnus Westerlund's Discuss on 
draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

>>>  So far only a single SRTP cipher suits defined provides source 
>>>authentication properties that allow an endpoint to cryptographically 
>>>assert that it sent a particular E2E protected packet. Instead, the 
>>>common property is that one can determine only that any endpoint that 
>>>has received the KEK has produced the packet.
>>
>>Magnus, I’m just a bit confused on what the above two senses are 
>>trying to say - can you just expand it out a bit more so I get it. I 
>>think I am struggling with what cipher you refer to in the first 
>>sentense.
>>
>The single SRTP cipher suit that exists that provides any stronger 
>source authentication property than, one of those that have the key has 
>generated this message, is to my knowledge TESLA (RFC  4383).
>
>So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or 
>cryptographic transform as I think SRTP actually calls it, the only 
>source authentication provided is that who ever generated the packet 
>has the key. If one have the KEK, one will also receive all endpoints 
>used master key and can derive the actual used key that protects the 
>inner payload and generates the integrity tag. Thus, unless the 
>involved parties has been compromised, the source authentication 
>statement provide is: Someone that was given the KEK has generated this 
>inner protected packet.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 May 2019 08:24:28 +0000

Hi,
I think the below with the suggested added sentence is good enough for
what needs to be described. 
Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit
whatever media the adversary wishes to send.  This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an
existing
endpoint. This is made possible since all conference participants share
the same KEK. Only a single SRTP cipher suite defined provides source
authentication properties that allow an endpoint to cryptographically
assert that it sent a particular E2E protected packet, and its usage is
presently not defined for PERC.  The suite defined in PERC only allows
an Endpoint to determine that whoever sent a packet had received the
KEK.
Cheers
Magnus
On mån, 2019-05-20 at 16:11 +0000, Paul E. Jones wrote:
> endpoint. This is made possible since all conference participants
> share
> the same KEK. > Only a single SRTP cipher suite defined provides source
> an Endpoint to determine that whoever sent a packet had received the KEK.
> 
> 
> I think that might capture the intent.  But, is this really useful to speak of the issue in terms of cipher suites?  The text already explains that an attacker could re-use another endpoint's SSRC.  It doesn't explain why, though?  Maybe that would be useful?  For example, saying right after "of an existing endpont" something like "This is made possible since all conference
> Anyway, I'm OK with inserting whatever you wish.  I just want to convey what's most readily understood.
> 
> Paul
> 
> 
> 
> Cc: "Paul Jones" <[email-masked]>; "The IESG" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> 
> Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
> 
> 
> > 
> > 
> > 

> > > > 
> > > >  > > > > So
> > > >  far only a single SRTP cipher suits defined provides source authentication properties that allow an endpoint to cryptographically assert that it sent a particular E2E protected packet. Instead, the common property is that one can determine only that any endpoint
> > > >  that has received the KEK has produced the packet.
> > > > 

> > So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or cryptographic transform as I think SRTP actually calls it, the only source authentication provided is that who ever generated the packet has the key. If one have the KEK, one will also
> >  receive all endpoints used master key and can derive the actual used key that protects the inner payload and generates the integrity tag. Thus, unless the involved parties has been compromised, the source authentication statement provide is: Someone that was
> >  given the KEK has generated this inner protected packet.
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 21 May 2019 14:15:03 +0000

Think we should reference TESLA (RFC  4383) as informational?  
Otherwise, the "one a single..." statement will leave most wondering 
which one it is.

------ Original Message ------
From: "Magnus Westerlund" <[email-masked]>
To: "[email-masked]" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked]" <[email-masked]>; 
"[email-masked]" <[email-masked]>; 
"[email-masked]" 
<[email-masked]>
Sent: 5/21/2019 4:24:28 AM
Subject: Re: Re[2]: [Perc] Magnus Westerlund's Discuss on 
draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

>>speak of the issue in terms of cipher suites?  The text already 
>>explains that an attacker could re-use another endpoint's SSRC.  It 
>>doesn't explain why, though?  Maybe that would be useful?  For 
>>example, saying right after "of an existing endpont" something like 
>>"This is made possible since all conference
>>"[email-masked]" <[email-masked]>; 
>>"[email-masked]" <[email-masked]>; "[email-masked]" 
>><[email-masked]>; "[email-masked]" 
>>>>>authentication properties that allow an endpoint to 
>>>>>cryptographically assert that it sent a particular E2E protected 
>>>>>packet. Instead, the common property is that one can determine only 
>>>>>that any endpoint that has received the KEK has produced the 
>>>>>packet.
>>>>
>>>source authentication property than, one of those that have the key 
>>>has generated this message, is to my knowledge TESLA (RFC  4383).
>>>
>>>So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, 
>>>or cryptographic transform as I think SRTP actually calls it, the 
>>>only source authentication provided is that who ever generated the 
>>>packet has the key. If one have the KEK, one will also receive all 
>>>endpoints used master key and can derive the actual used key that 
>>>protects the inner payload and generates the integrity tag. Thus, 
>>>unless the involved parties has been compromised, the source 
>>>authentication statement provide is: Someone that was given the KEK 
>>>has generated this inner protected packet.
>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 May 2019 14:31:25 +0000

On 2019-05-21 16:15, Paul E. Jones wrote:
Think we should reference TESLA (RFC  4383) as informational?  Otherwise, the "one a single..." statement will leave most wondering which one it is.

Yes, I think you are correct.

/Magnus

------ Original Message ------
From: "Magnus Westerlund" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; "[email-masked]"<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; "[email-masked]"<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; "[email-masked]"<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; "[email-masked]"<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; "[email-masked]"<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: 5/21/2019 4:24:28 AM
Subject: Re: Re[2]: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

Hi,

I think the below with the suggested added sentence is good enough for what needs to be described.

Cheers

Magnus

How about this?

Paul

------ Original Message ------
From: "Magnus Westerlund" <[email-masked]<mailto:[email-masked]>>
To: "Cullen Jennings" <[email-masked]<mailto:[email-masked]>>
Cc: "Paul Jones" <[email-masked]<mailto:[email-masked]>>; "The IESG" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 5/20/2019 3:10:17 AM
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

Cheers

Magnus Westerlund

--

Magnus Westerlund