Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
"Paul E. Jones" <paulej@packetizer.com> Tue, 21 May 2019 14:15 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 10F80120099; Tue, 21 May 2019 07:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 C_qVLap2iNvz; Tue, 21 May 2019 07:15:13 -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 6BFF1120020; Tue, 21 May 2019 07:15:13 -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=1558448107; bh=dLz08db0yogai4ucF/tDYV+AJoIn5IPAGsZs0l+R+Fw=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=Ygvc+Khv4aSDgI4KbTGTHFA5ZvYcXum7n7owPv35uMd9Hkh77x9Jx01okmopnbdTm h4GFZuKGVDHEFa7YY8c/adUUUAfen6qxmsnbIN2bWALrOBsHMBi+LnyuNlD/TslJ+F sEbP5IwaZy2BjFWIQsXdR8pFALQq2P7n/zph2HKU=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "fluffy@iii.ca" <fluffy@iii.ca>
Cc: "perc-chairs@ietf.org" <perc-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "nohlmeier@mozilla.com" <nohlmeier@mozilla.com>, "perc@ietf.org" <perc@ietf.org>, "draft-ietf-perc-private-media-framework@ietf.org" <draft-ietf-perc-private-media-framework@ietf.org>
Date: Tue, 21 May 2019 14:15:03 +0000
Message-Id: <em9a1e6e17-57fb-45d3-a2fa-e9305fb9e874@sydney>
In-Reply-To: <1558427057.31263.3.camel@ericsson.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> <emef567a8d-b7c8-4833-8d06-97cbb33c7554@sydney> <1558427057.31263.3.camel@ericsson.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="------=_MB800EBB8C-8C3F-4CB5-A6C9-38B4E4C3CCCB"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/ChvzjJWW6SHo-ZWHy0xMUSfc-0E>
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: Tue, 21 May 2019 14:15:16 -0000
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" <magnus.westerlund@ericsson.com> To: "paulej@packetizer.com" <paulej@packetizer.com>; "fluffy@iii.ca" <fluffy@iii.ca> Cc: "perc-chairs@ietf.org" <perc-chairs@ietf.org>; "iesg@ietf.org" <iesg@ietf.org>; "nohlmeier@mozilla.com" <nohlmeier@mozilla.com>; "perc@ietf.org" <perc@ietf.org>; "draft-ietf-perc-private-media-framework@ietf.org" <draft-ietf-perc-private-media-framework@ietf.org> 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" <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 >>>----------------------------------------------------------------------
- [Perc] Magnus Westerlund's Discuss on draft-ietf-… Magnus Westerlund via Datatracker
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Cullen Jennings
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Paul E. Jones
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Cullen Jennings
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Paul E. Jones
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Cullen Jennings
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Paul E. Jones
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Paul E. Jones
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [Perc] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund