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

"Paul E. Jones" <paulej@packetizer.com> Mon, 20 May 2019 16:11 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939A412017D; Mon, 20 May 2019 09:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgxvGf7ZrR4B; Mon, 20 May 2019 09:11:46 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B4112017A; Mon, 20 May 2019 09:11:46 -0700 (PDT)
Received: from authuser (localhost [127.0.0.1])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1558368701; bh=7UmGp0PMb8ca+v00WklFlCp7SPy8etAE+wA7dFK7qUE=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=W+E0Vlp0+96FnS8ArkFZzRds2QwHJViECZVrQrV4rarL97s4SlE4/Cx/J/jndgcw5 LSqAa1DzVpr2i1k2JDmvpHhbBQLaoNKGPm8SpdZtS1yz2utA8J39aPMr9GmHn4/IZf B6cnkL8WHdxxOv7bnCluOJzvxoxWeBqrVObjmpbM=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Cullen Jennings <fluffy@iii.ca>
Cc: The IESG <iesg@ietf.org>, "nohlmeier@mozilla.com" <nohlmeier@mozilla.com>, "perc-chairs@ietf.org" <perc-chairs@ietf.org>, "perc@ietf.org" <perc@ietf.org>, "draft-ietf-perc-private-media-framework@ietf.org" <draft-ietf-perc-private-media-framework@ietf.org>
Date: Mon, 20 May 2019 16:11:38 +0000
Message-Id: <emef567a8d-b7c8-4833-8d06-97cbb33c7554@sydney>
In-Reply-To: <HE1PR0701MB252253FCF1EEB0D1BD502D9495060@he1pr0701mb2522.eurprd07.prod.outlook.com>
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> <eme03c8681-09b1-41be-8d6f-ccd86546cdc4@sydney> <HE1PR0701MB2522CD96FDCB0F920CE2740F950A0@he1pr0701mb2522.eurprd07.prod.outlook.com> <em34aed8b0-2ed1-4e23-a0ee-b2e613076a94@sydney> <HE1PR0701MB25225ED31452D0FCC2787500950B0@he1pr0701mb2522.eurprd07.prod.outlook.com> <234A5249-3D7B-468C-9A77-72DBBF5CF46A@iii.ca> <HE1PR0701MB252253FCF1EEB0D1BD502D9495060@he1pr0701mb2522.eurprd07.prod.outlook.com>
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: eM_Client/7.2.35595.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB0C1EAF0B-0A66-4BF5-BDB9-BBCDE967721C"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/iNOWBBUJ9OOYZdw7gM449xZ5HWk>
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2019 16:11:49 -0000

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.  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" <magnus.westerlund@ericsson.com>
To: "Cullen Jennings" <fluffy@iii.ca>
Cc: "Paul Jones" <paulej@packetizer.com>; "The IESG" <iesg@ietf.org>; 
"nohlmeier@mozilla.com" <nohlmeier@mozilla.com>; "perc-chairs@ietf.org" 
<perc-chairs@ietf.org>; "perc@ietf.org" <perc@ietf.org>; 
"draft-ietf-perc-private-media-framework@ietf.org" 
<draft-ietf-perc-private-media-framework@ietf.org>
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 
>>><magnus.westerlund@ericsson.com> 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  +46 10 7148287
>Torshamnsgatan 23           | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------