From msec-bounces@securemulticast.org Mon Apr 03 12:54:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSJo-0007CH-3V for msec-archive@lists.ietf.org; Mon, 03 Apr 2006 12:54:20 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQSJm-0002ew-RT for msec-archive@lists.ietf.org; Mon, 03 Apr 2006 12:54:20 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7EF5A2C267; Mon, 3 Apr 2006 12:54:18 -0400 (EDT) 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 5F2562C099 for ; Mon, 3 Apr 2006 12:54:16 -0400 (EDT) Received: (qmail 75682 invoked by uid 3269); 3 Apr 2006 16:54:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75679 invoked from network); 3 Apr 2006 16:54:16 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Apr 2006 16:54:16 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 1167B68360 for ; Mon, 3 Apr 2006 12:54:15 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k33GsEWC018737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Apr 2006 09:54:15 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k33GsBMI000370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 3 Apr 2006 09:54:14 -0700 (PDT) Message-Id: <6.2.5.6.2.20060403094855.03b69428@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Apr 2006 09:54:08 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Consensus call: draft-fries-msec-mikey-applicability-00 (ending Apr 7th AOE) 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi all, At the Dallas meeting, there were no objections to making draft-fries-msec-mikey-applicability-00 an MSEC WG document. The scope of this document is to provide a roadmap to all the MIKEY work done in the MSEC and *elsewhere* and provide use cases and explain which mode might fit. I'd encourage the authors to do a gap analysis of MIKEY work as they prepare the document. This is going to be an "Informational RFC" eventually. Please post any objections or support to this document. I encourage all postings to the list, but welcome any private mail to Ran and me. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Apr 03 13:02:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSRv-0004I3-A4 for msec-archive@lists.ietf.org; Mon, 03 Apr 2006 13:02:43 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQSRu-000393-2X for msec-archive@lists.ietf.org; Mon, 03 Apr 2006 13:02:43 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A87BE2BA59; Mon, 3 Apr 2006 13:01:53 -0400 (EDT) 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 C873E2B999 for ; Mon, 3 Apr 2006 13:01:50 -0400 (EDT) Received: (qmail 76809 invoked by uid 3269); 3 Apr 2006 17:01:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76806 invoked from network); 3 Apr 2006 17:01:50 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Apr 2006 17:01:50 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 84A3C6838D for ; Mon, 3 Apr 2006 13:01:50 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k33H1lc0020252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Apr 2006 10:01:47 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k33H1gBh014423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Apr 2006 10:01:44 -0700 (PDT) Message-Id: <6.2.5.6.2.20060403095908.04073320@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Apr 2006 10:01:39 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: rmt@ietf.org Subject: [MSEC] Consensus call: making draft-faurite-rmt-tesla-for-alc-norm-01 an MSEC WG item 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hi all, Please send any objections you might have on making draft-faurite-rmt-tesla-for-alc-norm-01 an MSEC WG item. We also need to hear from folks who are interested in this becoming an RFC and need at least 3 volunteers to review the document (early and LC reviews). regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Apr 06 12:54:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXkU-00043m-QF for msec-archive@lists.ietf.org; Thu, 06 Apr 2006 12:54:22 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRXkT-0007LZ-IH for msec-archive@lists.ietf.org; Thu, 06 Apr 2006 12:54:22 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 158192CA9E; Thu, 6 Apr 2006 12:54:21 -0400 (EDT) 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 3040F2CA75 for ; Thu, 6 Apr 2006 12:54:19 -0400 (EDT) Received: (qmail 12869 invoked by uid 3269); 6 Apr 2006 16:54:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12866 invoked from network); 6 Apr 2006 16:54:19 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Apr 2006 16:54:19 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 46AE168388 for ; Thu, 6 Apr 2006 12:54:17 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36GsEq4001090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2006 09:54:15 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k36GsDb5003540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Apr 2006 09:54:13 -0700 (PDT) Message-Id: <6.2.5.6.2.20060406094758.059a5528@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Apr 2006 09:54:19 -0700 To: Brian Weis , "Sheela Rowles (srowles)" From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org Subject: [MSEC] GDOI update document scoping questions 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi Brian and Sheela, I raised a few questions on the scope of the GDOI Update document (3547bis?). First, there is the issue of introducing AH support in GDOI. I have a few questions here, first I would like the case for AH support discussed on the list, so I will ask the question again that I asked in Dallas. Why is AH support needed? Is ESP-NULL-Encryption not sufficient? What if any changes are required to the MSEC-IPsec extensions document due to the addition of AH support? Second, what is the scope of the GDOI update document. Or is it open ended? I am not really too particular about either approach (in moderation of course, we don't want to redesign GDOI, just update, hopefully with backward compatibility -- or is this is req that you have in mind?). While I am on topic, do you plan to introduce capabilities like sender/receiver indication in GSA download? I think I promised to review the I-D this week, but it looks like my schedule won't allow it, but will make it a higher priority next week. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Apr 07 19:30:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS0PM-0000Ij-Tl for msec-archive@lists.ietf.org; Fri, 07 Apr 2006 19:30:28 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS0PL-0001wL-J5 for msec-archive@lists.ietf.org; Fri, 07 Apr 2006 19:30:28 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EA5CF2CDEC; Fri, 7 Apr 2006 19:30:26 -0400 (EDT) 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 606292CDFD for ; Fri, 7 Apr 2006 19:30:25 -0400 (EDT) Received: (qmail 2145 invoked by uid 3269); 7 Apr 2006 23:30:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2142 invoked from network); 7 Apr 2006 23:30:25 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Apr 2006 23:30:25 -0000 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by klesh.pair.com (Postfix) with ESMTP id 14AB96835D for ; Fri, 7 Apr 2006 19:30:24 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 Apr 2006 16:30:24 -0700 X-IronPort-AV: i="4.04,101,1144047600"; d="scan'208"; a="1793003342:sNHT31402382" Received: from [10.32.244.211] (stealth-10-32-244-211.cisco.com [10.32.244.211]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k37NUN1j014808; Fri, 7 Apr 2006 16:30:23 -0700 (PDT) Message-ID: <4436F619.5060208@cisco.com> Date: Fri, 07 Apr 2006 16:30:33 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti References: <6.2.5.6.2.20060406094758.059a5528@qualcomm.com> In-Reply-To: <6.2.5.6.2.20060406094758.059a5528@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org Subject: [MSEC] Re: GDOI update document scoping questions 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Hi Laksminath, Lakshminath Dondeti wrote: > > > Hi Brian and Sheela, > > I raised a few questions on the scope of the GDOI Update document > (3547bis?). First, there is the issue of introducing AH support in > GDOI. I have a few questions here, first I would like the case for AH > support discussed on the list, so I will ask the question again that I > asked in Dallas. Why is AH support needed? Is ESP-NULL-Encryption not > sufficient? You're really asking why AH is relevant when ESP-NULL-Encryption could be used. There *is* a difference between the two, which is that AH authenticates the IP header whereas ESP does not. The IPsec community is used to thinking about VPN scenarios where authentication of the IP addresses seems irrelevant because there are just two endpoints sharing the keys anyway. However, in some group applications header authentication is valuable to prove that the *source* of the IP packet was not changed in transit. GDOI should support AH for those applications. For example, the Source-Specific Multicast architecture specification discusses the risks of spoofed source addresses. Another reason to support AH is that, for better or worse, some specifications dictate support for AH, and they are group applications. Most notably the PIM family of multicast routing protocols (PIM-DM, PIM-SM, PIM-Bidir) and OSPFv3. The protocols are often keyed manually and they deserve to use a dynamic key management system too! :-) > What if any changes are required to the MSEC-IPsec > extensions document due to the addition of AH support? Because RFC 4301 specifies AH as a valid (i.e., not deprecated) IPsec protocol, the MSEC-IPsec extensions document mentions it as well. > Second, what is the scope of the GDOI update document. Or is it open > ended? I am not really too particular about either approach (in > moderation of course, we don't want to redesign GDOI, just update, > hopefully with backward compatibility -- or is this is req that you have > in mind?). The scope we had in mind was 1) deal with hash agility, 2) clarifications to text based on implementation experience, and 3) minor additions to the protocol. Backward compatibility was intended if not explicitly stated. With this scope in mind, minor additions in addition to what we specified in the draft that maintain backward compatibility could be considered. Come to think of it, there's one other area we should add to the scope. The MSEC-IPsec extension document describes some additional key management attributes that would be new to GDOI. > While I am on topic, do you plan to introduce capabilities like > sender/receiver indication in GSA download? If this can be done without breaking backwards compatibility, it could make sense. We didn't intend to introduce it ourselves. > I think I promised to review the I-D this week, but it looks like my > schedule won't allow it, but will make it a higher priority next week. That'd be great, thanks! Brian > thanks and regards, > Lakshminath > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Apr 26 09:13:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYjpi-0001yk-J1 for msec-archive@lists.ietf.org; Wed, 26 Apr 2006 09:13:30 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYjpi-0003fR-9c for msec-archive@lists.ietf.org; Wed, 26 Apr 2006 09:13:30 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0811A2CCFF; Wed, 26 Apr 2006 09:13:28 -0400 (EDT) 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 50AED2CD7B for ; Wed, 26 Apr 2006 09:13:15 -0400 (EDT) Received: (qmail 63319 invoked by uid 3269); 26 Apr 2006 13:13:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63316 invoked from network); 26 Apr 2006 13:13:15 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 26 Apr 2006 13:13:15 -0000 Received: from victor.ndsuk.com (device.ndsuk.com [194.202.59.51]) by klesh.pair.com (Postfix) with ESMTP id C69B768352 for ; Wed, 26 Apr 2006 09:13:14 -0400 (EDT) Received: from victor.UK.NDS.COM ([192.168.24.204]) by victor.ndsuk.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 14:14:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 26 Apr 2006 14:13:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lehtovirta-srtp-rcc-01.txt for broadcast use Thread-Index: AcZpMyS4l/V7Whr4QXSRLF+0GewxkA== From: "Dallard, Nigel" To: , X-OriginalArrivalTime: 26 Apr 2006 13:14:22.0293 (UTC) FILETIME=[555B4050:01C66933] Cc: Subject: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 It is being proposed in the DVB standards group that this Internet draft be adopted in their specifications for broadcasting to mobile devices (DVB-H). Currently their specification A100 "Service Purchase and Protection" (see http://www.dvb-h-online.org/technology.htm) defines use of SRTP with authentication being optional. This internet draft appears to to enhance SRTP operation in a useful way for this application but, as it instatiates the Rollover Counter Carrying transform as an SRTP Authentication algorithm, its use seems to require that authentication becomes mandatory. The minimum level of authentication apparently allowed is authentication of every Rth SRTP packet using HMAC-SHA-1-80. Is this right, or have I misunderstood? For this broadcasting application, I would like to retain the use of authentication as optional, whilst using the method of carrying the ROC defined in this internet draft. It seems that the only way to do this would be to define an additional version of the RCC transform, which I shall call "RCCv3". I would envisage that RCCv3 would be similar to RCCv1, in that the authentication tag field would only be present in every Rth RTP packet. However, the content of the authentication tag field would consist only of ROC_sender, rather than ROC_sender || MAC. Would this be a sensible addition to the current draft, or is there a better solution? Regards, Nigel ** Nigel Dallard e-mail: ndallard@ndsuk.com **=20 ** Senior Member www: http://www.nds.com **=20 ** of Technical Staff tel: +44 23 8030 7151 **=20 ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 **=20 This email message and any attachments thereto are intended only for use = by the addressee(s) named above, and may contain legally privileged and/o= r confidential information. If the reader of this message is not the inte= nded recipient, or the employee or agent responsible to deliver it to the= intended recipient, you are hereby notified that any dissemination, dist= ribution or copying of this communication is strictly prohibited. If you = have received this communication in error, please immediately notify the = postmaster@nds.com and destroy the original message _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Apr 27 03:47:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ1Ds-0007bA-Ug for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 03:47:36 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ1Dp-0001ZX-HQ for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 03:47:36 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 132E32C986; Thu, 27 Apr 2006 03:47:33 -0400 (EDT) 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 A49082C975 for ; Thu, 27 Apr 2006 03:47:31 -0400 (EDT) Received: (qmail 48215 invoked by uid 3269); 27 Apr 2006 07:47:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48212 invoked from network); 27 Apr 2006 07:47:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Apr 2006 07:47:31 -0000 Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by klesh.pair.com (Postfix) with ESMTP id 46CE8683C1 for ; Thu, 27 Apr 2006 03:47:31 -0400 (EDT) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EF8A2AC1; Thu, 27 Apr 2006 09:47:29 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 09:47:29 +0200 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 09:47:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Date: Thu, 27 Apr 2006 09:47:29 +0200 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB02047F5726@esealmw104.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Thread-Index: AcZpMyS4l/V7Whr4QXSRLF+0GewxkAAmsQ/A From: "Karl Norrman \(KI/EAB\)" To: "Dallard, Nigel" X-OriginalArrivalTime: 27 Apr 2006 07:47:29.0580 (UTC) FILETIME=[D5AE7EC0:01C669CE] X-Brightmail-Tracker: AAAAAA== Cc: avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hello! The ROC needs to be integrity protected to ensure that it is not maliciously modified or subject to transmission bit errors en route. If the receiver starts using a ROC that has been modified during transmission, the receiver will be out of synch. Since in "normal" SRTP operation, the ROC is never transmitted=20 in-band, an unprotected transmission of ROC would therefore _add_=20 a vulnerability that is -_not_ present in RFC3711. You are correct when you say that it is necessary to include the MAC on each R:th packet. If one is worried about the bandwidth consumption of a MAC of 80 bits per R:th packet, one could put the length of the MAC (n_tag parameter in SRTP) to something less, e.g., 32 bits. Note that it is not mandatory to integrity protect every packet, only the ones=20 carrying the ROC.=20 Regards, Karl > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of Dallard, Nigel > Sent: den 26 april 2006 15:13 > To: avt@ietf.org; msec@securemulticast.org > Subject: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use >=20 >=20 > It is being proposed in the DVB standards group that this=20 > Internet draft be adopted in their specifications for=20 > broadcasting to mobile devices (DVB-H). >=20 > Currently their specification A100 "Service Purchase and Protection" > (see http://www.dvb-h-online.org/technology.htm) defines use=20 > of SRTP with authentication being optional. >=20 > This internet draft appears to to enhance SRTP operation in a=20 > useful way for this application but, as it instatiates the=20 > Rollover Counter Carrying transform as an SRTP Authentication=20 > algorithm, its use seems to require that authentication=20 > becomes mandatory. The minimum level of authentication=20 > apparently allowed is authentication of every Rth SRTP packet=20 > using HMAC-SHA-1-80. >=20 > Is this right, or have I misunderstood? >=20 > For this broadcasting application, I would like to retain the=20 > use of authentication as optional, whilst using the method of=20 > carrying the ROC defined in this internet draft. It seems=20 > that the only way to do this would be to define an additional=20 > version of the RCC transform, which I shall call "RCCv3". >=20 > I would envisage that RCCv3 would be similar to RCCv1, in=20 > that the authentication tag field would only be present in=20 > every Rth RTP packet. > However, the content of the authentication tag field would=20 > consist only of ROC_sender, rather than ROC_sender || MAC. >=20 > Would this be a sensible addition to the current draft, or is=20 > there a better solution? >=20 > Regards, >=20 > Nigel >=20 >=20 >=20 > ** Nigel Dallard e-mail: ndallard@ndsuk.com **=20 > ** Senior Member www: http://www.nds.com **=20 > ** of Technical Staff tel: +44 23 8030 7151 **=20 > ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 **=20 >=20 > This email message and any attachments thereto are intended=20 > only for use by the addressee(s) named above, and may contain=20 > legally privileged and/or confidential information. If the=20 > reader of this message is not the intended recipient, or the=20 > employee or agent responsible to deliver it to the intended=20 > recipient, you are hereby notified that any dissemination,=20 > distribution or copying of this communication is strictly=20 > prohibited. If you have received this communication in error,=20 > please immediately notify the postmaster@nds.com and destroy=20 > the original message _______________________________________________ > 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 Apr 27 05:33:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ2sQ-00078K-CI for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 05:33:34 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ2sP-0008Kx-2M for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 05:33:34 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C38092BEA7; Thu, 27 Apr 2006 05:33:32 -0400 (EDT) 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 E9B0E2BE9B for ; Thu, 27 Apr 2006 05:33:30 -0400 (EDT) Received: (qmail 71742 invoked by uid 3269); 27 Apr 2006 09:33:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71739 invoked from network); 27 Apr 2006 09:33:30 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Apr 2006 09:33:30 -0000 Received: from victor.ndsuk.com (device.ndsuk.com [194.202.59.51]) by klesh.pair.com (Postfix) with ESMTP id E45C6683AC for ; Thu, 27 Apr 2006 05:33:29 -0400 (EDT) Received: from victor.UK.NDS.COM ([192.168.24.204]) by victor.ndsuk.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 10:34:39 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Date: Thu, 27 Apr 2006 10:33:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Thread-Index: AcZpMyS4l/V7Whr4QXSRLF+0GewxkAAmsQ/AAABJmnA= From: "Dallard, Nigel" To: "Karl Norrman \(KI/EAB\)" X-OriginalArrivalTime: 27 Apr 2006 09:34:39.0516 (UTC) FILETIME=[CE38DDC0:01C669DD] Cc: avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe > From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com]=20 > The ROC needs to be integrity protected to ensure that it is > not maliciously modified or subject to transmission bit errors > en route. If the receiver starts using a ROC that has been modified > during transmission, the receiver will be out of synch. > Since in "normal" SRTP operation, the ROC is never transmitted=20 > in-band, an unprotected transmission of ROC would therefore _add_=20 > a vulnerability that is -_not_ present in RFC3711. Hi there Karl, I accept what you are saying, however, in the particular application I am concerned about... 1. Forward error protection is dealt with at a lower level in the protocol stack. It should be a very rare occurrence that an erroneous ROC value reaches the descramber in the ROC. The worst-case scenario would be that the receiver would be out of sync for R packets. The broadcaster has the ability to trade the impact of such loss of sync against bit-rate by varying the value of R. 2. Malicious modification is not necessarily a concern in a broadcast environment. Your TV does not, today, authenticate the source of the TV signal. I believe that if the system/network operator, having performed a risk assessment (along the lines of that described in Section 9 of RFC3711, for example), would prefer to trade bit-rate against the possibility of loss of ROC sync or the ability of receivers to authenticate the source of his signals, he should be able to do so. > You are correct when you say that it is necessary to include the MAC > on each R:th packet. If one is worried about the bandwidth=20 > consumption of a MAC of 80 bits per R:th packet, one could put the > length of the MAC (n_tag parameter in SRTP) to something less, e.g., > 32 bits. Yes, I understand this. I'd like to effectively set n_tag to 0 :-) Cheers, Nigel ** Nigel Dallard e-mail: ndallard@ndsuk.com **=20 ** Senior Member www: http://www.nds.com **=20 ** of Technical Staff tel: +44 23 8030 7151 **=20 ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 **=20 This email message and any attachments thereto are intended only for use = by the addressee(s) named above, and may contain legally privileged and/o= r confidential information. If the reader of this message is not the inte= nded recipient, or the employee or agent responsible to deliver it to the= intended recipient, you are hereby notified that any dissemination, dist= ribution or copying of this communication is strictly prohibited. If you = have received this communication in error, please immediately notify the = postmaster@nds.com and destroy the original message _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Apr 27 08:28:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ5bp-0006mt-3F for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 08:28:37 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ5bn-000154-Mh for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 08:28:37 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5F5832C979; Thu, 27 Apr 2006 08:28:29 -0400 (EDT) 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 A832C2C975 for ; Thu, 27 Apr 2006 08:28:27 -0400 (EDT) Received: (qmail 28782 invoked by uid 3269); 27 Apr 2006 12:28:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28779 invoked from network); 27 Apr 2006 12:28:27 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Apr 2006 12:28:27 -0000 Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by klesh.pair.com (Postfix) with ESMTP id 38AAC6838E for ; Thu, 27 Apr 2006 08:28:27 -0400 (EDT) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4EF504F0001; Thu, 27 Apr 2006 14:28:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 14:28:25 +0200 Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 14:28:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Date: Thu, 27 Apr 2006 14:28:23 +0200 Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB02047F5E36@esealmw104.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Thread-Index: AcZpMyS4l/V7Whr4QXSRLF+0GewxkAAmsQ/AAABJmnAACZjqMA== From: "Karl Norrman \(KI/EAB\)" To: "Dallard, Nigel" X-OriginalArrivalTime: 27 Apr 2006 12:28:25.0056 (UTC) FILETIME=[14540600:01C669F6] X-Brightmail-Tracker: AAAAAA== Cc: avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hello! You have a point in that there are specialized environments where a=20 NULL-MAC potentially could be acceptable after a proper threat/risk=20 analysis. Do other people on this list consider this a valuable addition to the draft?=20 Regards, Karl > -----Original Message----- > From: Dallard, Nigel [mailto:NDallard@ndsuk.com]=20 > Sent: den 27 april 2006 11:33 > To: Karl Norrman (KI/EAB) > Cc: avt@ietf.org; msec@securemulticast.org > Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use >=20 > > From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com] >=20 > > The ROC needs to be integrity protected to ensure that it is not=20 > > maliciously modified or subject to transmission bit errors=20 > en route. =20 > > If the receiver starts using a ROC that has been modified during=20 > > transmission, the receiver will be out of synch. > > Since in "normal" SRTP operation, the ROC is never transmitted=20 > > in-band, an unprotected transmission of ROC would therefore _add_ a=20 > > vulnerability that is -_not_ present in RFC3711. >=20 > Hi there Karl, >=20 > I accept what you are saying, however, in the particular=20 > application I am concerned about... >=20 > 1. Forward error protection is dealt with at a lower level in=20 > the protocol stack. It should be a very rare occurrence that=20 > an erroneous ROC value reaches the descramber in the ROC. The=20 > worst-case scenario would be that the receiver would be out=20 > of sync for R packets. The broadcaster has the ability to=20 > trade the impact of such loss of sync against bit-rate by=20 > varying the value of R. >=20 > 2. Malicious modification is not necessarily a concern in a=20 > broadcast environment. Your TV does not, today, authenticate=20 > the source of the TV signal. >=20 > I believe that if the system/network operator, having=20 > performed a risk assessment (along the lines of that=20 > described in Section 9 of RFC3711, for example), would prefer=20 > to trade bit-rate against the possibility of loss of ROC sync=20 > or the ability of receivers to authenticate the source of his=20 > signals, he should be able to do so. >=20 > > You are correct when you say that it is necessary to=20 > include the MAC=20 > > on each R:th packet. If one is worried about the bandwidth=20 > > consumption of a MAC of 80 bits per R:th packet, one could put the=20 > > length of the MAC (n_tag parameter in SRTP) to something less, e.g., > > 32 bits. >=20 > Yes, I understand this. I'd like to effectively set n_tag to 0 :-) >=20 > Cheers, >=20 > Nigel >=20 >=20 >=20 > ** Nigel Dallard e-mail: ndallard@ndsuk.com **=20 > ** Senior Member www: http://www.nds.com **=20 > ** of Technical Staff tel: +44 23 8030 7151 **=20 > ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 **=20 >=20 > This email message and any attachments thereto are intended=20 > only for use by the addressee(s) named above, and may contain=20 > legally privileged and/or confidential information. If the=20 > reader of this message is not the intended recipient, or the=20 > employee or agent responsible to deliver it to the intended=20 > recipient, you are hereby notified that any dissemination,=20 > distribution or copying of this communication is strictly=20 > prohibited. If you have received this communication in error,=20 > please immediately notify the postmaster@nds.com and destroy=20 > the original message >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Apr 27 18:07:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZEdb-0007uF-D5 for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 18:07:03 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZEdb-0006TN-0S for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 18:07:03 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B56E42CC83; Thu, 27 Apr 2006 18:07:02 -0400 (EDT) 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 408DD2CC7D for ; Thu, 27 Apr 2006 18:07:01 -0400 (EDT) Received: (qmail 95704 invoked by uid 3269); 27 Apr 2006 22:07:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95701 invoked from network); 27 Apr 2006 22:07:01 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Apr 2006 22:07:01 -0000 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by klesh.pair.com (Postfix) with ESMTP id D4D6C683B0 for ; Thu, 27 Apr 2006 18:07:00 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Apr 2006 15:06:58 -0700 X-IronPort-AV: i="4.04,162,1144047600"; d="scan'208"; a="1799370158:sNHT33630654" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3RM6vVI004385; Thu, 27 Apr 2006 15:06:57 -0700 (PDT) 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, 27 Apr 2006 15:06:57 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 15:06:56 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F0359C6-874A-4730-9483-775A39EBCA1A@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Date: Thu, 27 Apr 2006 15:06:54 -0700 To: "Dallard, Nigel" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 27 Apr 2006 22:06:56.0575 (UTC) FILETIME=[E6017CF0:01C66A46] Cc: "Karl Norrman \(KI/EAB\)" , avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Hi Nigel, On Apr 27, 2006, at 2:33 AM, Dallard, Nigel wrote: >> From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com] > >> The ROC needs to be integrity protected to ensure that it is >> not maliciously modified or subject to transmission bit errors >> en route. If the receiver starts using a ROC that has been modified >> during transmission, the receiver will be out of synch. >> Since in "normal" SRTP operation, the ROC is never transmitted >> in-band, an unprotected transmission of ROC would therefore _add_ >> a vulnerability that is -_not_ present in RFC3711. I second Karl's concern - RCC used without authentication introduces a new vulnerability. > > Hi there Karl, > > I accept what you are saying, however, in the particular application I > am concerned about... > > 1. Forward error protection is dealt with at a lower level in the > protocol stack. It should be a very rare occurrence that an erroneous > ROC value reaches the descramber in the ROC. The worst-case scenario > would be that the receiver would be out of sync for R packets. The > broadcaster has the ability to trade the impact of such loss of sync > against bit-rate by varying the value of R. > > 2. Malicious modification is not necessarily a concern in a broadcast > environment. Your TV does not, today, authenticate the source of > the TV > signal. > This makes sense - confidentiality is the main goal in a broadcast TV scenario, and authentication would be secondary. One of the concerns with security protocols is that sometimes the lack of authentication can induce a loss of confidentiality, but if you are transmitting audio/video/media only (as opposed to e.g. DTMF), that's probably not an issue in your scenario. I'm curious: are there any higher-level checksums on the application data that would catch the decryption error that would result from ROC de-synch? If not, how would the codec respond to seemingly random inputs? > I believe that if the system/network operator, having performed a risk > assessment (along the lines of that described in Section 9 of RFC3711, > for example), would prefer to trade bit-rate against the > possibility of > loss of ROC sync or the ability of receivers to authenticate the > source > of his signals, he should be able to do so. I'm not sure that I'd make that tradeoff. If there are system constraints (e.g. on packet size) that would prevent the use of authentication, that's one thing. But IIRC you're securing video broadcasts, and video packets are typically fairly large. What fraction of the bandwidth would be consumed by a 32-bit authentication tag on every Rth packet? Also, consider that with RCC as currently defined the 32-bit rollover counter is being included in every Rth packet - so there is already some bandwidth loss that's being incurred just for using RCC. > >> You are correct when you say that it is necessary to include the MAC >> on each R:th packet. If one is worried about the bandwidth >> consumption of a MAC of 80 bits per R:th packet, one could put the >> length of the MAC (n_tag parameter in SRTP) to something less, e.g., >> 32 bits. > > Yes, I understand this. I'd like to effectively set n_tag to 0 :-) > If you're interested in seeing a standard that supports the option you're describing, I suspect that people in the security area will ask you to provide the sort of analysis that you mention above. Have you considered using the "Encrypted Key Transport for SRTP" method, which provides ROC synchronization as well as some other features that are attractive in multi-participant RTP sessions? It doesn't increase the bandwidth usage (it eats into RTCP's bandwidth allocation, not RTP's bandwidth allocation - it robs Peter instead of Paul, so to speak :-). Best regards, David > Cheers, > > Nigel > > > > ** Nigel Dallard e-mail: ndallard@ndsuk.com ** > ** Senior Member www: http://www.nds.com ** > ** of Technical Staff tel: +44 23 8030 7151 ** > ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 ** > > This email message and any attachments thereto are intended only > for use by the addressee(s) named above, and may contain legally > privileged and/or confidential information. If the reader of this > message is not the intended recipient, or the employee or agent > responsible to deliver it to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please immediately notify the > postmaster@nds.com and destroy the original message > _______________________________________________ > 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 Apr 27 22:54:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZJ8E-0003WG-2X for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 22:54:58 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZJ8D-0006O8-K5 for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 22:54:58 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 334012C778; Thu, 27 Apr 2006 22:54:51 -0400 (EDT) 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 166622C76B for ; Thu, 27 Apr 2006 22:54:50 -0400 (EDT) Received: (qmail 55545 invoked by uid 3269); 28 Apr 2006 02:54:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55542 invoked from network); 28 Apr 2006 02:54:49 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Apr 2006 02:54:49 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id AB2E568367 for ; Thu, 27 Apr 2006 22:54:49 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11.20060308/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k3S2t25n002875; Thu, 27 Apr 2006 22:55:02 -0400 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 k3S2sb4298910; Thu, 27 Apr 2006 22:54:37 -0400 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 k3S2saG298908; Thu, 27 Apr 2006 22:54:36 -0400 Received: from sibylla.watson.ibm.com (sibylla.watson.ibm.com [9.2.16.101]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id k3S3nmje021437; Thu, 27 Apr 2006 23:49:48 -0400 Received: from localhost (canetti@localhost) by sibylla.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id k3S2sYq36154; Thu, 27 Apr 2006 22:54:34 -0400 Date: Thu, 27 Apr 2006 22:54:34 -0400 (EDT) From: canetti To: David McGrew Subject: Re: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use In-Reply-To: <3F0359C6-874A-4730-9483-775A39EBCA1A@cisco.com> Message-ID: References: <3F0359C6-874A-4730-9483-775A39EBCA1A@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Karl Norrman \(KI/EAB\)" , "Dallard, Nigel" , avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Two points: 1. I don't see a reason why authentication should not be a security concern for TV transmissions. I guess that when some hacker redirects a porn movie to the cartoon channel on sunday morning the problem will get appropriate attention... 2. If we're talking about broadcast where all recipients use the same key then just using HMAC (or any other MAC) is not good enough, since anyone who has the key can forge. A more sophisticated solution is needed. Ran On Thu, 27 Apr 2006, David McGrew wrote: > Hi Nigel, > > On Apr 27, 2006, at 2:33 AM, Dallard, Nigel wrote: > > >> From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com] > > > >> The ROC needs to be integrity protected to ensure that it is > >> not maliciously modified or subject to transmission bit errors > >> en route. If the receiver starts using a ROC that has been modified > >> during transmission, the receiver will be out of synch. > >> Since in "normal" SRTP operation, the ROC is never transmitted > >> in-band, an unprotected transmission of ROC would therefore _add_ > >> a vulnerability that is -_not_ present in RFC3711. > > I second Karl's concern - RCC used without authentication introduces > a new vulnerability. > > > > > Hi there Karl, > > > > I accept what you are saying, however, in the particular application I > > am concerned about... > > > > 1. Forward error protection is dealt with at a lower level in the > > protocol stack. It should be a very rare occurrence that an erroneous > > ROC value reaches the descramber in the ROC. The worst-case scenario > > would be that the receiver would be out of sync for R packets. The > > broadcaster has the ability to trade the impact of such loss of sync > > against bit-rate by varying the value of R. > > > > 2. Malicious modification is not necessarily a concern in a broadcast > > environment. Your TV does not, today, authenticate the source of > > the TV > > signal. > > > > This makes sense - confidentiality is the main goal in a broadcast TV > scenario, and authentication would be secondary. One of the concerns > with security protocols is that sometimes the lack of authentication > can induce a loss of confidentiality, but if you are transmitting > audio/video/media only (as opposed to e.g. DTMF), that's probably not > an issue in your scenario. > > I'm curious: are there any higher-level checksums on the application > data that would catch the decryption error that would result from ROC > de-synch? If not, how would the codec respond to seemingly random > inputs? > > > I believe that if the system/network operator, having performed a risk > > assessment (along the lines of that described in Section 9 of RFC3711, > > for example), would prefer to trade bit-rate against the > > possibility of > > loss of ROC sync or the ability of receivers to authenticate the > > source > > of his signals, he should be able to do so. > > I'm not sure that I'd make that tradeoff. If there are system > constraints (e.g. on packet size) that would prevent the use of > authentication, that's one thing. But IIRC you're securing video > broadcasts, and video packets are typically fairly large. What > fraction of the bandwidth would be consumed by a 32-bit > authentication tag on every Rth packet? Also, consider that with RCC > as currently defined the 32-bit rollover counter is being included in > every Rth packet - so there is already some bandwidth loss that's > being incurred just for using RCC. > > > > >> You are correct when you say that it is necessary to include the MAC > >> on each R:th packet. If one is worried about the bandwidth > >> consumption of a MAC of 80 bits per R:th packet, one could put the > >> length of the MAC (n_tag parameter in SRTP) to something less, e.g., > >> 32 bits. > > > > Yes, I understand this. I'd like to effectively set n_tag to 0 :-) > > > > If you're interested in seeing a standard that supports the option > you're describing, I suspect that people in the security area will > ask you to provide the sort of analysis that you mention above. > > Have you considered using the "Encrypted Key Transport for SRTP" > method, which provides ROC synchronization as well as some other > features that are attractive in multi-participant RTP sessions? It > doesn't increase the bandwidth usage (it eats into RTCP's bandwidth > allocation, not RTP's bandwidth allocation - it robs Peter instead of > Paul, so to speak :-). > > Best regards, > > David > > > Cheers, > > > > Nigel > > > > > > > > ** Nigel Dallard e-mail: ndallard@ndsuk.com ** > > ** Senior Member www: http://www.nds.com ** > > ** of Technical Staff tel: +44 23 8030 7151 ** > > ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 ** > > > > This email message and any attachments thereto are intended only > > for use by the addressee(s) named above, and may contain legally > > privileged and/or confidential information. If the reader of this > > message is not the intended recipient, or the employee or agent > > responsible to deliver it to the intended recipient, you are hereby > > notified that any dissemination, distribution or copying of this > > communication is strictly prohibited. If you have received this > > communication in error, please immediately notify the > > postmaster@nds.com and destroy the original message > > _______________________________________________ > > 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 Apr 27 23:45:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZJuj-0008Tp-LF for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 23:45:05 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZJuj-0001gk-7P for msec-archive@lists.ietf.org; Thu, 27 Apr 2006 23:45:05 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 215AB2C716; Thu, 27 Apr 2006 23:45:04 -0400 (EDT) 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 B43B32C713 for ; Thu, 27 Apr 2006 23:45:02 -0400 (EDT) Received: (qmail 65966 invoked by uid 3269); 28 Apr 2006 03:45:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65963 invoked from network); 28 Apr 2006 03:45:02 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Apr 2006 03:45:02 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 44BA068362 for ; Thu, 27 Apr 2006 23:45:02 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3S3iket032289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2006 20:44:46 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-86.qualcomm.com [10.50.72.86]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3S3iiDG004426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Apr 2006 20:44:44 -0700 (PDT) Message-Id: <6.2.5.6.2.20060427202856.04159758@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 Apr 2006 20:44:40 -0700 To: canetti@csail.mit.edu, David McGrew From: Lakshminath Dondeti Subject: Re: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use In-Reply-To: References: <3F0359C6-874A-4730-9483-775A39EBCA1A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Karl Norrman \(KI/EAB\)" , "Dallard, Nigel" , avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f At 07:54 PM 4/27/2006, canetti wrote: >Two points: > >1. I don't see a reason why authentication should not be a security >concern for TV transmissions. I guess that when some hacker >redirects a porn movie to the cartoon channel on sunday morning the >problem will get appropriate attention... Not to disagree, but to understand this problem better: wouldn't the two programs be protected with different program (encryption) keys? In that case, terminals that don't have keys can't decrypt the redirected program. The threat is that one of the entities which has the encryption keys sends the redirects the wrong program to the wrong channel. The additional assumption, at least in some systems is that the adversary can also transmit (which some people think is hard to do, but not anywhere close to "hard" in the cryptographic or computational sense. There are legal and monetary considerations, but none of those come close to the typical crypto computational complexity and the considerations thereof.) But, in those cases though, Ran's point (2) below applies. However, no (planned commercial) broadcast system today employs source authentication schemes. So the question is, since group authentication doesn't buy anything (if an entity can "transmit" it can go to the lengths of obtaining the symmetric key, which a relatively cheaper subscription makes available to anyone who signs up for the service), does it make sense to use group authentication? The other question that was asked of me recently is that if codec-level "error" correction (can people clued in in that area clarify what that means) results in better rendering of content, does it make sense to turn off integrity protection? Thoughts? regards, Lakshminath >2. If we're talking about broadcast where all recipients use the same key >then just using HMAC (or any other MAC) is not good enough, since anyone >who has the key can forge. A more sophisticated solution is needed. > >Ran > > >On Thu, 27 Apr 2006, David McGrew wrote: > > > Hi Nigel, > > > > On Apr 27, 2006, at 2:33 AM, Dallard, Nigel wrote: > > > > >> From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com] > > > > > >> The ROC needs to be integrity protected to ensure that it is > > >> not maliciously modified or subject to transmission bit errors > > >> en route. If the receiver starts using a ROC that has been modified > > >> during transmission, the receiver will be out of synch. > > >> Since in "normal" SRTP operation, the ROC is never transmitted > > >> in-band, an unprotected transmission of ROC would therefore _add_ > > >> a vulnerability that is -_not_ present in RFC3711. > > > > I second Karl's concern - RCC used without authentication introduces > > a new vulnerability. > > > > > > > > Hi there Karl, > > > > > > I accept what you are saying, however, in the particular application I > > > am concerned about... > > > > > > 1. Forward error protection is dealt with at a lower level in the > > > protocol stack. It should be a very rare occurrence that an erroneous > > > ROC value reaches the descramber in the ROC. The worst-case scenario > > > would be that the receiver would be out of sync for R packets. The > > > broadcaster has the ability to trade the impact of such loss of sync > > > against bit-rate by varying the value of R. > > > > > > 2. Malicious modification is not necessarily a concern in a broadcast > > > environment. Your TV does not, today, authenticate the source of > > > the TV > > > signal. > > > > > > > This makes sense - confidentiality is the main goal in a broadcast TV > > scenario, and authentication would be secondary. One of the concerns > > with security protocols is that sometimes the lack of authentication > > can induce a loss of confidentiality, but if you are transmitting > > audio/video/media only (as opposed to e.g. DTMF), that's probably not > > an issue in your scenario. > > > > I'm curious: are there any higher-level checksums on the application > > data that would catch the decryption error that would result from ROC > > de-synch? If not, how would the codec respond to seemingly random > > inputs? > > > > > I believe that if the system/network operator, having performed a risk > > > assessment (along the lines of that described in Section 9 of RFC3711, > > > for example), would prefer to trade bit-rate against the > > > possibility of > > > loss of ROC sync or the ability of receivers to authenticate the > > > source > > > of his signals, he should be able to do so. > > > > I'm not sure that I'd make that tradeoff. If there are system > > constraints (e.g. on packet size) that would prevent the use of > > authentication, that's one thing. But IIRC you're securing video > > broadcasts, and video packets are typically fairly large. What > > fraction of the bandwidth would be consumed by a 32-bit > > authentication tag on every Rth packet? Also, consider that with RCC > > as currently defined the 32-bit rollover counter is being included in > > every Rth packet - so there is already some bandwidth loss that's > > being incurred just for using RCC. > > > > > > > >> You are correct when you say that it is necessary to include the MAC > > >> on each R:th packet. If one is worried about the bandwidth > > >> consumption of a MAC of 80 bits per R:th packet, one could put the > > >> length of the MAC (n_tag parameter in SRTP) to something less, e.g., > > >> 32 bits. > > > > > > Yes, I understand this. I'd like to effectively set n_tag to 0 :-) > > > > > > > If you're interested in seeing a standard that supports the option > > you're describing, I suspect that people in the security area will > > ask you to provide the sort of analysis that you mention above. > > > > Have you considered using the "Encrypted Key Transport for SRTP" > > method, which provides ROC synchronization as well as some other > > features that are attractive in multi-participant RTP sessions? It > > doesn't increase the bandwidth usage (it eats into RTCP's bandwidth > > allocation, not RTP's bandwidth allocation - it robs Peter instead of > > Paul, so to speak :-). > > > > Best regards, > > > > David > > > > > Cheers, > > > > > > Nigel > > > > > > > > > > > > ** Nigel Dallard e-mail: ndallard@ndsuk.com ** > > > ** Senior Member www: http://www.nds.com ** > > > ** of Technical Staff tel: +44 23 8030 7151 ** > > > ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 ** > > > > > > This email message and any attachments thereto are intended only > > > for use by the addressee(s) named above, and may contain legally > > > privileged and/or confidential information. If the reader of this > > > message is not the intended recipient, or the employee or agent > > > responsible to deliver it to the intended recipient, you are hereby > > > notified that any dissemination, distribution or copying of this > > > communication is strictly prohibited. If you have received this > > > communication in error, please immediately notify the > > > postmaster@nds.com and destroy the original message > > > _______________________________________________ > > > 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 Fri Apr 28 04:15:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZO8i-0001S7-CK for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 04:15:48 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZO8h-00010Z-23 for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 04:15:48 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 92E4F2C8BB; Fri, 28 Apr 2006 04:15:46 -0400 (EDT) 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 7B3822C897 for ; Fri, 28 Apr 2006 04:15:45 -0400 (EDT) Received: (qmail 46747 invoked by uid 3269); 28 Apr 2006 08:15:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46744 invoked from network); 28 Apr 2006 08:15:45 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Apr 2006 08:15:45 -0000 Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by klesh.pair.com (Postfix) with ESMTP id F330A6836B for ; Fri, 28 Apr 2006 04:15:44 -0400 (EDT) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9529F4F0002; Fri, 28 Apr 2006 10:15:20 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:15:20 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:15:19 +0200 Message-ID: <4451CF17.2030206@ericsson.com> Date: Fri, 28 Apr 2006 10:15:19 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use References: <3F0359C6-874A-4730-9483-775A39EBCA1A@cisco.com> <6.2.5.6.2.20060427202856.04159758@qualcomm.com> In-Reply-To: <6.2.5.6.2.20060427202856.04159758@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 08:15:19.0848 (UTC) FILETIME=[E3A6EA80:01C66A9B] X-Brightmail-Tracker: AAAAAA== Cc: "Dallard, Nigel" , avt@ietf.org, msec@securemulticast.org, David McGrew , "Karl Norrman \(KI/EAB\)" , canetti@csail.mit.edu 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Lakshminath Dondeti wrote: > The other question that was asked of me recently is that if codec-level > "error" correction (can people clued in in that area clarify what that > means) results in better rendering of content, does it make sense to > turn off integrity protection? Thoughts? > What I assume they mean is the use of unequal error correction and then have an unequal error detection that allows you to discern between errors in the critical parts and errors in the non-critical. For IP the existing specifications in this regards are UDP-Lite that allows the UDP checksum to be applied to only parts of the payload. Then there exist a few RTP payload formats that have data structured in such a way that the least important data is at the end of the packet. The codec then can use data with errors to do error concealment that is better than not having any data at all. AMR and AMR-WB do have these features and some of the video codecs are also capable of producing packets where this will work. The big issue with this system is that it doesn't provide any knowledge about how badly damaged the unprotected part has suffered. This is very relevant because the amount of bit-errors that these can tolerate in the unprotected parts varies with the codec. This have created a situation where use of UDP-Lite is from a management point of view is undeployable. We don't have mechanism in place to provide the end to end path with information on how much bit-errors the individual packet flows can handle, nor a way of handling the accumulation received from multiple links. It was a nice idea and it is in use for non-generic systems, one example is for all the GSM circuit switched voice. In those cases the codec and the link correction and detection mechanism is tailored for the codec so that the right error behavior is achieved. So I would not design any special solution for this. It has been available to try since 2002 or so. I have not heard about any deployment of this. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Apr 28 12:27:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVo4-0001uh-PP for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 12:27:00 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVo2-0003qD-Df for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 12:27:00 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3DA822CE72; Fri, 28 Apr 2006 12:18:27 -0400 (EDT) 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 B1D622CB09 for ; Fri, 28 Apr 2006 11:45:09 -0400 (EDT) Received: (qmail 46395 invoked by uid 3269); 28 Apr 2006 15:45:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46392 invoked from network); 28 Apr 2006 15:45:09 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Apr 2006 15:45:09 -0000 Received: from victor.ndsuk.com (device.ndsuk.com [194.202.59.51]) by klesh.pair.com (Postfix) with ESMTP id 49A7468386 for ; Fri, 28 Apr 2006 11:45:09 -0400 (EDT) Received: from victor.UK.NDS.COM ([192.168.24.204]) by victor.ndsuk.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 16:46:23 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Date: Fri, 28 Apr 2006 16:45:06 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use Thread-Index: AcZqRuhXRd4gJqzoT9OGZf4FpbpdpwAj0ciw From: "Dallard, Nigel" To: "David McGrew" X-OriginalArrivalTime: 28 Apr 2006 15:46:23.0508 (UTC) FILETIME=[E6D9B540:01C66ADA] Cc: avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 > From: David McGrew [mailto:mcgrew@cisco.com]=20 > I'm curious: are there any higher-level checksums on the application =20= > data that would catch the decryption error that would result from > ROC de-synch? If not, how would the codec respond to seemingly > random inputs? Hi there David, No, there are not usually any checksums on the application data. MPEG A/V decoders used in TV broadcasting systems are pretty robust at recovering from errored bitstreams and concealing lost data from the viewer (via interpolation, etc). Loss of crypto-sync would just look like horrendous bit-errors to the decoder. > I'm not sure that I'd make that tradeoff. If there are system =20 > constraints (e.g. on packet size) that would prevent the use of =20 > authentication, that's one thing. But IIRC you're securing video =20 > broadcasts, and video packets are typically fairly large. Whilst it is true that a complete compressed video frame may be quite large, typically in broadcast TV systems, the compressed video stream is split into relatively small packets (payload of 184 bytes if using the MPEG-2 Transport Stream, for example). Whilst I'm not suggesting that each SRTP packet be that small, I don't expect a whole video frame to be transported in a single RTP packet. > Also, consider that with RCC as currently defined the 32-bit > rollover counter is being included in every Rth packet - so > there is already some bandwidth loss that's being incurred > just for using RCC. There is indeed, but we need to convey the ROC anyway, and the alternative is in the Key Stream Message, which in broadcast TV systems is sent several times a second. All we're doing here is moving the ROC delivery from out-of-band to in-band. Operators would then select "R" according to how they wish to trade-off bandwidth vs random-access time/crypto-sync loss recovery time. > If you're interested in seeing a standard that supports the option =20 > you're describing, I suspect that people in the security area will =20 > ask you to provide the sort of analysis that you mention above. OK, I could look at working on that, but really all I'm asking for is the OPTION to turn off authentication if *I* decide, for *MY* service, that I don't need it. SRTP already allows me that option, although it is clearly marked as not to be used lightly. I'm just asking for that option to be retained if I use RCC to convey the ROC. Do I really need to provide a security analysis to retain an option that is already present in RFC3711? > Have you considered using the "Encrypted Key Transport for SRTP" =20 > method, which provides ROC synchronization as well as some other =20 > features that are attractive in multi-participant RTP sessions? It =20= > doesn't increase the bandwidth usage (it eats into RTCP's bandwidth =20= > allocation, not RTP's bandwidth allocation - it robs Peter=20 > instead of Paul, so to speak :-). I haven't, but will do so. However, the use of RCC has been/is in the process of being adopted by various broadcast standards organisations, and it might be difficult to get them all to change direction at this stage. A slight modification to RCC would allow these various standards to both proceed and remain harmonised, whilst retaining the operator's choice as far as authenticating streams. Regards, Nigel ** Nigel Dallard e-mail: ndallard@ndsuk.com **=20 ** Senior Member www: http://www.nds.com **=20 ** of Technical Staff tel: +44 23 8030 7151 **=20 ** NDS Ltd, Southampton, UK. mobile: +44 7881 913151 **=20 This email message and any attachments thereto are intended only for use = by the addressee(s) named above, and may contain legally privileged and/o= r confidential information. If the reader of this message is not the inte= nded recipient, or the employee or agent responsible to deliver it to the= intended recipient, you are hereby notified that any dissemination, dist= ribution or copying of this communication is strictly prohibited. If you = have received this communication in error, please immediately notify the = postmaster@nds.com and destroy the original message _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Apr 28 12:27:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZVoX-0002Cj-13 for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 12:27:29 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZVoW-0003ty-Lj for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 12:27:29 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5E0E22CEC2; Fri, 28 Apr 2006 12:19:42 -0400 (EDT) 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 4582D2C75B for ; Fri, 28 Apr 2006 11:59:38 -0400 (EDT) Received: (qmail 48564 invoked by uid 3269); 28 Apr 2006 15:59:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48561 invoked from network); 28 Apr 2006 15:59:38 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Apr 2006 15:59:38 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id 0D260683AA for ; Fri, 28 Apr 2006 11:59:38 -0400 (EDT) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11.20060308/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k3SFxqk4011574; Fri, 28 Apr 2006 11:59:52 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k3SFxS338076; Fri, 28 Apr 2006 11:59:28 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k3SFxRZ34644; Fri, 28 Apr 2006 11:59:27 -0400 Received: from sibylla.watson.ibm.com (sibylla.watson.ibm.com [9.2.16.101]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id k3SGsa1n013800; Fri, 28 Apr 2006 12:54:36 -0400 Received: from localhost (canetti@localhost) by sibylla.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id k3SFxKP33618; Fri, 28 Apr 2006 11:59:20 -0400 Date: Fri, 28 Apr 2006 11:59:20 -0400 (EDT) From: canetti To: Magnus Westerlund Subject: Re: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use In-Reply-To: <4451CF17.2030206@ericsson.com> Message-ID: References: <3F0359C6-874A-4730-9483-775A39EBCA1A@cisco.com> <6.2.5.6.2.20060427202856.04159758@qualcomm.com> <4451CF17.2030206@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: avt@ietf.org, msec@securemulticast.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Lakshminath, > Not to disagree, but to understand this problem better: wouldn't the > two programs be protected with different program (encryption) > keys? In that case, terminals that don't have keys can't decrypt the > redirected program. The threat is that one of the entities which has > the encryption keys sends the redirects the wrong program to the > wrong channel. The additional assumption, at least in some systems > is that the adversary can also transmit (which some people think is > hard to do, but not anywhere close to "hard" in the cryptographic or > computational sense. There are legal and monetary considerations, > but none of those come close to the typical crypto computational > complexity and the considerations thereof.) This is a great example of "encryption doesnt buy authentication": First, as you say, if the attacker has the keys for both transmissions then it can ofcourse re-encrypt. But even if not, it is often quite easy to change ecrypted stream A to encrypted stream B *without knowing the key*, say if the encryption is a stream cipher. (Here A=donald duck and B=your favorite porn). > But, in those cases though, Ran's point (2) below applies. However, > no (planned commercial) broadcast system today employs source > authentication schemes. That's exactly the worry. what's justified on a dedicated link such as cable TV is no longer justified in IPTV... > > So the question is, since group authentication doesn't buy anything > (if an entity can "transmit" it can go to the lengths of obtaining > the symmetric key, which a relatively cheaper subscription makes > available to anyone who signs up for the service), does it make sense > to use group authentication? Group authentication does give some leverage, since an attacker needs to either hack or bypass its receiver box so as to extract the authentication key. but cryptographically it indeed buys you next to nothing in this one-to-many setting. > > The other question that was asked of me recently is that if > codec-level "error" correction (can people clued in in that area > clarify what that means) results in better rendering of content, does > it make sense to turn off integrity protection? Thoughts? > I dont think that any keyless error correction scheme can provide authentication. An attacker can simply use the same encoding scheme as the real source. Best, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Apr 28 19:40:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZcZf-0008At-R6 for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 19:40:35 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZcZe-0006FD-Fe for msec-archive@lists.ietf.org; Fri, 28 Apr 2006 19:40:35 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 42E7F2C9D2; Fri, 28 Apr 2006 19:40:29 -0400 (EDT) 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 01E882C9A9 for ; Fri, 28 Apr 2006 19:40:28 -0400 (EDT) Received: (qmail 38135 invoked by uid 3269); 28 Apr 2006 23:40:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38127 invoked from network); 28 Apr 2006 23:40:27 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Apr 2006 23:40:27 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id E035168362 for ; Fri, 28 Apr 2006 19:40:26 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SNePSC008835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Apr 2006 16:40:25 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-120.qualcomm.com [10.50.64.120]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3SNeN1N028200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Apr 2006 16:40:24 -0700 (PDT) Message-Id: <6.2.5.6.2.20060428161116.058261b8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 28 Apr 2006 16:40:23 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.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 X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Strictly as an IETF contributor, I am requesting reviews on this document. This is an IANA registration request of a new GenExt payload for MIKEY. regards, Lakshminath >To: i-d-announce@ietf.org >Cc: >From: Internet-Drafts@ietf.org >Date: Fri, 28 Apr 2006 15:50:01 -0400 >X-Spam-Score: -2.6 (--) >X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 >Subject: I-D ACTION:draft-dondeti-msec-mikey-genext-oma-00.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >X-PMX-Version: 4.7.0.111621 >X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, >Antispam-Data: 2006.4.28.135109 >X-OriginalArrivalTime: 28 Apr 2006 21:15:10.0229 (UTC) >FILETIME=[D4E47450:01C66B08] > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : OMA BCAST MIKEY General Extension Payload > Specification > Author(s) : L. Dondeti, D. Castleford > Filename : draft-dondeti-msec-mikey-genext-oma-00.txt > Pages : 7 > Date : 2006-4-28 > > This document specifies a new general extension payload type for use > in the Open Mobile Alliance's (OMA) Browser and Content (BAC) > Broadcast (BCAST) group. OMA BCAST's service and content protection > specification uses short term key message (STKM) and long term key > message (LTKM) payloads that in certain broadcast distribution > systems (BDS) are carried in the IETF MIKEY protocol [1]. A new > MIKEY general extension payload specified in this document will be > used for that purpose. > > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-dondeti-msec-mikey-genext-oma-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body >of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-dondeti-msec-mikey-genext-oma-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-dondeti-msec-mikey-genext-oma-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2006-4-28135953.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-dondeti-msec-mikey-genext-oma-00.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec