Re: [MSEC] Application layer multicast security protocol

"Dan Wing" <dwing@cisco.com> Fri, 02 September 2011 00:41 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: msec@ietfa.amsl.com
Delivered-To: msec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD0621F96AA for <msec@ietfa.amsl.com>; Thu, 1 Sep 2011 17:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.034
X-Spam-Level:
X-Spam-Status: No, score=-102.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, 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 H2q+1KupQbG4 for <msec@ietfa.amsl.com>; Thu, 1 Sep 2011 17:41:09 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5BC21F949C for <msec@ietf.org>; Thu, 1 Sep 2011 17:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2929; q=dns/txt; s=iport; t=1314924163; x=1316133763; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=0S1oEevEM8JN+ixWT5JRLaoSc5D7+civ6RwLZi11Zuc=; b=L1mZoXXph1LPSWb10GrO/LFlf28SozHd33qRplNw00Jwhd8+y1xZBSF7 yG75qLUvzRJYS66GPjd0TFw8rZpdVn1bvy+dsr0f5xKfL4Zt19pMbQDge rVpbU5ROflYwYoDuObbpdyI7Z3pB8mW+1d/o/4y6eQKEDcnI+i1aARHIY c=;
X-IronPort-AV: E=Sophos;i="4.68,316,1312156800"; d="scan'208";a="18699657"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 02 Sep 2011 00:42:43 +0000
Received: from dwingWS (dhcp-128-107-105-96.cisco.com [128.107.105.96]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p820gg0N001593; Fri, 2 Sep 2011 00:42:42 GMT
From: Dan Wing <dwing@cisco.com>
To: "'Sheela Rowles (sheela)'" <sheela@cisco.com>, 'Adrian-Ken Rueegsegger' <ken@codelabs.ch>, 'sampreeth ramavana' <sampreeth@gmail.com>
References: <CAODMbr0VCDd+m+3VunK8HOx1r+cmncQubWQAH0hCweVMqrpOzg@mail.gmail.com> <4E54A020.4020600@codelabs.ch> <6B9C4B97B82F924485E26968EB05A6EE0D113659@xmb-sjc-224.amer.cisco.com>
In-Reply-To: <6B9C4B97B82F924485E26968EB05A6EE0D113659@xmb-sjc-224.amer.cisco.com>
Date: Thu, 01 Sep 2011 17:42:42 -0700
Message-ID: <06ba01cc6909$39876b20$ac964160$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcxiKrLPEo/N42Q1TqGuzA6h3oSJ5wAPLVOgAagcaEA=
Content-Language: en-us
Cc: msec@ietf.org
Subject: Re: [MSEC] Application layer multicast security protocol
X-BeenThere: msec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/msec>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Sep 2011 00:41:09 -0000

> -----Original Message-----
> From: Sheela Rowles (sheela) [mailto:sheela@cisco.com]
> Sent: Wednesday, August 24, 2011 7:11 AM
> To: Adrian-Ken Rueegsegger; sampreeth ramavana; Dan Wing (dwing)
> Cc: msec@ietf.org
> Subject: RE: [MSEC] Application layer multicast security protocol
> 
> Added Dan Wing since the GDOI/SRTP draft was dropped because Dan Wing
> had an alternative draft.  Sorry can't remember the details now.

(Sorry for my late response.)

A problem with using GDOI to distribute SRTP keys is it requires 
an additional signaling infrastructure: the call itself has to
be signaled (codec, IP address/port, etc.) to the participants 
using existing call signaling (e.g., SIP), but GDOI introduces
an additional signaling protocol so those participants can obtain
the necessary keys.  This separate mechanism requires its own
signaling (which means worrying about NAT traversal and 
associated keepalive traffic, and so on), and unless all keys
for all speakers are distributed early (before the speaker
talks), adds delay before media from a new speaker can be 
decrypted.

Instead, we can distribute the initial SRTP key in SIP or via
DTLS-SRTP, and change the SRTP key (such as when the participant 
list changes or a new speaker talks) in the media path itself 
(using RTP or RTCP).  This is done with 
http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt.  This doesn't 
use additional ports and allows fate sharing between
the key changes and the SRTP packets (because the key changes can
be carried in the SRTP packets themselves).  We find this useful
when a new speaker says something in a conference (as their SRTP
key can be included in their very first SRTP packet, without delay
and without coordinating with key distribution via SIP or via
GDOI).

-d

> Sheela
> 
> -----Original Message-----
> From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of
> Adrian-Ken Rueegsegger
> Sent: Tuesday, August 23, 2011 11:54 PM
> To: sampreeth ramavana
> Cc: msec@ietf.org
> Subject: Re: [MSEC] Application layer multicast security protocol
> 
> Hi Sampreeth,
> 
> On 08/24/2011 07:35 AM, sampreeth ramavana wrote:
> > Hi All,
> >
> > Is there any multicast security protocol that can be implemented in
> > the application layer?
> >
> > I was seeing the GDOI protocol was mainly talking about implementing
> > using the IPSec at the IP layer. Can GDOI protocol also be useful if
> > implemented at application layer.
> 
> GDOI can be extended to provide key material for other protocols. Mark,
> Sheela and I wrote a draft (which has since expired) which specifies
> the
> usage of GDOI with SRTP [1].
> 
> Regards,
> Adrian
> 
> [1] - http://tools.ietf.org/html/draft-ietf-msec-gdoi-srtp
> _______________________________________________
> MSEC mailing list
> MSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/msec