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

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

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?


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

Cool, thanks... fixed that.

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

Good.

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

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

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