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

[Magnus Westerlund <[e-mail]>]

Hi Paul,

Thanks for the rapid response. See my comments inline.

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

Thanks for your feedback.  Please see my replies below:


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

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


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

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.

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.

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.

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:

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.



Can you clarify what you are looking for here?

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.

I changed my local text to say that.


Great!


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.


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


Thanks


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