From msec-bounces@securemulticast.org Mon Dec 05 01:17:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej9f2-0008De-0O for msec-archive@megatron.ietf.org; Mon, 05 Dec 2005 01:17:16 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04362 for ; Mon, 5 Dec 2005 01:16:25 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C01608CD25; Mon, 5 Dec 2005 01:17:14 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0A5098CD0B for ; Mon, 5 Dec 2005 01:17:11 -0500 (EST) Received: (qmail 13803 invoked by uid 3269); 5 Dec 2005 06:17:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 13800 invoked from network); 5 Dec 2005 06:17:11 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Dec 2005 06:17:11 -0000 Received: from 126.com (bj45-161.i.netease.com [202.108.45.161]) by klesh.pair.com (Postfix) with SMTP id 0737868374 for ; Mon, 5 Dec 2005 01:17:08 -0500 (EST) Received: from IMAGE-MYCOMPUTER (unknown [202.115.30.191]) by smtp4 (Coremail) with SMTP id FED3Tljbk0Onx2UH.35305S2; Mon, 05 Dec 2005 14:17:01 +0800 (CST) Date: Mon, 5 Dec 2005 14:19:03 +0800 From: "Q.Shevchenko" To: "msec" Organization: UESTC X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20051205061708.0737868374@klesh.pair.com> Subject: [MSEC] application-level multicast and IP multicast X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1833689455==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============1833689455== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBmb2xrczoNCgkNClRoZSBzZWN1cml0eSBvZiB1bmljYXN0IGlzIG1vcmUgbWF0dXJlIHRo YW4gdGhhdCBvZiBtdWx0aWNhc3QuIEFwcGxpY2F0aW9uLWxldmVsIG11bHRpY2FzdCBoYXMgYmVl biBwdXQgZm9yd2FyZCBpbiByZWNlbnQgeWVhcnMuIEFsdGhvdWdoIGFwcGxpY2F0aW9uLWxldmVs IG11bHRpY2FzdCBoYXMgaXRzIG93biB3ZWFrbmVzcywgaXQgaXMgZWFzaWVyIHRoYXQgSVAgbXVs dGljYXN0IGZyb20gdGhlIHZpZXdwb2ludCBvZiBpbXBsZW1lbnRhdGlvbi4gSaGvZCBsaWtlIHRv IGtub3csIGlzIGl0IGxpa2VseSB0aGF0IElQIG11bHRpY2FzdCB3aWxsIGJlIHJlcGxhY2VkIGJ5 IGFwcGxpY2F0aW9uLWxldmVsIG11bHRpY2FzdD8NCg0KUmVnYXJkcyENCgmhoaGhoaGhoaGhoaGh oVEuU2hldmNoZW5rbw0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA1LTEyLTA1DQo= --===============1833689455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1833689455==-- From msec-bounces@securemulticast.org Mon Dec 05 07:37:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjFbB-0008T4-CI for msec-archive@megatron.ietf.org; Mon, 05 Dec 2005 07:37:41 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10711 for ; Mon, 5 Dec 2005 07:36:50 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A9FAC8C847; Mon, 5 Dec 2005 07:37:39 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 15DBC8CCB6 for ; Mon, 5 Dec 2005 07:37:28 -0500 (EST) Received: (qmail 65455 invoked by uid 3269); 5 Dec 2005 12:37:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65452 invoked from network); 5 Dec 2005 12:37:28 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Dec 2005 12:37:28 -0000 Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by klesh.pair.com (Postfix) with ESMTP id E529568374 for ; Mon, 5 Dec 2005 07:37:27 -0500 (EST) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A3F494F0140; Mon, 5 Dec 2005 13:37:26 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 13:35:54 +0100 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 13:35:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Dec 2005 13:35:53 +0100 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D99@esealmw104.eemea.ericsson.se> Thread-Topic: Synchronization of SRTP roll-over counter Thread-Index: AcX5mG5YDoBmvhe1RjuH1KmaDSGq5w== From: "Karl Norrman (KI/EAB)" To: , X-OriginalArrivalTime: 05 Dec 2005 12:35:54.0510 (UTC) FILETIME=[6F2702E0:01C5F998] X-Brightmail-Tracker: AAAAAA== Subject: [MSEC] Synchronization of SRTP roll-over counter X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hello! 3GPP has a service for multicast and broadcast distribution of data called MBMS (Multimedia Broadcast/Multicast Service)=20 [http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/33246-640.zip]. This service uses SRTP for protection of media streams. To achieve robust synchronization of late joiners to a session, 3GPP has agreed on a mechanism that transports the SRTP roll-over counter (ROC) in SRTP packets using the integrity transform hooks. To avoid collisions with IANA registered values in the future, we would like to describe the transform in an IETF RFC and register the required values with IANA. The mechanism and the associated IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt=20 [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp-rcc-00.txt]. = Comments on the draft are very welcome. Since MBMS is close to finalization, we would like to send the draft to IESG for approval before the end of 2005. Regards, Karl _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Dec 05 10:08:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjHxP-0003Tv-AY for msec-archive@megatron.ietf.org; Mon, 05 Dec 2005 10:08:47 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00350 for ; Mon, 5 Dec 2005 10:07:57 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F359C8C471; Mon, 5 Dec 2005 10:08:45 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id EE0AB8C430 for ; Mon, 5 Dec 2005 10:08:44 -0500 (EST) Received: (qmail 90598 invoked by uid 3269); 5 Dec 2005 15:08:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90595 invoked from network); 5 Dec 2005 15:08:44 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Dec 2005 15:08:44 -0000 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by klesh.pair.com (Postfix) with ESMTP id B286368379 for ; Mon, 5 Dec 2005 10:08:44 -0500 (EST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 05 Dec 2005 07:08:44 -0800 X-IronPort-AV: i="3.99,217,1131350400"; d="scan'208"; a="681501710:sNHT33963104" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB5F8aBL012075; Mon, 5 Dec 2005 07:08:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 07:08:40 -0800 Received: from [192.168.0.10] ([10.21.82.211]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 07:08:40 -0800 In-Reply-To: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D99@esealmw104.eemea.ericsson.se> References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D99@esealmw104.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Synchronization of SRTP roll-over counter Date: Mon, 5 Dec 2005 07:08:36 -0800 To: Colin Perkins , "Magnus Westerlund (KI/EAB)" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Dec 2005 15:08:40.0470 (UTC) FILETIME=[C67D8360:01C5F9AD] Cc: "Karl Norrman (KI/EAB)" , AVT Lista , msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit hi I have a lot of comments that have to do with SRTP's cipher, modes, and security. Before posting these comments, I wonder if we should post to both lists or just to msec? Mark On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote: > Hello! > > 3GPP has a service for multicast and broadcast distribution of data > called MBMS (Multimedia Broadcast/Multicast Service) > [http://www.3gpp.org/ftp/Specs/archive/33_series/ > 33.246/33246-640.zip]. > > This service uses SRTP for protection of media streams. > To achieve robust synchronization of late joiners to a session, > 3GPP has agreed on a mechanism that transports the SRTP roll-over > counter (ROC) in SRTP packets using the integrity transform hooks. > > To avoid collisions with IANA registered values in the future, > we would like to describe the transform in an IETF RFC and register > the required values with IANA. The mechanism and the associated > IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt > [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp- > rcc-00.txt]. > Comments on the draft are very welcome. > > Since MBMS is close to finalization, we would like to send the draft > to IESG for approval before the end of 2005. > > Regards, > Karl > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Dec 05 10:39:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjIQv-0007cn-MX for msec-archive@megatron.ietf.org; Mon, 05 Dec 2005 10:39:17 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04423 for ; Mon, 5 Dec 2005 10:38:27 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 76DF08CA6B; Mon, 5 Dec 2005 10:39:16 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 9226E8C029 for ; Mon, 5 Dec 2005 10:39:13 -0500 (EST) Received: (qmail 95661 invoked by uid 3269); 5 Dec 2005 15:39:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95658 invoked from network); 5 Dec 2005 15:39:13 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Dec 2005 15:39:13 -0000 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by klesh.pair.com (Postfix) with ESMTP id 2F14D68374 for ; Mon, 5 Dec 2005 10:39:13 -0500 (EST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 05 Dec 2005 07:39:14 -0800 X-IronPort-AV: i="3.99,217,1131350400"; d="scan'208"; a="681515718:sNHT33808702" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB5FcYAO003017; Mon, 5 Dec 2005 07:39:10 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 07:39:10 -0800 Received: from [192.168.0.10] ([10.21.82.211]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 07:39:09 -0800 In-Reply-To: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D99@esealmw104.eemea.ericsson.se> References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D99@esealmw104.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B3FF588-8E7D-47D4-B80E-8158648EBA61@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Synchronization of SRTP roll-over counter Date: Mon, 5 Dec 2005 07:39:04 -0800 To: "Karl Norrman (KI/EAB)" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 05 Dec 2005 15:39:09.0532 (UTC) FILETIME=[08B239C0:01C5F9B2] Cc: vesa.lehtovirta@ericsson.com, AVT Lista , =?ISO-8859-1?Q?Mats_N=E4slund?= , msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit I'm glad that the Ericsson team and 3GPP have gotten to apply SRTP to broadcast. We are missing a concise statement of the security requirements in the document, however, though I see that there are a few appendices in the accompanying 3GPP document. Still, there are things proposed or assumed in this document that warrant discussion. The "trust model" appendix in the 3GPP Microsoft Word file is vague, and it is therefore difficult to assess the no-integrity mode that is supported by this document. There are also some assumptions that need review, such as why it is better to greatly increase the complexity of the media security protocol rather than increasing the complexity (or frequency) of key management or simply changing the cipher. Regarding the cipher, why not change it to use a mode that does not have a cryptographic dependency on the ROC? Regarding assumptions about key management, all five of the reasons advanced in the Introduction of draft-lehtovirta-srtp-rcc-00.txt for this feature would be unneeded if a key management refresh operation were performed. These are two-way networks, are they not? cheers, Mark On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote: > Hello! > > 3GPP has a service for multicast and broadcast distribution of data > called MBMS (Multimedia Broadcast/Multicast Service) > [http://www.3gpp.org/ftp/Specs/archive/33_series/ > 33.246/33246-640.zip]. > > This service uses SRTP for protection of media streams. > To achieve robust synchronization of late joiners to a session, > 3GPP has agreed on a mechanism that transports the SRTP roll-over > counter (ROC) in SRTP packets using the integrity transform hooks. > > To avoid collisions with IANA registered values in the future, > we would like to describe the transform in an IETF RFC and register > the required values with IANA. The mechanism and the associated > IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt > [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp- > rcc-00.txt]. > Comments on the draft are very welcome. > > Since MBMS is close to finalization, we would like to send the draft > to IESG for approval before the end of 2005. > > Regards, > Karl > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Dec 06 08:35:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejcyg-0000Hc-DS for msec-archive@megatron.ietf.org; Tue, 06 Dec 2005 08:35:30 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29595 for ; Tue, 6 Dec 2005 08:34:38 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0F10F8D188; Tue, 6 Dec 2005 08:35:29 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 810258D178 for ; Tue, 6 Dec 2005 08:35:26 -0500 (EST) Received: (qmail 30029 invoked by uid 3269); 6 Dec 2005 13:35:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 30026 invoked from network); 6 Dec 2005 13:35:25 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Dec 2005 13:35:25 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id D2E2068374 for ; Tue, 6 Dec 2005 08:35:24 -0500 (EST) Received: (qmail 47376 invoked from network); 6 Dec 2005 08:35:24 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 6 Dec 2005 08:35:24 -0500 Received: (qmail 43606 invoked from network); 6 Dec 2005 08:35:23 -0500 Received: from unknown (HELO localhost.localdomain) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 6 Dec 2005 08:35:23 -0500 Received: (from gmg@localhost) by localhost.localdomain (8.11.2/8.11.2) id jB6BERK00765; Tue, 6 Dec 2005 06:14:27 -0500 Date: Tue, 6 Dec 2005 06:14:27 -0500 (EST) From: George Gross To: "Q.Shevchenko" Subject: Re: [MSEC] application-level multicast and IP multicast In-Reply-To: <20051205061708.0737868374@klesh.pair.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, your question is more about the marketplace than the technology, any answer would be speculative and/or application-dependent. you may be interested in the IETF multicast overlay e-mail list: https://www1.ietf.org/mailman/listinfo/omcast organized by Mark Pullen from GMU.... hth, =09George On Mon, 5 Dec 2005, Q.Shevchenko wrote: > Dear folks: > > The security of unicast is more mature than that of multicast. Applicatio= n-level multicast has been put forward in recent years. Although applicatio= n-level multicast has its own weakness, it is easier that IP multicast from= the viewpoint of implementation. I=A1=AFd like to know, is it likely that = IP multicast will be replaced by application-level multicast? > > Regards! > =09=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Q.Shevchenko > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-12-05 > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Dec 07 05:58:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejwzx-0008Lc-CS for msec-archive@megatron.ietf.org; Wed, 07 Dec 2005 05:58:09 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17219 for ; Wed, 7 Dec 2005 05:57:18 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 811A08C1DF; Wed, 7 Dec 2005 05:57:50 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 593DC8C195 for ; Wed, 7 Dec 2005 05:57:48 -0500 (EST) Received: (qmail 21983 invoked by uid 3269); 7 Dec 2005 10:57:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21980 invoked from network); 7 Dec 2005 10:57:48 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Dec 2005 10:57:48 -0000 Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by klesh.pair.com (Postfix) with ESMTP id F06E168379 for ; Wed, 7 Dec 2005 05:57:47 -0500 (EST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 82F846B5; Wed, 7 Dec 2005 11:23:53 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Dec 2005 11:23:53 +0100 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Dec 2005 11:23:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Synchronization of SRTP roll-over counter Date: Wed, 7 Dec 2005 11:23:52 +0100 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DA2@esealmw104.eemea.ericsson.se> Thread-Topic: [MSEC] Synchronization of SRTP roll-over counter Thread-Index: AcX5skUda+1tyc0aQq2GycBA9w+ORQBY0Arg From: "Karl Norrman (KI/EAB)" To: "Mark Baugher" X-OriginalArrivalTime: 07 Dec 2005 10:23:53.0443 (UTC) FILETIME=[52A79B30:01C5FB18] X-Brightmail-Tracker: AAAAAA== Cc: =?iso-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= , AVT Lista , "Vesa Lehtovirta (JO/LMF)" , msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hello! Thanks for the comments. Please see answers inline. > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of Mark Baugher > Sent: den 5 december 2005 16:39 > To: Karl Norrman (KI/EAB) > Cc: Vesa Lehtovirta (JO/LMF); AVT Lista; Mats N=E4slund (KI/EAB); msec > Subject: Re: [MSEC] Synchronization of SRTP roll-over counter >=20 >=20 > I'm glad that the Ericsson team and 3GPP have gotten to apply=20 > SRTP to =20 > broadcast. We are missing a concise statement of the security =20 > requirements in the document, however, though I see that there are a =20 > few appendices in the accompanying 3GPP document. Still, there are =20 > things proposed or assumed in this document that warrant discussion. Assuming you are discussing the 3GPP specification TS 33.246,=20 this is probably not the right forum for discussing the=20 requirements for the MBMS security solution. They should be=20 raised in 3GPP groups. >=20 > The "trust model" appendix in the 3GPP Microsoft Word file is vague, =20 > and it is therefore difficult to assess the no-integrity mode=20 > that is =20 > supported by this document. There are also some assumptions that =20 > need review, such as why it is better to greatly increase the =20 > complexity of the media security protocol rather than increasing the =20 > complexity (or frequency) of key management or simply changing the =20 > cipher. There was a proposal sent to 3GPP/SA3 that suggested sending the=20 highest bit of the sequence number in key management messages. That=20 one did, however, not give a completely robust solution (packet loss=20 could still get the receiver out of synch). >=20 > Regarding the cipher, why not change it to use a mode that does not =20 > have a cryptographic dependency on the ROC? Since 3GPP/SA3 decided to use SRTP as of RFC3711, the session keys=20 are, as you know, derived from the index =3D ROC || SEQ and other=20 parameters. Removing the dependency of the ROC would also imply = shortening=20 the maximum number of packets that can be protected by the same key to=20 2^{16} (since the index is part of the IV), and (in my opinion) the = index is such a fundamental part of SRTP, that the remaining part after = removing it would require a complete security analysis of SRTP again. (Not to = mention,=20 we would have a specific 3GPP-SRTP and one IETF-SRTP). >=20 > Regarding assumptions about key management, all five of the reasons =20 > advanced in the Introduction of draft-lehtovirta-srtp-rcc-00.txt for =20 > this feature would be unneeded if a key management refresh operation =20 > were performed. Refreshing keys is allowed by TS 33.246. Unfortunately, refreshing=20 the security policy (including ROC) is far from free (especially in a radio environment). Opening a point-to-point link and delivering the=20 policy to each and every user of a big group is a heavy operation=20 (note that the point-to-point radio bearer may not be "always on",=20 and setting it up requires some signalling). Regards, Karl >=20 > These are two-way networks, are they not? >=20 > cheers, Mark >=20 > On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote: >=20 > > Hello! > > > > 3GPP has a service for multicast and broadcast distribution of data > > called MBMS (Multimedia Broadcast/Multicast Service) > > [http://www.3gpp.org/ftp/Specs/archive/33_series/=20 > > 33.246/33246-640.zip]. > > > > This service uses SRTP for protection of media streams. > > To achieve robust synchronization of late joiners to a session, > > 3GPP has agreed on a mechanism that transports the SRTP roll-over > > counter (ROC) in SRTP packets using the integrity transform hooks. > > > > To avoid collisions with IANA registered values in the future, > > we would like to describe the transform in an IETF RFC and register > > the required values with IANA. The mechanism and the associated > > IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt > > [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp-=20 > > rcc-00.txt]. > > Comments on the draft are very welcome. > > > > Since MBMS is close to finalization, we would like to send the draft > > to IESG for approval before the end of 2005. > > > > Regards, > > Karl > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Dec 07 14:35:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek54j-0003Tn-HH for msec-archive@megatron.ietf.org; Wed, 07 Dec 2005 14:35:41 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17671 for ; Wed, 7 Dec 2005 14:34:44 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3E7828CAF3; Wed, 7 Dec 2005 14:35:35 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 31E378CACC for ; Wed, 7 Dec 2005 14:35:33 -0500 (EST) Received: (qmail 27511 invoked by uid 3269); 7 Dec 2005 19:35:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27488 invoked from network); 7 Dec 2005 19:35:17 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Dec 2005 19:35:17 -0000 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by klesh.pair.com (Postfix) with ESMTP id 89E4868374 for ; Wed, 7 Dec 2005 14:35:15 -0500 (EST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Dec 2005 11:35:14 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB7JYkBf013470; Wed, 7 Dec 2005 11:35:11 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 11:35:09 -0800 Received: from [192.168.0.10] ([10.21.80.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 11:35:09 -0800 In-Reply-To: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DA2@esealmw104.eemea.ericsson.se> References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DA2@esealmw104.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <95C65E0D-59E4-4DD1-8689-0653CD742277@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] Synchronization of SRTP roll-over counter Date: Wed, 7 Dec 2005 11:35:07 -0800 To: Karl Norrman (KI/EAB) X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 07 Dec 2005 19:35:09.0183 (UTC) FILETIME=[555500F0:01C5FB65] Cc: =?ISO-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= , AVT Lista , "Vesa Lehtovirta (JO/LMF)" , msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Karl, On Dec 7, 2005, at 2:23 AM, Karl Norrman (KI/EAB) wrote: > Hello! > > Thanks for the comments. Please see answers inline. > >> -----Original Message----- >> From: msec-bounces@securemulticast.org >> [mailto:msec-bounces@securemulticast.org]On Behalf Of Mark Baugher >> Sent: den 5 december 2005 16:39 >> To: Karl Norrman (KI/EAB) >> Cc: Vesa Lehtovirta (JO/LMF); AVT Lista; Mats N=E4slund (KI/EAB); = msec >> Subject: Re: [MSEC] Synchronization of SRTP roll-over counter >> >> >> I'm glad that the Ericsson team and 3GPP have gotten to apply >> SRTP to >> broadcast. We are missing a concise statement of the security >> requirements in the document, however, though I see that there are a >> few appendices in the accompanying 3GPP document. Still, there are >> things proposed or assumed in this document that warrant discussion. > > Assuming you are discussing the 3GPP specification TS 33.246, > this is probably not the right forum for discussing the > requirements for the MBMS security solution. They should be > raised in 3GPP groups. I'm referring to the document that you pointed to in your note to =20 these lists: http://www.3gpp.org/ftp/Specs/archive/33_series/=20 33.246/33246-640.zip > >> >> The "trust model" appendix in the 3GPP Microsoft Word file is vague, >> and it is therefore difficult to assess the no-integrity mode >> that is >> supported by this document. There are also some assumptions that >> need review, such as why it is better to greatly increase the >> complexity of the media security protocol rather than increasing the >> complexity (or frequency) of key management or simply changing the >> cipher. > > There was a proposal sent to 3GPP/SA3 that suggested sending the > highest bit of the sequence number in key management messages. That > one did, however, not give a completely robust solution (packet loss > could still get the receiver out of synch). I don't understand why we would send the highest bit of the sequence =20 number in key management messages. Why not run a key management =20 exchange at the time that broadcast reception commences or =20 periodically based on the rate of session packets relative to the =20 sequence number space? Better still, why not multicast or broadcast =20 the key management messages? > >> >> Regarding the cipher, why not change it to use a mode that does not >> have a cryptographic dependency on the ROC? > > Since 3GPP/SA3 decided to use SRTP as of RFC3711, RFC 3711 claims to be a framework. It's a framework because we might =20= want to specialize the cipher, mode or other transforms based on =20 different application needs. I have been working under the =20 assumption that broadcast applications have much different =20 requirements than VOIP. So if we can't use the framework design of =20 SRTP for these two diverse applications, I don't know when we would. > the session keys > are, as you know, derived from the index =3D ROC || SEQ and other > parameters. Removing the dependency of the ROC would also imply =20 > shortening > the maximum number of packets that can be protected by the same key to > 2^{16} (since the index is part of the IV), That's if you don't change the cipher mode, but that's precisely what =20= I suggested be changed. What if we changed it to "randomized counter =20= mode" for this application? > and (in my opinion) the index > is such a fundamental part of SRTP, that the remaining part after =20 > removing it > would require a complete security analysis of SRTP again. (Not to =20 > mention, > we would have a specific 3GPP-SRTP and one IETF-SRTP). I'd be willing to help with this analysis. It would prove how well =20 we achieved the RFC 3711 goal of implementing a framework. > >> >> Regarding assumptions about key management, all five of the reasons >> advanced in the Introduction of draft-lehtovirta-srtp-rcc-00.txt for >> this feature would be unneeded if a key management refresh operation >> were performed. > > Refreshing keys is allowed by TS 33.246. Unfortunately, refreshing > the security policy (including ROC) is far from free (especially in a > radio environment). The only part of the security policy that we want to refresh here is =20 the ROC and that is six bytes long. > Opening a point-to-point link and delivering the > policy to each and every user of a big group is a heavy operation > (note that the point-to-point radio bearer may not be "always on", > and setting it up requires some signalling). Why would you necessarily do the key refresh point-to-point for a =20 broadcast or multicast service? cheers, Mark > > Regards, > Karl > >> >> These are two-way networks, are they not? >> >> cheers, Mark >> >> On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote: >> >>> Hello! >>> >>> 3GPP has a service for multicast and broadcast distribution of data >>> called MBMS (Multimedia Broadcast/Multicast Service) >>> [http://www.3gpp.org/ftp/Specs/archive/33_series/ >>> 33.246/33246-640.zip]. >>> >>> This service uses SRTP for protection of media streams. >>> To achieve robust synchronization of late joiners to a session, >>> 3GPP has agreed on a mechanism that transports the SRTP roll-over >>> counter (ROC) in SRTP packets using the integrity transform hooks. >>> >>> To avoid collisions with IANA registered values in the future, >>> we would like to describe the transform in an IETF RFC and register >>> the required values with IANA. The mechanism and the associated >>> IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt >>> [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp- >>> rcc-00.txt]. >>> Comments on the draft are very welcome. >>> >>> Since MBMS is close to finalization, we would like to send the draft >>> to IESG for approval before the end of 2005. >>> >>> Regards, >>> Karl >>> _______________________________________________ >>> msec mailing list >>> msec@securemulticast.org >>> http://six.pairlist.net/mailman/listinfo/msec >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Dec 08 11:13:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkOOm-0002LH-9L for msec-archive@megatron.ietf.org; Thu, 08 Dec 2005 11:13:36 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04434 for ; Thu, 8 Dec 2005 11:12:42 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 650728D20E; Thu, 8 Dec 2005 11:13:30 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 37FF88D1FC for ; Thu, 8 Dec 2005 11:13:29 -0500 (EST) Received: (qmail 61412 invoked by uid 3269); 8 Dec 2005 16:13:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61409 invoked from network); 8 Dec 2005 16:13:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Dec 2005 16:13:29 -0000 Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by klesh.pair.com (Postfix) with ESMTP id BAE4E68377 for ; Thu, 8 Dec 2005 11:13:28 -0500 (EST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A839411BD; Thu, 8 Dec 2005 17:10:48 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Dec 2005 17:09:54 +0100 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Dec 2005 17:09:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Synchronization of SRTP roll-over counter Date: Thu, 8 Dec 2005 17:09:53 +0100 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DB6@esealmw104.eemea.ericsson.se> Thread-Topic: [MSEC] Synchronization of SRTP roll-over counter Thread-Index: AcX7ZVxV7asSwCIvRxiARz3UWhsRPwAqrQmw From: "Karl Norrman (KI/EAB)" To: "Mark Baugher" X-OriginalArrivalTime: 08 Dec 2005 16:09:54.0210 (UTC) FILETIME=[D3730020:01C5FC11] X-Brightmail-Tracker: AAAAAA== Cc: =?iso-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= , AVT Lista , "Vesa Lehtovirta (JO/LMF)" , msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hello! > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: den 7 december 2005 20:35 > To: Karl Norrman (KI/EAB) > Cc: Vesa Lehtovirta (JO/LMF); AVT Lista; Mats N=E4slund (KI/EAB); msec > Subject: Re: [MSEC] Synchronization of SRTP roll-over counter >=20 >=20 > Karl, >=20 > On Dec 7, 2005, at 2:23 AM, Karl Norrman (KI/EAB) wrote: >=20 > > Hello! > > > > Thanks for the comments. Please see answers inline. > > > >> -----Original Message----- > >> From: msec-bounces@securemulticast.org > >> [mailto:msec-bounces@securemulticast.org]On Behalf Of Mark Baugher > >> Sent: den 5 december 2005 16:39 > >> To: Karl Norrman (KI/EAB) > >> Cc: Vesa Lehtovirta (JO/LMF); AVT Lista; Mats N=E4slund=20 > (KI/EAB); msec > >> Subject: Re: [MSEC] Synchronization of SRTP roll-over counter > >> > >> > >> I'm glad that the Ericsson team and 3GPP have gotten to apply > >> SRTP to > >> broadcast. We are missing a concise statement of the security > >> requirements in the document, however, though I see that=20 > there are a > >> few appendices in the accompanying 3GPP document. Still, there are > >> things proposed or assumed in this document that warrant=20 > discussion. > > > > Assuming you are discussing the 3GPP specification TS 33.246, > > this is probably not the right forum for discussing the > > requirements for the MBMS security solution. They should be > > raised in 3GPP groups. >=20 > I'm referring to the document that you pointed to in your note to =20 > these lists: http://www.3gpp.org/ftp/Specs/archive/33_series/=20 > 33.246/33246-640.zip >=20 > > > >> > >> The "trust model" appendix in the 3GPP Microsoft Word file=20 > is vague, > >> and it is therefore difficult to assess the no-integrity mode > >> that is > >> supported by this document. There are also some assumptions that > >> need review, such as why it is better to greatly increase the > >> complexity of the media security protocol rather than=20 > increasing the > >> complexity (or frequency) of key management or simply changing the > >> cipher. > > > > There was a proposal sent to 3GPP/SA3 that suggested sending the > > highest bit of the sequence number in key management messages. That > > one did, however, not give a completely robust solution (packet loss > > could still get the receiver out of synch). >=20 > I don't understand why we would send the highest bit of the sequence =20 > number in key management messages. Why not run a key management =20 > exchange at the time that broadcast reception commences or =20 > periodically based on the rate of session packets relative to the =20 > sequence number space? Better still, why not multicast or broadcast =20 > the key management messages? Please see answer at the end of the mail. > > > >> > >> Regarding the cipher, why not change it to use a mode that does not > >> have a cryptographic dependency on the ROC? > > > > Since 3GPP/SA3 decided to use SRTP as of RFC3711, >=20 > RFC 3711 claims to be a framework. It's a framework because=20 > we might =20 > want to specialize the cipher, mode or other transforms based on =20 > different application needs. I have been working under the =20 > assumption that broadcast applications have much different =20 > requirements than VOIP. So if we can't use the framework design of =20 > SRTP for these two diverse applications, I don't know when we would. Section 3.2.1 of RFC 3711 specifies as the first bullet that the ROC is a transform-independent parameter. I.e., no matter which transform is added to SRTP, the ROC is still part of the protocol used in other places than the encryption. Some parts of SRTP are not replaceable, even though SRTP is a framework. >=20 > > the session keys > > are, as you know, derived from the index =3D ROC || SEQ and other > > parameters. Removing the dependency of the ROC would also imply =20 > > shortening > > the maximum number of packets that can be protected by the=20 > same key to > > 2^{16} (since the index is part of the IV), >=20 > That's if you don't change the cipher mode, but that's=20 > precisely what =20 > I suggested be changed. What if we changed it to "randomized=20 > counter =20 > mode" for this application? If you mean sending the IV with each packet, that can be done. Note however, that this would add about 128 bits to each packet, which is about the same that would be added if the ROC is sent in each packet. Furthermore, the index (the concatenation of ROC and SEQ) is used in SRTP by: * Key derivation * Replay protection * Limit of the number of packets that can be protected without re-keying So even if a new integrity/confidentiality transform is added, that does not use the index as part of the IV, there are still important parts of SRTP that are dependent on the ROC. >=20 > > and (in my opinion) the index > > is such a fundamental part of SRTP, that the remaining part after =20 > > removing it > > would require a complete security analysis of SRTP again. (Not to =20 > > mention, > > we would have a specific 3GPP-SRTP and one IETF-SRTP). >=20 > I'd be willing to help with this analysis. It would prove how well =20 > we achieved the RFC 3711 goal of implementing a framework. > > > >> > >> Regarding assumptions about key management, all five of the reasons > >> advanced in the Introduction of=20 > draft-lehtovirta-srtp-rcc-00.txt for > >> this feature would be unneeded if a key management refresh=20 > operation > >> were performed. > > > > Refreshing keys is allowed by TS 33.246. Unfortunately, refreshing > > the security policy (including ROC) is far from free=20 > (especially in a > > radio environment). >=20 > The only part of the security policy that we want to refresh here is =20 > the ROC and that is six bytes long. >=20 > > Opening a point-to-point link and delivering the > > policy to each and every user of a big group is a heavy operation > > (note that the point-to-point radio bearer may not be "always on", > > and setting it up requires some signalling). >=20 > Why would you necessarily do the key refresh point-to-point for a =20 > broadcast or multicast service? TS 33.246 delivers the policy on a point-to-point link, but the=20 traffic keys are refreshed using mcast/bcast signalling. The reason for this is that the TS 33.246 supports use cases where the TEK is very frequently updated (e.g., every few seconds). If the policy is sent every time a TEK is delivered, there will be unnecessary waste of bandwidth. The TS 33.246 had a solution where the ROC was sent with = multicast/broadcast key management messages, but also in this case an unfortunate packet = loss or delay could still cause ROC to be out of synch. That is why this = SRTP=20 centered solution was developed to replace it. But again, this discussion is centered around TS 33.246 and not around draft-lehtovirta-srtp-rcc-00.txt. I can provide you with links to the discussion papers that have been presented in 3GPP/SA3, where these questions have been analyzed and lead to the solution that you see in TS 33.246. Regards, Karl >=20 > cheers, Mark > > > > Regards, > > Karl > > > >> > >> These are two-way networks, are they not? > >> > >> cheers, Mark > >> > >> On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote: > >> > >>> Hello! > >>> > >>> 3GPP has a service for multicast and broadcast=20 > distribution of data > >>> called MBMS (Multimedia Broadcast/Multicast Service) > >>> [http://www.3gpp.org/ftp/Specs/archive/33_series/ > >>> 33.246/33246-640.zip]. > >>> > >>> This service uses SRTP for protection of media streams. > >>> To achieve robust synchronization of late joiners to a session, > >>> 3GPP has agreed on a mechanism that transports the SRTP roll-over > >>> counter (ROC) in SRTP packets using the integrity transform hooks. > >>> > >>> To avoid collisions with IANA registered values in the future, > >>> we would like to describe the transform in an IETF RFC=20 > and register > >>> the required values with IANA. The mechanism and the associated > >>> IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt > >>> [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp- > >>> rcc-00.txt]. > >>> Comments on the draft are very welcome. > >>> > >>> Since MBMS is close to finalization, we would like to=20 > send the draft > >>> to IESG for approval before the end of 2005. > >>> > >>> Regards, > >>> Karl > >>> _______________________________________________ > >>> msec mailing list > >>> msec@securemulticast.org > >>> http://six.pairlist.net/mailman/listinfo/msec > >> _______________________________________________ > >> msec mailing list > >> msec@securemulticast.org > >> http://six.pairlist.net/mailman/listinfo/msec > >> >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Dec 15 15:57:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En09x-0007RE-Rr for msec-archive@megatron.ietf.org; Thu, 15 Dec 2005 15:57:07 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04357 for ; Thu, 15 Dec 2005 15:55:53 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 569E88D0FB; Thu, 15 Dec 2005 15:56:45 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8F3238D0A3 for ; Thu, 15 Dec 2005 15:56:43 -0500 (EST) Received: (qmail 18586 invoked by uid 3269); 15 Dec 2005 20:56:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18583 invoked from network); 15 Dec 2005 20:56:43 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Dec 2005 20:56:43 -0000 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by klesh.pair.com (Postfix) with ESMTP id 1645D68374 for ; Thu, 15 Dec 2005 15:56:43 -0500 (EST) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 15 Dec 2005 12:56:42 -0800 X-IronPort-AV: i="3.99,258,1131350400"; d="scan'208"; a="241426186:sNHT34896698" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jBFKuUpn026620; Thu, 15 Dec 2005 12:56:39 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 12:56:34 -0800 Received: from [192.168.0.10] ([10.21.98.198]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 12:56:34 -0800 In-Reply-To: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DB6@esealmw104.eemea.ericsson.se> References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DB6@esealmw104.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13E3B600-B675-415C-9DA4-464D411D002A@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Synchronization of SRTP roll-over counter Date: Thu, 15 Dec 2005 12:56:31 -0800 To: Karl Norrman (KI/EAB) X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 15 Dec 2005 20:56:34.0204 (UTC) FILETIME=[08560DC0:01C601BA] Cc: =?ISO-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= , AVT Lista , "Vesa Lehtovirta (JO/LMF)" , msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Karl, On Dec 8, 2005, at 8:09 AM, Karl Norrman (KI/EAB) wrote: ... >> >> I don't understand why we would send the highest bit of the sequence >> number in key management messages. Why not run a key management >> exchange at the time that broadcast reception commences or >> periodically based on the rate of session packets relative to the >> sequence number space? Better still, why not multicast or broadcast >> the key management messages? > > Please see answer at the end of the mail. I think the short answer is that multicast key management is either perceived or observed not to work properly outside of the data stream. As you point out, the key management is a 3GPP concern and not an IETF concern. So we are left with a situation where a non- IETF key management protocol needs changes to an IETF protocol in order to work properly. This is of interest to msec, since the 3GPP experience may call into question part of our architecture for group key management. The msec architecture, rightly or wrongly, does not put the keying in the data plane. If we're wrong, that would be a good thing for us to understand. > >>> >>>> >>>> Regarding the cipher, why not change it to use a mode that does not >>>> have a cryptographic dependency on the ROC? >>> >>> Since 3GPP/SA3 decided to use SRTP as of RFC3711, >> >> RFC 3711 claims to be a framework. It's a framework because >> we might >> want to specialize the cipher, mode or other transforms based on >> different application needs. I have been working under the >> assumption that broadcast applications have much different >> requirements than VOIP. So if we can't use the framework design of >> SRTP for these two diverse applications, I don't know when we would. > > Section 3.2.1 of RFC 3711 specifies as the first bullet that the ROC > is a transform-independent parameter. I.e., no matter which transform > is added to SRTP, the ROC is still part of the protocol used in other > places than the encryption. Some parts of SRTP are not replaceable, > even though SRTP is a framework. I agree that securing the ROC is needed even if we invent encryption transforms that have no dependencies on the ROC. >> >> ... >> That's if you don't change the cipher mode, but that's >> precisely what >> I suggested be changed. What if we changed it to "randomized >> counter >> mode" for this application? > > If you mean sending the IV with each packet, that can be done. Note > however, that this would add about 128 bits to each packet, which is > about the same that would be added if the ROC is sent in each packet. > > Furthermore, the index (the concatenation of ROC and SEQ) is > used in SRTP by: > > * Key derivation > * Replay protection > * Limit of the number of packets that can be protected without re- > keying > > So even if a new integrity/confidentiality transform is added, that > does > not use the index as part of the IV, there are still important parts > of SRTP that are dependent on the ROC. I agree. Properly considered, securing the ROC is a service that SRTP provides to RTP sessions. > ... >> >> Why would you necessarily do the key refresh point-to-point for a >> broadcast or multicast service? > > TS 33.246 delivers the policy on a point-to-point link, but the > traffic keys are refreshed using mcast/bcast signalling. The > reason for this is that the TS 33.246 supports use cases where > the TEK is very frequently updated (e.g., every few seconds). > If the policy is sent every time a TEK is delivered, there will > be unnecessary waste of bandwidth. There is no cryptographic reason to replace a TEK (SRTP master key) every few seconds, is there? > > The TS 33.246 had a solution where the ROC was sent with multicast/ > broadcast > key management messages, but also in this case an unfortunate > packet loss > or delay could still cause ROC to be out of synch. Was this proven through an analysis, experiment, or deployment? > That is why this SRTP > centered solution was developed to replace it. What does this say to msec about sending keys separately from the media in a broadcast (i.e. large-scale multicast) service? Maybe nothing. The rapid TEK rotation makes me think that this system is more of a conditional access system than a security system. I'm still not entirely clear on why the ROC being carried in (some) RTP packets addresses the problems of TEK rotation. > > But again, this discussion is centered around TS 33.246 and not > around draft-lehtovirta-srtp-rcc-00.txt. I can provide you > with links to the discussion papers that have been presented in > 3GPP/SA3, where these questions have been analyzed and lead to > the solution that you see in TS 33.246. Thanks for sending the links in a separate note. I plan to look at them soon. Mark > > Regards, > Karl > >> >> cheers, Mark >>> >>> Regards, >>> Karl >>> >>>> >>>> These are two-way networks, are they not? >>>> >>>> cheers, Mark >>>> >>>> On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote: >>>> >>>>> Hello! >>>>> >>>>> 3GPP has a service for multicast and broadcast >> distribution of data >>>>> called MBMS (Multimedia Broadcast/Multicast Service) >>>>> [http://www.3gpp.org/ftp/Specs/archive/33_series/ >>>>> 33.246/33246-640.zip]. >>>>> >>>>> This service uses SRTP for protection of media streams. >>>>> To achieve robust synchronization of late joiners to a session, >>>>> 3GPP has agreed on a mechanism that transports the SRTP roll-over >>>>> counter (ROC) in SRTP packets using the integrity transform hooks. >>>>> >>>>> To avoid collisions with IANA registered values in the future, >>>>> we would like to describe the transform in an IETF RFC >> and register >>>>> the required values with IANA. The mechanism and the associated >>>>> IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt >>>>> [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp- >>>>> rcc-00.txt]. >>>>> Comments on the draft are very welcome. >>>>> >>>>> Since MBMS is close to finalization, we would like to >> send the draft >>>>> to IESG for approval before the end of 2005. >>>>> >>>>> Regards, >>>>> Karl >>>>> _______________________________________________ >>>>> msec mailing list >>>>> msec@securemulticast.org >>>>> http://six.pairlist.net/mailman/listinfo/msec >>>> _______________________________________________ >>>> msec mailing list >>>> msec@securemulticast.org >>>> http://six.pairlist.net/mailman/listinfo/msec >>>> >> _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Dec 16 02:53:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnAPC-0002ZJ-Qu for msec-archive@megatron.ietf.org; Fri, 16 Dec 2005 02:53:30 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15374 for ; Fri, 16 Dec 2005 02:52:30 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AC0FF8CD1E; Fri, 16 Dec 2005 02:53:29 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BEE208CCEF for ; Fri, 16 Dec 2005 02:53:27 -0500 (EST) Received: (qmail 85949 invoked by uid 3269); 16 Dec 2005 07:53:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85946 invoked from network); 16 Dec 2005 07:53:27 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 16 Dec 2005 07:53:27 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 420686837C for ; Fri, 16 Dec 2005 02:53:27 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBG7r4Lx000569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Dec 2005 23:53:05 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-53.qualcomm.com [10.50.68.53]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBG7qw9g020336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Dec 2005 23:53:00 -0800 (PST) Message-Id: <6.2.5.6.2.20051216093455.03fb8da8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Dec 2005 09:52:58 +0200 To: Mark Baugher , Karl Norrman (KI/EAB) From: Lakshminath Dondeti Subject: Re: [MSEC] Synchronization of SRTP roll-over counter In-Reply-To: <13E3B600-B675-415C-9DA4-464D411D002A@cisco.com> References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DB6@esealmw104.eemea.ericsson.se> <13E3B600-B675-415C-9DA4-464D411D002A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec , AVT Lista , "Mats =?iso-8859-1?Q?N=E4slund?= (KI/EAB)" , "Vesa Lehtovirta (JO/LMF)" X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Mark, I have some of the same observations as you have. Please see inline for specific comments. At 08:56 AM 12/16/2005, Mark Baugher wrote: >Karl, > >On Dec 8, 2005, at 8:09 AM, Karl Norrman (KI/EAB) wrote: >... >>> >>>I don't understand why we would send the highest bit of the sequence >>>number in key management messages. Why not run a key management >>>exchange at the time that broadcast reception commences or >>>periodically based on the rate of session packets relative to the >>>sequence number space? Better still, why not multicast or broadcast >>>the key management messages? >> >>Please see answer at the end of the mail. > >I think the short answer is that multicast key management is either >perceived or observed not to work properly outside of the data >stream. As you point out, the key management is a 3GPP concern and >not an IETF concern. So we are left with a situation where a non- >IETF key management protocol needs changes to an IETF protocol in >order to work properly. > >This is of interest to msec, since the 3GPP experience may call into >question part of our architecture for group key management. The msec >architecture, rightly or wrongly, does not put the keying in the data >plane. If we're wrong, that would be a good thing for us to understand. Folks active in 3GPP2 also noted that SA synchronization (MSEC term, not theirs) is a major issue. Mobiles may go in and out of coverage and may receive encrypted content for which they don't have the latest SA/keys. SA updates sent out of band from data may have been sent when the mobile was off or out of coverage. For that same reason LKH would NOT be useful in such environments (Subset difference OTOH would work, but the high overhead of course is a concern). This, I think, call us to rethink MSEC key management architecture a bit. I think we have some notes on SA synchronization in 4046, but probably need to start thinking about solutions. In case of 3GPP2, they send some keying information as part of SRTP packets. >>>>>Regarding the cipher, why not change it to use a mode that does not >>>>>have a cryptographic dependency on the ROC? >>>> >>>>Since 3GPP/SA3 decided to use SRTP as of RFC3711, >>> >>>RFC 3711 claims to be a framework. It's a framework because >>>we might >>>want to specialize the cipher, mode or other transforms based on >>>different application needs. I have been working under the >>>assumption that broadcast applications have much different >>>requirements than VOIP. So if we can't use the framework design of >>>SRTP for these two diverse applications, I don't know when we would. >> >>Section 3.2.1 of RFC 3711 specifies as the first bullet that the ROC >>is a transform-independent parameter. I.e., no matter which transform >>is added to SRTP, the ROC is still part of the protocol used in other >>places than the encryption. Some parts of SRTP are not replaceable, >>even though SRTP is a framework. > >I agree that securing the ROC is needed even if we invent encryption >transforms that have no dependencies on the ROC. >>> >... >>>That's if you don't change the cipher mode, but that's >>>precisely what >>>I suggested be changed. What if we changed it to "randomized >>>counter >>>mode" for this application? >> >>If you mean sending the IV with each packet, that can be done. Note >>however, that this would add about 128 bits to each packet, which is >>about the same that would be added if the ROC is sent in each packet. >> >>Furthermore, the index (the concatenation of ROC and SEQ) is >>used in SRTP by: >> >>* Key derivation >>* Replay protection >>* Limit of the number of packets that can be protected without re- keying >> >>So even if a new integrity/confidentiality transform is added, that >>does >>not use the index as part of the IV, there are still important parts >>of SRTP that are dependent on the ROC. > >I agree. Properly considered, securing the ROC is a service that >SRTP provides to RTP sessions. > >... >>> >>>Why would you necessarily do the key refresh point-to-point for a >>>broadcast or multicast service? >> >>TS 33.246 delivers the policy on a point-to-point link, but the >>traffic keys are refreshed using mcast/bcast signalling. The >>reason for this is that the TS 33.246 supports use cases where >>the TEK is very frequently updated (e.g., every few seconds). >>If the policy is sent every time a TEK is delivered, there will >>be unnecessary waste of bandwidth. > >There is no cryptographic reason to replace a TEK (SRTP master key) >every few seconds, is there? Here is the best reasoning I found so far (and no it is not quite sufficient to me, but please read on). Suppose there are two parts to a mobile: a terminal and a smartcard. Assume further that the smartcard has secure storage and the terminal doesn't. The smartcard has access to all the long term keys and the terminal is given access to the TEK. It is assumed that the terminal owner may try and share the TEK with his/her friends. To do so, he/she may need to use the interactive channel to send the key to the others (say for argument sake via SMS). There is a cost associated with the Broadcast service and of course with the SMS service. If the TEK is changed frequently enough to make the cost of sharing the key more than the cost of Broadcast service, it might be worthwhile to change the TEK frequently. (I realize the explanation is along the lines of CAS reasoning, but anyway there it is). Of course if the unicast service usage is not metered, this technique is useless. In closing, the lessons learned from the MSEC perspective is of the need for SA synchronization and of the need for stateless rekeying. I think we need to start a concerted effort on mechanisms to carry key material as part of secure data encapsulation protocols, e.g., IPsec and SRTP. I'd like to hear others' opinions on this. thanks and regards, Lakshminath >>The TS 33.246 had a solution where the ROC was sent with multicast/ broadcast >>key management messages, but also in this case an unfortunate >>packet loss >>or delay could still cause ROC to be out of synch. > >Was this proven through an analysis, experiment, or deployment? > > >>That is why this SRTP >>centered solution was developed to replace it. > >What does this say to msec about sending keys separately from the >media in a broadcast (i.e. large-scale multicast) service? Maybe >nothing. The rapid TEK rotation makes me think that this system is >more of a conditional access system than a security system. I'm >still not entirely clear on why the ROC being carried in (some) RTP >packets addresses the problems of TEK rotation. > >> >>But again, this discussion is centered around TS 33.246 and not >>around draft-lehtovirta-srtp-rcc-00.txt. I can provide you >>with links to the discussion papers that have been presented in >>3GPP/SA3, where these questions have been analyzed and lead to >>the solution that you see in TS 33.246. > >Thanks for sending the links in a separate note. I plan to look at >them soon. > >Mark >> >>Regards, >>Karl >> >>> >>>cheers, Mark >>>> >>>>Regards, >>>>Karl >>>> >>>>> >>>>>These are two-way networks, are they not? >>>>> >>>>>cheers, Mark >>>>> >>>>>On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote: >>>>> >>>>>>Hello! >>>>>> >>>>>>3GPP has a service for multicast and broadcast >>>distribution of data >>>>>>called MBMS (Multimedia Broadcast/Multicast Service) >>>>>>[http://www.3gpp.org/ftp/Specs/archive/33_series/ >>>>>> >>>>> 33.246/33246-640.zip]. >>>>>> >>>>>>This service uses SRTP for protection of media streams. >>>>>>To achieve robust synchronization of late joiners to a session, >>>>>>3GPP has agreed on a mechanism that transports the SRTP roll-over >>>>>>counter (ROC) in SRTP packets using the integrity transform hooks. >>>>>> >>>>>>To avoid collisions with IANA registered values in the future, >>>>>>we would like to describe the transform in an IETF RFC >>>and register >>>>>>the required values with IANA. The mechanism and the associated >>>>>>IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt >>>>>>[http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp- >>>>>> >>>>> rcc-00.txt]. >>>>>>Comments on the draft are very welcome. >>>>>> >>>>>>Since MBMS is close to finalization, we would like to >>>send the draft >>>>>>to IESG for approval before the end of 2005. >>>>>> >>>>>>Regards, >>>>>>Karl >>>>>>_______________________________________________ >>>>>>msec mailing list >>>>>>msec@securemulticast.org >>>>>>http://six.pairlist.net/mailman/listinfo/msec >>>>>_______________________________________________ >>>>>msec mailing list >>>>>msec@securemulticast.org >>>>>http://six.pairlist.net/mailman/listinfo/msec >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Dec 18 11:28:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eo1Om-0002yN-CS for msec-archive@megatron.ietf.org; Sun, 18 Dec 2005 11:28:36 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27074 for ; Sun, 18 Dec 2005 11:27:31 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AFE198CB8B; Sun, 18 Dec 2005 11:28:32 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0F0488CB17 for ; Sun, 18 Dec 2005 11:28:32 -0500 (EST) Received: (qmail 16009 invoked by uid 3269); 18 Dec 2005 16:28:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15998 invoked from network); 18 Dec 2005 16:28:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Dec 2005 16:28:31 -0000 Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by klesh.pair.com (Postfix) with ESMTP id AAD5868377 for ; Sun, 18 Dec 2005 11:28:31 -0500 (EST) Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 46AA2E12; Sun, 18 Dec 2005 17:28:26 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 18 Dec 2005 17:28:25 +0100 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 18 Dec 2005 17:28:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Synchronization of SRTP roll-over counter Date: Sun, 18 Dec 2005 17:28:24 +0100 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DCC@esealmw104.eemea.ericsson.se> Thread-Topic: [MSEC] Synchronization of SRTP roll-over counter Thread-Index: AcYBug8nalHSPiuMRE20u4KE9v+beACNC7qQ From: "Karl Norrman (KI/EAB)" To: "Mark Baugher" X-OriginalArrivalTime: 18 Dec 2005 16:28:25.0739 (UTC) FILETIME=[121A5DB0:01C603F0] X-Brightmail-Tracker: AAAAAA== Cc: =?iso-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= , AVT Lista , "Vesa Lehtovirta (JO/LMF)" , msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hello! > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: den 15 december 2005 21:57 > To: Karl Norrman (KI/EAB) > Cc: Vesa Lehtovirta (JO/LMF); AVT Lista; Mats N=E4slund (KI/EAB); msec > Subject: Re: [MSEC] Synchronization of SRTP roll-over counter >=20 >=20 > Karl, >=20 > On Dec 8, 2005, at 8:09 AM, Karl Norrman (KI/EAB) wrote: > ... > >> > >> I don't understand why we would send the highest bit of=20 > the sequence > >> number in key management messages. Why not run a key management > >> exchange at the time that broadcast reception commences or > >> periodically based on the rate of session packets relative to the > >> sequence number space? Better still, why not multicast or=20 > broadcast > >> the key management messages? > > > > Please see answer at the end of the mail. >=20 > I think the short answer is that multicast key management is either =20 > perceived or observed not to work properly outside of the data =20 > stream. As you point out, the key management is a 3GPP concern and =20 > not an IETF concern. So we are left with a situation where a non-=20 > IETF key management protocol needs changes to an IETF protocol in =20 > order to work properly. >=20 > This is of interest to msec, since the 3GPP experience may call into =20 > question part of our architecture for group key management. =20 > The msec =20 > architecture, rightly or wrongly, does not put the keying in=20 > the data =20 > plane. If we're wrong, that would be a good thing for us to=20 > understand. I completely agree with the above. However, the solution in 3GPP uses the approach described in draft-lehtovirta-srtp-rcc-00, and to avoid future collisions in the MIKEY and SRTP name spaces it would be good if the IANA registrations in the draft could be done. This does of course not stop any further work on the MSEC group key management architecture. [SNIP] > > TS 33.246 delivers the policy on a point-to-point link, but the > > traffic keys are refreshed using mcast/bcast signalling. The > > reason for this is that the TS 33.246 supports use cases where > > the TEK is very frequently updated (e.g., every few seconds). > > If the policy is sent every time a TEK is delivered, there will > > be unnecessary waste of bandwidth. >=20 > There is no cryptographic reason to replace a TEK (SRTP master key) =20 > every few seconds, is there? No, the reasoning in 3GPP that lead to this approach was along the lines described by Lakshminath in another mail in this thread. >=20 > > > > The TS 33.246 had a solution where the ROC was sent with multicast/=20 > > broadcast > > key management messages, but also in this case an unfortunate =20 > > packet loss > > or delay could still cause ROC to be out of synch. >=20 > Was this proven through an analysis, experiment, or deployment? This was the result of analysis. Check the examples in the introduction of the draft (example 2 should be a continuation of example 1, there was a formatting error. Sorry about that).=20 >=20 >=20 > > That is why this SRTP > > centered solution was developed to replace it. >=20 > What does this say to msec about sending keys separately from the =20 > media in a broadcast (i.e. large-scale multicast) service? Maybe =20 > nothing. The rapid TEK rotation makes me think that this system is =20 > more of a conditional access system than a security system. I'm =20 > still not entirely clear on why the ROC being carried in (some) RTP =20 > packets addresses the problems of TEK rotation. It doesn't really. The TEK rotation is another issue. If a user joins an ongoing session close to SEQ wrap around there can be synch problems, regardless of the TEK rotation (see the examples in the draft). Regards, Karl _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Dec 19 14:39:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoQqh-000254-78 for msec-archive@megatron.ietf.org; Mon, 19 Dec 2005 14:39:07 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02458 for ; Mon, 19 Dec 2005 14:38:02 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 46CAA8CF2E; Mon, 19 Dec 2005 14:39:05 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8A2DB8CEC3 for ; Mon, 19 Dec 2005 14:39:01 -0500 (EST) Received: (qmail 78343 invoked by uid 3269); 19 Dec 2005 19:39:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78340 invoked from network); 19 Dec 2005 19:39:01 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Dec 2005 19:39:01 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id 40FE368377 for ; Mon, 19 Dec 2005 14:39:01 -0500 (EST) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jBJJeo2B009049; Mon, 19 Dec 2005 14:40:50 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jBJJcgk171316; Mon, 19 Dec 2005 14:38:42 -0500 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jBJJcau118238; Mon, 19 Dec 2005 14:38:41 -0500 Received: from prf.watson.ibm.com (prf.watson.ibm.com [9.2.16.112]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id jBJKaNJS023968; Mon, 19 Dec 2005 15:36:23 -0500 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id jBJJcWJ31000; Mon, 19 Dec 2005 14:38:34 -0500 Date: Mon, 19 Dec 2005 14:38:32 -0500 (EST) From: canetti To: "Karl Norrman (KI/EAB)" Subject: RE: [MSEC] Synchronization of SRTP roll-over counter In-Reply-To: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DCC@esealmw104.eemea.ericsson.se> Message-ID: References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3DCC@esealmw104.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Vesa Lehtovirta (JO/LMF)" , msec , Mark Baugher , =?iso-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= , AVT Lista X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: canetti@csail.mit.edu List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: QUOTED-PRINTABLE I was wondering in which way do you envision the MSEC architecture be changed. the MSEC architecture tries to provide separation between the overall mechanism of initial keying followed by periodic rekeying on one side, and the actual scheme used for membership management (eg, LKH, subset-sum, etc) on the other side. I'd classify the question of whether the member needs to obtain all past rekeying messages as being a question about the properties of specific schemes. also, the question of how the member obtains the rekeying messages is scheme-specific, eg the member can get the rekeying messages by explicitly pushed messages, or alternatively the member can pull the rekeying information from a (suitably replicated) website. That said, it does sound like a very good idea to standardize one particular group key management scheme as a "default". suggestions are welcome... Ran On Sun, 18 Dec 2005, Karl Norrman (KI/EAB) wrote: > Hello! > > > -----Original Message----- > > From: Mark Baugher [mailto:mbaugher@cisco.com] > > Sent: den 15 december 2005 21:57 > > To: Karl Norrman (KI/EAB) > > Cc: Vesa Lehtovirta (JO/LMF); AVT Lista; Mats N=E4slund (KI/EAB); msec > > Subject: Re: [MSEC] Synchronization of SRTP roll-over counter > > > > > > Karl, > > > > On Dec 8, 2005, at 8:09 AM, Karl Norrman (KI/EAB) wrote: > > ... > > >> > > >> I don't understand why we would send the highest bit of > > the sequence > > >> number in key management messages. Why not run a key management > > >> exchange at the time that broadcast reception commences or > > >> periodically based on the rate of session packets relative to the > > >> sequence number space? Better still, why not multicast or > > broadcast > > >> the key management messages? > > > > > > Please see answer at the end of the mail. > > > > I think the short answer is that multicast key management is either > > perceived or observed not to work properly outside of the data > > stream. As you point out, the key management is a 3GPP concern and > > not an IETF concern. So we are left with a situation where a non- > > IETF key management protocol needs changes to an IETF protocol in > > order to work properly. > > > > This is of interest to msec, since the 3GPP experience may call into > > question part of our architecture for group key management. > > The msec > > architecture, rightly or wrongly, does not put the keying in > > the data > > plane. If we're wrong, that would be a good thing for us to > > understand. > > I completely agree with the above. However, the solution in 3GPP > uses the approach described in draft-lehtovirta-srtp-rcc-00, > and to avoid future collisions in the MIKEY and SRTP name spaces > it would be good if the IANA registrations in the draft could be done. > > This does of course not stop any further work on the MSEC group > key management architecture. > > [SNIP] > > > > TS 33.246 delivers the policy on a point-to-point link, but the > > > traffic keys are refreshed using mcast/bcast signalling. The > > > reason for this is that the TS 33.246 supports use cases where > > > the TEK is very frequently updated (e.g., every few seconds). > > > If the policy is sent every time a TEK is delivered, there will > > > be unnecessary waste of bandwidth. > > > > There is no cryptographic reason to replace a TEK (SRTP master key) > > every few seconds, is there? > > No, the reasoning in 3GPP that lead to this approach was along the > lines described by Lakshminath in another mail in this thread. > > > > > > > > > The TS 33.246 had a solution where the ROC was sent with multicast/ > > > broadcast > > > key management messages, but also in this case an unfortunate > > > packet loss > > > or delay could still cause ROC to be out of synch. > > > > Was this proven through an analysis, experiment, or deployment? > > This was the result of analysis. Check the examples in the introduction > of the draft (example 2 should be a continuation of example 1, there was > a formatting error. Sorry about that). > > > > > > > > That is why this SRTP > > > centered solution was developed to replace it. > > > > What does this say to msec about sending keys separately from the > > media in a broadcast (i.e. large-scale multicast) service? Maybe > > nothing. The rapid TEK rotation makes me think that this system is > > more of a conditional access system than a security system. I'm > > still not entirely clear on why the ROC being carried in (some) RTP > > packets addresses the problems of TEK rotation. > > It doesn't really. The TEK rotation is another issue. If a user joins > an ongoing session close to SEQ wrap around there can be synch problems, > regardless of the TEK rotation (see the examples in the draft). > > Regards, > Karl > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Dec 19 16:38:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoSi1-0003R5-Nn for msec-archive@megatron.ietf.org; Mon, 19 Dec 2005 16:38:17 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16252 for ; Mon, 19 Dec 2005 16:37:14 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3B5368C943; Mon, 19 Dec 2005 16:38:15 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 3DAC48C662 for ; Mon, 19 Dec 2005 16:38:14 -0500 (EST) Received: (qmail 96663 invoked by uid 3269); 19 Dec 2005 21:38:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96660 invoked from network); 19 Dec 2005 21:38:14 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Dec 2005 21:38:14 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id A9D4C68374 for ; Mon, 19 Dec 2005 16:38:13 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBJLc9Lx006732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2005 13:38:10 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-67.qualcomm.com [10.50.69.67]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBJLc59g020692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Dec 2005 13:38:06 -0800 (PST) Message-Id: <6.2.5.6.2.20051219133546.05911668@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Dec 2005 13:38:02 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_17537838==_" Cc: canetti Subject: [MSEC] WGLC draft-ietf-msec-newtype-keyid-03.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --=====================_17537838==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, This revision has been available for ~3 weeks, I will give another week until next Monday Dec 26th, 2005 for any comments. Only the revisions between -02- and -03- are open for discussion. thanks and regards, Lakshminath >Subject: Submission of draft-ietf-msec-newtype-keyid-03.txt >Date: Wed, 30 Nov 2005 13:47:11 +0100 >X-MS-Has-Attach: yes >X-MS-TNEF-Correlator: >Thread-Topic: Submission of draft-ietf-msec-newtype-keyid-03.txt >Thread-Index: AcX1rC68KKQSrlAoQumv1mc773DjsQ== >From: "Karl Norrman (KI/EAB)" >To: >Cc: , >X-OriginalArrivalTime: 30 Nov 2005 12:47:13.0165 (UTC) >FILETIME=[2F98CBD0:01C5F5AC] >X-Brightmail-Tracker: AAAAAA== >X-PMX-Version: 4.7.0.111621 >X-PMX-Version: 4.6.0.99824, Antispam-Engine: 2.1.0.0, Antispam-Data: >2005.11.30.8 > >Dear Editor, > >please submit the new version of draft-ietf-msec-newtype-keyid-03.txt, >work item in the msec WG. > >Best Regards, >Karl Norrman >Ericsson > --=====================_17537838==_ Content-Type: text/plain; charset="us-ascii" Internet Engineering Task Force Carrara (KTH) Lehtovirta, Norrman (Ericsson) INTERNET-DRAFT EXPIRES: June 2006 December 2005 The Key ID Information Type for the General Extension Payload in MIKEY Status of this memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in June 2006. Abstract This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing Protocol. This is used in, e.g., the Multimedia Broadcast/Multicast Service specified in the 3rd Generation Partnership Project. INTERNET-DRAFT newtype-keyid December, 2005 TABLE OF CONTENTS 1. Introduction...................................................2 2. Rationale......................................................2 3. The Key ID Information Type for the General Extension Payload..3 4. Empty map type definition for the CS ID map type...............5 5. Security Considerations........................................5 6. IANA Considerations............................................6 7. Acknowledgements...............................................7 8. Author's Addresses.............................................7 9. References.....................................................7 1. Introduction The 3rd Generation Partnership Project (3GPP) is currently involved in the development of a multicast and broadcast service, the Multimedia Broadcast/Multicast Service (MBMS), and its security architecture [MBMS]. [MBMS] requires the use of the Multimedia Internet KEYing (MIKEY) Protocol [RFC3830], to convey the keys and related security parameters needed to secure the multimedia that is multicast or broadcast. One of the requirements that MBMS puts on security is the ability to perform frequent updates of the keys. The rationale behind this is that it would be inconvenient for subscribers to publish the decryption keys enabling non-subscribers to view the content. To implement this, MBMS uses a three level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. As illustrated in the section below, MBMS has the need to identify which types of key are involved in the MIKEY message, and their identity. This memo specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of keys involved. 2. Rationale An application where this extension is used is MBMS key management. The key management solution adopted by MBMS uses three level key management. The keys are used in the way described below. "Clients" refers to the clients who have subscribed to a given multicast/broadcast service. Carrara et al. [Page 2] INTERNET-DRAFT newtype-keyid December, 2005 * The MBMS User Key (MUK), point-to-point key between the multicast server and each client * The MBMS Service Key (MSK), group key between the multicast server and all the clients * The MBMS Traffic Key (MTK), group traffic key between the multicast server and all clients. The Traffic Keys are the keys that are regularly updated. The point-to-point MUK key (first-level key) is shared between the multicast server and the client via means defined by MBMS [MBMS]. The MUK is used as pre-shared key to run MIKEY with the pre-shared key method [RFC3830], to deliver (point-to-point) the MSK key. The same MSK key is pushed to all the clients, to be used as a (second- level) group key. Then, the MSK is used to push to all the clients an MTK key (third- level key), the actual group key that is used for the protection of the media traffic. For example, the MTK could be the master key for SRTP [RFC3711] in the streaming case. A Key Domain identifier defines the domain where the group keys are valid or applicable. For example it may define a specific service provider. To allow the key distribution described above, an indication of the type and identity of keys being carried in a MIKEY message is needed. This indication is carried in a new Type of the General Extension Payload in MIKEY. It is necessary to specify what Crypto Session ID map type is associated with a given key. There are cases, for example the download case in MBMS, where the required parameters are signalled in-band (each downloaded DCF-object [DCF] contains the necessary parameters needed by the receiver to process it). Since the parameters are not transported by MIKEY, this implies that a CS ID map type needs to be registered to the "empty map" as defined in Table 3, which is to be used when the map/policy information is conveyed outside of MIKEY. 3. The Key ID Information Type for the General Extension Payload The General Extension payload in MIKEY is defined in Section 6.15 of [RFC3830]. Carrara et al. [Page 3] INTERNET-DRAFT newtype-keyid December, 2005 The Key ID Information Type (Type 3) formats the General Extension payload as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Type ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key ID Information ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. The Key ID Information General Extension Payload. Next Payload and Length are defined in Section 6.15 of [RFC3830]. * Type (8 bits): identifies the type of the General Extension Payload [RFC3830]. This memo adds Type 3 to the ones already defined in [RFC3830]. Type | Value | Comments ------------------------------------------------------------ Key ID | 3 | information on type and identity of keys Table 1. Definition of the new General Extension Payload. * Key ID Information (variable length): the general payload data transporting the type and identifier of a key. This field is formed by Key ID Type sub-payloads as specified below. The Key ID Type sub-payload is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key ID Type ! Key ID Length ! Key ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The Key ID Type sub-payload. * Key ID Type (8 bits): describes the type of the key ID. Predefined types are listed in Table 2. Carrara et al. [Page 4] INTERNET-DRAFT newtype-keyid December, 2005 Key ID Type | Value | Comment -------------------------------------- MBMS Key Domain ID | 0 | ID of the group key domain MBMS Service Key ID | 1 | ID of the group key MBMS Transport Key ID | 2 | ID of the group traffic key Table 2. Type definitions for Key IDs. * Key ID Length (8 bits): describes the length of the Key ID field in octets. * Key ID (variable length): defines the identity of the key. Note that there may be more than one Key ID Type sub-payload in an extension, and that the overall length (i.e., the sum of lengths of all Key ID Type sub-payloads) of the Key ID information field cannot exceed 2^16 - 1 octets. Applications using this general extension payload have to define the semantics and usage of the Key ID Type sub-payloads. 4. Empty map type definition for the CS ID map type When the security policy information is conveyed outside of MIKEY, the CS ID map type is set to value defined in Table 3 to indicate "empty map". CS ID map type | Value | Comments ------------------------------------------------------------ Empty map | 1 | Used when the map/policy information | | is conveyed outside of MIKEY Table 3. Definition of the CS ID map type. 5. Security Considerations The usage of MIKEY for updating the traffic encryption key (MTK) in the broadcast manner, described in Section 2, deviates from the way MIKEY [RFC3830] was originally designed. There are mainly two points that are related to the security of the described usage. First, the delivery of the MTK is not source origin authenticated, but rather protected by a group MAC, keyed by the group key (MSK). Carrara et al. [Page 5] INTERNET-DRAFT newtype-keyid December, 2005 The threat this raises is that users that are part of the group are able to send faked MTK messages to other group members. The origin of the MTK messages is a node inside the core network, and the trust model used in MBMS, is that only trusted traffic is allowed to be sent on the MBMS bearers (from within the operator's network). However, there is always the risk that traffic is injected in the air interface between the base stations and the user equipment. It is possible for members of the group (i.e., with access to the MSK) to spoof MTK updates to other members of the group. 3GPP decided that the technical difficulties and costs involved in performing such an attack are large enough compared to the expected gain for the attacker, that the risk was deemed acceptable. Secondly, the delivery of the MTK is separated from the delivery of the security policy. The security policy is delivered with the MSK. The delivery of the MTKs is assumed to be very frequent (some scenarios require the delivery of MTKs to be as frequent as a few seconds apart). This would imply that the cost (in terms of bandwidth) would be very high if the security policy was delivered together with each MTK. Furthermore, the security policy parameters of the streaming session are not anticipated to change during the session, even though there would be an update of the MTK. It was decided in 3GPP that there was no identified need for updating the policy during an ongoing session, and the cost of allowing such a feature, only to be on the safe side, would be too high. On the other hand, updating the security policy during an ongoing session would be possible by updating the MSK. 6. IANA Considerations According to Section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the Type namespace of the MIKEY General Extension Payload and the CS ID map type namespace of the Common Header Payload. A new MIKEY General Extension Payload Type needs to be registered for this purpose. The registered value for Key ID is requested to be 3 according to Section 3. It is also requested to register the value 1 for the Empty map in the CS ID map namespace of the Common Header Payload as specified in Table 3 in Section 4. The name space for the following field in the Key ID information sub-payload (from Sections 3 and 4) is requested to be managed by IANA: Carrara et al. [Page 6] INTERNET-DRAFT newtype-keyid December, 2005 * Key ID Type It is requested that IANA register the pre-defined types of Table 2 for this namespace. 7. Acknowledgements We would like to thank Fredrik Lindholm. 8. Author's Addresses Questions and comments should be directed to the authors: Elisabetta Carrara Royal Institute of Technology Stockholm Phone: Sweden EMail: carrara@kth.se Vesa Lehtovirta Ericsson Research 02420 Jorvas Phone: +358 9 2993314 Finland EMail: vesa.lehtovirta@ericsson.com Karl Norrman Ericsson Research SE-16480 Stockholm Phone: +46 8 4044502 Sweden EMail: karl.norrman@ericsson.com 9. References Normative [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. Informative [RFC3711] Baugher et al., "The Secure Real-time Transport Protocol (SRTP)", RFC3711, March 2004. [MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and Carrara et al. [Page 7] INTERNET-DRAFT newtype-keyid December, 2005 System Aspects; Security; Security of Multimedia Broadcast/Multicast Service." [DCF] OMA, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0", Candidate Version 2.0 - 29 March 2005 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Carrara et al. [Page 8] INTERNET-DRAFT newtype-keyid December, 2005 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft will expire in June 2006. Carrara et al. [Page 9] --=====================_17537838==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --=====================_17537838==_-- From gilbert@quitsmokeless.biz Thu Dec 29 00:33:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErqPO-0000ts-0o for msec-archive@megatron.ietf.org; Thu, 29 Dec 2005 00:33:02 -0500 Received: from friend ([202.28.116.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07207 for ; Thu, 29 Dec 2005 00:31:46 -0500 (EST) Message-ID: <000001c60c39$3e07b700$0100007f@cc3c13> From: "Thomas" To: Subject: Need medicine? All here! Date: Thu, 29 Dec 2005 12:32:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------ms030208070408010403050502" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. --------------ms030208070408010403050502 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable My Canadian Pharmacy We ship worldwide to all destinations ! a.. Viagra Soft Tabs bestseller=20 b.. Viagra Professional bestseller=20 c.. Cialis bestseller=20 d.. Cialis Soft Tabs bestseller=20 e.. Generic Viagra bestseller=20 f.. Levitra=20 g.. Maxaman=20 h.. Flomax=20 i.. Propecia=20 j.. view all products=20 Need some love pi11s? Why waste time and extra money? Why let people = know about your intimate life? Evil-wishers are always around to spread = rumors. We give you the issue! Make a quick, secure and ABSOLUTELY CONFIDENTIAL = purchase online and receive your LICENSED love life enhancer right to = your door! No privacy exposure, no time wasted, no exorbitant pri$es! = Start a super life now! Our store is VERIFIED BY BBB! All transactions are APPROVED BY VISA! --------------ms030208070408010403050502 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
My Canadian = Pharmacy We ship worldwide to all destinations=20 !
Need some love pi11s? Why waste = time and extra=20 money? Why let people know about your intimate life? Evil-wishers are = always=20 around to spread rumors.
We give you the issue! Make a quick, secure = and=20 ABSOLUTELY CONFIDENTIAL purchase online and receive your LICENSED love = life=20 enhancer right to your door! No privacy exposure, no time wasted, no = exorbitant=20 pri$es! Start a super life now!
 
Our store is VERIFIED BY BBB! All = transactions=20 are APPROVED BY VISA!
--------------ms030208070408010403050502--