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

[Magnus Westerlund <[e-mail]>]

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


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

Maybe if the second paragraph is somewhat expanded:

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

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.

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.

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

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------