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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 21 May 2019 08:24 UTC

Return-Path: <magnus.westerlund@ericsson.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 9542E120059; Tue, 21 May 2019 01:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 L69n_dItmlAS; Tue, 21 May 2019 01:24:34 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::627]) (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 E658412011C; Tue, 21 May 2019 01:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ssGrXva8ZD2IR3uI8Z0QvI8zUPyLY2dBYqwb07BLG3Q=; b=mWGaA77Iw8OY0wcmCZLSn8NHVHj+/dLxPkd/rJiplTNbAkx6/UE2sKlvajzHJ7ioYoZ4Ia++JcKSv0VqNUNgMpMA1/5ypKnS1oReaXwwKX2igkQqWUpHVs1QEgJCAk9YLUb6JF2ndpot84CszouZiTuUg9ZrwbA1pPSAgaCDsk0=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2236.eurprd07.prod.outlook.com (10.168.31.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.10; Tue, 21 May 2019 08:24:29 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.013; Tue, 21 May 2019 08:24:29 +0000
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>
Thread-Topic: Re[2]: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
Thread-Index: AQHVDLv05Xj4KxTpkE2ssVAnd4w1BqZ0M/AAgAEPwYA=
Date: Tue, 21 May 2019 08:24:28 +0000
Message-ID: <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>
In-Reply-To: <emef567a8d-b7c8-4833-8d06-97cbb33c7554@sydney>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [129.192.74.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a918dfe3-6d6f-495e-e3a7-08d6ddc5be4f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2236;
x-ms-traffictypediagnostic: HE1PR0701MB2236:
x-microsoft-antispam-prvs: <HE1PR0701MB2236D5B0AD6ADCDEE85AD02D95070@HE1PR0701MB2236.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:517;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(346002)(396003)(366004)(51444003)(13464003)(52314003)(199004)(189003)(110136005)(103116003)(4326008)(508600001)(76176011)(54906003)(486006)(25786009)(44832011)(54896002)(36756003)(236005)(3846002)(6116002)(2616005)(26005)(2906002)(6512007)(229853002)(99286004)(102836004)(316002)(11346002)(53546011)(186003)(6506007)(446003)(2690700001)(6486002)(8676002)(81156014)(99936001)(81166006)(53936002)(6436002)(6246003)(256004)(7736002)(476003)(8936002)(14444005)(71200400001)(71190400001)(66946007)(91956017)(86362001)(68736007)(76116006)(66556008)(14454004)(66446008)(66066001)(5660300002)(66476007)(73956011)(66616009)(64756008)(66574012)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2236; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: A2bVvINrco/vQ8Wmhx8vrTlWKFrGrvglnbrErvD2aa2aqnI8on98w5ExDFiHITinClX5hqWw0KKMi5bV4SnxJSDA7TgJ9dzesTRCD2peNzpvCjH75OGK2MS6ygojFxFF6AMbHm8v/P59/szDyOl3C/bSxKwmZ3aM+UP2kNFAUkTJS8O2+fV248mk5/CSxnZmYKaEaXwTQmNuboAk1T/48hF3syv1b3XnnqZAMowHAfYebyjCjwVksTIfHBtajhP7qH0h91Gc8ojYySn/4GFLCsbQ52wJX61nK1aMDskNphxD8Dft/VZrQH0sGUSgFAst0ZPBpAnBATrRA6+eiipqPMuaEYYuUXw5ecG4BFvM9cpeKauMFkTZ45PJUWXJvMG/7dv4Eu06I4NPODujWX2Flu3o3dQhhWnm4HNMRWNOp+g=
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-bp96dndxNFC2M9eDhO5Z"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a918dfe3-6d6f-495e-e3a7-08d6ddc5be4f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 08:24:28.8494 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2236
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/Eerx8rc6b7Y2poQrICzt8driIbM>
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 08:24:38 -0000

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

> 
> 
> 
>