From msec-bounces@securemulticast.org Fri Jul 01 12:00:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoNwY-0000u7-C1 for msec-archive@megatron.ietf.org; Fri, 01 Jul 2005 12:00:42 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09574 for ; Fri, 1 Jul 2005 12:00:39 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 49F1C8C727; Fri, 1 Jul 2005 12:00:41 -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 2769F8C6FA for ; Fri, 1 Jul 2005 12:00:40 -0400 (EDT) Received: (qmail 25506 invoked by uid 3269); 1 Jul 2005 16:00:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25501 invoked from network); 1 Jul 2005 16:00:38 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 1 Jul 2005 16:00:38 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j61G0Y2V020302 for ; Fri, 1 Jul 2005 09:00:35 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j61G0Vv5005541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 1 Jul 2005 09:00:32 -0700 (PDT) Message-ID: <42C568A0.10401@qualcomm.com> Date: Fri, 01 Jul 2005 12:00:32 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Repeating the request to review the 802.16e draft X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 all, I am in the middle of sending personal requests to MSEC regulars to review the 802.16e draft. All told only 20 pages need to be reviewed, and for folks on this list it is quite familiar text (TEKs, KEKs and rekeying :-)). Please let me know if you are interested and I will send a copy of the latest draft. thanks again and best regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jul 06 05:36:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq6K6-0000Un-IR for msec-archive@megatron.ietf.org; Wed, 06 Jul 2005 05:36:06 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05689 for ; Wed, 6 Jul 2005 05:36:03 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B993F8C361; Wed, 6 Jul 2005 05:36: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 8A48A8C11B for ; Wed, 6 Jul 2005 05:36:01 -0400 (EDT) Received: (qmail 55953 invoked by uid 3269); 6 Jul 2005 09:36:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55950 invoked from network); 6 Jul 2005 09:36:01 -0000 Received: from motgate8.mot.com (129.188.136.8) by klesh.pair.com with SMTP; 6 Jul 2005 09:36:01 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j669j0oX010102 for ; Wed, 6 Jul 2005 02:45:00 -0700 (MST) Received: from zfr27exm01.corp.mot.com (zfr27exm01.corp.mot.com [10.161.200.203]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j669et9C018131 for ; Wed, 6 Jul 2005 04:40:56 -0500 (CDT) Received: from [10.161.201.67] (zfr01-2067.crm.mot.com [10.161.201.67]) by zfr27exm01.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id NV3HR80G; Wed, 6 Jul 2005 11:35:59 +0200 Message-ID: <42CBA5FE.2040600@motorola.com> Date: Wed, 06 Jul 2005 11:35:58 +0200 From: Mounir Kellil User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Host access control to the multicast trees and Mobile IP impact 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 Dear all, We have recently published a paper in IEEE CST, Second Quarter Issue, 2005, which addresses the access control problem to the delivery tree (multicast receiver and sender access control). In our study we also investigated the implications of Mobile IP on the existing approaches. Both msec and mip(4/6) WGs are concerned with this contribution. For the msec community, the present study addresses a problem that is part of the multicast infrastructure security area. For further details, please visit the following link to IEEE CST Second Quarter Issue 2005. http://www.comsoc.org/livepubs/surveys/public/2005/apr/index.html Regards Mounir _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jul 06 11:32:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBse-0007Ea-Id for msec-archive@megatron.ietf.org; Wed, 06 Jul 2005 11:32:08 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11032 for ; Wed, 6 Jul 2005 11:32:05 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AA01A8C24E; Wed, 6 Jul 2005 11:32:06 -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 743EB8C010 for ; Wed, 6 Jul 2005 11:32:05 -0400 (EDT) Received: (qmail 21303 invoked by uid 3269); 6 Jul 2005 15:32:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21300 invoked from network); 6 Jul 2005 15:32:04 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 6 Jul 2005 15:32:04 -0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j66FW02m016886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jul 2005 08:32:01 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j66FVu50004329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 6 Jul 2005 08:31:57 -0700 (PDT) Message-ID: <42CBF96B.9070406@qualcomm.com> Date: Wed, 06 Jul 2005 11:31:55 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] [Fwd: Cross-area msec query: draft-cruickshank-ipdvb-sec-00.txt] X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 all, Here is a request from Gorry F chair of IPDVB. That WG is currently considering a new I-D, http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-00.txt, that suggests the use of MSEC protocols for key management, and therefore the chair is requesting a security review from MSEC. Ran requested that the I-D be presented to MSEC at the Paris meeting. We welcome any comments/review on the document to the list. thanks and regards, Lakshminath -------- Original Message -------- Subject: Cross-area msec query: draft-cruickshank-ipdvb-sec-00.txt Date: Wed, 06 Jul 2005 13:03:52 +0200 From: Gorry Fairhurst To: Ran Canetti , Lakshminath Dondeti CC: Russ Housley , Greetings, I am the WG Chair of the ipdvb WG in the Internet Area. As a part of the work of this WG, we have defined an IETF Standards-track encapsulation (currently with the IESG): http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-06.txt This encapsulation is intended for use with wide-area broadcast wireless/satellite links. We resisted the pleas to add mandatory link encryption when this was defined, but provided an extension mechanism in the L2 protocol header. The document below was recently received by the ipdvb WG and proposes use of a ULE extension mechanism to provide L2 security - but using msec key management. http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-00.txt I have scheduled a 15 minute slot to discuss this issue at the next IETF within ipdvb (this is *NOT* currently a chartered action of this WG, but the work on ULE extension headers may naturally reside in ipdvb). I am anxious to get additional security expertise on reviewing this first input, to see if this heading in the best direction. I think some visibility within "msec" would be really useful. Do you think a couple of slides would be helpful within the msec meeting? Best wishes, Gorry Fairhurst (ipdvb WG Chair) http://www.ietf.org/html.charters/ipdvb-charter.html _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jul 06 12:06:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCQ3-0001wF-TJ for msec-archive@megatron.ietf.org; Wed, 06 Jul 2005 12:06:39 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15382 for ; Wed, 6 Jul 2005 12:06:37 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 471D78C7A3; Wed, 6 Jul 2005 12:06:39 -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 837298C79F for ; Wed, 6 Jul 2005 12:06:37 -0400 (EDT) Received: (qmail 27196 invoked by uid 3269); 6 Jul 2005 16:06:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27192 invoked from network); 6 Jul 2005 16:06:37 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 6 Jul 2005 16:06:37 -0000 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 j66G6Wdd011799; Wed, 6 Jul 2005 09:06:33 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j66G6T50010159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jul 2005 09:06:30 -0700 (PDT) Message-ID: <42CC0185.3080103@qualcomm.com> Date: Wed, 06 Jul 2005 12:06:29 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mounir Kellil Subject: Re: [MSEC] Host access control to the multicast trees and Mobile IP impact References: <42CBA5FE.2040600@motorola.com> In-Reply-To: <42CBA5FE.2040600@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Mounir, Many thanks for sharing your work with the WG. I must note that infrastructure protection is not currently within our charter. Furthermore, the receiver access control aspect has been discussed several times in MSEC, GSEC, SMuG and in various others groups in the IETF. I was wondering if you could produce an I-D (it appears that the paper is available to subscribers only) and/or present your work, especially with a comparison to previous proposals at the IETF. If it is an I-D, please submit to the I-D admin and post to the list, and if you would like to present your work at the Paris meeting, please let us know, and we'll be happy to add your presentation to the agenda. thanks and regards, Lakshminath Mounir Kellil wrote: > Dear all, > > We have recently published a paper in IEEE CST, Second Quarter Issue, > 2005, which addresses the access control problem to the delivery tree > (multicast receiver and sender access control). In our study we also > investigated the implications of Mobile IP on the existing approaches. > Both msec and mip(4/6) WGs are concerned with this contribution. > > For the msec community, the present study addresses a problem that is > part of the multicast infrastructure security area. > For further details, please visit the following link to IEEE CST > Second Quarter Issue 2005. > > > http://www.comsoc.org/livepubs/surveys/public/2005/apr/index.html > > > Regards > > Mounir > > _______________________________________________ > 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 Wed Jul 06 12:09:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCSW-0003UJ-EF for msec-archive@megatron.ietf.org; Wed, 06 Jul 2005 12:09:12 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15665 for ; Wed, 6 Jul 2005 12:09:10 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D8F018C7EE; Wed, 6 Jul 2005 12:09:11 -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 550E58C7E7 for ; Wed, 6 Jul 2005 12:09:10 -0400 (EDT) Received: (qmail 27617 invoked by uid 3269); 6 Jul 2005 16:09:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27611 invoked from network); 6 Jul 2005 16:09:09 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 6 Jul 2005 16:09:09 -0000 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 j66G96dd011992 for ; Wed, 6 Jul 2005 09:09:06 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j66G9250010610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 6 Jul 2005 09:09:03 -0700 (PDT) Message-ID: <42CC021E.6000600@qualcomm.com> Date: Wed, 06 Jul 2005 12:09:02 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] 1st call for agenda items at the MSEC meeting X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com, Ran Canetti 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 all, Please send Ran and I requests for presentations at the MSEC meeting. Here are some open items for discussion (in no particular order): 1. Additional work on MIKEY (MIKEY-ECC, MIKEY-RSA-R etc.) 2. IPsec extensions work by Brian W., et. al 3. Need to close the policy I-D last call (let us try to finish this before the meeting on the list, if possible) 4. DVB review 5. Update on the 802.16 review (thanks to all the folks who signed up. I really appreciate you stepping up to help!) 6. MSEC status and WG milestones 7. Moving forward with the TESLA work 8. GKDP I personally prefer presentations on updates to the drafts to be kept to a short duration and use the f2f time for discussions on contentious issues and proposals that *need* f2f discussion for consensus. If there are items that we can achieve some degree of consensus on the list, let us not wait until the meeting. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jul 06 13:17:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDWd-0003NS-1l for msec-archive@megatron.ietf.org; Wed, 06 Jul 2005 13:17:31 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24702 for ; Wed, 6 Jul 2005 13:17:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E456B8C1B4; Wed, 6 Jul 2005 13:17: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 7C8308C19A for ; Wed, 6 Jul 2005 13:17:28 -0400 (EDT) Received: (qmail 39727 invoked by uid 3269); 6 Jul 2005 17:17:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39723 invoked from network); 6 Jul 2005 17:17:24 -0000 Received: from motgate8.mot.com (129.188.136.8) by klesh.pair.com with SMTP; 6 Jul 2005 17:17:24 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j66HQMsU002803 for ; Wed, 6 Jul 2005 10:26:22 -0700 (MST) Received: from zfr27exm01.corp.mot.com (zfr27exm01.corp.mot.com [10.161.200.203]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j66HLpL1016626 for ; Wed, 6 Jul 2005 12:21:51 -0500 (CDT) Received: from [10.161.201.67] (zfr01-2067.crm.mot.com [10.161.201.67]) by zfr27exm01.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id NV3HSAY2; Wed, 6 Jul 2005 19:17:22 +0200 Message-ID: <42CC1221.6060200@motorola.com> Date: Wed, 06 Jul 2005 19:17:21 +0200 From: Mounir Kellil User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ldondeti@qualcomm.com Subject: Re: [MSEC] Host access control to the multicast trees and Mobile IP impact References: <42CBA5FE.2040600@motorola.com> <42CC0185.3080103@qualcomm.com> In-Reply-To: <42CC0185.3080103@qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Cc: 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA24702 Hi Lakshminath, Thanks a lot for you reply, First of all, please note that the access to the IEEE CST papers is=20 available to everybody (IEEE members and non-members), and is free of=20 charges. Non-members need just to create a Visitor Web Account (upon the=20 selection of the paper title). Regarding my paper, it explains the scope of the multicast access=20 control problem, and reviews the existing solutions (pros and cons of=20 each solution, and a comparative study). I did not define any new approac= h. AFAIK, there have been three main proposals at GSEC (SMRAC, HASM, and,=20 IGMP message Authentication). Actually, my study focused rather on works=20 that appeared in published papers (e.g. KHIP, Gothic, etc.). However,=20 some of those works are quite similar to GSEC=92s drafts. Best regards Mounir Lakshminath Dondeti wrote: > Hi Mounir, > > Many thanks for sharing your work with the WG. I must note that=20 > infrastructure protection is not currently within our charter.=20 > Furthermore, the receiver access control aspect has been discussed=20 > several times in MSEC, GSEC, SMuG and in various others groups in the=20 > IETF. > > I was wondering if you could produce an I-D (it appears that the paper=20 > is available to subscribers only) and/or present your work, especially=20 > with a comparison to previous proposals at the IETF. If it is an I-D,=20 > please submit to the I-D admin and post to the list, and if you would=20 > like to present your work at the Paris meeting, please let us know,=20 > and we'll be happy to add your presentation to the agenda. > > thanks and regards, > Lakshminath > > Mounir Kellil wrote: > >> Dear all, >> >> We have recently published a paper in IEEE CST, Second Quarter Issue,=20 >> 2005, which addresses the access control problem to the delivery tree=20 >> (multicast receiver and sender access control). In our study we also=20 >> investigated the implications of Mobile IP on the existing=20 >> approaches. Both msec and mip(4/6) WGs are concerned with this=20 >> contribution. >> >> For the msec community, the present study addresses a problem that is=20 >> part of the multicast infrastructure security area. For further=20 >> details, please visit the following link to IEEE CST Second Quarter=20 >> Issue 2005. >> >> >> http://www.comsoc.org/livepubs/surveys/public/2005/apr/index.html >> >> >> Regards >> >> Mounir >> >> _______________________________________________ >> 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 Jul 07 04:01:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRKU-0002G3-0Z for msec-archive@megatron.ietf.org; Thu, 07 Jul 2005 04:01:54 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09898 for ; Thu, 7 Jul 2005 04:01:51 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E3D8D8C653; Thu, 7 Jul 2005 04:01:52 -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 064D78C539 for ; Thu, 7 Jul 2005 04:01:51 -0400 (EDT) Received: (qmail 15625 invoked by uid 3269); 7 Jul 2005 08:01:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15608 invoked from network); 7 Jul 2005 08:01:49 -0000 Received: from bj45-160.i.netease.com (HELO 126.com) (202.108.45.160) by klesh.pair.com with SMTP; 7 Jul 2005 08:01:49 -0000 Received: from thinker (unknown [202.115.28.189]) by smtp3 (Coremail) with SMTP id GMAho23hzEIUbJI0.1 for ; Thu, 07 Jul 2005 16:01:50 +0800 (CST) X-Originating-IP: [202.115.28.189] Date: Thu, 7 Jul 2005 16:01:42 +0800 From: "QinKe" To: "msec" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050707080151.064D78C539@six.pairlist.net> Subject: [MSEC] need some roadmaps 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="===============1513518589==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============1513518589== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQoNCkFyZSB0aGVyZSBhbnkgZG9jdW1lbnRzIGFib3V0IE11bHRpY2FzdCBEaWdp dGFsIFJpZ2h0IE1hbmFnZW1lbnQgKE1EUk0pPyBCeSBtZWFucyBvZiBlbmNyeXB0aW9uLCB3ZSBj YW4gZW5zdXJlIHRoYXQgb25seSBsZWdpdGltYXRlIG1lbWJlcnMgY2FuIGFjY2VzcyBzb21lIGlu Zm9ybWF0aW9uLCBidXQgc29tZSBtYWxpY2lvdXMgbWVtYmVycyBtYXkgY29weSB0aGVtIGZyZWVs eS4gSW4gdGhpcyBjYXNlLCBNRFJNIHdpbGwgYmUgdmVyeSB1c2VmdWwgdG8gZmluZCBvdXQgd2hv IGlzIGJyZWFraW5nIHRoZSBydWxlLiBTbyB3b3VsZCBhbnlvbmUga2luZCBlbm91Z2ggdGVsbGlu ZyBtZSB0aGUgc2NoZWR1bGUgb2YgdGhpcyBmaWVsZD8NCkJlc2lkZXMsIEmhr2QgbGlrZSB0byBr bm93IGhvdyBtYW55IGRpZmZlcmVudCBmaWVsZHMgdGhlcmUgYXJlIGluIG11bHRpY2FzdCByZXNl YXJjaC4gUm91Z2hseSwgSSBoYXZlIHRoaXMgbGlzdDogKDEpIE11bHRpY2FzdCBLZXkgTWFuYWdl bWVudCBwcm90b2NvbHMgaW5jbHVkaW5nIEdTQUtNUCwgR0RPSSwgTUlLRSBhbmQgc28gb24sICgy KSBTb3VyY2UgQXV0aGVudGljYXRpb24sICgzKSBNRFJNLCAoNCkgQWNjZXNzIENvbnRyb2wsICg1 KSBSb3V0aW5nIHByb3RvY29scywgKDYpIFJlbGlhYmlsaXR5LiBJIGFtIGluIGEgZ3JlYXQgbWVz cyBhbmQgbWF5YmUgSSBkZWxpdmVyIHRoZSB3cm9uZyBjYXRlZ29yeS4gU28gd291bGQgYW55b25l IHNlbmQgbWUgYSBjb3JyZWN0IGFuZCBtb3JlIGRldGFpbGVkIGRlc2NyaXB0aW9uPyBBcmUgdGhl cmUgYW55IHJvYWRtYXBzPw0KDQpUaGFua3MgYSBtaWxsaW9uIQ0KDQqhoaGhoaGhoaGhoaGhoaGh ICAgICBRaW5LZQ0KoaGhoaGhoaGhoaGhoaGhoXl1eHVhbnFrQDEyNi5jb20NCqGhoaGhoaGhoaGh oaGhoaGhoaGhMjAwNS0wNy0wNw0K --===============1513518589== 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 --===============1513518589==-- From msec-bounces@securemulticast.org Sat Jul 09 14:03:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrJfU-0007aU-5m for msec-archive@megatron.ietf.org; Sat, 09 Jul 2005 14:03:12 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15542 for ; Sat, 9 Jul 2005 14:03:10 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 026AF8C012; Sat, 9 Jul 2005 14:03:09 -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 5C24F8C007 for ; Sat, 9 Jul 2005 14:03:07 -0400 (EDT) Received: (qmail 36417 invoked by uid 3269); 9 Jul 2005 18:03:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36414 invoked from network); 9 Jul 2005 18:03:06 -0000 Received: from syd-iport-1.cisco.com (64.104.193.196) by klesh.pair.com with SMTP; 9 Jul 2005 18:03:06 -0000 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 10 Jul 2005 04:32:28 +1000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j69I1b9V006043; Sun, 10 Jul 2005 04:02:27 +1000 (EST) 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); Sat, 9 Jul 2005 11:02:47 -0700 Received: from [192.168.0.11] ([10.21.123.12]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Jul 2005 11:02:47 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Mark Baugher Date: Sat, 9 Jul 2005 11:01:49 -0700 To: msec@securemulticast.org, dignjatic@polycom.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 09 Jul 2005 18:02:47.0160 (UTC) FILETIME=[69A72780:01C584B0] Cc: "'Cullen Jennings'" , Flemming S Andreasen , "David A. McGrew" , Dave Oran , Dan Wing Subject: [MSEC] Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-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 Content-Transfer-Encoding: quoted-printable hi Thanks for posting draft-ietf-msec-mikey-rsa-r-00.txt. I have a few =20= comments. 1. It's nicely written and clear. The last sentence below, however, =20= is not accurate: "The DH mode or the DH-HMAC mode of MIKEY might be useful in cases where the Initiator does not have access to the Responder's exact identity and/or CERT. In these modes, the two parties engage in an authenticated DH exchange to derive the TGK. However, the DH modes have higher computational and communication overhead compared to the RSA and the PSK modes. More importantly, these modes are unsuitable for group key distribution." I believe that msec key distribution typically RFCs use DH as part of = =20 group key distribution viz. http://www.ietf.org/rfc/rfc4046.txt. So =20 this last sentence is wrong. 2. Further on: "Note that in the MIKEY-RSA mode (as in case of the PSK mode), the Initiator proposes the RTP security policy, and chooses the TGK. However, it is also possible that the Initiator wants to allow the Responder to specify the security policy and send the TGK. This would be the case in some multicast and group conferencing =20 scenarios." I think you're absolutely right but I would add a little bit here. =20= MIKEY modes are today pairwise and your I-D adds a mode to make it =20 possible for a bridge, mixer, mcu, server, or other type of controller =20= to hand the end-system a group key. Did I get that right? I think =20 it's true that MIKEY (RFC 3880) supports a pairwise crypto context and =20= mikey-rsa-r supports a group crypto context. That's fine, but what =20 about an n-parwise crypto context? As a footnote, I would add that =20 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions=20 -11.txt supports pairwise and n-pairwise because offerer/initiator =20 sends a master key to the answerer/responder and the latter (always) =20 sends its master key back. For "meet-me" (e.g. 3-way) conferencing, =20 n-pairwise is very convenient. I don't think that rsa-r or RFC 3880 =20 support this. rsa-r does not support n-pairwise. 3. But you do support a group key, in the msec sense, and I think the =20= following security consideration is really important for group =20 communications: "When using the RSA-R mode, the Responder may turn out to be = different from who the Initiator sent the MIKEY message to. It is the responsibility of the Initiator to verify that the identity of the Responder is acceptable if it changes from the intended Responder, Ignjatic, et al. Expires January 8, 2006 [Page 10] =0C Internet-Draft MIKEY-RSA-R July 2005 based on its policy, and to take appropriate action based on the outcome. In some cases, it could be appropriate to accept any Responder's identity; in other cases, a blacklist or a whitelist may be appropriate." This needs an example and maybe a security improvement. First, SIP =20= forking is an example. I don't think RFC 3880 is well suited to SIP on =20= the general Internet, but it will be used for SIP (see =20 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-15.txt) =20= maybe in some contexts (3GPP?). SIP calls fork and RFC 3830 =20 implementations may not handle SSRC collisions well when a fork occurs. =20= I think rsa-r should address this problem directly and the current I-D = =20 should mention it. I think rsa-r may need to also need to admit tesla =20 source-authentication in the case where A goes to talk to B but B is a =20= bridge to C and etc. If B hands out a group key, which is what I think =20= you intend to do, then how does A tell if B, C or D is talking. It =20 might be that A just talks to B, and B is the only entity trusted to =20 package RFC 3550 CSRC payloads from C and/or D. 4. Finally, this is a bit convoluted, I think: "Consider that A wants to talk to B and C, but does not have B's or C's CERT. A might contact B and request that B supply a key for a 3-way call. Now if B knows C's CERT, then B can simply use the MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If = not, then the solution is not straightforward. For instance, A might ask C to contact B or itself to get the TGK, in effect initiating a = 3-way exchange. It should be noted that 3-way calling is typically implemented using a bridge, in which case there are no issues (it looks like 3 point-to-point sessions, where one end of each session is a bridge mixing the traffic into a single stream)." I would forget about this. I think you're defining a mode for a bridge =20= to let it use a group key, but I'm not sure what your trying to do =20 here. 5. In summary, the group key may need better management than rsa-r is =20= currently offering. Here are three suggestions. (i) I think the DH and PFS should be used (ii) SRTP-TESLA may be used (iii) self-signed certs should not be used without SRTP-TESLA cheers, Mark On Jul 9, 2005, at 7:15 AM, Cullen Jennings wrote: > > I just noticed a new ID > > http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt > > This one looks like it actually addresses most my issues with Mikey - =20= > I have > not thought about it too much yet but it looks much better than the =20= > other 4 > modes. It still seems to have the artifact that the responder is =20 > forced to > choose the SRTP keys for both sides. > > The point that we are now up to 5 modes is interesting. Mikey is =20 > starting to > remind me very much of IKE. > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sat Jul 09 15:00:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrKZ9-0004JM-Qf for msec-archive@megatron.ietf.org; Sat, 09 Jul 2005 15:00:45 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18529 for ; Sat, 9 Jul 2005 15:00:41 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id ED34B8C026; Sat, 9 Jul 2005 15:00: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 DB6648BFD4 for ; Sat, 9 Jul 2005 15:00:41 -0400 (EDT) Received: (qmail 44268 invoked by uid 3269); 9 Jul 2005 19:00:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44252 invoked from network); 9 Jul 2005 19:00:41 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 9 Jul 2005 19:00:41 -0000 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j69J0Xn21595; Sat, 9 Jul 2005 15:00:33 -0400 (EDT) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Some comments onhttp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Date: Sat, 9 Jul 2005 14:00:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF032B1877@zrc2hxm0.corp.nortel.com> Thread-Topic: [MSEC] Some comments onhttp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Thread-Index: AcWEsHvgnexxFZmAR1G7Dd0IyMsL9QAAqOwQ From: "Francois Audet" To: "Mark Baugher" , Cc: Cullen Jennings , Lakshminath Dondeti , Dave Oran , Flemming S Andreasen , dignjatic@polycom.com, "David A. McGrew" , Ping Lin , Dan Wing 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 Mark, thanks for your comments. (I'll limit my reply to the SIP aspects you are refering to). See below on the SIP aspects. > 3. But you do support a group key, in the msec sense, and I=20 > think the =20 > following security consideration is really important for group =20 > communications: > "When using the RSA-R mode, the Responder may turn out to=20 > be different > from who the Initiator sent the MIKEY message to. It is the > responsibility of the Initiator to verify that the identity of the > Responder is acceptable if it changes from the intended Responder, > based on its policy, and to take appropriate action based on the > outcome. In some cases, it could be appropriate to accept any > Responder's identity; in other cases, a blacklist or a=20 > whitelist may > be appropriate." >=20 > This needs an example and maybe a security improvement. =20 > First, SIP =20 > forking is an example. I don't think RFC 3880 is well suited=20 > to SIP on =20 > the general Internet, but it will be used for SIP (see =20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ex > t-15.txt) =20 > maybe in some contexts (3GPP?). SIP calls fork and RFC 3830 =20 > implementations may not handle SSRC collisions well when a=20 > fork occurs. =20 > I think rsa-r should address this problem directly and the=20 > current I-D =20 > should mention it. I don't see any justification for the statement that 3830 is not well suited to SIP on the general internet. In fact, one of RSA-R's goal is specifically to target to deal with=20 a very common case in SIP: You wish to establish a session with sRTP media, and you don't "know" in=20 advance who the responder will be (because of retargeting), but you still=20 want the media to be encrypted using sRTP. This is very typical for "telephony" for example where you may wish to have a policy that=20 all calls have encrypted media, regardless of who answers. The text you quote discusses the security implications of this, specifically if the initiator wants to use blacklist, whitelists, and so forth. This case is not addressed today by the current mechanism (MIKEY PSK and SDESC) which focuses on another scenario, which is when you want to established a secure=20 sRTP media session and/or encrypted MIME bodies with a specific individual (or at least a specific Address Of Record).=20 Those two cases are quite different and address different scenarios. PS: Can you clarify what you mean by the SSRC problem, and specifically why it would be different for RSA-R versus sdesc or PSK (and thus covered in this I-D)? I must be missing something. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sat Jul 09 16:28:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrLwE-00022G-3Z for msec-archive@megatron.ietf.org; Sat, 09 Jul 2005 16:28:40 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23558 for ; Sat, 9 Jul 2005 16:28:35 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 215EF8C56F; Sat, 9 Jul 2005 16:28:37 -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 2B2148C559 for ; Sat, 9 Jul 2005 16:28:36 -0400 (EDT) Received: (qmail 56308 invoked by uid 3269); 9 Jul 2005 20:28:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56305 invoked from network); 9 Jul 2005 20:28:36 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 9 Jul 2005 20:28:36 -0000 Received: (qmail 77971 invoked from network); 9 Jul 2005 16:28:33 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 9 Jul 2005 16:28:33 -0400 Received: (qmail 19422 invoked from network); 9 Jul 2005 16:28:33 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.6) by mail1.oct.nac.net with SMTP; 9 Jul 2005 16:28:33 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j69HDNK12438; Sat, 9 Jul 2005 13:13:23 -0400 Date: Sat, 9 Jul 2005 13:13:23 -0400 (EDT) From: George Gross To: QinKe Subject: Re: [MSEC] need some roadmaps In-Reply-To: <20050707080151.064D78C539@six.pairlist.net> 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 QinKe, =09The MSEC working group is focused on specifying the Internet standards described by the charter: http://www.ietf.org/html.charters/msec-charter.html Multicast digital rights management is not within scope of the current working group charter. additional information and documents can be found at the IETF MSEC working group and the IRTF GSEC working group's web site both located at www.securemulticast.org. hth, =09George On Thu, 7 Jul 2005, QinKe wrote: > Dear all: > > Are there any documents about Multicast Digital Right Management (MDRM)? = By means of encryption, we can ensure that only legitimate members can acce= ss some information, but some malicious members may copy them freely. In th= is case, MDRM will be very useful to find out who is breaking the rule. So = would anyone kind enough telling me the schedule of this field? > Besides, I=A1=AFd like to know how many different fields there are in mul= ticast research. Roughly, I have this list: (1) Multicast Key Management pr= otocols including GSAKMP, GDOI, MIKE and so on, (2) Source Authentication, = (3) MDRM, (4) Access Control, (5) Routing protocols, (6) Reliability. I am = in a great mess and maybe I deliver the wrong category. So would anyone sen= d me a correct and more detailed description? Are there any roadmaps? > > Thanks a million! > > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 QinKe > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1yuxuanqk@126.com > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-07-07 > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Jul 10 13:02:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrfCC-0006mf-AT for msec-archive@megatron.ietf.org; Sun, 10 Jul 2005 13:02:24 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12077 for ; Sun, 10 Jul 2005 13:02:21 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F1D848C537; Sun, 10 Jul 2005 13:02:22 -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 188668C533 for ; Sun, 10 Jul 2005 13:02:21 -0400 (EDT) Received: (qmail 55410 invoked by uid 3269); 10 Jul 2005 17:02:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55407 invoked from network); 10 Jul 2005 17:02:20 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 10 Jul 2005 17:02:20 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 Jul 2005 10:02:20 -0700 X-IronPort-AV: i="3.93,277,1115017200"; d="scan'208"; a="197361479:sNHT30447516" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6AH2F6r023024; Sun, 10 Jul 2005 10:02:17 -0700 (PDT) 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); Sun, 10 Jul 2005 10:02:15 -0700 Received: from [192.168.0.11] ([10.21.122.160]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 10:02:14 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF032B1877@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF032B1877@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2fe9c810ebb49d367c326ca172a217e1@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Some comments onhttp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Date: Sun, 10 Jul 2005 10:01:16 -0700 To: "Francois Audet" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 10 Jul 2005 17:02:14.0414 (UTC) FILETIME=[1EC7DAE0:01C58571] Cc: Cullen Jennings , Lakshminath Dondeti , Dave Oran , msec@securemulticast.org, Flemming S Andreasen , dignjatic@polycom.com, "David A. McGrew" , Ping Lin , Dan Wing 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 Francois, On Jul 9, 2005, at 12:00 PM, Francois Audet wrote: > Hi Mark, thanks for your comments. You're welcome. > > (I'll limit my reply to the SIP aspects you are refering to). > > See below on the SIP aspects. ... > > I don't see any justification for the statement that 3830 is not well > suited to SIP on the general internet. mikey requires synchronized clocks, which are not generally available on the Internet, i.e. mikey assumes a level of homogeneity that does not exist on the Internet. > > In fact, one of RSA-R's goal is specifically to target to deal with > a very common case in SIP: > > You wish to establish a session with sRTP media, and you don't "know" > in > advance who the responder will be (because of retargeting), but you > still > want the media to be encrypted using sRTP. This is very typical > for "telephony" for example where you may wish to have a policy that > all calls have encrypted media, regardless of who answers. The text > you > quote discusses the security implications of this, specifically if > the > > initiator wants to use blacklist, whitelists, and so forth. I have another question about rsa-r and the presence of a certificate authority to vouch for an initiator or responder. Such a thing doesn't exist today and I'm curious to know if it's a reasonable service to expect in the near future? I think you need a little more coverage in the Security Considerations section to explain under what conditions an r_message would be authorized by the initiator, since the responder may not be the entity originally invited. > > This case is not addressed today by the current mechanism (MIKEY PSK > and > SDESC) I agree. Flemming, Dan and I have been discussing adding a new exchange where the responder provides the keymat. That's still different from rsa-r, however, because rsa-r does not stongly identify the responder before the message is sent. It might be useful to allow the initiator to offer a certificate without knowing the responder's *if you can strongly authenticate AND authorize the responder when the r_message arrives* I think this might be hard to do without a global PKI. It also begs the question: If it's possible to validate a cert after it's received in an r_message, why can't you get it prior to sending the i_message? > which focuses on another scenario, which is when you want to > established > a secure > sRTP media session and/or encrypted MIME bodies with a specific > individual (or at > least a specific Address Of Record). As I said in my previous note, sdescriptions supports n-pairwise as well as pairwise (between specific individuals) sessions. That's a SIP requirement, e.g. to support forking. The difference between sdescriptions and rsa-r/mikey is that each sdescriptions sender sends its own master key. We wanted to keep it simple. I think a useful sdescriptions feature might be for either the responder or the initiator to give the other a master key. sdescriptions also needs a diffie-hellman exchange. We (or at least I) plan to add group-security features to the next version of sdescriptions. We postponed it for now because SRTP's is not well-suited to group/multicast applications at the present time owing to the problem of SSRC uniqueness. > > Those two cases are quite different and address different scenarios. > > PS: Can you clarify what you mean by the SSRC problem, and specifically > why it would be different for RSA-R versus sdesc or PSK (and thus > covered > in this I-D)? I must be missing something. Sure. If SSRCs are not unique in an SRTP session, the encryption will eventually be compromised owing to One-time-pad reuse (e.g. known plaintext leads to disclosed ciphertex). sdescriptions avoids this by requiring each side to use its own master key. mikey avoids this by including the SSRC (and the ROC) in the signaling. We have seen applications, however, that change the SSRC "on the fly" without signaling. Tight coupling of RTP with the key management, moreover, is hard to achieve since both SRTP key mgt schemes hooks into the SDP or signaling state machine. The dangers are worse in forking since the forked responders can collide and won't know that they collided (or that they were even forked, I am told) because this is n-pairwise and not a group communications scenario. At every point when you get something other than one endpoint communicating with exactly one endpoint, there is an SSRC collision problem looming. Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Jul 10 16:17:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DriFE-0006wB-Da for msec-archive@megatron.ietf.org; Sun, 10 Jul 2005 16:17:44 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22593 for ; Sun, 10 Jul 2005 16:17:41 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 47DAC8C5A2; Sun, 10 Jul 2005 16:17:43 -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 E3D2A8C59E for ; Sun, 10 Jul 2005 16:17:41 -0400 (EDT) Received: (qmail 87204 invoked by uid 3269); 10 Jul 2005 20:17:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87201 invoked from network); 10 Jul 2005 20:17:41 -0000 Received: from zcars04e.nortelnetworks.com (HELO zcars04e.ca.nortel.com) (47.129.242.56) by klesh.pair.com with SMTP; 10 Jul 2005 20:17:41 -0000 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j6AKGGV20856; Sun, 10 Jul 2005 16:16:16 -0400 (EDT) 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] Some comments onhttp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 10 Jul 2005 15:17:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF032B1959@zrc2hxm0.corp.nortel.com> Thread-Topic: [MSEC] Some comments onhttp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Thread-Index: AcWFcShgok3K0KfRQDiO6seHHiivAgAFl5/A From: "Francois Audet" To: "Mark Baugher" Cc: Cullen Jennings , Lakshminath Dondeti , Dave Oran , msec@securemulticast.org, Flemming S Andreasen , dignjatic@polycom.com, "David A. McGrew" , Ping Lin , Dan Wing 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 > I have another question about rsa-r and the presence of a certificate=20 > authority to vouch for an initiator or responder. Such a=20 > thing doesn't=20 > exist today and I'm curious to know if it's a reasonable service to=20 > expect in the near future? I think you need a little more=20 > coverage in=20 > the Security Considerations section to explain under what=20 > conditions an=20 > r_message would be authorized by the initiator, since the=20 > responder may=20 > not be the entity originally invited. Right, it probably does need more coverage. However, I'd like to=20 cover it without getting into the turf of the protocols that would provide that functionality. For example, it could be certificates attached to responses as described in RFC 3261, or it could be the SIP Identity-draft. I'll try to work with Cullen on that one. > > This case is not addressed today by the current mechanism (MIKEY PSK > > and > > SDESC) >=20 > I agree. Flemming, Dan and I have been discussing adding a=20 > new exchange=20 > where the responder provides the keymat. That's still different from=20 > rsa-r, however, because rsa-r does not stongly identify the responder=20 > before the message is sent. It might be useful to allow the=20 > initiator=20 > to offer a certificate without knowing the responder's *if you can=20 > strongly authenticate AND authorize the responder when the r_message=20 > arrives* I think this might be hard to do without a global PKI. =20 Yeah, it makes sense to me that you would consider doing this. I had the same tought that something similar to what we are proposing could apply to sdesc=20 as well. I think the case where initiator can not "strongly identify the=20 responder" before the message is sent applies to SDESC with S/MIME just as much as it applies to MIKEY-PSK (it's when there is retargeting to another AOR/Subject). > It=20 > also begs the question: If it's possible to validate a cert=20 > after it's=20 > received in an r_message, why can't you get it prior to sending the=20 > i_message? That's the idea: it is when your specifically want to allow retargeting (which is unpredictable: even if you "try to get it" before sending the i_message, it may still change). We have to deal with this: it is very basic=20 SIP. It happens all the time, and it's not going away. >=20 > > which focuses on another scenario, which is when you want to > > established > > a secure > > sRTP media session and/or encrypted MIME bodies with a specific > > individual (or at > > least a specific Address Of Record). >=20 > As I said in my previous note, sdescriptions supports n-pairwise as=20 > well as pairwise (between specific individuals) sessions. =20 > That's a SIP=20 > requirement, e.g. to support forking. =20 It only makes a difference if you assume that the sender is capable of receving=20 and playing all the early media streams from the different branches of the fork=20 simultaneously, which I have yet to see anybody do, and even if anybody did, the cacophony would most look more like a design flaw to the user than design intent. In other words, early media doesn't work with forking. But, this is exactly the type of thing that I don't think belongs in the msec group... That being said, point taken: we should explain the limitations it has with point to multipoint. > The difference between=20 > sdescriptions and rsa-r/mikey is that each sdescriptions sender sends=20 > its own master key. We wanted to keep it simple. I think a useful=20 > sdescriptions feature might be for either the responder or the=20 > initiator to give the other a master key. sdescriptions also needs a=20 > diffie-hellman exchange. We (or at least I) plan to add=20 > group-security=20 > features to the next version of sdescriptions. We postponed=20 > it for now=20 > because SRTP's is not well-suited to group/multicast applications at=20 > the present time owing to the problem of SSRC uniqueness. Makes sense to me: it would be useful features to add to SDESC. > > > > Those two cases are quite different and address different scenarios. > > > > PS: Can you clarify what you mean by the SSRC problem, and=20 > > specifically why it would be different for RSA-R versus=20 > sdesc or PSK=20 > > (and thus covered in this I-D)? I must be missing something. >=20 > Sure. If SSRCs are not unique in an SRTP session, the=20 > encryption will=20 > eventually be compromised owing to One-time-pad reuse (e.g. known=20 > plaintext leads to disclosed ciphertex). sdescriptions=20 > avoids this by=20 > requiring each side to use its own master key. mikey avoids this by=20 > including the SSRC (and the ROC) in the signaling. We have seen=20 > applications, however, that change the SSRC "on the fly" without=20 > signaling. Tight coupling of RTP with the key management,=20 > moreover, is=20 > hard to achieve since both SRTP key mgt schemes hooks into the SDP or=20 > signaling state machine. The dangers are worse in forking since the=20 > forked responders can collide and won't know that they collided (or=20 > that they were even forked, I am told) because this is n-pairwise and=20 > not a group communications scenario. >=20 > At every point when you get something other than one endpoint=20 > communicating with exactly one endpoint, there is an SSRC collision=20 > problem looming. We'll look into that.=20 Thanks again: good input. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 11 13:36:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2CO-0004TO-3G for msec-archive@megatron.ietf.org; Mon, 11 Jul 2005 13:36:08 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03755 for ; Mon, 11 Jul 2005 13:36:00 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 735028C74F; Mon, 11 Jul 2005 13:35:52 -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 D18578C6E3 for ; Mon, 11 Jul 2005 13:35:51 -0400 (EDT) Received: (qmail 36477 invoked by uid 3269); 11 Jul 2005 17:35:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36474 invoked from network); 11 Jul 2005 17:35:51 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 11 Jul 2005 17:35:51 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BHYa2m029649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2005 10:34:36 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BHYVRq003107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 10:34:32 -0700 (PDT) Message-ID: <42D2ADA7.1020506@qualcomm.com> Date: Mon, 11 Jul 2005 13:34:31 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MSEC] Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , Dave Oran , msec@securemulticast.org, Flemming S Andreasen , dignjatic@polycom.com, "David A. McGrew" , Dan Wing X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Mark, Thanks for your review. I prepared a response on Saturday, and my mailer ate it :-). So, here are my thoughts: Mark Baugher wrote: > hi > Thanks for posting draft-ietf-msec-mikey-rsa-r-00.txt. I have a > few comments. > > 1. It's nicely written and clear. The last sentence below, however, > is not accurate: > "The DH mode or the DH-HMAC mode of MIKEY might be useful in cases > where the Initiator does not have access to the Responder's exact > identity and/or CERT. In these modes, the two parties engage in an > authenticated DH exchange to derive the TGK. However, the DH modes > have higher computational and communication overhead compared to the > RSA and the PSK modes. More importantly, these modes are unsuitable > for group key distribution." > > I believe that msec key distribution typically RFCs use DH as part > of group key distribution viz. http://www.ietf.org/rfc/rfc4046.txt. > So this last sentence is wrong. Our intent is to say that MIKEY-DH and DHHMAC, as specified in 3830 and the DHHMAC I-D, specify that group key distribution is unsupported. So, if the issue is whether group DH schemes exist in the research literature, sure they do. But, that is not what we are considering. The last sentence could use a rewrite say along the lines of: "these modes do not support group key distribution, as specified." > > 2. Further on: > "Note that in the MIKEY-RSA mode (as in case of the PSK mode), the > Initiator proposes the RTP security policy, and chooses the TGK. > However, it is also possible that the Initiator wants to allow the > Responder to specify the security policy and send the TGK. This > would be the case in some multicast and group conferencing > scenarios." > > I think you're absolutely right but I would add a little bit > here. MIKEY modes are today pairwise and your I-D adds a mode to > make it possible for a bridge, mixer, mcu, server, or other type of > controller to hand the end-system a group key. Did I get that > right? I think it's true that MIKEY (RFC 3880) supports a pairwise > crypto context and mikey-rsa-r supports a group crypto context. > That's fine, but what about an n-parwise crypto context? As a > footnote, I would add that > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > -11.txt supports pairwise and n-pairwise because offerer/initiator > sends a master key to the answerer/responder and the latter (always) > sends its master key back. For "meet-me" (e.g. 3-way) conferencing, > n-pairwise is very convenient. I don't think that rsa-r or RFC 3880 > support this. rsa-r does not support n-pairwise. MIKEY modes are run pairwise, but can be used to establish a group key. Section 8 discusses group key establishment with MIKEY (MIKEY-PSK and MIKEY-RSA modes support this). Section 8 also says that the sender is the Initiator and contacts all authorized members and supplies the same key, CSB_ID and so forth. RSA-R facilitates the reverse operation which, I think, is attractive, if not preferable (somewhat similar to MSEC protocols). Each member can request the sender or a center to supply keys (presumably after seeing an announcement for a conference). There might be some issues as to whether the signaling support is sufficient (we will get to that latter). I think I understand what is n-pairwise, but would like to be absolutely sure, so please define it for me pleas, so we can discuss that further. > > 3. But you do support a group key, in the msec sense, and I think > the following security consideration is really important for group > communications: > "When using the RSA-R mode, the Responder may turn out to be different > from who the Initiator sent the MIKEY message to. It is the > responsibility of the Initiator to verify that the identity of the > Responder is acceptable if it changes from the intended Responder, > > > > Ignjatic, et al. Expires January 8, 2006 [Page 10] > > Internet-Draft MIKEY-RSA-R July 2005 > > > based on its policy, and to take appropriate action based on the > outcome. In some cases, it could be appropriate to accept any > Responder's identity; in other cases, a blacklist or a whitelist may > be appropriate." > > This needs an example and maybe a security improvement. First, > SIP forking is an example. I don't think RFC 3880 is well suited to > SIP on the general Internet, but it will be used for SIP (see > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-15.txt) > maybe in some contexts (3GPP?). SIP calls fork and RFC 3830 > implementations may not handle SSRC collisions well when a fork > occurs. I think rsa-r should address this problem directly and the > current I-D should mention it. We will definitely tighten up the language there and will also update the security considerations so that each end-point has guarantees as to who they are communicating to. We will make a note about SSRC collisions and address them in the next version. > > I think rsa-r may need to also need to admit tesla > source-authentication in the case where A goes to talk to B but B is > a bridge to C and etc. If B hands out a group key, which is what I > think you intend to do, then how does A tell if B, C or D is > talking. It might be that A just talks to B, and B is the only > entity trusted to package RFC 3550 CSRC payloads from C and/or D. We will talk about the need for source authentication in general, although I think for this document, that discussion will have a place only in the security considerations section. > > 4. Finally, this is a bit convoluted, I think: > "Consider that A wants to talk to B and C, but does not have B's or > C's CERT. A might contact B and request that B supply a key for a > 3-way call. Now if B knows C's CERT, then B can simply use the > MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If not, > then the solution is not straightforward. For instance, A might ask > C to contact B or itself to get the TGK, in effect initiating a 3-way > exchange. It should be noted that 3-way calling is typically > implemented using a bridge, in which case there are no issues (it > looks like 3 point-to-point sessions, where one end of each session > is a bridge mixing the traffic into a single stream)." > > I would forget about this. I think you're defining a mode for a > bridge to let it use a group key, but I'm not sure what your trying > to do here. We were trying to be comprehensive and say that in some cases -- the above example, which needs to be revised considering that it is confusing -- MIKEY-RSA-R mode might *not* be the best choice. We don't have to write that in, but admitting in advance the limitations of the proposed mode. > > 5. In summary, the group key may need better management than rsa-r is > currently offering. Here are three suggestions. > (i) I think the DH and PFS should be used > (ii) SRTP-TESLA may be used > (iii) self-signed certs should not be used without SRTP-TESLA Unfortunately, I don't see the need for PFS (please make a case as to why that is necessary). Furthermore, I think the DH modes should stay optional as they are now. We'll include notes on source authentication. I don't quite understand (iii), please elaborate. Thanks. Some notes on Cullen's email below: Yes, MIKEY modes are increasing and I am not too happy about that. OTOH, I am not too worried that we are on the path of IKE. IKE's modes were too complicated and too distinct from each other, making that protocol hard to analyze and understand. MIKEY is much simpler and so far ok. That said, I have in the past talked about and would be ready for a discussion on 3830bis. Knowing what we now know, how would we revise that spec to contain most if not all of the modes and extensions in one well-woven spec. The other topic of some interest to me is each end supplying own key material. Aside from the crypto advantages there are usage advantages. RSA-R being a 2-message mode can have each side supply own key material (as I wrote in the previous paragraph, I would consider adding that feature optionally to the Verification messages in PSK and RSA modes). There are also some downsides too in that each sender would have to supply key material to all the members (but that is also a feature in that each member actually knows who might decipher the RTP traffic it sends). Thanks again for your comments. thanks and regards, Lakshminath > > cheers, Mark > > > > On Jul 9, 2005, at 7:15 AM, Cullen Jennings wrote: > >> >> I just noticed a new ID >> >> http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt >> >> This one looks like it actually addresses most my issues with Mikey >> - I have >> not thought about it too much yet but it looks much better than the >> other 4 >> modes. It still seems to have the artifact that the responder is >> forced to >> choose the SRTP keys for both sides. >> >> The point that we are now up to 5 modes is interesting. Mikey is >> starting to >> remind me very much of IKE. >> > _______________________________________________ > 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 Jul 11 14:00:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2a7-0001pd-Eu for msec-archive@megatron.ietf.org; Mon, 11 Jul 2005 14:00:41 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05295 for ; Mon, 11 Jul 2005 14:00:35 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 868688C7F6; Mon, 11 Jul 2005 14:00: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 587378C7A1 for ; Mon, 11 Jul 2005 14:00:32 -0400 (EDT) Received: (qmail 40801 invoked by uid 3269); 11 Jul 2005 18:00:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40797 invoked from network); 11 Jul 2005 18:00:32 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 11 Jul 2005 18:00:32 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2005 11:00:05 -0700 X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208"; a="300816538:sNHT1130405984" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6BI03vW021308; Mon, 11 Jul 2005 11:00:04 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:00:03 -0700 Received: from [192.168.0.11] ([10.21.80.240]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:00:02 -0700 In-Reply-To: <42D2ADA7.1020506@qualcomm.com> References: <42D2ADA7.1020506@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3f9aadb4362cf4a09497814e89b9cc7a@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Date: Mon, 11 Jul 2005 10:59:02 -0700 To: ldondeti@qualcomm.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 11 Jul 2005 18:00:02.0816 (UTC) FILETIME=[5C85C000:01C58642] Cc: "'Cullen Jennings'" , Dave Oran , msec@securemulticast.org, Flemming S Andreasen , dignjatic@polycom.com, "David A. McGrew" , Dan Wing 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 Lakshminath, On Jul 11, 2005, at 10:34 AM, Lakshminath Dondeti wrote: > Hi Mark, > > Thanks for your review. I prepared a response on Saturday, and my =20 > mailer ate it :-). So, here are my thoughts: > > Mark Baugher wrote: > >> hi >> Thanks for posting draft-ietf-msec-mikey-rsa-r-00.txt. I have a =20= >> few comments. >> >> 1. It's nicely written and clear. The last sentence below, however, = =20 >> is not accurate: >> "The DH mode or the DH-HMAC mode of MIKEY might be useful in cases >> where the Initiator does not have access to the Responder's exact >> identity and/or CERT. In these modes, the two parties engage in = an >> authenticated DH exchange to derive the TGK. However, the DH = modes >> have higher computational and communication overhead compared to =20= >> the >> RSA and the PSK modes. More importantly, these modes are =20 >> unsuitable >> for group key distribution." >> >> I believe that msec key distribution typically RFCs use DH as part =20= >> of group key distribution viz. http://www.ietf.org/rfc/rfc4046.txt. = =20 >> So this last sentence is wrong. > > Our intent is to say that MIKEY-DH and DHHMAC, as specified in 3830 =20= > and the DHHMAC I-D, specify that group key distribution is =20 > unsupported. > > So, if the issue is whether group DH schemes exist in the research =20 > literature, sure they do. GDOI and GSAKMP use DH. > But, that is not what we are considering. The last sentence could use = =20 > a rewrite say along the lines of: "these modes do not support group =20= > key distribution, as specified." I think you want to make it clear that you are referring to MIKEY's =20 modes and mode-lets and not to group key management in general. > >> >> 2. Further on: >> "Note that in the MIKEY-RSA mode (as in case of the PSK mode), the >> Initiator proposes the RTP security policy, and chooses the TGK. >> However, it is also possible that the Initiator wants to allow the >> Responder to specify the security policy and send the TGK. This >> would be the case in some multicast and group conferencing =20 >> scenarios." >> >> I think you're absolutely right but I would add a little bit here. = =20 >> MIKEY modes are today pairwise and your I-D adds a mode to make it = =20 >> possible for a bridge, mixer, mcu, server, or other type of =20 >> controller to hand the end-system a group key. Did I get that =20 >> right? I think it's true that MIKEY (RFC 3880) supports a pairwise =20= >> crypto context and mikey-rsa-r supports a group crypto context. =20 >> That's fine, but what about an n-parwise crypto context? As a =20 >> footnote, I would add that =20 >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions =20= >> -11.txt supports pairwise and n-pairwise because offerer/initiator =20= >> sends a master key to the answerer/responder and the latter (always) = =20 >> sends its master key back. For "meet-me" (e.g. 3-way) conferencing, = =20 >> n-pairwise is very convenient. I don't think that rsa-r or RFC 3880 = =20 >> support this. rsa-r does not support n-pairwise. > > MIKEY modes are run pairwise, but can be used to establish a group =20 > key. Section 8 discusses group key establishment with MIKEY =20 > (MIKEY-PSK and MIKEY-RSA modes support this). > > Section 8 also says that the sender is the Initiator and contacts all =20= > authorized members and supplies the same key, CSB_ID and so forth. =20= > RSA-R facilitates the reverse operation which, I think, is attractive, = =20 > if not preferable (somewhat similar to MSEC protocols). Each member =20= > can request the sender or a center to supply keys (presumably after =20= > seeing an announcement for a conference). There might be some issues =20= > as to whether the signaling support is sufficient (we will get to that = =20 > latter). > > I think I understand what is n-pairwise, but would like to be =20 > absolutely sure, so please define it for me pleas, so we can discuss =20= > that further. In a forking context with sdescriptions, the offerer sends its key to n =20= answerers who send their keys to the offerer (but not to each other) > >> >> 3. But you do support a group key, in the msec sense, and I think =20= >> the following security consideration is really important for group =20= >> communications: >> "When using the RSA-R mode, the Responder may turn out to be =20 >> different >> from who the Initiator sent the MIKEY message to. It is the >> responsibility of the Initiator to verify that the identity of the >> Responder is acceptable if it changes from the intended Responder, >> >> >> >> Ignjatic, et al. Expires January 8, 2006 [Page =20= >> 10] >> =0C >> Internet-Draft MIKEY-RSA-R July =20= >> 2005 >> >> >> based on its policy, and to take appropriate action based on the >> outcome. In some cases, it could be appropriate to accept any >> Responder's identity; in other cases, a blacklist or a whitelist =20= >> may >> be appropriate." >> >> This needs an example and maybe a security improvement. First, =20= >> SIP forking is an example. I don't think RFC 3880 is well suited to = =20 >> SIP on the general Internet, but it will be used for SIP (see =20 >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext=20 >> -15.txt) maybe in some contexts (3GPP?). SIP calls fork and RFC =20 >> 3830 implementations may not handle SSRC collisions well when a fork = =20 >> occurs. I think rsa-r should address this problem directly and the =20= >> current I-D should mention it. > > We will definitely tighten up the language there and will also update =20= > the security considerations so that each end-point has guarantees as =20= > to who they are communicating to. > We will make a note about SSRC collisions and address them in the next = =20 > version. > >> >> I think rsa-r may need to also need to admit tesla =20 >> source-authentication in the case where A goes to talk to B but B is =20= >> a bridge to C and etc. If B hands out a group key, which is what I =20= >> think you intend to do, then how does A tell if B, C or D is =20 >> talking. It might be that A just talks to B, and B is the only =20 >> entity trusted to package RFC 3550 CSRC payloads from C and/or D. > > We will talk about the need for source authentication in general, =20 > although I think for this document, that discussion will have a place =20= > only in the security considerations section. Well, where does one define the tesla bindings? I would think that it =20= needs to be in a MIKEY document and this looks like the right one - =20 it's about multicast. > >> >> 4. Finally, this is a bit convoluted, I think: >> "Consider that A wants to talk to B and C, but does not have B's or >> C's CERT. A might contact B and request that B supply a key for a >> 3-way call. Now if B knows C's CERT, then B can simply use the >> MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If =20= >> not, >> then the solution is not straightforward. For instance, A might =20= >> ask >> C to contact B or itself to get the TGK, in effect initiating a =20= >> 3-way >> exchange. It should be noted that 3-way calling is typically >> implemented using a bridge, in which case there are no issues (it >> looks like 3 point-to-point sessions, where one end of each = session >> is a bridge mixing the traffic into a single stream)." >> >> I would forget about this. I think you're defining a mode for a =20 >> bridge to let it use a group key, but I'm not sure what your trying = =20 >> to do here. > > We were trying to be comprehensive and say that in some cases -- the =20= > above example, which needs to be revised considering that it is =20 > confusing -- MIKEY-RSA-R mode might *not* be the best choice. We =20 > don't have to write that in, but admitting in advance the limitations =20= > of the proposed mode. To be comprehensive, you need to discuss the configurations where each =20= side contributes key material either (i) each side sends its own master =20= key as done in sdescriptions, (ii) each side has a Diffie-Hellman =20 half-secret and does a DH exchange, and (iii) each side has its own =20 master key that they provide to the initiator (but not to other =20 parties) as done in an n-pairwise connection - all are distinct from =20 the group-key case. > >> >> 5. In summary, the group key may need better management than rsa-r is = =20 >> currently offering. Here are three suggestions. >> (i) I think the DH and PFS should be used >> (ii) SRTP-TESLA may be used >> (iii) self-signed certs should not be used without SRTP-TESLA > > Unfortunately, I don't see the need for PFS (please make a case as to =20= > why that is necessary). Furthermore, I think the DH modes should stay = =20 > optional as they are now. If the long-term private key is compromised then all communications =20 that are established used PKE without a DH can be compromised. Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 11 14:11:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2kl-0004lp-BU for msec-archive@megatron.ietf.org; Mon, 11 Jul 2005 14:11:39 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06020 for ; Mon, 11 Jul 2005 14:11:27 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C13EB8C806; Mon, 11 Jul 2005 14:11:05 -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 C1DCF8C7FF for ; Mon, 11 Jul 2005 14:11:04 -0400 (EDT) Received: (qmail 43244 invoked by uid 3269); 11 Jul 2005 18:11:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43241 invoked from network); 11 Jul 2005 18:11:04 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 11 Jul 2005 18:11:04 -0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BIAx2m005510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2005 11:10:59 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BIArTT020717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 11:10:55 -0700 (PDT) Message-ID: <42D2B62D.6080902@qualcomm.com> Date: Mon, 11 Jul 2005 14:10:53 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MSEC] Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt References: <42D2ADA7.1020506@qualcomm.com> <3f9aadb4362cf4a09497814e89b9cc7a@cisco.com> In-Reply-To: <3f9aadb4362cf4a09497814e89b9cc7a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , Dave Oran , msec@securemulticast.org, Flemming S Andreasen , dignjatic@polycom.com, "David A. McGrew" , Dan Wing X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Mark, Thanks for the follow-up. Please see inline: Mark Baugher wrote: > hi Lakshminath, > > On Jul 11, 2005, at 10:34 AM, Lakshminath Dondeti wrote: > >> Hi Mark, >> >> Thanks for your review. I prepared a response on Saturday, and my >> mailer ate it :-). So, here are my thoughts: >> >> Mark Baugher wrote: >> >>> hi >>> Thanks for posting draft-ietf-msec-mikey-rsa-r-00.txt. I have a >>> few comments. >>> >>> 1. It's nicely written and clear. The last sentence below, >>> however, is not accurate: >>> "The DH mode or the DH-HMAC mode of MIKEY might be useful in cases >>> where the Initiator does not have access to the Responder's exact >>> identity and/or CERT. In these modes, the two parties engage in an >>> authenticated DH exchange to derive the TGK. However, the DH modes >>> have higher computational and communication overhead compared to >>> the >>> RSA and the PSK modes. More importantly, these modes are >>> unsuitable >>> for group key distribution." >>> >>> I believe that msec key distribution typically RFCs use DH as >>> part of group key distribution viz. >>> http://www.ietf.org/rfc/rfc4046.txt. So this last sentence is wrong. >> >> >> Our intent is to say that MIKEY-DH and DHHMAC, as specified in 3830 >> and the DHHMAC I-D, specify that group key distribution is unsupported. >> >> So, if the issue is whether group DH schemes exist in the research >> literature, sure they do. > > > GDOI and GSAKMP use DH. Only for establishing the one-to-one secure channel, not to actually using the DH exchange to generate the group key. My understanding is that the MIKEY-DH mode uses the DH-key to generate the SRTP key, and therefore, as defined, does not support group communication. > >> But, that is not what we are considering. The last sentence could >> use a rewrite say along the lines of: "these modes do not support >> group key distribution, as specified." > > > I think you want to make it clear that you are referring to MIKEY's > modes and mode-lets and not to group key management in general. Indeed. > >> >>> >>> 2. Further on: >>> "Note that in the MIKEY-RSA mode (as in case of the PSK mode), the >>> Initiator proposes the RTP security policy, and chooses the TGK. >>> However, it is also possible that the Initiator wants to allow the >>> Responder to specify the security policy and send the TGK. This >>> would be the case in some multicast and group conferencing >>> scenarios." >>> >>> I think you're absolutely right but I would add a little bit >>> here. MIKEY modes are today pairwise and your I-D adds a mode to >>> make it possible for a bridge, mixer, mcu, server, or other type >>> of controller to hand the end-system a group key. Did I get that >>> right? I think it's true that MIKEY (RFC 3880) supports a >>> pairwise crypto context and mikey-rsa-r supports a group crypto >>> context. That's fine, but what about an n-parwise crypto >>> context? As a footnote, I would add that >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions >>> -11.txt supports pairwise and n-pairwise because offerer/initiator >>> sends a master key to the answerer/responder and the latter >>> (always) sends its master key back. For "meet-me" (e.g. 3-way) >>> conferencing, n-pairwise is very convenient. I don't think that >>> rsa-r or RFC 3880 support this. rsa-r does not support n-pairwise. >> >> >> MIKEY modes are run pairwise, but can be used to establish a group >> key. Section 8 discusses group key establishment with MIKEY >> (MIKEY-PSK and MIKEY-RSA modes support this). >> >> Section 8 also says that the sender is the Initiator and contacts >> all authorized members and supplies the same key, CSB_ID and so >> forth. RSA-R facilitates the reverse operation which, I think, is >> attractive, if not preferable (somewhat similar to MSEC protocols). >> Each member can request the sender or a center to supply keys >> (presumably after seeing an announcement for a conference). There >> might be some issues as to whether the signaling support is >> sufficient (we will get to that latter). >> >> I think I understand what is n-pairwise, but would like to be >> absolutely sure, so please define it for me pleas, so we can discuss >> that further. > > > In a forking context with sdescriptions, the offerer sends its key to > n answerers who send their keys to the offerer (but not to each other) > Ok. Actually, I didn't know that definition. I will reread the emails with that information in mind and respond separately, if I could >> >>> >>> 3. But you do support a group key, in the msec sense, and I think >>> the following security consideration is really important for >>> group communications: >>> "When using the RSA-R mode, the Responder may turn out to be >>> different >>> from who the Initiator sent the MIKEY message to. It is the >>> responsibility of the Initiator to verify that the identity of the >>> Responder is acceptable if it changes from the intended Responder, >>> >>> >>> >>> Ignjatic, et al. Expires January 8, 2006 >>> [Page 10] >>> >>> Internet-Draft MIKEY-RSA-R July >>> 2005 >>> >>> >>> based on its policy, and to take appropriate action based on the >>> outcome. In some cases, it could be appropriate to accept any >>> Responder's identity; in other cases, a blacklist or a whitelist >>> may >>> be appropriate." >>> >>> This needs an example and maybe a security improvement. First, >>> SIP forking is an example. I don't think RFC 3880 is well suited >>> to SIP on the general Internet, but it will be used for SIP (see >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext >>> -15.txt) maybe in some contexts (3GPP?). SIP calls fork and RFC >>> 3830 implementations may not handle SSRC collisions well when a >>> fork occurs. I think rsa-r should address this problem directly >>> and the current I-D should mention it. >> >> >> We will definitely tighten up the language there and will also >> update the security considerations so that each end-point has >> guarantees as to who they are communicating to. >> We will make a note about SSRC collisions and address them in the >> next version. >> >>> >>> I think rsa-r may need to also need to admit tesla >>> source-authentication in the case where A goes to talk to B but B >>> is a bridge to C and etc. If B hands out a group key, which is >>> what I think you intend to do, then how does A tell if B, C or D >>> is talking. It might be that A just talks to B, and B is the >>> only entity trusted to package RFC 3550 CSRC payloads from C >>> and/or D. >> >> >> We will talk about the need for source authentication in general, >> although I think for this document, that discussion will have a >> place only in the security considerations section. > > > Well, where does one define the tesla bindings? I would think that > it needs to be in a MIKEY document and this looks like the right one > - it's about multicast. :-). 3830 does give prominence to unicast communication, with brief notes about multicast and groups. In any event, we will talk about the need for source authentication. > >> >>> >>> 4. Finally, this is a bit convoluted, I think: >>> "Consider that A wants to talk to B and C, but does not have B's or >>> C's CERT. A might contact B and request that B supply a key for a >>> 3-way call. Now if B knows C's CERT, then B can simply use the >>> MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If >>> not, >>> then the solution is not straightforward. For instance, A might >>> ask >>> C to contact B or itself to get the TGK, in effect initiating a >>> 3-way >>> exchange. It should be noted that 3-way calling is typically >>> implemented using a bridge, in which case there are no issues (it >>> looks like 3 point-to-point sessions, where one end of each session >>> is a bridge mixing the traffic into a single stream)." >>> >>> I would forget about this. I think you're defining a mode for a >>> bridge to let it use a group key, but I'm not sure what your >>> trying to do here. >> >> >> We were trying to be comprehensive and say that in some cases -- the >> above example, which needs to be revised considering that it is >> confusing -- MIKEY-RSA-R mode might *not* be the best choice. We >> don't have to write that in, but admitting in advance the >> limitations of the proposed mode. > > > To be comprehensive, you need to discuss the configurations where > each side contributes key material either (i) each side sends its own > master key as done in sdescriptions, (ii) each side has a > Diffie-Hellman half-secret and does a DH exchange, and (iii) each > side has its own master key that they provide to the initiator (but > not to other parties) as done in an n-pairwise connection - all are > distinct from the group-key case. > >> >>> >>> 5. In summary, the group key may need better management than rsa-r >>> is currently offering. Here are three suggestions. >>> (i) I think the DH and PFS should be used >>> (ii) SRTP-TESLA may be used >>> (iii) self-signed certs should not be used without SRTP-TESLA >> >> >> Unfortunately, I don't see the need for PFS (please make a case as >> to why that is necessary). Furthermore, I think the DH modes should >> stay optional as they are now. > > > If the long-term private key is compromised then all communications > that are established used PKE without a DH can be compromised. But DH does come at a cost, i.e., p2p key generation, and MIKEY-RSA mode has a way to bootstrap the PSK mode. Given those two facts, I still don't see the *need* for PFS. The DH mode is an option and can be used if PFS is a requirement. I will follow-up on any remaining topics in the next day or two. Also, if you are coming to Paris, let us meet some time and discuss this further f2f. thanks and regards, Lakshminath > > Mark > >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 11 14:21:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2u9-0006fJ-I1 for msec-archive@megatron.ietf.org; Mon, 11 Jul 2005 14:21:21 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06666 for ; Mon, 11 Jul 2005 14:21:18 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4DE228CA4F; Mon, 11 Jul 2005 14:21:16 -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 2A3C98CA39 for ; Mon, 11 Jul 2005 14:21:15 -0400 (EDT) Received: (qmail 45573 invoked by uid 3269); 11 Jul 2005 18:21:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45566 invoked from network); 11 Jul 2005 18:21:14 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 11 Jul 2005 18:21:14 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2005 11:21:14 -0700 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 j6BIL9od012466; Mon, 11 Jul 2005 11:21:09 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:21:06 -0700 Received: from [192.168.0.11] ([10.21.80.240]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:21:06 -0700 In-Reply-To: <42D2B62D.6080902@qualcomm.com> References: <42D2ADA7.1020506@qualcomm.com> <3f9aadb4362cf4a09497814e89b9cc7a@cisco.com> <42D2B62D.6080902@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Date: Mon, 11 Jul 2005 11:20:06 -0700 To: ldondeti@qualcomm.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 11 Jul 2005 18:21:06.0427 (UTC) FILETIME=[4DB17CB0:01C58645] Cc: 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 Content-Transfer-Encoding: 7bit One more comment... On Jul 11, 2005, at 11:10 AM, Lakshminath Dondeti wrote: >> ... >> Well, where does one define the tesla bindings? I would think that >> it needs to be in a MIKEY document and this looks like the right one >> - it's about multicast. > > :-). 3830 does give prominence to unicast communication, with brief > notes about multicast and groups. In any event, we will talk about > the need for source authentication. I think you should do more and define how it gets signaled. Mark > >> >>> >>>> >>>> 4. Finally, this is a bit convoluted, I think: >>>> "Consider that A wants to talk to B and C, but does not have B's >>>> or >>>> C's CERT. A might contact B and request that B supply a key for >>>> a >>>> 3-way call. Now if B knows C's CERT, then B can simply use the >>>> MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. If >>>> not, >>>> then the solution is not straightforward. For instance, A might >>>> ask >>>> C to contact B or itself to get the TGK, in effect initiating a >>>> 3-way >>>> exchange. It should be noted that 3-way calling is typically >>>> implemented using a bridge, in which case there are no issues (it >>>> looks like 3 point-to-point sessions, where one end of each >>>> session >>>> is a bridge mixing the traffic into a single stream)." >>>> >>>> I would forget about this. I think you're defining a mode for a >>>> bridge to let it use a group key, but I'm not sure what your >>>> trying to do here. >>> >>> >>> We were trying to be comprehensive and say that in some cases -- the >>> above example, which needs to be revised considering that it is >>> confusing -- MIKEY-RSA-R mode might *not* be the best choice. We >>> don't have to write that in, but admitting in advance the >>> limitations of the proposed mode. >> >> >> To be comprehensive, you need to discuss the configurations where >> each side contributes key material either (i) each side sends its >> own master key as done in sdescriptions, (ii) each side has a >> Diffie-Hellman half-secret and does a DH exchange, and (iii) each >> side has its own master key that they provide to the initiator (but >> not to other parties) as done in an n-pairwise connection - all are >> distinct from the group-key case. >> >>> >>>> >>>> 5. In summary, the group key may need better management than rsa-r >>>> is currently offering. Here are three suggestions. >>>> (i) I think the DH and PFS should be used >>>> (ii) SRTP-TESLA may be used >>>> (iii) self-signed certs should not be used without SRTP-TESLA >>> >>> >>> Unfortunately, I don't see the need for PFS (please make a case as >>> to why that is necessary). Furthermore, I think the DH modes >>> should stay optional as they are now. >> >> >> If the long-term private key is compromised then all communications >> that are established used PKE without a DH can be compromised. > > But DH does come at a cost, i.e., p2p key generation, and MIKEY-RSA > mode has a way to bootstrap the PSK mode. Given those two facts, I > still don't see the *need* for PFS. The DH mode is an option and can > be used if PFS is a requirement. > > I will follow-up on any remaining topics in the next day or two. > Also, if you are coming to Paris, let us meet some time and discuss > this further f2f. > > thanks and regards, > Lakshminath > >> >> Mark >> >>> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 11 14:38:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3Al-00036R-GZ for msec-archive@megatron.ietf.org; Mon, 11 Jul 2005 14:38:31 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08880 for ; Mon, 11 Jul 2005 14:38:26 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0ABB58C8EE; Mon, 11 Jul 2005 14:38: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 B20B58C8BB for ; Mon, 11 Jul 2005 14:38:00 -0400 (EDT) Received: (qmail 48019 invoked by uid 3269); 11 Jul 2005 18:38:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48015 invoked from network); 11 Jul 2005 18:38:00 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 11 Jul 2005 18:38:00 -0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BIbs2m009383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2005 11:37:55 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BIboTT002790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2005 11:37:52 -0700 (PDT) Message-ID: <42D2BC7E.1000405@qualcomm.com> Date: Mon, 11 Jul 2005 14:37:50 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MSEC] Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt References: <42D2ADA7.1020506@qualcomm.com> <3f9aadb4362cf4a09497814e89b9cc7a@cisco.com> <42D2B62D.6080902@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 am inclined to say, sure. However, the bootstrapping-TESLA I-D defines how to. Do you think the RSA-R document should repeat what's in bootstrapping-TESLA? If you are for merging the various MIKEY drafts, as I noted, I am willing to open that discussion :-). thanks Mark, Lakshminath Mark Baugher wrote: > One more comment... > > On Jul 11, 2005, at 11:10 AM, Lakshminath Dondeti wrote: > >>> > ... > >>> Well, where does one define the tesla bindings? I would think that >>> it needs to be in a MIKEY document and this looks like the right >>> one - it's about multicast. >> >> >> :-). 3830 does give prominence to unicast communication, with brief >> notes about multicast and groups. In any event, we will talk about >> the need for source authentication. > > > I think you should do more and define how it gets signaled. > > Mark > >> >>> >>>> >>>>> >>>>> 4. Finally, this is a bit convoluted, I think: >>>>> "Consider that A wants to talk to B and C, but does not have B's or >>>>> C's CERT. A might contact B and request that B supply a key for a >>>>> 3-way call. Now if B knows C's CERT, then B can simply use the >>>>> MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. >>>>> If not, >>>>> then the solution is not straightforward. For instance, A >>>>> might ask >>>>> C to contact B or itself to get the TGK, in effect initiating >>>>> a 3-way >>>>> exchange. It should be noted that 3-way calling is typically >>>>> implemented using a bridge, in which case there are no issues (it >>>>> looks like 3 point-to-point sessions, where one end of each >>>>> session >>>>> is a bridge mixing the traffic into a single stream)." >>>>> >>>>> I would forget about this. I think you're defining a mode for a >>>>> bridge to let it use a group key, but I'm not sure what your >>>>> trying to do here. >>>> >>>> >>>> >>>> We were trying to be comprehensive and say that in some cases -- >>>> the above example, which needs to be revised considering that it >>>> is confusing -- MIKEY-RSA-R mode might *not* be the best choice. >>>> We don't have to write that in, but admitting in advance the >>>> limitations of the proposed mode. >>> >>> >>> >>> To be comprehensive, you need to discuss the configurations where >>> each side contributes key material either (i) each side sends its >>> own master key as done in sdescriptions, (ii) each side has a >>> Diffie-Hellman half-secret and does a DH exchange, and (iii) each >>> side has its own master key that they provide to the initiator (but >>> not to other parties) as done in an n-pairwise connection - all are >>> distinct from the group-key case. >>> >>>> >>>>> >>>>> 5. In summary, the group key may need better management than rsa-r >>>>> is currently offering. Here are three suggestions. >>>>> (i) I think the DH and PFS should be used >>>>> (ii) SRTP-TESLA may be used >>>>> (iii) self-signed certs should not be used without SRTP-TESLA >>>> >>>> >>>> >>>> Unfortunately, I don't see the need for PFS (please make a case as >>>> to why that is necessary). Furthermore, I think the DH modes >>>> should stay optional as they are now. >>> >>> >>> >>> If the long-term private key is compromised then all communications >>> that are established used PKE without a DH can be compromised. >> >> >> But DH does come at a cost, i.e., p2p key generation, and MIKEY-RSA >> mode has a way to bootstrap the PSK mode. Given those two facts, I >> still don't see the *need* for PFS. The DH mode is an option and can >> be used if PFS is a requirement. >> >> I will follow-up on any remaining topics in the next day or two. >> Also, if you are coming to Paris, let us meet some time and discuss >> this further f2f. >> >> thanks and regards, >> Lakshminath >> >>> >>> Mark >>> >>>> >>> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 11 14:58:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3Tu-00014T-OD for msec-archive@megatron.ietf.org; Mon, 11 Jul 2005 14:58:18 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10975 for ; Mon, 11 Jul 2005 14:58:12 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0A6658C797; Mon, 11 Jul 2005 14:58:11 -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 AD55C8C31F for ; Mon, 11 Jul 2005 14:58:09 -0400 (EDT) Received: (qmail 51198 invoked by uid 3269); 11 Jul 2005 18:58:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51195 invoked from network); 11 Jul 2005 18:58:09 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 11 Jul 2005 18:58:09 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2005 11:57:54 -0700 X-IronPort-AV: i="3.93,280,1115017200"; d="scan'208"; a="647960297:sNHT1832704156" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6BIvpvS001200; Mon, 11 Jul 2005 11:57:51 -0700 (PDT) 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); Mon, 11 Jul 2005 11:57:48 -0700 Received: from [192.168.0.11] ([10.21.80.240]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 11:57:47 -0700 In-Reply-To: <42D2BC7E.1000405@qualcomm.com> References: <42D2ADA7.1020506@qualcomm.com> <3f9aadb4362cf4a09497814e89b9cc7a@cisco.com> <42D2B62D.6080902@qualcomm.com> <42D2BC7E.1000405@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Date: Mon, 11 Jul 2005 11:56:48 -0700 To: ldondeti@qualcomm.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 11 Jul 2005 18:57:47.0990 (UTC) FILETIME=[6DED5760:01C5864A] Cc: 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 Content-Transfer-Encoding: 7bit On Jul 11, 2005, at 11:37 AM, Lakshminath Dondeti wrote: > I am inclined to say, sure. However, the bootstrapping-TESLA I-D > defines how to. Yes, you're right. I forgot about this document Mark > Do you think the RSA-R document should repeat what's in > bootstrapping-TESLA? If you are for merging the various MIKEY drafts, > as I noted, I am willing to open that discussion :-). > > thanks Mark, > Lakshminath > > Mark Baugher wrote: > >> One more comment... >> >> On Jul 11, 2005, at 11:10 AM, Lakshminath Dondeti wrote: >> >>>> >> ... >> >>>> Well, where does one define the tesla bindings? I would think that >>>> it needs to be in a MIKEY document and this looks like the right >>>> one - it's about multicast. >>> >>> >>> :-). 3830 does give prominence to unicast communication, with brief >>> notes about multicast and groups. In any event, we will talk about >>> the need for source authentication. >> >> >> I think you should do more and define how it gets signaled. >> >> Mark >> >>> >>>> >>>>> >>>>>> >>>>>> 4. Finally, this is a bit convoluted, I think: >>>>>> "Consider that A wants to talk to B and C, but does not have >>>>>> B's or >>>>>> C's CERT. A might contact B and request that B supply a key >>>>>> for a >>>>>> 3-way call. Now if B knows C's CERT, then B can simply use the >>>>>> MIKEY-RSA mode (as defined in RFC 3830) to send the TGK to C. >>>>>> If not, >>>>>> then the solution is not straightforward. For instance, A >>>>>> might ask >>>>>> C to contact B or itself to get the TGK, in effect initiating >>>>>> a 3-way >>>>>> exchange. It should be noted that 3-way calling is typically >>>>>> implemented using a bridge, in which case there are no issues >>>>>> (it >>>>>> looks like 3 point-to-point sessions, where one end of each >>>>>> session >>>>>> is a bridge mixing the traffic into a single stream)." >>>>>> >>>>>> I would forget about this. I think you're defining a mode for a >>>>>> bridge to let it use a group key, but I'm not sure what your >>>>>> trying to do here. >>>>> >>>>> >>>>> >>>>> We were trying to be comprehensive and say that in some cases -- >>>>> the above example, which needs to be revised considering that it >>>>> is confusing -- MIKEY-RSA-R mode might *not* be the best choice. >>>>> We don't have to write that in, but admitting in advance the >>>>> limitations of the proposed mode. >>>> >>>> >>>> >>>> To be comprehensive, you need to discuss the configurations where >>>> each side contributes key material either (i) each side sends its >>>> own master key as done in sdescriptions, (ii) each side has a >>>> Diffie-Hellman half-secret and does a DH exchange, and (iii) each >>>> side has its own master key that they provide to the initiator >>>> (but not to other parties) as done in an n-pairwise connection - >>>> all are distinct from the group-key case. >>>> >>>>> >>>>>> >>>>>> 5. In summary, the group key may need better management than >>>>>> rsa-r is currently offering. Here are three suggestions. >>>>>> (i) I think the DH and PFS should be used >>>>>> (ii) SRTP-TESLA may be used >>>>>> (iii) self-signed certs should not be used without SRTP-TESLA >>>>> >>>>> >>>>> >>>>> Unfortunately, I don't see the need for PFS (please make a case as >>>>> to why that is necessary). Furthermore, I think the DH modes >>>>> should stay optional as they are now. >>>> >>>> >>>> >>>> If the long-term private key is compromised then all communications >>>> that are established used PKE without a DH can be compromised. >>> >>> >>> But DH does come at a cost, i.e., p2p key generation, and MIKEY-RSA >>> mode has a way to bootstrap the PSK mode. Given those two facts, I >>> still don't see the *need* for PFS. The DH mode is an option and >>> can be used if PFS is a requirement. >>> >>> I will follow-up on any remaining topics in the next day or two. >>> Also, if you are coming to Paris, let us meet some time and discuss >>> this further f2f. >>> >>> thanks and regards, >>> Lakshminath >>> >>>> >>>> Mark >>>> >>>>> >>>> >>> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 11 16:13:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds4f7-0000Kj-J2 for msec-archive@megatron.ietf.org; Mon, 11 Jul 2005 16:13:57 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23590 for ; Mon, 11 Jul 2005 16:13:54 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 70E898C2F1; Mon, 11 Jul 2005 16:13: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 2F2CF8C74C for ; Mon, 11 Jul 2005 16:13:52 -0400 (EDT) Received: (qmail 66370 invoked by uid 3269); 11 Jul 2005 20:13:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66366 invoked from network); 11 Jul 2005 20:13:51 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 11 Jul 2005 20:13:51 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BKDm2m022295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jul 2005 13:13:49 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6BKDjRq004967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Jul 2005 13:13:46 -0700 (PDT) Message-ID: <42D2D2F9.70006@qualcomm.com> Date: Mon, 11 Jul 2005 16:13:45 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Reminder: 802.16e reviews X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 all, I am using the MSEC list to send the reminder so I can also take the opportunity to thank you again for volunteering to do the reviews. Thanks also to the folks who have already submitted their reviews. That said, I am still waiting to receive reviews from several folks. Please send them to me before 5 PM US Eastern time tomorrow (July 12, 200). While that is quite late, Jeff Mandin and I will collate the reviews and find a way to communicate our input the 802.16 group that meets starting -- I think -- this coming Sunday. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jul 12 07:57:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJOO-0003lg-Uq for msec-archive@megatron.ietf.org; Tue, 12 Jul 2005 07:57:40 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13819 for ; Tue, 12 Jul 2005 07:57:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E9D508C5B2; Tue, 12 Jul 2005 07:57:39 -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 6B83E8C575 for ; Tue, 12 Jul 2005 07:57:38 -0400 (EDT) Received: (qmail 15012 invoked by uid 3269); 12 Jul 2005 11:57:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15008 invoked from network); 12 Jul 2005 11:57:38 -0000 Received: from mx-serv.inrialpes.fr (194.199.18.100) by klesh.pair.com with SMTP; 12 Jul 2005 11:57:38 -0000 Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.0/8.13.0) with ESMTP id j6CBus5v008760; Tue, 12 Jul 2005 13:56:54 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id j6CButO08988; Tue, 12 Jul 2005 13:56:55 +0200 (MEST) Message-ID: <42D3B007.5030005@inrialpes.fr> Date: Tue, 12 Jul 2005 13:56:55 +0200 From: Vincent Roca Organization: INRIA Rhone-Alpes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050504 Fedora/1.7.7-1.2.2.legacy X-Accept-Language: en-us, en MIME-Version: 1.0 To: rmt@ietf.org, msec@securemulticast.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 12 Jul 2005 13:56:54 +0200 (MEST) X-SMAUG-MailScanner: Found to be clean X-SMAUG-MailScanner-From: vincent.roca@inrialpes.fr Cc: Aurelien Francillon , sebastien faurite , Vincent Roca Subject: [MSEC] TESLA for ALC/NORM I-D available 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 all, An Internet-draft on the use of TESLA for ALC and NORM sessions is available: http://www.ietf.org/internet-drafts/draft-faurite-rmt-tesla-for-alc-norm-00.txt -------------- Abstract This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM content delivery protocols. This draft only considers the authentication/integrity of the packets generated by the session's sender. -------------- Comments are of course welcome. Following the advice of the RMT/MSEC WG chairs, this I-D is is primarily submitted to the RMT WG and CC-ed to MSEC for a "close technical supervision". Cheers, Sebastien/Aurelien/Vincent _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jul 12 08:32:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJwQ-000829-Mk for msec-archive@megatron.ietf.org; Tue, 12 Jul 2005 08:32:50 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16987 for ; Tue, 12 Jul 2005 08:32:49 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 145108C987; Tue, 12 Jul 2005 08:32:50 -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 7967C8C970 for ; Tue, 12 Jul 2005 08:32:48 -0400 (EDT) Received: (qmail 20888 invoked by uid 3269); 12 Jul 2005 12:32:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20885 invoked from network); 12 Jul 2005 12:32:48 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 12 Jul 2005 12:32:48 -0000 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 j6CCMBdd015422; Tue, 12 Jul 2005 05:22:12 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CCM651023452; Tue, 12 Jul 2005 05:22:09 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 05:22:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] TESLA for ALC/NORM I-D available Date: Tue, 12 Jul 2005 05:22:09 -0700 Message-ID: Thread-Topic: [MSEC] TESLA for ALC/NORM I-D available Thread-Index: AcWG2PMdG0FS7UxfSpaWMbuPdP7JsAAAjqj0 From: "Dondeti, Lakshminath" To: "Vincent Roca" , , X-OriginalArrivalTime: 12 Jul 2005 12:22:09.0173 (UTC) FILETIME=[52E71450:01C586DC] Cc: Aurelien Francillon , sebastien faurite 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="===============1092715298==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1092715298== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C586DC.53546E60" This is a multi-part message in MIME format. ------_=_NextPart_001_01C586DC.53546E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thanks for posting this I-D to MSEC. =20 We will put this on the MSEC agenda in Paris, with the intent to follow = its progress so that the TESLA work within MSEC and this work are in = sync. (TESLA authors: hint ... hint) best regards, Lakshminath -----Original Message----- From: msec-bounces@securemulticast.org on behalf of Vincent Roca Sent: Tue 7/12/2005 4:56 AM To: rmt@ietf.org; msec@securemulticast.org Cc: Aurelien Francillon; sebastien faurite; Vincent Roca Subject: [MSEC] TESLA for ALC/NORM I-D available =20 Hi all, An Internet-draft on the use of TESLA for ALC and NORM sessions is available: http://www.ietf.org/internet-drafts/draft-faurite-rmt-tesla-for-alc-norm-= 00.txt -------------- Abstract This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM content delivery protocols. This draft only considers the authentication/integrity of the packets generated by the session's sender. -------------- Comments are of course welcome. Following the advice of the RMT/MSEC WG chairs, this I-D is is primarily submitted to the RMT WG and CC-ed to MSEC for a "close technical supervision". Cheers, Sebastien/Aurelien/Vincent _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec ------_=_NextPart_001_01C586DC.53546E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MSEC] TESLA for ALC/NORM I-D available

Hi,

Thanks for posting this I-D to MSEC. 

We will put this on the MSEC agenda in Paris, with the intent to follow = its progress so that the TESLA work within MSEC and this work are in = sync. (TESLA authors: hint ... hint)

best regards,
Lakshminath


-----Original Message-----
From: msec-bounces@securemulticast.org on behalf of Vincent Roca
Sent: Tue 7/12/2005 4:56 AM
To: rmt@ietf.org; msec@securemulticast.org
Cc: Aurelien Francillon; sebastien faurite; Vincent Roca
Subject: [MSEC] TESLA for ALC/NORM I-D available

Hi all,

An Internet-draft on the use of TESLA for ALC and NORM sessions
is available:

http://www.ietf.org/internet-drafts/draft-faurite-rmt-tes= la-for-alc-norm-00.txt

--------------
Abstract

   This document explains how to integrate the TESLA = source
   authentication and packet integrity protocol to the ALC and = NORM
   content delivery protocols.  This draft only considers = the
   authentication/integrity of the packets generated by the = session's
   sender.
--------------

Comments are of course welcome.

Following the advice of the RMT/MSEC WG chairs, this I-D
is is primarily submitted to the RMT WG and CC-ed to MSEC
for a "close technical supervision".

Cheers,

  Sebastien/Aurelien/Vincent
_______________________________________________
msec mailing list
msec@securemulticast.org
http://six.pairlis= t.net/mailman/listinfo/msec

------_=_NextPart_001_01C586DC.53546E60-- --===============1092715298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1092715298==-- From msec-bounces@securemulticast.org Tue Jul 12 14:10:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsPDV-0004VH-Nw for msec-archive@megatron.ietf.org; Tue, 12 Jul 2005 14:10:49 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21166 for ; Tue, 12 Jul 2005 14:10:48 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3AADD8C875; Tue, 12 Jul 2005 14:10:48 -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 F3CF98C81A for ; Tue, 12 Jul 2005 14:10:46 -0400 (EDT) Received: (qmail 88672 invoked by uid 3269); 12 Jul 2005 18:10:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88669 invoked from network); 12 Jul 2005 18:10:46 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 12 Jul 2005 18:10:46 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CIAd2m029638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2005 11:10:40 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CIAYRq003329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 11:10:35 -0700 (PDT) Message-ID: <42D4079B.5090503@qualcomm.com> Date: Tue, 12 Jul 2005 14:10:35 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: elisabetta Carrara , mark baugher Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org Subject: [MSEC] [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 -------- Original Message -------- Subject: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard Date: Mon, 11 Jul 2005 17:18:07 -0400 From: Russ Housley To: ldondeti@qualcomm.com, canetti@watson.ibm.com Please let me know how you want to handle this comment. Russ >From: Colin Perkins >Date: Mon, 11 Jul 2005 18:34:45 +0100 >To: iesg@ietf.org >Cc: msec@securemulticast.org >Subject: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard > >On 24 Jun 2005, at 23:54, The IESG wrote: >>The IESG has received a request from the Multicast Security WG to >>consider the >>following document: >> >>- 'The Use of TESLA in SRTP ' >> as a Proposed Standard >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-11. > >I have reviewed this draft, and believe the material appropriate for >publication as a proposed standard RFC. > >My only minor concern is that the data origin authentication features >of TESLA are presented as extensions to SRTP, needing new headers and >new processing rules, and not as a new authentication option for use >within the existing SRTP framework. The protocol appears reasonable, >but would be more obviously compatible with SRTP if it were presented >differently. I would recommend either editorial clarifications to >explain this or, if TESLA cannot be considered a new authentication >option in the SRTP framework, a more detailed review of how this >draft fits with SRTP as a whole. > >Colin > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jul 12 14:41:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsPgh-00070q-3i for msec-archive@megatron.ietf.org; Tue, 12 Jul 2005 14:41:00 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22865 for ; Tue, 12 Jul 2005 14:40:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 808F78C3B5; Tue, 12 Jul 2005 14:40:58 -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 5CCA88C389 for ; Tue, 12 Jul 2005 14:40:57 -0400 (EDT) Received: (qmail 94190 invoked by uid 3269); 12 Jul 2005 18:40:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94180 invoked from network); 12 Jul 2005 18:40:55 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 12 Jul 2005 18:40:55 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 12 Jul 2005 11:40:54 -0700 X-IronPort-AV: i="3.93,283,1115017200"; d="scan'208"; a="302744526:sNHT30990520" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6CIe9W1013854; Tue, 12 Jul 2005 11:40:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 11:40:32 -0700 Received: from [192.168.0.11] ([10.21.114.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 11:40:32 -0700 In-Reply-To: <42D4079B.5090503@qualcomm.com> References: <42D4079B.5090503@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Mark Baugher Date: Tue, 12 Jul 2005 11:39:30 -0700 To: ldondeti@qualcomm.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 12 Jul 2005 18:40:32.0104 (UTC) FILETIME=[2EE76E80:01C58711] Cc: elisabetta Carrara , Russ Housley , Colin Perkins , msec@securemulticast.org Subject: [MSEC] Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] 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, I think there is a misunderstanding here: >> ... >> I have reviewed this draft, and believe the material appropriate for >> publication as a proposed standard RFC. >> >> My only minor concern is that the data origin authentication features >> of TESLA are presented as extensions to SRTP, needing new headers and >> new processing rules, and not as a new authentication option for use >> within the existing SRTP framework. The protocol appears reasonable, >> but would be more obviously compatible with SRTP if it were presented >> differently. I would recommend either editorial clarifications to >> explain this or, if TESLA cannot be considered a new authentication >> option in the SRTP framework, a more detailed review of how this >> draft fits with SRTP as a whole. >> >> Colin >> It is definitely a new authentication option in the SRTP framework. =20 This is made clear in the document, viz. 4.1. The TESLA extension TESLA is an OPTIONAL authentication transform for SRTP. When used, TESLA adds the fields shown in Figure 1 per-packet. The fields added by TESLA are called "TESLA authentication extensions" altogether, whereas "authentication tag" or "integrity protection tag" indicate the normal SRTP integrity protection tag, when the SRTP master key is shared by more than two endpoints [RFC3711]. Baugher, Carrara [Page 4] =0C INTERNET-DRAFT TESLA-SRTP February 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Disclosed Key ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TESLA MAC ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The "TESLA authentication extension". speaking strictly for myself, I think this is the right way to add the=20= tesla function to a security protocol: As a new transform. All=20 security protocols need to be extensible to new transforms and support=20= the update of existing transforms in order to offer a known workload=20 factor as computers get faster, to handle advances in breaking=20 algorithms, and etc. By adding a new=20 authentication/message-integrity-check transform, TESLA gets added=20 without the need to redefine SRTP at all. It's business as usual. Mark p.s. I think that changing the protocol format is not a good way to add=20= tesla to a security protocol.= _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jul 12 14:58:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsPxb-0005Do-7Y for msec-archive@megatron.ietf.org; Tue, 12 Jul 2005 14:58:27 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23988 for ; Tue, 12 Jul 2005 14:58:25 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 590308C90B; Tue, 12 Jul 2005 14:58: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 19AF68C939 for ; Tue, 12 Jul 2005 14:58:25 -0400 (EDT) Received: (qmail 97062 invoked by uid 3269); 12 Jul 2005 18:58:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97059 invoked from network); 12 Jul 2005 18:58:24 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 12 Jul 2005 18:58:24 -0000 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 j6CIwHdd029797; Tue, 12 Jul 2005 11:58:17 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CIwC50027867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 11:58:13 -0700 (PDT) Message-ID: <42D412CA.7090308@qualcomm.com> Date: Tue, 12 Jul 2005 14:58:18 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher , Colin Perkins References: <42D4079B.5090503@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: elisabetta Carrara , Russ Housley , msec@securemulticast.org Subject: [MSEC] Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Thanks Mark. My *guess* is Colin is asking for an explanation as to why the auth tag cannot be reused to put the result of the TESLA computation. I think in MSEC we know the history behind it; so perhaps the TESLA-SRTP document should say in detail why (what are the pros and cons and why we chose to use two MACs instead of using one. The additional fields might also be a concern. Perhaps a section titled "Packet expansion due to TESLA" might help. Colin, please elaborate. Thanks. I also noticed that "4.2. SRTP Packet Format," Paragraph 1 says (recommended) authentication tag (SRTP MAC) ^^^^^^^^^^^^^ and Section 4.6, Paragraph 3 says The normal authentication tag (OPTIONAL for SRTP, ... ) ^^^^^^^^^^^ That seems inconsistent. Could you please double check? (Sorry I missed that in the previous readings of the draft.) Thanks. best regards, Lakshminath Mark Baugher wrote: > hi, > I think there is a misunderstanding here: > >>> > ... > >>> I have reviewed this draft, and believe the material appropriate for >>> publication as a proposed standard RFC. >>> >>> My only minor concern is that the data origin authentication features >>> of TESLA are presented as extensions to SRTP, needing new headers and >>> new processing rules, and not as a new authentication option for use >>> within the existing SRTP framework. The protocol appears reasonable, >>> but would be more obviously compatible with SRTP if it were presented >>> differently. I would recommend either editorial clarifications to >>> explain this or, if TESLA cannot be considered a new authentication >>> option in the SRTP framework, a more detailed review of how this >>> draft fits with SRTP as a whole. >>> >>> Colin >>> > > It is definitely a new authentication option in the SRTP framework. > This is made clear in the document, viz. > 4.1. The TESLA extension > > TESLA is an OPTIONAL authentication transform for SRTP. When used, > TESLA adds the fields shown in Figure 1 per-packet. The fields > added by TESLA are called "TESLA authentication extensions" > altogether, whereas "authentication tag" or "integrity protection > tag" indicate the normal SRTP integrity protection tag, when the > SRTP master key is shared by more than two endpoints [RFC3711]. > > Baugher, Carrara [Page 4] > > INTERNET-DRAFT TESLA-SRTP February 2005 > > > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | i | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Disclosed Key ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ TESLA MAC ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Figure 1: The "TESLA authentication extension". > > speaking strictly for myself, I think this is the right way to add the > tesla function to a security protocol: As a new transform. All > security protocols need to be extensible to new transforms and support > the update of existing transforms in order to offer a known workload > factor as computers get faster, to handle advances in breaking > algorithms, and etc. By adding a new > authentication/message-integrity-check transform, TESLA gets added > without the need to redefine SRTP at all. It's business as usual. > > Mark > > p.s. I think that changing the protocol format is not a good way to > add tesla to a security protocol. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jul 12 16:08:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsR2u-0008Ft-HE for msec-archive@megatron.ietf.org; Tue, 12 Jul 2005 16:08:00 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04342 for ; Tue, 12 Jul 2005 16:07:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9BEAC8C65F; Tue, 12 Jul 2005 16:07:56 -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 6BA5D8C57F for ; Tue, 12 Jul 2005 16:07:55 -0400 (EDT) Received: (qmail 9220 invoked by uid 3269); 12 Jul 2005 20:07:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9215 invoked from network); 12 Jul 2005 20:07:55 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 12 Jul 2005 20:07:55 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 12 Jul 2005 13:07:54 -0700 X-IronPort-AV: i="3.93,283,1115017200"; d="scan'208"; a="648174974:sNHT31714108" 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 j6CK7lov005562; Tue, 12 Jul 2005 13:07:48 -0700 (PDT) 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); Tue, 12 Jul 2005 13:07:52 -0700 Received: from [192.168.0.11] ([10.21.114.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 13:07:51 -0700 In-Reply-To: <42D412CA.7090308@qualcomm.com> References: <42D4079B.5090503@qualcomm.com> <42D412CA.7090308@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8f0b8e26021739bafbe5b0b2dcd22c2e@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Date: Tue, 12 Jul 2005 13:06:50 -0700 To: ldondeti@qualcomm.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 12 Jul 2005 20:07:51.0339 (UTC) FILETIME=[61BB3FB0:01C5871D] Cc: elisabetta Carrara , Russ Housley , Colin Perkins , msec@securemulticast.org Subject: [MSEC] Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] 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 Lakshminath, We discussed this extensively on the list and agreed that we would=20 have two MACs as a means to (1) integrity-check the group, which uses=20 an SRTP HMAC, and (2) integrity-check the sender, which uses TESLA. =20 There are other alternatives, but we defined the one that is the most=20 secure. We could define a second, but I would wait until we see that=20 this is needed because we don't like options in a security protocol; we=20= don't like doubling the complexity and use cases. At the present, we do compound authentication, which is all=20 completely defined by the specification. Mark On Jul 12, 2005, at 11:58 AM, Lakshminath Dondeti wrote: > Thanks Mark. > > > My *guess* is Colin is asking for an explanation as to why the auth=20 > tag cannot be reused to put the result of the TESLA computation. I=20 > think in MSEC we know the history behind it; so perhaps the TESLA-SRTP=20= > document should say in detail why (what are the pros and cons and why=20= > we chose to use two MACs instead of using one. The additional fields=20= > might also be a concern. Perhaps a section titled "Packet expansion=20= > due to TESLA" might help. > > Colin, please elaborate. Thanks. > > I also noticed that "4.2. SRTP Packet Format," Paragraph 1 says=20 > (recommended) authentication tag (SRTP MAC) > =20= > ^^^^^^^^^^^^^ > and > > Section 4.6, Paragraph 3 says The normal authentication tag (OPTIONAL=20= > for SRTP, ... ) > =20= > ^^^^^^^^^^^ > That seems inconsistent. Could you please double check? (Sorry I=20 > missed that in the previous readings of the draft.) Thanks. > > best regards, > Lakshminath > > Mark Baugher wrote: > >> hi, >> I think there is a misunderstanding here: >> >>>> >> ... >> >>>> I have reviewed this draft, and believe the material appropriate = for >>>> publication as a proposed standard RFC. >>>> >>>> My only minor concern is that the data origin authentication=20 >>>> features >>>> of TESLA are presented as extensions to SRTP, needing new headers=20= >>>> and >>>> new processing rules, and not as a new authentication option for = use >>>> within the existing SRTP framework. The protocol appears = reasonable, >>>> but would be more obviously compatible with SRTP if it were=20 >>>> presented >>>> differently. I would recommend either editorial clarifications to >>>> explain this or, if TESLA cannot be considered a new authentication >>>> option in the SRTP framework, a more detailed review of how this >>>> draft fits with SRTP as a whole. >>>> >>>> Colin >>>> >> >> It is definitely a new authentication option in the SRTP framework. =20= >> This is made clear in the document, viz. >> 4.1. The TESLA extension >> >> TESLA is an OPTIONAL authentication transform for SRTP. When = used, >> TESLA adds the fields shown in Figure 1 per-packet. The fields >> added by TESLA are called "TESLA authentication extensions" >> altogether, whereas "authentication tag" or "integrity protection >> tag" indicate the normal SRTP integrity protection tag, when the >> SRTP master key is shared by more than two endpoints [RFC3711]. >> >> Baugher, Carrara [Page = 4] >> =0C >> INTERNET-DRAFT TESLA-SRTP February = 2005 >> >> >> >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | i | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ Disclosed Key ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ TESLA MAC ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Figure 1: The "TESLA authentication extension". >> >> speaking strictly for myself, I think this is the right way to add=20 >> the tesla function to a security protocol: As a new transform. All=20= >> security protocols need to be extensible to new transforms and=20 >> support the update of existing transforms in order to offer a known=20= >> workload factor as computers get faster, to handle advances in=20 >> breaking algorithms, and etc. By adding a new=20 >> authentication/message-integrity-check transform, TESLA gets added=20 >> without the need to redefine SRTP at all. It's business as usual. >> >> Mark >> >> p.s. I think that changing the protocol format is not a good way to=20= >> add tesla to a security protocol. > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jul 12 18:23:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsT9r-0002Cg-Nd for msec-archive@megatron.ietf.org; Tue, 12 Jul 2005 18:23:19 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24934 for ; Tue, 12 Jul 2005 18:23:16 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8CF0D8C553; Tue, 12 Jul 2005 18:23:17 -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 E7BC28C3D2 for ; Tue, 12 Jul 2005 18:23:15 -0400 (EDT) Received: (qmail 34582 invoked by uid 3269); 12 Jul 2005 22:23:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34579 invoked from network); 12 Jul 2005 22:23:15 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 12 Jul 2005 22:23:15 -0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CMN7WQ025163; Tue, 12 Jul 2005 15:23:08 -0700 (PDT) Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CMN0TW021683; Tue, 12 Jul 2005 15:23:04 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 15:23:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Jul 2005 15:22:59 -0700 Message-ID: Thread-Topic: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] Thread-Index: AcWHHWfhW7N+r+hRR9+HUWi5osPRygAEXKSW From: "Dondeti, Lakshminath" To: "Mark Baugher" X-OriginalArrivalTime: 12 Jul 2005 22:23:02.0243 (UTC) FILETIME=[4434FB30:01C58730] Cc: elisabetta Carrara , Russ Housley , Colin Perkins , msec@securemulticast.org Subject: [MSEC] RE: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] 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="===============0681329745==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0681329745== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58730.429E54A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58730.429E54A6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, Thanks. Perhaps some additional text along the lines you explain below = and responding to Colin's request would be great! Have you had a chance to look at the RECOMMENDED vs. OPTIONAL references = I listed below. thanks again, Lakshminath -----Original Message----- From: Mark Baugher [mailto:mbaugher@cisco.com] Sent: Tue 7/12/2005 1:06 PM To: Dondeti, Lakshminath Cc: msec@securemulticast.org; Colin Perkins; elisabetta Carrara; Russ = Housley Subject: Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to = Proposed Standard] =20 Lakshminath, We discussed this extensively on the list and agreed that we would=20 have two MACs as a means to (1) integrity-check the group, which uses=20 an SRTP HMAC, and (2) integrity-check the sender, which uses TESLA. =20 There are other alternatives, but we defined the one that is the most=20 secure. We could define a second, but I would wait until we see that=20 this is needed because we don't like options in a security protocol; we=20 don't like doubling the complexity and use cases. At the present, we do compound authentication, which is all=20 completely defined by the specification. Mark On Jul 12, 2005, at 11:58 AM, Lakshminath Dondeti wrote: > Thanks Mark. > > > My *guess* is Colin is asking for an explanation as to why the auth=20 > tag cannot be reused to put the result of the TESLA computation. I=20 > think in MSEC we know the history behind it; so perhaps the TESLA-SRTP = > document should say in detail why (what are the pros and cons and why=20 > we chose to use two MACs instead of using one. The additional fields=20 > might also be a concern. Perhaps a section titled "Packet expansion=20 > due to TESLA" might help. > > Colin, please elaborate. Thanks. > > I also noticed that "4.2. SRTP Packet Format," Paragraph 1 says=20 > (recommended) authentication tag (SRTP MAC) > = > ^^^^^^^^^^^^^ > and > > Section 4.6, Paragraph 3 says The normal authentication tag (OPTIONAL=20 > for SRTP, ... ) > = > ^^^^^^^^^^^ > That seems inconsistent. Could you please double check? (Sorry I=20 > missed that in the previous readings of the draft.) Thanks. > > best regards, > Lakshminath > > Mark Baugher wrote: > >> hi, >> I think there is a misunderstanding here: >> >>>> >> ... >> >>>> I have reviewed this draft, and believe the material appropriate = for >>>> publication as a proposed standard RFC. >>>> >>>> My only minor concern is that the data origin authentication=20 >>>> features >>>> of TESLA are presented as extensions to SRTP, needing new headers=20 >>>> and >>>> new processing rules, and not as a new authentication option for = use >>>> within the existing SRTP framework. The protocol appears = reasonable, >>>> but would be more obviously compatible with SRTP if it were=20 >>>> presented >>>> differently. I would recommend either editorial clarifications to >>>> explain this or, if TESLA cannot be considered a new authentication >>>> option in the SRTP framework, a more detailed review of how this >>>> draft fits with SRTP as a whole. >>>> >>>> Colin >>>> >> >> It is definitely a new authentication option in the SRTP framework. =20 >> This is made clear in the document, viz. >> 4.1. The TESLA extension >> >> TESLA is an OPTIONAL authentication transform for SRTP. When = used, >> TESLA adds the fields shown in Figure 1 per-packet. The fields >> added by TESLA are called "TESLA authentication extensions" >> altogether, whereas "authentication tag" or "integrity protection >> tag" indicate the normal SRTP integrity protection tag, when the >> SRTP master key is shared by more than two endpoints [RFC3711]. >> >> Baugher, Carrara [Page = 4] >> =0C >> INTERNET-DRAFT TESLA-SRTP February = 2005 >> >> >> >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | i | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ Disclosed Key ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ TESLA MAC ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Figure 1: The "TESLA authentication extension". >> >> speaking strictly for myself, I think this is the right way to add=20 >> the tesla function to a security protocol: As a new transform. All=20 >> security protocols need to be extensible to new transforms and=20 >> support the update of existing transforms in order to offer a known=20 >> workload factor as computers get faster, to handle advances in=20 >> breaking algorithms, and etc. By adding a new=20 >> authentication/message-integrity-check transform, TESLA gets added=20 >> without the need to redefine SRTP at all. It's business as usual. >> >> Mark >> >> p.s. I think that changing the protocol format is not a good way to=20 >> add tesla to a security protocol. > ------_=_NextPart_001_01C58730.429E54A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to = Proposed Standard]

Mark,

Thanks.  Perhaps some additional text along the lines you explain = below and responding to Colin's request would be great!

Have you had a chance to look at the RECOMMENDED vs. OPTIONAL references = I listed below.

thanks again,
Lakshminath

-----Original Message-----
From: Mark Baugher [mailto:mbaugher@cisco.com]
Sent: Tue 7/12/2005 1:06 PM
To: Dondeti, Lakshminath
Cc: msec@securemulticast.org; Colin Perkins; elisabetta Carrara; Russ = Housley
Subject: Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to = Proposed Standard]

Lakshminath,
   We discussed this extensively on the list and agreed that = we would
have two MACs as a means to (1) integrity-check the group, which = uses
an SRTP HMAC, and (2) integrity-check the sender, which uses = TESLA. 
There are other alternatives, but we defined the one that is the = most
secure.  We could define a second, but I would wait until we see = that
this is needed because we don't like options in a security protocol; = we
don't like doubling the complexity and use cases.

   At the present, we do compound authentication, which is = all
completely defined by the specification.

Mark
On Jul 12, 2005, at 11:58 AM, Lakshminath Dondeti wrote:

> Thanks Mark.
> <Speaking as a contributor to the MSEC WG.>
>
> My *guess* is Colin is asking for an explanation as to why the = auth
> tag cannot be reused to put the result of the TESLA = computation.  I
> think in MSEC we know the history behind it; so perhaps the = TESLA-SRTP
> document should say in detail why (what are the pros and cons and = why
> we chose to use two MACs instead of using one.  The additional = fields
> might also be a concern.  Perhaps a section titled = "Packet expansion
> due to TESLA" might help.
>
> Colin, please elaborate.  Thanks.
>
> I also noticed that "4.2. SRTP Packet Format," Paragraph = 1  says
> (recommended)  authentication tag (SRTP MAC)
>           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;          
>           &nb= sp;        ^^^^^^^^^^^^^
> and
>
> Section 4.6, Paragraph 3 says The normal authentication tag = (OPTIONAL
> for SRTP, ... )
>           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;          
>           &nb= sp;  ^^^^^^^^^^^
> That seems inconsistent.  Could you please double check? = (Sorry I
> missed that in the previous readings of the draft.)  = Thanks.
>
> best regards,
> Lakshminath
>
> Mark Baugher wrote:
>
>> hi,
>>   I think there is a misunderstanding here:
>>
>>>>
>> ...
>>
>>>> I have reviewed this draft, and believe the material = appropriate for
>>>> publication as a proposed standard RFC.
>>>>
>>>> My only minor concern is that the data origin = authentication
>>>> features
>>>> of TESLA are presented as extensions to SRTP, needing = new headers
>>>> and
>>>> new processing rules, and not as a new authentication = option for use
>>>> within the existing SRTP framework. The protocol = appears reasonable,
>>>> but would be more obviously compatible with SRTP if it = were
>>>> presented
>>>> differently. I would recommend either editorial = clarifications to
>>>> explain this or, if TESLA cannot be considered a new = authentication
>>>> option in the SRTP framework, a more detailed review of = how this
>>>> draft fits with SRTP as a whole.
>>>>
>>>> Colin
>>>>
>>
>> It is definitely a new authentication option in the SRTP = framework. 
>> This is made clear in the document, viz.
>> 4.1. The TESLA extension
>>
>>    TESLA is an OPTIONAL authentication transform = for SRTP.  When used,
>>    TESLA adds the fields shown in Figure 1 = per-packet.  The fields
>>    added by TESLA are called "TESLA = authentication extensions"
>>    altogether, whereas "authentication = tag" or "integrity protection
>>    tag" indicate the normal SRTP integrity = protection tag, when the
>>    SRTP master key is shared by more than two = endpoints [RFC3711].
>>
>> Baugher, = Carrara           =             &= nbsp;           &n= bsp;          [Page 4]
>> =0C
>> = INTERNET-DRAFT          = ;       = TESLA-SRTP          &nb= sp;     February 2005
>>
>>
>>
>>
>>    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
>>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    = |            =             &= nbsp;     = i            =             &= nbsp;       |
>>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    = ~            =              = Disclosed = Key           &nbs= p;            = ; ~
>>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    = ~            =             &= nbsp;  TESLA = MAC           &nbs= p;            = ;   ~
>>    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    Figure 1: The "TESLA authentication = extension".
>>
>> speaking strictly for myself, I think this is the right way to = add
>> the tesla function to a security protocol:  As a new = transform.  All
>> security protocols need to be extensible to new transforms = and
>> support the update of existing transforms in order to offer a = known
>> workload factor as computers get faster, to handle advances = in
>> breaking algorithms, and etc.  By adding a new
>> authentication/message-integrity-check transform, TESLA gets = added
>> without the need to redefine SRTP at all.  It's business = as usual.
>>
>> Mark
>>
>> p.s. I think that changing the protocol format is not a good = way to
>> add tesla to a security protocol.
>

------_=_NextPart_001_01C58730.429E54A6-- --===============0681329745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0681329745==-- From msec-bounces@securemulticast.org Wed Jul 13 18:25:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dspfy-00089z-Ab for msec-archive@megatron.ietf.org; Wed, 13 Jul 2005 18:25:58 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21249 for ; Wed, 13 Jul 2005 18:25:55 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5C4018C3BB; Wed, 13 Jul 2005 18:25:57 -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 C043C8C391 for ; Wed, 13 Jul 2005 18:25:55 -0400 (EDT) Received: (qmail 21624 invoked by uid 3269); 13 Jul 2005 22:25:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21619 invoked from network); 13 Jul 2005 22:25:55 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 13 Jul 2005 22:25:55 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2005 15:25:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6DMPlVb009315; Wed, 13 Jul 2005 15:25:52 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 15:25:51 -0700 Received: from [192.168.0.11] ([10.21.120.252]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 15:25:50 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Mark Baugher Date: Wed, 13 Jul 2005 15:25:51 -0700 To: Lakshminath Dondeti , Francois Audet X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 13 Jul 2005 22:25:50.0641 (UTC) FILETIME=[D2FE3A10:01C587F9] Cc: "'Cullen Jennings'" , Dave Oran , msec@securemulticast.org, Flemming S Andreasen , dignjatic@polycom.com, Dan Wing Subject: [MSEC] Re: Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-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 Content-Transfer-Encoding: quoted-printable Francois, Lakshminath I think what we want to define for MIKEY is the ability of the=20 responder to hand the initiator a key. This is done in rsa-r and it is=20= done in RFC 3547 (GDOI). RFC 3830 (MIKEY) initiators hand the key to=20 the responder, not vice versa, so I see why you want to change that=20 when talking to bridges, controllers, etc. Existing msec RFCs also discuss the following issue that you raise: > "When using the RSA-R mode, the Responder may turn out to be=20 > different > from who the Initiator sent the MIKEY message to. It is the > responsibility of the Initiator to verify that the identity of the > Responder is acceptable if it changes from the intended Responder, > > > > Ignjatic, et al. Expires January 8, 2006 [Page=20= > 10] > =0C > Internet-Draft MIKEY-RSA-R July=20 > 2005 > > > based on its policy, and to take appropriate action based on the > outcome. In some cases, it could be appropriate to accept any > Responder's identity; in other cases, a blacklist or a whitelist = may > be appropriate." I don't see why we are going here and admitting antispam mechanisms in=20= the key establishment. I would expect that the initiator will=20 establish a connection with the responder, which has a cryptographic=20 identity. What if the message gets redirected or (more likely)=20 intercepted and another entity responds? We discuss this in RFC 3547=20 and also is RFC 4046: "Alternatively, the sender may forward rekey messages on behalf of the GCKS when it uses a credential mechanism that supports delegation. Thus, it is possible for the sender, or other members, to source keying material (TPKs encrypted in the Group KEK) as it sources multicast or unicast data. As mentioned above, the rekey message = can be sent using unicast or multicast delivery. Upon receipt of a TPK (as part of a Data SA) via a rekey message or a registration = protocol exchange, the member's group key management functional block will provide the new or updated security association (SA) to the data security protocol. This protects the data sent from sender to receiver." In other words, rsa-r can be used by a credentialing mechanism that=20 supports delegation or some other method that allows the initiator to=20 determine (1) that the responder is authorized to respond (perhaps for=20= an entity with a different identity) and (2) the initiator is=20 authorized to communicate with the particular responder, or delegated=20 responder. The way it's written now, it just sounds like something that could be=20 done very insecurely. It says that the initiator is responsible but=20 does not give a clue how it could be done. Mark _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jul 13 19:02:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqFb-0007TM-Vg for msec-archive@megatron.ietf.org; Wed, 13 Jul 2005 19:02:48 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23333 for ; Wed, 13 Jul 2005 19:02:45 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 28EF88C20C; Wed, 13 Jul 2005 19:02:47 -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 786898C204 for ; Wed, 13 Jul 2005 19:02:45 -0400 (EDT) Received: (qmail 26602 invoked by uid 3269); 13 Jul 2005 23:02:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26599 invoked from network); 13 Jul 2005 23:02:45 -0000 Received: from softdnserror (HELO milpmailbhs.milpitas.polycom.com) (140.242.16.3) by klesh.pair.com with SMTP; 13 Jul 2005 23:02:45 -0000 Received: from vanmail01.vancouver.polycom.com ([172.16.1.119]) by milpmailbhs.milpitas.polycom.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 16:02:42 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2005 16:02:22 -0700 Message-ID: <4280DB4085C0FC4BAA41AB503C1024D0091E82@vanmail01.vancouver.polycom.com> Thread-Topic: Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Thread-Index: AcWH+defUMn6mjMWSQyU/DeoMPdVYAABEJKw From: "Ignjatic, Dragan" To: "Mark Baugher" , "Lakshminath Dondeti" , "Francois Audet" X-OriginalArrivalTime: 13 Jul 2005 23:02:42.0540 (UTC) FILETIME=[F9633AC0:01C587FE] Cc: Cullen Jennings , Flemming S Andreasen , Dave Oran , Dan Wing , msec@securemulticast.org Subject: [MSEC] RE: Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-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 Content-Transfer-Encoding: quoted-printable Thanks Mark, We will try to be more explicit about Initiator's options here. There is a number of ways how this can (securely) be done and we should list the acceptable methods. Regards, Dragan -----Original Message----- From: Mark Baugher [mailto:mbaugher@cisco.com]=20 Sent: July 13, 2005 3:26 PM To: Lakshminath Dondeti; Francois Audet Cc: 'Cullen Jennings'; Ignjatic, Dragan; Dan Wing; msec@securemulticast.org; Dave Oran; Flemming S Andreasen Subject: Re: Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt Francois, Lakshminath I think what we want to define for MIKEY is the ability of the=20 responder to hand the initiator a key. This is done in rsa-r and it is=20 done in RFC 3547 (GDOI). RFC 3830 (MIKEY) initiators hand the key to=20 the responder, not vice versa, so I see why you want to change that=20 when talking to bridges, controllers, etc. Existing msec RFCs also discuss the following issue that you raise: > "When using the RSA-R mode, the Responder may turn out to be=20 > different > from who the Initiator sent the MIKEY message to. It is the > responsibility of the Initiator to verify that the identity of the > Responder is acceptable if it changes from the intended Responder, > > > > Ignjatic, et al. Expires January 8, 2006 [Page=20 > 10] >=20 > Internet-Draft MIKEY-RSA-R July=20 > 2005 > > > based on its policy, and to take appropriate action based on the > outcome. In some cases, it could be appropriate to accept any > Responder's identity; in other cases, a blacklist or a whitelist may > be appropriate." I don't see why we are going here and admitting antispam mechanisms in=20 the key establishment. I would expect that the initiator will=20 establish a connection with the responder, which has a cryptographic=20 identity. What if the message gets redirected or (more likely)=20 intercepted and another entity responds? We discuss this in RFC 3547=20 and also is RFC 4046: "Alternatively, the sender may forward rekey messages on behalf of the GCKS when it uses a credential mechanism that supports delegation. Thus, it is possible for the sender, or other members, to source keying material (TPKs encrypted in the Group KEK) as it sources multicast or unicast data. As mentioned above, the rekey message can be sent using unicast or multicast delivery. Upon receipt of a TPK (as part of a Data SA) via a rekey message or a registration protocol exchange, the member's group key management functional block will provide the new or updated security association (SA) to the data security protocol. This protects the data sent from sender to receiver." In other words, rsa-r can be used by a credentialing mechanism that=20 supports delegation or some other method that allows the initiator to=20 determine (1) that the responder is authorized to respond (perhaps for=20 an entity with a different identity) and (2) the initiator is=20 authorized to communicate with the particular responder, or delegated=20 responder. The way it's written now, it just sounds like something that could be=20 done very insecurely. It says that the initiator is responsible but=20 does not give a clue how it could be done. Mark _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jul 14 00:36:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsvSp-0004wz-1j for msec-archive@megatron.ietf.org; Thu, 14 Jul 2005 00:36:47 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09713 for ; Thu, 14 Jul 2005 00:36:44 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 014BE8C428; Thu, 14 Jul 2005 00:36: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 EA0198C3F2 for ; Thu, 14 Jul 2005 00:36:44 -0400 (EDT) Received: (qmail 20716 invoked by uid 3269); 14 Jul 2005 04:36:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20704 invoked from network); 14 Jul 2005 04:36:28 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 14 Jul 2005 04:36:28 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2005 21:36:26 -0700 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 j6E4aMod019000; Wed, 13 Jul 2005 21:36:23 -0700 (PDT) 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, 13 Jul 2005 21:36:25 -0700 Received: from [192.168.0.11] ([10.21.99.167]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 21:36:24 -0700 In-Reply-To: References: <42D4079B.5090503@qualcomm.com> <42D412CA.7090308@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2029927c32648f2f1cf20461bb9ed964@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Wed, 13 Jul 2005 21:36:25 -0700 To: Colin Perkins X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 14 Jul 2005 04:36:24.0682 (UTC) FILETIME=[9783A4A0:01C5882D] Cc: Russ Housley , elisabetta Carrara , msec@securemulticast.org Subject: [MSEC] Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] 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 Colin, Thanks for your comments. More below... On Jul 12, 2005, at 1:15 PM, Colin Perkins wrote: > On 12 Jul 2005, at 19:58, Lakshminath Dondeti wrote: ... >> Colin, please elaborate. Thanks. > > That's close: I'm asking why the TESLA MAC is presented as a new set > of headers to be added to SRTP, rather than as part of the existing > authentication header (which would gain more structure to include the > second MAC). There didn't seem to be a good rationale for extending > SRTP, We're not, the whole thing is processed by tesla but the tesla authentication tag is a compound tag with different parts for different purposes. > rather than registering a new authentication mechanism that happens to > do something funky with dual MACs, but within the usual SRTP > framework. Yes this is a new authentication framework that does something funky with dual MACs. What am I missing? Mark > > Colin > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 18 12:26:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuYRg-0000VJ-EV for msec-archive@megatron.ietf.org; Mon, 18 Jul 2005 12:26:21 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25876 for ; Mon, 18 Jul 2005 12:26:14 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EFAA48C40A; Mon, 18 Jul 2005 12:26:15 -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 DD5ED8BF9E for ; Mon, 18 Jul 2005 12:26:13 -0400 (EDT) Received: (qmail 75519 invoked by uid 3269); 18 Jul 2005 16:26:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75516 invoked from network); 18 Jul 2005 16:26:13 -0000 Received: from mailgw3.ericsson.se (193.180.251.60) by klesh.pair.com with SMTP; 18 Jul 2005 16:26:13 -0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 618DC4F0009; Mon, 18 Jul 2005 18:26:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 18:26:08 +0200 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 18:26:08 +0200 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, 18 Jul 2005 18:26:08 +0200 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD65010A1DE7@esealmw106.eemea.ericsson.se> Thread-Topic: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] Thread-Index: AcWJfs2GjTewh8mPTXGz182n45csaQCNOIFw From: "Elisabetta Carrara (AL/EAB)" To: "Colin Perkins" X-OriginalArrivalTime: 18 Jul 2005 16:26:08.0690 (UTC) FILETIME=[67369920:01C58BB5] X-Brightmail-Tracker: AAAAAA== Cc: Russ Housley , canetti@watson.ibm.com, Mark Baugher , msec@securemulticast.org Subject: [MSEC] RE: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] 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 Colin! your proposal appears good. It also shows well what a new transform=20 that needs its own fields should do; for example, a cipher=20 with an explicit IV may define to place such IV in front of the=20 payload.=20 However, the reason why the TESLA fields are placed like that, is=20 the authentication coverage. It actually appeared to us a nice fit to place all the fields to be authenticated together at the beginning.=20 I think to recall that the TESLA RFC requires the group-key MAC=20 (i.e. the SRTP MAC, here) to cover the message and the TESLA-own=20 fields. Hence, this would mean that, if we apply your proposal (your drawing=20 nr 2), then we would have the following: - there is a "jump" in coverage (since the MKI is not integrity=20 protected in SRTP)[although this would not really have any impact=20 in terms of implementation] - what you call "MAC including TESLA MAC" would cover in part itself=20 (the TESLA fields). This is not very elegant, although I believe it has no implementation impact. Would this two things be acceptable? I think so, maybe they are not=20 extremely "elegant", still should have not big implications, as far as I can see.=20 Given these explanations, any preference from you and the msec folk is=20 welcome.=20 We had another issue to solve with GenArt (Elwyn Davies reviewed the draft), and your drawing nr 2 much better aligns with the new fix we have to do (which is, we make the flag for TESLA an IANA registration within SRTP's identifier for the authentication algorithm transform). Thanks for your review cheers /E >-----Original Message----- >From: Colin Perkins [mailto:csp@csperkins.org] >Sent: den 15 juli 2005 18:00 >To: Mark Baugher >Cc: msec@securemulticast.org; ldondeti@qualcomm.com; Elisabetta Carrara >(AL/EAB); Russ Housley >Subject: Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to >Proposed Standard] > > >Mark, > >On 14 Jul 2005, at 05:36, Mark Baugher wrote: >> On Jul 12, 2005, at 1:15 PM, Colin Perkins wrote: >... >>> That's close: I'm asking why the TESLA MAC is presented as a new =20 >>> set of headers to be added to SRTP, rather than as part of the =20 >>> existing authentication header (which would gain more structure to =20 >>> include the second MAC). There didn't seem to be a good rationale =20 >>> for extending SRTP, >> >> We're not, the whole thing is processed by tesla but the tesla =20 >> authentication tag is a compound tag with different parts for =20 >> different purposes. > >Sure, but that's not how the draft is presented. Section 4 states =20 >"The present specification is an extension to the SRTP =20 >specification", and defines an extra TESLA MAC header field in SRTP =20 >before the MKI and MAC fields. Instead of using: > > +-------------+ > | RTP header | > +-------------+ > | RTP payload | > +-------------+ > | TESLA MAC | > +-------------+ > | MKI | > +-------------+ > | MAC | > +-------------+ > >I was expecting: > > +---------------+ > | RTP header | > +---------------+ > | RTP payload | > +---------------+ > | MKI | > +---------------+ > | MAC including | > | TESLA MAC | > +---------------+ > >with the TESLA processing being described as part of the usual MAC =20 >processing steps of SRTP, rather than as extra steps. This would seem =20 >to be a better fit to the SRTP model, than the addition of extra =20 >headers and processing steps. > >If there's a good reason for the ordering in the draft, that's fine =20 >and just needs explaining. However, the reasoning isn't clear from =20 >the draft, making it appear gratuitously different. > >Cheers, >Colin > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 18 15:02:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duasz-0004CG-Q2 for msec-archive@megatron.ietf.org; Mon, 18 Jul 2005 15:02:42 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06140 for ; Mon, 18 Jul 2005 15:02:39 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5057C8C603; Mon, 18 Jul 2005 15:02:40 -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 149FE8C5CB for ; Mon, 18 Jul 2005 15:02:39 -0400 (EDT) Received: (qmail 7423 invoked by uid 3269); 18 Jul 2005 19:02:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7414 invoked from network); 18 Jul 2005 19:02:38 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 18 Jul 2005 19:02:38 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Jul 2005 12:02:30 -0700 X-IronPort-AV: i="3.93,297,1115017200"; d="scan'208"; a="313750330:sNHT1445051842" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6IJ2IVf017668; Mon, 18 Jul 2005 12:02:27 -0700 (PDT) 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); Mon, 18 Jul 2005 12:02:19 -0700 Received: from [192.168.0.12] ([10.21.97.44]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 12:02:18 -0700 In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD65010A1DE7@esealmw106.eemea.ericsson.se> References: <0CDAE977A7172A40A2A3A1C20C12BD65010A1DE7@esealmw106.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <91aced67e2067c1fa9261c8e9984dead@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Mon, 18 Jul 2005 12:02:19 -0700 To: "Elisabetta Carrara (AL/EAB)" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 18 Jul 2005 19:02:18.0994 (UTC) FILETIME=[38598520:01C58BCB] Cc: Russ Housley , canetti , "'Dave Oran'" , msec@securemulticast.org, "David A. McGrew" , =?ISO-8859-1?Q?Mats_N=E4slund?= , Colin Perkins Subject: [MSEC] Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] 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 Elisabetta, Colin Thanks to Elisabetta for explaining why we did not make the two authentication tags contiguous. We wanted one tag to cover the other (viz. from P.6 of http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-03.txt), 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ |V=2|P|X| CC |M| PT | sequence number | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | synchronization source (SSRC) identifier | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | contributing source (CSRC) identifiers | | | | .... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RTP extension (OPTIONAL) | | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | payload ... | | | | | +-------------------------------+ | | | | | RTP padding | RTP pad count | | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | | | i | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ Disclosed Key ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ TESLA MAC ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ | ~ MKI ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ MAC ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +- Encrypted Portion TESLA Authenticated Portion ---+ | | Authenticated Portion ---+ SRTP HMAC-SHA1 includes up to the MKI field but does not include MKI. We want SRTP-TESLA tag to be covered by the SRTP HMAC-SHA-1 integrity check. SRTP authors decided in our infinite wisdom not to cover the MKI field (because it did not need to be covered for SRTP packet integrity). In order to make the two tags (SRTP-TESLA and SRTP-HMAC_SHA1) contiguous, we would need to redefine the SRTP specification to include the MKI in HMAC-SHA1 coverage. We don't want to do that. Unfortunately, this looks like a new packet format to people who know RTP. Hence it follows to some that it requires a new profile as did SRTP. But SRTP does not need to have profiles because it is a framework that accommodates upgrade (e.g. 256-bit AES, SRTP-TESLA) and replacement (e.g. f8 with AES) of authentication and encryption transforms, any of which may change the packet format (e.g. a 32-bit tag instead of an 80 bit tag). We made SRTP-TESLA practically transparent to SRTP-HMAC-SHA1 processing, and included the TESLA tag in the HMAC integrity check (i.e. it is contiguous with the payload portion of the packet and easily covered by the integrity-check value). The point of doing the HMAC integrity check is to add an additional layer of authentication that prevents non group-members from submitting packets to SRTP-TESLA processing as a denial-of-service prevention mechanism. I recommend that we don't make the two authentication tags to be contiguous in the packet. Instead, we think of everything beyond the end of the application payload as being SRTP and key management stuff that are interpreted under a given transform or cipher suite. Mark On Jul 18, 2005, at 9:26 AM, Elisabetta Carrara (AL/EAB) wrote: > Hi Colin! > > your proposal appears good. It also shows well what a new transform > that needs its own fields should do; for example, a cipher > with an explicit IV may define to place such IV in front of the > payload. > > However, the reason why the TESLA fields are placed like that, is > the authentication coverage. It actually appeared to us a nice fit to > place all the fields to be authenticated together at the beginning. > I think to recall that the TESLA RFC requires the group-key MAC > (i.e. the SRTP MAC, here) to cover the message and the TESLA-own > fields. > Hence, this would mean that, if we apply your proposal (your drawing > nr 2), then we would have the following: > - there is a "jump" in coverage (since the MKI is not integrity > protected in SRTP)[although this would not really have any impact > in terms of implementation] > - what you call "MAC including TESLA MAC" would cover in part itself > (the TESLA fields). This is not very elegant, although I believe > it has no implementation impact. > > Would this two things be acceptable? I think so, maybe they are not > extremely "elegant", still should have not big implications, as far as > I > can see. > > Given these explanations, any preference from you and the msec folk is > welcome. > > We had another issue to solve with GenArt (Elwyn Davies reviewed the > draft), and your drawing nr 2 much better aligns with the new fix > we have to do (which is, we make the flag for TESLA an IANA > registration > within SRTP's identifier for the authentication algorithm transform). > > Thanks for your review > cheers > /E > > > > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: den 15 juli 2005 18:00 >> To: Mark Baugher >> Cc: msec@securemulticast.org; ldondeti@qualcomm.com; Elisabetta >> Carrara >> (AL/EAB); Russ Housley >> Subject: Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to >> Proposed Standard] >> >> >> Mark, >> >> On 14 Jul 2005, at 05:36, Mark Baugher wrote: >>> On Jul 12, 2005, at 1:15 PM, Colin Perkins wrote: >> ... >>>> That's close: I'm asking why the TESLA MAC is presented as a new >>>> set of headers to be added to SRTP, rather than as part of the >>>> existing authentication header (which would gain more structure to >>>> include the second MAC). There didn't seem to be a good rationale >>>> for extending SRTP, >>> >>> We're not, the whole thing is processed by tesla but the tesla >>> authentication tag is a compound tag with different parts for >>> different purposes. >> >> Sure, but that's not how the draft is presented. Section 4 states >> "The present specification is an extension to the SRTP >> specification", and defines an extra TESLA MAC header field in SRTP >> before the MKI and MAC fields. Instead of using: >> >> +-------------+ >> | RTP header | >> +-------------+ >> | RTP payload | >> +-------------+ >> | TESLA MAC | >> +-------------+ >> | MKI | >> +-------------+ >> | MAC | >> +-------------+ >> >> I was expecting: >> >> +---------------+ >> | RTP header | >> +---------------+ >> | RTP payload | >> +---------------+ >> | MKI | >> +---------------+ >> | MAC including | >> | TESLA MAC | >> +---------------+ >> >> with the TESLA processing being described as part of the usual MAC >> processing steps of SRTP, rather than as extra steps. This would seem >> to be a better fit to the SRTP model, than the addition of extra >> headers and processing steps. >> >> If there's a good reason for the ordering in the draft, that's fine >> and just needs explaining. However, the reasoning isn't clear from >> the draft, making it appear gratuitously different. >> >> Cheers, >> Colin >> > _______________________________________________ > 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 Jul 18 15:31:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubKd-0003hw-5F for msec-archive@megatron.ietf.org; Mon, 18 Jul 2005 15:31:15 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09249 for ; Mon, 18 Jul 2005 15:31:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C61118C5CD; Mon, 18 Jul 2005 15:31:11 -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 01B528C520 for ; Mon, 18 Jul 2005 15:31:10 -0400 (EDT) Received: (qmail 14635 invoked by uid 3269); 18 Jul 2005 19:31:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14570 invoked from network); 18 Jul 2005 19:30:53 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 18 Jul 2005 19:30:53 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6IJSdXS017863; Mon, 18 Jul 2005 12:28:40 -0700 (PDT) Received: from [129.46.75.2] (ldondeti.na.qualcomm.com [129.46.75.2]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6IJSaRq025593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jul 2005 12:28:36 -0700 (PDT) Message-ID: <42DC02E3.8000503@qualcomm.com> Date: Mon, 18 Jul 2005 15:28:35 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org References: <0CDAE977A7172A40A2A3A1C20C12BD65010A1DE0@esealmw106.eemea.ericsson.se> <42DBB254.4070204@dial.pipex.com> In-Reply-To: <42DBB254.4070204@dial.pipex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David R Oran , canetti Canetti , Russ Housley , "Elisabetta Carrara (AL/EAB)" , "David A. McGrew" , Mark Baugher , Elwyn Davies Subject: [MSEC] Re: Gen-Art Review: draft-ietf-msec-srtp-tesla-03.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Resending Elwyn's review thread to the MSEC list so others in the MSEC list can participate in the discussion. regards, Lakshminath Elwyn Davies wrote: > Glad to be of assistance :-) > > I just saw David (M)'s reply also. > > As regards avt's view of the world, that is not something I know about > and you are in a better position to know. IMHO the TESLA addition > would seem to give the sort of extra facility that an application > would understand and would justify a new profile. As I understand it > there are currently two profiles RTP and SRTP with maybe another one > in the pipeline - I am not sure that four doesn't count as very low... > Maybe avt count 1, 2, Many O:-) > > Maybe the security and application AD's should give an opinion on this. > > Regards, > Elwyn > > > > Elisabetta Carrara (AL/EAB) wrote: > >> Hi! >> yes, thanks for your review, Elwyn. >> You are correct -- we should have not defined a transform independent >> parameter. Indeed, there is already a transform independent parameter >> that can be used to flag the use of TESLA, the "identifier for the >> message authentication algorithm". Once TESLA is flagged (via MIKEY >> or sdescription), then there is the logic to understand the added >> field. >> Hence, we propose to follow the first of your suggestion, basically >> take away the definition of the transform independent parameter, and >> go for the appropriate IANA registration of TESLA_in_SRTP as >> new value for the already existing "identifier for the message >> authentication algorithm". >> >> (Note also, we know that the avt group does not want to have many RTP >> profiles, they have explicitly stated to expect the number of >> profiles to be very low.) >> >> Thanks again >> cheers >> /E >> >> >> >> >> >>> -----Original Message----- >>> From: David A. McGrew [mailto:mcgrew@cisco.com] >>> Sent: den 18 juli 2005 15:06 >>> To: Elwyn Davies >>> Cc: gen-art@alvestrand.no; canetti Canetti; Mark Baugher; David R Oran; >>> Elisabetta Carrara (AL/EAB); Russ Housley >>> Subject: Re: Gen-Art Review: draft-ietf-msec-srtp-tesla-03.txt >>> >>> >>> Elwyn, >>> >>> thanks for the detailed explanation. You are right about the >>> transform independent parameter. I think (and I believe that Mark >>> and Elisabetta do as well) that it would be best to eliminate it >>> from the spec but keep the current approach in that doc. >>> >>> David >>> >>> On Jul 15, 2005, at 1:22 AM, Elwyn Davies wrote: >>> >>> >>> >>>> Hi. >>>> >>>> The technical point that came over as a red flag was that you are >>>> adding a new transform independent parameter (begiining of >>> >>> s4.3 in the >>> >>>> TESLA draft) and that is *not* (if I understand SRTP correctly) >>>> something which you can do in the course of defining a new >>>> authentication transform. I think it breaks interoperability, but >>>> I will bow to more informed sources if this is not so. Also >>> >>> there is no >>> >>>> way to carry this flag in the MIKEY SRTP policy payload (s6.10.1 of >>>> RFC3830). >>>> >>>> If I am correct about the technical point above, the exact >>> >>> status quo >>> >>>> is not an option but I think you have two choices: >>>> - define the combination of the existing RFC3711 authentication and >>>> TESLA as a new authentication method - you can then do away with >>>> the Transform Independent parameter - applications can then >>>> negotiate on which authentication algorithm to use (basic or >>>> basic+TESLA) as intended. >>>> - define a new RTP profile as I suggested offering traffic stream >>>> encryption and authentication + source authentication., as compared >>>> with existing traffic stream encryption and authentication >>>> >>>> The choice between these is to some extent philosophical, I >>> >>> guess. My >>> >>>> personal feeling is that the addition of TESLA pushes the >>> >>> envelope of >>> >>>> what basic SRTP is supposed to do: adding TESLA to the >>> >>> authentication >>> >>>> algorithm is not simply switching from one mathematical function to >>>> another but adds logical capabilities - don't get me wrong, I >>>> understand this is a good thing - rather than (say) just using a >>>> longer key. To that extent it is something which an >>> >>> application would >>> >>>> maybe want to select as a profile (and there might turn out to be >>>> other ways of doing source authentication that could be subsumed in >>>> the same profile!). Its maybe a bit more work to do a new >>> >>> profile but >>> >>>> avoids overloading the existing profile. >>>> >>>> In either case some additional work has to be done in sdescriptions >>>> (but you knew that ;-) ) and MIKEY to support TESLA. >>>> >>>> Regards, >>>> Elwyn >>>> >>>> PS >>>> The other comments are independent of this choice and need to be >>>> looked at as well! >>>> >>>> E >>>> >>>> >>>> David A. McGrew wrote: >>>> >>>> >>>> >>>>> Mark, Elwyn, >>>>> >>>>> FWICT, a new RTP profile for TESLA isn't advantageous. It >>>> >>> occurs to >>> >>>>> me that, in addition to the reasons that Mark mentions, there are >>>>> cases in which it might be desirable to use TESLA authentication >>>>> in conjunction with SRTP encryption. This case is easier to >>>>> handle in SRTP than with a combination of multiple profiles. >>>>> Also, re-using the SRTP profile for TESLA allows the re-use of the >>>>> signaling mechanisms that have been developed for that profile. >>>>> The current methods of signaling SRTP crypto algorithms would >>>>> allow the user to negotiate TESLA, were that option available, so >>>>> I don't see the benefit of using a separate profile. (It may be >>>>> that I'm missing some point on how profiles, rather than profile >>>>> options, are negotiated. If this is the case, please let me know.) >>>>> >>>>> David >>>>> >>>>> On Jul 14, 2005, at 10:25 AM, Mark Baugher wrote: >>>>> >>>>> >>>>> >>>>>> Thank you for the comments, one of which is major while >>>>> >>> others might >>> >>>>>> merit only editorial consideration. So, let's take the >>>>> >>> big comment >>> >>>>>> first, the suggestion that SRTP-TESLA should be a new RTP profile >>>>>> (please see inline, below). >>>>>> >>>>>> On Jul 14, 2005, at 3:49 AM, Elwyn Davies wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Background for those on the CC list, who may be unaware of GenART: >>>>>>> GenART is the Area Review Team for the General Area of the >>>>>>> IETF. We advise the General Area Director (i.e. the IETF/IESG >>>>>>> chair) by providing more in depth reviews than he could do >>>>>>> himself of documents that come up for final decision in IESG >>>>>>> >>>>>> >>> telechat. I was >>> >>>>>>> selected as the GenART member to review this document. >>>>>> >>> Below is my >>> >>>>>>> review, which was written specifically with an eye to the GenART >>>>>>> process, but since I believe that it will be useful to have >>>>>>> these comments more widely distributed, others outside the >>>>>>> GenART group are being copied. >>>>>>> >>>>>>> Document: draft-ietf-msec-srtp-tesla-03.txt >>>>>>> Intended Status: Proposed Standard >>>>>>> Shepherding AD: Russ Housely >>>>>>> Review Trigger: IETF Last call ended 11 July 2005 >>>>>>> >>>>>>> Summary: >>>>>>> In my opinion this document is not ready to go to the >>>>>> >>> IESG. It has >>> >>>>>>> (in my view)significant issues. The major one is whether (for >>>>>>> technical reasons) it can be treated as an optional add-on to >>>>>>> the SRTP RTP profile, and even if it can, whether it would be >>>>>>> better treated as a separate profile, facilitating application >>>>>>> >>>>>> >>> negotiation >>> >>>>>>> of specific capabilities - i.e., stream >>>>>>> encryption/authentication (use SRTP), rigorous source >>>>>>> authentication (add TESLA). I am not an expert in this area so >>>>>>> it is quite possible that I am wrong about the technical point >>>>>>> but I think making it a >>>>>> >>> separate profile >>> >>>>>>> would have merit irrespective of the technical issue. >>>>>>> >>>>>> >>>>>> SRTP-TESLA is simply a new authentication transform for the SRTP >>>>>> framework and should be viewed as such. From Section 1 of >>>>> >>> RFC 3711: >>> >>> >>>>>> " >>>>>> SRTP provides a framework for encryption and message >>>>>> authentication >>>>>> of RTP and RTCP streams (Section 3). SRTP defines a set of >>>>>> default >>>>>> cryptographic transforms (Sections 4 and 5), and it allows new >>>>>> transforms to be introduced in the future (Section 6). With >>>>>> appropriate key management (Sections 7 and 8), SRTP is secure >>>>>> (Sections 9) for unicast and multicast RTP applications >>>>> >>> (Section >>> >>>>>> 11). >>>>>> " >>>>>> As a framework, SRTP aspires to accommodate new and updated >>>>>> transforms in order to stay competitive with advances in >>>>>> computing power and crypto-analysis. SRTP as a framework can >>>>>> also >>>>> >>> accommodate >>> >>>>>> special-purpose transforms for specific applications, such as >>>>>> large-scale multicast with one or more senders. That's what this >>>>>> I-D specifies. It is business as usual for the RTP/SAVP >>>>> >>> profile to >>> >>>>>> add a new authentication transform. We would not develop >>>>> >>> a new RTP >>> >>>>>> profile if we chose to add HMAC-MD5 to SRTP and we would not do >>>>>> it with TESLA, which is just an authentication transform, albeit >>>>>> a complicated one. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> In the process of reviewing this, I identified a >>>>>> >>> potential problem >>> >>>>>>> in RFC4082 - a telegraph pole problem with the length of the key >>>>>>> chain - which has some knock-on effects into this specification. >>>>>>> >>>>>> >>>>>> Whether we need to fix a potential problem in RFC 4082 or address >>>>>> the other detailed comments below should be resolved once we all >>>>>> agree that there need to no new RTP profile for SRTP-TESLA. >>>>>> >>>>>> I propose the status quo: No need for a new RTP profile. >>>>>> >>>>>> cheers, Mark >>>>>> >>>>>> >>>>>> >>>>>>> Detailed Review: >>>>>>> >>>>>>> Substantive points: >>>>>>> >>>>>>> Is this a separate RTP profile? >>>>>>> I have some difficulty understanding how the proposal can be an >>>>>>> optional extension of SRTP: This is proposed in s4.3 to be >>>>>>> implemented by adding a new flag to the Transform Independent >>>>>>> parameters of the SRTP cryptographic context. The intention >>>>>>> appears to be that the proposal reverts to RFC3711 SRTP >>>>>> >>> if this bit >>> >>>>>>> is not set. Inspection of s3.2.1 of RFC3711 does not reveal a >>>>>>> generic flag bit word in which this flag could be placed, so I >>>>>>> am at a loss to determine how the proposed enhanced profile can >>>>>>> be interoperable with existing implementations of SRTP that do >>>>>>> not understand TESLA. It seems to me (from my very naive >>>>>> >>> perspective on >>> >>>>>>> RTP and SDP etc) that SRTP/TESLA has to be a separate RTP >>>>>>> >>>>>> >>> profile. >>> >>>>>>> Defining this as a new profile would appear to conform to the >>>>>>> general usage of this sort of scheme - an application can >>>>>>> >>>>>> >>> negotiate >>> >>>>>>> for RTP/STP/TESLA if it feels the need, falling back to >>>>>> >>> RTP/SRTP or >>> >>>>>>> plain old RTP if the user will accept the reduced security. >>>>>>> From another point of view, it is a whole other capability on >>>>>>> >>>>>> >>> top of the >>> >>>>>>> stream security which SRTP provides and conflating it >>>>>> >>> with the SRTP >>> >>>>>>> profile doesn't seem to make sense. This of course would have >>>>>>> knock on effects on the IANA considerations. >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Length of the key chain: >>>>>>> 'A telegraph pole uncertainty?' >>>>>>> [Note on TESLA intro, RFC4082: S3.2 says that there is one-way >>>>>>> chain of length N made up of K_0, K_1, -> K_N... This appears to >>>>>>> have N+1 keys but, of course, N links. Is the list of >>>>>> >>> keys wrong or >>> >>>>>>> does the length give the number of links?] >>>>>>> This uncertainty links to item 10 of s4.3 - just how many >>>>>>> >>>>>> >>> keys are >>> >>>>>>> there in a key chain of length n_c? Is this number the number >>>>>>> of links or the number of keys? >>>>>>> >>>>>>> -------- >>>>>>> >>>>>>> SRTCP average packet size: >>>>>>> Probably in s4.5 or 4.6, there needs to be a note indicating >>>>>>> whether (I think they need to be ) or not the extra >>>>>> >>> fields need to >>> >>>>>>> be incorporated in the 'avg_rtcp_size' (s3.4 of RFC3711, >>>>>> >>> s6.3.3 of >>> >>>>>>> RFC3550). (There is text related to the packet size increase in >>>>>>> s6). >>>>>>> >>>>>>> ---------- >>>>>>> >>>>>>> Session Cleanup: >>>>>>> s5: Firstly, I think the sentence 'This repetition might >>>>>>> abruptly stop, however, if the key-bearing packets stop abruptly >>>>>>> >>>>>> >>> at the end >>> >>>>>>> of the stream.' is garbled. Maybe it should be 'The reliability >>>>>>> will be compromised if the flow of packets terminates >>>>>> >>> abruptly when >>> >>>>>>> there is no more data to send, so that the keys for the last few >>>>>>> previous packets are never sent.' >>>>>>> >>>>>>> In the next sentence the implementer is instructed to 'send null >>>>>>> packets with TESLA keys for one entire interval'.. how >>>>>> >>> many and how >>> >>>>>>> frequently? Presumably this will depend on the length of the >>>>>>> interval and some view of the reliability but I think guidance >>>>>>> is required. >>>>>>> >>>>>>> ------------ >>>>>>> >>>>>>> IANA Considerations: >>>>>>> s8 claims this document has no registration requirements. >>>>>>> >>>>>> >>> This does >>> >>>>>>> not appear to be true. >>>>>>> If, as I suggest above , this is really a separate RTP >>>>>> >>> profile, the >>> >>>>>>> document defines an RTP profile which needs to be named and >>>>>>> registered [RFC3711]. >>>>>>> Whether or not this needs to be done, the specification needs to >>>>>>> define one or more registries for the One Way Function >>>>>> >>> identifiers >>> >>>>>>> (CTANs in the terminology of draft-ietf-msec-tesla-spec-00.txt), >>>>>>> and maybe the overall cryptographic context. >>>>>>> >>>>>>> ============ >>>>>>> >>>>>>> Semi-substantive: >>>>>>> >>>>>>> Key and MAC lengths: >>>>>>> s4.1/s4.2/s4.5: The lengths of the Disclosed Key and TESLA MAC >>>>>>> fields are determined by the one way functions used to setup the >>>>>>> key chain and generate the MAC. This is discussed in >>>>>> >>> 4.3: It would >>> >>>>>>> save head scratching to mention this earlier since the packet >>>>>>> format doesn't have explicit lengths. >>>>>>> >>>>>>> s4.2: Just for clarification, the Disclosed Key and TESLA MAC >>>>>>> fields are specified as variable length. The figures >>>>>> >>> show them as >>> >>>>>>> ending on 32 bit boundaries. Is this merely for convenience in >>>>>>> drawing or is there any constraint on the length of the fields. >>>>>>> Presumably it would be at least good for them to be >>>>>> >>> multiples of 8 >>> >>>>>>> bits. >>>>>>> >>>>>>> s6.2: This section specifies various options for the OWF and the >>>>>>> key and MAC lengths generated. It doesn't say they are in bits, >>>>>>> and it would be worth linking the lengths to the 'Disclosed Key' >>>>>>> and 'TESLA MAC' fields in s4.1/4.2. Also, mentioning >>>>>> >>> that RFC2104 >>> >>>>>>> defines HMAC-SHA1 would be helpful. >>>>>>> >>>>>>> ---------- >>>>>>> Dealing with Disclosed Keys in Sender and Receiver: >>>>>>> s4.4.1: Item 6: A few words indicating that the disclosed key >>>>>>> possibly needs to be updated from what was sent previously (and >>>>>>> what drives this) would be useful. >>>>>>> >>>>>>> >>>>>>> s4.4.2: para 6: Since this part is couched as a set of >>>>>>> processing to be performed on a current packet, the start of the >>>>>>> second sentence might be better as: 'Check if the current packet >>>>>>> >>>>>> >>> contains >>> >>>>>>> a new disclosed key from the current time, the time >>>>>> >>> interval of the >>> >>>>>>> last disclosed key and the key disclosure interval: if the >>>>>>> disclosed key is a new one, determine the index of the >>>>>> >>> key. If any >>> >>>>>>> keys in the chain have not been received as a result of lost >>>>>>> packets, calculate the intervening keys (give a ref to >>>>>> >>> how). Using >>> >>>>>>> these newly obtained keys, perform TESLA verification on any >>>>>>> buffered packets to which they apply using the rollover >>>>>> >>> counter...' >>> >>> >>>>>>> ---------- >>>>>>> Optionality of TESLA: >>>>>>> TESLA is specified as an optional profile.. I found the words in >>>>>>> the 'Note' sentence of the captions of Figures 2 and 3 >>>>>> >>> confusing... >>> >>>>>>> It could be read as TESLA fields being optional on a per packet >>>>>>> basis. Everything about the 'optionality of TESLA' is >>>>>> >>> said in the >>> >>>>>>> paragraph before each figure in a much clearer way. Suggest >>>>>>> omitting these sentences. >>>>>>> >>>>>>> ------------ >>>>>>> HMAC-SHA1 is default, not only possibility for MAC algorithm? >>>>>>> s4.6: last para: This appears to imply that HMAC-SHA1 is >>>>>> >>> the *only* >>> >>>>>>> possible algorithm for calculating the TESLA MAC. This seems to >>>>>>> contradict s4.3, Item 5 where the MAC algorithm is specified as >>>>>>> a parameter. This needs to be clarified/corrected. >>>>>>> >>>>>>> Editorial Nits: >>>>>>> global: s/bytes/octets/ (3 instances) >>>>>>> global: consistency of usage of f/f' vs F/F' for the OWFs >>>>>>> Abstract: s/loss/Loss/ >>>>>>> s1, para 3: s/discern/distinguish/ >>>>>>> s1, last para: s/loss/Loss/ >>>>>>> s1.1, para 2: s/familiar/is familiar/ >>>>>>> s3, para 3: S/needed/necessary/ >>>>>>> s4.1, para 1: s/The fields added by TESLA are called "TESLA >>>>>>> authentication extensions" altogether/The fields added by TESLA, >>>>>>> considered as a group, are called "TESLA authentication >>>>>> >>> extensions/ >>> >>> >>>>>>> s4.4.1, s4.4.2: s/included/inclusive/ >>>>>>> s4.4.1: Item 9: It would not hurt to expand ROC (rollover >>>>>>> >>>>>> >>> counter). >>> >>> >>>>>>> s4.4.2: s/is the following/is as follows/ >>>>>>> s4.6: para 5 (1st bullet): s/as for/as described in/ >>>>>>> s4.6: para 6 (2nd bullet): s/as for Section 4.2/as described in >>>>>>> Section 4.5/ >>>>>>> s6.2/s11: RFC2104 is referenced in s6.2 (and elsewhere) but the >>>>>>> reference is missing. It might be useful to put this ref against >>>>>>> the first usage of HMAC-SHA1 in this section (although it >>>>>>> >>>>>> >>> has been >>> >>>>>>> refeerenced before). >>>>>>> s6.2: A reference back to the definitions of the crypto context >>>>>>> variables in s4.3 would help. >>>>>>> s6.2: OUTPUT LENGTH of TESLA KEYCHAIN OWF is n_p >>>>>>> s11: References to RFC2119 and RFC2104 are missing. >>>>>>> >>>>>>> >>>>>>> Background for those on the CC list, who may be unaware of >>>>>>> GenART: >>>>>>> GenART is the Area Review Team for the General Area of the >>>>>>> IETF. We advise the General Area Director (i.e. the >>>>>>> IETF/IESG chair) by providing more in depth reviews than he >>>>>>> could do himself of documents that come up for final >>>>>>> decision in IESG telechat. I was selected as the GenART >>>>>>> member to review this document. Below is my review, which >>>>>>> was written specifically with an eye to the GenART process, >>>>>>> but since I believe that it will be useful to have these >>>>>>> comments more widely distributed, others outside the GenART >>>>>>> group are being copied. >>>>>>> >>>>>>> Document: draft-ietf-msec-srtp-tesla-03.txt >>>>>>> Intended Status: Proposed Standard >>>>>>> Shepherding AD: Russ Housely >>>>>>> Review Trigger: IETF Last call ended 11 July 2005 >>>>>>> >>>>>>> Summary: >>>>>>> In my opinion this document is not ready to go to the >>>>>>> IESG. It has (in my view)significant issues. The major >>>>>>> one is whether (for technical reasons) it can be treated as >>>>>>> an optional add-on to the SRTP RTP profile, and even if it >>>>>>> can, whether it would be better treated as a separate >>>>>>> profile, facilitating application negotiation of specific >>>>>>> capabilities - i.e., stream encryption/authentication (use >>>>>>> SRTP), rigorous source authentication (add TESLA). I am >>>>>>> not an expert in this area so it is quite possible that I >>>>>>> am wrong about the technical point but I think making it a >>>>>>> separate profile would have merit irrespective of the >>>>>>> technical issue. >>>>>>> >>>>>>> In the process of reviewing this, I identified a potential >>>>>>> problem in RFC4082 - a telegraph pole problem with the >>>>>>> length of the key chain - which has some knock-on effects >>>>>>> into this specification. >>>>>>> >>>>>>> Detailed Review: >>>>>>> >>>>>>> Substantive points: >>>>>>> >>>>>>> Is this a separate RTP profile? >>>>>>> I have some difficulty understanding how the proposal can >>>>>>> be an optional extension of SRTP: This is proposed in s4.3 >>>>>>> to be implemented by adding a new flag to the Transform >>>>>>> Independent parameters of the SRTP cryptographic context. >>>>>>> The intention appears to be that the proposal reverts to >>>>>>> RFC3711 SRTP if this bit is not set. Inspection of s3.2.1 >>>>>>> of RFC3711 does not reveal a generic flag bit word in which >>>>>>> this flag could be placed, so I am at a loss to determine >>>>>>> how the proposed enhanced profile can be interoperable with >>>>>>> existing implementations of SRTP that do not understand >>>>>>> TESLA. It seems to me (from my very naive perspective on >>>>>>> RTP and SDP etc) that SRTP/TESLA has to be a separate RTP >>>>>>> profile. Defining this as a new profile would appear to >>>>>>> conform to the general usage of this sort of scheme - an >>>>>>> application can negotiate for RTP/STP/TESLA if it feels the >>>>>>> need, falling back to RTP/SRTP or plain old RTP if the user >>>>>>> will accept the reduced security. From another point of >>>>>>> view, it is a whole other capability on top of the stream >>>>>>> security which SRTP provides and conflating it with the >>>>>>> SRTP profile doesn't seem to make sense. This of course >>>>>>> would have knock on effects on the IANA considerations. >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> Length of the key chain: >>>>>>> 'A telegraph pole uncertainty?' >>>>>>> [Note on TESLA intro, RFC4082: S3.2 says that there is one- >>>>>>> way chain of length N made up of K_0, K_1, -> K_N... This >>>>>>> appears to have N+1 keys but, of course, N links. Is the >>>>>>> list of keys wrong or does the length give the number of >>>>>>> links?] >>>>>>> This uncertainty links to item 10 of s4.3 - just how many >>>>>>> keys are there in a key chain of length n_c? Is this >>>>>>> number the number of links or the number of keys? >>>>>>> >>>>>>> -------- >>>>>>> >>>>>>> SRTCP average packet size: >>>>>>> Probably in s4.5 or 4.6, there needs to be a note >>>>>>> indicating whether (I think they need to be ) or not the >>>>>>> extra fields need to be incorporated in the 'avg_rtcp_size' >>>>>>> (s3.4 of RFC3711, s6.3.3 of RFC3550). (There is text >>>>>>> related to the packet size increase in s6). >>>>>>> >>>>>>> ---------- >>>>>>> >>>>>>> Session Cleanup: >>>>>>> s5: Firstly, I think the sentence 'This repetition might >>>>>>> abruptly stop, however, if the key-bearing packets stop >>>>>>> abruptly at the end of the stream.' is garbled. Maybe it >>>>>>> should be 'The reliability will be compromised if the flow >>>>>>> of packets terminates abruptly when there is no more data >>>>>>> to send, so that the keys for the last few previous packets >>>>>>> are never sent.' >>>>>>> >>>>>>> In the next sentence the implementer is instructed to 'send >>>>>>> null packets with TESLA keys for one entire interval'.. how >>>>>>> many and how frequently? Presumably this will depend on >>>>>>> the length of the interval and some view of the reliability >>>>>>> but I think guidance is required. >>>>>>> >>>>>>> ------------ >>>>>>> >>>>>>> IANA Considerations: >>>>>>> s8 claims this document has no registration requirements. >>>>>>> This does not appear to be true. >>>>>>> If, as I suggest above , this is really a separate RTP >>>>>>> profile, the document defines an RTP profile which needs to >>>>>>> be named and registered [RFC3711]. >>>>>>> Whether or not this needs to be done, the specification >>>>>>> needs to define one or more registries for the One Way >>>>>>> Function identifiers (CTANs in the terminology of draft- >>>>>>> ietf-msec-tesla-spec-00.txt), and maybe the overall >>>>>>> cryptographic context. >>>>>>> >>>>>>> ============ >>>>>>> >>>>>>> Semi-substantive: >>>>>>> >>>>>>> Key and MAC lengths: >>>>>>> s4.1/s4.2/s4.5: The lengths of the Disclosed Key and TESLA >>>>>>> MAC fields are determined by the one way functions used to >>>>>>> setup the key chain and generate the MAC. This is >>>>>>> discussed in 4.3: It would save head scratching to mention >>>>>>> this earlier since the packet format doesn't have explicit >>>>>>> lengths. >>>>>>> >>>>>>> s4.2: Just for clarification, the Disclosed Key and TESLA >>>>>>> MAC fields are specified as variable length. The figures >>>>>>> show them as ending on 32 bit boundaries. Is this merely >>>>>>> for convenience in drawing or is there any constraint on >>>>>>> the length of the fields. Presumably it would be at least >>>>>>> good for them to be multiples of 8 bits. >>>>>>> >>>>>>> s6.2: This section specifies various options for the OWF >>>>>>> and the key and MAC lengths generated. It doesn't say they >>>>>>> are in bits, and it would be worth linking the lengths to >>>>>>> the 'Disclosed Key' and 'TESLA MAC' fields in s4.1/4.2. >>>>>>> Also, mentioning that RFC2104 defines HMAC-SHA1 would be >>>>>>> helpful. >>>>>>> >>>>>>> ---------- >>>>>>> Dealing with Disclosed Keys in Sender and Receiver: >>>>>>> s4.4.1: Item 6: A few words indicating that the disclosed >>>>>>> key possibly needs to be updated from what was sent >>>>>>> previously (and what drives this) would be useful. >>>>>>> >>>>>>> >>>>>>> s4.4.2: para 6: Since this part is couched as a set of >>>>>>> processing to be performed on a current packet, the start >>>>>>> of the second sentence might be better as: 'Check if the >>>>>>> current packet contains a new disclosed key from the >>>>>>> current time, the time interval of the last disclosed key >>>>>>> and the key disclosure interval: if the disclosed key is a >>>>>>> new one, determine the index of the key. If any keys in >>>>>>> the chain have not been received as a result of lost >>>>>>> packets, calculate the intervening keys (give a ref to >>>>>>> how). Using these newly obtained keys, perform TESLA >>>>>>> verification on any buffered packets to which they apply >>>>>>> using the rollover counter...' >>>>>>> >>>>>>> ---------- >>>>>>> Optionality of TESLA: >>>>>>> TESLA is specified as an optional profile.. I found the >>>>>>> words in the 'Note' sentence of the captions of Figures 2 >>>>>>> and 3 confusing... It could be read as TESLA fields being >>>>>>> optional on a per packet basis. Everything about the >>>>>>> 'optionality of TESLA' is said in the paragraph before each >>>>>>> figure in a much clearer way. Suggest omitting these >>>>>>> sentences. >>>>>>> >>>>>>> ------------ >>>>>>> HMAC-SHA1 is default, not only possibility for MAC >>>>>>> algorithm? >>>>>>> s4.6: last para: This appears to imply that HMAC-SHA1 is >>>>>>> the *only* possible algorithm for calculating the TESLA >>>>>>> MAC. This seems to contradict s4.3, Item 5 where the MAC >>>>>>> algorithm is specified as a parameter. This needs to be >>>>>>> clarified/corrected. >>>>>>> >>>>>>> Editorial Nits: >>>>>>> global: s/bytes/octets/ (3 instances) >>>>>>> global: consistency of usage of f/f' vs F/F' for the OWFs >>>>>>> Abstract: s/loss/Loss/ >>>>>>> s1, para 3: s/discern/distinguish/ >>>>>>> s1, last para: s/loss/Loss/ >>>>>>> s1.1, para 2: s/familiar/is familiar/ >>>>>>> s3, para 3: S/needed/necessary/ >>>>>>> s4.1, para 1: s/The fields added by TESLA are called "TESLA >>>>>>> authentication extensions" altogether/The fields added by >>>>>>> TESLA, considered as a group, are called "TESLA >>>>>>> authentication extensions/ >>>>>>> s4.4.1, s4.4.2: s/included/inclusive/ >>>>>>> s4.4.1: Item 9: It would not hurt to expand ROC (rollover >>>>>>> counter). >>>>>>> s4.4.2: s/is the following/is as follows/ >>>>>>> s4.6: para 5 (1st bullet): s/as for/as described in/ >>>>>>> s4.6: para 6 (2nd bullet): s/as for Section 4.2/as >>>>>>> described in Section 4.5/ >>>>>>> s6.2/s11: RFC2104 is referenced in s6.2 (and elsewhere) but >>>>>>> the reference is missing. It might be useful to put this >>>>>>> ref against the first usage of HMAC-SHA1 in this section >>>>>>> (although it has been refeerenced before). >>>>>>> s6.2: A reference back to the definitions of the crypto >>>>>>> context variables in s4.3 would help. >>>>>>> s6.2: OUTPUT LENGTH of TESLA KEYCHAIN OWF is n_p >>>>>>> s11: References to RFC2119 and RFC2104 are missing. >>>>>>> >>>>>>> >>>>>> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jul 19 10:04:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dushj-0002qG-1A for msec-archive@megatron.ietf.org; Tue, 19 Jul 2005 10:04:15 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15403 for ; Tue, 19 Jul 2005 10:04:12 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7D9FA8C5CB; Tue, 19 Jul 2005 10:04:12 -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 E4B648C5B5 for ; Tue, 19 Jul 2005 10:04:10 -0400 (EDT) Received: (qmail 23732 invoked by uid 3269); 19 Jul 2005 14:04:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23729 invoked from network); 19 Jul 2005 14:04:10 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 19 Jul 2005 14:04:10 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2005 07:04:10 -0700 X-IronPort-AV: i="3.93,299,1115017200"; d="scan'208"; a="649299576:sNHT30341418" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6JE3fVv006325; Tue, 19 Jul 2005 07:04:07 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 07:04:06 -0700 Received: from [192.168.0.12] ([10.21.144.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 07:03:59 -0700 In-Reply-To: References: <0CDAE977A7172A40A2A3A1C20C12BD65010A1DE7@esealmw106.eemea.ericsson.se> <91aced67e2067c1fa9261c8e9984dead@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Tue, 19 Jul 2005 07:03:57 -0700 To: Colin Perkins X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 19 Jul 2005 14:03:59.0567 (UTC) FILETIME=[B5DF75F0:01C58C6A] Cc: Russ Housley , canetti , "'Dave Oran'" , msec@securemulticast.org, "Elisabetta Carrara (AL/EAB)" , "David A. McGrew" , =?ISO-8859-1?Q?Mats_N=E4slund?= Subject: [MSEC] Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard] 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 Colin Yes, I think we need to discuss the nature of the SRTP framework and the fact that the SRTP packet can change without requiring a new profile. Mark On Jul 19, 2005, at 5:46 AM, Colin Perkins wrote: > Mark, > > On 18 Jul 2005, at 20:02, Mark Baugher wrote: >> Elisabetta, Colin >> Thanks to Elisabetta for explaining why we did not make the two >> authentication tags contiguous. We wanted one tag to cover the other >> (viz. from P.6 of >> http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla >> -03.txt), > ... >> SRTP HMAC-SHA1 includes up to the MKI field but does not include MKI. >> We want SRTP-TESLA tag to be covered by the SRTP HMAC-SHA-1 >> integrity check. SRTP authors decided in our infinite wisdom not to >> cover the MKI field (because it did not need to be covered for SRTP >> packet integrity). In order to make the two tags (SRTP-TESLA and >> SRTP-HMAC_SHA1) contiguous, we would need to redefine the SRTP >> specification to include the MKI in HMAC-SHA1 coverage. We don't >> want to do that. >> >> Unfortunately, this looks like a new packet format to people who know >> RTP. Hence it follows to some that it requires a new profile as did >> SRTP. But SRTP does not need to have profiles because it is a >> framework that accommodates upgrade (e.g. 256-bit AES, SRTP-TESLA) >> and replacement (e.g. f8 with AES) of authentication and encryption >> transforms, any of which may change the packet format (e.g. a 32-bit >> tag instead of an 80 bit tag). We made SRTP-TESLA practically >> transparent to SRTP-HMAC-SHA1 processing, and included the TESLA tag >> in the HMAC integrity check (i.e. it is contiguous with the payload >> portion of the packet and easily covered by the integrity-check >> value). The point of doing the HMAC integrity check is to add an >> additional layer of authentication that prevents non group-members >> from submitting packets to SRTP-TESLA processing as a >> denial-of-service prevention mechanism. >> >> I recommend that we don't make the two authentication tags to be >> contiguous in the packet. Instead, we think of everything beyond the >> end of the application payload as being SRTP and key management stuff >> that are interpreted under a given transform or cipher suite. > > Okay - I'm happy with this. Would it be possible to explain more of > this rationale in the draft? > > Colin > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jul 21 12:47:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DveD3-0001Ee-91 for msec-archive@megatron.ietf.org; Thu, 21 Jul 2005 12:47:47 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17369 for ; Thu, 21 Jul 2005 12:47:42 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 217DC8C535; Thu, 21 Jul 2005 12:47:44 -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 4A5778C495 for ; Thu, 21 Jul 2005 12:47:43 -0400 (EDT) Received: (qmail 17757 invoked by uid 3269); 21 Jul 2005 16:47:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17752 invoked from network); 21 Jul 2005 16:47:42 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 21 Jul 2005 16:47:42 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2005 09:47:42 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6LGlcJL029726; Thu, 21 Jul 2005 09:47:38 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 09:47:38 -0700 Received: from [192.168.0.12] ([10.21.98.54]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 09:47:25 -0700 In-Reply-To: <42D6434D.3060507@dial.pipex.com> References: <42D6434D.3060507@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0430ab252e997a82f2f6b6a74545c9ea@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Thu, 21 Jul 2005 09:47:35 -0700 To: Elwyn Davies X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 21 Jul 2005 16:47:26.0008 (UTC) FILETIME=[DFCB1B80:01C58E13] Cc: canetti , "'Dave Oran'" , Joerg Ott , Russ Housley , msec@securemulticast.org, "'Elisabetta Carrara (AL/EAB)'" , "David A. McGrew" , Mary Barnes , =?ISO-8859-1?Q?Mats_N=E4slund?= , gen-art@alvestrand.no, Colin Perkins Subject: [MSEC] Re: Gen-Art Review: draft-ietf-msec-srtp-tesla-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 Content-Transfer-Encoding: 7bit Elwyn, On Jul 14, 2005, at 3:49 AM, Elwyn Davies wrote: > ... > Summary: > In my opinion this document is not ready to go to the IESG. It has > (in my view)significant issues. The major one is whether (for > technical reasons) it can be treated as an optional add-on to the SRTP > RTP profile, and even if it can, whether it would be better treated as > a separate profile, facilitating application negotiation of specific > capabilities - i.e., stream encryption/authentication (use SRTP), > rigorous source authentication (add TESLA). I am not an expert in > this area so it is quite possible that I am wrong about the technical > point but I think making it a separate profile would have merit > irrespective of the technical issue. I think we all agree that if we remove the transport-independent parameter from the crypto context data structure, then SRTP-TESLA is properly viewed as a new authentication transform for SRTP. SRTP-TESLA is signaled in the key management, offer/answer, announcement protocol, etc. There is an I-D that describes signaling bindings in an IANA registration for MIKEY. We will need SRTP-TESLA bindinds for SDP Security Descriptions once the group/multicast version of the security descriptions offer/answer exchange is complete. In addition to removing the transport-dependent parameter as Elisabetta proposed, I promised Colin Perkins that we'll explain why SRTP does not have profiles but instead interprets the layout of the SRTP packet according to its transforms, which are replaceable and upgradeable. (There is an I-D from RMT that does add TESLA using a new profile, such is not the case with SRTP where we treat TESLA as a new authentication transform.) > > In the process of reviewing this, I identified a potential problem in > RFC4082 - a telegraph pole problem with the length of the key chain - > which has some knock-on effects into this specification. You actually identified quite a bit and I'll comment further on the substantive points of your detailed review. Regarding the "telegraph pole" problem, the error in RFC4082 (section 3.2) is inconsequential AFAICT. > > Detailed Review: > > Substantive points: > > Is this a separate RTP profile? > I have some difficulty understanding how the proposal can be an > optional extension of SRTP: This is proposed in s4.3 to be > implemented by adding a new flag to the Transform Independent > parameters of the SRTP cryptographic context. The intention appears > to be that the proposal reverts to RFC3711 SRTP if this bit is not > set. Inspection of s3.2.1 of RFC3711 does not reveal a generic flag > bit word in which this flag could be placed, so I am at a loss to > determine how the proposed enhanced profile can be interoperable with > existing implementations of SRTP that do not understand TESLA. It > seems to me (from my very naive perspective on RTP and SDP etc) that > SRTP/TESLA has to be a separate RTP profile. Defining this as a new > profile would appear to conform to the general usage of this sort of > scheme - an application can negotiate for RTP/STP/TESLA if it feels > the need, falling back to RTP/SRTP or plain old RTP if the user will > accept the reduced security. From another point of view, it is a > whole other capability on top of the stream security which SRTP > provides and conflating it with the SRTP profile doesn't seem to make > sense. This of course would have knock on effects on the IANA > considerations. Yes, we need to remove the flag but IANA considerations should be clarified and state that the key management protocol that establishes TESLA keys will register SRTP-TESLA bindings. This is being done for MIKEY in http://www.ietf.org/internet-drafts/draft-ietf-msec-bootstrapping- tesla-01.txt but SDP Security Descriptions does not yet support multicast SRTP and there are no bindings for SRTP-TESLA. > > --------- > > Length of the key chain: > 'A telegraph pole uncertainty?' > [Note on TESLA intro, RFC4082: S3.2 says that there is one-way chain > of length N made up of K_0, K_1, -> K_N... This appears to have N+1 > keys but, of course, N links. Is the list of keys wrong or does the > length give the number of links?] The number is typically so large that this error does not matter. > This uncertainty links to item 10 of s4.3 - just how many keys are > there in a key chain of length n_c? Is this number the number of > links or the number of keys? I think you mean item 11. I don't think it matters if the key chain only supports 999,999 packets instead of a million. > > -------- > > SRTCP average packet size: > Probably in s4.5 or 4.6, there needs to be a note indicating whether > (I think they need to be ) or not the extra fields need to be > incorporated in the 'avg_rtcp_size' (s3.4 of RFC3711, s6.3.3 of > RFC3550). (There is text related to the packet size increase in s6). Thanks. > > ---------- > > Session Cleanup: > s5: Firstly, I think the sentence 'This repetition might abruptly > stop, however, if the key-bearing packets stop abruptly at the end of > the stream.' is garbled. Maybe it should be 'The reliability will be > compromised if the flow of packets terminates abruptly when there is > no more data to send, so that the keys for the last few previous > packets are never sent.' Thanks. How about "Since the key for time interval i is disclosed in i+1, it follows that a stream with n time intervals must continue through n+1 to disclose all keys." > > In the next sentence the implementer is instructed to 'send null > packets with TESLA keys for one entire interval'.. how many and how > frequently? Presumably this will depend on the length of the interval > and some view of the reliability but I think guidance is required. I think this is well defined as the packet field "i" that is shown in Fig. 1. > > ------------ > > IANA Considerations: > s8 claims this document has no registration requirements. This does > not appear to be true. > If, as I suggest above , this is really a separate RTP profile, the > document defines an RTP profile which needs to be named and registered > [RFC3711]. > Whether or not this needs to be done, the specification needs to > define one or more registries for the One Way Function identifiers > (CTANs in the terminology of draft-ietf-msec-tesla-spec-00.txt), and > maybe the overall cryptographic context. We should mention that key management uses and registers the names, all we are naming in this I-D are packet fields. We could reference http://www.ietf.org/internet-drafts/draft-ietf-msec-bootstrapping- tesla-01.txt to illustrate. > > ============ > > Semi-substantive: > > Key and MAC lengths: > s4.1/s4.2/s4.5: The lengths of the Disclosed Key and TESLA MAC fields > are determined by the one way functions used to setup the key chain > and generate the MAC. This is discussed in 4.3: It would save head > scratching to mention this earlier since the packet format doesn't > have explicit lengths. Okay. > > s4.2: Just for clarification, the Disclosed Key and TESLA MAC fields > are specified as variable length. The figures show them as ending on > 32 bit boundaries. Is this merely for convenience in drawing or is > there any constraint on the length of the fields. Presumably it would > be at least good for them to be multiples of 8 bits. Everything is a multiple of 8 bits but not 32. We should say that. > > s6.2: This section specifies various options for the OWF and the key > and MAC lengths generated. It doesn't say they are in bits, and it > would be worth linking the lengths to the 'Disclosed Key' and 'TESLA > MAC' fields in s4.1/4.2. Also, mentioning that RFC2104 defines > HMAC-SHA1 would be helpful. Okay. > > ---------- > Dealing with Disclosed Keys in Sender and Receiver: > s4.4.1: Item 6: A few words indicating that the disclosed key possibly > needs to be updated from what was sent previously (and what drives > this) would be useful. > I don't understand what you mean by "the disclosed key possibly needs to be updated." > > s4.4.2: para 6: Since this part is couched as a set of processing to > be performed on a current packet, the start of the second sentence > might be better as: 'Check if the current packet contains a new > disclosed key from the current time, the time interval of the last > disclosed key and the key disclosure interval: if the disclosed key > is a new one, determine the index of the key. If any keys in the > chain have not been received as a result of lost packets, calculate > the intervening keys (give a ref to how). This is in section 3.5 of RFC 4082, and the reader must be familiar with this section to understand 4.4.2 of srtp-tesla, which references sections 3.5-3.7 of RFC 4082. We chose to reference rather than reproduce in detail the processing of RFC 4082. > Using these newly obtained keys, perform TESLA verification on any > buffered packets to which they apply using the rollover counter...' I'm not sure what we are fixing here. > > ---------- > Optionality of TESLA: > TESLA is specified as an optional profile.. I found the words in the > 'Note' sentence of the captions of Figures 2 and 3 confusing... It > could be read as TESLA fields being optional on a per packet basis. > Everything about the 'optionality of TESLA' is said in the paragraph > before each figure in a much clearer way. Suggest omitting these > sentences. Ok, but we don't refer to TESLA as an optional profile. I think it's best understood as an authentication transform that may be chosen for certain applications. > > ------------ > HMAC-SHA1 is default, not only possibility for MAC algorithm? None other are currently defined in RFC 3711. > s4.6: last para: This appears to imply that HMAC-SHA1 is the *only* > possible algorithm for calculating the TESLA MAC. This seems to > contradict s4.3, Item 5 where the MAC algorithm is specified as a > parameter. This needs to be clarified/corrected. We should clarify this because if HMAC-MD5 or some other MAC is defined for SRTP, it probably can be used for SRTP-TESLA as well. > > Editorial Nits: > global: s/bytes/octets/ (3 instances) > global: consistency of usage of f/f' vs F/F' for the OWFs > Abstract: s/loss/Loss/ > s1, para 3: s/discern/distinguish/ > s1, last para: s/loss/Loss/ > s1.1, para 2: s/familiar/is familiar/ > s3, para 3: S/needed/necessary/ > s4.1, para 1: s/The fields added by TESLA are called "TESLA > authentication extensions" altogether/The fields added by TESLA, > considered as a group, are called "TESLA authentication extensions/ > s4.4.1, s4.4.2: s/included/inclusive/ > s4.4.1: Item 9: It would not hurt to expand ROC (rollover counter). > s4.4.2: s/is the following/is as follows/ > s4.6: para 5 (1st bullet): s/as for/as described in/ > s4.6: para 6 (2nd bullet): s/as for Section 4.2/as described in > Section 4.5/ > s6.2/s11: RFC2104 is referenced in s6.2 (and elsewhere) but the > reference is missing. It might be useful to put this ref against the > first usage of HMAC-SHA1 in this section (although it has been > refeerenced before). > s6.2: A reference back to the definitions of the crypto context > variables in s4.3 would help. > s6.2: OUTPUT LENGTH of TESLA KEYCHAIN OWF is n_p > s11: References to RFC2119 and RFC2104 are missing. > Thanks for your comments Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Jul 24 17:03:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwnd6-0007Pk-MR for msec-archive@megatron.ietf.org; Sun, 24 Jul 2005 17:03:24 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25036 for ; Sun, 24 Jul 2005 17:03:21 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4A5178C396; Sun, 24 Jul 2005 17:03:23 -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 C6B2D8C362 for ; Sun, 24 Jul 2005 17:03:21 -0400 (EDT) Received: (qmail 60865 invoked by uid 3269); 24 Jul 2005 21:03:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60862 invoked from network); 24 Jul 2005 21:03:21 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Jul 2005 21:03:21 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 8A9E06836F for ; Sun, 24 Jul 2005 17:03:21 -0400 (EDT) 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 j6OL3Hsa017194; Sun, 24 Jul 2005 14:03:18 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6OL3F4x027374; Sun, 24 Jul 2005 14:03:15 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 14:03:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Jul 2005 14:03:13 -0700 Message-ID: Thread-Index: AcWQkxrEwE1izdlpRz6+CqiDfcPgHA== From: "Dondeti, Lakshminath" To: X-OriginalArrivalTime: 24 Jul 2005 21:03:14.0961 (UTC) FILETIME=[1BB8B810:01C59093] Cc: canetti@watson.ibm.com Subject: [MSEC] (no subject) 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="===============1410832045==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1410832045== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59093.1AD7D368" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59093.1AD7D368 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Here is a draft MSEC@IETF-63 Agenda. If I missed any items or if anyone = needs more time, please let Ran/me know. We may be able to entertain = 1-2 last minute items. * MSEC status report (Ran/Lakshminath) 10 mins Revised milestones Notes on cross-area work and reviews * draft-ietf-msec-bootstrapping-tesla (Steffen) 5 mins * The following two drafts are in IETF last call; Perhaps the authors = can brief the WG on the status? If not Ran/Lakshminath will summarize. draft-ietf-msec-newtype-keyid (Elisabetta?) 5 mins draft-ietf-msec-srtp-tesla (Mark/Elisabetta?) 5 mins * draft-ietf-msec-ipsec-extensions (Dragan/George) 10 mins * draft-ietf-msec-mikey-ecc (Andy) 10 mins =09 * draft-ietf-msec-mikey-rsa-r (Dragan) 10 mins * draft-dondeti-msec-inband-key-updates (Lakshminath) 10 mins * draft-faurite-rmt-tesla-for-alc-norm "RMT proposal for 10 mins MSEC review" 75 mins thanks and regards, Lakshminath ------_=_NextPart_001_01C59093.1AD7D368 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

Here is a draft MSEC@IETF-63 Agenda.  If I missed any items or if = anyone needs more time, please let Ran/me know.  We may be able to = entertain 1-2 last minute items.

* MSEC status = report           &= nbsp;       = (Ran/Lakshminath)    10 mins
  Revised milestones
  Notes on cross-area work and reviews

* draft-ietf-msec-bootstrapping-tesla   = (Steffen)          &nbs= p; 5 mins

* The following two drafts are in IETF last call;  Perhaps the = authors can brief the WG on the status? If not Ran/Lakshminath will = summarize.

    = draft-ietf-msec-newtype-keyid       = (Elisabetta?)        5 mins
    = draft-ietf-msec-srtp-tesla        = ;  (Mark/Elisabetta?)   5 mins

* draft-ietf-msec-ipsec-extensions      = (Dragan/George)     10 mins

* = draft-ietf-msec-mikey-ecc        =      = (Andy)           &= nbsp;  10 mins
       
* = draft-ietf-msec-mikey-rsa-r       &nbs= p;   = (Dragan)           = ; 10 mins

* draft-dondeti-msec-inband-key-updates = (Lakshminath)       10 mins

* draft-faurite-rmt-tesla-for-alc-norm  "RMT proposal = for   10 mins
            &= nbsp;           &n= bsp;           &nb= sp;    MSEC review"

            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           75 = mins

thanks and regards,
Lakshminath

------_=_NextPart_001_01C59093.1AD7D368-- --===============1410832045== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1410832045==-- From msec-bounces@securemulticast.org Sun Jul 24 17:05:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwnel-0007ky-U6 for msec-archive@megatron.ietf.org; Sun, 24 Jul 2005 17:05:08 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25179 for ; Sun, 24 Jul 2005 17:05:05 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 274138C361; Sun, 24 Jul 2005 17:05:07 -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 8E2898C301 for ; Sun, 24 Jul 2005 17:05:05 -0400 (EDT) Received: (qmail 61183 invoked by uid 3269); 24 Jul 2005 21:05:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61179 invoked from network); 24 Jul 2005 21:05:05 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Jul 2005 21:05:05 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 396636836F for ; Sun, 24 Jul 2005 17:05:05 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6OL51sa017770; Sun, 24 Jul 2005 14:05:01 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6OL4xN2019969; Sun, 24 Jul 2005 14:04:59 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 14:04:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Jul 2005 14:04:32 -0700 Message-ID: Thread-Topic: MSEC agenda Thread-Index: AcWQkxrEwE1izdlpRz6+CqiDfcPgHAAAC9MC From: "Dondeti, Lakshminath" To: "Dondeti, Lakshminath" , X-OriginalArrivalTime: 24 Jul 2005 21:04:58.0873 (UTC) FILETIME=[59A86E90:01C59093] Cc: canetti@watson.ibm.com Subject: [MSEC] MSEC agenda 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="===============2085457452==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============2085457452== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59093.590ED640" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59093.590ED640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable With a subject line, sorry for the duplicate. thanks, Lakshminath -----Original Message----- From: Dondeti, Lakshminath Sent: Sun 7/24/2005 2:03 PM To: msec@securemulticast.org Cc: canetti@watson.ibm.com Subject:=20 =20 Hi all, Here is a draft MSEC@IETF-63 Agenda. If I missed any items or if anyone = needs more time, please let Ran/me know. We may be able to entertain = 1-2 last minute items. * MSEC status report (Ran/Lakshminath) 10 mins Revised milestones Notes on cross-area work and reviews * draft-ietf-msec-bootstrapping-tesla (Steffen) 5 mins * The following two drafts are in IETF last call; Perhaps the authors = can brief the WG on the status? If not Ran/Lakshminath will summarize. draft-ietf-msec-newtype-keyid (Elisabetta?) 5 mins draft-ietf-msec-srtp-tesla (Mark/Elisabetta?) 5 mins * draft-ietf-msec-ipsec-extensions (Dragan/George) 10 mins * draft-ietf-msec-mikey-ecc (Andy) 10 mins =09 * draft-ietf-msec-mikey-rsa-r (Dragan) 10 mins * draft-dondeti-msec-inband-key-updates (Lakshminath) 10 mins * draft-faurite-rmt-tesla-for-alc-norm "RMT proposal for 10 mins MSEC review" 75 mins thanks and regards, Lakshminath ------_=_NextPart_001_01C59093.590ED640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MSEC agenda

With a subject line, sorry for the duplicate.

thanks,
Lakshminath


-----Original Message-----
From: Dondeti, Lakshminath
Sent: Sun 7/24/2005 2:03 PM
To: msec@securemulticast.org
Cc: canetti@watson.ibm.com
Subject:

Hi all,

Here is a draft MSEC@IETF-63 Agenda.  If I missed any items or if = anyone needs more time, please let Ran/me know.  We may be able to = entertain 1-2 last minute items.

* MSEC status = report           &= nbsp;       = (Ran/Lakshminath)    10 mins
  Revised milestones
  Notes on cross-area work and reviews

* draft-ietf-msec-bootstrapping-tesla   = (Steffen)          &nbs= p; 5 mins

* The following two drafts are in IETF last call;  Perhaps the = authors can brief the WG on the status? If not Ran/Lakshminath will = summarize.

    = draft-ietf-msec-newtype-keyid       = (Elisabetta?)        5 mins
    = draft-ietf-msec-srtp-tesla        = ;  (Mark/Elisabetta?)   5 mins

* draft-ietf-msec-ipsec-extensions      = (Dragan/George)     10 mins

* = draft-ietf-msec-mikey-ecc        =      = (Andy)           &= nbsp;  10 mins
       
* = draft-ietf-msec-mikey-rsa-r       &nbs= p;   = (Dragan)           = ; 10 mins

* draft-dondeti-msec-inband-key-updates = (Lakshminath)       10 mins

* draft-faurite-rmt-tesla-for-alc-norm  "RMT proposal = for   10 mins
            &= nbsp;           &n= bsp;           &nb= sp;    MSEC review"

            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           75 = mins

thanks and regards,
Lakshminath

------_=_NextPart_001_01C59093.590ED640-- --===============2085457452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============2085457452==-- From msec-bounces@securemulticast.org Sun Jul 24 17:07:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnhL-0008MY-3K for msec-archive@megatron.ietf.org; Sun, 24 Jul 2005 17:07:50 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25459 for ; Sun, 24 Jul 2005 17:07:44 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 45C5E8C40A; Sun, 24 Jul 2005 17:07: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 D0B878C301 for ; Sun, 24 Jul 2005 17:07:44 -0400 (EDT) Received: (qmail 61669 invoked by uid 3269); 24 Jul 2005 21:07:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61666 invoked from network); 24 Jul 2005 21:07:44 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Jul 2005 21:07:44 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 92DB56836F for ; Sun, 24 Jul 2005 17:07:44 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6OL7do7002446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 24 Jul 2005 14:07:40 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6OL7b4x027638 for ; Sun, 24 Jul 2005 14:07:37 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 14:07:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Jul 2005 14:07:36 -0700 Message-ID: Thread-Topic: MSEC meeting at IETF-63: need scribes Thread-Index: AcWQk7ejTMmUKca6RxyERHqwB7gOHw== From: "Dondeti, Lakshminath" To: X-OriginalArrivalTime: 24 Jul 2005 21:07:37.0367 (UTC) FILETIME=[B820B270:01C59093] Subject: [MSEC] MSEC meeting at IETF-63: need scribes 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="===============0009970496==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0009970496== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59093.B7AA94F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59093.B7AA94F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here are the details for the MSEC meeting in Paris. Tuesday, August 2, 2005 1815-1945 Afternoon Session III Room 351 SEC msec Multicast Security WG We need 2 scribes at the meeting. Ran and I are looking for volunteers. = Thanks in advance. best regards, Lakshminath =20 ------_=_NextPart_001_01C59093.B7AA94F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MSEC meeting at IETF-63: need scribes

Here are the details for the MSEC meeting in = Paris.

     Tuesday, August 2, 2005
     1815-1945 Afternoon Session III
     Room 351  SEC   = msec      Multicast Security WG

We need 2 scribes at the meeting.  Ran and I are looking for = volunteers.  Thanks in advance.

best regards,
Lakshminath


 

------_=_NextPart_001_01C59093.B7AA94F0-- --===============0009970496== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0009970496==-- From msec-bounces@securemulticast.org Mon Jul 25 11:37:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx51d-0006SZ-BR for msec-archive@megatron.ietf.org; Mon, 25 Jul 2005 11:37:53 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00717 for ; Mon, 25 Jul 2005 11:37:49 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2B78D8C5B0; Mon, 25 Jul 2005 11:37:50 -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 BF8548C5A9 for ; Mon, 25 Jul 2005 11:37:49 -0400 (EDT) Received: (qmail 32819 invoked by uid 3269); 25 Jul 2005 15:37:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32816 invoked from network); 25 Jul 2005 15:37:49 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 25 Jul 2005 15:37:49 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 4B1C16836F for ; Mon, 25 Jul 2005 11:37:49 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6PFbTsa003844; Mon, 25 Jul 2005 08:37:30 -0700 (PDT) Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6PFbJTY017333; Mon, 25 Jul 2005 08:37:27 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 08:37:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Jul 2005 08:37:24 -0700 Message-ID: Thread-Topic: MSEC Agenda Thread-Index: AcWRLsFcig3061x1TyaGcNWB+iIiFA== From: "Dondeti, Lakshminath" To: X-OriginalArrivalTime: 25 Jul 2005 15:37:25.0709 (UTC) FILETIME=[C1DF57D0:01C5912E] Cc: msec@securemulticast.org Subject: [MSEC] MSEC Agenda 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="===============1691459162==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1691459162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5912E.C168DF00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5912E.C168DF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here is the MSEC Agenda for IETF-63. * Blue sheets, Agenda Bashing etc., 2 mins * MSEC status report (Ran/Lakshminath) 10 mins Revised milestones Notes on cross-area work and reviews * draft-ietf-msec-bootstrapping-tesla (Steffen) 5 mins * draft-ietf-msec-newtype-keyid (Ran/Lakshminath) 5 mins * draft-ietf-msec-srtp-tesla (Ran/Lakshminath) 5 mins * draft-ietf-msec-ipsec-extensions (Dragan) 10 mins * draft-ietf-msec-mikey-ecc (Andy) 10 mins =20 * draft-ietf-msec-mikey-rsa-r (Dragan) 10 mins * draft-dondeti-msec-inband-key-updates (Lakshminath) 10 mins * draft-faurite-rmt-tesla-for-alc-norm "RMT proposal for 10 mins MSEC review" * draft-cruickshank-ipdvb-sec-00.txt "IPDVB proposal for 10 mins MSEC review" * closing remarks 3 mins 90 mins thanks and regards, Lakshminath ------_=_NextPart_001_01C5912E.C168DF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MSEC Agenda

Hi,

Here is the MSEC Agenda for IETF-63.


* Blue sheets, Agenda Bashing = etc.,           &n= bsp;           &nb= sp;  2 mins
* MSEC status = report           &= nbsp;       = (Ran/Lakshminath)    10 mins
  Revised milestones
  Notes on cross-area work and reviews

* draft-ietf-msec-bootstrapping-tesla   = (Steffen)          &nbs= p; 5 mins

* = draft-ietf-msec-newtype-keyid        = (Ran/Lakshminath)     5 mins
* = draft-ietf-msec-srtp-tesla        = ;   (Ran/Lakshminath)     5 mins

* draft-ietf-msec-ipsec-extensions      = (Dragan)           = ; 10 mins

* = draft-ietf-msec-mikey-ecc        =      = (Andy)           &= nbsp;  10 mins
      
* = draft-ietf-msec-mikey-rsa-r       &nbs= p;   = (Dragan)           = ; 10 mins

* draft-dondeti-msec-inband-key-updates = (Lakshminath)       10 mins

* draft-faurite-rmt-tesla-for-alc-norm  "RMT proposal = for   10 mins
            &= nbsp;           &n= bsp;           &nb= sp;    MSEC review"

* draft-cruickshank-ipdvb-sec-00.txt    "IPDVB = proposal for 10 mins
            &= nbsp;           &n= bsp;           &nb= sp;    MSEC review"
* closing = remarks           =             &= nbsp;           &n= bsp;        3 mins

            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           90 = mins

thanks and regards,
Lakshminath

------_=_NextPart_001_01C5912E.C168DF00-- --===============1691459162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1691459162==-- From msec-bounces@securemulticast.org Thu Jul 28 04:11:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3Tn-0000mh-Vm for msec-archive@megatron.ietf.org; Thu, 28 Jul 2005 04:11:00 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04697 for ; Thu, 28 Jul 2005 04:10:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AE0D08C5C7; Thu, 28 Jul 2005 04:10:58 -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 80E5D8C558 for ; Thu, 28 Jul 2005 04:10:57 -0400 (EDT) Received: (qmail 11680 invoked by uid 3269); 28 Jul 2005 08:10:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11672 invoked from network); 28 Jul 2005 08:10:57 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Jul 2005 08:10:57 -0000 Received: from mx-serv.inrialpes.fr (mx-serv.inrialpes.fr [194.199.18.100]) by klesh.pair.com (Postfix) with ESMTP id 14E5068374 for ; Thu, 28 Jul 2005 04:10:56 -0400 (EDT) Received: from amandier.inrialpes.fr (amandier.inrialpes.fr [194.199.18.76]) by mx-serv.inrialpes.fr (8.13.0/8.13.0) with ESMTP id j6S8ADK8017809; Thu, 28 Jul 2005 10:10:13 +0200 (MEST) Received: from [194.199.24.96] (charmille.inrialpes.fr [194.199.24.96]) by amandier.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id j6S8ABB09109; Thu, 28 Jul 2005 10:10:13 +0200 (MEST) Message-ID: <42E892E6.50608@inrialpes.fr> Date: Thu, 28 Jul 2005 10:10:14 +0200 From: faurite User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Michael Luby References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mx-serv.inrialpes.fr [194.199.18.100]); Thu, 28 Jul 2005 10:10:14 +0200 (MEST) X-SMAUG-MailScanner: Found to be clean X-SMAUG-MailScanner-From: sebastien.faurite@inrialpes.fr Cc: msec@securemulticast.org, vincent.roca@inrialpes.fr, "Rmt@ietf. org" Subject: [MSEC] Re: [Rmt] Comments on TESLA source authentication in the ALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA04697 Mike, thanks a lot for your constructive remarks. Generally speaking, we do agree with all of them. The choices we made have been done with the goal to bootstrap the work (keep in mind it's only a -00 version) and to fill in some missing aspects in current TESLA documents. Let's go into the details, in particular concerning the "split between MSEC and RMT WG". You're right, our I-D could easily be split into several separate documents, some of them being specified in the MSEC WG, and the ALC/NORM instanciation in the RMT WG. This is not the choice we made for the -00 version because we wanted to put forward all the points we believe are needed (and that are missing in current MSEC TESLA documents). For instance: - boostrap stuff could be moved to a separate "TESLA bootstraping for ALC/NORM" document (or merged with the current "TESLA bootstraping for SRTP" document if the authors believe it's feasible/desireable). - key chain switching: RFC4082 (TESLA introduction) does not discuss this possibility of high practical importance. The same is true for the "TESLA for SRTP" I-D. This is an issue in particular (but not only) with on-demand ALC sessions of non-predefined duration. We tried to fix this, but yes, a better solution would be to have this mechanism described in some MSEC TESLA document since it could then be used not only for ALC/NORM but also for SRTP... =20 - time synchronization stuff: RFC4082 and "TESLA for SRTP" essentially focuss on direct synchronization, which is not necessarily appropriate in case of ALC (scalability/feedback problems). So we tried to further clarify how indirect synchronization could be done (securely)... But yes, here also, a better solution would be to have it described in an MSEC TESLA document. Having it all in the same -00 document was a deliberate choice, but this is questionable, sure. A direct consequence is that this single I-D could not be submitted to both WGs and we've been adviced to send it to RMT and CC it to MSEC. That's why. BTW, an updated "TESLA spec" along the lines of the (dead) I-D: http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec-00.txt that would incorporate the missing points above is clearly missing.=20 Some parts of our I-D is inspired from it, as we explained. Cheers, Sebastien/Aurelien/Vincent >Comments on TESLA source authentication in the ALC and NORM protocols: >draft-faurite-rmt-tesla-for-alc-norm-00.txt > >First off, I think that this is a very good thing to try and standardize= , as >TESLA is ideally suited to provide authentication and packet integrity >protection to ALC and NORM. Unfortunately, I have a lot of questions a= nd >issues with the draft, and some are basic questions about where this wor= k >should be done. > >What I was expecting is a document that describes how to apply TESLA and >related security features that have been developed in MSEC that have bee= n >developed in the spirit of a building block to ALC and NORM, where all t= he >security issues have been addressed in the TESLA work and it is simply c= ut >and paste to put that into the ALC and NORM context. What I see instead= is >a document that describes a lot of protocol work that has security aspec= ts >to it that seems more suitable for MSEC. I=92m not sure why this is, pe= rhaps >because the TESLA specification does not lend itself to being used as a >building block directly, and perhaps because some of the other security >protocols have not been addressed by MSEC. It would be good though if t= he >basic security work were done in MSEC, and only applications of that wor= k >that have no potential to introduce weaknesses in security were describe= d in >the RMT work that describes how these protocols are applied to ALC and N= ORM. >I have been informed that this is the approach taken with SRTP, i.e., th= e >work to apply TESLA to SRTP is being done within MSEC, and not AVT. > >As an example, Section 2 describes protocols for time synchronization >between the sender and receivers. Since the security of TESLA entirely >relies on time synchronization, the security of this protocol is of cruc= ial >importance. Furthermore, it seems that time synchronization would be a >basic primitive of any protocol that uses TESLA. Thus, it seems like th= e >time synchronization protocols should be work done within the MSEC group >that can then be leveraged for application work done in RMT, and it seem= s >inappropriate for this work to be done in RMT since the security protoco= l >experts aren=92t there. > >Section 3 on setting TESLA parameters seems to be the type of thing that= one >would expect in this draft. However, even in this section, there is ver= y >little reference and tie-in with the TESLA RFC, and thus it would be goo= d to >tighten this section up and refer to the appropriate sections and >definitions used in TESLA in this section and use the protocols that hav= e >been standardized in TESLA. A related comment is that it should be sai= d >somewhere in this draft incorporates the TESLA RFC and inherits all of t= he >terminology of the TESLA RFC. > >The bulk of Section 3 defines the format of bootstrap information signat= ure >fields and authentication tags, and many related parameters. It seems l= ike >this format and information should all be defined in the TESLA RFC, or i= f >not in a related RFC within MSEC. If this is all new to this draft and = not >described in the TESLA RFC then this seems like a lot of new >formatting/information to be adding beyond TESLA, and I would feel a lot >more comfortable if this work were done in MSEC. > >There are a number of other technical comments that could be made, but I >think the high level issue of how to split the work between MSEC and RMT >should be solved before addressing lower level technical issues. > >Regards, >Michael Luby > > >_______________________________________________ >Rmt mailing list >Rmt@ietf.org >https://www1.ietf.org/mailman/listinfo/rmt > > =20 > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jul 28 09:14:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8DY-0005DF-P2 for msec-archive@megatron.ietf.org; Thu, 28 Jul 2005 09:14:33 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24441 for ; Thu, 28 Jul 2005 09:14:30 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5EFEF8C852; Thu, 28 Jul 2005 09:14:31 -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 B4C588C847 for ; Thu, 28 Jul 2005 09:14:29 -0400 (EDT) Received: (qmail 58136 invoked by uid 3269); 28 Jul 2005 13:14:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58133 invoked from network); 28 Jul 2005 13:14:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 28 Jul 2005 13:14:29 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id 39FCC68371 for ; Thu, 28 Jul 2005 09:14:29 -0400 (EDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j6SDEHa2013089; Thu, 28 Jul 2005 15:14:17 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j6SDE1NZ026440; Thu, 28 Jul 2005 15:14:16 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Jul 2005 15:13:57 +0200 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2005 15:13:51 +0200 Message-ID: Thread-Topic: Comments on draft-ietf-msec-mikey-ecc-00.txt Thread-Index: AcWTdjLdmhuLro6BRoeytJNwOPamOA== From: "Fries, Steffen" To: , , , X-OriginalArrivalTime: 28 Jul 2005 13:13:57.0617 (UTC) FILETIME=[3649FE10:01C59376] Cc: "Hess, Erwin" , msec@securemulticast.org Subject: [MSEC] Comments on draft-ietf-msec-mikey-ecc-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 Content-Transfer-Encoding: quoted-printable Hi, during the presentation of the draft draft-ietf-msec-mikey-ecc-00.txt at the last IETF meeting, there was discussion about the patent situation=20 regarding EC-MQV.=20 Because of this, we suggest to add a DH method to the current draft, which=20 is (to our knowledge) free of patent issues. This DH method is very similar=20 to the method defined in RFC3830. The only difference here is that the=20 signature algorithm is based on elliptic curves, to be more specific on=20 ECDSA. The proposal also proceeds with one roundtrip for the key establishing=20 process of two clients A and B : Elliptic curve Diffie Hellman key agreement (ECDH) protected with the ECDSA (or ECGDSA) signature scheme. This scheme proceeds as follows: Both client A and client B are endowed with the same cryptographically secure elliptic curve. The system parameters are: - an elliptic curve E over a finite field F (of type GF(p) or GF(2^n), p a prime, n a positive integer). - a point P on E generating a cyclic group of prime order q - a hash function h - the elliptic curve based digital signature scheme ECDSA (or ECGDSA) using hash function h - a random number generator Random() generating random numbers in the range {1, ..., q-1} - The client's individual keys and parameters are: - ID_A: A's identity - SK_A: A's private key - PK_A: A's public key - Cert_A: Certificate binding PK_A to ID_A - ID_B: B's identity - SK_B: B's private key - PK_B: B's public key - Cert_B: Certificate binding PK_B to ID_B Client A - Initiator Client B -Responder Initialization: Rand, x:=3D Random() Protocol execution: xP:=3D the x-fold of curve point P K:=3D xP, T, RAND, [ID_A|CERT_A], ID_B, {SP} S:=3D EC(G)DSA(H(xP),SK_A) I_MESSAGE =3D HDR, (K,S) ----------------------------> Initialization: Rand, y:=3D Random() Protocol execution: Verification of certificate Cert_A and signature S. (if valid continue else abort) yP:=3D the y-fold of curve point P K':=3D yP, T, RAND, [ID_B|CERT_B], ID_A, {SP} S':=3D EC(G)DSA(H(yP),SK_B) R_MESSAGE =3D(K',S') <---------------------------- Verification of certificate Cert_B and signature S'. (if valid continue else abort) TGK:=3D xK' TGK:=3D yK TGK is the common key A and B agreed on in this protocol. A similar approach using elliptic curves in TLS is described in=20 draft-ietf-tls-ecc-10.txt and provides also the option to use ESDH=20 with ECDSA. Regards Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Jul 29 10:50:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWBg-0000eL-9Q for msec-archive@megatron.ietf.org; Fri, 29 Jul 2005 10:50:12 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14685 for ; Fri, 29 Jul 2005 10:50:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 424728C533; Fri, 29 Jul 2005 10:50:10 -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 E0D908C4D3 for ; Fri, 29 Jul 2005 10:50:08 -0400 (EDT) Received: (qmail 16747 invoked by uid 3269); 29 Jul 2005 14:50:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16744 invoked from network); 29 Jul 2005 14:50:08 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 29 Jul 2005 14:50:08 -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 7D97268371 for ; Fri, 29 Jul 2005 10:50:08 -0400 (EDT) Received: (qmail 2960 invoked from network); 29 Jul 2005 10:50:03 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 29 Jul 2005 10:50:03 -0400 Received: (qmail 53719 invoked from network); 29 Jul 2005 10:50:02 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.6) by mail1.oct.nac.net with SMTP; 29 Jul 2005 10:50:02 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j6TBVYW28333; Fri, 29 Jul 2005 07:31:34 -0400 Date: Fri, 29 Jul 2005 07:31:34 -0400 (EDT) From: George Gross To: faurite Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source authentication in the ALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt In-Reply-To: <42E892E6.50608@inrialpes.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Rmt@ietf. org" , vincent.roca@inrialpes.fr, 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 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, =09I've taken a quick look at the NORM/ALC TESLA draft. It makes a good starting point for how to apply TESLA in combination with the RMT work. I did not dive into it to get details, but a few high level comments seemed in order: 1) I have not identified a compelling architectural reason why NORM/ALC TESLA needs to be applied in an application specific manner. Instead, this work is a good candidate for inclusion within a set of one or more standards track documents that describe how to apply TESLA to existing and emergent MSEC and IPsec standards. In particular, I would suggest taking a look at the draft-ietf-msec-ipsec-extensions-00.txt, particularly the service models discussion in the appendix. 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong resemblance to the Internet layer group key management protocols already developed in MSEC: GDOI and GSAKMP. For example, the TESLA bootstrap information could become a sub-payload within the GSAKMP Key DownLoad payload. By using an existent MSEC GKMP, the group membership and group speaker authentication and authorization procedures are largely defined and the TESLA feature becomes an extension of a framework. As an aside, GSAKMP has a distributed mode of operation that alleviates the scalability problem, and it also a uni-directional mode too (e.g. for satellite). 3) as part of the same activity, we would need to design a TESLA ESP trailer authenticator, with NORM or ALC as the payload. 4) integration with the MSEC framework has the additional benefit that the unicast NORM repair and congestion notification messages directed at the group speaker could be both group and source endpoint authenticated, the source authentication using the RSA signatures scheme now in RFC editor queue. 5) The use of one-way hash chains advocated in the NORM/ALC TESLA draft may have IPR issues. I'm not a patent attornory, YMMV. The NORM/ALC TESLA draft is on the MSEC agenda for Paris, but I won't be there. So I would hope these discussions could continue on the MSEC list. hth, =09George On Thu, 28 Jul 2005, faurite wrote: > Mike, thanks a lot for your constructive remarks. > > Generally speaking, we do agree with all of them. The choices > we made have been done with the goal to bootstrap the work (keep > in mind it's only a -00 version) and to fill in some missing > aspects in current TESLA documents. > > > Let's go into the details, in particular concerning the > "split between MSEC and RMT WG". > > > You're right, our I-D could easily be split into several separate > documents, some of them being specified in the MSEC WG, and the > ALC/NORM instanciation in the RMT WG. > This is not the choice we made for the -00 version because we > wanted to put forward all the points we believe are needed (and > that are missing in current MSEC TESLA documents). > > For instance: > - boostrap stuff could be moved to a separate "TESLA bootstraping > for ALC/NORM" document (or merged with the current "TESLA > bootstraping for SRTP" document if the authors believe it's > feasible/desireable). > > - key chain switching: RFC4082 (TESLA introduction) does not discuss > this possibility of high practical importance. The same is true > for the "TESLA for SRTP" I-D. This is an issue in particular (but > not only) with on-demand ALC sessions of non-predefined duration. > We tried to fix this, but yes, a better solution would be to > have this mechanism described in some MSEC TESLA document since > it could then be used not only for ALC/NORM but also for SRTP... > > - time synchronization stuff: RFC4082 and "TESLA for SRTP" > essentially focuss on direct synchronization, which is > not necessarily appropriate in case of ALC (scalability/feedback > problems). So we tried to further clarify how indirect synchronization > could be done (securely)... > But yes, here also, a better solution would be to have it described > in an MSEC TESLA document. > > Having it all in the same -00 document was a deliberate choice, but > this is questionable, sure. A direct consequence is that this single > I-D could not be submitted to both WGs and we've been adviced to send > it to RMT and CC it to MSEC. That's why. > > BTW, an updated "TESLA spec" along the lines of the (dead) I-D: > http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec-00.txt > that would incorporate the missing points above is clearly missing. > Some parts of our I-D is inspired from it, as we explained. > > Cheers, > > Sebastien/Aurelien/Vincent > > > > >Comments on TESLA source authentication in the ALC and NORM protocols: > >draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > >First off, I think that this is a very good thing to try and standardize= , as > >TESLA is ideally suited to provide authentication and packet integrity > >protection to ALC and NORM. Unfortunately, I have a lot of questions a= nd > >issues with the draft, and some are basic questions about where this wor= k > >should be done. > > > >What I was expecting is a document that describes how to apply TESLA and > >related security features that have been developed in MSEC that have bee= n > >developed in the spirit of a building block to ALC and NORM, where all t= he > >security issues have been addressed in the TESLA work and it is simply c= ut > >and paste to put that into the ALC and NORM context. What I see instead= is > >a document that describes a lot of protocol work that has security aspec= ts > >to it that seems more suitable for MSEC. I=92m not sure why this is, pe= rhaps > >because the TESLA specification does not lend itself to being used as a > >building block directly, and perhaps because some of the other security > >protocols have not been addressed by MSEC. It would be good though if t= he > >basic security work were done in MSEC, and only applications of that wor= k > >that have no potential to introduce weaknesses in security were describe= d in > >the RMT work that describes how these protocols are applied to ALC and N= ORM. > >I have been informed that this is the approach taken with SRTP, i.e., th= e > >work to apply TESLA to SRTP is being done within MSEC, and not AVT. > > > >As an example, Section 2 describes protocols for time synchronization > >between the sender and receivers. Since the security of TESLA entirely > >relies on time synchronization, the security of this protocol is of cruc= ial > >importance. Furthermore, it seems that time synchronization would be a > >basic primitive of any protocol that uses TESLA. Thus, it seems like th= e > >time synchronization protocols should be work done within the MSEC group > >that can then be leveraged for application work done in RMT, and it seem= s > >inappropriate for this work to be done in RMT since the security protoco= l > >experts aren=92t there. > > > >Section 3 on setting TESLA parameters seems to be the type of thing that= one > >would expect in this draft. However, even in this section, there is ver= y > >little reference and tie-in with the TESLA RFC, and thus it would be goo= d to > >tighten this section up and refer to the appropriate sections and > >definitions used in TESLA in this section and use the protocols that hav= e > >been standardized in TESLA. A related comment is that it should be sai= d > >somewhere in this draft incorporates the TESLA RFC and inherits all of t= he > >terminology of the TESLA RFC. > > > >The bulk of Section 3 defines the format of bootstrap information signat= ure > >fields and authentication tags, and many related parameters. It seems l= ike > >this format and information should all be defined in the TESLA RFC, or i= f > >not in a related RFC within MSEC. If this is all new to this draft and = not > >described in the TESLA RFC then this seems like a lot of new > >formatting/information to be adding beyond TESLA, and I would feel a lot > >more comfortable if this work were done in MSEC. > > > >There are a number of other technical comments that could be made, but I > >think the high level issue of how to split the work between MSEC and RMT > >should be solved before addressing lower level technical issues. > > > >Regards, > >Michael Luby > > > > > >_______________________________________________ > >Rmt mailing list > >Rmt@ietf.org > >https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > _______________________________________________ > 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