Re: [AVT] Key exchange for multicast SRTP

"Dan Wing" <dwing@cisco.com> Tue, 22 December 2009 00:24 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DB33A6879 for <avt@core3.amsl.com>; Mon, 21 Dec 2009 16:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.14
X-Spam-Level:
X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMoF6FFB0I7d for <avt@core3.amsl.com>; Mon, 21 Dec 2009 16:24:26 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7D65328C12D for <avt@ietf.org>; Mon, 21 Dec 2009 16:24:17 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIFALqfL0urR7Hu/2dsb2JhbACIXoEWtjCWOYQuBA
X-IronPort-AV: E=Sophos;i="4.47,434,1257120000"; d="scan'208";a="454285780"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 22 Dec 2009 00:24:00 +0000
Received: from dwingwxp01 (sjc-vpn3-759.cisco.com [10.21.66.247]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBM0O00W022568; Tue, 22 Dec 2009 00:24:00 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Romain Biehlmann' <romain.biehlmann@gmail.com>, avt@ietf.org
References: <9a06dcf0912210834i3fba1badhf50de908a9dcd411@mail.gmail.com>
Date: Mon, 21 Dec 2009 16:24:00 -0800
Message-ID: <0be201ca829d$0ecc5930$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <9a06dcf0912210834i3fba1badhf50de908a9dcd411@mail.gmail.com>
Thread-Index: AcqCW7QtkWxzeRtgTXSSVlzvZOAlTwAP6Zmg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Subject: Re: [AVT] Key exchange for multicast SRTP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2009 00:24:28 -0000

 

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
> Behalf Of Romain Biehlmann
> Sent: Monday, December 21, 2009 8:34 AM
> To: avt@ietf.org
> Subject: [AVT] Key exchange for multicast SRTP
> 
> Hi all,
> 
> In advance, I apologize if my request is misplaced: I just 
> had no idea where to ask for expert advice.
> I'd like to use multicast SRTP on a 802.1x network (i.e. 
> eavesdroppers are the only problem, there should be no man in 
> the middle) and to have a frequently renewed group master key.
> From my point of view, the best solution would be to have a 
> Diffie-Hellman key exchange (in order not to have more public 
> key infrastructure) where the group symmetric key would be 
> ciphered by the symmetric key (and therefore sent in the same 
> time as DHr, so everything would still be done in one round trip).

I'm not sure how DH could be used to establish the same
symmetric key with a bunch of different listeners.

> EKT would be used for the group symmetric key renewal.
> Have I missed an article already describing such a solution?
> Would it be a clean solution according to you?

EKT is helpful to rotate the SRTP key.  It isn't helpful to
change the group symmetric key (that is, the key that encrypts
the SRTP key -- the "KEK"), because every authorized listener 
needs to know the KEK.  So if you have listeners joining/leaving,
and want to deny members that are not current 'active' 
listeners the SRTP key, they need to be denied the KEK, too --
which means the KEK needs to be changed and the SRTP key
needs to be changed.

-d

> I thank you very much for your valuable time.
> 
> ---
> Alice
> p = D303B61A16A14BA5B482C7F23EDBC22F906267596AC32797AEF306138A44DE73
> g = 5
> privateKey = 
> 75C31F842480CEBF87B6F091C2CBAFF931690C8967F310B34C5E14D086D141C4
> publicKey = 
> 2054F2452528B0CBACD9ED31A92304F40F262F60560AAD2969C95DDD1CDBF1B6
> ---
> Alice -> p, g, publicKeyAlice -> Bob
> ---
> Bob
> p = D303B61A16A14BA5B482C7F23EDBC22F906267596AC32797AEF306138A44DE73
> g = 5
> privateKey = 
> 7E15B2E88394C2206E43E2AB44734D7317D14067133C818AF081A607B63ADF9F
> publicKey = 
> E7453D0D9E142C1C83C81E596ABE092FE92E0C952ACE7E71E30B81359A58737
> Symmetric key = 
> 5872C67E4BDA9A407B180891B1EA9EE5C4D3E719417A4477328B87D99DC6EB79
> <Group symmetric key ciphered here with the symmetric key>
> ---
> Bob -> p, g, publicKeyBob, groupSymmetricKey -> Alice
> ---
> Alice
> Symmetric key = 
> 5872C67E4BDA9A407B180891B1EA9EE5C4D3E719417A4477328B87D99DC6EB79
> <Group symmetric key deciphered here with the symmetric key>
> ---
> 
> RB
> 
>