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

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

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" <[e-mail]>
To: "[e-mail]" <[e-mail]>; "[e-mail]" 
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "[e-mail]" 
<[e-mail]>; "[e-mail]" <[e-mail]>; 
"[e-mail]" <[e-mail]>; 
"[e-mail]" 
<[e-mail]>
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.
>
>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:
>>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. 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.
>>
>>
>>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" <[e-mail]>
>>To: "Cullen Jennings" <[e-mail]>
>>Cc: "Paul Jones" <[e-mail]>; "The IESG" <[e-mail]>; 
>>"[e-mail]" <[e-mail]>; 
>>"[e-mail]" <[e-mail]>; "[e-mail]" 
>><[e-mail]>; "[e-mail]" 
>><[e-mail]>
>>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)
>>
>>>On 2019-05-17 20:24, Cullen Jennings wrote:
>>>>
>>>>
>>>>>On May 17, 2019, at 8:22 AM, Magnus Westerlund 
>>>>><[e-mail]> 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.
>>>>
>>>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
>>>
>>>----------------------------------------------------------------------
>>>Network Architecture & Protocols, Ericsson Research
>>>----------------------------------------------------------------------
>>>Ericsson AB                 | Phone  [phone]
>>>Torshamnsgatan 23           | Mobile [phone]
>>>SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>>>----------------------------------------------------------------------