Re: [rtcweb] New use-case proposed

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 14 May 2012 08:48 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9F121F85D1 for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 01:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.147
X-Spam-Level:
X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpwQ+2ORt0bE for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 01:48:33 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 12A9D21F85D0 for <rtcweb@ietf.org>; Mon, 14 May 2012 01:48:32 -0700 (PDT)
X-AuditID: c1b4fb30-b7c05ae000003df9-45-4fb0c6dfa1a4
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 77.3E.15865.FD6C0BF4; Mon, 14 May 2012 10:48:31 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 10:48:30 +0200
Message-ID: <4FB0C6DD.6080405@ericsson.com>
Date: Mon, 14 May 2012 10:48:29 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <4FB0B91E.30507@ericsson.com>
In-Reply-To: <4FB0B91E.30507@ericsson.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New use-case proposed
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2012 08:48:33 -0000

On 2012-05-14 09:49, Magnus Westerlund wrote:
> On 2012-05-11 18:21, Harald Alvestrand wrote:
>> I propose to reject this use case because it requires yet another 
>> security redesign.
>> The clue is here:
>>
>>>
>>> - The keying solution must allow each participants to encrypt to
>>> multiple receivers without any decryption+encryption in the middle node
>>>
>>
>> This means that each participant must use the same encryption keys to 
>> all other participants; this in turn means that when someone leaves the 
>> group, all participants must change their encryption keys; it also means 
>> that as long as shared keys are used for authentication, all 
>> participants can impersonate all other participants.
> 
> Actually EKT solves this in a very reasonable way. Each participant
> announces his key using EKT. When a participant leaves all the other
> participants uses EKT to provide a new key for the media they send. Thus
> no need for synchronized key roll over anything.

To make it clear, there are two levels of security here. A first one of
each participant changing keys after a participant has left and no
longer gets the traffic. If that is done without changing the EKT key
then that participant could decrypt the key, but then the attacker must
get to the media which no longer is being forwarded to it.

The second level which is recommend is to have the central node change
the EKT key by triggering DTLS based rekeying of the EKT. Then it is
impossible for the participant that left to eavesdrop on the conference.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------