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

["Paul E. Jones" <[e-mail]>]

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.

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

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.


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

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.


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

Paul