From mailman-bounces@six.pairlist.net Sun Aug 1 05:03:52 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04196 for ; Sun, 1 Aug 2004 05:03:52 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 672378D17E for ; Sun, 1 Aug 2004 05:03:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: securemulticast.org mailing list memberships reminder From: mailman-owner@securemulticast.org To: msec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:01:15 -0400 Precedence: bulk X-BeenThere: mailman@six.pairlist.net X-Mailman-Version: 2.1.5 List-Id: mailman.six.pairlist.net X-List-Administrivia: yes Sender: mailman-bounces@six.pairlist.net Errors-To: mailman-bounces@six.pairlist.net Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your securemulticast.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@securemulticast.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@securemulticast.org. Thanks! Passwords for msec-archive@lists.ietf.org: List Password // URL ---- -------- msec@securemulticast.org ucweat http://six.pairlist.net/mailman/options/msec/msec-archive%40lists.ietf.org From msec-bounces@securemulticast.org Sun Aug 1 21:39:33 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07567 for ; Sun, 1 Aug 2004 21:39:32 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2F6FE8C432; Sun, 1 Aug 2004 21:39: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 D83D38C225 for ; Sun, 1 Aug 2004 21:39:31 -0400 (EDT) Received: (qmail 83147 invoked by uid 3269); 2 Aug 2004 01:39:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83144 invoked from network); 2 Aug 2004 01:39:31 -0000 Received: from bache.ece.cmu.edu (128.2.129.23) by klesh.pair.com with SMTP; 2 Aug 2004 01:39:31 -0000 Received: from FINCH.ECE.CMU.EDU (FINCH.ECE.CMU.EDU [128.2.134.43]) by bache.ece.cmu.edu (Postfix) with ESMTP id 7B21EBBE for ; Sun, 1 Aug 2004 21:39:31 -0400 (EDT) Date: Sun, 1 Aug 2004 21:39:31 -0400 (EDT) From: Adrian Perrig To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Updated draft-ietf-msec-tesla-intro-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 Hi, We updated the introductory draft for the TESLA broadcast authentication protocol, it is available at: http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-intro-03.txt We are looking forward to hearing any comments or suggestions you may have. Best wishes, Adrian _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 3 04:10:40 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23694 for ; Tue, 3 Aug 2004 04:10:39 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 43AD98D31B; Tue, 3 Aug 2004 04:10:38 -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 99C428D2FB for ; Tue, 3 Aug 2004 04:10:36 -0400 (EDT) Received: (qmail 19139 invoked by uid 3269); 3 Aug 2004 08:10:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19136 invoked from network); 3 Aug 2004 08:10:36 -0000 Received: from saturn.bt.com (HELO cbibipnt08.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 3 Aug 2004 08:10:36 -0000 Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QDZSGBAJ; Tue, 3 Aug 2004 09:10:35 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1091520634267; Tue, 3 Aug 2004 09:10:34 +0100 Received: from maat.jungle.bt.co.uk (maat.jungle.bt.co.uk [132.146.108.145]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i738AT7S018467; Tue, 3 Aug 2004 09:10:30 +0100 Message-Id: <5.2.1.1.2.20040803090532.02001510@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 03 Aug 2004 09:11:34 +0100 To: Adrian Perrig From: Bob Briscoe Subject: Re: [MSEC] Updated draft-ietf-msec-tesla-intro-03.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; 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 Adrian, At 02:39 02/08/04, Adrian Perrig wrote: >Hi, >We updated the introductory draft for the TESLA broadcast >authentication protocol, it is available at: >http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-intro-03.txt >We are looking forward to hearing any comments or suggestions you may >have. Best wishes, > Adrian Thanks for this. I am about to read it, but before I do... I've done a quick compare relative to the 02 draft and there seem to be quite a few changes. Can you give a quick summary of the main things you've changed and motivation, so those of us who have read previous drafts can comment more efficiently. Alternatively, if you don't have time, just say, and I'll read the whole thing. Cheers Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 3 17:19:24 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12895 for ; Tue, 3 Aug 2004 17:19:24 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D24DD8D7EF; Tue, 3 Aug 2004 17:19:24 -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 211DA8D1E9 for ; Tue, 3 Aug 2004 17:19:23 -0400 (EDT) Received: (qmail 85996 invoked by uid 3269); 3 Aug 2004 21:19:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85993 invoked from network); 3 Aug 2004 21:19:23 -0000 Received: from web12505.mail.yahoo.com (216.136.173.197) by klesh.pair.com with SMTP; 3 Aug 2004 21:19:23 -0000 Message-ID: <20040803211922.19763.qmail@web12505.mail.yahoo.com> Received: from [65.205.251.51] by web12505.mail.yahoo.com via HTTP; Tue, 03 Aug 2004 14:19:22 PDT Date: Tue, 3 Aug 2004 14:19:22 -0700 (PDT) From: Thomas Hardjono To: MSEC MSEC MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MSEC] Slides now online (from MSEC meeting on Monday) 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 Folks, The slides from the MSEC meeting on Monday at IETF60 can now be found on the MSEC website: http://www.securemulticast.org/msec-meetings.htm Those who have not submitted their slides, please do so a.s.a.p as I have to send them to the IETF secretariat for the proceedings. Regards. thomas ------ __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 4 14:05:37 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24548 for ; Wed, 4 Aug 2004 14:05:37 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7CB868CFEF; Wed, 4 Aug 2004 14:05: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 9BE7E8CFDD for ; Wed, 4 Aug 2004 14:05:36 -0400 (EDT) Received: (qmail 76713 invoked by uid 3269); 4 Aug 2004 18:05:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76707 invoked from network); 4 Aug 2004 18:05:35 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 4 Aug 2004 18:05:35 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i74I5V503856 for ; Wed, 4 Aug 2004 14:05:31 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPX306AS; Wed, 4 Aug 2004 14:05:30 -0400 Received: from [47.130.24.70] (acart0jr.ca.nortel.com [47.130.24.70]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PSKYPYNF; Wed, 4 Aug 2004 14:05:30 -0400 Message-ID: <41112567.5070604@nortelnetworks.com> Date: Wed, 04 Aug 2004 14:05:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MSEC MSEC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Experimental/Standards track for IPsec mapping for GSAKMP I-D X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi, I was looking at the meeting summary that notes that the IPsec mapping for GSAKMP I-D is going forward as a standards track document. As I recall, Hugh's point was that this is just one way of IPsec SA establishment in GSAKMP. I think I was agnostic :-). So, I was wondering - since the draft only talks about one of the several ways of doing IPsec with GSAKMP (does GSAKMP specify one already?) - whether it makes sense to use the experimental track for this. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 5 10:45:36 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22041 for ; Thu, 5 Aug 2004 10:45:36 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5C1188C7BD; Thu, 5 Aug 2004 10:45: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 6B9238C733 for ; Thu, 5 Aug 2004 10:45:36 -0400 (EDT) Received: (qmail 6151 invoked by uid 3269); 5 Aug 2004 14:45:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6148 invoked from network); 5 Aug 2004 14:45:36 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 5 Aug 2004 14:45:36 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.12.8/8.12.8) with ESMTP id i75EjUZ5013470; Thu, 5 Aug 2004 09:45:31 -0500 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id i75EjUsZ013887; Thu, 5 Aug 2004 09:45:31 -0500 Received: from [157.185.80.26] (dhcp-26.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id i75EjScV013691; Thu, 5 Aug 2004 10:45:30 -0400 (EDT) In-Reply-To: <41112567.5070604@nortelnetworks.com> References: <41112567.5070604@nortelnetworks.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <18BB9DDD-E6EE-11D8-AFD5-000393DAFB3C@sparta.com> Content-Transfer-Encoding: 7bit From: Hugh Harney Subject: Re: [MSEC] Experimental/Standards track for IPsec mapping for GSAKMP I-D Date: Thu, 5 Aug 2004 10:45:29 -0400 To: "Dondeti, Lakshminath" X-Mailer: Apple Mail (2.618) Cc: MSEC MSEC X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Lakshminath, GSAKMP does not specify how to do IPSec for group communications. It does offer a policy token that can be extended to provide policy information to support IPSec. GSAKMP is agnostic wrt the data layer protocol it is supporting. Hugh On Aug 4, 2004, at 2:05 PM, Dondeti, Lakshminath wrote: > Hi, > > I was looking at the meeting summary that notes that the IPsec mapping > for GSAKMP I-D is going forward as a standards track document. As I > recall, Hugh's point was that this is just one way of IPsec SA > establishment in GSAKMP. I think I was agnostic :-). > > So, I was wondering - since the draft only talks about one of the > several ways of doing IPsec with GSAKMP (does GSAKMP specify one > already?) - whether it makes sense to use the experimental track for > this. > > regards, > Lakshminath > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 5 12:24:31 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27737 for ; Thu, 5 Aug 2004 12:24:31 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C4AA18D842; Thu, 5 Aug 2004 12:24:30 -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 217748D7FF for ; Thu, 5 Aug 2004 12:24:29 -0400 (EDT) Received: (qmail 24953 invoked by uid 3269); 5 Aug 2004 16:24:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24946 invoked from network); 5 Aug 2004 16:24:28 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 5 Aug 2004 16:24:28 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i75GMpc17132; Thu, 5 Aug 2004 12:22:51 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i75GOOD33684; Thu, 5 Aug 2004 12:24:24 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i75GOML23020; Thu, 5 Aug 2004 12:24:23 -0400 Date: Thu, 5 Aug 2004 12:24:11 -0400 (EDT) From: canetti To: Hugh Harney In-Reply-To: <18BB9DDD-E6EE-11D8-AFD5-000393DAFB3C@sparta.com> Message-ID: References: <41112567.5070604@nortelnetworks.com> <18BB9DDD-E6EE-11D8-AFD5-000393DAFB3C@sparta.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: MSEC MSEC Subject: [MSEC] Can GSAKMP setup TESLA? 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 Hugh an all, Can GSAKMP handle setting up the parameters for TESLA? or if not, can it be easily extended to do so? The parameters needed by a TESLA are described in the TESLA-SRTP draft and the TESLA-intro draft. (The upcoming TESLA-ESP has similar requirements.) The only potentially tricky parameter is the value D_t, which is the bound on the time difference between the member and the sender. To setup that value correctly, there should be an authenticated member->gcks flow, followed by an authenticated gcks->member flow. The member should re cord the time of the outgoing message. the center should record the time of receipt of the message, and send it over in the return message. In addition, a sender and the gcks will do the same but in the reverse direction (ie, a gcks->sender flow, followed by a sender->gcks flow). the value D_t of each member with respect to a given sender will be the sum of the sender->gcks delay and the gcks->member delay. I'm sure GSAKMP can handle this in principle. But is there today provisioning on how to do this? If not, may be useful to add it. Best, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 5 13:37:14 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01980 for ; Thu, 5 Aug 2004 13:37:14 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CEAFD8D5BF; Thu, 5 Aug 2004 13:37:14 -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 CAD798D5B7 for ; Thu, 5 Aug 2004 13:37:12 -0400 (EDT) Received: (qmail 39225 invoked by uid 3269); 5 Aug 2004 17:37:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39222 invoked from network); 5 Aug 2004 17:37:12 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 5 Aug 2004 17:37:12 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.12.8/8.12.8) with ESMTP id i75Hb9Z5017249; Thu, 5 Aug 2004 12:37:10 -0500 Received: from columbia.sparta.com (lilo.columbia.SPARTA.COM [157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id i75Hb30a020989; Thu, 5 Aug 2004 12:37:09 -0500 Received: from [157.185.80.26] (dhcp-26.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id i75Hb2cV017206; Thu, 5 Aug 2004 13:37:02 -0400 (EDT) In-Reply-To: References: <41112567.5070604@nortelnetworks.com> <18BB9DDD-E6EE-11D8-AFD5-000393DAFB3C@sparta.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <104FB8FC-E706-11D8-AFD5-000393DAFB3C@sparta.com> Content-Transfer-Encoding: 7bit From: Hugh Harney Date: Thu, 5 Aug 2004 13:37:03 -0400 To: canetti X-Mailer: Apple Mail (2.618) Cc: MSEC MSEC Subject: [MSEC] Re: Can GSAKMP setup TESLA? 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 Ran, GSAKMP passes a policy token during the registration exchange. The core GSAKMP Policy Token has a "hook" for Data Layer policy specifications. I believe TESLA would be a data layer application in this context. Our Internet Draft for this Policy Token is written in ASN.1. ASN.1 provides a model where a core specification provides easy reference points for other ASN.1 specifications. So, in this case, we have provided a reference for data layer protocols. TESLA is clearly a data layer protocol. TESLA should write a TESLA specific I-D describing the configuration/policy information needed. This I-D would link to the core policy token specification and you have a well defined mechanism for providing TESLA policy via the Policy Token. Because the Policy Token specification already describes how this is works, the TESLA I-D for the Policy Token can be very short. We included a data layer policy example in the submitted draft. We used SRTP as the example. If TESLA does something similar an ASN.1 compiler would be able to create a Policy Token with TESLA policy incorporated into it. One of the reasons we believe the Policy Token should be written in ASN.1 is the to chain specifications together. The potential protocols supported an continue to grow even after the core Policy Token is an RFC. It becomes infinitely extensible. In short, I'd suggest that TESLA write a short I-D describing the policy it needs to be passed in the Policy Token. If this is done in ASN.1 you automatically can be linked to any Policy Token. I believe it is better to have an I-D for each data layer protocol supported by the PT because we can then create simple policy building blocks that can be used in ways that we don't envision today. For example, If GDOI version (x) decides to incorporate a Policy Token it could reference the TESLA ASN.1 RFC and use it. Hugh On Aug 5, 2004, at 12:24 PM, canetti wrote: > > Hugh an all, > > Can GSAKMP handle setting up the parameters for TESLA? or if not, can > it > be easily extended to do so? > > The parameters needed by a TESLA are described in the TESLA-SRTP draft > and > the TESLA-intro draft. (The upcoming TESLA-ESP has similar > requirements.) > > The only potentially tricky parameter is the value D_t, which is the > bound > on the time difference between the member and the sender. To setup > that > value correctly, there should be an authenticated member->gcks flow, > followed by an authenticated gcks->member flow. The member should re > cord the time of the outgoing message. the center should record the > time of receipt of the message, and send it over in the return message. > > In addition, a sender and the gcks will do the same but in the reverse > direction (ie, a gcks->sender flow, followed by a sender->gcks flow). > the > value D_t of each member with respect to a given sender will be the sum > of the sender->gcks delay and the gcks->member delay. > > I'm sure GSAKMP can handle this in principle. But is there today > provisioning on how to do this? If not, may be useful to add it. > > Best, > > Ran > > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 5 14:46:44 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05955 for ; Thu, 5 Aug 2004 14:46:44 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3F8578D787; Thu, 5 Aug 2004 14:46:45 -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 998038D783 for ; Thu, 5 Aug 2004 14:46:43 -0400 (EDT) Received: (qmail 53776 invoked by uid 3269); 5 Aug 2004 18:46:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53773 invoked from network); 5 Aug 2004 18:46:43 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 5 Aug 2004 18:46:43 -0000 Received: (qmail 57424 invoked from network); 5 Aug 2004 18:46:42 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 5 Aug 2004 18:46:42 -0000 Received: (qmail 47759 invoked from network); 5 Aug 2004 14:46:42 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 5 Aug 2004 14:46:42 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i75GIS306921; Thu, 5 Aug 2004 12:18:28 -0400 Date: Thu, 5 Aug 2004 12:18:28 -0400 (EDT) From: George Gross To: Hugh Harney Subject: Re: [MSEC] Re: Can GSAKMP setup TESLA? In-Reply-To: <104FB8FC-E706-11D8-AFD5-000393DAFB3C@sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: canetti , MSEC 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 Hi, I concur with Hugh's assessment of adding TESLA to GSAKMP. It can be done as a policy token extension, in combination with piggyback'ing TESLA specific payloads on the RTJ, KDL, and KDL-ACK messages. The TESLA payloads could be defined as Notification payloads, or for the GSAKMP IPsec application, it could be sub-payloads within Security Association Configuration payload. that said, I am not clear how one could accurately measure the network delay parameter on which TESLA depends. The GC/KS<->GM registration exchange is a snapshot of that delay at particular communication path at a particular time. The delay between the Group Speaker and a Group Receiver may be a different value, depending on the respective location and time of those two endpoints. Ran, how did you envision tracking and adjusting the network delay in a secure way after a Group Speaker's registration phase completes? would an active attacker who altered the perceived packet delivery delay of a sub-group make life difficult for TESLA? If you composed a TESLA GSAKMP ID along the lines suggested by Hugh, it would probably need to talk about how to handle these issues... George On Thu, 5 Aug 2004, Hugh Harney wrote: > Ran, > > GSAKMP passes a policy token during the registration exchange. The core > GSAKMP Policy Token has a "hook" for Data Layer policy specifications. > I believe TESLA would be a data layer application in this context. > > Our Internet Draft for this Policy Token is written in ASN.1. ASN.1 > provides a model where a core specification provides easy reference > points for other ASN.1 specifications. So, in this case, we have > provided a reference for data layer protocols. TESLA is clearly a data > layer protocol. TESLA should write a TESLA specific I-D describing the > configuration/policy information needed. This I-D would link to the > core policy token specification and you have a well defined mechanism > for providing TESLA policy via the Policy Token. > > Because the Policy Token specification already describes how this is > works, the TESLA I-D for the Policy Token can be very short. We > included a data layer policy example in the submitted draft. We used > SRTP as the example. If TESLA does something similar an ASN.1 compiler > would be able to create a Policy Token with TESLA policy incorporated > into it. > > One of the reasons we believe the Policy Token should be written in > ASN.1 is the to chain specifications together. The potential protocols > supported an continue to grow even after the core Policy Token is an > RFC. It becomes infinitely extensible. > > In short, I'd suggest that TESLA write a short I-D describing the > policy it needs to be passed in the Policy Token. If this is done in > ASN.1 you automatically can be linked to any Policy Token. I believe it > is better to have an I-D for each data layer protocol supported by the > PT because we can then create simple policy building blocks that can be > used in ways that we don't envision today. For example, If GDOI version > (x) decides to incorporate a Policy Token it could reference the TESLA > ASN.1 RFC and use it. > > Hugh > > > > > > On Aug 5, 2004, at 12:24 PM, canetti wrote: > > > > > Hugh an all, > > > > Can GSAKMP handle setting up the parameters for TESLA? or if not, can > > it > > be easily extended to do so? > > > > The parameters needed by a TESLA are described in the TESLA-SRTP draft > > and > > the TESLA-intro draft. (The upcoming TESLA-ESP has similar > > requirements.) > > > > The only potentially tricky parameter is the value D_t, which is the > > bound > > on the time difference between the member and the sender. To setup > > that > > value correctly, there should be an authenticated member->gcks flow, > > followed by an authenticated gcks->member flow. The member should re > > cord the time of the outgoing message. the center should record the > > time of receipt of the message, and send it over in the return message. > > > > In addition, a sender and the gcks will do the same but in the reverse > > direction (ie, a gcks->sender flow, followed by a sender->gcks flow). > > the > > value D_t of each member with respect to a given sender will be the sum > > of the sender->gcks delay and the gcks->member delay. > > > > I'm sure GSAKMP can handle this in principle. But is there today > > provisioning on how to do this? If not, may be useful to add it. > > > > Best, > > > > Ran > > > > > > > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 > > _______________________________________________ > 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 Aug 5 15:24:55 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09201 for ; Thu, 5 Aug 2004 15:24:54 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 09B848CF77; Thu, 5 Aug 2004 15:24: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 A1A978C8A0 for ; Thu, 5 Aug 2004 15:24:54 -0400 (EDT) Received: (qmail 62591 invoked by uid 3269); 5 Aug 2004 19:24:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62588 invoked from network); 5 Aug 2004 19:24:54 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 5 Aug 2004 19:24:54 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i75JNCc97586; Thu, 5 Aug 2004 15:23:12 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i75JOjD08082; Thu, 5 Aug 2004 15:24:45 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i75JOhp23032; Thu, 5 Aug 2004 15:24:43 -0400 Date: Thu, 5 Aug 2004 15:24:40 -0400 (EDT) From: canetti To: George Gross Subject: Re: [MSEC] Re: Can GSAKMP setup TESLA? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Hugh Harney , MSEC 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 Hugh, George, I dont think there is need in another draft: The current TESLA-SRTP draft already specified exactly what it needs from the key management protocol (be it GSAKMP or otherwise). It is not written in ASN.1 language, but this can be added if necessary. Do you think it is? Also, if we want things to work then there probably should be an appendix in GSAKMP that re-iterates these parameters and describes how they are computed. (Most of these parameters are just downloaded rfrom the GCKS. as said, the only tricky one is the time difference D_t.) George's suggestion on how to piggyback the timing info on the GSAKMP messages looks reasonable to me; it just needs to be written down. Thanks, Ran See below on George's question: On Thu, 5 Aug 2004, George Gross wrote: > Hi, > I concur with Hugh's assessment of adding TESLA to GSAKMP. It can > be done as a policy token extension, in combination with piggyback'ing > TESLA specific payloads on the RTJ, KDL, and KDL-ACK messages. The TESLA > payloads could be defined as Notification payloads, or for the GSAKMP > IPsec application, it could be sub-payloads within Security Association > Configuration payload. > > that said, I am not clear how one could accurately measure the > network delay parameter on which TESLA depends. The GC/KS<->GM > registration exchange is a snapshot of that delay at particular > communication path at a particular time. The delay between the Group > Speaker and a Group Receiver may be a different value, depending on > the respective location and time of those two endpoints. > > Ran, how did you envision tracking and adjusting the network delay > in a secure way after a Group Speaker's registration phase completes? > would an active attacker who altered the perceived packet delivery delay > of a sub-group make life difficult for TESLA? The purpose of the timing payloads in GSAKMP (or any other session setup protocol) is NOT to estimate the network delay. Rather, the goal is to compute a bound on the time difference between the local clocks at the sender and the receiver. Assuming that clocks do not drift too much, the "snapshot" at registration is good enough. Estimating the network delay is a different issue, which should be taken care of by the sender independnetly. Indeed, this task is quite application-specific and is thus left outside our stnadard. (A reminder: getting a good estimate on the network delay is not a security issue. TESLA is secure even if this estimate is totally off. If the estimate is too pessimistic then packets will be buffered for longer than necessary. If it is too optimistic then too many packets will arrive "too late" and will be dropped.) > > If you composed a TESLA GSAKMP ID along the lines suggested by > Hugh, it would probably need to talk about how to handle these issues... > > George > > On Thu, 5 Aug 2004, Hugh Harney wrote: > > > Ran, > > > > GSAKMP passes a policy token during the registration exchange. The core > > GSAKMP Policy Token has a "hook" for Data Layer policy specifications. > > I believe TESLA would be a data layer application in this context. > > > > Our Internet Draft for this Policy Token is written in ASN.1. ASN.1 > > provides a model where a core specification provides easy reference > > points for other ASN.1 specifications. So, in this case, we have > > provided a reference for data layer protocols. TESLA is clearly a data > > layer protocol. TESLA should write a TESLA specific I-D describing the > > configuration/policy information needed. This I-D would link to the > > core policy token specification and you have a well defined mechanism > > for providing TESLA policy via the Policy Token. > > > > Because the Policy Token specification already describes how this is > > works, the TESLA I-D for the Policy Token can be very short. We > > included a data layer policy example in the submitted draft. We used > > SRTP as the example. If TESLA does something similar an ASN.1 compiler > > would be able to create a Policy Token with TESLA policy incorporated > > into it. > > > > One of the reasons we believe the Policy Token should be written in > > ASN.1 is the to chain specifications together. The potential protocols > > supported an continue to grow even after the core Policy Token is an > > RFC. It becomes infinitely extensible. > > > > In short, I'd suggest that TESLA write a short I-D describing the > > policy it needs to be passed in the Policy Token. If this is done in > > ASN.1 you automatically can be linked to any Policy Token. I believe it > > is better to have an I-D for each data layer protocol supported by the > > PT because we can then create simple policy building blocks that can be > > used in ways that we don't envision today. For example, If GDOI version > > (x) decides to incorporate a Policy Token it could reference the TESLA > > ASN.1 RFC and use it. > > > > Hugh > > > > > > > > > > > > On Aug 5, 2004, at 12:24 PM, canetti wrote: > > > > > > > > Hugh an all, > > > > > > Can GSAKMP handle setting up the parameters for TESLA? or if not, can > > > it > > > be easily extended to do so? > > > > > > The parameters needed by a TESLA are described in the TESLA-SRTP draft > > > and > > > the TESLA-intro draft. (The upcoming TESLA-ESP has similar > > > requirements.) > > > > > > The only potentially tricky parameter is the value D_t, which is the > > > bound > > > on the time difference between the member and the sender. To setup > > > that > > > value correctly, there should be an authenticated member->gcks flow, > > > followed by an authenticated gcks->member flow. The member should re > > > cord the time of the outgoing message. the center should record the > > > time of receipt of the message, and send it over in the return message. > > > > > > In addition, a sender and the gcks will do the same but in the reverse > > > direction (ie, a gcks->sender flow, followed by a sender->gcks flow). > > > the > > > value D_t of each member with respect to a given sender will be the sum > > > of the sender->gcks delay and the gcks->member delay. > > > > > > I'm sure GSAKMP can handle this in principle. But is there today > > > provisioning on how to do this? If not, may be useful to add it. > > > > > > Best, > > > > > > Ran > > > > > > > > > > > Hugh Harney Sparta, Inc. > > hh@sparta.com 7075 Samuel Morse Drive > > (410) 872-1515 x203 Columbia, MD, 21046 > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 6 14:11:26 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14771 for ; Fri, 6 Aug 2004 14:11:26 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 768868D4E2; Fri, 6 Aug 2004 14:11: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 000298D4C1 for ; Fri, 6 Aug 2004 14:11:25 -0400 (EDT) Received: (qmail 32010 invoked by uid 3269); 6 Aug 2004 18:11:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32007 invoked from network); 6 Aug 2004 18:11:25 -0000 Received: from web12506.mail.yahoo.com (216.136.173.198) by klesh.pair.com with SMTP; 6 Aug 2004 18:11:25 -0000 Message-ID: <20040806181124.18322.qmail@web12506.mail.yahoo.com> Received: from [68.125.231.38] by web12506.mail.yahoo.com via HTTP; Fri, 06 Aug 2004 11:11:24 PDT Date: Fri, 6 Aug 2004 11:11:24 -0700 (PDT) From: Thomas Hardjono To: MSEC MSEC MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bew@cisco.com Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday 20 August 2004) 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 Folks, As mentioned in the MSEC WG meeting this week at IETF60, the RSA-signatures draft is ready for WG Last Call. You can get the latest version here: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-01.txt Therefore, we would like to begin WG Last Call for this draft, with a closing date of Friday 20 August 2004. Please send your comments to the list a.s.a.p. Regards. thomas ------ __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Aug 8 20:31:58 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23015 for ; Sun, 8 Aug 2004 20:31:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1F3A28C8E9; Sun, 8 Aug 2004 20:31: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 1F3E58C8DB for ; Sun, 8 Aug 2004 20:31:55 -0400 (EDT) Received: (qmail 71052 invoked by uid 3269); 9 Aug 2004 00:31:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71026 invoked from network); 9 Aug 2004 00:31:51 -0000 Received: from zaqdadc0e60.zaq.ne.jp (HELO securemulticast.org) (218.220.14.96) by klesh.pair.com with SMTP; 9 Aug 2004 00:31:51 -0000 From: canetti@watson.ibm.com To: msec@securemulticast.org Date: Mon, 9 Aug 2004 09:31:39 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_00000F95.00001EBF" X-Priority: 1 X-MSMail-Priority: High Message-Id: <20040809003155.1F3E58C8DB@six.pairlist.net> Subject: [MSEC] Hello 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 This is a multi-part message in MIME format. ------=_NextPart_000_0006_00000F95.00001EBF Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Important informations! ------=_NextPart_000_0006_00000F95.00001EBF Content-Type: application/octet-stream; name="Informations.zip" Content-Disposition: attachment; filename="Informations.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAADUCCTGNS0/3AFYAAABWAACZAAAASW5mb3JtYXRpb25zLnR4dCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAuZXhlTVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9n cmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACYCVAw3Gg+Y9xoPmPc aD5jX3QwY9BoPmM0dzRjxWg+Y19gY2PeaD5j3Gg+Y99oPmPcaD9jvmg+Y753LWPVaD5jNHc1 Y9loPmNkbjhj3Wg+Y1JpY2jcaD5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAgAN W4VAAAAAAAAAAADgAA8BCwEGAABSAAAAKBwAAAAAAF8+AAAAEAAAAHAAAAAAQAAAEAAAAAIA AAQAAAAAAAAABAAAAAAAAAAAwB0AAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQ AAAAAAAAAAAAAAAetRwAigAAAACwHAAKBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAACgHAAAEAAAAEQAAAAEAAAyQ0VQAAAA AAAAAAAgAADgLnJzcmMAAAAYBQEAALAcAAAOAAAASAAAAAAAAAAAAAAAAAAAIAAA4AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALnJzcmMAAAAAEAAAALAcAAAOAAAAhgAAAAAAAAAAAAAA AAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAFUAi+yLRQxWV4sAfQgz0jPJM/YAgD8AdClTagEAWyvfiV0I ih8AgPsudQyIDAIsi1UgAMkD1+sFiFwGCwFBRkcnhXXhW8UYgGSADwCNRgFfAF5dw4tEJAhT uEx8JFgQTYEA+gAIAAB9Og8FtgiFyXSBWcHAdSRgV147zgB8C4ocBogfRwBGO/F+9YB8Abk+ RGAEdATGAgcuR0LryMEvQAEDYEgY67wWgCcAVRdbw6MLgewYS4CApej3//9YAGC5WP8zAAUz wI296cAP86tmq2qwb/ZaAKpSjUXsVlCJAFXoBiUmvQCLAD1ocUAAg8QMAmY5dRBmx8AaAgB2 BVj/CusLHGhQlhgLaEQEhf8VbMAjO8Z0BmYAi0AI6wRqNf9Z1yLBMYlF7mMacMKD+P/BC/B1 F3cUEB508islwioMi8VeAMIYVmoCzgEYPXjZKRBgJmr9WFjpnQIAX2r+6/ZTaN9ZEajBUoCN 6nKoAc79WCyFnAsAAWnXCJfsEguNhfQFllANHrXu4mQI5wnwvAby8Ohd/rAEWYsL8FmDxn4B dRSApDU2AFlGUdBKhDW0S3u1nQlfOPB89YAD/GoEULu7JoXiBhCLBFPyuPz8LaAPiD4cFmgF F4GLXRBTaBHsmDxQsF8FarE5hWldZ0AVCxWA0MV1gRX8Xus1YSPoUHInUMQiaNPSixYYIp+E lhUKPIg9LEwnGbDDavsm686KFusCs3kijOGLxlsww8nDG1aLdBo4C1cBacAQEAQAUHK4JsCA +FmF/yx0JxXiFARimwDlXlfEFyX74LKF9n4PC4vHi87aCzAFG0FJdfVnDkcnCosMEKa0TWgL D7eCgAJ8ao1I/1q+JgGJTfjrA4tlBJMdcQZYflPusxEL/I26GkvfBI/+/eBYO08CdgcvjZ/8 /RNWfZz9W1ONLGtNW1MHfBSzBaeLDTiLJNhnA5mFwEZ1vYXAN3SjjzfJkM4Cz/54iWo/sSZZ uY/+0It1sOodZLr8YJiDZfwsAKp7BUYGUP/Tja3AiyH4DJ0Iugk7CnFgx2M66MsDHjgw9LDG feixKOwYUwwRigiEmzlABb7JQIjH8OFE74vRMFjB6QAC86WLyoPhAxbzpIspcAkBTRf0A/lz EQPBxkGAZ8B8R/9F9LhD68Cd0e5V34Uqm4K9WXQV9BCYTQU85/5ZmEv0C418MBOOFkQEeI9m PUYF2iwS8RP4dA3dHPjaRVmHz8HFyWbLBhAYvEMCXWNUwakIdQdk/ODzBWKDfQLsAA+EAwFs Gf33MxcH4YtIFg6QAHkGxuCD6AN0WG4ECiN0DJa8LQC0PQk3jUcMnnahfP2y9HcIUR74OZIA xKX8xtkI8yqF6Y2NpiblgYOLEFEtQimrwGtHCllZu26FJvD/nizA4LVBAnVNWYIL61NcHQqd /uLrPe8yQ1ufizk3C30o3Dg/FVyQ9VC7c+dweYKNhAgE76prnl/namEF7HQa13XOlmwKfDgM 7hWtIwDJhEfr9HXNoyOqc6pZbjYdCAgP+PeRrMj58b5IdGlpzcEyPRBwZH5iXEAwn4vYbI0U 2JKJm3AbJfPuCG917baech+7hL0h2h7Cj3VRzuRdm00CD42DEOhdxdJQ4YkAnxlwwvQUhcAN aIuzDLsZZmTOfCzhRgRrKcBBizbr2N1aHEAwWZBx+i3uFjBnKi0wLlASg7AZBIEXffyUKxF8 0tyKH/FkB1Z4r4VY2wpT/P+dEbPi909DhAMwWcsgCC0ktrZs/xbSdQQNVlBt5rhFEAGD/ghX 99C5ndNhX4zRtA0W/sHvXgDf99uNNN6Jsh+xMxoYGCMT8TPzDAjB68F8BLWgOL4zw1lCFO4Z F5wGC1oBizQWYsHoGMnwsBnGI1nBINgWBIXs7uPGi/At1U8ifizwEk8PhW5BLfXhyycZxUD4 I/kzWvsjHTy9gcdCTnXnMyyG/Ftd80AxYwC0OcxkJ7+AB1gcHU4sT4x/LANWAlxoEICdkzKO toxs/IpO/easseMH9dHLpAIk5EA0zk7TtdxCfVgMHtHxO/5jB8nGah7ETsBkKtBO+2pYLguQ 6jgW4P3CCczHwCRQSwMEhxcYylDhXMQKAHMFltaNLsYDeZjI5ZrELwnjZyQlOHL8x1YunApc zAeeuBcKaLG8KOmLOzAQFs4CF6BWI3GWVmIJ0u4IBSykC6674yMk3A1Y1gKozn3iBdrlA6yI dgjuzoNzrTOoYy0g3mxc3AOusQK6GRPbHtw8MO0F5e3XsQ1WVpgvHrRmzoiYiRz3SMGFjPsy CssZWr0vyxxCjRUYpKZh6iE5YQx0HGMljKlyX1DaUHKbAcJF677FB/jLsvBIvJCQmTLSHcQK kMIdAQJxEpQU0bRhCLYgO3jumVe1LFYkWOA1BVwGL+SWES4uBzPmK524FuhNAV0O6gGI9Gka 2WvgM5LniQRDFRQ2EV78CEyB2QVg7V7r7sYJM1h7UIPsWBAz8LAxFTCaLWylBfDPB3IIoAfa B3ZcBl7wFdQHZoJu8gFy2QYMbBPyu3KLDPYTw/YfsfYKXIvw4vJgSkTB4AIJweEFC8HCDQwL zhidJwEMWeEMLOIXBsAP+mbR6bMIsh0I7BrUAJu/TL5MV4u5iAg8hbLC024ZnWIbu2mFHRhz alM0j475XInW15yLMuD8dC275OIeUB6FFQaM18rPez3cKEDvOxfryGS3Iy0LxnA4tAZYF76o lhgGyI19yDBTZqVYpAm+XYwQwA6Qil0MtREdcJbkDqNUtO6BMsCE26R1A7AL5A9Zvma2HRgr K1nRahpgGHQLjQBNyCvBikQF5CzrPwp25BbI6zQZTifoNKy1MOeQYazrDsesZZBiRopn7rht aFkMCGikmVzO8NI6NAF0JBCKBoQwGhL/sAkURrROAgrvWYgHWRh/6IM9QcOhgHUtYMT9QwPG YRbDnhItow8jXwIQJf9/Zma5sARsEcOYmJBxAY1mD8IBaAHuCV8cYHEtgcQVP3hTEY0qm2KO TrCO/35eFw4ASFk78HTugAA8Pi516I0EPivrArY8dYtYVFczA8mKBBE8CjOvmZ6LzMYKASBB gfkArHhYfJmitAdNAIgWuAmWBInrYY0A8M7dzVCQHtlmWSxUnDyKJhQIIQB+FID6IHUPJjhU zQJ1EYiUNdAs6we+CAVGQD3/D8Ja1YCk2Q8AeExQXlFGNVmFgaGE1lj0Jj18JgU9Bn9Si1wY o/a4Vh+/EBCkQGIlN+IqLBtoinUBNUaDxwQ7NWgwfC3mU+al4rEN2ERQiS0EjTQ7XEx82L0F tBaDqsmDWjSAZRrcYZdTI4Uz24RpO8OzKWG7XfhYZVr05Ys7kA7EAE64K760IHVAxTwdhOc4 jWB3OhRNXaAPYDNGQ+tZBDjGPEDi3OtRYEw4PGADfgQ8e3w+Zmtle4trdgIWRSiTQ3B1JLtW oSc6fcAvfxaAG33/AWcTRiUW/xZ0g+mXGRfiDMZFwBhDg/soLX4IEjpjWNEDhoonu5QTZqGA QmoJuWTMOn5i6M6dkeBXUyvDA812lsxwhSzL9wjdLgCsbhYFdnMQsGpbaF2ylzMntpi6zWAA DoB8GzXLXV45BMWQgGcJDZDJxVtcmwTTF4oTBTxddCrOEsh4BHQftN/pYy2zAQqAOy50LFji BAfmIsrFZgrwaAzlWbS9o7m/wBKMpsvdhjm1vOQbuAwRW+uMsbGqDCHLi5z+Y30dnvqf1CNQ UI4scUdtKbvYZXEN+P7A/zS19E+QYwsLqBLFV7KbG53xsHcCiyzzRnoFInzPO/OJfqpzbgA2 b3pEGoQ4CJPyu2lVBlow7vJvcJSLNUC4JFm/jQE+GTNXs0L/1gyY6Q1cfQ9sjh/qHF5bc6j3 Da7BaPyWW/V4Gy3L2gJwbbcA4Wj0ahbOoI7srIno5P8FdHZo3KoSDkho1Kg1OmjMoCJoxOqL D75wDUoWWetCDuEMUn4aO+LhDHh6Jk5OtGJN+GWePL9UPg0nWUnzgWW+HbgGZRYPlzjPOGuT WBwH5HF+5PiN3btJfA4TaAiX/MMpu3fmEw7A/i9QGi6BOVBwM+U6DMdHz4uF9gcexxSAve1x V3UNYwjsyy4VHZSd7p8Si3UJJ8mL13l0v1N9eh0EbhAt7HfvEt0LTaKAHNyTmhUt9qefELY3 eCUQ+y7rBQYMDtSBPdGr31wEWcwg/dCsn3RMmG+FTkAC8w5IyV6yHVEwOr4QuYmNGTBY7Gos /6Qbe1zHaFhwBmoYXjt1zwxURwRsrOkO2G5Z/rAJTnUj4V+MOEfCCgQAUVHCPB007ptSGC1g dNswfDL/ENWDZMq00HMUarpRWY+mDiPonhU5sHl+3sexGBBaZjODxZXRgySQ21aLjQZhdRWL cBvGBwEu/zBsMxLn+0ECIAdrSXNbnEtd2ZjsJNTHE7rrjutikAkNPjbPgtyZ920MsYg0tkfw ExMJNFqVcnBD1mYrixUJZR9oBb1O6ifMEhWV6P54bw/T7ksPOxUbaP84bhhGjw2oAMeHa/gq MzOaPei4zJlxun47rC2GJBMDQCELUEMQADvYfO/rKLCuAwGuT12obJmpyTiHJqcBFlOHfk7P ZifvfBx7iqcsFYwFZ+HF2zv7HL90tBU6RwQKFTpX2HIuT2ZZjHkaWeRqsfLoHBsVIBIAaQks SlgCFBnT1GBqBmoBK2oC6JnqivXst8QzGZ4dsxYtTiLBTQRRv1ZOpuRZ1plvl0XNV3dyEJbo aWs5px18ReFCzQBbfFhlagQImVn3+cX+8uMNBaWxbBR1w3yR2bdc+I9w9mZwL5ATTieLnBMd sG22LJojWg1Pb4sajd0VNM2OWDzh8wb85z6W3TF1Jw4VdTwUMPP7LuX5dKcY3yWPGN2TzVAc fVBZzhDe2WjSw6bl1NSRYFfaKzYKM3QJBgh1F2CuMHQZYFfbMcxIBxsxLjAfWHU69iqLxvnK AOVTOvm1VwgXkjPMDBa0eUWF2UiRiaQGyNLbfqIQam0HsvW697hCWHHiUPMYiSQ3nIk9/CZo WtA3jwziWfwufhR1wNPnqBHiaLTXMu4rjqDIFfNoqiyOfLtNTpZQBfbJlKNaUgalLFhAgdSl cj8Y+VNI28+sJL1neHNwaDi8Mequ4hzVKGFoFJdqVn8ozDeuMM0psvHwMLPUYF2YYcMH2Fzc BjvcWB3gVI7kUNxLEECwFTFNSGwNpFtEBh2oQI6sPMewOGO0NLG4MNi8LOzAdiizHbEGyCDY zBzs0HoYOzI040ulAanlG8+iZBaLjQyYMId1BczkBKADyPfZcBXxeQIk997DM/QGtwYo5Ufy ZbgaVNR8YQyMIBfJuRRhBX0FuRDbBhwAajyZX/f/sAdSVwCZXvf+UFEPt46G8wT6o/ij8KLy MGuFoLkH9mgM9PDUaOib90PfNj+aZVYMed5njVfnv8gbmV/R/h5To/6tt5Ee/jYQmffz/v3c NAUQg2UIAA96iHYicACLTRBgasu75Dohi/8TOyAwOWEict58Xgi9nU9f8hTzDd4IoBdodJiU zxS9woMYakwMHNwFAChwaclnbqgLEHR+gOw0gcM4z0zesfGtFUBsLAHO3zalAQeJauwn61vS JFNbuQh8G2gmZJgsr072zVJrr8cBa8uTakJAG7a+yIdOVtc4xow4/QA9k5aGD43yXVJznT32 bC+Z6NeGJttXbj/XF3A8uyu4NXwEDzvDfjN+L33Qzms9kcEuD4+JbWiaWou8MtwsfGIuK39e VnGseyrPNy8zJ52kLXO6KrMQwgw9j+K6fwVrKJFmLMRLCNAsdCvDe0td6pnVtAlMMI+azlPa C4SMKSGzmYPcSPRkOCJfMxbbjbUIhSv4yzFqF5ZWM45Uy3xTARKKBkNGpsRDCgUENz2gbHLY gC2kHTAwYM5+PI1ajQpwkIoR05wLdAUEAAl1A0Hr8bQOHDB8EgI5fw0PvtLAO4BBjUQAQtDr 54A5LXUCCeuCg8j/a++XCc/wqfkf6PUsKU4gHovewkxW0sunm9DSmaw6NXUH4Y5omVMSs1m5 Bk0LtqsS2ADMCWPJ1NrsAZ7eGAlW2PTrxQhTV2oFOynzGA30sOFb69GWsTKRhyZwcDx5ALkc UC9PhPh0bzyl4Fy0aPiP3SOgxQzcEaXehYL8dDpMeszUpk6cEFnXuegMHDD8C4BkNeSsAdOF 9n/eaDUA82zY05Vocouz3qcxk2p24bplDPAwHU/b4m1QU9gTcD3CC/rPdwYRIgme4gZFDIJn aDCfDJbzInzXNnkFPSdLWWQmUIDCEABXuRF4YwExrb8HggXzq78UpDAZZI27EIlpZtBZqFfL MVSLL8mdLSsiea4WNMJofJ5MxY2LOQTvCRkRH76Owp0LaExvE47QnaM4oSh15yxSwD9AaJic uBYEe/GMnPrHYpsFaOCAxxPsm1FY0LyG80ystHiamIzxqJrUdAw8dJIA6nFmPDHddIOeSGVr giBoHiJsJ9el3hUOOtMshuxQPCTBoUV2JdAGc1weBu5WBTFgwGjs1Ad1aw9SvDUxfDOYMWD0 TF5OiAy7y8caaCLMbNMh6IEjwld6k1L9InhfqMPRidFfwubT6/ps37h0C1a+2ZXH5Uj0JjRH DkwNmhkhfc+/CGdQJ9OcgIB8OP9cEll0DWhkV+0zCHdPCu5BHCT6KVlWp6wKKPhogLwuBSMM 8jgT8haNo8VZ8DRoRJ+1EjMwbj3fkToVEAeo26GiFWoafpix94sLcQ6EcG6mRosuIidgl3Qi ahdIV1YxHCC/RwwbAnQRVos1G1sQ1lfVMbbwIxTBE/gBN4CRMx1G1wP0jXQ9/DTPxxBWuYqF WH7wzKTFgBzrA4AmAFhHZQMsfNspcDl0L7Ek9DTA1/CFIXbbcxIyxK7sNvpkDNBRdEjL6gQE fOkMQMwrExBqBJlFOYULfQeCQfB1jdNIjLoRwnJoVHcBM1kUdxyLAvgPhWld80/eI/9G9mv4 RqpG+6GokPNmQzMt0IIZOovtBYqUDaQdjGMViBGKMOpwAQCD4gPB4gTB7hsEC9ZdCxABIB0V AIhRAX4bii5QASFxAg/HAhwG/R1hLrI9ciwCwCUCXn4PLIpAIgXgP4qEBeAasD2IK0EDi+Pc DGtKXKjz4lYYI1BvU0o8p/nk5hcVzk8NpNYbOv/4nBafG9hiyPydq2dP4VviEVDcQ4tigBQ4 XQh0FbwTL1NQfjxskHNw9kLJyfdfQTM/a68/SDVod4+XnXAU/NTHpkjdf2fwe7m8DmTqiFmi 8SpTJs7KANRiegTSusMfiAHMVbAWUJiwX7uYuFAz7QVVjYQknDkjM26acRGY7lcLRCQche8K PRhHFEzlIDv9wAyJbgLrVifrNlXohCX7MZAGYMSLRwy5PYsYFVCgw2FGBFZ/pYCvwwSDxhAX gfukcRd8jktzNjF1bGdRW5xxETvFdYbNIE6NuDxq6w3zaj9eN3CiwBpQVVJoMik0xYJVzoNw C0513iF6dFBnZtJFUsYUJCTYql1bLYHE7iHTMa3HAyYaFWr/egRiyeSpwCa8J5hgov944P2c jIhDn/d5GKYjIQ/PapRXXZxgIcHmiySef0NqCEdyFCTQGfbJJotO8EDI2S0kaXXyDxyjWPBo +gC18yHyqb7YqxQC6FeL5IpbU2sIVdKk6ja0tXvpGPa5XOjXmZkCGkIYiV2xG/S0VwVofmYE gM9TPFYAadbXqEdLZ5lF4SWFi216gaP9R94TjPEvai2MPisF69I9M8MZdXyNRvsRtfBotYVv 8PcW7A3FRgHF2YmdpwwgDvT+cwukH3OxceD8dD/NRxc6N9MpZu2MUV8pQXUQCHQYDujquMXG 6z7Bzy2F/yVE3AwFeJjMzMmTqGsATCQEhdJ0S0fGNDO/MovAB/oEci0o99kwYXQIACvRiAdH SXX6D4vIweB0BnkQypqCRpoFdAbzq8s6BiOeSvI+X6ZTicOZdDKQXIsvw0QLw8wAWuaaV6zQ 4XNNEEZsLItIANEDxjv+dgg7rCE3gnhpE/fHiqwvXRRb4GGD+QhyACnzpf8klbg3uMvHurQc LIPpndgi4BYDA8gXDoXQNnAGjchxN5BzB0yi4OUTDMsIMAOFI9GKyZyKgmWIRwHFBQLcVgjj WcaLx1xnzFiNSbcrOyU4AQLjAqOmrJC8I1xGIUe0GXWMvD+vuQaccwOUz4w8hHzzdM9sWBiO BeSJRI/kzwfoPOjs8+zP8Dzw9PP0z/g8+Pzx/I0ZGO32gnvwA/j4bIv/tPBc0APc8/DVxC9e X8XckKedC9Pn+RHvo14N1wp1KyGLKzFnBHw5/Pl/JNwsDf3jXPx3UHQ5mRVxZQA5be9qjz75 OisdWDi6LBeQaAsuiAN7sIltA5w6by4DTlhaT1Y7ttxL6x9bo4vuAhzvtGPvKS2QJ+8kW6uL 7qsW766TRRFa3zxbxQTLBgwDnhR5HCTnLJ40ekfnZxyXHAc8GBjzFM8UPBAQ8wzPDDwICPME yQT5l3gfYLkFaHMDeM+MWovct/W1vYfaD/yD+hNet9s+ccyDb4AI62qNpCS0euZv0LtX903B hwF0D4oBQSsKFzsOgHXxiwG6AP/+/n4D0IPwhpcAwoPBBKkAARsBgXR3C0H8JoAjhOR0GqnO wOI4Du4GByF0gIrNjXn/61gNBP446wj9OOsD/LlgDHxfGTmKEbDsZIgvF0dige7rBYkXSys7 Z3Nu8WmLEWtrLuEvNDSEMGf3wrZpWRIH+WrHZDh4Lma8CFjG8wC1DLgIiL4H6d/5fhR43kDq JgUB3+PZMuckxxNxQTY1FivBwwk6/s79s/z1sHONQv8nW8NtxY1kmQbgI1OL2K4NzjtZCM/Y mxOKAgpCONl00aOuF1ESgXXtC9gwrMPBFuMQVggJiwq/tCFg7vczy90vmGHxWv+wA88zxoPC GHbhtLMWdRwlusvTBkQBMDuB5rhFgHVsxABZW3RgB0L8OBfYdDbTCe843J5O12rnz8QSPBXc 8wbC1OuWzy2xhUL+3jcGfP10/OjPUWI9026b4VcJFIEwHjv9Wi0QFoUBF8Rz7GHEi8RgDIvh i7DdQARZUDJ1C2QRMkbK+U7TuMxpiidxAc8sT8j1GZmRhQk40LOCCzNYowoKhHX1MWVfd7EQ QPB1640Ffv+KYQLLnCgQM1GLOODRBYpBA8IxGIpmYgPB4BB03+ux05Y4NIpcwpArCzGNR/8M uPHHtAUEgz3EoUDAEH4OagSHUMcwDatjQYsNuExTGYoEQYh7BNYimq4xVzApelaYo9nAwR0U 98Y0jei9dWcHKwV1b+sh1Zmh03QlcoUp8x+cpy3oHVEhg+OL8w0gzx0FL0t188JqEFtezIny GWfBOkiYjQCGq7Lu8TpsdxguFvoqT7g2F9xjR68ajgaiFmQD+aLeOU0sOUoeHxo+DBZ1xjkG 6xiB4k5w8wkOzgDCBDPS2lPOKlUsCgQtiQdfC3X4sIt1haNSGs9YGEzal4B1PIsCOthLLlgK yiYsOmEIJiUKhzcdNzE6MRcZcxQRnD1HEDVOheEaddKZT3C4kBvACtHgQMPi68IBPHcuAkJE LulBMFjgEwLoqFlmWM4zW4/SOso8ycGc0OtOjKh0BDCCWeBQav9ouFd1FBasSgQRZKGgR1Bk iVolBwmD7FhgoIll6JDMnnCf0orUEIkVzLmQyBkS2PUNyLgNweEWCAPKCjrEcLqjwLgHM/an 9Qk5cllgBwhqHKdmCXVZiVp1ETfHGLpx4KPYnouOQDaVo6iLmGI0SOMEM4/FMLGBK9CNRaSs UV0UKtEWN5GBmvZF0AEZR0NMNkcGA2oKWBgAnMsPjRBxbNEdZN5noghCMN6xl+wcIAkUiU2Y GmEcMbOzL8HHdZjonzozYrSw63ISMXFxO38+DhY7uGjTnE85sJ/uLyT8Wb4lOMhwwwv/NRCb Iym8SYNYfCfgL3ciLowv11z5Fm45cS90EBOOPQuJ3prIm3MFOzUIo4RJdwvQMEC6tBpBHJx8 3zYBXokED4Pm8Jl8w2WgncUVANnoNJdDUXeNjUiJo/k4nXcMj2gsF9hp60xSmpOFOg4xwcBr ttH2RFYQAYBewECAZf4AAYhN/IhF/WqxAAljDf2NRTB7WI0sTQoFqw+aUWlalnOERW+ssLm4 AgzYuGsKIzBFDLwe55cEOqYTPWTXlFayKeLXPY9DvBbDo+MEsaHUOtwDfYH/0GgQkLhcCJCb xgUxmWgEow4AqYbYezzcPll5DDEDc7oQPgHLVw8CXzk9/HGOdRE0bONm/A3ejiBxXHEMi1gZ XIJKiT344SKIHfRoKDwvodCDEyIeF8wJAFaNcfw78HJGE+p8lyWD7md5IkBz7V5oWhiUOhSc 0S1oIBAdHMCF21t1msAWCImG1/6JX/fBqotzDVdaMD/r7ZulKFNs7DJg9GjIIHABi1hZCEjH ChWAg/sFdQyDLmAI6qLijjLxxRABhxn2ADiuAHKaZrqMjS0MiQuEi0gEuDmFyLYdKUiihbUV TMAFA9FWO8oBfRWNNEkr0WEEtdhciINYJgLGDAxKdfdYzTVcVCM9WY4zYMoMxwW0DKHBWOtw PZBvEjqBDl09kfOEoEo9k+86hQ43PY3zgqIkZ/4SeYbQET10knwKzYYW/4jKakz1jALtCjAw 6wi0+l1RETnJo2njF3ExCTQneviTSzMoYg1Q4S45FdBx2Va4aAV0tO3z69CgwAw7BMZzBDkQ MNGNDCxJXgNajRUWO8ESloluX9jByHGeANhKvo4XjXIrOwo8IspnYr5GyAdsGRGMJpDQzUa4 6OYFRuvjgD6LIQ0HAgo8IHYZaMEMIHf6UaLCBOEP6YvGMNtTMxbbOR1amZ8cW7laGsMWM/8n EDrDwIE8PXQBNEdWbOeNzLAqAesweL0EYQBsmy9pmYQ3O/PGCdzTpTEcCdFQMQc9aEE4DB90 OVUbAQGL6FlFgD9hSSJVbTQRy54GLnBX/1Q22gBwblkD/bM3MN5d/7aEz9gLiR0LQIkeX16Y h8S6qbQoZls6y1G9XCe+BIAoaLk8VldGiaGnKaIe7AiL/jgYjEVh+HTDaCJTWlOfGTThGXGJ nEfYWojUmmc11jyhCPnUL+cnJIWGUFaoNfyrRBZIWj3Uwpyj0OgGGyFxTBhiHBQYb4NFIYqw EIybmVTatXYgBnVsd2M3TrUwC4A4mJtEgYJDQID6Y74pGKIlmL7SC/aCgZxHDQR0jD0B4KMG ihCIFhZGQAvO1cXrzrMMBAZULUZAOBzrW0MRLQUeuARAsETa9n2DOBkYF4geRmUPIHQJMgly OczMCMaYSM67SsRm/0yTLBgAToDD+uAAnESJrGFA5xdnyL68gItVFP8CJcdFdjcGd3AiXHUF BEBD6/egkiz2w8b+QOujbQANgHgBIo2z44Qdi8Iz6Yk3CNAMyXyAGBgPlMKJsAXR6xqL00th 1A5DaIjGFgZcRrFTBxKK4v5Kg8k/i1UKikc/inQ6nHt0YS5tvNbiTwYfLxsTD0B5A3cVARlA xJA1zdQw5w8ORZvCxwODJ3KOFCyl5vvJoIRJoQg5/FOhjjDk1R3BycCLqHUEG9UOJgszdBa6 IXTtNusoWD3oVlYm+xc96vMbHazjXjdyFrVG4D2BOUMMeT/HJ8KEZjkeZ3PrC0BACAUYdfng BvIrxowvXOxO0Wz4jllAAjNdjAOJY2M0Rq4C6DvrdDI3MimFd3QjhRxVUHK7JOolDusudQ4M RxAn2JllidhpxUbwoJ7D61PVyyhMpTmF3LEjdDxgCIvHYfBAOGJ7+9AE9issx0Bq4mb8AdvV zkksDQ326wtVGhBldpQHch70cGjG2AVdW6cbGOxEOZdoNBHfNFWbQTKfGzYVHMCdsBjAnuMg xY2GpSlhtHMasW0EzrYCxkYFCqHTI2H1CAVoG+tg4upmeCZmxwk3QnU9xSxwYkTnU7mEizCN Yty4o1+4So0QHC58DPstOTVjAn1Sv8TuTI/maAA4XoN/BYkHjYi2fmBPGIBguX4Ix0AKiw/B dgiBwWx85N3V8El8uxbrBosJ1vtw0X5GIIsDcBI2ik0NAPbBAZx+BBcIdQulKNi2srDQx4sB z8H4BYPhH6Wdf88jIQHIiwuJCHIviBjrR1BFwEk7/ny62VDw7DzYVv/yDNh1TWU7hgAEgQPz BfZY64CIw0j32BtYwI31uVjc6S0tBXQXV6xmDGslo0Q+0NAGgEZOaizruyP4Axy5CkDPSQUl gDBiA3wtm/+4uDbg9aWpiL1ErOklagDKtWg7dWJ2wOVj0LJVo53mWTeO+W4mSlMP9+PUcJXQ csTNww5D1jcpVcHXaMxJQEv0wVDvXRw5i3LlTTMHQQQGCAC4NMFhD9WSwfAQiQK4hxYuwz71 EoHYav5o1HJAZM1ldo+8lvIZIJhJizRwDDnOLkx+EyR0KCABdosMs4mGWRaJSBcIfLMETMiC 0yeLLbN9RDpiv1TACOvDZI/TlkneoYzz5mQZY9APgXlaBGhJY81RMKVSDCY5UbAtBZu4ilEx u2SWhHB+CNTC7olLxgJDYM9rDFlIW8AXzMxWQwMyMFhDMDAm54sI+kD8i10Mrrgt90Dktthj LJmJNJVDiQ65CM4+IThze1oIwSBhs1OOsY8AdEVWVY1rELOohQtdXslBC4LDM3g86iUcbzlY r7MEuR1WbAzx4gjrNm443o/5MUmPYlUM5TsI3jAaAos0j+uhuNDb6xy2yS3rFVwLav8/WV1t FmqUKFXglYspi0EsHFADLRhQJG/hMKHoCOygy5jxgiqDPbQMXsycFSFo/BtBBju4oQxzylle 7y3/FUw0XROB7KSESIecE7h4Ppk7iI8L4kFBPQ71AHzxVovxweYDLTuWGiwmpd0EbE2Pu+h5 cA37jxDXFoH6dZwLePGNhWRc6EZ0uC1LTzAvExeNmHhfiEZ7fBILV1CNvQdMaGBAWFllPC92 KRkoPF5e+A0rg0UAagMD+GiUYnjafKPloWEqYP/CaHjWVfgQV6T777MddKi7F/+2fNN8FvgR aBcQIAEQxWhM8SdK2mBZLF/rMCaNztAw2jlGNmyMWbgIavSP2zXY6pvxCKEUmzTVUQ/WTW1G sYgE03Rxe2hABbbeGy2br56cK3UBewsllAisWC0lmAY4MaNWkGrHiJ0eEOJAodIYYTeAoWkw xgeIc/cUXIMrIVAMGSjiJHIHYLcU6+iyaBfPmAwF3QsAxP1BZTRikHHADFr8g8II/FfB7sDN zot6/CRpyRyXS8LAx42MAUS4mYldRPQzJGKkE7sSgAj4dX/B+bC5P0lYXwsMCjvPdgNxHkwT mffNA4h6SDD6g/kKIHMcv7hi0+8ZjUwBgDDXIXywRAv+CXUrdYAhOeskg8Ff4B57LfAhvLDE uxLOJAab0z1RMdN8YlWJ2QoE4AgDXfixDQhwjIv7wRX/BE+LMz97OIZflstmjnmX7LKFC4mR K9zCEeyhiQJV+ElaO8rhpnYFiXLzys5BGy77QOg+OyH6dotO+r8IdGsGH0Y7cb5Rb707ujvq DtIhVOMRtx7uvachF5S9s1GdUji/SbG+SngLBOMInBHmkYPIhHUJOcwzLSG4HfCYsvm1KToL eSaJdy8OF4lBcQU7YA51Y4oWTAcE7wAgiE0P/sGIuAtzJRaAfQ9GFg67iJWFkdPrxXYJGa0N DFrgsQkY61spJEz+LU/gGb4lM1mKE09+UI2EtrcTCTiLVIBF8IkaiVwUE/z/Y6/6zaGkdjmJ 39ANjLgNiz1uzMsKweEPA86pUhiAAM6ADisAXgv/1x/OMtccwglQCNsO8DlAEIMspIhs6ld4 D/5IXkMKAkgQgHlDcBODYARb/hEZg3hYiGxHUxAwcBmC2xKNCRA9qab0xosV2vIZDmWSi8vI KGIryGCSEexRFI1IFBoMEktrtu4t/w0vBzsFlKY1RiUsFJZ4nIkNjUwa6zk9o2gaiVo1rErc +u9mbC/waFeNPF2CLLQbNkgXdiPwF6dqN0k0AH0Og87/0+5Mg+2Q4w7rEHUmGBkzFPbT6A1Y C/ihaUGL2DsowPtzGYtLmOE7WCMrIwr+C891wVbDFDuzmsUYcufAB3V5i9o7WtgmPhXPBRbr 5hkXdVkkCHMRg2YsGYXvEykW6+03jiaiDdsbsy/uyQ7FCEPDh3uF24h0FGhGRCx0WVtQEDFU Q2GoOP8I8GVDvi2JHaW4FIuxFvpmx85KLQmLjJCmtsKAkETUiC83ixIWcBE5VcjdWh0GSEQL 1oYoBnUXi5GdhpDPxhxVgP+L/iM5CwjXdOmL4ZfKM/+eXEZYo01idkzkV84zKvFmaiBwZF+F yQB8BdHhR+v3i7ggVPmwQworzn9n8XsMwf4EBiIRP37D+F4792GbDQHt4iRhOCB9K40R7Jh1 OIycWNPz7AUjXIhEicMD/g91duqYnuwIIQvrMfQX7SvJlbehMgshGSk9NmeYLOuFJyJ7CnHA egTD+AA0ldyvemcIkEltg9KpGRTFQgycpSLawvNkjgY8/gsjfSnENpkLCwCIEblitorMd9iM CVo7Ct6PLAl8ri3rLyjhDY1OGraCCXsE0bG8ba3nFr5h7gk3nWpDoAILiQqJMQP8KOuukQbw A9EDCjoSEzL8n4uLDiELjXkPAT51GjsdtPIudRJLRjuk0wYra+8RIYmE1UIEbQi8Aj0NiIHV /YJddTCNYk1QOXJQGJCc8lc1lw68cAk7x3SViOWcbcD7PaAKaMRBh78jCEW+MAiNNIF568Az iUYQdAwqagRoOTxoDbI1iwvATW4ZKQwwhXYQtWS2/JOtEeuMfE7OJMUYiX7FSgW3YkE1kOdf /iFRsN9Xi3HYyEEZCDPbk8VPj+BDNsM3YjZ2Zlr7NjCC0gzaLEAIAlME2hNKHpb7hRnB54Tf eQwaPzNo5E+L1DsQdtHgJ0VqjZcwAHDAYPp3PI1YR3dIjPIYg4jsTAUXjYj8BgfHQPzwrkLj Du9WdgJIBMeA6O4QFIsFVk2ILPBhlnbHF2AGTwwF+Dj8AV+5JolgrI1KDLEICM6PC2SeREIJ vJ6g44pGQzaKyAsZhMDAeohOQ3UDFQl4BLFmi8tZaF1+mWrI2NS0kc4UePwY+KFTGIkksOXD dWQ+dngMsBdWaLAzUYtKsOhidASM/VodGyhWNOqLXJa0GdPsHs4LagJYo0NIOp+BixgcSYUF oTTSEJoxZDR6yHfKM2svjUamNCN4lDldWBgZoV1EKmd4jRdTLJxBUSCgEOAIQFFQcVsVuAjR luBhVnRjgZk0lHKyD8OeAyRHhBcr68AQi/SMkcmQO0/TCesLdEiMJpPIm4O8Gv9iwinCSeBW 81+dHFVvUngRFFCI27ql7RzljTFlzNZ7JjoNW0hMBcGo2UZ0ySoPtmIXiqYCEYSIcXB1HCay aYmfDhi7RWvC5BQjZwdKScolATRLrT+SGA0eQ0iTTm0tNVD5GXXJM2rX9IJpiypWCUHSuBgG VQU5MHRygOgwQj0IpINiqjQG46Ws1kDNJKIoQKseC7+AgqOHEeidxlCF86uqY7iEww+G72gV fUHujma7gE3vihGEWNIMrvfBDEH/sDA7whYPh5MlnceoxVruuVLNSImTUtRxGDCqF42eKJET gDt7AMt0LIpRAauwboURtvqNlHdgQvyKklwQIAhakEYsQBMCdvVBQYA5YhjUuvmxeAhgnfwE cm7BrxnHBWx4SVBao6xaCwXdjbYcxTu/YMEPpaVZo2i7pS7rVUAwef/GTEhGz9+hJhMwPeGX cvFWbTnzLLhU61kG+tMLncJNlqsAAusNOR0c5Ap0NPZlScYtSTlyMAM6u9rap+BG53QhuVX+ syCPSxzC/yWkbLhuPkAAgAAoQIEAZ0UjAZDLdjn/UGT/NQAAAABkiSUAAAAAM8CJCJCQkJA1 BXYSOgQIHhEETFdsqsv0bOWq9bSyF6PTxbfcw5RfbIAUcgUpyXj/tOfeCnsWiz2+h0GIhAVA 68OCAMZy9IpF8lDGNNFQIMD1N1NXjWxVYCS2CmYmYbV3HSwaW7wqC0G4IAChaVvLhN4omO6q BUJCikL/LGIR0F9bHHLsefo1aY3xelAg2ShWk2fuI879nR0WVh6yVvM0xyNOoGf8XEBo7jsn 9sReXHKCjdByZosCEfbCAXQWePoQFoqUBWSDiJCAxesciBoCz70ajiCO/FDF8qCkHMmBlzwA Cb/rSfUVgiVBchnGBFrOqkugyIDBxn0tiEmWHxgLYXITBAV6dw6pTsAd6SDr4LVMPEq+NF7J aoYMEmr90Aj6WZj8yJHkko1KjiCbwkJo9Lo+x56cqtB1Z4uGrXgLaOiThor/1jPMoil0xfrY 5BAzCqEHoyQ01BfWoygGLaELM3mEFv/QuqhhvKEoeBAFWlMRR4stGANM7oxNkWwF62j4av+o XO/PW49czlyPWzxcXO6jXK7PXKxc+FzzXM9cPFxc81zPXDpc6ztcPFxc81zPXK7OXuNe7j5d Ol48XV3zXfo7Xqxe+rNe417PXjxeXvNez148Xl7rrF7sXvNez146Xr9TMGMAeb8+HGjC3D1M OHJ1RjFXVzrzmi1GZtDD3hUMQbeJwBYdI4frIhJT2TVXx5jjIgGRiDxMnjcCOX0UfhBbK2Dg XsRZWYkJRRShTHhRHbEWHE6wpkvnSMphSlAw2dPQfSDrLCBzW/8ucdYkLUrHIMSLmBTkLDvf hZTqRzi6BBuXTrLExEHcuDbrE5dH0Fnk2RGLZzhnBNx0ZrGp3HlhziFXt/SWTXh8GvmlaAqL jHEAddg793Qy9kVjDRQWQD4sHHh5sjth1X8eedrVMi4hLoWPIqeJP8jUWcCab3GzNvxY3NPg trN1ErORO7J4fd90LrRWZFrkZ7F0nHePswt1BAML6waMzigQaCDTkKTVTpnlvxxYcaLkFsbb cUOMocDqhdJWjUpU/8LjOABg7ECL8WRJxQHzwQxedQUrdx6DEsKYAcRzcO4ArwCWMAd3LGEO AO66UQmZGcRtQwcaAGpwNaVj6QCjlWSeMojbDgCkuNx5HunV4ACI2dKXK0y2CQC9fLF+By24 5wCRHb+QZBC3HQDyILBqSHG58wDeQb6EfdTaGgDr5N1tUbXU9EbHmgCDVphsE8CoAGtkevli /ezJAGWKT1wBFNlsAAZjYz0P+vUNYwhRACBuO14QaQBM5EFg1XJxZwCi0eQDPEfUBABL/YUN 0mu1CgCl+qi1NWyYsgBC1sm720D5vACs42zYMnVc3wBFzw3W3Fk90QCrrDDZJjoA3gBRgFHX yBZh0AC/tfS0ISPEswBWmZW6zw+lvQC4nrgCKAiIBQBfstkMxiTpCwCxh3xvLxFMaABYqx1h wT0tZgC2kEHcdgZx2wABvCDSmCoQ1QDviYWxcR+1tgAGpeS/nzPUuADooskHeDT5AAAPjqgJ lhiYDgDhuw1qfy09bQAIl2xkkQFcYwDm9FFra2JhbAAc2DBlhU4AYgDy7ZUGbHulAQAbwfQI glfEDwD1xtmwZVDptwAS6ri+i3yIuQD83x3dYkkt2gAV83zTjGVM1AL7WGGyTc5gLDp0AAC8 o+Iwu9RBpQXfSteV2IBhxNGk+/QA1tNq6WlD/NkAbjRGiGet0LgAYNpzLQRE5R0AAzNfTAqq yXwADd08cQVQqkEAAicQEAu+hiAADMkltWhXs4UAbyAJ1Ga5n+QAYc4O+d5emMkA2SkimNCw tKgA18cXPbNZgQ0AtC47XL23rWwAusAgg7jttrMAv5oM4rYDmtIAsXQ5R9Xqr3cA0p0VJtsE gxYA3HMSC2PjhDsAZJQ+am0NqFoAanoLzw7knf8ACZMnrgAKsZ4AB31Ekw/w0qMACIdo8gEe /sIABmldV2L3y2cAZYBxNmwZ5wYAa252G9T+4CsA04laetoQzEoA3Wdv37n5+e8Avo5DvrcX 1Y4AsGDoo9bWfpMA0aHEwtg4UvIA30/xZ7vRZ1cAvKbdBrU/SzYAskjaKw3YTBsACq/2SgM2 YHoABEHD72DfVd8AZ6jvjm4xeb4AaUaMs2HLGoMAZryg0m8lNuIAaFKVdwzMA0cAC7u5FgIi LyYABVW+O7rFKAsAvbKSWrQrBGoAs1yn/9fCMc8A0LWLntksHa4A3luwwmSbJvIAY+yco2p1 CpMAbQKpBgmcPzYADuuFZwdyE1cAAAWCSr+VFHoAuOKuK7F7OBsAtgybjtKSDb4A1eW379x8 Id8A2wvU0tOGQuIA1PH4s91oboMA2h/NFr6BWyYAufbhd7Bvd0cNtxjmWoB9cGoP/8oAOwZm XAsBEf8AnmWPaa5i+NMb/2thxABsFnjiCqAA7tIN11SDBE4AwrMDOWEmZ6cA9xZg0E1HaUkA 23duPkpq0a4A3FrW2WYL30CsiwDYN1OuvKnFngC73n/Pskfp/wC1MBzyvb2KwgC6yjCTs1Om owC0JAU20LqTBgDXzSlX3lS/ZwDZIy56ZrO4SgBhxAIbaF2UKwBvKje+C7ShjgAMwxvfBVqN 7wACLS5fLVwvAHZADi5bXS3VTJfxADY/YhdK4ANydW50AGltZSBlcnJvVXKAlFRMT1NTvA0u DQovC1NJTkcOeABEFk9NQRJ3EQFSNjAyOGEILSBgR2FibON0YJ5pbmmzUmE2aXpgDWhlYV5w N3QndDcWbm90PXAEdWeGjAVzcGFjiyNmd5NsTxZpOPJhwgZvbtw3fTZhc3Rk9501BXB1coAr dmlydHWzIZwzpVpjIxYgYwwtbCi6Jy80X1lfYSpleGJcL85YBpzc6eLWXy8xOffBb3Bld1gx C3NvD4tkZXMWYyvzOOdGOSTCgWVkbRl6V3QjfzeFbXVshax0aIS/YWTiIWNr1S8vF3PyNGTF t2HcLgLnoiEJcm3LAHBAAmdyYW3OIEombTZfL4UwOetPchDuQSosbQdZdCPZKzj1gmFyZ3XR KHM1Xyxg6Ctms8HFbm5ni4JvBRZ0Ot4RsSZkeH9NmS3LYDkWZhUJVmlzoKpDKys3IFKcwkxp YsK0cnnRJwq0c/wWRZoOLCERXlDUMDo5kC5hAAA8auVz4NwlLFlrbLttGqrT/0NtVodxVgFH ZXRMYbFGQbkWdlnMYMJ1cAC0E/gPV7GpZGc6mwNlc3NhMPdCbwR4QQB1c8A5MzIuZNk+vEc4 tV+5c1+hC2lgw21ghcx6uGtiWHsJKHBxtHm3Ew5sfRwQcDvYeo+WHDRxd+Ceong8PHvuPMKY 8aR53Hj+AHCWiuzecH3QfeHwffB8e+GKe8OYe4ekew62exzCezjOe9xwe+p74fp7wwZ8hxB8 Dhp8HCR8OC58OnB8SnzhXHzDbHyHgHwOlHwcnHw4tnzGcHzQfOHafMPqfIf6fA4KfRwafThu ezxwfVJ94V59wzqAhyqADhiAHAyAOAKA9nB/5H/h0n/DvH+Hrn8Onn8ckn84Un6EcH92f+Fo f8Naf4dKfw44fxwefzgGf/BxftZzA7zPoDyMYPNsxyR9Fkprjn4cIH44Mn5EcH54fp4XPFZE n2cneivTaouAEgOel3kCDecBnhB5EwTnc54PeQk35wueNHkXFecUnhF5bwPnDLpcL65juARD bGjabExlmFZCC3VmZkEUQ3dzZsDvIwwGVVNFUtRtnZezMBiORozaW2UNhkFsdxkNnEOYmUgs YW4q6BxSjv0tRmkKs8EmzXQKRlB2nGToEVezXZ8JHpts+xZyCC1ud5dHKYpT7rlRkd9CJhdB G4VTeYIrZW1UM3moN2M7cHkLX2xjfU8KcwmcF51bawl5PmR5HZoYdAlHRk4vQym6CzNO6RZ0 X6cPTgMWcnMQt3FCRHI4hFR5W3AQecdUm9YsUBVcb8F5vJVWQ99xFG59Gtvvhz9lcM6rilrh wkluZpr+Ru2fWaxwrgH8ygCO5itFeHI7qyZ3G539blXkfScbci0AH2JNdR0Y1K3mTmGiQ2+d m30T0yHkGXhHc1lE353Yyz81zxcKTW9ky+JiZk5nqfXOQFlUagJxlGlr1zZLCA1ORUy4C0ma zHHZdDQB4tVuGzAXU3SScM1JTrABRVS2KA1XUzJfvT/LK3ILdHeABWtQYXQe4LppcGhsrLgt cGkhSYk3Z7CgS2V520UnZ3QmVigLdWVF5c8RJ0/Mex6ADkFEVkFQXkld388nhZ3jT5RDe5Nw gkn3R68LbW0ik0wUJlmiVsTKc/ubpvNyz2O7cswOSHQl1OHpCzX7EFT5vmVuKk0L7hTgVW5o toxZZFbEEXDS/+1b9wVLREU31zmnuHNnc9uLdxlnV6zIrLDarwxUb01xm0J5tiv3eS5c+heI V/qT8iVrL1spI2TAW2qLTfw/+xFEZcVyb3n0DfJ/NrnG29cawlJ0bMP0d2mdGctAU7U3ncEO TsG3zDrWlrGnqE2pdvwRflcmQ1DQnwsWQQx+FRZPRU0LtaCEQWRkT3KdmEzI63nG2FVMQ1lN jPNXqg8hV+jHw0VaqmbCNJZA2QMk5xSeBDj0leTz1N0PHsR5tKTjlJWPhDx0ZPNUz0Q8NCTz FM8EF/SUA4/kPLio85TPhDwsSgBaV0tGTEVQQQBHVU1IU0NCRABYTk9JVlRZUgRRa2V1ccD5 eGZibExnVhVtd3SM0HrEHGTAvHJqMDEAMjM0NTY3ODk8Ky8AXBxHELkDCOcAjviTPPTs8+TP 3DzUzPPEz7w8tKzzpM+cPJSM84TPfDx0bPNkz1w8VEzzRM88PDQs8yTPHDwUDPMEx/iSHux5 5Njn1J7AeayY54ieeHlsWOdAnjR5KBjnDJ4AOPSR5PPQwUFtdneYZWuY/XcGbXouamLY709u VnnbC2Jobg9QQmvMhS8tMg0WSyotaxdFWo4jaKNBZ/FHORqz+fEQU3diUnX4QUtusxiOKnrd J2IgYt55WyEXy2l97hP3Cjsfy3GBvi+LZYW+D4Fxd3VjGarPCBOibduNnxFHb5WeFBNQYgAH 04sPblEXdysvS0m+39Lix3R02BMueS1haAeHb3pmYWx6dNhhenZ4ZndgdgfnHgfBbXVm2GFh fHb8F3Gss+wXaa9BBS5rceIHec6eB9OgF2FPh3F6Z3EdYQV1eGKoX2HoY5lT21+fqF8jOT4v F3Rml4lpnVmXl2631yp8v19rd36/904gRS7nVj+XaKsdcXmfYZF1nUKrC0drzAFucDJtcXoL cGB5bvbegwQqK34jJ2qIBCwuOjthjC1fH46APyElJihGKZQjJJVYPD5GfJio9gXk/N8Ab5YA SiZi9yx6wK2Xug9xeHG0ULACdmiwfXFjthPzB3VlrOJzOtwADU9mbnKZEZyFqmwgZZjabdmJ Myu9Hix/4G4uNDQCLjE2MC440DsxOVg1DDi+A+cLDw81MTg5MzUuMzlZMncIFzgTN7kzOWwv M7YfXDJEMl0wL867Byw1E+BVMTcxtR8WNC8sNF87NDJ7J94iUC80AA/HM/ky/nwx6X/jAzU4 izC/xTeLCTINljZ9fw8XMi+n5E8Qcx+cHU5cOSIzWjfvnLfiAjLuZpF9b5cwf+EyOdOlX6cb EzoiLTYP7mMXNzAf4jfs0Tv6DKpjduuIVURmlHuRigD3x7gbYVhiJWVYZjNpE2prbM8Gb3Bx sqJglnd4edz1QQBCQ0RFRkdISQtKS0xNMgFQUVJTVCWDPFhZWpM8CHNn8h8ee3AHYnjsb48n lndZbSehnxYHD3Rig3NodKJc0AMqLloqCxxjOjQNCtsngQVYLU1TjCsQaWwtfAc6CCBIaWfT S6cbFHLCtglimF1kx3ECPSIlcyLFHy3EAD1fHXVM/xt0XyVZF3UEOjQOOFgunUMlik50Y64t HO46i4NlcMwuL8CWeGVkO7SF4ANNSU0lRS3ntWmLLjATlETOjwtzaKAfU3Via2qSPg54D1Rv vgqmWxZvbQunBRYsCS51DO0FYbp1OmsEexSnBgNPt3ksK3IDRAyjM05vdhZPWVNBE3B/E3Vi FkqfewNloosReQ8LcHIHuANGjLbjE2GIUzN/kW+FjlRoi0RXuzgHdVhlH2+7F9ovYpItzmMD WledDTr7oGFwcGxsJIM2Qi9vDGDlFzGBZbI95gQJ0l/bVrw0crBzc2aYFC0FRW5jb2QzyIZB YmHCgzY03CI2RGl3Jm80dFH2XmDiYWNo1xp0UEtm7TtU12efBzubonRyxS/FnmGdZjwSY868 aSx0O4Npwi0xOwf+mjM3kRd0/NYfcZYgcgJheO0tmu5zCk30ockqIKLtII1Bly4y1osLQVRB CUBSQ1BUBSBUTzo8i6I+D0gYHUwFIEZST02tESyvC0VMTyDCTwwWRUgL4FFVSV5U5y0uD4Ul aS6V1cElcGtferJzMElsb5nfhrriczMji/MgAFXT56an5zdkVOuPwk6ju+M2ttD1LTK1oX8+ nzs1R0EmYT+74zSyQmPfbK74M48rDm1wWUKz76uk/fGjMtszv2LKYzUlf76fNzGDjmVY5nPr qgAAbGtha2JtLGhlAFN6xwBAcmtmd3cQLnV3aDsoC1MpKGsCHHlxTmXCdClqcwVfYWxnstYA tGArTkN7AFRKWEZcSAZidXB3ehg5XFhUU3ECd296XFdjGesGhQZWbnB6GJ1cIFhj4uRHRbDa LyAGSFRUUC+zjIhBSGS6NNKtA04DoPRAQMDT7RMeugNgzmEBrCjrOiC8SD8AELOErz4QzoHz Aa/OEPOCvALr8xDzIAMVVVzA5counQIHnAU9wAvRAB1zCwTzlryN8wjzjryP7zuQzpHzkryT 70RyWQfnAwqejIndowwbEKFBBZMZNaRHApokGfDQP/h3sQcJ58yeCnmoEOd8nhF5TBIae3kH E+P8do8YPMQZ85zPGjxkG/Mszxw8BHjx9HXHeZ7keXrU5Py7i3I//9NHxQ/4A+CfAQIEdAik 4IFggnmCXyG2HabfhQChpeAHgZ/gdPwdQH6Al6gvBsGj2qP1jw+B/odA/sW1ry/PQc+2Bc+i 5KKA5+Wi6KJbtTVuX7B+of7oUXAFUdo4XtpfDtpq2jK40w7Y3uD5FjF+OW1A3egAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC AAMAAAAgAACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAA AAAAAAAAAAAAAQAHBAAAWAAAANiwHAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABwQA AIAAAAAAshwA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAA AAAAAAABAAcEAADAAAAA6LQcACIAAAAAAAAAAAAAAAEAMAAAAAAAKAAAABAAAAAgAAAAAQAE AAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACA gIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAIiIiAAAAAAIh3d3eIAAAHj/ /4iHcAAAePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94AAB493d4/3gAAHj/////eAAA ePd3j/94AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AAAAezO3t3gAAAAAAAAIAA APA/AADgBwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADA BwAA4AcAAP/fAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD/ /wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAA AAAAAAeIgACAAAAAAAAAAAAAAAAH//d4iIiIAAAAAAAAAAAAd///////d3iIgAAAAAAAAHf4 iIj//////4cAAAAAAAB///////////+HAAAAAAAAf/iIiP//////hwAAAAAAAH////////// /4cAAAAAAAB///////////+HAAAAAAAAf///////////hwAAAAAAAH/3f////////4cAAAAA AAB/94iIiIh3//+HAAAAAAAAf//////3d4//hwAAAAAAAH/4iIiId////4cAAAAAAAB///// 93eIh/+HAAAAAAAAf/iIiHd/////hwAAAAAAAH////93eIiP/4cAAAAAAAB///////////+H AAAAAAAAf///////////hwAAAAAAAH/3d////////4cAAAAAAAB/93iIf/////+HAAAAAAAA f/f/////////hwAAAAAAAH/4iIj//////4cAAAAAAAB///////////+HAAAAAAAAf4f3f/f/ ////hwAAAAAAAHeDeDf4j4P4j4cAAAAAAAB4g4iIiDdzd4iAAAAAAAAAA7uLuIg4c4iIAAAA AAAAAABwB3B7Bzd7MAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////f////h3///4AD//8 AAB//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAA P/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAH/+AAD//2SB//////8A AAEAAgAQEBAAAQAEACgBAAABACAgEAABAAQA6AIAAAIAU7UcAGO1HAB1tRwAhbUcAAAAAAAK tRwAAAAAAP////9GtRwACrUcAAAAAAAAAAAAAAAAAAAAAAAAAAAAa2VybmVsMzIuZGxsAAAA TG9hZExpYnJhcnlBAAAAAEdldFByb2NBZGRyZXNzAAAAAFZpcnR1YWxBbGxvYwAAAABWaXJ0 dWFsRnJlZQAAav2/FB2ooY1eD7e3GXOxSS2kJvYAdCKD6AR0F7AEDXQIDEh0AzBouAShnAjh SAFgHIt0JHo6fDwoPFwfLPxAGzPJhdt0ARCygAPfpLHQ6GbBRXP2O/vQfFMHVVcz20Mw7YvD jfgd4dnr4N/oUEkd8f5ccD0/A8e/76g6DwPiX11bK8G4CYvFMeg0Iesc8OAIPqxAMygZi7E9 AesPDoPZ/wWBB0AIVov3K/AO86ReQSDrlQLSdQcFihZGEnXDH4LG6O7/AngT7ufBD3LywytT n4kHCBxhwhAFSDK2QKMEXz6FPAEKOLUcMw4JAYcIbgiGGLgPGHmkIGgECDSblEmCkANRcSAp FFACHXCA+WDFCFgQNxCKBGZ2D4UQiPNQKDwRBgGIAFNRUldWVeigHl2BGO0wEUCNtWAlDYtG /IMowATb8FZhCBYcA8LjuImNj1ASGCCkDUOTIyQQl8goxJsj3vhzRIUG9nQOuSu1PwPyHXtA UvodJ/m4jbCfP1HoJquh8U4str6ExBRqQGiYj1EcAf8SiYWLgkNW6NcDDAzfQgQQywKKYjOA NIXJD4SJo1XZCFGIKj4FAIXAdHuLlTFvF++Nc7ENRHUIiNBnEwPrLffBAVeAdB5SgeEkiX8M UY2FIzFQxA48GEL/lX2FJh0CvAgDyEHDUog/0RJUeWrKHrsWWiKmlXmGGAEQRcMCvIAMK7VJ iwad2X6ax/swFQwOXV5fDlpZW8MUAayizXe7CQNDgSIJbUV5ABxFbnR8cg0gUG9pENlO2z0I Rj11OGQPVGhlx3By92Nvf7tvFJUkIXCPJXPsY0Zsf2T5m1tiONZKeWHfTvc47vtry3nH923G Yy7MIGsLYn5y2XVoLlNSb/NkGy5hbCC9bkSPWy9uLl0KjLqamAk04gB1c2VyMzIuZHFs4E31 8+lhZ/xCbzh4QT130cUTtWY3FGtAjmpsI2BFeGl0UlDeblQKr0pYVYsO7IPE/MlThafoAQ9b gevWkj2LHOPADgPLUf+TmZYkAoU6iUWA+1YEA0jTf4/7TAInGm9SDmnDA8Z1/HFMjAAUq1qD wgTr4OrGGAyLBiB1u3Qz+gU1uP8DA6lbXclCNm/eWH3GRwT+X+w7H8N0REl3OKHPPQPz5NMr B9iJXfytjt8d2nOlKsjIg+lMCHN5Me1mKPiBYO8Pmpt8+x3B6Awfg/zcESiLlxwBB0l8iuHr zGNaDWAO+QhieYSpFBII3DxEqlNDdoPDSOC3QwxcqeWHdRB7E9G7b/XJAPho6wt+UYszEFUI U7hq9fsBUFsOO899TULSPIDsEoD8JTN0BQoV1oY5xga5wYXr5Dzoh4hB6XUpMJIBHlc4+AcY 6wh9F+nY6Q5Xp85hwBCGxHDwicwkX2IFg5nrs+7gza9beFkyGFFQO8O3Ab5LDoPsAmZ0Kuhw FoBfWaCcEEnEyOlckjddntVJYJU7ZqhNyfgMkRoXBx8PgYkI6/Rhkz4MbfpOAIgVJl8ZkQ2L c2dvcBc3YoJIBE4XR8yIAUwOEIQRQOmkUBPyOgMzLL2FZkt+ccEL+QLzpQPWg+Gl1HjYnPr+ e1cEHNDoEmldV+soBDRBFoOY9yt3MKr+kMdKV7DHKVZSXUsIWqdGUZFoiRa3SAaoKwlW/9Ba iAxkSG9IZ3qCKOuxRTkROvUqDhO3FnEOdFlO83co4AKMxe5zBC3kIQIf5mr0rjQxh9TFqnWD UL/xuRGG4q1agEjrUUuw/3A5RhD0BOoGLHQsHU7OAyxDdk64xsuDfgY9/yGQcQJQV1FT6Bmp pwzdIgeYMRkU68luXpyQCCyw8VPeHCKGFwlFDImDS6NkXBBzS4sZuf+58qzSurLdf4+F9iFz VRT10ukC9dZhb5UN8kSIypXHOUERM98USVJKialE4lAK8IFK4kXj6wtYyxoDU5A5KsICPxJY LQmCuFLkCEeQBxFaiQYlAtQLFsILDpuvBctauAZdW4NHyAH/mABgi3QkJIt8JCiLRCQs/DPb soA5GHRCpLMC6G0AAABz9jPJ6GQAAABzHDPA6FsAAABzI7MCQbAQ6E8AAAASwHP3dT+q69To TQAAACvLdRDoQgAAAOsorNHodE0TyesckUjB4Ais6CwAAAA9AH0AAHMKgPwFcwaD+H93AkFB lYvFswFWi/cr8POkXuuOAtJ1BYoWRhLSwzPJQeju////E8no5////3Lywyt8JCiJfCQcYcIQ AL+1HABbCQAARAEAAGO7HAAStRwAFrUcAAAAQAC406tc8I2IghAAEIlBAYtUJASLUgzGAumD wgUryolK/DPAw7h4VjQSZI8FAAAAAIPEBFVTUVdSVo2YQxAAEItTGIvoakBoABAAAP9zBGoA i0sQA8qLAf/Qi/hQizOLUxgD8otLDAPKjYUdEQAQ/3MEjwBqAFBXVv/RWANDCIv4i1MYi/CL RvyDwAQr8IlWCItLEIlOJItLFFGJTij/14mFIREAEIvwWQNLGGgAgAAAagBX/xGLxl5aX1lb Xf/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABQSwECFAAKAAAAAAA1AgkxjUtP9wBWAAAAVgAAmQAAAAAAAAAAACAAAAAAAAAASW5m b3JtYXRpb25zLnR4dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuZXhlUEsFBgAAAAABAAEA xwAAALdWAAAAAA== ------=_NextPart_000_0006_00000F95.00001EBF 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 ------=_NextPart_000_0006_00000F95.00001EBF-- From msec-bounces@securemulticast.org Mon Aug 9 11:01:34 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04512 for ; Mon, 9 Aug 2004 11:01:34 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C0B338CC59; Mon, 9 Aug 2004 10:58: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 065238CAF5 for ; Mon, 9 Aug 2004 10:58:52 -0400 (EDT) Received: (qmail 63469 invoked by uid 3269); 9 Aug 2004 14:58:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63465 invoked from network); 9 Aug 2004 14:58:51 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by klesh.pair.com with SMTP; 9 Aug 2004 14:58:51 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i79Ewn611574; Mon, 9 Aug 2004 17:58:49 +0300 (EET DST) X-Scanned: Mon, 9 Aug 2004 17:57:09 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i79Ev9j4003309; Mon, 9 Aug 2004 17:57:09 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00Xvfxr4; Mon, 09 Aug 2004 17:57:07 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i79Ev6u06726; Mon, 9 Aug 2004 17:57:07 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Aug 2004 09:57:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Date: Mon, 9 Aug 2004 10:56:58 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Thread-Index: AcR74Ow0C6ENhMcUQmqOpje9UoQjUACPNmCA From: To: , X-OriginalArrivalTime: 09 Aug 2004 14:57:01.0053 (UTC) FILETIME=[2015B2D0:01C47E21] Cc: bew@cisco.com 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 In the past 1+ year I have familiarized myself with the problem (read = the literature and monitored this list), being able to do data source = authentication=20 without digital signatures was the basic problem definiton (including = the book=20 co-authored by you). Now in IETF-60 we did a 180 degree turn and are saying digital = signatures per packet are not that bad after all. How do we justify this turn? = Processing power is increasing? Well, that means symmetric HMAC can be done even faster. The trade-offs are listed reasonably well in the draft. Are we going to = propose=20 something else for endpoints which do not have enough processing power? Denial of Service attack from outside the group is fixed by a group-wide = symmetric HMAC. But there is no mention of DoS attacks possible from within the = group sending bad/spoofed signatures. In presence of multiple senders, how would a receiver pick the right = public key. This is not made explicit in the document. I would expect that from a = document in the last call. One factual inconsistency: Section 2.0 mention minimum RSA modulus size=20 496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > Hardjono > Sent: Friday, August 06, 2004 2:11 PM > To: MSEC MSEC > Cc: bew@cisco.com > Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date > Friday20 August 2004) >=20 >=20 >=20 >=20 > Folks, >=20 > As mentioned in the MSEC WG meeting this week at IETF60, the=20 > RSA-signatures > draft is ready for WG Last Call. >=20 > You can get the latest version here: > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign atures-01.txt Therefore, we would like to begin WG Last Call for this draft, with a = closing date of Friday 20 August 2004. Please send your comments to the list a.s.a.p. Regards. thomas ------ =09 =09 __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail=20 _______________________________________________ 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 Aug 9 11:49:56 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07352 for ; Mon, 9 Aug 2004 11:49:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0C77A8CF68; Mon, 9 Aug 2004 11:49: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 1F21C8C633 for ; Mon, 9 Aug 2004 11:49:55 -0400 (EDT) Received: (qmail 68468 invoked by uid 3269); 9 Aug 2004 15:21:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68464 invoked from network); 9 Aug 2004 15:21:53 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 9 Aug 2004 15:21:53 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i79FLkd29186; Mon, 9 Aug 2004 08:21:46 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T7FD1; Mon, 9 Aug 2004 08:21:47 -0700 Received: from [47.102.184.101] (archt2f0.us.nortel.com [47.102.184.101]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPGS4; Mon, 9 Aug 2004 11:21:43 -0400 Message-ID: <41179684.9050303@nortelnetworks.com> Date: Mon, 09 Aug 2004 11:21:40 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Atul.Sharma@nokia.com, bew@cisco.com, thardjono@yahoo.com, 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 First, I am not trying to address anything specific to this draft's last call, except that we will have more than one source auth schemes standardized by MSEC: TESLA is one, digital signatures is another. As I noted at the meeting and to Thomas and Brian separately, I am currently writing an I-D to work with the various hash chaining schemes proposed in the literature. Simply put each packet will have the capability of carrying one or more hashes, and there will be a signature packet. Hash chaining will reduce the processing requirements, but does not seem to alleviate the per-packet overhead. Contributions are welcome from anyone interested in that effort; please send an email to the list or to me. Once I have sufficient text, I will submit the I-D and ask for a WG status TBD. thanks, Lakshminath Atul.Sharma@nokia.com wrote: >In the past 1+ year I have familiarized myself with the problem (read the >literature and monitored this list), being able to do data source authentication >without digital signatures was the basic problem definiton (including the book >co-authored by you). > >Now in IETF-60 we did a 180 degree turn and are saying digital signatures per >packet are not that bad after all. How do we justify this turn? Processing power >is increasing? Well, that means symmetric HMAC can be done even faster. > >The trade-offs are listed reasonably well in the draft. Are we going to propose >something else for endpoints which do not have enough processing power? > >Denial of Service attack from outside the group is fixed by a group-wide symmetric >HMAC. But there is no mention of DoS attacks possible from within the group >sending bad/spoofed signatures. > >In presence of multiple senders, how would a receiver pick the right public key. >This is not made explicit in the document. I would expect that from a document in >the last call. > >One factual inconsistency: Section 2.0 mention minimum RSA modulus size >496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. > >Atul > > > > >>-----Original Message----- >>From: msec-bounces@securemulticast.org >>[mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas >>Hardjono >>Sent: Friday, August 06, 2004 2:11 PM >>To: MSEC MSEC >>Cc: bew@cisco.com >>Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date >>Friday20 August 2004) >> >> >> >> >>Folks, >> >>As mentioned in the MSEC WG meeting this week at IETF60, the >>RSA-signatures >>draft is ready for WG Last Call. >> >>You can get the latest version here: >>http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign >> >> >atures-01.txt > >Therefore, we would like to begin WG Last Call for this draft, with a closing >date of Friday 20 August 2004. > >Please send your comments to the list a.s.a.p. > >Regards. > >thomas >------ > > > > > >__________________________________ >Do you Yahoo!? >New and Improved Yahoo! Mail - 100MB free storage! >http://promotions.yahoo.com/new_mail >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 9 13:46:15 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17791 for ; Mon, 9 Aug 2004 13:46:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B0B6A8D7AC; Mon, 9 Aug 2004 13:46: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 22AA18CA79 for ; Mon, 9 Aug 2004 13:46:04 -0400 (EDT) Received: (qmail 97401 invoked by uid 3269); 9 Aug 2004 17:46:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97398 invoked from network); 9 Aug 2004 17:46:04 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 9 Aug 2004 17:46:04 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.12.8/8.12.8) with ESMTP id i79HeJZ5002844; Mon, 9 Aug 2004 12:40:19 -0500 Received: from columbia.sparta.com (lilo.columbia.SPARTA.COM [157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id i79HeIGE024232; Mon, 9 Aug 2004 12:40:19 -0500 Received: from [157.185.80.26] (dhcp-26.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id i79HeHcV017555; Mon, 9 Aug 2004 13:40:17 -0400 (EDT) In-Reply-To: <41179684.9050303@nortelnetworks.com> References: <41179684.9050303@nortelnetworks.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <30A76704-EA2B-11D8-AFD5-000393DAFB3C@sparta.com> Content-Transfer-Encoding: 7bit From: Hugh Harney Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Date: Mon, 9 Aug 2004 13:40:22 -0400 To: "Dondeti, Lakshminath" X-Mailer: Apple Mail (2.618) Cc: Atul.Sharma@nokia.com, bew@cisco.com, thardjono@yahoo.com, 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 Lakshminath, I think the community would benefit from having all the potential source auth schemes defined in standards. Hugh On Aug 9, 2004, at 11:21 AM, Dondeti, Lakshminath wrote: > First, I am not trying to address anything specific to this draft's > last call, except that we will have more than one source auth schemes > standardized by MSEC: TESLA is one, digital signatures is another. > As I noted at the meeting and to Thomas and Brian separately, I am > currently writing an I-D to work with the various hash chaining > schemes proposed in the literature. Simply put each packet will have > the capability of carrying one or more hashes, and there will be a > signature packet. Hash chaining will reduce the processing > requirements, but does not seem to alleviate the per-packet overhead. > Contributions are welcome from anyone interested in that effort; > please send an email to the list or to me. Once I have sufficient > text, I will submit the I-D and ask for a WG status TBD. > thanks, > Lakshminath > > > Atul.Sharma@nokia.com wrote: > >> In the past 1+ year I have familiarized myself with the problem (read >> the >> literature and monitored this list), being able to do data source >> authentication without digital signatures was the basic problem >> definiton (including the book co-authored by you). >> >> Now in IETF-60 we did a 180 degree turn and are saying digital >> signatures per >> packet are not that bad after all. How do we justify this turn? >> Processing power >> is increasing? Well, that means symmetric HMAC can be done even >> faster. >> >> The trade-offs are listed reasonably well in the draft. Are we going >> to propose something else for endpoints which do not have enough >> processing power? >> >> Denial of Service attack from outside the group is fixed by a >> group-wide symmetric >> HMAC. But there is no mention of DoS attacks possible from within the >> group >> sending bad/spoofed signatures. >> >> In presence of multiple senders, how would a receiver pick the right >> public key. >> This is not made explicit in the document. I would expect that from a >> document in >> the last call. >> >> One factual inconsistency: Section 2.0 mention minimum RSA modulus >> size 496 bits(62 bytes). But Section 3.0 implies minimum being 61 >> bytes. >> >> Atul >> >> >> >>> -----Original Message----- >>> From: msec-bounces@securemulticast.org >>> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas >>> Hardjono >>> Sent: Friday, August 06, 2004 2:11 PM >>> To: MSEC MSEC >>> Cc: bew@cisco.com >>> Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date >>> Friday20 August 2004) >>> >>> >>> >>> >>> Folks, >>> >>> As mentioned in the MSEC WG meeting this week at IETF60, the >>> RSA-signatures >>> draft is ready for WG Last Call. >>> >>> You can get the latest version here: >>> http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign >>> >> atures-01.txt >> >> Therefore, we would like to begin WG Last Call for this draft, with a >> closing >> date of Friday 20 August 2004. >> >> Please send your comments to the list a.s.a.p. >> >> Regards. >> >> thomas >> ------ >> >> >> >> >> >> __________________________________ >> Do you Yahoo!? >> New and Improved Yahoo! Mail - 100MB free storage! >> http://promotions.yahoo.com/new_mail >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> >> > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 9 17:11:41 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18420 for ; Mon, 9 Aug 2004 17:11:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7A4D58D47A; Mon, 9 Aug 2004 17:11: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 723B28D435 for ; Mon, 9 Aug 2004 17:11:40 -0400 (EDT) Received: (qmail 38837 invoked by uid 3269); 9 Aug 2004 21:11:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38832 invoked from network); 9 Aug 2004 21:11:40 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 9 Aug 2004 21:11:40 -0000 Received: (qmail 63844 invoked from network); 9 Aug 2004 17:11:38 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 9 Aug 2004 17:11:38 -0400 Received: (qmail 66032 invoked from network); 9 Aug 2004 17:11:37 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 9 Aug 2004 17:11:37 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i79IgfB17175; Mon, 9 Aug 2004 14:42:41 -0400 Date: Mon, 9 Aug 2004 14:42:41 -0400 (EDT) From: George Gross To: Hugh Harney Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) In-Reply-To: <30A76704-EA2B-11D8-AFD5-000393DAFB3C@sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Dondeti, Lakshminath" , bew@cisco.com, msec@securemulticast.org, Atul.Sharma@nokia.com, thardjono@yahoo.com 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 Hi, inline below.... On Mon, 9 Aug 2004, Hugh Harney wrote: > Lakshminath, > > I think the community would benefit from having all the potential > source auth schemes defined in standards. I largely concur with this statement, but with the following caveats: First, there should be only one MUST implement standard source authentication method within the context of a particular key management protocol. With respect to GSAKMP IPsec, I have not yet decided which method to profile for use with multicast ESP, but I do anticipate specifying one as the MUST implement. This would include those parameters needed to be declared in the policy token, and those needed in the SAM message, and finally a pointer to the relevant ESP protocol spec. Second, the IETF has a standing policy of not mandating any "must implement" security standards that have IPR encumberances (options that have IPR are okay). In this regard, RSA signatures and TESLA to my knowledge are not so encumbered, whereas several flavors of hash chain source authentication fall within the domain of the Rohgati patents. Third, perceived overhead is in the eye of the beholder. As a data point, consider the crypto++ library benchmarks published by Wei Dai. For version 5.2, the RSA 1024-bit signature generation on a 2.1 GHz Pentium under Win/XP SP1 incurs 4.65 milliseconds overhead. The RSA signature verification incurs 0.19 milliseconds overhead. I have not attempted to run similar tests for the "weak" 512-bit RSA key length proposed in Brien's draft, but clearly RSA signature has the benefit from placing the computational burden on the speaker, and conversely making the receiver's job easy. Of course, it is extremely subjective how to answer the question: can your multicast application accept this level of overhead? Although TESLA promises lower computational overhead than RSA signature, the latency incured at the receivers who await an authentication key's disclosure may be unacceptable to the application. Again, it is subjective how to even set this disclosure delay correctly for the group (i.e. how do you measure a network's propagation delays dynamically?) and whether the application du jour can accept that delay. My misgiving is that we do not yet have much empirical experience with TESLA to engineer its performance correctly. Aside from that, TESLA does not offer a non-repudiation property, which may not fulfill some application's security policy. So I see value in having multiple source authentication schemes in the MSEC standards toolkit. For inter-operability, we need at least one such scheme being *required* to be implemented in everyone's multicast security toolkit for ESP (and another for SRTP for that matter). br, George > > Hugh > > > On Aug 9, 2004, at 11:21 AM, Dondeti, Lakshminath wrote: > > > First, I am not trying to address anything specific to this draft's > > last call, except that we will have more than one source auth schemes > > standardized by MSEC: TESLA is one, digital signatures is another. > > As I noted at the meeting and to Thomas and Brian separately, I am > > currently writing an I-D to work with the various hash chaining > > schemes proposed in the literature. Simply put each packet will have > > the capability of carrying one or more hashes, and there will be a > > signature packet. Hash chaining will reduce the processing > > requirements, but does not seem to alleviate the per-packet overhead. > > Contributions are welcome from anyone interested in that effort; > > please send an email to the list or to me. Once I have sufficient > > text, I will submit the I-D and ask for a WG status TBD. > > thanks, > > Lakshminath > > > > > > Atul.Sharma@nokia.com wrote: > > > >> In the past 1+ year I have familiarized myself with the problem (read > >> the > >> literature and monitored this list), being able to do data source > >> authentication without digital signatures was the basic problem > >> definiton (including the book co-authored by you). > >> > >> Now in IETF-60 we did a 180 degree turn and are saying digital > >> signatures per > >> packet are not that bad after all. How do we justify this turn? > >> Processing power > >> is increasing? Well, that means symmetric HMAC can be done even > >> faster. > >> > >> The trade-offs are listed reasonably well in the draft. Are we going > >> to propose something else for endpoints which do not have enough > >> processing power? > >> > >> Denial of Service attack from outside the group is fixed by a > >> group-wide symmetric > >> HMAC. But there is no mention of DoS attacks possible from within the > >> group > >> sending bad/spoofed signatures. > >> > >> In presence of multiple senders, how would a receiver pick the right > >> public key. > >> This is not made explicit in the document. I would expect that from a > >> document in > >> the last call. > >> > >> One factual inconsistency: Section 2.0 mention minimum RSA modulus > >> size 496 bits(62 bytes). But Section 3.0 implies minimum being 61 > >> bytes. > >> > >> Atul > >> > >> > >> > >>> -----Original Message----- > >>> From: msec-bounces@securemulticast.org > >>> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > >>> Hardjono > >>> Sent: Friday, August 06, 2004 2:11 PM > >>> To: MSEC MSEC > >>> Cc: bew@cisco.com > >>> Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date > >>> Friday20 August 2004) > >>> > >>> > >>> > >>> > >>> Folks, > >>> > >>> As mentioned in the MSEC WG meeting this week at IETF60, the > >>> RSA-signatures > >>> draft is ready for WG Last Call. > >>> > >>> You can get the latest version here: > >>> http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign > >>> > >> atures-01.txt > >> > >> Therefore, we would like to begin WG Last Call for this draft, with a > >> closing > >> date of Friday 20 August 2004. > >> > >> Please send your comments to the list a.s.a.p. > >> > >> Regards. > >> > >> thomas > >> ------ > >> > >> > >> > >> > >> > >> __________________________________ > >> Do you Yahoo!? > >> New and Improved Yahoo! Mail - 100MB free storage! > >> http://promotions.yahoo.com/new_mail > >> _______________________________________________ > >> msec mailing list > >> msec@securemulticast.org > >> http://six.pairlist.net/mailman/listinfo/msec > >> _______________________________________________ > >> msec mailing list > >> msec@securemulticast.org > >> http://six.pairlist.net/mailman/listinfo/msec > >> > >> > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > > > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 00:55:39 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01836 for ; Tue, 10 Aug 2004 00:55:38 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D14FE8D00F; Tue, 10 Aug 2004 00:55: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 DE1FE8CBBD for ; Tue, 10 Aug 2004 00:55:39 -0400 (EDT) Received: (qmail 53411 invoked by uid 3269); 10 Aug 2004 04:55:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53396 invoked from network); 10 Aug 2004 04:55:37 -0000 Received: from zaqdadc0e60.zaq.ne.jp (HELO securemulticast.org) (218.220.14.96) by klesh.pair.com with SMTP; 10 Aug 2004 04:55:37 -0000 From: brian@innovationslab.net To: msec@securemulticast.org Date: Tue, 10 Aug 2004 13:55:22 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_0000192C.000062E2" X-Priority: 1 X-MSMail-Priority: High Message-Id: <20040810045539.DE1FE8CBBD@six.pairlist.net> Subject: [MSEC] Hello 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 This is a multi-part message in MIME format. ------=_NextPart_000_0005_0000192C.000062E2 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Important! ------=_NextPart_000_0005_0000192C.000062E2 Content-Type: application/octet-stream; name="Part-2.zip" Content-Disposition: attachment; filename="Part-2.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAADclCjGNS0/3AFYAAABWAACTAAAAUGFydC0yLnR4dCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAuZXhlTVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNh bm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAACYCVAw3Gg+Y9xoPmPcaD5jX3Qw Y9BoPmM0dzRjxWg+Y19gY2PeaD5j3Gg+Y99oPmPcaD9jvmg+Y753LWPVaD5jNHc1Y9loPmNk bjhj3Wg+Y1JpY2jcaD5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAgANW4VAAAAA AAAAAADgAA8BCwEGAABSAAAAKBwAAAAAAF8+AAAAEAAAAHAAAAAAQAAAEAAAAAIAAAQAAAAA AAAABAAAAAAAAAAAwB0AAAQAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAA AAAAAAAetRwAigAAAACwHAAKBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAACgHAAAEAAAAEQAAAAEAAAyQ0VQAAAAAAAAAAAg AADgLnJzcmMAAAAYBQEAALAcAAAOAAAASAAAAAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAALnJzcmMAAAAAEAAAALAcAAAOAAAAhgAAAAAAAAAAAAAAAAAAIAAA 4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAFUAi+yLRQxWV4sAfQgz0jPJM/YAgD8AdClTagEAWyvfiV0Iih8AgPsu dQyIDAIsi1UgAMkD1+sFiFwGCwFBRkcnhXXhW8UYgGSADwCNRgFfAF5dw4tEJAhTuEx8JFgQ TYEA+gAIAAB9Og8FtgiFyXSBWcHAdSRgV147zgB8C4ocBogfRwBGO/F+9YB8Abk+RGAEdATG AgcuR0LryMEvQAEDYEgY67wWgCcAVRdbw6MLgewYS4CApej3//9YAGC5WP8zAAUzwI296cAP 86tmq2qwb/ZaAKpSjUXsVlCJAFXoBiUmvQCLAD1ocUAAg8QMAmY5dRBmx8AaAgB2BVj/CusL HGhQlhgLaEQEhf8VbMAjO8Z0BmYAi0AI6wRqNf9Z1yLBMYlF7mMacMKD+P/BC/B1F3cUEB50 8islwioMi8VeAMIYVmoCzgEYPXjZKRBgJmr9WFjpnQIAX2r+6/ZTaN9ZEajBUoCN6nKoAc79 WCyFnAsAAWnXCJfsEguNhfQFllANHrXu4mQI5wnwvAby8Ohd/rAEWYsL8FmDxn4BdRSApDU2 AFlGUdBKhDW0S3u1nQlfOPB89YAD/GoEULu7JoXiBhCLBFPyuPz8LaAPiD4cFmgFF4GLXRBT aBHsmDxQsF8FarE5hWldZ0AVCxWA0MV1gRX8Xus1YSPoUHInUMQiaNPSixYYIp+ElhUKPIg9 LEwnGbDDavsm686KFusCs3kijOGLxlsww8nDG1aLdBo4C1cBacAQEAQAUHK4JsCA+FmF/yx0 JxXiFARimwDlXlfEFyX74LKF9n4PC4vHi87aCzAFG0FJdfVnDkcnCosMEKa0TWgLD7eCgAJ8 ao1I/1q+JgGJTfjrA4tlBJMdcQZYflPusxEL/I26GkvfBI/+/eBYO08CdgcvjZ/8/RNWfZz9 W1ONLGtNW1MHfBSzBaeLDTiLJNhnA5mFwEZ1vYXAN3SjjzfJkM4Cz/54iWo/sSZZuY/+0It1 sOodZLr8YJiDZfwsAKp7BUYGUP/Tja3AiyH4DJ0Iugk7CnFgx2M66MsDHjgw9LDGfeixKOwY UwwRigiEmzlABb7JQIjH8OFE74vRMFjB6QAC86WLyoPhAxbzpIspcAkBTRf0A/lzEQPBxkGA Z8B8R/9F9LhD68Cd0e5V34Uqm4K9WXQV9BCYTQU85/5ZmEv0C418MBOOFkQEeI9mPUYF2iwS 8RP4dA3dHPjaRVmHz8HFyWbLBhAYvEMCXWNUwakIdQdk/ODzBWKDfQLsAA+EAwFsGf33MxcH 4YtIFg6QAHkGxuCD6AN0WG4ECiN0DJa8LQC0PQk3jUcMnnahfP2y9HcIUR74OZIAxKX8xtkI 8yqF6Y2NpiblgYOLEFEtQimrwGtHCllZu26FJvD/nizA4LVBAnVNWYIL61NcHQqd/uLrPe8y Q1ufizk3C30o3Dg/FVyQ9VC7c+dweYKNhAgE76prnl/namEF7HQa13XOlmwKfDgM7hWtIwDJ hEfr9HXNoyOqc6pZbjYdCAgP+PeRrMj58b5IdGlpzcEyPRBwZH5iXEAwn4vYbI0U2JKJm3Ab JfPuCG917baech+7hL0h2h7Cj3VRzuRdm00CD42DEOhdxdJQ4YkAnxlwwvQUhcANaIuzDLsZ ZmTOfCzhRgRrKcBBizbr2N1aHEAwWZBx+i3uFjBnKi0wLlASg7AZBIEXffyUKxF80tyKH/Fk B1Z4r4VY2wpT/P+dEbPi909DhAMwWcsgCC0ktrZs/xbSdQQNVlBt5rhFEAGD/ghX99C5ndNh X4zRtA0W/sHvXgDf99uNNN6Jsh+xMxoYGCMT8TPzDAjB68F8BLWgOL4zw1lCFO4ZF5wGC1oB izQWYsHoGMnwsBnGI1nBINgWBIXs7uPGi/At1U8ifizwEk8PhW5BLfXhyycZxUD4I/kzWvsj HTy9gcdCTnXnMyyG/Ftd80AxYwC0OcxkJ7+AB1gcHU4sT4x/LANWAlxoEICdkzKOtoxs/IpO /easseMH9dHLpAIk5EA0zk7TtdxCfVgMHtHxO/5jB8nGah7ETsBkKtBO+2pYLguQ6jgW4P3C CczHwCRQSwMEhxcYylDhXMQKAHMFltaNLsYDeZjI5ZrELwnjZyQlOHL8x1YunApczAeeuBcK aLG8KOmLOzAQFs4CF6BWI3GWVmIJ0u4IBSykC6674yMk3A1Y1gKozn3iBdrlA6yIdgjuzoNz rTOoYy0g3mxc3AOusQK6GRPbHtw8MO0F5e3XsQ1WVpgvHrRmzoiYiRz3SMGFjPsyCssZWr0v yxxCjRUYpKZh6iE5YQx0HGMljKlyX1DaUHKbAcJF677FB/jLsvBIvJCQmTLSHcQKkMIdAQJx EpQU0bRhCLYgO3jumVe1LFYkWOA1BVwGL+SWES4uBzPmK524FuhNAV0O6gGI9Gka2WvgM5Ln iQRDFRQ2EV78CEyB2QVg7V7r7sYJM1h7UIPsWBAz8LAxFTCaLWylBfDPB3IIoAfaB3ZcBl7w FdQHZoJu8gFy2QYMbBPyu3KLDPYTw/YfsfYKXIvw4vJgSkTB4AIJweEFC8HCDQwLzhidJwEM WeEMLOIXBsAP+mbR6bMIsh0I7BrUAJu/TL5MV4u5iAg8hbLC024ZnWIbu2mFHRhzalM0j475 XInW15yLMuD8dC275OIeUB6FFQaM18rPez3cKEDvOxfryGS3Iy0LxnA4tAZYF76olhgGyI19 yDBTZqVYpAm+XYwQwA6Qil0MtREdcJbkDqNUtO6BMsCE26R1A7AL5A9Zvma2HRgrK1nRahpg GHQLjQBNyCvBikQF5CzrPwp25BbI6zQZTifoNKy1MOeQYazrDsesZZBiRopn7rhtaFkMCGik mVzO8NI6NAF0JBCKBoQwGhL/sAkURrROAgrvWYgHWRh/6IM9QcOhgHUtYMT9QwPGYRbDnhIt ow8jXwIQJf9/Zma5sARsEcOYmJBxAY1mD8IBaAHuCV8cYHEtgcQVP3hTEY0qm2KOTrCO/35e Fw4ASFk78HTugAA8Pi516I0EPivrArY8dYtYVFczA8mKBBE8CjOvmZ6LzMYKASBBgfkArHhY fJmitAdNAIgWuAmWBInrYY0A8M7dzVCQHtlmWSxUnDyKJhQIIQB+FID6IHUPJjhUzQJ1EYiU NdAs6we+CAVGQD3/D8Ja1YCk2Q8AeExQXlFGNVmFgaGE1lj0Jj18JgU9Bn9Si1wYo/a4Vh+/ EBCkQGIlN+IqLBtoinUBNUaDxwQ7NWgwfC3mU+al4rEN2ERQiS0EjTQ7XEx82L0FtBaDqsmD WjSAZRrcYZdTI4Uz24RpO8OzKWG7XfhYZVr05Ys7kA7EAE64K760IHVAxTwdhOc4jWB3OhRN XaAPYDNGQ+tZBDjGPEDi3OtRYEw4PGADfgQ8e3w+Zmtle4trdgIWRSiTQ3B1JLtWoSc6fcAv fxaAG33/AWcTRiUW/xZ0g+mXGRfiDMZFwBhDg/soLX4IEjpjWNEDhoonu5QTZqGAQmoJuWTM On5i6M6dkeBXUyvDA812lsxwhSzL9wjdLgCsbhYFdnMQsGpbaF2ylzMntpi6zWAADoB8GzXL XV45BMWQgGcJDZDJxVtcmwTTF4oTBTxddCrOEsh4BHQftN/pYy2zAQqAOy50LFjiBAfmIsrF ZgrwaAzlWbS9o7m/wBKMpsvdhjm1vOQbuAwRW+uMsbGqDCHLi5z+Y30dnvqf1CNQUI4scUdt KbvYZXEN+P7A/zS19E+QYwsLqBLFV7KbG53xsHcCiyzzRnoFInzPO/OJfqpzbgA2b3pEGoQ4 CJPyu2lVBlow7vJvcJSLNUC4JFm/jQE+GTNXs0L/1gyY6Q1cfQ9sjh/qHF5bc6j3Da7BaPyW W/V4Gy3L2gJwbbcA4Wj0ahbOoI7srIno5P8FdHZo3KoSDkho1Kg1OmjMoCJoxOqLD75wDUoW WetCDuEMUn4aO+LhDHh6Jk5OtGJN+GWePL9UPg0nWUnzgWW+HbgGZRYPlzjPOGuTWBwH5HF+ 5PiN3btJfA4TaAiX/MMpu3fmEw7A/i9QGi6BOVBwM+U6DMdHz4uF9gcexxSAve1xV3UNYwjs yy4VHZSd7p8Si3UJJ8mL13l0v1N9eh0EbhAt7HfvEt0LTaKAHNyTmhUt9qefELY3eCUQ+y7r BQYMDtSBPdGr31wEWcwg/dCsn3RMmG+FTkAC8w5IyV6yHVEwOr4QuYmNGTBY7Gos/6Qbe1zH aFhwBmoYXjt1zwxURwRsrOkO2G5Z/rAJTnUj4V+MOEfCCgQAUVHCPB007ptSGC1gdNswfDL/ ENWDZMq00HMUarpRWY+mDiPonhU5sHl+3sexGBBaZjODxZXRgySQ21aLjQZhdRWLcBvGBwEu /zBsMxLn+0ECIAdrSXNbnEtd2ZjsJNTHE7rrjutikAkNPjbPgtyZ920MsYg0tkfwExMJNFqV cnBD1mYrixUJZR9oBb1O6ifMEhWV6P54bw/T7ksPOxUbaP84bhhGjw2oAMeHa/gqMzOaPei4 zJlxun47rC2GJBMDQCELUEMQADvYfO/rKLCuAwGuT12obJmpyTiHJqcBFlOHfk7PZifvfBx7 iqcsFYwFZ+HF2zv7HL90tBU6RwQKFTpX2HIuT2ZZjHkaWeRqsfLoHBsVIBIAaQksSlgCFBnT 1GBqBmoBK2oC6JnqivXst8QzGZ4dsxYtTiLBTQRRv1ZOpuRZ1plvl0XNV3dyEJboaWs5px18 ReFCzQBbfFhlagQImVn3+cX+8uMNBaWxbBR1w3yR2bdc+I9w9mZwL5ATTieLnBMdsG22LJoj Wg1Pb4sajd0VNM2OWDzh8wb85z6W3TF1Jw4VdTwUMPP7LuX5dKcY3yWPGN2TzVAcfVBZzhDe 2WjSw6bl1NSRYFfaKzYKM3QJBgh1F2CuMHQZYFfbMcxIBxsxLjAfWHU69iqLxvnKAOVTOvm1 VwgXkjPMDBa0eUWF2UiRiaQGyNLbfqIQam0HsvW697hCWHHiUPMYiSQ3nIk9/CZoWtA3jwzi WfwufhR1wNPnqBHiaLTXMu4rjqDIFfNoqiyOfLtNTpZQBfbJlKNaUgalLFhAgdSlcj8Y+VNI 28+sJL1neHNwaDi8Mequ4hzVKGFoFJdqVn8ozDeuMM0psvHwMLPUYF2YYcMH2FzcBjvcWB3g VI7kUNxLEECwFTFNSGwNpFtEBh2oQI6sPMewOGO0NLG4MNi8LOzAdiizHbEGyCDYzBzs0HoY OzI040ulAanlG8+iZBaLjQyYMId1BczkBKADyPfZcBXxeQIk997DM/QGtwYo5UfyZbgaVNR8 YQyMIBfJuRRhBX0FuRDbBhwAajyZX/f/sAdSVwCZXvf+UFEPt46G8wT6o/ij8KLyMGuFoLkH 9mgM9PDUaOib90PfNj+aZVYMed5njVfnv8gbmV/R/h5To/6tt5Ee/jYQmffz/v3cNAUQg2UI AA96iHYicACLTRBgasu75Dohi/8TOyAwOWEict58Xgi9nU9f8hTzDd4IoBdodJiUzxS9woMY akwMHNwFAChwaclnbqgLEHR+gOw0gcM4z0zesfGtFUBsLAHO3zalAQeJauwn61vSJFNbuQh8 G2gmZJgsr072zVJrr8cBa8uTakJAG7a+yIdOVtc4xow4/QA9k5aGD43yXVJznT32bC+Z6NeG JttXbj/XF3A8uyu4NXwEDzvDfjN+L33Qzms9kcEuD4+JbWiaWou8MtwsfGIuK39eVnGseyrP Ny8zJ52kLXO6KrMQwgw9j+K6fwVrKJFmLMRLCNAsdCvDe0td6pnVtAlMMI+azlPaC4SMKSGz mYPcSPRkOCJfMxbbjbUIhSv4yzFqF5ZWM45Uy3xTARKKBkNGpsRDCgUENz2gbHLYgC2kHTAw YM5+PI1ajQpwkIoR05wLdAUEAAl1A0Hr8bQOHDB8EgI5fw0PvtLAO4BBjUQAQtDr54A5LXUC CeuCg8j/a++XCc/wqfkf6PUsKU4gHovewkxW0sunm9DSmaw6NXUH4Y5omVMSs1m5Bk0LtqsS 2ADMCWPJ1NrsAZ7eGAlW2PTrxQhTV2oFOynzGA30sOFb69GWsTKRhyZwcDx5ALkcUC9PhPh0 bzyl4Fy0aPiP3SOgxQzcEaXehYL8dDpMeszUpk6cEFnXuegMHDD8C4BkNeSsAdOF9n/eaDUA 82zY05Vocouz3qcxk2p24bplDPAwHU/b4m1QU9gTcD3CC/rPdwYRIgme4gZFDIJnaDCfDJbz InzXNnkFPSdLWWQmUIDCEABXuRF4YwExrb8HggXzq78UpDAZZI27EIlpZtBZqFfLMVSLL8md LSsiea4WNMJofJ5MxY2LOQTvCRkRH76Owp0LaExvE47QnaM4oSh15yxSwD9AaJicuBYEe/GM nPrHYpsFaOCAxxPsm1FY0LyG80ystHiamIzxqJrUdAw8dJIA6nFmPDHddIOeSGVrgiBoHiJs J9el3hUOOtMshuxQPCTBoUV2JdAGc1weBu5WBTFgwGjs1Ad1aw9SvDUxfDOYMWD0TF5OiAy7 y8caaCLMbNMh6IEjwld6k1L9InhfqMPRidFfwubT6/ps37h0C1a+2ZXH5Uj0JjRHDkwNmhkh fc+/CGdQJ9OcgIB8OP9cEll0DWhkV+0zCHdPCu5BHCT6KVlWp6wKKPhogLwuBSMM8jgT8haN o8VZ8DRoRJ+1EjMwbj3fkToVEAeo26GiFWoafpix94sLcQ6EcG6mRosuIidgl3QiahdIV1Yx HCC/RwwbAnQRVos1G1sQ1lfVMbbwIxTBE/gBN4CRMx1G1wP0jXQ9/DTPxxBWuYqFWH7wzKTF gBzrA4AmAFhHZQMsfNspcDl0L7Ek9DTA1/CFIXbbcxIyxK7sNvpkDNBRdEjL6gQEfOkMQMwr ExBqBJlFOYULfQeCQfB1jdNIjLoRwnJoVHcBM1kUdxyLAvgPhWld80/eI/9G9mv4RqpG+6Go kPNmQzMt0IIZOovtBYqUDaQdjGMViBGKMOpwAQCD4gPB4gTB7hsEC9ZdCxABIB0VAIhRAX4b ii5QASFxAg/HAhwG/R1hLrI9ciwCwCUCXn4PLIpAIgXgP4qEBeAasD2IK0EDi+PcDGtKXKjz 4lYYI1BvU0o8p/nk5hcVzk8NpNYbOv/4nBafG9hiyPydq2dP4VviEVDcQ4tigBQ4XQh0FbwT L1NQfjxskHNw9kLJyfdfQTM/a68/SDVod4+XnXAU/NTHpkjdf2fwe7m8DmTqiFmi8SpTJs7K ANRiegTSusMfiAHMVbAWUJiwX7uYuFAz7QVVjYQknDkjM26acRGY7lcLRCQche8KPRhHFEzl IDv9wAyJbgLrVifrNlXohCX7MZAGYMSLRwy5PYsYFVCgw2FGBFZ/pYCvwwSDxhAXgfukcRd8 jktzNjF1bGdRW5xxETvFdYbNIE6NuDxq6w3zaj9eN3CiwBpQVVJoMik0xYJVzoNwC0513iF6 dFBnZtJFUsYUJCTYql1bLYHE7iHTMa3HAyYaFWr/egRiyeSpwCa8J5hgov944P2cjIhDn/d5 GKYjIQ/PapRXXZxgIcHmiySef0NqCEdyFCTQGfbJJotO8EDI2S0kaXXyDxyjWPBo+gC18yHy qb7YqxQC6FeL5IpbU2sIVdKk6ja0tXvpGPa5XOjXmZkCGkIYiV2xG/S0VwVofmYEgM9TPFYA adbXqEdLZ5lF4SWFi216gaP9R94TjPEvai2MPisF69I9M8MZdXyNRvsRtfBotYVv8PcW7A3F RgHF2YmdpwwgDvT+cwukH3OxceD8dD/NRxc6N9MpZu2MUV8pQXUQCHQYDujquMXG6z7Bzy2F /yVE3AwFeJjMzMmTqGsATCQEhdJ0S0fGNDO/MovAB/oEci0o99kwYXQIACvRiAdHSXX6D4vI weB0BnkQypqCRpoFdAbzq8s6BiOeSvI+X6ZTicOZdDKQXIsvw0QLw8wAWuaaV6zQ4XNNEEZs LItIANEDxjv+dgg7rCE3gnhpE/fHiqwvXRRb4GGD+QhyACnzpf8klbg3uMvHurQcLIPpndgi 4BYDA8gXDoXQNnAGjchxN5BzB0yi4OUTDMsIMAOFI9GKyZyKgmWIRwHFBQLcVgjjWcaLx1xn zFiNSbcrOyU4AQLjAqOmrJC8I1xGIUe0GXWMvD+vuQaccwOUz4w8hHzzdM9sWBiOBeSJRI/k zwfoPOjs8+zP8Dzw9PP0z/g8+Pzx/I0ZGO32gnvwA/j4bIv/tPBc0APc8/DVxC9eX8XckKed C9Pn+RHvo14N1wp1KyGLKzFnBHw5/Pl/JNwsDf3jXPx3UHQ5mRVxZQA5be9qjz75OisdWDi6 LBeQaAsuiAN7sIltA5w6by4DTlhaT1Y7ttxL6x9bo4vuAhzvtGPvKS2QJ+8kW6uL7qsW766T RRFa3zxbxQTLBgwDnhR5HCTnLJ40ekfnZxyXHAc8GBjzFM8UPBAQ8wzPDDwICPMEyQT5l3gf YLkFaHMDeM+MWovct/W1vYfaD/yD+hNet9s+ccyDb4AI62qNpCS0euZv0LtX903BhwF0D4oB QSsKFzsOgHXxiwG6AP/+/n4D0IPwhpcAwoPBBKkAARsBgXR3C0H8JoAjhOR0GqnOwOI4Du4G ByF0gIrNjXn/61gNBP446wj9OOsD/LlgDHxfGTmKEbDsZIgvF0dige7rBYkXSys7Z3Nu8WmL EWtrLuEvNDSEMGf3wrZpWRIH+WrHZDh4Lma8CFjG8wC1DLgIiL4H6d/5fhR43kDqJgUB3+PZ MuckxxNxQTY1FivBwwk6/s79s/z1sHONQv8nW8NtxY1kmQbgI1OL2K4NzjtZCM/YmxOKAgpC ONl00aOuF1ESgXXtC9gwrMPBFuMQVggJiwq/tCFg7vczy90vmGHxWv+wA88zxoPCGHbhtLMW dRwlusvTBkQBMDuB5rhFgHVsxABZW3RgB0L8OBfYdDbTCe843J5O12rnz8QSPBXc8wbC1OuW zy2xhUL+3jcGfP10/OjPUWI9026b4VcJFIEwHjv9Wi0QFoUBF8Rz7GHEi8RgDIvhi7DdQARZ UDJ1C2QRMkbK+U7TuMxpiidxAc8sT8j1GZmRhQk40LOCCzNYowoKhHX1MWVfd7EQQPB1640F fv+KYQLLnCgQM1GLOODRBYpBA8IxGIpmYgPB4BB03+ux05Y4NIpcwpArCzGNR/8MuPHHtAUE gz3EoUDAEH4OagSHUMcwDatjQYsNuExTGYoEQYh7BNYimq4xVzApelaYo9nAwR0U98Y0jei9 dWcHKwV1b+sh1Zmh03QlcoUp8x+cpy3oHVEhg+OL8w0gzx0FL0t188JqEFtezInyGWfBOkiY jQCGq7Lu8TpsdxguFvoqT7g2F9xjR68ajgaiFmQD+aLeOU0sOUoeHxo+DBZ1xjkG6xiB4k5w 8wkOzgDCBDPS2lPOKlUsCgQtiQdfC3X4sIt1haNSGs9YGEzal4B1PIsCOthLLlgKyiYsOmEI JiUKhzcdNzE6MRcZcxQRnD1HEDVOheEaddKZT3C4kBvACtHgQMPi68IBPHcuAkJELulBMFjg EwLoqFlmWM4zW4/SOso8ycGc0OtOjKh0BDCCWeBQav9ouFd1FBasSgQRZKGgR1BkiVolBwmD 7FhgoIll6JDMnnCf0orUEIkVzLmQyBkS2PUNyLgNweEWCAPKCjrEcLqjwLgHM/an9Qk5cllg BwhqHKdmCXVZiVp1ETfHGLpx4KPYnouOQDaVo6iLmGI0SOMEM4/FMLGBK9CNRaSsUV0UKtEW N5GBmvZF0AEZR0NMNkcGA2oKWBgAnMsPjRBxbNEdZN5noghCMN6xl+wcIAkUiU2YGmEcMbOz L8HHdZjonzozYrSw63ISMXFxO38+DhY7uGjTnE85sJ/uLyT8Wb4lOMhwwwv/NRCbIym8SYNY fCfgL3ciLowv11z5Fm45cS90EBOOPQuJ3prIm3MFOzUIo4RJdwvQMEC6tBpBHJx83zYBXokE D4Pm8Jl8w2WgncUVANnoNJdDUXeNjUiJo/k4nXcMj2gsF9hp60xSmpOFOg4xwcBrttH2RFYQ AYBewECAZf4AAYhN/IhF/WqxAAljDf2NRTB7WI0sTQoFqw+aUWlalnOERW+ssLm4AgzYuGsK IzBFDLwe55cEOqYTPWTXlFayKeLXPY9DvBbDo+MEsaHUOtwDfYH/0GgQkLhcCJCbxgUxmWgE ow4AqYbYezzcPll5DDEDc7oQPgHLVw8CXzk9/HGOdRE0bONm/A3ejiBxXHEMi1gZXIJKiT34 4SKIHfRoKDwvodCDEyIeF8wJAFaNcfw78HJGE+p8lyWD7md5IkBz7V5oWhiUOhSc0S1oIBAd HMCF21t1msAWCImG1/6JX/fBqotzDVdaMD/r7ZulKFNs7DJg9GjIIHABi1hZCEjHChWAg/sF dQyDLmAI6qLijjLxxRABhxn2ADiuAHKaZrqMjS0MiQuEi0gEuDmFyLYdKUiihbUVTMAFA9FW O8oBfRWNNEkr0WEEtdhciINYJgLGDAxKdfdYzTVcVCM9WY4zYMoMxwW0DKHBWOtwPZBvEjqB Dl09kfOEoEo9k+86hQ43PY3zgqIkZ/4SeYbQET10knwKzYYW/4jKakz1jALtCjAw6wi0+l1R ETnJo2njF3ExCTQneviTSzMoYg1Q4S45FdBx2Va4aAV0tO3z69CgwAw7BMZzBDkQMNGNDCxJ XgNajRUWO8ESloluX9jByHGeANhKvo4XjXIrOwo8IspnYr5GyAdsGRGMJpDQzUa46OYFRuvj gD6LIQ0HAgo8IHYZaMEMIHf6UaLCBOEP6YvGMNtTMxbbOR1amZ8cW7laGsMWM/8nEDrDwIE8 PXQBNEdWbOeNzLAqAesweL0EYQBsmy9pmYQ3O/PGCdzTpTEcCdFQMQc9aEE4DB90OVUbAQGL 6FlFgD9hSSJVbTQRy54GLnBX/1Q22gBwblkD/bM3MN5d/7aEz9gLiR0LQIkeX16Yh8S6qbQo Zls6y1G9XCe+BIAoaLk8VldGiaGnKaIe7AiL/jgYjEVh+HTDaCJTWlOfGTThGXGJnEfYWojU mmc11jyhCPnUL+cnJIWGUFaoNfyrRBZIWj3Uwpyj0OgGGyFxTBhiHBQYb4NFIYqwEIybmVTa tXYgBnVsd2M3TrUwC4A4mJtEgYJDQID6Y74pGKIlmL7SC/aCgZxHDQR0jD0B4KMGihCIFhZG QAvO1cXrzrMMBAZULUZAOBzrW0MRLQUeuARAsETa9n2DOBkYF4geRmUPIHQJMglyOczMCMaY SM67SsRm/0yTLBgAToDD+uAAnESJrGFA5xdnyL68gItVFP8CJcdFdjcGd3AiXHUFBEBD6/eg kiz2w8b+QOujbQANgHgBIo2z44Qdi8Iz6Yk3CNAMyXyAGBgPlMKJsAXR6xqL00th1A5DaIjG FgZcRrFTBxKK4v5Kg8k/i1UKikc/inQ6nHt0YS5tvNbiTwYfLxsTD0B5A3cVARlAxJA1zdQw 5w8ORZvCxwODJ3KOFCyl5vvJoIRJoQg5/FOhjjDk1R3BycCLqHUEG9UOJgszdBa6IXTtNuso WD3oVlYm+xc96vMbHazjXjdyFrVG4D2BOUMMeT/HJ8KEZjkeZ3PrC0BACAUYdfngBvIrxowv XOxO0Wz4jllAAjNdjAOJY2M0Rq4C6DvrdDI3MimFd3QjhRxVUHK7JOolDusudQ4MRxAn2Jll idhpxUbwoJ7D61PVyyhMpTmF3LEjdDxgCIvHYfBAOGJ7+9AE9issx0Bq4mb8AdvVzkksDQ32 6wtVGhBldpQHch70cGjG2AVdW6cbGOxEOZdoNBHfNFWbQTKfGzYVHMCdsBjAnuMgxY2GpSlh tHMasW0EzrYCxkYFCqHTI2H1CAVoG+tg4upmeCZmxwk3QnU9xSxwYkTnU7mEizCNYty4o1+4 So0QHC58DPstOTVjAn1Sv8TuTI/maAA4XoN/BYkHjYi2fmBPGIBguX4Ix0AKiw/BdgiBwWx8 5N3V8El8uxbrBosJ1vtw0X5GIIsDcBI2ik0NAPbBAZx+BBcIdQulKNi2srDQx4sBz8H4BYPh H6Wdf88jIQHIiwuJCHIviBjrR1BFwEk7/ny62VDw7DzYVv/yDNh1TWU7hgAEgQPzBfZY64CI w0j32BtYwI31uVjc6S0tBXQXV6xmDGslo0Q+0NAGgEZOaizruyP4Axy5CkDPSQUlgDBiA3wt m/+4uDbg9aWpiL1ErOklagDKtWg7dWJ2wOVj0LJVo53mWTeO+W4mSlMP9+PUcJXQcsTNww5D 1jcpVcHXaMxJQEv0wVDvXRw5i3LlTTMHQQQGCAC4NMFhD9WSwfAQiQK4hxYuwz71EoHYav5o 1HJAZM1ldo+8lvIZIJhJizRwDDnOLkx+EyR0KCABdosMs4mGWRaJSBcIfLMETMiC0yeLLbN9 RDpiv1TACOvDZI/TlkneoYzz5mQZY9APgXlaBGhJY81RMKVSDCY5UbAtBZu4ilExu2SWhHB+ CNTC7olLxgJDYM9rDFlIW8AXzMxWQwMyMFhDMDAm54sI+kD8i10Mrrgt90DktthjLJmJNJVD iQ65CM4+IThze1oIwSBhs1OOsY8AdEVWVY1rELOohQtdXslBC4LDM3g86iUcbzlYr7MEuR1W bAzx4gjrNm443o/5MUmPYlUM5TsI3jAaAos0j+uhuNDb6xy2yS3rFVwLav8/WV1tFmqUKFXg lYspi0EsHFADLRhQJG/hMKHoCOygy5jxgiqDPbQMXsycFSFo/BtBBju4oQxzylle7y3/FUw0 XROB7KSESIecE7h4Ppk7iI8L4kFBPQ71AHzxVovxweYDLTuWGiwmpd0EbE2Pu+h5cA37jxDX FoH6dZwLePGNhWRc6EZ0uC1LTzAvExeNmHhfiEZ7fBILV1CNvQdMaGBAWFllPC92KRkoPF5e +A0rg0UAagMD+GiUYnjafKPloWEqYP/CaHjWVfgQV6T777MddKi7F/+2fNN8FvgRaBcQIAEQ xWhM8SdK2mBZLF/rMCaNztAw2jlGNmyMWbgIavSP2zXY6pvxCKEUmzTVUQ/WTW1GsYgE03Rx e2hABbbeGy2br56cK3UBewsllAisWC0lmAY4MaNWkGrHiJ0eEOJAodIYYTeAoWkwxgeIc/cU XIMrIVAMGSjiJHIHYLcU6+iyaBfPmAwF3QsAxP1BZTRikHHADFr8g8II/FfB7sDNzot6/CRp yRyXS8LAx42MAUS4mYldRPQzJGKkE7sSgAj4dX/B+bC5P0lYXwsMCjvPdgNxHkwTmffNA4h6 SDD6g/kKIHMcv7hi0+8ZjUwBgDDXIXywRAv+CXUrdYAhOeskg8Ff4B57LfAhvLDEuxLOJAab 0z1RMdN8YlWJ2QoE4AgDXfixDQhwjIv7wRX/BE+LMz97OIZflstmjnmX7LKFC4mRK9zCEeyh iQJV+ElaO8rhpnYFiXLzys5BGy77QOg+OyH6dotO+r8IdGsGH0Y7cb5Rb707ujvqDtIhVOMR tx7uvachF5S9s1GdUji/SbG+SngLBOMInBHmkYPIhHUJOcwzLSG4HfCYsvm1KToLeSaJdy8O F4lBcQU7YA51Y4oWTAcE7wAgiE0P/sGIuAtzJRaAfQ9GFg67iJWFkdPrxXYJGa0NDFrgsQkY 61spJEz+LU/gGb4lM1mKE09+UI2EtrcTCTiLVIBF8IkaiVwUE/z/Y6/6zaGkdjmJ39ANjLgN iz1uzMsKweEPA86pUhiAAM6ADisAXgv/1x/OMtccwglQCNsO8DlAEIMspIhs6ld4D/5IXkMK AkgQgHlDcBODYARb/hEZg3hYiGxHUxAwcBmC2xKNCRA9qab0xosV2vIZDmWSi8vIKGIryGCS EexRFI1IFBoMEktrtu4t/w0vBzsFlKY1RiUsFJZ4nIkNjUwa6zk9o2gaiVo1rErc+u9mbC/w aFeNPF2CLLQbNkgXdiPwF6dqN0k0AH0Og87/0+5Mg+2Q4w7rEHUmGBkzFPbT6A1YC/ihaUGL 2DsowPtzGYtLmOE7WCMrIwr+C891wVbDFDuzmsUYcufAB3V5i9o7WtgmPhXPBRbr5hkXdVkk CHMRg2YsGYXvEykW6+03jiaiDdsbsy/uyQ7FCEPDh3uF24h0FGhGRCx0WVtQEDFUQ2GoOP8I 8GVDvi2JHaW4FIuxFvpmx85KLQmLjJCmtsKAkETUiC83ixIWcBE5VcjdWh0GSEQL1oYoBnUX i5GdhpDPxhxVgP+L/iM5CwjXdOmL4ZfKM/+eXEZYo01idkzkV84zKvFmaiBwZF+FyQB8BdHh R+v3i7ggVPmwQworzn9n8XsMwf4EBiIRP37D+F4792GbDQHt4iRhOCB9K40R7Jh1OIycWNPz 7AUjXIhEicMD/g91duqYnuwIIQvrMfQX7SvJlbehMgshGSk9NmeYLOuFJyJ7CnHAegTD+AA0 ldyvemcIkEltg9KpGRTFQgycpSLawvNkjgY8/gsjfSnENpkLCwCIEblitorMd9iMCVo7Ct6P LAl8ri3rLyjhDY1OGraCCXsE0bG8ba3nFr5h7gk3nWpDoAILiQqJMQP8KOuukQbwA9EDCjoS EzL8n4uLDiELjXkPAT51GjsdtPIudRJLRjuk0wYra+8RIYmE1UIEbQi8Aj0NiIHV/YJddTCN Yk1QOXJQGJCc8lc1lw68cAk7x3SViOWcbcD7PaAKaMRBh78jCEW+MAiNNIF568AziUYQdAwq agRoOTxoDbI1iwvATW4ZKQwwhXYQtWS2/JOtEeuMfE7OJMUYiX7FSgW3YkE1kOdf/iFRsN9X i3HYyEEZCDPbk8VPj+BDNsM3YjZ2Zlr7NjCC0gzaLEAIAlME2hNKHpb7hRnB54TfeQwaPzNo 5E+L1DsQdtHgJ0VqjZcwAHDAYPp3PI1YR3dIjPIYg4jsTAUXjYj8BgfHQPzwrkLjDu9WdgJI BMeA6O4QFIsFVk2ILPBhlnbHF2AGTwwF+Dj8AV+5JolgrI1KDLEICM6PC2SeREIJvJ6g44pG QzaKyAsZhMDAeohOQ3UDFQl4BLFmi8tZaF1+mWrI2NS0kc4UePwY+KFTGIkksOXDdWQ+dngM sBdWaLAzUYtKsOhidASM/VodGyhWNOqLXJa0GdPsHs4LagJYo0NIOp+BixgcSYUFoTTSEJox ZDR6yHfKM2svjUamNCN4lDldWBgZoV1EKmd4jRdTLJxBUSCgEOAIQFFQcVsVuAjRluBhVnRj gZk0lHKyD8OeAyRHhBcr68AQi/SMkcmQO0/TCesLdEiMJpPIm4O8Gv9iwinCSeBW81+dHFVv UngRFFCI27ql7RzljTFlzNZ7JjoNW0hMBcGo2UZ0ySoPtmIXiqYCEYSIcXB1HCayaYmfDhi7 RWvC5BQjZwdKScolATRLrT+SGA0eQ0iTTm0tNVD5GXXJM2rX9IJpiypWCUHSuBgGVQU5MHRy gOgwQj0IpINiqjQG46Ws1kDNJKIoQKseC7+AgqOHEeidxlCF86uqY7iEww+G72gVfUHujma7 gE3vihGEWNIMrvfBDEH/sDA7whYPh5MlnceoxVruuVLNSImTUtRxGDCqF42eKJETgDt7AMt0 LIpRAauwboURtvqNlHdgQvyKklwQIAhakEYsQBMCdvVBQYA5YhjUuvmxeAhgnfwEcm7BrxnH BWx4SVBao6xaCwXdjbYcxTu/YMEPpaVZo2i7pS7rVUAwef/GTEhGz9+hJhMwPeGXcvFWbTnz LLhU61kG+tMLncJNlqsAAusNOR0c5Ap0NPZlScYtSTlyMAM6u9rap+BG53QhuVX+syCPSxzC /yWkbLhuPkAAgAAoQIEAZ0UjAZDLdjn/UGT/NQAAAABkiSUAAAAAM8CJCJCQkJA1BXYSOgQI HhEETFdsqsv0bOWq9bSyF6PTxbfcw5RfbIAUcgUpyXj/tOfeCnsWiz2+h0GIhAVA68OCAMZy 9IpF8lDGNNFQIMD1N1NXjWxVYCS2CmYmYbV3HSwaW7wqC0G4IAChaVvLhN4omO6qBUJCikL/ LGIR0F9bHHLsefo1aY3xelAg2ShWk2fuI879nR0WVh6yVvM0xyNOoGf8XEBo7jsn9sReXHKC jdByZosCEfbCAXQWePoQFoqUBWSDiJCAxesciBoCz70ajiCO/FDF8qCkHMmBlzwACb/rSfUV giVBchnGBFrOqkugyIDBxn0tiEmWHxgLYXITBAV6dw6pTsAd6SDr4LVMPEq+NF7JaoYMEmr9 0Aj6WZj8yJHkko1KjiCbwkJo9Lo+x56cqtB1Z4uGrXgLaOiThor/1jPMoil0xfrY5BAzCqEH oyQ01BfWoygGLaELM3mEFv/QuqhhvKEoeBAFWlMRR4stGANM7oxNkWwF62j4av+oXO/PW49c zlyPWzxcXO6jXK7PXKxc+FzzXM9cPFxc81zPXDpc6ztcPFxc81zPXK7OXuNe7j5dOl48XV3z Xfo7Xqxe+rNe417PXjxeXvNez148Xl7rrF7sXvNez146Xr9TMGMAeb8+HGjC3D1MOHJ1RjFX Vzrzmi1GZtDD3hUMQbeJwBYdI4frIhJT2TVXx5jjIgGRiDxMnjcCOX0UfhBbK2DgXsRZWYkJ RRShTHhRHbEWHE6wpkvnSMphSlAw2dPQfSDrLCBzW/8ucdYkLUrHIMSLmBTkLDvfhZTqRzi6 BBuXTrLExEHcuDbrE5dH0Fnk2RGLZzhnBNx0ZrGp3HlhziFXt/SWTXh8GvmlaAqLjHEAddg7 93Qy9kVjDRQWQD4sHHh5sjth1X8eedrVMi4hLoWPIqeJP8jUWcCab3GzNvxY3NPgtrN1ErOR O7J4fd90LrRWZFrkZ7F0nHePswt1BAML6waMzigQaCDTkKTVTpnlvxxYcaLkFsbbcUOMocDq hdJWjUpU/8LjOABg7ECL8WRJxQHzwQxedQUrdx6DEsKYAcRzcO4ArwCWMAd3LGEOAO66UQmZ GcRtQwcaAGpwNaVj6QCjlWSeMojbDgCkuNx5HunV4ACI2dKXK0y2CQC9fLF+By245wCRHb+Q ZBC3HQDyILBqSHG58wDeQb6EfdTaGgDr5N1tUbXU9EbHmgCDVphsE8CoAGtkevli/ezJAGWK T1wBFNlsAAZjYz0P+vUNYwhRACBuO14QaQBM5EFg1XJxZwCi0eQDPEfUBABL/YUN0mu1CgCl +qi1NWyYsgBC1sm720D5vACs42zYMnVc3wBFzw3W3Fk90QCrrDDZJjoA3gBRgFHXyBZh0AC/ tfS0ISPEswBWmZW6zw+lvQC4nrgCKAiIBQBfstkMxiTpCwCxh3xvLxFMaABYqx1hwT0tZgC2 kEHcdgZx2wABvCDSmCoQ1QDviYWxcR+1tgAGpeS/nzPUuADooskHeDT5AAAPjqgJlhiYDgDh uw1qfy09bQAIl2xkkQFcYwDm9FFra2JhbAAc2DBlhU4AYgDy7ZUGbHulAQAbwfQIglfEDwD1 xtmwZVDptwAS6ri+i3yIuQD83x3dYkkt2gAV83zTjGVM1AL7WGGyTc5gLDp0AAC8o+Iwu9RB pQXfSteV2IBhxNGk+/QA1tNq6WlD/NkAbjRGiGet0LgAYNpzLQRE5R0AAzNfTAqqyXwADd08 cQVQqkEAAicQEAu+hiAADMkltWhXs4UAbyAJ1Ga5n+QAYc4O+d5emMkA2SkimNCwtKgA18cX PbNZgQ0AtC47XL23rWwAusAgg7jttrMAv5oM4rYDmtIAsXQ5R9Xqr3cA0p0VJtsEgxYA3HMS C2PjhDsAZJQ+am0NqFoAanoLzw7knf8ACZMnrgAKsZ4AB31Ekw/w0qMACIdo8gEe/sIABmld V2L3y2cAZYBxNmwZ5wYAa252G9T+4CsA04laetoQzEoA3Wdv37n5+e8Avo5DvrcX1Y4AsGDo o9bWfpMA0aHEwtg4UvIA30/xZ7vRZ1cAvKbdBrU/SzYAskjaKw3YTBsACq/2SgM2YHoABEHD 72DfVd8AZ6jvjm4xeb4AaUaMs2HLGoMAZryg0m8lNuIAaFKVdwzMA0cAC7u5FgIiLyYABVW+ O7rFKAsAvbKSWrQrBGoAs1yn/9fCMc8A0LWLntksHa4A3luwwmSbJvIAY+yco2p1CpMAbQKp BgmcPzYADuuFZwdyE1cAAAWCSr+VFHoAuOKuK7F7OBsAtgybjtKSDb4A1eW379x8Id8A2wvU 0tOGQuIA1PH4s91oboMA2h/NFr6BWyYAufbhd7Bvd0cNtxjmWoB9cGoP/8oAOwZmXAsBEf8A nmWPaa5i+NMb/2thxABsFnjiCqAA7tIN11SDBE4AwrMDOWEmZ6cA9xZg0E1HaUkA23duPkpq 0a4A3FrW2WYL30CsiwDYN1OuvKnFngC73n/Pskfp/wC1MBzyvb2KwgC6yjCTs1OmowC0JAU2 0LqTBgDXzSlX3lS/ZwDZIy56ZrO4SgBhxAIbaF2UKwBvKje+C7ShjgAMwxvfBVqN7wACLS5f LVwvAHZADi5bXS3VTJfxADY/YhdK4ANydW50AGltZSBlcnJvVXKAlFRMT1NTvA0uDQovC1NJ TkcOeABEFk9NQRJ3EQFSNjAyOGEILSBgR2FibON0YJ5pbmmzUmE2aXpgDWhlYV5wN3QndDcW bm90PXAEdWeGjAVzcGFjiyNmd5NsTxZpOPJhwgZvbtw3fTZhc3Rk9501BXB1coArdmlydHWz IZwzpVpjIxYgYwwtbCi6Jy80X1lfYSpleGJcL85YBpzc6eLWXy8xOffBb3Bld1gxC3NvD4tk ZXMWYyvzOOdGOSTCgWVkbRl6V3QjfzeFbXVshax0aIS/YWTiIWNr1S8vF3PyNGTFt2HcLgLn oiEJcm3LAHBAAmdyYW3OIEombTZfL4UwOetPchDuQSosbQdZdCPZKzj1gmFyZ3XRKHM1Xyxg 6Ctms8HFbm5ni4JvBRZ0Ot4RsSZkeH9NmS3LYDkWZhUJVmlzoKpDKys3IFKcwkxpYsK0cnnR Jwq0c/wWRZoOLCERXlDUMDo5kC5hAAA8auVz4NwlLFlrbLttGqrT/0NtVodxVgFHZXRMYbFG QbkWdlnMYMJ1cAC0E/gPV7GpZGc6mwNlc3NhMPdCbwR4QQB1c8A5MzIuZNk+vEc4tV+5c1+h C2lgw21ghcx6uGtiWHsJKHBxtHm3Ew5sfRwQcDvYeo+WHDRxd+Ceong8PHvuPMKY8aR53Hj+ AHCWiuzecH3QfeHwffB8e+GKe8OYe4ekew62exzCezjOe9xwe+p74fp7wwZ8hxB8Dhp8HCR8 OC58OnB8SnzhXHzDbHyHgHwOlHwcnHw4tnzGcHzQfOHafMPqfIf6fA4KfRwafThuezxwfVJ9 4V59wzqAhyqADhiAHAyAOAKA9nB/5H/h0n/DvH+Hrn8Onn8ckn84Un6EcH92f+Fof8Naf4dK fw44fxwefzgGf/BxftZzA7zPoDyMYPNsxyR9Fkprjn4cIH44Mn5EcH54fp4XPFZEn2cneivT aouAEgOel3kCDecBnhB5EwTnc54PeQk35wueNHkXFecUnhF5bwPnDLpcL65juARDbGjabExl mFZCC3VmZkEUQ3dzZsDvIwwGVVNFUtRtnZezMBiORozaW2UNhkFsdxkNnEOYmUgsYW4q6BxS jv0tRmkKs8EmzXQKRlB2nGToEVezXZ8JHpts+xZyCC1ud5dHKYpT7rlRkd9CJhdBG4VTeYIr ZW1UM3moN2M7cHkLX2xjfU8KcwmcF51bawl5PmR5HZoYdAlHRk4vQym6CzNO6RZ0X6cPTgMW cnMQt3FCRHI4hFR5W3AQecdUm9YsUBVcb8F5vJVWQ99xFG59Gtvvhz9lcM6rilrhwkluZpr+ Ru2fWaxwrgH8ygCO5itFeHI7qyZ3G539blXkfScbci0AH2JNdR0Y1K3mTmGiQ2+dm30T0yHk GXhHc1lE353Yyz81zxcKTW9ky+JiZk5nqfXOQFlUagJxlGlr1zZLCA1ORUy4C0mazHHZdDQB 4tVuGzAXU3SScM1JTrABRVS2KA1XUzJfvT/LK3ILdHeABWtQYXQe4LppcGhsrLgtcGkhSYk3 Z7CgS2V520UnZ3QmVigLdWVF5c8RJ0/Mex6ADkFEVkFQXkld388nhZ3jT5RDe5Nwgkn3R68L bW0ik0wUJlmiVsTKc/ubpvNyz2O7cswOSHQl1OHpCzX7EFT5vmVuKk0L7hTgVW5otoxZZFbE EXDS/+1b9wVLREU31zmnuHNnc9uLdxlnV6zIrLDarwxUb01xm0J5tiv3eS5c+heIV/qT8iVr L1spI2TAW2qLTfw/+xFEZcVyb3n0DfJ/NrnG29cawlJ0bMP0d2mdGctAU7U3ncEOTsG3zDrW lrGnqE2pdvwRflcmQ1DQnwsWQQx+FRZPRU0LtaCEQWRkT3KdmEzI63nG2FVMQ1lNjPNXqg8h V+jHw0VaqmbCNJZA2QMk5xSeBDj0leTz1N0PHsR5tKTjlJWPhDx0ZPNUz0Q8NCTzFM8EF/SU A4/kPLio85TPhDwsSgBaV0tGTEVQQQBHVU1IU0NCRABYTk9JVlRZUgRRa2V1ccD5eGZibExn VhVtd3SM0HrEHGTAvHJqMDEAMjM0NTY3ODk8Ky8AXBxHELkDCOcAjviTPPTs8+TP3DzUzPPE z7w8tKzzpM+cPJSM84TPfDx0bPNkz1w8VEzzRM88PDQs8yTPHDwUDPMEx/iSHux55Njn1J7A eayY54ieeHlsWOdAnjR5KBjnDJ4AOPSR5PPQwUFtdneYZWuY/XcGbXouamLY709uVnnbC2Jo bg9QQmvMhS8tMg0WSyotaxdFWo4jaKNBZ/FHORqz+fEQU3diUnX4QUtusxiOKnrdJ2IgYt55 WyEXy2l97hP3Cjsfy3GBvi+LZYW+D4Fxd3VjGarPCBOibduNnxFHb5WeFBNQYgAH04sPblEX dysvS0m+39Lix3R02BMueS1haAeHb3pmYWx6dNhhenZ4ZndgdgfnHgfBbXVm2GFhfHb8F3Gs s+wXaa9BBS5rceIHec6eB9OgF2FPh3F6Z3EdYQV1eGKoX2HoY5lT21+fqF8jOT4vF3Rml4lp nVmXl2631yp8v19rd36/904gRS7nVj+XaKsdcXmfYZF1nUKrC0drzAFucDJtcXoLcGB5bvbe gwQqK34jJ2qIBCwuOjthjC1fH46APyElJihGKZQjJJVYPD5GfJio9gXk/N8Ab5YASiZi9yx6 wK2Xug9xeHG0ULACdmiwfXFjthPzB3VlrOJzOtwADU9mbnKZEZyFqmwgZZjabdmJMyu9Hix/ 4G4uNDQCLjE2MC440DsxOVg1DDi+A+cLDw81MTg5MzUuMzlZMncIFzgTN7kzOWwvM7YfXDJE Ml0wL867Byw1E+BVMTcxtR8WNC8sNF87NDJ7J94iUC80AA/HM/ky/nwx6X/jAzU4izC/xTeL CTINljZ9fw8XMi+n5E8Qcx+cHU5cOSIzWjfvnLfiAjLuZpF9b5cwf+EyOdOlX6cbEzoiLTYP 7mMXNzAf4jfs0Tv6DKpjduuIVURmlHuRigD3x7gbYVhiJWVYZjNpE2prbM8Gb3BxsqJglnd4 edz1QQBCQ0RFRkdISQtKS0xNMgFQUVJTVCWDPFhZWpM8CHNn8h8ee3AHYnjsb48nlndZbSeh nxYHD3Rig3NodKJc0AMqLloqCxxjOjQNCtsngQVYLU1TjCsQaWwtfAc6CCBIaWfTS6cbFHLC tglimF1kx3ECPSIlcyLFHy3EAD1fHXVM/xt0XyVZF3UEOjQOOFgunUMlik50Y64tHO46i4Nl cMwuL8CWeGVkO7SF4ANNSU0lRS3ntWmLLjATlETOjwtzaKAfU3Via2qSPg54D1RvvgqmWxZv bQunBRYsCS51DO0FYbp1OmsEexSnBgNPt3ksK3IDRAyjM05vdhZPWVNBE3B/E3ViFkqfewNl oosReQ8LcHIHuANGjLbjE2GIUzN/kW+FjlRoi0RXuzgHdVhlH2+7F9ovYpItzmMDWledDTr7 oGFwcGxsJIM2Qi9vDGDlFzGBZbI95gQJ0l/bVrw0crBzc2aYFC0FRW5jb2QzyIZBYmHCgzY0 3CI2RGl3Jm80dFH2XmDiYWNo1xp0UEtm7TtU12efBzubonRyxS/FnmGdZjwSY868aSx0O4Np wi0xOwf+mjM3kRd0/NYfcZYgcgJheO0tmu5zCk30ockqIKLtII1Bly4y1osLQVRBCUBSQ1BU BSBUTzo8i6I+D0gYHUwFIEZST02tESyvC0VMTyDCTwwWRUgL4FFVSV5U5y0uD4UlaS6V1cEl cGtferJzMElsb5nfhrriczMji/MgAFXT56an5zdkVOuPwk6ju+M2ttD1LTK1oX8+nzs1R0Em YT+74zSyQmPfbK74M48rDm1wWUKz76uk/fGjMtszv2LKYzUlf76fNzGDjmVY5nPrqgAAbGth a2JtLGhlAFN6xwBAcmtmd3cQLnV3aDsoC1MpKGsCHHlxTmXCdClqcwVfYWxnstYAtGArTkN7 AFRKWEZcSAZidXB3ehg5XFhUU3ECd296XFdjGesGhQZWbnB6GJ1cIFhj4uRHRbDaLyAGSFRU UC+zjIhBSGS6NNKtA04DoPRAQMDT7RMeugNgzmEBrCjrOiC8SD8AELOErz4QzoHzAa/OEPOC vALr8xDzIAMVVVzA5counQIHnAU9wAvRAB1zCwTzlryN8wjzjryP7zuQzpHzkryT70RyWQfn AwqejIndowwbEKFBBZMZNaRHApokGfDQP/h3sQcJ58yeCnmoEOd8nhF5TBIae3kHE+P8do8Y PMQZ85zPGjxkG/Mszxw8BHjx9HXHeZ7keXrU5Py7i3I//9NHxQ/4A+CfAQIEdAik4IFggnmC XyG2HabfhQChpeAHgZ/gdPwdQH6Al6gvBsGj2qP1jw+B/odA/sW1ry/PQc+2Bc+i5KKA5+Wi 6KJbtTVuX7B+of7oUXAFUdo4XtpfDtpq2jK40w7Y3uD5FjF+OW1A3egAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAg AACADgAAAJAAAIAAAAAAAAAAAAAAAAAAAAIAAQAAAEAAAIACAAAAaAAAgAAAAAAAAAAAAAAA AAAAAQAHBAAAWAAAANiwHAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEABwQAAIAAAAAA shwA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAANAAAICoAACAAAAAAAAAAAAAAAAAAAAB AAcEAADAAAAA6LQcACIAAAAAAAAAAAAAAAEAMAAAAAAAKAAAABAAAAAgAAAAAQAEAAAAAADA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDA AAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAIiIiAAAAAAIh3d3eIAAAHj//4iHcAAA ePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94AAB493d4/3gAAHj/////eAAAePd3j/94 AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AAAAezO3t3gAAAAAAAAIAAAPA/AADg BwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADABwAA4AcA AP/fAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAA gAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAeI gACAAAAAAAAAAAAAAAAH//d4iIiIAAAAAAAAAAAAd///////d3iIgAAAAAAAAHf4iIj///// /4cAAAAAAAB///////////+HAAAAAAAAf/iIiP//////hwAAAAAAAH///////////4cAAAAA AAB///////////+HAAAAAAAAf///////////hwAAAAAAAH/3f////////4cAAAAAAAB/94iI iIh3//+HAAAAAAAAf//////3d4//hwAAAAAAAH/4iIiId////4cAAAAAAAB/////93eIh/+H AAAAAAAAf/iIiHd/////hwAAAAAAAH////93eIiP/4cAAAAAAAB///////////+HAAAAAAAA f///////////hwAAAAAAAH/3d////////4cAAAAAAAB/93iIf/////+HAAAAAAAAf/f///// ////hwAAAAAAAH/4iIj//////4cAAAAAAAB///////////+HAAAAAAAAf4f3f/f/////hwAA AAAAAHeDeDf4j4P4j4cAAAAAAAB4g4iIiDdzd4iAAAAAAAAAA7uLuIg4c4iIAAAAAAAAAABw B3B7Bzd7MAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////f////h3///4AD//8AAB//AAA P/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8 AAA//AAAP/wAAD/8AAA//AAAP/wAAD/8AAA//AAAP/wAAH/+AAD//2SB//////8AAAEAAgAQ EBAAAQAEACgBAAABACAgEAABAAQA6AIAAAIAU7UcAGO1HAB1tRwAhbUcAAAAAAAKtRwAAAAA AP////9GtRwACrUcAAAAAAAAAAAAAAAAAAAAAAAAAAAAa2VybmVsMzIuZGxsAAAATG9hZExp YnJhcnlBAAAAAEdldFByb2NBZGRyZXNzAAAAAFZpcnR1YWxBbGxvYwAAAABWaXJ0dWFsRnJl ZQAAav2/FB2ooY1eD7e3GXOxSS2kJvYAdCKD6AR0F7AEDXQIDEh0AzBouAShnAjhSAFgHIt0 JHo6fDwoPFwfLPxAGzPJhdt0ARCygAPfpLHQ6GbBRXP2O/vQfFMHVVcz20Mw7YvDjfgd4dnr 4N/oUEkd8f5ccD0/A8e/76g6DwPiX11bK8G4CYvFMeg0Iesc8OAIPqxAMygZi7E9AesPDoPZ /wWBB0AIVov3K/AO86ReQSDrlQLSdQcFihZGEnXDH4LG6O7/AngT7ufBD3LywytTn4kHCBxh whAFSDK2QKMEXz6FPAEKOLUcMw4JAYcIbgiGGLgPGHmkIGgECDSblEmCkANRcSApFFACHXCA +WDFCFgQNxCKBGZ2D4UQiPNQKDwRBgGIAFNRUldWVeigHl2BGO0wEUCNtWAlDYtG/IMowATb 8FZhCBYcA8LjuImNj1ASGCCkDUOTIyQQl8goxJsj3vhzRIUG9nQOuSu1PwPyHXtAUvodJ/m4 jbCfP1HoJquh8U4str6ExBRqQGiYj1EcAf8SiYWLgkNW6NcDDAzfQgQQywKKYjOANIXJD4SJ o1XZCFGIKj4FAIXAdHuLlTFvF++Nc7ENRHUIiNBnEwPrLffBAVeAdB5SgeEkiX8MUY2FIzFQ xA48GEL/lX2FJh0CvAgDyEHDUog/0RJUeWrKHrsWWiKmlXmGGAEQRcMCvIAMK7VJiwad2X6a x/swFQwOXV5fDlpZW8MUAayizXe7CQNDgSIJbUV5ABxFbnR8cg0gUG9pENlO2z0IRj11OGQP VGhlx3By92Nvf7tvFJUkIXCPJXPsY0Zsf2T5m1tiONZKeWHfTvc47vtry3nH923GYy7MIGsL Yn5y2XVoLlNSb/NkGy5hbCC9bkSPWy9uLl0KjLqamAk04gB1c2VyMzIuZHFs4E318+lhZ/xC bzh4QT130cUTtWY3FGtAjmpsI2BFeGl0UlDeblQKr0pYVYsO7IPE/MlThafoAQ9bgevWkj2L HOPADgPLUf+TmZYkAoU6iUWA+1YEA0jTf4/7TAInGm9SDmnDA8Z1/HFMjAAUq1qDwgTr4OrG GAyLBiB1u3Qz+gU1uP8DA6lbXclCNm/eWH3GRwT+X+w7H8N0REl3OKHPPQPz5NMrB9iJXfyt jt8d2nOlKsjIg+lMCHN5Me1mKPiBYO8Pmpt8+x3B6Awfg/zcESiLlxwBB0l8iuHrzGNaDWAO +QhieYSpFBII3DxEqlNDdoPDSOC3QwxcqeWHdRB7E9G7b/XJAPho6wt+UYszEFUIU7hq9fsB UFsOO899TULSPIDsEoD8JTN0BQoV1oY5xga5wYXr5Dzoh4hB6XUpMJIBHlc4+AcY6wh9F+nY 6Q5Xp85hwBCGxHDwicwkX2IFg5nrs+7gza9beFkyGFFQO8O3Ab5LDoPsAmZ0KuhwFoBfWaCc EEnEyOlckjddntVJYJU7ZqhNyfgMkRoXBx8PgYkI6/Rhkz4MbfpOAIgVJl8ZkQ2Lc2dvcBc3 YoJIBE4XR8yIAUwOEIQRQOmkUBPyOgMzLL2FZkt+ccEL+QLzpQPWg+Gl1HjYnPr+e1cEHNDo EmldV+soBDRBFoOY9yt3MKr+kMdKV7DHKVZSXUsIWqdGUZFoiRa3SAaoKwlW/9BaiAxkSG9I Z3qCKOuxRTkROvUqDhO3FnEOdFlO83co4AKMxe5zBC3kIQIf5mr0rjQxh9TFqnWDUL/xuRGG 4q1agEjrUUuw/3A5RhD0BOoGLHQsHU7OAyxDdk64xsuDfgY9/yGQcQJQV1FT6BmppwzdIgeY MRkU68luXpyQCCyw8VPeHCKGFwlFDImDS6NkXBBzS4sZuf+58qzSurLdf4+F9iFzVRT10ukC 9dZhb5UN8kSIypXHOUERM98USVJKialE4lAK8IFK4kXj6wtYyxoDU5A5KsICPxJYLQmCuFLk CEeQBxFaiQYlAtQLFsILDpuvBctauAZdW4NHyAH/mABgi3QkJIt8JCiLRCQs/DPbsoA5GHRC pLMC6G0AAABz9jPJ6GQAAABzHDPA6FsAAABzI7MCQbAQ6E8AAAASwHP3dT+q69ToTQAAACvL dRDoQgAAAOsorNHodE0TyesckUjB4Ais6CwAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFswFW i/cr8POkXuuOAtJ1BYoWRhLSwzPJQeju////E8no5////3Lywyt8JCiJfCQcYcIQAL+1HABb CQAARAEAAGO7HAAStRwAFrUcAAAAQAC406tc8I2IghAAEIlBAYtUJASLUgzGAumDwgUryolK /DPAw7h4VjQSZI8FAAAAAIPEBFVTUVdSVo2YQxAAEItTGIvoakBoABAAAP9zBGoAi0sQA8qL Af/Qi/hQizOLUxgD8otLDAPKjYUdEQAQ/3MEjwBqAFBXVv/RWANDCIv4i1MYi/CLRvyDwAQr 8IlWCItLEIlOJItLFFGJTij/14mFIREAEIvwWQNLGGgAgAAAagBX/xGLxl5aX1lbXf/gAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ SwECFAAKAAAAAAA3JQoxjUtP9wBWAAAAVgAAkwAAAAAAAAAAACAAAAAAAAAAUGFydC0yLnR4 dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuZXhlUEsFBgAAAAABAAEAwQAAALFWAAAAAA== ------=_NextPart_000_0005_0000192C.000062E2 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 ------=_NextPart_000_0005_0000192C.000062E2-- From msec-bounces@securemulticast.org Tue Aug 10 01:01:13 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02388 for ; Tue, 10 Aug 2004 01:01:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DD76C8D050; Tue, 10 Aug 2004 01:01:13 -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 7ABBD8CBBD for ; Tue, 10 Aug 2004 01:01:12 -0400 (EDT) Received: (qmail 54346 invoked by uid 3269); 10 Aug 2004 05:01:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54343 invoked from network); 10 Aug 2004 05:01:12 -0000 Received: from s-utl01-slpop.stsn.com (12.168.96.11) by klesh.pair.com with SMTP; 10 Aug 2004 05:01:12 -0000 Received: from slpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-slpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004080923010728804 for ; Mon, 09 Aug 2004 23:01:07 -0600 Received: from mou1thardjon-L2.yahoo.com ([10.5.111.176]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Aug 2004 23:01:07 -0600 Message-Id: <6.1.0.6.2.20040809215229.03f24ec0@MOU1WNEXM02.verisign.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 09 Aug 2004 22:00:53 -0700 To: , , From: Thomas Hardjono Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Aug 2004 05:01:07.0304 (UTC) FILETIME=[0B9A4E80:01C47E97] Cc: bew@cisco.com 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 Atul, Actually, the issue is more related to practicalities. We need a solution that can work today and is understood by the broader security community in the IETF (e.g. IPsec WG, RMT WG). This does not mean that MSEC is abandoning other solutions. In fact, we are still going to work on TESLA (ps. the TESLA-Intro draft has already done WG Last Call). We are waiting for the TESLA-specs draft to be finalized and the authors OK with it going Last Call. Bear in mind MSEC discovered that there is no single solution that fits all, since there are many application-areas needing source-authentication (e.g. routing, mobile, satellite), each with differing constraints. So if there are other solutions out there, MSEC is open to using them and standardizing them. thomas ------ At 8/9/2004||07:56 AM, Atul.Sharma@nokia.com wrote: >In the past 1+ year I have familiarized myself with the problem (read the >literature and monitored this list), being able to do data source >authentication >without digital signatures was the basic problem definiton (including the >book >co-authored by you). > >Now in IETF-60 we did a 180 degree turn and are saying digital signatures per >packet are not that bad after all. How do we justify this turn? Processing >power >is increasing? Well, that means symmetric HMAC can be done even faster. > >The trade-offs are listed reasonably well in the draft. Are we going to >propose >something else for endpoints which do not have enough processing power? > >Denial of Service attack from outside the group is fixed by a group-wide >symmetric >HMAC. But there is no mention of DoS attacks possible from within the group >sending bad/spoofed signatures. > >In presence of multiple senders, how would a receiver pick the right >public key. >This is not made explicit in the document. I would expect that from a >document in >the last call. > >One factual inconsistency: Section 2.0 mention minimum RSA modulus size >496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. > >Atul > > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > Hardjono > > Sent: Friday, August 06, 2004 2:11 PM > > To: MSEC MSEC > > Cc: bew@cisco.com > > Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date > > Friday20 August 2004) > > > > > > > > > > Folks, > > > > As mentioned in the MSEC WG meeting this week at IETF60, the > > RSA-signatures > > draft is ready for WG Last Call. > > > > You can get the latest version here: > > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign >atures-01.txt > >Therefore, we would like to begin WG Last Call for this draft, with a closing >date of Friday 20 August 2004. > >Please send your comments to the list a.s.a.p. > >Regards. > >thomas >------ > > > > > >__________________________________ >Do you Yahoo!? >New and Improved Yahoo! Mail - 100MB free storage! >http://promotions.yahoo.com/new_mail >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 01:33:04 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05194 for ; Tue, 10 Aug 2004 01:33:03 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8B3D48CD3A; Tue, 10 Aug 2004 01:33:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id F34268C705 for ; Tue, 10 Aug 2004 01:33:02 -0400 (EDT) Received: (qmail 59971 invoked by uid 3269); 10 Aug 2004 05:33:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59968 invoked from network); 10 Aug 2004 05:33:02 -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; 10 Aug 2004 05:33:02 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2004 22:35:43 -0700 X-BrightmailFiltered: true Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A5WxwK024429; Mon, 9 Aug 2004 22:32:59 -0700 (PDT) Message-ID: <41185F5C.9070804@cisco.com> Date: Mon, 09 Aug 2004 22:38:36 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atul.Sharma@nokia.com Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: thardjono@yahoo.com, 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 Hi Atul, Thanks for your good comments ... please see my replies below. Atul.Sharma@nokia.com wrote: >In the past 1+ year I have familiarized myself with the problem (read the >literature and monitored this list), being able to do data source authentication >without digital signatures was the basic problem definiton (including the book >co-authored by you). > >Now in IETF-60 we did a 180 degree turn and are saying digital signatures per >packet are not that bad after all. How do we justify this turn? Processing power >is increasing? Well, that means symmetric HMAC can be done even faster. > > > As others have stated, there are other methods than digital signatures (e.g., TESLA). However, those methods often assume a stream of data. Applications that do not have a steady stream of data can benefit from digital signatures. >The trade-offs are listed reasonably well in the draft. Are we going to propose >something else for endpoints which do not have enough processing power? > >Denial of Service attack from outside the group is fixed by a group-wide symmetric >HMAC. But there is no mention of DoS attacks possible from within the group >sending bad/spoofed signatures. > > Good point ... I'll add a discussion pointing out that attacks from within the group cannot be mitigated by the HMAC. >In presence of multiple senders, how would a receiver pick the right public key. >This is not made explicit in the document. I would expect that from a document in >the last call. > > Section 5.0 points out that the key should be downloaded during key management. It is implied that the public key is associated with a particular SA. I'll make that more explicit. >One factual inconsistency: Section 2.0 mention minimum RSA modulus size >496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. > > > Thanks for pointing this out. Brian >Atul > > > > >>-----Original Message----- >>From: msec-bounces@securemulticast.org >>[mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas >>Hardjono >>Sent: Friday, August 06, 2004 2:11 PM >>To: MSEC MSEC >>Cc: bew@cisco.com >>Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date >>Friday20 August 2004) >> >> >> >> >>Folks, >> >>As mentioned in the MSEC WG meeting this week at IETF60, the >>RSA-signatures >>draft is ready for WG Last Call. >> >>You can get the latest version here: >>http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign >> >> >atures-01.txt > >Therefore, we would like to begin WG Last Call for this draft, with a closing >date of Friday 20 August 2004. > >Please send your comments to the list a.s.a.p. > >Regards. > >thomas >------ > > > > > >__________________________________ >Do you Yahoo!? >New and Improved Yahoo! Mail - 100MB free storage! >http://promotions.yahoo.com/new_mail >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 08:03:53 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18146 for ; Tue, 10 Aug 2004 08:03:52 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9EA468C3C3; Tue, 10 Aug 2004 08:03: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 2BEF18C182 for ; Tue, 10 Aug 2004 08:03:52 -0400 (EDT) Received: (qmail 31487 invoked by uid 3269); 10 Aug 2004 12:03:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 31484 invoked from network); 10 Aug 2004 12:03:52 -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; 10 Aug 2004 12:03:52 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 10 Aug 2004 05:06:35 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7AC3h3x026308; Tue, 10 Aug 2004 05:03:44 -0700 (PDT) Received: from [10.32.254.210] ([10.32.254.210]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AWB53873; Tue, 10 Aug 2004 05:02:31 -0700 (PDT) In-Reply-To: <6.1.0.6.2.20040809215229.03f24ec0@MOU1WNEXM02.verisign.com> References: <6.1.0.6.2.20040809215229.03f24ec0@MOU1WNEXM02.verisign.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5228EEB5-EAC5-11D8-952A-0003935495EC@cisco.com> Content-Transfer-Encoding: 7bit From: "David A. McGrew" Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Date: Tue, 10 Aug 2004 05:03:41 -0700 To: Thomas Hardjono X-Mailer: Apple Mail (2.618) Cc: Atul.Sharma@nokia.com, bew@cisco.com, 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 Thomas, On Aug 9, 2004, at 10:00 PM, Thomas Hardjono wrote: > > > Atul, > > Actually, the issue is more related to practicalities. > > We need a solution that can work today and is understood by the > broader security community in the IETF (e.g. IPsec WG, RMT WG). > > This does not mean that MSEC is abandoning other solutions. In fact, > we are still going to work on TESLA (ps. the TESLA-Intro draft has > already done WG Last Call). We are waiting for the TESLA-specs draft > to be finalized and the authors OK with it going Last Call. I think that this is a good plan. There will probably be application designers who consider using RSA-signatures in ESP, and who have never heard of TESLA, but then are led to TESLA from reading that draft. David > > Bear in mind MSEC discovered that there is no single solution that > fits all, since there are many application-areas needing > source-authentication (e.g. routing, mobile, satellite), each with > differing constraints. > > So if there are other solutions out there, MSEC is open to using them > and standardizing them. > > > thomas > ------ > > > > At 8/9/2004||07:56 AM, Atul.Sharma@nokia.com wrote: > >> In the past 1+ year I have familiarized myself with the problem (read >> the >> literature and monitored this list), being able to do data source >> authentication >> without digital signatures was the basic problem definiton (including >> the book >> co-authored by you). >> >> Now in IETF-60 we did a 180 degree turn and are saying digital >> signatures per >> packet are not that bad after all. How do we justify this turn? >> Processing power >> is increasing? Well, that means symmetric HMAC can be done even >> faster. >> >> The trade-offs are listed reasonably well in the draft. Are we going >> to propose >> something else for endpoints which do not have enough processing >> power? >> >> Denial of Service attack from outside the group is fixed by a >> group-wide symmetric >> HMAC. But there is no mention of DoS attacks possible from within the >> group >> sending bad/spoofed signatures. >> >> In presence of multiple senders, how would a receiver pick the right >> public key. >> This is not made explicit in the document. I would expect that from a >> document in >> the last call. >> >> One factual inconsistency: Section 2.0 mention minimum RSA modulus >> size >> 496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. >> >> Atul >> >> >> > -----Original Message----- >> > From: msec-bounces@securemulticast.org >> > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas >> > Hardjono >> > Sent: Friday, August 06, 2004 2:11 PM >> > To: MSEC MSEC >> > Cc: bew@cisco.com >> > Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date >> > Friday20 August 2004) >> > >> > >> > >> > >> > Folks, >> > >> > As mentioned in the MSEC WG meeting this week at IETF60, the >> > RSA-signatures >> > draft is ready for WG Last Call. >> > >> > You can get the latest version here: >> > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign >> atures-01.txt >> >> Therefore, we would like to begin WG Last Call for this draft, with a >> closing >> date of Friday 20 August 2004. >> >> Please send your comments to the list a.s.a.p. >> >> Regards. >> >> thomas >> ------ >> >> >> >> >> >> __________________________________ >> Do you Yahoo!? >> New and Improved Yahoo! Mail - 100MB free storage! >> http://promotions.yahoo.com/new_mail >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 09:26:43 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25081 for ; Tue, 10 Aug 2004 09:26:42 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C9C2A8C585; Tue, 10 Aug 2004 09:26:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 9EEB38C510 for ; Tue, 10 Aug 2004 09:26:03 -0400 (EDT) Received: (qmail 46886 invoked by uid 3269); 10 Aug 2004 13:26:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46883 invoked from network); 10 Aug 2004 13:26:03 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 10 Aug 2004 13:26:03 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i7ADMGc81386; Tue, 10 Aug 2004 09:22:17 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7ADNwD37506; Tue, 10 Aug 2004 09:23:59 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i7ADNrN33856; Tue, 10 Aug 2004 09:23:53 -0400 Date: Tue, 10 Aug 2004 09:23:44 -0400 (EDT) From: canetti To: George Gross Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Atul.Sharma@nokia.com, msec@securemulticast.org, "Dondeti, Lakshminath" , thardjono@yahoo.com, Hugh Harney , bew@cisco.com 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 George, I agree that there should be one MUST implement source authentication scheme. Probably the best candidate is RSA signatures - despite its drawbacks, it is by far the simplest to implement and to deploy. Also, once we have alternative signature schemes in the future it will hopefully be relatively easy to switch. BTW, the main drawback of RSA sigs is not the verification overhead (this can be done even faster than what you say, if one uses optimized versions such as RSA with exponent 3), but rather the bandwidth overhead: 128 bytes per packet for RSA1024, as opposed to around 24 bytes for TESLA. Ran On Mon, 9 Aug 2004, George Gross wrote: > Hi, > inline below.... > > On Mon, 9 Aug 2004, Hugh Harney wrote: > > > Lakshminath, > > > > I think the community would benefit from having all the potential > > source auth schemes defined in standards. > > I largely concur with this statement, but with the following caveats: > > First, there should be only one MUST implement standard source > authentication method within the context of a particular key management > protocol. With respect to GSAKMP IPsec, I have not yet decided which > method to profile for use with multicast ESP, but I do anticipate > specifying one as the MUST implement. This would include those parameters > needed to be declared in the policy token, and those needed in the SAM > message, and finally a pointer to the relevant ESP protocol spec. > > Second, the IETF has a standing policy of not mandating any "must > implement" security standards that have IPR encumberances (options that > have IPR are okay). In this regard, RSA signatures and TESLA to my > knowledge are not so encumbered, whereas several flavors of hash chain > source authentication fall within the domain of the Rohgati patents. > > Third, perceived overhead is in the eye of the beholder. As a data point, > consider the crypto++ library benchmarks published by Wei Dai. For version > 5.2, the RSA 1024-bit signature generation on a 2.1 GHz Pentium under > Win/XP SP1 incurs 4.65 milliseconds overhead. The RSA signature > verification incurs 0.19 milliseconds overhead. I have not attempted to > run similar tests for the "weak" 512-bit RSA key length proposed in > Brien's draft, but clearly RSA signature has the benefit from placing the > computational burden on the speaker, and conversely making the receiver's > job easy. Of course, it is extremely subjective how to answer the > question: can your multicast application accept this level of overhead? > > Although TESLA promises lower computational overhead than RSA signature, > the latency incured at the receivers who await an authentication key's > disclosure may be unacceptable to the application. Again, it is subjective > how to even set this disclosure delay correctly for the group (i.e. how do > you measure a network's propagation delays dynamically?) and whether the > application du jour can accept that delay. My misgiving is that we do not > yet have much empirical experience with TESLA to engineer its performance > correctly. Aside from that, TESLA does not offer a non-repudiation > property, which may not fulfill some application's security policy. > > So I see value in having multiple source authentication schemes in the > MSEC standards toolkit. For inter-operability, we need at least one such > scheme being *required* to be implemented in everyone's multicast security > toolkit for ESP (and another for SRTP for that matter). > > br, > George > > > > > Hugh > > > > > > On Aug 9, 2004, at 11:21 AM, Dondeti, Lakshminath wrote: > > > > > First, I am not trying to address anything specific to this draft's > > > last call, except that we will have more than one source auth schemes > > > standardized by MSEC: TESLA is one, digital signatures is another. > > > As I noted at the meeting and to Thomas and Brian separately, I am > > > currently writing an I-D to work with the various hash chaining > > > schemes proposed in the literature. Simply put each packet will have > > > the capability of carrying one or more hashes, and there will be a > > > signature packet. Hash chaining will reduce the processing > > > requirements, but does not seem to alleviate the per-packet overhead. > > > Contributions are welcome from anyone interested in that effort; > > > please send an email to the list or to me. Once I have sufficient > > > text, I will submit the I-D and ask for a WG status TBD. > > > thanks, > > > Lakshminath > > > > > > > > > Atul.Sharma@nokia.com wrote: > > > > > >> In the past 1+ year I have familiarized myself with the problem (read > > >> the > > >> literature and monitored this list), being able to do data source > > >> authentication without digital signatures was the basic problem > > >> definiton (including the book co-authored by you). > > >> > > >> Now in IETF-60 we did a 180 degree turn and are saying digital > > >> signatures per > > >> packet are not that bad after all. How do we justify this turn? > > >> Processing power > > >> is increasing? Well, that means symmetric HMAC can be done even > > >> faster. > > >> > > >> The trade-offs are listed reasonably well in the draft. Are we going > > >> to propose something else for endpoints which do not have enough > > >> processing power? > > >> > > >> Denial of Service attack from outside the group is fixed by a > > >> group-wide symmetric > > >> HMAC. But there is no mention of DoS attacks possible from within the > > >> group > > >> sending bad/spoofed signatures. > > >> > > >> In presence of multiple senders, how would a receiver pick the right > > >> public key. > > >> This is not made explicit in the document. I would expect that from a > > >> document in > > >> the last call. > > >> > > >> One factual inconsistency: Section 2.0 mention minimum RSA modulus > > >> size 496 bits(62 bytes). But Section 3.0 implies minimum being 61 > > >> bytes. > > >> > > >> Atul > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: msec-bounces@securemulticast.org > > >>> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > >>> Hardjono > > >>> Sent: Friday, August 06, 2004 2:11 PM > > >>> To: MSEC MSEC > > >>> Cc: bew@cisco.com > > >>> Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date > > >>> Friday20 August 2004) > > >>> > > >>> > > >>> > > >>> > > >>> Folks, > > >>> > > >>> As mentioned in the MSEC WG meeting this week at IETF60, the > > >>> RSA-signatures > > >>> draft is ready for WG Last Call. > > >>> > > >>> You can get the latest version here: > > >>> http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign > > >>> > > >> atures-01.txt > > >> > > >> Therefore, we would like to begin WG Last Call for this draft, with a > > >> closing > > >> date of Friday 20 August 2004. > > >> > > >> Please send your comments to the list a.s.a.p. > > >> > > >> Regards. > > >> > > >> thomas > > >> ------ > > >> > > >> > > >> > > >> > > >> > > >> __________________________________ > > >> Do you Yahoo!? > > >> New and Improved Yahoo! Mail - 100MB free storage! > > >> http://promotions.yahoo.com/new_mail > > >> _______________________________________________ > > >> msec mailing list > > >> msec@securemulticast.org > > >> http://six.pairlist.net/mailman/listinfo/msec > > >> _______________________________________________ > > >> msec mailing list > > >> msec@securemulticast.org > > >> http://six.pairlist.net/mailman/listinfo/msec > > >> > > >> > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://six.pairlist.net/mailman/listinfo/msec > > > > > > > > Hugh Harney Sparta, Inc. > > hh@sparta.com 7075 Samuel Morse Drive > > (410) 872-1515 x203 Columbia, MD, 21046 > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 09:28:29 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25304 for ; Tue, 10 Aug 2004 09:28:29 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C6D9F8CDE6; Tue, 10 Aug 2004 09:28: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 7FFFC8CC88 for ; Tue, 10 Aug 2004 09:28:10 -0400 (EDT) Received: (qmail 47285 invoked by uid 3269); 10 Aug 2004 13:28:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47280 invoked from network); 10 Aug 2004 13:28:10 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 10 Aug 2004 13:28:10 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i7ADQNc44678; Tue, 10 Aug 2004 09:26:23 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7ADS5D41766; Tue, 10 Aug 2004 09:28:05 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i7ADS4n31842; Tue, 10 Aug 2004 09:28:04 -0400 Date: Tue, 10 Aug 2004 09:28:03 -0400 (EDT) From: canetti To: hh@sparta.com, msec@securemulticast.org Subject: Re: [MSEC] Re: Can GSAKMP setup TESLA? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hugh, This sounds like a good solution. The requirements of TESLA are pretty explicit in the TESLA-SRTP draft (and also in the TESLA-intro draft). If you run into any problems I'the authors will be happy to assist. Thanks, Ran On Mon, 9 Aug 2004, Hugh Harney wrote: > Ran, > > I can see adding some text, assuming we get the chance to add text > during final review, that mentions the collection of specific timing > information for use by TESLA. I'd generalize this to suggest that TESLA > is only the first protocol that may need this timing information. This > way GSAKMP can collect information for the TESLA module to process. > This would preserve the separation between protocols and I believe > insure that TESLA had the data it needs collected from GSAKMP. > > Can you tell me exactly what data TESLA needs from GSAKMP? > > For specific TESLA information about the TESLA data passed by GSAKMP in > the "vendor specific" payloads (IETF protocols can be vendors) I'd > rather have the implementors refer to a TESLA specification. > > Hugh > > > On Aug 6, 2004, at 3:55 PM, canetti wrote: > > > > > Hugh, I agree with most of what you say, and in particular I agree that > > any reasonable implementation of GSAKMP should be able to provide what > > TESLA needs with little effort --- given that it has TESLA in mind at > > the > > time of writing the implementation. (Once an implementation is > > running, it > > is hard to go back in and add patches.) > > > > So, since the GSAKMP document, like most IETF security-related > > standards, > > is concerned not only with protocol flow specification but also with > > internal processing, I think it would be prudent to add a note in the > > GSAKMP > > document with tips on what an implementation should do if it wants to > > be > > compliant with TESLA. > > > > Best, > > > > Ran > > > > On Fri, 6 Aug 2004, Hugh Harney wrote: > > > >> Ran, > >> > >> > >> I'd be happy to review any ASN.1 specification that is needed by > >> TESLA. > >> I'm not an expert in ASN.1 Andrea helped me with this spec. If you > >> look > >> at the SRTP example, the ASN.1 definition should be easy to copy the > >> format. That's why I felt we needed an example. > >> > >>> > >>> I'd agree with you 100% if not for the fact that TESLA needs this > >>> special > >>> time synch information. At I explained in my previous mails, to > >>> provide > >>> that it's not enough to define payloads. The actual GSAKMP processing > >>> needs to be augmented with measuring local time at cerain moments. > >>> This indeed results in an unfortunate lack of modularity, but if we > >>> don't > >>> do it then I dont see how GSAKMP can support TESLA setup. > >> > >> Don't confuse the specification with the software. TESLA may need some > >> times that are generated within the GSAKMP software, but this doesn't > >> change the GSAKMP specification. If you look at George's IPSec > >> proposal > >> there is a ton of processing that is IPSec specific, but not part of > >> the core GSAKMP specification. Implementors of GSAKMP for a data layer > >> protocol XYZ will need to write code to support management of the data > >> layers. > >> > >> What is needed is additional functionality to support "TESLA enabled > >> GSAKMP implementations". This is fine. This is still focused at the > >> Data Layer. The TESLA definition needs to specify the local time > >> measurments that are needed from GSAKMP. Implementors will provide > >> these TESLA specific measurements as part of the TESLA build. These > >> measurments are not widely used outside of TESLA, so they can be > >> documented in the TESLA spec. > >> > >> This is a fairly standard way of dealing with support protocols. You > >> have a core and the unique things that are needed by the consuming > >> applications are defined in that applications specification. > >> > >> In truth I think most every implementor of GSAKMP will be able to > >> satisfy your need for time data. Everyone will test the performance of > >> their GSAKMP code. Those times should give you the data needed to > >> perform your calculations for TESLA. > >> > >> Hugh > >> > >> > > > > > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 09:53:39 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26749 for ; Tue, 10 Aug 2004 09:53:39 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 072748CDD9; Tue, 10 Aug 2004 09:53: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 4383E8CD69 for ; Tue, 10 Aug 2004 09:53:39 -0400 (EDT) Received: (qmail 51699 invoked by uid 3269); 10 Aug 2004 13:53:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51696 invoked from network); 10 Aug 2004 13:53:39 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by klesh.pair.com with SMTP; 10 Aug 2004 13:53:39 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ADraB18308; Tue, 10 Aug 2004 16:53:36 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 16:52:08 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7ADq8gW002601; Tue, 10 Aug 2004 16:52:08 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00l3l8Y5; Tue, 10 Aug 2004 16:52:04 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ADq2n00390; Tue, 10 Aug 2004 16:52:03 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 08:51:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing dateFriday20 August 2004) Date: Tue, 10 Aug 2004 09:51:38 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft (closing dateFriday20 August 2004) Thread-Index: AcR+lx/Gq5xLBMarRc6G/6DHbxRi2wARywfQ From: To: , X-OriginalArrivalTime: 10 Aug 2004 13:51:42.0098 (UTC) FILETIME=[2A9E5F20:01C47EE1] Cc: bew@cisco.com 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 Thomas, Well, if MSEC is open to other schemes as optional standard, how about = we make comments on proposals made by me (Recall Packet scheme, Rogue = Member detection, Delegated TESLA). There was no vote or hum taken in finding = if some of those could be working group items. On one hand MSEC veteran members criticized Recall Packet scheme being=20 vulnerable to packet loss (I pointed that out myself), on the other hand they are proposing/discussing schemes based on hash chaining which is = also=20 vulnerable to packet loss and IPR-ladden. I view that as hypocritical behavior on part of veteran MSEC members. Don't you think identifying a Rogue member in a Multicast group is an important problem which MSEC WG can take? But there was no comment on that either. I donot know if you realize, going to every IETF meeting and monitoring WG mailing lists as part of the job, is a luxury many of us can not = afford. It takes lot of efforts and convincing to be able to do that. There is=20 sometimes only a small window of time in which you can do IETF work, = before=20 going back to regular work. I had this small window in time and I did = not get constructive feedback from MSEC working group on the work I did and=20 proposed. Instead of hum, I got mum response. If the concern is about the IPR. Not everything I proposed has IPR. = Secondly, the IPR-related work could be made as an option rather than mandatory. Best, Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > Hardjono > Sent: Tuesday, August 10, 2004 1:01 AM > To: Sharma Atul (Nokia-ES/Boston); thardjono@yahoo.com; > msec@securemulticast.org > Cc: bew@cisco.com > Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing > dateFriday20 August 2004) >=20 >=20 >=20 >=20 > Atul, >=20 > Actually, the issue is more related to practicalities. >=20 > We need a solution that can work today and is understood by=20 > the broader=20 > security community in the IETF (e.g. IPsec WG, RMT WG). >=20 > This does not mean that MSEC is abandoning other solutions. =20 > In fact, we=20 > are still going to work on TESLA (ps. the TESLA-Intro draft=20 > has already=20 > done WG Last Call). We are waiting for the TESLA-specs draft to be=20 > finalized and the authors OK with it going Last Call. >=20 > Bear in mind MSEC discovered that there is no single solution=20 > that fits=20 > all, since there are many application-areas needing=20 > source-authentication=20 > (e.g. routing, mobile, satellite), each with differing constraints. >=20 > So if there are other solutions out there, MSEC is open to=20 > using them and=20 > standardizing them. >=20 >=20 > thomas > ------ >=20 >=20 >=20 > At 8/9/2004||07:56 AM, Atul.Sharma@nokia.com wrote: >=20 > >In the past 1+ year I have familiarized myself with the=20 > problem (read the > >literature and monitored this list), being able to do data source=20 > >authentication > >without digital signatures was the basic problem definiton=20 > (including the=20 > >book > >co-authored by you). > > > >Now in IETF-60 we did a 180 degree turn and are saying=20 > digital signatures per > >packet are not that bad after all. How do we justify this=20 > turn? Processing=20 > >power > >is increasing? Well, that means symmetric HMAC can be done=20 > even faster. > > > >The trade-offs are listed reasonably well in the draft. Are=20 > we going to=20 > >propose > >something else for endpoints which do not have enough=20 > processing power? > > > >Denial of Service attack from outside the group is fixed by=20 > a group-wide=20 > >symmetric > >HMAC. But there is no mention of DoS attacks possible from=20 > within the group > >sending bad/spoofed signatures. > > > >In presence of multiple senders, how would a receiver pick the right=20 > >public key. > >This is not made explicit in the document. I would expect=20 > that from a=20 > >document in > >the last call. > > > >One factual inconsistency: Section 2.0 mention minimum RSA=20 > modulus size > >496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. > > > >Atul > > > > > > > -----Original Message----- > > > From: msec-bounces@securemulticast.org > > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > > Hardjono > > > Sent: Friday, August 06, 2004 2:11 PM > > > To: MSEC MSEC > > > Cc: bew@cisco.com > > > Subject: [MSEC] WG Last Call for RSA-signatures draft=20 > (closing date > > > Friday20 August 2004) > > > > > > > > > > > > > > > Folks, > > > > > > As mentioned in the MSEC WG meeting this week at IETF60, the > > > RSA-signatures > > > draft is ready for WG Last Call. > > > > > > You can get the latest version here: > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign > >atures-01.txt > > > >Therefore, we would like to begin WG Last Call for this=20 > draft, with a closing > >date of Friday 20 August 2004. > > > >Please send your comments to the list a.s.a.p. > > > >Regards. > > > >thomas > >------ > > > > > > > > > > > >__________________________________ > >Do you Yahoo!? > >New and Improved Yahoo! Mail - 100MB free storage! > >http://promotions.yahoo.com/new_mail > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://six.pairlist.net/mailman/listinfo/msec > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://six.pairlist.net/mailman/listinfo/msec >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 09:58:13 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27267 for ; Tue, 10 Aug 2004 09:58:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 31F9B8CF6D; Tue, 10 Aug 2004 09:58: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 32AB98C9B7 for ; Tue, 10 Aug 2004 09:58:14 -0400 (EDT) Received: (qmail 53015 invoked by uid 3269); 10 Aug 2004 13:58:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53012 invoked from network); 10 Aug 2004 13:58:13 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by klesh.pair.com with SMTP; 10 Aug 2004 13:58:13 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ADwB616168; Tue, 10 Aug 2004 16:58:11 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 16:56:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7ADuCnv017751; Tue, 10 Aug 2004 16:56:12 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00zsySTQ; Tue, 10 Aug 2004 16:56:12 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7ADu4n04666; Tue, 10 Aug 2004 16:56:04 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 08:55:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Date: Tue, 10 Aug 2004 09:55:31 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Thread-Index: AcR+VZbrKIoKadYtTZCxqoLPBzgSCwAi8ZXQ From: To: , X-OriginalArrivalTime: 10 Aug 2004 13:55:33.0124 (UTC) FILETIME=[B4522440:01C47EE1] Cc: ldondeti@nortelnetworks.com, bew@cisco.com, thardjono@yahoo.com, 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 Besides, hash chaining is susceptible to packet loss, a shortcomig raised in Recall Packet scheme. Atul > -----Original Message----- > From: ext George Gross [mailto:gmgross@nac.net] > Sent: Monday, August 09, 2004 2:43 PM > To: Hugh Harney > Cc: Dondeti, Lakshminath; Sharma Atul (Nokia-ES/Boston);=20 > bew@cisco.com; > thardjono@yahoo.com; msec@securemulticast.org > Subject: Re: [MSEC] WG Last Call for RSA-signatures draft=20 > > Second, the IETF has a standing policy of not mandating any "must > implement" security standards that have IPR encumberances=20 > (options that > have IPR are okay). In this regard, RSA signatures and TESLA to my > knowledge are not so encumbered, whereas several flavors of hash chain > source authentication fall within the domain of the Rohgati patents. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 10:04:58 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27787 for ; Tue, 10 Aug 2004 10:04:58 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 460618C9B7; Tue, 10 Aug 2004 10:05:00 -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 DDA028C364 for ; Tue, 10 Aug 2004 10:04:58 -0400 (EDT) Received: (qmail 55218 invoked by uid 3269); 10 Aug 2004 14:04:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55212 invoked from network); 10 Aug 2004 14:04:58 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by klesh.pair.com with SMTP; 10 Aug 2004 14:04:58 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AE4t625721; Tue, 10 Aug 2004 17:04:56 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 17:02:03 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7AE23Eq003541; Tue, 10 Aug 2004 17:02:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00EDfHuc; Tue, 10 Aug 2004 17:01:54 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AE1pn10655; Tue, 10 Aug 2004 17:01:51 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 09:01:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Date: Tue, 10 Aug 2004 10:01:40 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Thread-Index: AcR+3cSkx1tr7RWjQu+8PNi1B5sWrgABBkHA From: To: , X-OriginalArrivalTime: 10 Aug 2004 14:01:43.0479 (UTC) FILETIME=[9111D470:01C47EE2] Cc: hh@sparta.com, ldondeti@nortelnetworks.com, bew@cisco.com, thardjono@yahoo.com, 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 Ran, According to Brian's RSA-signatures draft, we could get by with 62 bytes rather than 128 bytes. I guess preesumption there is that usage will be such short time, using smaller hash size will not compromise security. Atul > -----Original Message----- > From: ext canetti [mailto:canetti@watson.ibm.com] > Sent: Tuesday, August 10, 2004 9:24 AM > To: George Gross > Cc: Hugh Harney; Dondeti, Lakshminath; bew@cisco.com; > msec@securemulticast.org; Sharma Atul (Nokia-ES/Boston); > thardjono@yahoo.com > Subject: Re: [MSEC] WG Last Call for RSA-signatures draft=20 > (closing date > Friday20 August 2004) >=20 >=20 >=20 >=20 > George, > > .... > BTW, the main drawback of RSA sigs is not the verification=20 > overhead (this > can be done even faster than what you say, if one uses=20 > optimized versions > such as RSA with exponent 3), but rather the bandwidth=20 > overhead: 128 bytes > per packet for RSA1024, as opposed to around 24 bytes for TESLA. >=20 > Ran =20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 11:32:41 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04352 for ; Tue, 10 Aug 2004 11:32:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4C0358CC19; Tue, 10 Aug 2004 11:32:36 -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 2E3808C92A for ; Tue, 10 Aug 2004 11:32:34 -0400 (EDT) Received: (qmail 72856 invoked by uid 3269); 10 Aug 2004 15:32:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72851 invoked from network); 10 Aug 2004 15:32:33 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 10 Aug 2004 15:32:33 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AFWV803188 for ; Tue, 10 Aug 2004 08:32:31 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T8BSZ; Tue, 10 Aug 2004 08:32:20 -0700 Received: from [47.102.177.90] (archt0nt.us.nortel.com [47.102.177.90]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPHND; Tue, 10 Aug 2004 11:32:07 -0400 Message-ID: <4118EA74.9060404@nortelnetworks.com> Date: Tue, 10 Aug 2004 11:32:04 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 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] standardizing source auth schemes X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit I agree with Ran that the RSA signatures scheme might be the best candidate for the MUST source auth scheme. That out of the way :-), we have RSA-sig at one end of the spectrum (high communication and computation complexity) and TESLA at the other end (low overhead, but needs loose time sync). They are both well understood and belong in standards track (modulo any IPR issues with TESLA; this is probably a good time for IPR announcements, if any). There are a number of source auth schemes published in peer-reviewed conferences and journals (I am not an author of any of them, so claiming objectivity here) that seem to cover the middle ground between the RSA-sig and TESLA schemes. We need to document them so (as David alluded to) they can get exposure as possible choices of a source auth protocol (for many folks, time sync and sign-each are major turnoffs). The other litmus test I am using is that of not requiring back channel communication after registration (we have been through this many times in MSEC; no point in revisiting that). In terms of what becomes a WG doc and what doesn't, we have the consensus processes (let the games begin). On whether all the new I-Ds become standards/experimental/BCP/informational, the chairs and ADs might opine on that. I will just hint that we might draw a lesson here from RMT :-). Another clue might be to see how encryption and authentication schemes are defined in the past. best, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 11:38:04 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05294 for ; Tue, 10 Aug 2004 11:38:03 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D49968CFC4; Tue, 10 Aug 2004 11:38:03 -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 9805B8CFA9 for ; Tue, 10 Aug 2004 11:38:02 -0400 (EDT) Received: (qmail 73776 invoked by uid 3269); 10 Aug 2004 15:38:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73773 invoked from network); 10 Aug 2004 15:38:02 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 10 Aug 2004 15:38:02 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.12.8/8.12.8) with ESMTP id i7AFYRZ5018567; Tue, 10 Aug 2004 10:34:27 -0500 Received: from columbia.sparta.com (lilo.columbia.SPARTA.COM [157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id i7AFYRkE023140; Tue, 10 Aug 2004 10:34:27 -0500 Received: from [157.185.80.26] (dhcp-26.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id i7AFYQcV008891; Tue, 10 Aug 2004 11:34:26 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hugh Harney Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004) Date: Tue, 10 Aug 2004 11:34:33 -0400 To: George Gross X-Mailer: Apple Mail (2.618) Cc: "Dondeti, Lakshminath" , Atul.Sharma@nokia.com, bew@cisco.com, thardjono@yahoo.com, 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 George, comments in line. On Aug 9, 2004, at 2:42 PM, George Gross wrote: > Hi, > inline below.... > > On Mon, 9 Aug 2004, Hugh Harney wrote: > >> Lakshminath, >> >> I think the community would benefit from having all the potential >> source auth schemes defined in standards. > > I largely concur with this statement, but with the following caveats: > > First, there should be only one MUST implement standard source > authentication method within the context of a particular key management > protocol. I think the singular MUST should refer to the data layer protocol specification. GSAKMP can support many data layer protocols and each can have a different source auth protocol specified as MUST in the different specifications. > With respect to GSAKMP IPsec, I have not yet decided which > method to profile for use with multicast ESP, but I do anticipate > specifying one as the MUST implement. This would include those > parameters > needed to be declared in the policy token, and those needed in the SAM > message, and finally a pointer to the relevant ESP protocol spec. If the MUST implement source auth mechanism is specified in it's own standard, I'd think it would be better to reference that standard for the policy transferal mechanism. For example, if TESLA specified it's own payloads to be passed in GSAKMP for TESLA unique policy (latency info), then I'd think it would be preferable to use the same TESLA mechanisms. > > Second, the IETF has a standing policy of not mandating any "must > implement" security standards that have IPR encumberances (options that > have IPR are okay). In this regard, RSA signatures and TESLA to my > knowledge are not so encumbered, whereas several flavors of hash chain > source authentication fall within the domain of the Rohgati patents. Yup, the IETF's policy is pretty clear. I'm not sure of the span of the Rohgati patents. > > Third, perceived overhead is in the eye of the beholder. As a data > point, > consider the crypto++ library benchmarks published by Wei Dai. For > version > 5.2, the RSA 1024-bit signature generation on a 2.1 GHz Pentium under > Win/XP SP1 incurs 4.65 milliseconds overhead. The RSA signature > verification incurs 0.19 milliseconds overhead. I have not attempted to > run similar tests for the "weak" 512-bit RSA key length proposed in > Brien's draft, but clearly RSA signature has the benefit from placing > the > computational burden on the speaker, and conversely making the > receiver's > job easy. Of course, it is extremely subjective how to answer the > question: can your multicast application accept this level of overhead? > > Although TESLA promises lower computational overhead than RSA > signature, > the latency incured at the receivers who await an authentication key's > disclosure may be unacceptable to the application. Again, it is > subjective > how to even set this disclosure delay correctly for the group (i.e. > how do > you measure a network's propagation delays dynamically?) and whether > the > application du jour can accept that delay. My misgiving is that we do > not > yet have much empirical experience with TESLA to engineer its > performance > correctly. Aside from that, TESLA does not offer a non-repudiation > property, which may not fulfill some application's security policy. > > So I see value in having multiple source authentication schemes in the > MSEC standards toolkit. For inter-operability, we need at least one > such > scheme being *required* to be implemented in everyone's multicast > security > toolkit for ESP (and another for SRTP for that matter). > > br, > George > >> >> Hugh >> >> >> On Aug 9, 2004, at 11:21 AM, Dondeti, Lakshminath wrote: >> >>> First, I am not trying to address anything specific to this draft's >>> last call, except that we will have more than one source auth schemes >>> standardized by MSEC: TESLA is one, digital signatures is another. >>> As I noted at the meeting and to Thomas and Brian separately, I am >>> currently writing an I-D to work with the various hash chaining >>> schemes proposed in the literature. Simply put each packet will have >>> the capability of carrying one or more hashes, and there will be a >>> signature packet. Hash chaining will reduce the processing >>> requirements, but does not seem to alleviate the per-packet overhead. >>> Contributions are welcome from anyone interested in that effort; >>> please send an email to the list or to me. Once I have sufficient >>> text, I will submit the I-D and ask for a WG status TBD. >>> thanks, >>> Lakshminath >>> >>> >>> Atul.Sharma@nokia.com wrote: >>> >>>> In the past 1+ year I have familiarized myself with the problem >>>> (read >>>> the >>>> literature and monitored this list), being able to do data source >>>> authentication without digital signatures was the basic problem >>>> definiton (including the book co-authored by you). >>>> >>>> Now in IETF-60 we did a 180 degree turn and are saying digital >>>> signatures per >>>> packet are not that bad after all. How do we justify this turn? >>>> Processing power >>>> is increasing? Well, that means symmetric HMAC can be done even >>>> faster. >>>> >>>> The trade-offs are listed reasonably well in the draft. Are we going >>>> to propose something else for endpoints which do not have enough >>>> processing power? >>>> >>>> Denial of Service attack from outside the group is fixed by a >>>> group-wide symmetric >>>> HMAC. But there is no mention of DoS attacks possible from within >>>> the >>>> group >>>> sending bad/spoofed signatures. >>>> >>>> In presence of multiple senders, how would a receiver pick the right >>>> public key. >>>> This is not made explicit in the document. I would expect that from >>>> a >>>> document in >>>> the last call. >>>> >>>> One factual inconsistency: Section 2.0 mention minimum RSA modulus >>>> size 496 bits(62 bytes). But Section 3.0 implies minimum being 61 >>>> bytes. >>>> >>>> Atul >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: msec-bounces@securemulticast.org >>>>> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas >>>>> Hardjono >>>>> Sent: Friday, August 06, 2004 2:11 PM >>>>> To: MSEC MSEC >>>>> Cc: bew@cisco.com >>>>> Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date >>>>> Friday20 August 2004) >>>>> >>>>> >>>>> >>>>> >>>>> Folks, >>>>> >>>>> As mentioned in the MSEC WG meeting this week at IETF60, the >>>>> RSA-signatures >>>>> draft is ready for WG Last Call. >>>>> >>>>> You can get the latest version here: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign >>>>> >>>> atures-01.txt >>>> >>>> Therefore, we would like to begin WG Last Call for this draft, with >>>> a >>>> closing >>>> date of Friday 20 August 2004. >>>> >>>> Please send your comments to the list a.s.a.p. >>>> >>>> Regards. >>>> >>>> thomas >>>> ------ >>>> >>>> >>>> >>>> >>>> >>>> __________________________________ >>>> Do you Yahoo!? >>>> New and Improved Yahoo! Mail - 100MB free storage! >>>> http://promotions.yahoo.com/new_mail >>>> _______________________________________________ >>>> msec mailing list >>>> msec@securemulticast.org >>>> http://six.pairlist.net/mailman/listinfo/msec >>>> _______________________________________________ >>>> msec mailing list >>>> msec@securemulticast.org >>>> http://six.pairlist.net/mailman/listinfo/msec >>>> >>>> >>> >>> _______________________________________________ >>> msec mailing list >>> msec@securemulticast.org >>> http://six.pairlist.net/mailman/listinfo/msec >>> >>> >> Hugh Harney Sparta, Inc. >> hh@sparta.com 7075 Samuel Morse Drive >> (410) 872-1515 x203 Columbia, MD, 21046 >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 11:47:58 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05941 for ; Tue, 10 Aug 2004 11:47:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1AAA88D253; Tue, 10 Aug 2004 11:47: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 436DB8D13E for ; Tue, 10 Aug 2004 11:47:56 -0400 (EDT) Received: (qmail 75493 invoked by uid 3269); 10 Aug 2004 15:47:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75489 invoked from network); 10 Aug 2004 15:47:56 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 10 Aug 2004 15:47:56 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AFlr804554 for ; Tue, 10 Aug 2004 08:47:53 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T8CA2; Tue, 10 Aug 2004 08:47:54 -0700 Received: from [47.102.177.90] (archt0nt.us.nortel.com [47.102.177.90]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPHNP; Tue, 10 Aug 2004 11:47:51 -0400 Message-ID: <4118EE25.7060108@nortelnetworks.com> Date: Tue, 10 Aug 2004 11:47:49 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Requirements on Rekey and source auth schemes in GKM protocol specifications X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit I think it is better to suggest simple schemes as MUST in GKM protocol specifications (e.g., RSA-sign as Ran noted). As I noted on the list before, I saw some old patents on USPTO which I thought cover LKH (I am not a lawyer). We have not seen any IPR statements from LKH to the IETF to my recollection. Just noting here, so we don't require LKH in any of the GKM protocol specifications. Besides, as Thomas noted, different app scenarios require different protocols/schemes/mechanisms. That is applicable to rekey protocols, source authentication schemes, reliable transport protocols etc. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 12:25:25 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08367 for ; Tue, 10 Aug 2004 12:25:24 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 216608CD8B; Tue, 10 Aug 2004 12:25: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 2A5948CD54 for ; Tue, 10 Aug 2004 12:25:25 -0400 (EDT) Received: (qmail 82954 invoked by uid 3269); 10 Aug 2004 16:25:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82950 invoked from network); 10 Aug 2004 16:25:24 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by klesh.pair.com with SMTP; 10 Aug 2004 16:25:24 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AGPMB27680; Tue, 10 Aug 2004 19:25:22 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 19:20:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7AGKCEK014712; Tue, 10 Aug 2004 19:20:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00FDmml2; Tue, 10 Aug 2004 19:20:09 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AGK3u28301; Tue, 10 Aug 2004 19:20:04 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 11:18:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] standardizing source auth schemes Date: Tue, 10 Aug 2004 12:18:01 -0400 Message-ID: Thread-Topic: [MSEC] standardizing source auth schemes Thread-Index: AcR+75lEW+ZTXh3FSIOkPaSTW9qjlAABJzzg From: To: , X-OriginalArrivalTime: 10 Aug 2004 16:18:02.0856 (UTC) FILETIME=[9C5BB680:01C47EF5] 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 A new thread is started without answering the similar questions raised in the previous thread. You talk about consensus w.r.t. I-Ds. Can you tell me one instance of hum/vote on any I-Ds presented in IETF-60? In the case of GDOIv2, only one gentleman stood up and said he supports GDOIv2. There was no hum or vote taken. On proposals made by me, there=20 was no hum/vote. There was no comment from anybody in the WG stating=20 whether they want or don't want these as WG items. I thought IETF worked using rough consensus, if not consensus. = Unfortunately, none of those guidelines were followed in the MSEC WG meeting at IETF-60 (there was no single hum or vote). Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, > Lakshminath > Sent: Tuesday, August 10, 2004 11:32 AM > To: msec@securemulticast.org > Subject: [MSEC] standardizing source auth schemes >=20 > In terms of what becomes a WG doc and what doesn't, we have the=20 > consensus processes (let the games begin). On whether all=20 > the new I-Ds=20 > become standards/experimental/BCP/informational, the chairs and ADs=20 > might opine on that. I will just hint that we might draw a=20 > lesson here=20 > from RMT :-). Another clue might be to see how encryption and=20 > authentication schemes are defined in the past. >=20 > best, > Lakshminath > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 12:28:01 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08608 for ; Tue, 10 Aug 2004 12:27:59 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E99F18CF22; Tue, 10 Aug 2004 12:28:00 -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 895328CD37 for ; Tue, 10 Aug 2004 12:27:59 -0400 (EDT) Received: (qmail 83427 invoked by uid 3269); 10 Aug 2004 16:27:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83424 invoked from network); 10 Aug 2004 16:27:59 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 10 Aug 2004 16:27:59 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AGRnG10155; Tue, 10 Aug 2004 09:27:49 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T8DCS; Tue, 10 Aug 2004 09:27:42 -0700 Received: from [47.102.177.90] (archt0nt.us.nortel.com [47.102.177.90]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPH3Y; Tue, 10 Aug 2004 12:27:29 -0400 Message-ID: <4118F76F.2080905@nortelnetworks.com> Date: Tue, 10 Aug 2004 12:27:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atul.Sharma@nokia.com Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closingdateFriday20 August 2004) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bew@cisco.com, thardjono@yahoo.com, 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 Atul, I will ignore your non-technical comments and address the differences between your "Recall Packet scheme" and hash chaining: First, there are ways to get around packet losses in hash chaining. I recall seeing some related references in your I-D, so you are aware of them. The catch, as I noted in the meeting during your presentation, is that the per-packet overhead quickly approaches the overhead of the RSA-sig scheme. More importantly, if a packet is lost while hash chaining is being used, the receivers cannot verify one or more packets and will drop it/them. If I understand your scheme correctly, if a recall packet is lost, receivers accept a potentially compromised packet as a legitimate packet. regards, Lakshminath (on IPR issues, see Hugh's comments. Other than that, I think if the I-D I am working on is generic enough, then any hash chaining scheme should be able to use it. That might be difficult, but I think we should try). On Rogue member detection, I think that's out of MSEC charter. If you want to discuss rogue member detection w.r.t. message integrity attacks, and/or traitor tracing w.r.t members who might be leaking data to non-members, and other similar topics, you are welcome to bring your work to GSEC. Please send Pete and I an email. Thanks. Atul.Sharma@nokia.com wrote: > > Thomas, > > Well, if MSEC is open to other schemes as optional standard, how about we > make comments on proposals made by me (Recall Packet scheme, Rogue Member > detection, Delegated TESLA). There was no vote or hum taken in finding if > some of those could be working group items. > > On one hand MSEC veteran members criticized Recall Packet scheme being > vulnerable to packet loss (I pointed that out myself), on the other hand > they are proposing/discussing schemes based on hash chaining which is > also > vulnerable to packet loss and IPR-ladden. I view that as hypocritical > behavior on part of veteran MSEC members. > > Don't you think identifying a Rogue member in a Multicast group is an > important problem which MSEC WG can take? But there was no comment on > that either. > > I donot know if you realize, going to every IETF meeting and monitoring > WG mailing lists as part of the job, is a luxury many of us can not > afford. > It takes lot of efforts and convincing to be able to do that. There is > sometimes only a small window of time in which you can do IETF work, > before > going back to regular work. I had this small window in time and I did not > get constructive feedback from MSEC working group on the work I did and > proposed. Instead of hum, I got mum response. > > If the concern is about the IPR. Not everything I proposed has IPR. > Secondly, > the IPR-related work could be made as an option rather than mandatory. > > Best, > Atul > > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > Hardjono > > Sent: Tuesday, August 10, 2004 1:01 AM > > To: Sharma Atul (Nokia-ES/Boston); thardjono@yahoo.com; > > msec@securemulticast.org > > Cc: bew@cisco.com > > Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing > > dateFriday20 August 2004) > > > > > > > > > > Atul, > > > > Actually, the issue is more related to practicalities. > > > > We need a solution that can work today and is understood by > > the broader > > security community in the IETF (e.g. IPsec WG, RMT WG). > > > > This does not mean that MSEC is abandoning other solutions. > > In fact, we > > are still going to work on TESLA (ps. the TESLA-Intro draft > > has already > > done WG Last Call). We are waiting for the TESLA-specs draft to be > > finalized and the authors OK with it going Last Call. > > > > Bear in mind MSEC discovered that there is no single solution > > that fits > > all, since there are many application-areas needing > > source-authentication > > (e.g. routing, mobile, satellite), each with differing constraints. > > > > So if there are other solutions out there, MSEC is open to > > using them and > > standardizing them. > > > > > > thomas > > ------ > > > > > > > > At 8/9/2004||07:56 AM, Atul.Sharma@nokia.com wrote: > > > > >In the past 1+ year I have familiarized myself with the > > problem (read the > > >literature and monitored this list), being able to do data source > > >authentication > > >without digital signatures was the basic problem definiton > > (including the > > >book > > >co-authored by you). > > > > > >Now in IETF-60 we did a 180 degree turn and are saying > > digital signatures per > > >packet are not that bad after all. How do we justify this > > turn? Processing > > >power > > >is increasing? Well, that means symmetric HMAC can be done > > even faster. > > > > > >The trade-offs are listed reasonably well in the draft. Are > > we going to > > >propose > > >something else for endpoints which do not have enough > > processing power? > > > > > >Denial of Service attack from outside the group is fixed by > > a group-wide > > >symmetric > > >HMAC. But there is no mention of DoS attacks possible from > > within the group > > >sending bad/spoofed signatures. > > > > > >In presence of multiple senders, how would a receiver pick the right > > >public key. > > >This is not made explicit in the document. I would expect > > that from a > > >document in > > >the last call. > > > > > >One factual inconsistency: Section 2.0 mention minimum RSA > > modulus size > > >496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. > > > > > >Atul > > > > > > > > > > -----Original Message----- > > > > From: msec-bounces@securemulticast.org > > > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > > > Hardjono > > > > Sent: Friday, August 06, 2004 2:11 PM > > > > To: MSEC MSEC > > > > Cc: bew@cisco.com > > > > Subject: [MSEC] WG Last Call for RSA-signatures draft > > (closing date > > > > Friday20 August 2004) > > > > > > > > > > > > > > > > > > > > Folks, > > > > > > > > As mentioned in the MSEC WG meeting this week at IETF60, the > > > > RSA-signatures > > > > draft is ready for WG Last Call. > > > > > > > > You can get the latest version here: > > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign > > >atures-01.txt > > > > > >Therefore, we would like to begin WG Last Call for this > > draft, with a closing > > >date of Friday 20 August 2004. > > > > > >Please send your comments to the list a.s.a.p. > > > > > >Regards. > > > > > >thomas > > >------ > > > > > > > > > > > > > > > > > >__________________________________ > > >Do you Yahoo!? > > >New and Improved Yahoo! Mail - 100MB free storage! > > >http://promotions.yahoo.com/new_mail > > >_______________________________________________ > > >msec mailing list > > >msec@securemulticast.org > > >http://six.pairlist.net/mailman/listinfo/msec > > >_______________________________________________ > > >msec mailing list > > >msec@securemulticast.org > > >http://six.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 12:32:19 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09532 for ; Tue, 10 Aug 2004 12:32:17 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BA25A8D280; Tue, 10 Aug 2004 12:31: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 C39138D006 for ; Tue, 10 Aug 2004 12:31:50 -0400 (EDT) Received: (qmail 84058 invoked by uid 3269); 10 Aug 2004 16:31:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84055 invoked from network); 10 Aug 2004 16:31:50 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by klesh.pair.com with SMTP; 10 Aug 2004 16:31:50 -0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AGVj303302; Tue, 10 Aug 2004 19:31:47 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 19:27:58 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7AGRwt1027577; Tue, 10 Aug 2004 19:27:58 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00oVWKdS; Tue, 10 Aug 2004 19:27:56 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AGRin04743; Tue, 10 Aug 2004 19:27:45 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 11:26:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] standardizing source auth schemes Date: Tue, 10 Aug 2004 12:26:43 -0400 Message-ID: Thread-Topic: [MSEC] standardizing source auth schemes Thread-Index: AcR+75lEW+ZTXh3FSIOkPaSTW9qjlAABxNMQ From: To: , X-OriginalArrivalTime: 10 Aug 2004 16:26:45.0631 (UTC) FILETIME=[D3F4D8F0:01C47EF6] 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 Are there any IPR issues with TESLA, as possibility was alluded in this email? Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, > Lakshminath > Sent: Tuesday, August 10, 2004 11:32 AM > To: msec@securemulticast.org > Subject: [MSEC] standardizing source auth schemes >=20 > That out of the way :-), we have RSA-sig at one end of the spectrum=20 > (high communication and computation complexity) and TESLA at=20 > the other=20 > end (low overhead, but needs loose time sync). They are both well=20 > understood and belong in standards track (modulo any IPR issues with=20 > TESLA; this is probably a good time for IPR announcements, if any). >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 12:34:26 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09950 for ; Tue, 10 Aug 2004 12:34:25 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 25DE18CC6E; Tue, 10 Aug 2004 12:34: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 CAB4D8CBA0 for ; Tue, 10 Aug 2004 12:34:24 -0400 (EDT) Received: (qmail 84648 invoked by uid 3269); 10 Aug 2004 16:34:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84644 invoked from network); 10 Aug 2004 16:34:24 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 10 Aug 2004 16:34:24 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AGYAP19347; Tue, 10 Aug 2004 12:34:10 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPXPC5K1; Tue, 10 Aug 2004 12:34:09 -0400 Received: from [47.102.177.90] (archt0nt.us.nortel.com [47.102.177.90]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPH39; Tue, 10 Aug 2004 12:34:09 -0400 Message-ID: <4118F8FF.9040205@nortelnetworks.com> Date: Tue, 10 Aug 2004 12:34:07 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atul.Sharma@nokia.com Subject: Re: [MSEC] standardizing source auth schemes References: 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 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 thread renaming: there was a suggestion (by Radia?) made not too long ago to rename threads when the topic and the discussion don't match. I think it's quite helpful. On procedural matters: please check with chairs and ADs. On GDOIv2: there was a discussion and I think consensus on the list quite a while ago. On your work: a few folks raised issues. I would revise, resubmit, and invite discussion. For instance, think about an application scenario (or requirements) where your scheme would work better than other schemes proposed in the literature, and start from there. Also, please see my response to your questions. best wishes, Lakshminath Atul.Sharma@nokia.com wrote: >A new thread is started without answering the similar questions raised >in the previous thread. > >You talk about consensus w.r.t. I-Ds. Can you tell me one instance of >hum/vote on any I-Ds presented in IETF-60? > >In the case of GDOIv2, only one gentleman stood up and said he supports >GDOIv2. There was no hum or vote taken. On proposals made by me, there >was no hum/vote. There was no comment from anybody in the WG stating >whether they want or don't want these as WG items. > >I thought IETF worked using rough consensus, if not consensus. Unfortunately, >none of those guidelines were followed in the MSEC WG meeting at IETF-60 >(there was no single hum or vote). > >Atul > > > > >>-----Original Message----- >>From: msec-bounces@securemulticast.org >>[mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, >>Lakshminath >>Sent: Tuesday, August 10, 2004 11:32 AM >>To: msec@securemulticast.org >>Subject: [MSEC] standardizing source auth schemes >> >>In terms of what becomes a WG doc and what doesn't, we have the >>consensus processes (let the games begin). On whether all >>the new I-Ds >>become standards/experimental/BCP/informational, the chairs and ADs >>might opine on that. I will just hint that we might draw a >>lesson here >>from RMT :-). Another clue might be to see how encryption and >>authentication schemes are defined in the past. >> >>best, >>Lakshminath >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://six.pairlist.net/mailman/listinfo/msec >> >> >> >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 12:52:57 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11728 for ; Tue, 10 Aug 2004 12:52:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 286938C729; Tue, 10 Aug 2004 12:53:00 -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 7C82A8C70D for ; Tue, 10 Aug 2004 12:52:58 -0400 (EDT) Received: (qmail 87974 invoked by uid 3269); 10 Aug 2004 16:52:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87971 invoked from network); 10 Aug 2004 16:52:58 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 10 Aug 2004 16:52:58 -0000 Received: (qmail 97278 invoked from network); 10 Aug 2004 12:52:55 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 10 Aug 2004 12:52:55 -0400 Received: (qmail 62677 invoked from network); 10 Aug 2004 12:52:55 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 10 Aug 2004 12:52:55 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7AENrm18503; Tue, 10 Aug 2004 10:23:53 -0400 Date: Tue, 10 Aug 2004 10:23:52 -0400 (EDT) From: George Gross To: Subject: RE: [MSEC] standardizing source auth schemes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ldondeti@nortelnetworks.com, 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 Hi Atul, On Tue, 10 Aug 2004 Atul.Sharma@nokia.com wrote: > > A new thread is started without answering the similar questions raised > in the previous thread. > > You talk about consensus w.r.t. I-Ds. Can you tell me one instance of > hum/vote on any I-Ds presented in IETF-60? In fact, any movement/proposal taken at a working group meeting is not binding, as the reality is that in the IETF standards process rough consensus only can be achieved on its mailing list. Even if a straw vote is taken at a WG face-to-face meeting, it is not binding on the WG's community, a follow up must be brought to the list after the meeting. > > In the case of GDOIv2, only one gentleman stood up and said he supports > GDOIv2. There was no hum or vote taken. On proposals made by me, there > was no hum/vote. There was no comment from anybody in the WG stating > whether they want or don't want these as WG items. > > I thought IETF worked using rough consensus, if not consensus. Unfortunately, > none of those guidelines were followed in the MSEC WG meeting at IETF-60 > (there was no single hum or vote). There is no obligation for the WG to hum, vote, or exhibit any other behavior at its face-to-face meetings ;o) Well, within the norms of decency I suppose. Seriously, one of the good things about the IETF standards process is that it is mailing list driven, and does not force you to attend in person to participate as an equal. So please don't feel slighted that the working group did not immediately make any decision wrt/ your work. so rest assured, MSEC will likely examine each of the proposals/presentations from IETF60 in its own good time on this list. If past observations hold true, it will take time, and it will field comments from the usual interested parties, and consensus will emerge. hth, George > > Atul > > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, > > Lakshminath > > Sent: Tuesday, August 10, 2004 11:32 AM > > To: msec@securemulticast.org > > Subject: [MSEC] standardizing source auth schemes > > > > In terms of what becomes a WG doc and what doesn't, we have the > > consensus processes (let the games begin). On whether all > > the new I-Ds > > become standards/experimental/BCP/informational, the chairs and ADs > > might opine on that. I will just hint that we might draw a > > lesson here > > from RMT :-). Another clue might be to see how encryption and > > authentication schemes are defined in the past. > > > > best, > > Lakshminath > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 13:11:22 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13115 for ; Tue, 10 Aug 2004 13:11:21 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4E9908C9EF; Tue, 10 Aug 2004 13:11:24 -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 D449F8C9F5 for ; Tue, 10 Aug 2004 13:11:22 -0400 (EDT) Received: (qmail 91888 invoked by uid 3269); 10 Aug 2004 17:11:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91885 invoked from network); 10 Aug 2004 17:11:22 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by klesh.pair.com with SMTP; 10 Aug 2004 17:11:22 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AHBDj04974; Tue, 10 Aug 2004 20:11:13 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 20:07:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7AH7OnL011138; Tue, 10 Aug 2004 20:07:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00pQ4mpZ; Tue, 10 Aug 2004 20:07:24 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AH7Fn15441; Tue, 10 Aug 2004 20:07:16 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 12:05:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] standardizing source auth schemes Date: Tue, 10 Aug 2004 13:05:48 -0400 Message-ID: Thread-Topic: [MSEC] standardizing source auth schemes Thread-Index: AcR+9/xm8yF73TGeQ3O+m0F3RfI6NAAA8gzA From: To: X-OriginalArrivalTime: 10 Aug 2004 17:05:50.0261 (UTC) FILETIME=[4976FE50:01C47EFC] 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 The issue was not renaming. The issue was not dealing with the questions raised in the earlier thread. This was in continuation of the behavior I saw earlier: instead of being forthright and upfront with the issues, try to be selectively hush/mum/quiet about things. br, Atul > -----Original Message----- > From: ext Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com] > Sent: Tuesday, August 10, 2004 12:34 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: msec@securemulticast.org > Subject: Re: [MSEC] standardizing source auth schemes >=20 >=20 > On thread renaming: there was a suggestion (by Radia?) made=20 > not too long=20 > ago to rename threads when the topic and the discussion don't=20 > match. I=20 > think it's quite helpful. >=20 > On procedural matters: please check with chairs and ADs. >=20 > On GDOIv2: there was a discussion and I think consensus on the list=20 > quite a while ago. >=20 > On your work: a few folks raised issues. I would revise,=20 > resubmit, and=20 > invite discussion. For instance, think about an application scenario=20 > (or requirements) where your scheme would work better than=20 > other schemes=20 > proposed in the literature, and start from there. Also,=20 > please see my=20 > response to your questions. >=20 > best wishes, > Lakshminath >=20 =20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 13:13:09 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13354 for ; Tue, 10 Aug 2004 13:13:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AA9BF8CEF6; Tue, 10 Aug 2004 13:13: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 B1A658CD0E for ; Tue, 10 Aug 2004 13:13:09 -0400 (EDT) Received: (qmail 92979 invoked by uid 3269); 10 Aug 2004 17:13:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92973 invoked from network); 10 Aug 2004 17:13:09 -0000 Received: from mgw-x4.nokia.com (131.228.20.27) by klesh.pair.com with SMTP; 10 Aug 2004 17:13:09 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AHB8j04812; Tue, 10 Aug 2004 20:11:08 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 20:03:03 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7AH33DO031266; Tue, 10 Aug 2004 20:03:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00FMLoOX; Tue, 10 Aug 2004 20:03:02 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AH30n11289; Tue, 10 Aug 2004 20:03:00 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 12:02:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closingdateFriday20 August 2004) Date: Tue, 10 Aug 2004 13:01:02 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft (closingdateFriday20 August 2004) Thread-Index: AcR+92FmRdvYaleqRpu8VOKS8Dei4AAAxIcg From: To: X-OriginalArrivalTime: 10 Aug 2004 17:02:39.0315 (UTC) FILETIME=[D7A6F230:01C47EFB] Cc: bew@cisco.com, thardjono@yahoo.com, 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 Lakshminath, You are not correct in stating that per packet ovehead of Recall Packet Scheme will be that of RSA-Sig scheme. May be you are confusing that = with Delegated Authentication, the other scheme I presented, where the = per-packet overhead can approach that of RSA-Sig scheme. Recall packet scheme does = not incur such overheads. You are right though, a loss of Recall packet in Recall Packet scheme = would mean an illegitimate packet being accepted. Basically packet loss will = be manifested as a different symptom for different schemes. It will be = tough to argue which symptom is acceptable and which symptom is not. BR, Atul > -----Original Message----- > From: ext Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com] > Sent: Tuesday, August 10, 2004 12:27 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: thardjono@yahoo.com; msec@securemulticast.org; bew@cisco.com > Subject: Re: [MSEC] WG Last Call for RSA-signatures draft > (closingdateFriday20 August 2004) >=20 >=20 > Atul, >=20 > I will ignore your non-technical comments and address the differences=20 > between your "Recall Packet scheme" and hash chaining: >=20 > First, there are ways to get around packet losses in hash=20 > chaining. I=20 > recall seeing some related references in your I-D, so you are=20 > aware of=20 > them. The catch, as I noted in the meeting during your=20 > presentation, is=20 > that the per-packet overhead quickly approaches the overhead of the=20 > RSA-sig scheme. >=20 > More importantly, if a packet is lost while hash chaining is=20 > being used,=20 > the receivers cannot verify one or more packets and will drop=20 > it/them. =20 > If I understand your scheme correctly, if a recall packet is lost,=20 > receivers accept a potentially compromised packet as a=20 > legitimate packet. >=20 > regards, > Lakshminath >=20 > (on IPR issues, see Hugh's comments. Other than that, I think if the=20 > I-D I am working on is generic enough, then any hash chaining scheme=20 > should be able to use it. That might be difficult, but I think we=20 > should try). >=20 > On Rogue member detection, I think that's out of MSEC=20 > charter. If you=20 > want to discuss rogue member detection w.r.t. message=20 > integrity attacks,=20 > and/or traitor tracing w.r.t members who might be leaking data to=20 > non-members, and other similar topics, you are welcome to bring your=20 > work to GSEC. Please send Pete and I an email. Thanks. > Atul.Sharma@nokia.com wrote: >=20 > > > > Thomas, > > > > Well, if MSEC is open to other schemes as optional=20 > standard, how about we > > make comments on proposals made by me (Recall Packet=20 > scheme, Rogue Member > > detection, Delegated TESLA). There was no vote or hum taken=20 > in finding if > > some of those could be working group items. > > > > On one hand MSEC veteran members criticized Recall Packet=20 > scheme being > > vulnerable to packet loss (I pointed that out myself), on=20 > the other hand > > they are proposing/discussing schemes based on hash=20 > chaining which is=20 > > also > > vulnerable to packet loss and IPR-ladden. I view that as=20 > hypocritical > > behavior on part of veteran MSEC members. > > > > Don't you think identifying a Rogue member in a Multicast=20 > group is an > > important problem which MSEC WG can take? But there was no=20 > comment on > > that either. > > > > I donot know if you realize, going to every IETF meeting=20 > and monitoring > > WG mailing lists as part of the job, is a luxury many of us can not=20 > > afford. > > It takes lot of efforts and convincing to be able to do=20 > that. There is > > sometimes only a small window of time in which you can do=20 > IETF work,=20 > > before > > going back to regular work. I had this small window in time=20 > and I did not > > get constructive feedback from MSEC working group on the=20 > work I did and > > proposed. Instead of hum, I got mum response. > > > > If the concern is about the IPR. Not everything I proposed has IPR.=20 > > Secondly, > > the IPR-related work could be made as an option rather than=20 > mandatory. > > > > Best, > > Atul > > > > > > > -----Original Message----- > > > From: msec-bounces@securemulticast.org > > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > > Hardjono > > > Sent: Tuesday, August 10, 2004 1:01 AM > > > To: Sharma Atul (Nokia-ES/Boston); thardjono@yahoo.com; > > > msec@securemulticast.org > > > Cc: bew@cisco.com > > > Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing > > > dateFriday20 August 2004) > > > > > > > > > > > > > > > Atul, > > > > > > Actually, the issue is more related to practicalities. > > > > > > We need a solution that can work today and is understood by > > > the broader > > > security community in the IETF (e.g. IPsec WG, RMT WG). > > > > > > This does not mean that MSEC is abandoning other solutions.=20 > > > In fact, we > > > are still going to work on TESLA (ps. the TESLA-Intro draft > > > has already > > > done WG Last Call). We are waiting for the TESLA-specs draft to be > > > finalized and the authors OK with it going Last Call. > > > > > > Bear in mind MSEC discovered that there is no single solution > > > that fits > > > all, since there are many application-areas needing > > > source-authentication > > > (e.g. routing, mobile, satellite), each with differing=20 > constraints. > > > > > > So if there are other solutions out there, MSEC is open to > > > using them and > > > standardizing them. > > > > > > > > > thomas > > > ------ > > > > > > > > > > > > At 8/9/2004||07:56 AM, Atul.Sharma@nokia.com wrote: > > > > > > >In the past 1+ year I have familiarized myself with the > > > problem (read the > > > >literature and monitored this list), being able to do data source > > > >authentication > > > >without digital signatures was the basic problem definiton > > > (including the > > > >book > > > >co-authored by you). > > > > > > > >Now in IETF-60 we did a 180 degree turn and are saying > > > digital signatures per > > > >packet are not that bad after all. How do we justify this > > > turn? Processing > > > >power > > > >is increasing? Well, that means symmetric HMAC can be done > > > even faster. > > > > > > > >The trade-offs are listed reasonably well in the draft. Are > > > we going to > > > >propose > > > >something else for endpoints which do not have enough > > > processing power? > > > > > > > >Denial of Service attack from outside the group is fixed by > > > a group-wide > > > >symmetric > > > >HMAC. But there is no mention of DoS attacks possible from > > > within the group > > > >sending bad/spoofed signatures. > > > > > > > >In presence of multiple senders, how would a receiver=20 > pick the right > > > >public key. > > > >This is not made explicit in the document. I would expect > > > that from a > > > >document in > > > >the last call. > > > > > > > >One factual inconsistency: Section 2.0 mention minimum RSA > > > modulus size > > > >496 bits(62 bytes). But Section 3.0 implies minimum=20 > being 61 bytes. > > > > > > > >Atul > > > > > > > > > > > > > -----Original Message----- > > > > > From: msec-bounces@securemulticast.org > > > > > [mailto:msec-bounces@securemulticast.org]On Behalf Of=20 > ext Thomas > > > > > Hardjono > > > > > Sent: Friday, August 06, 2004 2:11 PM > > > > > To: MSEC MSEC > > > > > Cc: bew@cisco.com > > > > > Subject: [MSEC] WG Last Call for RSA-signatures draft > > > (closing date > > > > > Friday20 August 2004) > > > > > > > > > > > > > > > > > > > > > > > > > Folks, > > > > > > > > > > As mentioned in the MSEC WG meeting this week at IETF60, the > > > > > RSA-signatures > > > > > draft is ready for WG Last Call. > > > > > > > > > > You can get the latest version here: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign > > > >atures-01.txt > > > > > > > >Therefore, we would like to begin WG Last Call for this > > > draft, with a closing > > > >date of Friday 20 August 2004. > > > > > > > >Please send your comments to the list a.s.a.p. > > > > > > > >Regards. > > > > > > > >thomas > > > >------ > > > > > > > > > > > > > > > > > > > > > > > >__________________________________ > > > >Do you Yahoo!? > > > >New and Improved Yahoo! Mail - 100MB free storage! > > > >http://promotions.yahoo.com/new_mail > > > >_______________________________________________ > > > >msec mailing list > > > >msec@securemulticast.org > > > >http://six.pairlist.net/mailman/listinfo/msec > > > >_______________________________________________ > > > >msec mailing list > > > >msec@securemulticast.org > > > >http://six.pairlist.net/mailman/listinfo/msec > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://six.pairlist.net/mailman/listinfo/msec > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > >=20 >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 13:29:47 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15238 for ; Tue, 10 Aug 2004 13:29:47 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 241DB8D546; Tue, 10 Aug 2004 13:29: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 2CD858D719 for ; Tue, 10 Aug 2004 13:29:40 -0400 (EDT) Received: (qmail 96185 invoked by uid 3269); 10 Aug 2004 17:29:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96182 invoked from network); 10 Aug 2004 17:29:39 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 10 Aug 2004 17:29:39 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AHQkn18000; Tue, 10 Aug 2004 10:26:47 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T819P; Tue, 10 Aug 2004 10:24:42 -0700 Received: from [47.102.177.90] (archt0nt.us.nortel.com [47.102.177.90]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPHQC; Tue, 10 Aug 2004 13:24:16 -0400 Message-ID: <411904BD.4010601@nortelnetworks.com> Date: Tue, 10 Aug 2004 13:24:13 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atul.Sharma@nokia.com Subject: Re: [MSEC] WG Last Call for RSA-signatures draft (closingdateFriday20 August 2004) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bew@cisco.com, thardjono@yahoo.com, 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 Clarification: per-packet overhead in some hash chaining schemes, e.g., EMSS is about the same as (e.g., 6-degree hash chain would amount to 120B of overhead) RSA-sig. I don't know the overhead of your recall packet scheme. Please clarify this: do you mean that it is ok in some cases to accept unverifiable packets as legitimate? Apologies if that's not what you meant. regards, Lakshminath Atul.Sharma@nokia.com wrote: >Lakshminath, > >You are not correct in stating that per packet ovehead of Recall Packet >Scheme will be that of RSA-Sig scheme. May be you are confusing that with >Delegated Authentication, the other scheme I presented, where the per-packet >overhead can approach that of RSA-Sig scheme. Recall packet scheme does not >incur such overheads. > >You are right though, a loss of Recall packet in Recall Packet scheme would >mean an illegitimate packet being accepted. Basically packet loss will be >manifested as a different symptom for different schemes. It will be tough >to argue which symptom is acceptable and which symptom is not. > >BR, >Atul > > > >>-----Original Message----- >>From: ext Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com] >>Sent: Tuesday, August 10, 2004 12:27 PM >>To: Sharma Atul (Nokia-ES/Boston) >>Cc: thardjono@yahoo.com; msec@securemulticast.org; bew@cisco.com >>Subject: Re: [MSEC] WG Last Call for RSA-signatures draft >>(closingdateFriday20 August 2004) >> >> >>Atul, >> >>I will ignore your non-technical comments and address the differences >>between your "Recall Packet scheme" and hash chaining: >> >>First, there are ways to get around packet losses in hash >>chaining. I >>recall seeing some related references in your I-D, so you are >>aware of >>them. The catch, as I noted in the meeting during your >>presentation, is >>that the per-packet overhead quickly approaches the overhead of the >>RSA-sig scheme. >> >>More importantly, if a packet is lost while hash chaining is >>being used, >>the receivers cannot verify one or more packets and will drop >>it/them. >>If I understand your scheme correctly, if a recall packet is lost, >>receivers accept a potentially compromised packet as a >>legitimate packet. >> >>regards, >>Lakshminath >> >>(on IPR issues, see Hugh's comments. Other than that, I think if the >>I-D I am working on is generic enough, then any hash chaining scheme >>should be able to use it. That might be difficult, but I think we >>should try). >> >>On Rogue member detection, I think that's out of MSEC >>charter. If you >>want to discuss rogue member detection w.r.t. message >>integrity attacks, >>and/or traitor tracing w.r.t members who might be leaking data to >>non-members, and other similar topics, you are welcome to bring your >>work to GSEC. Please send Pete and I an email. Thanks. >>Atul.Sharma@nokia.com wrote: >> >> >> >>>Thomas, >>> >>>Well, if MSEC is open to other schemes as optional >>> >>> >>standard, how about we >> >> >>>make comments on proposals made by me (Recall Packet >>> >>> >>scheme, Rogue Member >> >> >>>detection, Delegated TESLA). There was no vote or hum taken >>> >>> >>in finding if >> >> >>>some of those could be working group items. >>> >>>On one hand MSEC veteran members criticized Recall Packet >>> >>> >>scheme being >> >> >>>vulnerable to packet loss (I pointed that out myself), on >>> >>> >>the other hand >> >> >>>they are proposing/discussing schemes based on hash >>> >>> >>chaining which is >> >> >>>also >>>vulnerable to packet loss and IPR-ladden. I view that as >>> >>> >>hypocritical >> >> >>>behavior on part of veteran MSEC members. >>> >>>Don't you think identifying a Rogue member in a Multicast >>> >>> >>group is an >> >> >>>important problem which MSEC WG can take? But there was no >>> >>> >>comment on >> >> >>>that either. >>> >>>I donot know if you realize, going to every IETF meeting >>> >>> >>and monitoring >> >> >>>WG mailing lists as part of the job, is a luxury many of us can not >>>afford. >>>It takes lot of efforts and convincing to be able to do >>> >>> >>that. There is >> >> >>>sometimes only a small window of time in which you can do >>> >>> >>IETF work, >> >> >>>before >>>going back to regular work. I had this small window in time >>> >>> >>and I did not >> >> >>>get constructive feedback from MSEC working group on the >>> >>> >>work I did and >> >> >>>proposed. Instead of hum, I got mum response. >>> >>>If the concern is about the IPR. Not everything I proposed has IPR. >>>Secondly, >>>the IPR-related work could be made as an option rather than >>> >>> >>mandatory. >> >> >>>Best, >>>Atul >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: msec-bounces@securemulticast.org >>>>[mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas >>>>Hardjono >>>>Sent: Tuesday, August 10, 2004 1:01 AM >>>>To: Sharma Atul (Nokia-ES/Boston); thardjono@yahoo.com; >>>>msec@securemulticast.org >>>>Cc: bew@cisco.com >>>>Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing >>>>dateFriday20 August 2004) >>>> >>>> >>>> >>>> >>>>Atul, >>>> >>>>Actually, the issue is more related to practicalities. >>>> >>>>We need a solution that can work today and is understood by >>>>the broader >>>>security community in the IETF (e.g. IPsec WG, RMT WG). >>>> >>>>This does not mean that MSEC is abandoning other solutions. >>>>In fact, we >>>>are still going to work on TESLA (ps. the TESLA-Intro draft >>>>has already >>>>done WG Last Call). We are waiting for the TESLA-specs draft to be >>>>finalized and the authors OK with it going Last Call. >>>> >>>>Bear in mind MSEC discovered that there is no single solution >>>>that fits >>>>all, since there are many application-areas needing >>>>source-authentication >>>>(e.g. routing, mobile, satellite), each with differing >>>> >>>> >>constraints. >> >> >>>>So if there are other solutions out there, MSEC is open to >>>>using them and >>>>standardizing them. >>>> >>>> >>>>thomas >>>>------ >>>> >>>> >>>> >>>>At 8/9/2004||07:56 AM, Atul.Sharma@nokia.com wrote: >>>> >>>> >>>> >>>>>In the past 1+ year I have familiarized myself with the >>>>> >>>>> >>>>problem (read the >>>> >>>> >>>>>literature and monitored this list), being able to do data source >>>>>authentication >>>>>without digital signatures was the basic problem definiton >>>>> >>>>> >>>>(including the >>>> >>>> >>>>>book >>>>>co-authored by you). >>>>> >>>>>Now in IETF-60 we did a 180 degree turn and are saying >>>>> >>>>> >>>>digital signatures per >>>> >>>> >>>>>packet are not that bad after all. How do we justify this >>>>> >>>>> >>>>turn? Processing >>>> >>>> >>>>>power >>>>>is increasing? Well, that means symmetric HMAC can be done >>>>> >>>>> >>>>even faster. >>>> >>>> >>>>>The trade-offs are listed reasonably well in the draft. Are >>>>> >>>>> >>>>we going to >>>> >>>> >>>>>propose >>>>>something else for endpoints which do not have enough >>>>> >>>>> >>>>processing power? >>>> >>>> >>>>>Denial of Service attack from outside the group is fixed by >>>>> >>>>> >>>>a group-wide >>>> >>>> >>>>>symmetric >>>>>HMAC. But there is no mention of DoS attacks possible from >>>>> >>>>> >>>>within the group >>>> >>>> >>>>>sending bad/spoofed signatures. >>>>> >>>>>In presence of multiple senders, how would a receiver >>>>> >>>>> >>pick the right >> >> >>>>>public key. >>>>>This is not made explicit in the document. I would expect >>>>> >>>>> >>>>that from a >>>> >>>> >>>>>document in >>>>>the last call. >>>>> >>>>>One factual inconsistency: Section 2.0 mention minimum RSA >>>>> >>>>> >>>>modulus size >>>> >>>> >>>>>496 bits(62 bytes). But Section 3.0 implies minimum >>>>> >>>>> >>being 61 bytes. >> >> >>>>>Atul >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: msec-bounces@securemulticast.org >>>>>>[mailto:msec-bounces@securemulticast.org]On Behalf Of >>>>>> >>>>>> >>ext Thomas >> >> >>>>>>Hardjono >>>>>>Sent: Friday, August 06, 2004 2:11 PM >>>>>>To: MSEC MSEC >>>>>>Cc: bew@cisco.com >>>>>>Subject: [MSEC] WG Last Call for RSA-signatures draft >>>>>> >>>>>> >>>>(closing date >>>> >>>> >>>>>>Friday20 August 2004) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Folks, >>>>>> >>>>>>As mentioned in the MSEC WG meeting this week at IETF60, the >>>>>>RSA-signatures >>>>>>draft is ready for WG Last Call. >>>>>> >>>>>>You can get the latest version here: >>>>>>http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign >>>>>> >>>>>> >>>>>atures-01.txt >>>>> >>>>>Therefore, we would like to begin WG Last Call for this >>>>> >>>>> >>>>draft, with a closing >>>> >>>> >>>>>date of Friday 20 August 2004. >>>>> >>>>>Please send your comments to the list a.s.a.p. >>>>> >>>>>Regards. >>>>> >>>>>thomas >>>>>------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>__________________________________ >>>>>Do you Yahoo!? >>>>>New and Improved Yahoo! Mail - 100MB free storage! >>>>>http://promotions.yahoo.com/new_mail >>>>>_______________________________________________ >>>>>msec mailing list >>>>>msec@securemulticast.org >>>>>http://six.pairlist.net/mailman/listinfo/msec >>>>>_______________________________________________ >>>>>msec mailing list >>>>>msec@securemulticast.org >>>>>http://six.pairlist.net/mailman/listinfo/msec >>>>> >>>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://six.pairlist.net/mailman/listinfo/msec >>>> >>>> >>>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://six.pairlist.net/mailman/listinfo/msec >>> >>> >>> >> >> >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 14:41:38 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20002 for ; Tue, 10 Aug 2004 14:41:38 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8C3B38CE44; Tue, 10 Aug 2004 14:41: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 4FC2C8CD50 for ; Tue, 10 Aug 2004 14:41:37 -0400 (EDT) Received: (qmail 10038 invoked by uid 3269); 10 Aug 2004 18:41:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10034 invoked from network); 10 Aug 2004 18:41:36 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by klesh.pair.com with SMTP; 10 Aug 2004 18:41:36 -0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AIfYB04111; Tue, 10 Aug 2004 21:41:35 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 21:39:58 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7AIdwDn009740; Tue, 10 Aug 2004 21:39:58 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00GRiiSg; Tue, 10 Aug 2004 21:39:58 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AIdvu04183; Tue, 10 Aug 2004 21:39:57 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 13:39:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closingdateFriday20August 2004) Date: Tue, 10 Aug 2004 14:39:40 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft (closingdateFriday20August 2004) Thread-Index: AcR/A2hdm3AMioz3ScaQKaWMnQd7UwABMM2g From: To: X-OriginalArrivalTime: 10 Aug 2004 18:39:42.0503 (UTC) FILETIME=[668AEB70:01C47F09] Cc: bew@cisco.com, thardjono@yahoo.com, 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 comments inline. > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, > Lakshminath > Sent: Tuesday, August 10, 2004 1:24 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: bew@cisco.com; thardjono@yahoo.com; msec@securemulticast.org > Subject: Re: [MSEC] WG Last Call for RSA-signatures draft > (closingdateFriday20August 2004) >=20 >=20 > Clarification: per-packet overhead in some hash chaining=20 > schemes, e.g.,=20 > EMSS is about the same as (e.g., 6-degree hash chain would amount to=20 > 120B of overhead) RSA-sig. I don't know the overhead of your recall=20 > packet scheme. There is only one HMAC field in Recall Packet scheme, the size of which = of=20 course depends on the algorithm chosen. There is no per-packet overhead = with=20 scalability issues in this scheme in its vanilla form. > Please clarify this: do you mean that it is ok in some cases=20 > to accept=20 > unverifiable packets as legitimate? Apologies if that's not=20 > what you meant. Let me reiterate in a different way: a packet loss in Hash chaining has different implications; a packet loss in Recall Packet has different implications. It will be tough to argue that one implication/symptom is more acceptable than the other. > regards, > Lakshminath >=20 > Atul.Sharma@nokia.com wrote: >=20 > >Lakshminath, > > > >You are not correct in stating that per packet ovehead of=20 > Recall Packet > >Scheme will be that of RSA-Sig scheme. May be you are=20 > confusing that with > >Delegated Authentication, the other scheme I presented,=20 > where the per-packet > >overhead can approach that of RSA-Sig scheme. Recall packet=20 > scheme does not > >incur such overheads. > > > >You are right though, a loss of Recall packet in Recall=20 > Packet scheme would > >mean an illegitimate packet being accepted. Basically packet=20 > loss will be > >manifested as a different symptom for different schemes. It=20 > will be tough > >to argue which symptom is acceptable and which symptom is not. > > > >BR, > >Atul > > =20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 15:03:04 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21228 for ; Tue, 10 Aug 2004 15:03:04 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 44F258C5BC; Tue, 10 Aug 2004 15:03: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 631238BFAE for ; Tue, 10 Aug 2004 15:03:03 -0400 (EDT) Received: (qmail 13980 invoked by uid 3269); 10 Aug 2004 19:03:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 13977 invoked from network); 10 Aug 2004 19:03:03 -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; 10 Aug 2004 19:03:03 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2004 12:06:45 +0000 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn5-47.cisco.com [10.21.88.47]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7AJ2QjL029109; Tue, 10 Aug 2004 12:03:00 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] standardizing source auth schemes Date: Tue, 10 Aug 2004 11:48:59 -0700 To: X-Mailer: Apple Mail (2.618) Cc: ldondeti@nortelnetworks.com, 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 It's not possible to answer the question "are there any IPR issues with TESLA?" The "IPR issues" (potential patent claims) that matter in the future might not be known today. I don't know of any IPR encumbrances on TESLA. The basic algorithm is over twenty years old. Unfortunately, http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-02.txt is formatted incorrectly and does not use the current IETF boilerplate, which requires IPR statements from authors. That's at least a start towards answering "are there an known IPR encumbrances on TESLA?" Mark On Aug 10, 2004, at 9:26 AM, wrote: > Are there any IPR issues with TESLA, as possibility was alluded in this > email? > > Atul > >> -----Original Message----- >> From: msec-bounces@securemulticast.org >> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, >> Lakshminath >> Sent: Tuesday, August 10, 2004 11:32 AM >> To: msec@securemulticast.org >> Subject: [MSEC] standardizing source auth schemes >> >> That out of the way :-), we have RSA-sig at one end of the spectrum >> (high communication and computation complexity) and TESLA at >> the other >> end (low overhead, but needs loose time sync). They are both well >> understood and belong in standards track (modulo any IPR issues with >> TESLA; this is probably a good time for IPR announcements, if any). >> > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 15:14:31 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22734 for ; Tue, 10 Aug 2004 15:14:31 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 270998CA99; Tue, 10 Aug 2004 15:14: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 90F7F8CA8A for ; Tue, 10 Aug 2004 15:14:31 -0400 (EDT) Received: (qmail 16997 invoked by uid 3269); 10 Aug 2004 19:14:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16994 invoked from network); 10 Aug 2004 19:14:31 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 10 Aug 2004 19:14:31 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AJ7Jb01209; Tue, 10 Aug 2004 12:07:19 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T82WT; Tue, 10 Aug 2004 12:05:40 -0700 Received: from [47.102.177.90] (archt0nt.us.nortel.com [47.102.177.90]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPHT5; Tue, 10 Aug 2004 15:05:37 -0400 Message-ID: <41191C7E.10505@nortelnetworks.com> Date: Tue, 10 Aug 2004 15:05:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atul.Sharma@nokia.com Subject: Re: [MSEC] WG Last Call for RSA-signatures draft(closingdateFriday20August 2004) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bew@cisco.com, thardjono@yahoo.com, 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 In your scheme, an adversary can introduce bogus packets, and can make the receivers believe there is nothing wrong. In hash chaining or TESLA, receivers drop packets that they cannot verify, i.e., the adversary can create packet losses and launch at best a DoS attack. Successful packet modification attacks are worse than DoS attacks. regards, Lakshminath Atul.Sharma@nokia.com wrote: >comments inline. > > > >>-----Original Message----- >>From: msec-bounces@securemulticast.org >>[mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, >>Lakshminath >>Sent: Tuesday, August 10, 2004 1:24 PM >>To: Sharma Atul (Nokia-ES/Boston) >>Cc: bew@cisco.com; thardjono@yahoo.com; msec@securemulticast.org >>Subject: Re: [MSEC] WG Last Call for RSA-signatures draft >>(closingdateFriday20August 2004) >> >> >>Clarification: per-packet overhead in some hash chaining >>schemes, e.g., >>EMSS is about the same as (e.g., 6-degree hash chain would amount to >>120B of overhead) RSA-sig. I don't know the overhead of your recall >>packet scheme. >> >> > >There is only one HMAC field in Recall Packet scheme, the size of which of >course depends on the algorithm chosen. There is no per-packet overhead with >scalability issues in this scheme in its vanilla form. > > > >>Please clarify this: do you mean that it is ok in some cases >>to accept >>unverifiable packets as legitimate? Apologies if that's not >>what you meant. >> >> > >Let me reiterate in a different way: a packet loss in Hash chaining >has different implications; a packet loss in Recall Packet has different >implications. It will be tough to argue that one implication/symptom >is more acceptable than the other. > > > >>regards, >>Lakshminath >> >>Atul.Sharma@nokia.com wrote: >> >> > > > > >>>Lakshminath, >>> >>>You are not correct in stating that per packet ovehead of >>> >>> >>Recall Packet >> >> >>>Scheme will be that of RSA-Sig scheme. May be you are >>> >>> >>confusing that with >> >> >>>Delegated Authentication, the other scheme I presented, >>> >>> >>where the per-packet >> >> >>>overhead can approach that of RSA-Sig scheme. Recall packet >>> >>> >>scheme does not >> >> >>>incur such overheads. >>> >>>You are right though, a loss of Recall packet in Recall >>> >>> >>Packet scheme would >> >> >>>mean an illegitimate packet being accepted. Basically packet >>> >>> >>loss will be >> >> >>>manifested as a different symptom for different schemes. It >>> >>> >>will be tough >> >> >>>to argue which symptom is acceptable and which symptom is not. >>> >>>BR, >>>Atul >>> >>> >>> > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 15:43:08 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24968 for ; Tue, 10 Aug 2004 15:43:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 13B598C5A0; Tue, 10 Aug 2004 15:43: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 4A7E78BFB8 for ; Tue, 10 Aug 2004 15:43:08 -0400 (EDT) Received: (qmail 21905 invoked by uid 3269); 10 Aug 2004 19:43:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21901 invoked from network); 10 Aug 2004 19:43:08 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 10 Aug 2004 19:43:08 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24963; Tue, 10 Aug 2004 15:43:05 -0400 (EDT) Message-Id: <200408101943.PAA24963@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 10 Aug 2004 15:43:05 -0400 Cc: msec@securemulticast.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-gdoiv2-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : GDOIv2: An efficient group key distribution protocol Author(s) : L. Dondeti Filename : draft-ietf-msec-gdoiv2-00.txt Pages : 12 Date : 2004-8-10 This document specifies a group key distribution protocol based on IKEv2 [2]; the new protocol is similar to IKEv2 in message and payload formats, and message semantics to a large extent. The protocol in conformance with MSEC key management architecture contains two components: member registration and group rekeying, and downloads a group security association from the GCKS to a member. This protocol is independent of IKEv2 except in its likeness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoiv2-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gdoiv2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gdoiv2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-10160519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoiv2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoiv2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-10160519.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From msec-bounces@securemulticast.org Tue Aug 10 15:47:00 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25176 for ; Tue, 10 Aug 2004 15:47:00 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E42C88C40A; Tue, 10 Aug 2004 15:47:01 -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 5F7AC8C9EE for ; Tue, 10 Aug 2004 15:47:00 -0400 (EDT) Received: (qmail 22525 invoked by uid 3269); 10 Aug 2004 19:47:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22522 invoked from network); 10 Aug 2004 19:47:00 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by klesh.pair.com with SMTP; 10 Aug 2004 19:47:00 -0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AJkv303162; Tue, 10 Aug 2004 22:46:57 +0300 (EET DST) X-Scanned: Tue, 10 Aug 2004 22:45:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7AJjd8P002220; Tue, 10 Aug 2004 22:45:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 007U8ZVx; Tue, 10 Aug 2004 22:45:38 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7AJjWu14619; Tue, 10 Aug 2004 22:45:33 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 Aug 2004 14:45:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft(closingdateFriday20August 2004) Date: Tue, 10 Aug 2004 15:45:07 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft(closingdateFriday20August 2004) Thread-Index: AcR/DixBdiWiiVf7RyulySVE3gnZlgAA8o6w From: To: X-OriginalArrivalTime: 10 Aug 2004 19:45:08.0856 (UTC) FILETIME=[8AD4D780:01C47F12] Cc: bew@cisco.com, thardjono@yahoo.com, 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 > -----Original Message----- > From: ext Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com] > Sent: Tuesday, August 10, 2004 3:06 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: bew@cisco.com; thardjono@yahoo.com; msec@securemulticast.org > Subject: Re: [MSEC] WG Last Call for RSA-signatures > draft(closingdateFriday20August 2004) > > Successful packet modification attacks are worse than DoS attacks. >=20 That can be one opinion for a certain domain/application. I do not think there is a general agreed upon grading of all security vulnerabilities, where we can say spoofing is worse than DoS. Atul _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 16:17:48 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29944 for ; Tue, 10 Aug 2004 16:17:47 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B17118D13E; Tue, 10 Aug 2004 16:17:49 -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 695718D12F for ; Tue, 10 Aug 2004 16:17:48 -0400 (EDT) Received: (qmail 29184 invoked by uid 3269); 10 Aug 2004 20:17:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29181 invoked from network); 10 Aug 2004 20:17:48 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 10 Aug 2004 20:17:48 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7AKHgG08682; Tue, 10 Aug 2004 13:17:43 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T8KR1; Tue, 10 Aug 2004 13:15:57 -0700 Received: from [47.102.177.90] (archt0nt.us.nortel.com [47.102.177.90]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQPFPHV9; Tue, 10 Aug 2004 16:15:19 -0400 Message-ID: <41192CD6.8030702@nortelnetworks.com> Date: Tue, 10 Aug 2004 16:15:18 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atul.Sharma@nokia.com Subject: Re: [MSEC] WG Last Call for RSA-signaturesdraft(closingdateFriday20August 2004) References: 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 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 My last message in this thread. A source auth scheme provides this property: A receiver is able to prove to itself that a packet received actually comes from the claimed sender. Yours does not! Lakshminath Atul.Sharma@nokia.com wrote: > > > > -----Original Message----- > > From: ext Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com] > > Sent: Tuesday, August 10, 2004 3:06 PM > > To: Sharma Atul (Nokia-ES/Boston) > > Cc: bew@cisco.com; thardjono@yahoo.com; msec@securemulticast.org > > Subject: Re: [MSEC] WG Last Call for RSA-signatures > > draft(closingdateFriday20August 2004) > > > > Successful packet modification attacks are worse than DoS attacks. > > > > That can be one opinion for a certain domain/application. I do not > think there is a general agreed upon grading of all security > vulnerabilities, where we can say spoofing is worse than DoS. > > Atul > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 17:03:06 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06632 for ; Tue, 10 Aug 2004 17:03:06 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 790D68CA84; Tue, 10 Aug 2004 17:03:08 -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 725AA8C97F for ; Tue, 10 Aug 2004 17:03:06 -0400 (EDT) Received: (qmail 37745 invoked by uid 3269); 10 Aug 2004 21:03:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37737 invoked from network); 10 Aug 2004 21:03:05 -0000 Received: from tosh.netlab.uky.edu (204.198.76.200) by klesh.pair.com with SMTP; 10 Aug 2004 21:03:05 -0000 Received: from ozark.netlab.uky.edu (ozark.netlab.uky.edu [204.198.76.63]) by tosh.netlab.uky.edu (Postfix) with ESMTP id 0C9C6CE8E; Tue, 10 Aug 2004 17:03:05 -0400 (EDT) Date: Tue, 10 Aug 2004 17:03:04 -0400 (EDT) From: Ken Calvert To: Atul.Sharma@nokia.com Subject: RE: [MSEC] WG Last Call for RSA-signatures draft(closingdateFriday20August 2004) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 > I do not > think there is a general agreed upon grading of all security > vulnerabilities, where we can say spoofing is worse than DoS. I think you'll find this position a tough sell. (In other words, I disagree, and I think others will also.) One of the first things I try to teach my students is that undetected faults are much worse than detected ones. It is far better for a program to crash or fail to terminate than for it to behave correctly but produce wrong results. Spoofing is by definition an undetected failure, while DoS is by definition detected or at least detectable. KC -- Ken Calvert, Associate Professor Lab for Advanced Networking calvert@netlab.uky.edu University of Kentucky Tel: +1.859.257.6745 Hardymon Building, 2nd Floor Fax: +1.859.323.1971 301 Rose Street http://www.cs.uky.edu/~calvert/ Lexington, KY 40506-0495 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 17:32:23 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08623 for ; Tue, 10 Aug 2004 17:32:23 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 40D6E8CCC3; Tue, 10 Aug 2004 17:32:25 -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 7F3E58CC59 for ; Tue, 10 Aug 2004 17:32:24 -0400 (EDT) Received: (qmail 43864 invoked by uid 3269); 10 Aug 2004 21:32:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43861 invoked from network); 10 Aug 2004 21:32:24 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 10 Aug 2004 21:32:24 -0000 Received: (qmail 3780 invoked from network); 10 Aug 2004 17:32:21 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 10 Aug 2004 17:32:21 -0400 Received: (qmail 16724 invoked from network); 10 Aug 2004 17:32:21 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 10 Aug 2004 17:32:21 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7AJ3H719065; Tue, 10 Aug 2004 15:03:17 -0400 Date: Tue, 10 Aug 2004 15:03:17 -0400 (EDT) From: George Gross To: "Dondeti, Lakshminath" Subject: Re: [MSEC] Requirements on Rekey and source auth schemes in GKM protocol specifications In-Reply-To: <4118EE25.7060108@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi Lakshminath, On Tue, 10 Aug 2004, Dondeti, Lakshminath wrote: > I think it is better to suggest simple schemes as MUST in GKM protocol > specifications (e.g., RSA-sign as Ran noted). agreed. RSA signature seems like a reasonable candidate for this role. I anticipate reviewing and posting comments before the last call elapses.... > > As I noted on the list before, I saw some old patents on USPTO which I > thought cover LKH (I am not a lawyer). We have not seen any IPR > statements from LKH to the IETF to my recollection. Just noting here, > so we don't require LKH in any of the GKM protocol specifications. I had brought the question of LKH IPR to the MSEC list last year. See the e-mail thread in the archive dated July 21st 2003, with the Subject line "A few questions on GSAKMP (long)". My take away from that discussion was that Sun's patents were pre-dated by prior art and publications. But as Mark has pointed out in another e-mail today, IPR can be claimed at any time from any point of the compass, not just the USPTO. That said, in the GSAKMP IPsec profile I have nominated LKH as a MUST, and it is fully spec'd as an option in the GSAKMP base specification appendix 1. No comparable protocol spec exists for OFT (or any other group rekey protocol/algorithm) AFAIK. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 10 20:21:28 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18930 for ; Tue, 10 Aug 2004 20:21:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 317F08C838; Tue, 10 Aug 2004 20:21: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 0175D8C7AB for ; Tue, 10 Aug 2004 20:21:28 -0400 (EDT) Received: (qmail 73918 invoked by uid 3269); 11 Aug 2004 00:21:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73914 invoked from network); 11 Aug 2004 00:21:27 -0000 Received: from web12504.mail.yahoo.com (216.136.173.196) by klesh.pair.com with SMTP; 11 Aug 2004 00:21:27 -0000 Message-ID: <20040811002127.7561.qmail@web12504.mail.yahoo.com> Received: from [65.219.183.25] by web12504.mail.yahoo.com via HTTP; Tue, 10 Aug 2004 17:21:26 PDT Date: Tue, 10 Aug 2004 17:21:26 -0700 (PDT) From: Thomas Hardjono Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing dateFriday20 August 2004) To: Atul.Sharma@nokia.com, msec@securemulticast.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Hi Atul, Apologies for replying late - my current meeting location has no IP connection for guests, so I have to wait until I get back to the hotel to do emails. With regards to the openness of the MSEC to new schemes, seeing the quietness of the group it is quite natural to think that MSEC (or other IETF WGs) has no interest in other schemes. Actually, some of the old-timers have been attending for the last 5 years (from the SMuG days), so are probably exhausted with multicast security :-) Also, many people have less bandwidth today since their employers are burdening more work on them. BTW. he lack of questions or humming or hands-up is not any reliable indication of interest in the audience. The reverse is also true (eg. the PERM BOF). Many people in the audience usually have not read the drafts. So, I'd like to encourage you to submit your work and get it discussed in the mailing-list. cheers, thomas ------ --- Atul.Sharma@nokia.com wrote: > > Thomas, > > Well, if MSEC is open to other schemes as optional standard, how about we > make comments on proposals made by me (Recall Packet scheme, Rogue Member > detection, Delegated TESLA). There was no vote or hum taken in finding if > some of those could be working group items. > > On one hand MSEC veteran members criticized Recall Packet scheme being > vulnerable to packet loss (I pointed that out myself), on the other hand > they are proposing/discussing schemes based on hash chaining which is also > vulnerable to packet loss and IPR-ladden. I view that as hypocritical > behavior on part of veteran MSEC members. > > Don't you think identifying a Rogue member in a Multicast group is an > important problem which MSEC WG can take? But there was no comment on > that either. > > I donot know if you realize, going to every IETF meeting and monitoring > WG mailing lists as part of the job, is a luxury many of us can not afford. > It takes lot of efforts and convincing to be able to do that. There is > sometimes only a small window of time in which you can do IETF work, before > going back to regular work. I had this small window in time and I did not > get constructive feedback from MSEC working group on the work I did and > proposed. Instead of hum, I got mum response. > > If the concern is about the IPR. Not everything I proposed has IPR. Secondly, > the IPR-related work could be made as an option rather than mandatory. > > Best, > Atul > > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > Hardjono > > Sent: Tuesday, August 10, 2004 1:01 AM > > To: Sharma Atul (Nokia-ES/Boston); thardjono@yahoo.com; > > msec@securemulticast.org > > Cc: bew@cisco.com > > Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing > > dateFriday20 August 2004) > > > > > > > > > > Atul, > > > > Actually, the issue is more related to practicalities. > > > > We need a solution that can work today and is understood by > > the broader > > security community in the IETF (e.g. IPsec WG, RMT WG). > > > > This does not mean that MSEC is abandoning other solutions. > > In fact, we > > are still going to work on TESLA (ps. the TESLA-Intro draft > > has already > > done WG Last Call). We are waiting for the TESLA-specs draft to be > > finalized and the authors OK with it going Last Call. > > > > Bear in mind MSEC discovered that there is no single solution > > that fits > > all, since there are many application-areas needing > > source-authentication > > (e.g. routing, mobile, satellite), each with differing constraints. > > > > So if there are other solutions out there, MSEC is open to > > using them and > > standardizing them. > > > > > > thomas > > ------ > > > > > > > > At 8/9/2004||07:56 AM, Atul.Sharma@nokia.com wrote: > > > > >In the past 1+ year I have familiarized myself with the > > problem (read the > > >literature and monitored this list), being able to do data source > > >authentication > > >without digital signatures was the basic problem definiton > > (including the > > >book > > >co-authored by you). > > > > > >Now in IETF-60 we did a 180 degree turn and are saying > > digital signatures per > > >packet are not that bad after all. How do we justify this > > turn? Processing > > >power > > >is increasing? Well, that means symmetric HMAC can be done > > even faster. > > > > > >The trade-offs are listed reasonably well in the draft. Are > > we going to > > >propose > > >something else for endpoints which do not have enough > > processing power? > > > > > >Denial of Service attack from outside the group is fixed by > > a group-wide > > >symmetric > > >HMAC. But there is no mention of DoS attacks possible from > > within the group > > >sending bad/spoofed signatures. > > > > > >In presence of multiple senders, how would a receiver pick the right > > >public key. > > >This is not made explicit in the document. I would expect > > that from a > > >document in > > >the last call. > > > > > >One factual inconsistency: Section 2.0 mention minimum RSA > > modulus size > > >496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes. > > > > > >Atul > > > > > > > > > > -----Original Message----- > > > > From: msec-bounces@securemulticast.org > > > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Thomas > > > > Hardjono > > > > Sent: Friday, August 06, 2004 2:11 PM > > > > To: MSEC MSEC > > > > Cc: bew@cisco.com > > > > Subject: [MSEC] WG Last Call for RSA-signatures draft > > (closing date > > > > Friday20 August 2004) > > > > > > > > > > > > > > > > > > > > Folks, > > > > > > > > As mentioned in the MSEC WG meeting this week at IETF60, the > > > > RSA-signatures > > > > draft is ready for WG Last Call. > > > > > > > > You can get the latest version here: > > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign > > >atures-01.txt > > > > > >Therefore, we would like to begin WG Last Call for this > > draft, with a closing > > >date of Friday 20 August 2004. > > > > > >Please send your comments to the list a.s.a.p. > > > > > >Regards. > > > > > >thomas > > >------ > > > > > > > > > > > > > > > > > >__________________________________ > > >Do you Yahoo!? > > >New and Improved Yahoo! Mail - 100MB free storage! > > >http://promotions.yahoo.com/new_mail > > >_______________________________________________ > > >msec mailing list > > >msec@securemulticast.org > > >http://six.pairlist.net/mailman/listinfo/msec > > >_______________________________________________ > > >msec mailing list > > >msec@securemulticast.org > > >http://six.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 11 00:53:59 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04154 for ; Wed, 11 Aug 2004 00:53:59 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 02CBE8C8A9; Wed, 11 Aug 2004 00:54: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 3A5C88C5B2 for ; Wed, 11 Aug 2004 00:54:01 -0400 (EDT) Received: (qmail 56974 invoked by uid 3269); 11 Aug 2004 04:54:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56963 invoked from network); 11 Aug 2004 04:54:00 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 11 Aug 2004 04:54:00 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i7B4pYc76530; Wed, 11 Aug 2004 00:51:35 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7B4rID51162; Wed, 11 Aug 2004 00:53:18 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i7B4rHT34984; Wed, 11 Aug 2004 00:53:17 -0400 Date: Wed, 11 Aug 2004 00:53:16 -0400 (EDT) From: canetti To: Mark Baugher Subject: Re: [MSEC] standardizing source auth schemes In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Atul.Sharma@nokia.com, ldondeti@nortelnetworks.com, 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 There are no IPR issues with TESLA. Thanks Mark for pointing out the lack of IPR statement in the draft. Will fix. Ran On Tue, 10 Aug 2004, Mark Baugher wrote: > It's not possible to answer the question "are there any IPR issues with > TESLA?" The "IPR issues" (potential patent claims) that matter in the > future might not be known today. I don't know of any IPR encumbrances > on TESLA. The basic algorithm is over twenty years old. > Unfortunately, > http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-02.txt > is formatted incorrectly and does not use the current IETF boilerplate, > which requires IPR statements from authors. That's at least a start > towards answering "are there an known IPR encumbrances on TESLA?" > > Mark > On Aug 10, 2004, at 9:26 AM, wrote: > > > Are there any IPR issues with TESLA, as possibility was alluded in this > > email? > > > > Atul > > > >> -----Original Message----- > >> From: msec-bounces@securemulticast.org > >> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Dondeti, > >> Lakshminath > >> Sent: Tuesday, August 10, 2004 11:32 AM > >> To: msec@securemulticast.org > >> Subject: [MSEC] standardizing source auth schemes > >> > >> That out of the way :-), we have RSA-sig at one end of the spectrum > >> (high communication and computation complexity) and TESLA at > >> the other > >> end (low overhead, but needs loose time sync). They are both well > >> understood and belong in standards track (modulo any IPR issues with > >> TESLA; this is probably a good time for IPR announcements, if any). > >> > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 11 07:54:12 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23525 for ; Wed, 11 Aug 2004 07:54:10 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 61B038CD3B; Wed, 11 Aug 2004 07:54:08 -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 D70318CD2F for ; Wed, 11 Aug 2004 07:54:06 -0400 (EDT) Received: (qmail 33180 invoked by uid 3269); 11 Aug 2004 11:54:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 33177 invoked from network); 11 Aug 2004 11:54:06 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by klesh.pair.com with SMTP; 11 Aug 2004 11:54:06 -0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBs2321178; Wed, 11 Aug 2004 14:54:02 +0300 (EET DST) X-Scanned: Wed, 11 Aug 2004 14:53:48 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i7BBrmXF022753; Wed, 11 Aug 2004 14:53:48 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00uDiE9V; Wed, 11 Aug 2004 14:53:47 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7BBrfu01277; Wed, 11 Aug 2004 14:53:41 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 11 Aug 2004 06:53:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] WG Last Call for RSA-signatures draft(closingdateFriday20August 2004) Date: Wed, 11 Aug 2004 07:53:37 -0400 Message-ID: Thread-Topic: [MSEC] WG Last Call for RSA-signatures draft(closingdateFriday20August 2004) Thread-Index: AcR/HYtZ+lbcT8MaRPy422s1/A3DFgAevW/g From: To: X-OriginalArrivalTime: 11 Aug 2004 11:53:39.0220 (UTC) FILETIME=[D74EB540:01C47F99] 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 Your argument on detected vs undetected faults is well taken. But it is possible spoofing at network level is detected at the application level based on contextual information. On the other hand in a DoS, one is dead, you can not do anything. One could=20 argue that recoverable spoofing is better than a DoS. But again, this seems like a personal opinion. May be, as a community we ought to grade the security faults based on as much information we can gather, e.g. the applications=20 they occur in. For all we know, there is one already and I am just not aware of it. Something to consult Security area directors with. I shall send them an email. Best, Atul > -----Original Message----- > From: ext Ken Calvert [mailto:calvert@netlab.uky.edu] > Sent: Tuesday, August 10, 2004 5:03 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: msec@securemulticast.org > Subject: RE: [MSEC] WG Last Call for RSA-signatures > draft(closingdateFriday20August 2004) >=20 >=20 >=20 > > I do not > > think there is a general agreed upon grading of all security > > vulnerabilities, where we can say spoofing is worse than DoS. >=20 > I think you'll find this position a tough sell. (In other > words, I disagree, and I think others will also.) >=20 > One of the first things I try to teach my students is that > undetected faults are much worse than detected ones. It is > far better for a program to crash or fail to terminate than > for it to behave correctly but produce wrong results. >=20 > Spoofing is by definition an undetected failure, while DoS > is by definition detected or at least detectable. >=20 > KC > --=20 > Ken Calvert, Associate Professor Lab for Advanced Networking > calvert@netlab.uky.edu University of Kentucky > Tel: +1.859.257.6745 Hardymon Building, 2nd Floor > Fax: +1.859.323.1971 301 Rose Street > http://www.cs.uky.edu/~calvert/ Lexington, KY 40506-0495 >=20 >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 11 16:57:00 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15272 for ; Wed, 11 Aug 2004 16:56:59 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 18C758CA7D; Wed, 11 Aug 2004 16:56:59 -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 B33328C989 for ; Wed, 11 Aug 2004 16:56:56 -0400 (EDT) Received: (qmail 40568 invoked by uid 3269); 11 Aug 2004 20:56:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40565 invoked from network); 11 Aug 2004 20:56:56 -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 Aug 2004 20:56:56 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Aug 2004 13:59:18 -0700 Received: from [192.168.0.10] (sjc-vpn5-204.cisco.com [10.21.88.204]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i7BKurH0006015; Wed, 11 Aug 2004 13:56:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Wed, 11 Aug 2004 13:56:49 -0700 To: msec@securemulticast.org X-Mailer: Apple Mail (2.618) Cc: ldondeti@nortelnetworks.com Subject: [MSEC] Comments on http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoiv2-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: 7bit Lakshminath, all I read the GDOIv2 draft and think we should go back to the drawing board. We do need a version 2 of GDOI but this draft redefines GDOI into yet-another group key management protocol - and says so plainly. My objections are explained in what follows and my points are numbered. 1. The title of the GDOIv2 I-D is changed from GDOIv1 RFC. Why rename something when the version number changes? I am the one who named GDOI as the "group domain of interpretation" for ISAKMP. If it is no longer a group domain of interpretation for ISAKMP, then I would not call it GDOI. And I'm unaware of any evidence that ISAKMP-based protocols are "efficient." If you really want something that is Group IKE and not an ISAKMP DOI, then you should just invent a new protocol and give it a new name. I am interested in developing a second version of GDOI. 2. I am interested in a second version of GDOI that supports a two message exchange, like IKEv2, and better supports devices on home entertainment networks. In fact, I would port some of the functions and even some of the design from GSAKMP into GDOIv2 as well as the 2-message exchange (Child-SA functionality) from IKEv2. We need to support the policy token, perhaps in a form adapted to GDOI (e.g. no ASN.1, thank you :). We need to support GCKS discovery. And we need to support GCKS-GCKS exchanges. 3. The IKEv2 phase 1 functionality is pretty much the focus of this I-D and it's the least interesting technical issue in GDOIv2 IMHO. If fact, this should be a no-brainer. Fixing the proof-of-possession protocol in the second version is also pretty much a no-brainer. 4. What's more interesting is the inter-GCKS protocol. We need to discuss a number of alternative designs. For example, should we do it like SMTP, which is a client/server protocol that allows each server to act as a forwarding client. Or do we invent another protocol for GCKS-GCKS communication? 5. Also of interest is the policy token, which could use a core/profile design to allow application-specific policies such as PERM rights management payload. 6. We need to consider how to securely discover GCKS nodes. (Cathy Meadow's successful attack on the GDOIv1 POP involves a GCKS server that acts as a client to another GCKS unbeknownst to a requesting client/member.) We can roll our own secure service discovery protocol or use a general-purpose standard (rendezvous, upnp, http://www.ietf.org/html.charters/svrloc-charter.html - and possibly some others). This needs to be discussed. So, I want to stop work on this I-D and reset the work on a second version of GDOI, which I personally want to contribute to. We used to refer to GDOI as "group IKE" and that is one attribute of GDOI - among many. If Lakshminath or others think we need a better group IKE, then I think they and perhaps even the WG might want to pursue it. But GDOI is named in the context of the ISAKMP DOI framework and it is what it is. thanks, Mark _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 11 20:51:35 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04025 for ; Wed, 11 Aug 2004 20:51:33 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D63938CF18; Wed, 11 Aug 2004 20:51: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 A278F8CF3F for ; Wed, 11 Aug 2004 20:51:32 -0400 (EDT) Received: (qmail 79384 invoked by uid 3269); 12 Aug 2004 00:51:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79381 invoked from network); 12 Aug 2004 00:51:32 -0000 Received: from zsc3s004.nortelnetworks.com (47.81.138.65) by klesh.pair.com with SMTP; 12 Aug 2004 00:51:32 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7C0nv312108; Wed, 11 Aug 2004 17:49:57 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P78T9K19; Wed, 11 Aug 2004 17:49:09 -0700 Received: from [47.140.52.135] (artpt5qh.us.nortel.com [47.140.52.135]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QVY9ZFP7; Wed, 11 Aug 2004 20:49:06 -0400 Message-ID: <411ABE80.4040309@nortelnetworks.com> Date: Wed, 11 Aug 2004 20:49:04 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org Subject: [MSEC] Re: Comments on http://www.ietf.org/internet-drafts/draft-ietf-msec-g doiv2-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: 7bit Mark, First, let me say that I am open to changes including the title :-). My goal is a group key download protocol similar to IKEv2, so we can reuse the basic constructs. I am open to the use cases you mention below as well as adding support for GCKS discovery and inter-GCKS protocol (although I am curious if that work should be in a separate document). I will try and address the items below. Mark Baugher wrote: > Lakshminath, all > I read the GDOIv2 draft and think we should go back to the drawing > board. We do need a version 2 of GDOI but this draft redefines GDOI > into yet-another group key management protocol - and says so plainly. > My objections are explained in what follows and my points are numbered. > > 1. The title of the GDOIv2 I-D is changed from GDOIv1 RFC. Why rename > something when the version number changes? I am the one who named GDOI > as the "group domain of interpretation" for ISAKMP. If it is no longer > a group domain of interpretation for ISAKMP, then I would not call it > GDOI. And I'm unaware of any evidence that ISAKMP-based protocols are > "efficient." If you really want something that is Group IKE and not an > ISAKMP DOI, then you should just invent a new protocol and give it a > new name. I am interested in developing a second version of GDOI. > IKEv2 is considerably more efficient than IKE, and removes the DOI concept. I am thinking of GDOIv2 in the same vein. As you note in one of your points below, and I noted at the meeting, the work is mostly cut-and-paste from IKEv2 I-D and reuse of constructs from GDOI and policy token from GSAKMP. > 2. I am interested in a second version of GDOI that supports a two > message exchange, like IKEv2, and better supports devices on home > entertainment networks. In fact, I would port some of the functions > and even some of the design from GSAKMP into GDOIv2 as well as the > 2-message exchange (Child-SA functionality) from IKEv2. We need to > support the policy token, perhaps in a form adapted to GDOI (e.g. no > ASN.1, thank you :). We need to support GCKS discovery. And we need > to support GCKS-GCKS exchanges. > I am also interested in GCKS discovery and inter-GCKS communication. > 3. The IKEv2 phase 1 functionality is pretty much the focus of this I-D > and it's the least interesting technical issue in GDOIv2 IMHO. If > fact, this should be a no-brainer. Fixing the proof-of-possession > protocol in the second version is also pretty much a no-brainer. > Agreed :-). > 4. What's more interesting is the inter-GCKS protocol. We need to > discuss a number of alternative designs. For example, should we do it > like SMTP, which is a client/server protocol that allows each server to > act as a forwarding client. Or do we invent another protocol for > GCKS-GCKS communication? > > 5. Also of interest is the policy token, which could use a core/profile > design to allow application-specific policies such as PERM rights > management payload. > I need to think about PERM fits in here. I think there is common ground, although we may have slightly different view points. I would rather see us discuss and converge on a single IKEv2+GDOI-based protocol rather than adding more KM protocols to the mix. To reiterate, my interest is to design a protocol as efficient as IKEv2 without morphing it too much (so we can reuse as much code as possible). best, Lakshminath > 6. We need to consider how to securely discover GCKS nodes. (Cathy > Meadow's successful attack on the GDOIv1 POP involves a GCKS server > that acts as a client to another GCKS unbeknownst to a requesting > client/member.) We can roll our own secure service discovery protocol > or use a general-purpose standard (rendezvous, upnp, > http://www.ietf.org/html.charters/svrloc-charter.html - and possibly > some others). This needs to be discussed. > > So, I want to stop work on this I-D and reset the work on a second > version of GDOI, which I personally want to contribute to. We used to > refer to GDOI as "group IKE" and that is one attribute of GDOI - among > many. If Lakshminath or others think we need a better group IKE, then > I think they and perhaps even the WG might want to pursue it. But GDOI > is named in the context of the ISAKMP DOI framework and it is what it > is. > > thanks, Mark > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 11 21:14:07 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05702 for ; Wed, 11 Aug 2004 21:14:06 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 107048C960; Wed, 11 Aug 2004 21:14:08 -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 91F9F8C866 for ; Wed, 11 Aug 2004 21:14:06 -0400 (EDT) Received: (qmail 83430 invoked by uid 3269); 12 Aug 2004 01:14:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83427 invoked from network); 12 Aug 2004 01:14:06 -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 Aug 2004 01:14:06 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2004 18:17:06 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn5-656.cisco.com [10.21.90.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7C1E2Te023099; Wed, 11 Aug 2004 18:14:02 -0700 (PDT) In-Reply-To: <411ABE80.4040309@nortelnetworks.com> References: <411ABE80.4040309@nortelnetworks.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Wed, 11 Aug 2004 18:13:53 -0700 To: "Dondeti, Lakshminath" X-Mailer: Apple Mail (2.618) Cc: msec@securemulticast.org Subject: [MSEC] Re: Comments on http://www.ietf.org/internet-drafts/draft-ietf-msec-g doiv2-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: 7bit Lakshminath, On Aug 11, 2004, at 5:49 PM, Dondeti, Lakshminath wrote: > Mark, > > First, let me say that I am open to changes including the title :-). > My goal is a group key download protocol similar to IKEv2, so we can > reuse the basic constructs. I am open to the use cases you mention > below as well as adding support for GCKS discovery and inter-GCKS > protocol (although I am curious if that work should be in a separate > document). I will try and address the items below. > Mark Baugher wrote: > >> Lakshminath, all >> I read the GDOIv2 draft and think we should go back to the drawing >> board. We do need a version 2 of GDOI but this draft redefines GDOI >> into yet-another group key management protocol - and says so plainly. >> My objections are explained in what follows and my points are >> numbered. >> >> 1. The title of the GDOIv2 I-D is changed from GDOIv1 RFC. Why rename >> something when the version number changes? I am the one who named >> GDOI >> as the "group domain of interpretation" for ISAKMP. If it is no >> longer >> a group domain of interpretation for ISAKMP, then I would not call it >> GDOI. And I'm unaware of any evidence that ISAKMP-based protocols are >> "efficient." If you really want something that is Group IKE and not >> an >> ISAKMP DOI, then you should just invent a new protocol and give it a >> new name. I am interested in developing a second version of GDOI. >> > IKEv2 is considerably more efficient than IKE, and removes the DOI > concept. Two ideas are juxtaposed that may have not correspondence. It is true that IKEv2 has a more efficient phase 1 and phase 2 negotiation. And it is also true that it removes the DOI concept. It is not true that IKEv2 is more efficient because it removes the DOI concept. We want the DOI concept since we want to use a core key establishment framework with a profile, for groups in our case. If you throw out the DOI concept in IKEv2 in one door, it comes in through another, because you are using IKEv2 as a core protocol and extending with a distinct profile, e.g. with some new payloads. At least with ISAKMP, this is explicit. > I am thinking of GDOIv2 in the same vein. As you note in one of your > points below, and I noted at the meeting, the work is mostly > cut-and-paste from IKEv2 I-D and reuse of constructs from GDOI and > policy token from GSAKMP. > >> 2. I am interested in a second version of GDOI that supports a two >> message exchange, like IKEv2, and better supports devices on home >> entertainment networks. In fact, I would port some of the functions >> and even some of the design from GSAKMP into GDOIv2 as well as the >> 2-message exchange (Child-SA functionality) from IKEv2. We need to >> support the policy token, perhaps in a form adapted to GDOI (e.g. no >> ASN.1, thank you :). We need to support GCKS discovery. And we need >> to support GCKS-GCKS exchanges. >> > I am also interested in GCKS discovery and inter-GCKS communication. > >> 3. The IKEv2 phase 1 functionality is pretty much the focus of this >> I-D >> and it's the least interesting technical issue in GDOIv2 IMHO. If >> fact, this should be a no-brainer. Fixing the proof-of-possession >> protocol in the second version is also pretty much a no-brainer. >> > Agreed :-). > >> 4. What's more interesting is the inter-GCKS protocol. We need to >> discuss a number of alternative designs. For example, should we do it >> like SMTP, which is a client/server protocol that allows each server >> to >> act as a forwarding client. Or do we invent another protocol for >> GCKS-GCKS communication? >> >> 5. Also of interest is the policy token, which could use a >> core/profile >> design to allow application-specific policies such as PERM rights >> management payload. >> > I need to think about PERM fits in here. > > I think there is common ground, although we may have slightly > different view points. I would rather see us discuss and converge on > a single IKEv2+GDOI-based protocol rather than adding more KM > protocols to the mix. To reiterate, my interest is to design a > protocol as efficient as IKEv2 without morphing it too much (so we can > reuse as much code as possible). I have not heard anyone say that they cannot deploy GDOI because it is not efficient enough in its exchanges. We have seen the need for a simple 2-message key establishment and have MIKEY for this purpose. The 2-message case is a specialized need that has to do with assuming only one (e.g., SIP) roundtrip available for the key establishment. That's fine, but this efficiency comes at a cost in terms of identity protection, i.e. there are good reasons for having a 3 or 4 message exchange from a security standpoint. I'd say that if all you want is an IKEv2 type of exchange, then why not write a less ambitious I-D that simply adds a new, combined Phase 1 and Phase 2 for GDOI. You could call it "a new Phase 1 and Phase 2 exchange for GDOI." cheers, Mark > > best, > Lakshminath > >> 6. We need to consider how to securely discover GCKS nodes. (Cathy >> Meadow's successful attack on the GDOIv1 POP involves a GCKS server >> that acts as a client to another GCKS unbeknownst to a requesting >> client/member.) We can roll our own secure service discovery protocol >> or use a general-purpose standard (rendezvous, upnp, >> http://www.ietf.org/html.charters/svrloc-charter.html - and possibly >> some others). This needs to be discussed. >> >> So, I want to stop work on this I-D and reset the work on a second >> version of GDOI, which I personally want to contribute to. We used to >> refer to GDOI as "group IKE" and that is one attribute of GDOI - among >> many. If Lakshminath or others think we need a better group IKE, then >> I think they and perhaps even the WG might want to pursue it. But >> GDOI >> is named in the context of the ISAKMP DOI framework and it is what it >> is. >> >> thanks, Mark >> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 12 16:59:14 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07309 for ; Thu, 12 Aug 2004 16:59:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1748D8BFED; Thu, 12 Aug 2004 16:58:54 -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 012E28BFC7 for ; Thu, 12 Aug 2004 16:58:52 -0400 (EDT) Received: (qmail 32355 invoked by uid 3269); 12 Aug 2004 20:58:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32352 invoked from network); 12 Aug 2004 20:58:51 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 12 Aug 2004 20:58:51 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7CKvSt10449; Thu, 12 Aug 2004 16:57:28 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPXP1Y78; Thu, 12 Aug 2004 16:57:27 -0400 Received: from [47.16.102.59] (47.16.102.59 [47.16.102.59]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QVY9ZG22; Thu, 12 Aug 2004 16:57:27 -0400 Message-ID: <411BD9B0.50804@nortelnetworks.com> Date: Thu, 12 Aug 2004 16:57:20 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher References: <411ABE80.4040309@nortelnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org Subject: [MSEC] Re: Comments on http://www.ietf.org/internet-drafts/draft-ietf-msec-g doiv2-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: 7bit Mark, I still think we are not that far apart, although I am realizing that there are some differences in our approach to this. I am starting out with a simple spec, but Ran's and Hugh's suggestions for TESLA and policy token (you also suggest this, right?), EAP, and other requirements such as distributed GCKS operation (the old intra-gkm I-D by Thomas, Brad and Inder is what I have in mind, at least to start with) and GCKS discovery look to be some additional features, that might make this a fairly bulky document. As I noted in my previous email, the last two topics may be separated from a "core spec." Please see inline for some additional thoughts: Mark Baugher wrote: > Lakshminath, > > On Aug 11, 2004, at 5:49 PM, Dondeti, Lakshminath wrote: > >> Mark, >> >> First, let me say that I am open to changes including the title :-). >> My goal is a group key download protocol similar to IKEv2, so we can >> reuse the basic constructs. I am open to the use cases you mention >> below as well as adding support for GCKS discovery and inter-GCKS >> protocol (although I am curious if that work should be in a separate >> document). I will try and address the items below. >> Mark Baugher wrote: >> >>> Lakshminath, all >>> I read the GDOIv2 draft and think we should go back to the drawing >>> board. We do need a version 2 of GDOI but this draft redefines GDOI >>> into yet-another group key management protocol - and says so >>> plainly. My objections are explained in what follows and my points >>> are numbered. >>> >>> 1. The title of the GDOIv2 I-D is changed from GDOIv1 RFC. Why rename >>> something when the version number changes? I am the one who named GDOI >>> as the "group domain of interpretation" for ISAKMP. If it is no longer >>> a group domain of interpretation for ISAKMP, then I would not call it >>> GDOI. And I'm unaware of any evidence that ISAKMP-based protocols are >>> "efficient." If you really want something that is Group IKE and not an >>> ISAKMP DOI, then you should just invent a new protocol and give it a >>> new name. I am interested in developing a second version of GDOI. >>> >> IKEv2 is considerably more efficient than IKE, and removes the DOI >> concept. > > Two ideas are juxtaposed that may have not correspondence. It is true > that IKEv2 has a more efficient phase 1 and phase 2 negotiation. And > it is also true that it removes the DOI concept. It is not true that > IKEv2 is more efficient because it removes the DOI concept. > > We want the DOI concept since we want to use a core key establishment > framework with a profile, for groups in our case. If you throw out > the DOI concept in IKEv2 in one door, it comes in through another, > because you are using IKEv2 as a core protocol and extending with a > distinct profile, e.g. with some new payloads. At least with ISAKMP, > this is explicit. > With distinct ports being used, for instance in case of IKE and GDOI, my understanding is that we can do without the DOI field (so port 500 would indicate an IKE/IKEv2 message and 848 would mean GDOI message, irrespective of what's in the DOI field; of course following the specs strictly would mean that we still check what's in that field - w.r.t. IKE and GDOI only - and reject messages with illegal values). Although, I think I understand what you mean - in that the DOI is there explicitly or implicitly. Anyway, if you care to clarify your thoughts on this further, I will appreciate it! >> I am thinking of GDOIv2 in the same vein. As you note in one of your >> points below, and I noted at the meeting, the work is mostly >> cut-and-paste from IKEv2 I-D and reuse of constructs from GDOI and >> policy token from GSAKMP. >> >>> 2. I am interested in a second version of GDOI that supports a two >>> message exchange, like IKEv2, and better supports devices on home >>> entertainment networks. In fact, I would port some of the functions >>> and even some of the design from GSAKMP into GDOIv2 as well as the >>> 2-message exchange (Child-SA functionality) from IKEv2. We need to >>> support the policy token, perhaps in a form adapted to GDOI (e.g. no >>> ASN.1, thank you :). We need to support GCKS discovery. And we need >>> to support GCKS-GCKS exchanges. >>> >> I am also interested in GCKS discovery and inter-GCKS communication. >> >>> 3. The IKEv2 phase 1 functionality is pretty much the focus of this I-D >>> and it's the least interesting technical issue in GDOIv2 IMHO. If >>> fact, this should be a no-brainer. Fixing the proof-of-possession >>> protocol in the second version is also pretty much a no-brainer. >>> >> Agreed :-). >> >>> 4. What's more interesting is the inter-GCKS protocol. We need to >>> discuss a number of alternative designs. For example, should we do it >>> like SMTP, which is a client/server protocol that allows each server to >>> act as a forwarding client. Or do we invent another protocol for >>> GCKS-GCKS communication? >>> >>> 5. Also of interest is the policy token, which could use a core/profile >>> design to allow application-specific policies such as PERM rights >>> management payload. >>> >> I need to think about PERM fits in here. >> >> I think there is common ground, although we may have slightly >> different view points. I would rather see us discuss and converge on >> a single IKEv2+GDOI-based protocol rather than adding more KM >> protocols to the mix. To reiterate, my interest is to design a >> protocol as efficient as IKEv2 without morphing it too much (so we >> can reuse as much code as possible). > > > I have not heard anyone say that they cannot deploy GDOI because it is > not efficient enough in its exchanges. We have seen the need for a > simple 2-message key establishment and have MIKEY for this purpose. > The 2-message case is a specialized need that has to do with assuming > only one (e.g., SIP) roundtrip available for the key establishment. > That's fine, but this efficiency comes at a cost in terms of identity > protection, i.e. there are good reasons for having a 3 or 4 message > exchange from a security standpoint. > Here is my perspective of this: IKEv2 is simpler, has lower latency, simpler to analyze, reliable, flexible, compared to IKE (this characterization is from ikev2-14, put in one sentence :-) ). If that is the justification for someone to implement IKEv2, it is natural to look for a group key download protocol that is along the same lines (in other words, why implement/deploy GDOI - based on IKE, which is supposed to be replaced by IKEv2, whenever that happens). So, In a way, I set out to do what you suggest below (would give it a shorter name though :-)), but looks like will end up adding some new features. regards, Lakshminath > I'd say that if all you want is an IKEv2 type of exchange, then why > not write a less ambitious I-D that simply adds a new, combined Phase > 1 and Phase 2 for GDOI. You could call it "a new Phase 1 and Phase 2 > exchange for GDOI." > > cheers, Mark > >> >> best, >> Lakshminath >> >>> 6. We need to consider how to securely discover GCKS nodes. (Cathy >>> Meadow's successful attack on the GDOIv1 POP involves a GCKS server >>> that acts as a client to another GCKS unbeknownst to a requesting >>> client/member.) We can roll our own secure service discovery protocol >>> or use a general-purpose standard (rendezvous, upnp, >>> http://www.ietf.org/html.charters/svrloc-charter.html - and possibly >>> some others). This needs to be discussed. >>> >>> So, I want to stop work on this I-D and reset the work on a second >>> version of GDOI, which I personally want to contribute to. We used to >>> refer to GDOI as "group IKE" and that is one attribute of GDOI - among >>> many. If Lakshminath or others think we need a better group IKE, then >>> I think they and perhaps even the WG might want to pursue it. But GDOI >>> is named in the context of the ISAKMP DOI framework and it is what it >>> is. >>> >>> thanks, Mark >>> >>> >> > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 12 19:41:44 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17845 for ; Thu, 12 Aug 2004 19:41:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 98E998D0A8; Thu, 12 Aug 2004 19:41: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 75D3C8D099 for ; Thu, 12 Aug 2004 19:41:39 -0400 (EDT) Received: (qmail 58385 invoked by uid 3269); 12 Aug 2004 23:41:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58382 invoked from network); 12 Aug 2004 23:41:39 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 12 Aug 2004 23:41:39 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2004 16:43:26 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn3-697.cisco.com [10.21.66.185]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7CNeQCL004978; Thu, 12 Aug 2004 16:40:26 -0700 (PDT) In-Reply-To: <411BD9B0.50804@nortelnetworks.com> References: <411ABE80.4040309@nortelnetworks.com> <411BD9B0.50804@nortelnetworks.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20C9F0C6-ECB9-11D8-A2A0-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Thu, 12 Aug 2004 16:41:27 -0700 To: "Dondeti, Lakshminath" X-Mailer: Apple Mail (2.618) Cc: msec@securemulticast.org Subject: [MSEC] Re: Comments on http://www.ietf.org/internet-drafts/draft-ietf-msec-g doiv2-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: 7bit Lakshminath, On Aug 12, 2004, at 1:57 PM, Dondeti, Lakshminath wrote: > Mark, > > I still think we are not that far apart, although I am realizing that > there are some differences in our approach to this. > I am starting out with a simple spec, but Ran's and Hugh's suggestions > for TESLA and policy token (you also suggest this, right?), I think we need to at least consider whether to add a policy token payload in GDOI, yes. > EAP, I don't know why EAP is in the picture. > and other requirements such as distributed GCKS operation (the old > intra-gkm I-D by Thomas, Brad and Inder is what I have in mind, at > least to start with) Like I said, some protocols such as SMTP allow the entity to act as a client and a server, perhaps GDOI's protocol can allow a GDOI entity to act as a member or a controller, i.e. we use the Phase 1 and Phase 2 exchanges as a GCKS-GCKS protocol. (I would call this an "inter-GCKS" protocol and I don't recall the "intra-GCKS" protocol very well from the SMuG days). > and GCKS discovery look to be some additional features, that might > make this a fairly bulky document. Maybe. I think we would need to get into the work to see what's involved. > As I noted in my previous email, the last two topics may be separated > from a "core spec." I think the core spec is RFC 2408 - at least that's one way to look at it. The change to the core spec would be the 2-message exchange. > > Please see inline for some additional thoughts: > > Mark Baugher wrote: > >> Lakshminath, >> >> On Aug 11, 2004, at 5:49 PM, Dondeti, Lakshminath wrote: >> >>> Mark, >>> >>> First, let me say that I am open to changes including the title :-). >>> My goal is a group key download protocol similar to IKEv2, so we can >>> reuse the basic constructs. I am open to the use cases you mention >>> below as well as adding support for GCKS discovery and inter-GCKS >>> protocol (although I am curious if that work should be in a separate >>> document). I will try and address the items below. >>> Mark Baugher wrote: >>> >>>> Lakshminath, all >>>> I read the GDOIv2 draft and think we should go back to the >>>> drawing >>>> board. We do need a version 2 of GDOI but this draft redefines GDOI >>>> into yet-another group key management protocol - and says so >>>> plainly. My objections are explained in what follows and my points >>>> are numbered. >>>> >>>> 1. The title of the GDOIv2 I-D is changed from GDOIv1 RFC. Why >>>> rename >>>> something when the version number changes? I am the one who named >>>> GDOI >>>> as the "group domain of interpretation" for ISAKMP. If it is no >>>> longer >>>> a group domain of interpretation for ISAKMP, then I would not call >>>> it >>>> GDOI. And I'm unaware of any evidence that ISAKMP-based protocols >>>> are >>>> "efficient." If you really want something that is Group IKE and >>>> not an >>>> ISAKMP DOI, then you should just invent a new protocol and give it a >>>> new name. I am interested in developing a second version of GDOI. >>>> >>> IKEv2 is considerably more efficient than IKE, and removes the DOI >>> concept. >> >> Two ideas are juxtaposed that may have not correspondence. It is >> true that IKEv2 has a more efficient phase 1 and phase 2 negotiation. >> And it is also true that it removes the DOI concept. It is not true >> that IKEv2 is more efficient because it removes the DOI concept. >> >> We want the DOI concept since we want to use a core key establishment >> framework with a profile, for groups in our case. If you throw out >> the DOI concept in IKEv2 in one door, it comes in through another, >> because you are using IKEv2 as a core protocol and extending with a >> distinct profile, e.g. with some new payloads. At least with ISAKMP, >> this is explicit. >> > With distinct ports being used, for instance in case of IKE and GDOI, > my understanding is that we can do without the DOI field (so port 500 > would indicate an IKE/IKEv2 message and 848 would mean GDOI message, > irrespective of what's in the DOI field; of course following the specs > strictly would mean that we still check what's in that field - w.r.t. > IKE and GDOI only - and reject messages with illegal values). > > Although, I think I understand what you mean - in that the DOI is > there explicitly or implicitly. Anyway, if you care to clarify your > thoughts on this further, I will appreciate it! The DOI field is the outward expression of the ISAKMP design, which provides a framework that gets bound to a DOI having specific payloads plus optional additional extensions such as new exchanges. It seems to be a clean approach to extending a pairwise key establishment system to take a "group key" approach to multicast key establishment. In this extension, the point-to-point key management protocol serves to establish a group key at a group member in addition to a pairwise key, which forms the security association between member and controller. With the DOI field, it is possible to build this right on top of the existing protocol, e.g. IKEv1. Without the DOI field, then the design is not so clean. IKEv1 never seemed to accept its fate as an ISAKMP DOI. IKEv1 wanted to be the framework. IKEv2 eliminates the framework. But it may be straightforward to extend an IKEv2 implementation to offer GDOI functionality. > >>> I am thinking of GDOIv2 in the same vein. As you note in one of >>> your points below, and I noted at the meeting, the work is mostly >>> cut-and-paste from IKEv2 I-D and reuse of constructs from GDOI and >>> policy token from GSAKMP. >>> >>>> 2. I am interested in a second version of GDOI that supports a two >>>> message exchange, like IKEv2, and better supports devices on home >>>> entertainment networks. In fact, I would port some of the functions >>>> and even some of the design from GSAKMP into GDOIv2 as well as the >>>> 2-message exchange (Child-SA functionality) from IKEv2. We need to >>>> support the policy token, perhaps in a form adapted to GDOI (e.g. no >>>> ASN.1, thank you :). We need to support GCKS discovery. And we >>>> need >>>> to support GCKS-GCKS exchanges. >>>> >>> I am also interested in GCKS discovery and inter-GCKS communication. >>> >>>> 3. The IKEv2 phase 1 functionality is pretty much the focus of this >>>> I-D >>>> and it's the least interesting technical issue in GDOIv2 IMHO. If >>>> fact, this should be a no-brainer. Fixing the proof-of-possession >>>> protocol in the second version is also pretty much a no-brainer. >>>> >>> Agreed :-). >>> >>>> 4. What's more interesting is the inter-GCKS protocol. We need to >>>> discuss a number of alternative designs. For example, should we do >>>> it >>>> like SMTP, which is a client/server protocol that allows each >>>> server to >>>> act as a forwarding client. Or do we invent another protocol for >>>> GCKS-GCKS communication? >>>> >>>> 5. Also of interest is the policy token, which could use a >>>> core/profile >>>> design to allow application-specific policies such as PERM rights >>>> management payload. >>>> >>> I need to think about PERM fits in here. >>> >>> I think there is common ground, although we may have slightly >>> different view points. I would rather see us discuss and converge >>> on a single IKEv2+GDOI-based protocol rather than adding more KM >>> protocols to the mix. To reiterate, my interest is to design a >>> protocol as efficient as IKEv2 without morphing it too much (so we >>> can reuse as much code as possible). >> >> >> I have not heard anyone say that they cannot deploy GDOI because it >> is not efficient enough in its exchanges. We have seen the need for >> a simple 2-message key establishment and have MIKEY for this purpose. >> The 2-message case is a specialized need that has to do with >> assuming only one (e.g., SIP) roundtrip available for the key >> establishment. That's fine, but this efficiency comes at a cost in >> terms of identity protection, i.e. there are good reasons for having >> a 3 or 4 message exchange from a security standpoint. >> > Here is my perspective of this: IKEv2 is simpler, has lower latency, > simpler to analyze, reliable, flexible, compared to IKE (this > characterization is from ikev2-14, put in one sentence :-) ). If that > is the justification for someone to implement IKEv2, it is natural to > look for a group key download protocol that is along the same lines > (in other words, why implement/deploy GDOI - based on IKE, which is > supposed to be replaced by IKEv2, whenever that happens). > > So, In a way, I set out to do what you suggest below (would give it a > shorter name though :-)), but looks like will end up adding some new > features. I think that the narrower effort of just adding an IKEv2 Phase 1 or Phase 1/2 to GDOI would meet your objectives. You can leave the policy, GCKS-GCKS protocol, and GCKS discovery to a larger effort that should use the name "GDOIv2." Mark > > regards, > Lakshminath > >> I'd say that if all you want is an IKEv2 type of exchange, then why >> not write a less ambitious I-D that simply adds a new, combined Phase >> 1 and Phase 2 for GDOI. You could call it "a new Phase 1 and Phase 2 >> exchange for GDOI." >> >> cheers, Mark >> >>> >>> best, >>> Lakshminath >>> >>>> 6. We need to consider how to securely discover GCKS nodes. (Cathy >>>> Meadow's successful attack on the GDOIv1 POP involves a GCKS server >>>> that acts as a client to another GCKS unbeknownst to a requesting >>>> client/member.) We can roll our own secure service discovery >>>> protocol >>>> or use a general-purpose standard (rendezvous, upnp, >>>> http://www.ietf.org/html.charters/svrloc-charter.html - and >>>> possibly >>>> some others). This needs to be discussed. >>>> >>>> So, I want to stop work on this I-D and reset the work on a second >>>> version of GDOI, which I personally want to contribute to. We used >>>> to >>>> refer to GDOI as "group IKE" and that is one attribute of GDOI - >>>> among >>>> many. If Lakshminath or others think we need a better group IKE, >>>> then >>>> I think they and perhaps even the WG might want to pursue it. But >>>> GDOI >>>> is named in the context of the ISAKMP DOI framework and it is what >>>> it >>>> is. >>>> >>>> thanks, Mark >>>> >>>> >>> >> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 16 13:26:48 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16479 for ; Mon, 16 Aug 2004 13:26:45 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0A18A8CAF7; Mon, 16 Aug 2004 13:26: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 A48E68CAA0 for ; Mon, 16 Aug 2004 13:26:44 -0400 (EDT) Received: (qmail 43257 invoked by uid 3269); 16 Aug 2004 17:26:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43254 invoked from network); 16 Aug 2004 17:26:44 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 16 Aug 2004 17:26:44 -0000 Received: (qmail 38339 invoked from network); 16 Aug 2004 17:26:44 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 16 Aug 2004 17:26:44 -0000 Received: (qmail 79347 invoked from network); 16 Aug 2004 13:26:43 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 16 Aug 2004 13:26:43 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7GEuf202688; Mon, 16 Aug 2004 10:56:41 -0400 Date: Mon, 16 Aug 2004 10:56:41 -0400 (EDT) From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: gmgross@nac.net Subject: [MSEC] comments on IPSEC RSA signature draft 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 Hi Brien, Generally this draft is in good shape, and I'm glad to see it moving forward. I'm still working through how I would implement this draft, and that process may uncover additional topics for discussion. In the meantime, here's what I found on my first read: ISSUE 1: In the ESP/AH RSA signatures draft section 2, there is paragraph that begins with the sentence: "Ephemeral RSA key pairs generated for use during the lifetime of an SA may be generated." I think I understand what this above sentence intends, but it is written in passive voice and it leaves some important things unsaid. As a clarification, how about replacing it with the following text: "The signing party MAY generate multiple ephemeral RSA key pairs during the SA lifetime. The public key's distribution mechanism and its replacement interval are a local policy matter. The SA key management protocol MUST provide a certification mechanism for the ephemeral RSA public key that complies with the profile in section 5.X. The signature verifiers MUST use that certification mechanism to assure that they use only an authentic and currently valid signature public key." The new sub-section 5.X would be entitled "Public Key Certification Mechanism Requirements" or something like that. See ISSUE 3 below. ISSUE 2: Does the same ESP SPI get used after each time that the key pair has changed? I'm wondering if that would make sense. Otherwise, the verifier would not know when the ESP packet stream has made its transition to a new public key. Out of order packet delivery would magnify this problem. Alternatively, the ESP authenticator must include a public key identifier field, which might be a good thing to introduce anyway. ISSUE 3: Ephermeral RSA key pairs creates a tough key management problem. I realize it is too heavyweight to require that there be a RFC3280 compliant certificate created for each ephermeral RSA key pair. OTOH, I think we have the obligation to say how do we handle: - key revocation in the event of private key compromise? - verify the validity period for the public key's lifetime? - thwart an active attacker that partitions the group during the transition between public keys. May be an unlikely case, but if the attacker withheld the "new public key" announcement from the group long enough, the attacker could crack the signature private key and then forge packet signatures to the sub-group under the attacker's control. - the public key's validation to a trust anchor when it is a traditional X.509 signature certificate key pair rather than an ephermeral key pair? I'm assuming you may use your X.509 EE signature cert, this is not prohibited, right? Specifying these key management mechanisms may be out of scope for this spec, but it would be good for this document to mandate a profile and requirements pointing at the mechanisms that handle these issues. I realize that the intent here is to get the benefit of "lightweight" public key cryptography without the baggage of PKI. So I agree that this flavor of digital signature ESP/AH is an important design goal. OTOH, I am concerned that we'll create a potential inter-operability problem unless we explicitly couple the RSA public key to something analogous to the PKIX standards that can manage that ephermeral public key's lifecycle. ISSUE 4: In section 5 there is the statement: "Use of this transform with a pair-wise key management system such as the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of using this transform for a pair-wise connection is limited, considering the performance impact." This statement precludes a policy that uses a digital signature for its non-repudiation characteristic. This may be useful in an application for which legal or economic policy requires that it can substantiate that only one of the two parties could have sent the signed message. I would suggest revising the text to say that local policy may elect to use this mechanism for non-repudiation provided the public key length is increased for the (presumably) longer period that the signature must be kept secure. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 16 13:43:01 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17233 for ; Mon, 16 Aug 2004 13:43:01 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CDAC18D1C8; Mon, 16 Aug 2004 13:43:01 -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 A5B5B8D1D8 for ; Mon, 16 Aug 2004 13:43:00 -0400 (EDT) Received: (qmail 46335 invoked by uid 3269); 16 Aug 2004 17:43:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46332 invoked from network); 16 Aug 2004 17:43:00 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 16 Aug 2004 17:43:00 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7GHgpW13747; Mon, 16 Aug 2004 12:42:51 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RBJQV5KZ; Mon, 16 Aug 2004 10:42:51 -0700 Received: from [47.16.67.20] (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QVY9ZH05; Mon, 16 Aug 2004 13:42:48 -0400 Message-ID: <4120F217.1010100@nortelnetworks.com> Date: Mon, 16 Aug 2004 13:42:47 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] comments on IPSEC RSA signature draft References: 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 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 My biggest concern with signing and hash chaining of IPsec packets is that we would be providing non-repudiation without the user asking for that capability (or burden :-)). Like many (they said it before I did) in the IPsec world, I believe non-repudiation is not an IP layer feature/requirement. It is an application layer feature/requirement. So, I think the "NOT RECOMMENDED" should stay. thanks, Lakshminath George Gross wrote: > ISSUE 4: In section 5 there is the statement: > > "Use of this transform with a pair-wise key management system such as > the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of > using this transform for a pair-wise connection is limited, > considering the performance impact." > > This statement precludes a policy that uses a digital signature for its > non-repudiation characteristic. This may be useful in an application for > which legal or economic policy requires that it can substantiate that > only > one of the two parties could have sent the signed message. I would > suggest > revising the text to say that local policy may elect to use this > mechanism > for non-repudiation provided the public key length is increased for the > (presumably) longer period that the signature must be kept secure. > > br, > George > > _______________________________________________ > 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 Aug 16 14:29:36 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20486 for ; Mon, 16 Aug 2004 14:29:36 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0CEBF8C6DA; Mon, 16 Aug 2004 14:29: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 5F9028C642 for ; Mon, 16 Aug 2004 14:29:36 -0400 (EDT) Received: (qmail 55208 invoked by uid 3269); 16 Aug 2004 18:29:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55204 invoked from network); 16 Aug 2004 18:29:36 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by klesh.pair.com with SMTP; 16 Aug 2004 18:29:36 -0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GITXB07243; Mon, 16 Aug 2004 21:29:33 +0300 (EET DST) X-Scanned: Mon, 16 Aug 2004 21:26:53 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i7GIQrL0002162; Mon, 16 Aug 2004 21:26:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 006kBKNx; Mon, 16 Aug 2004 21:26:52 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7GIQpn25478; Mon, 16 Aug 2004 21:26:51 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 16 Aug 2004 13:26:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] comments on IPSEC RSA signature draft Date: Mon, 16 Aug 2004 14:26:47 -0400 Message-ID: Thread-Topic: [MSEC] comments on IPSEC RSA signature draft Thread-Index: AcSDtmKMC/cj5M/tQzic+fb4qvGp0QABpi3Q From: To: , X-OriginalArrivalTime: 16 Aug 2004 18:26:48.0808 (UTC) FILETIME=[97DCEE80:01C483BE] 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 George, Some questions/comments inline. Thanks, Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext George Gross > Sent: Monday, August 16, 2004 10:57 AM > To: msec@securemulticast.org > Cc: gmgross@nac.net > Subject: [MSEC] comments on IPSEC RSA signature draft > > I realize that the intent here is to get the benefit of "lightweight" > public key cryptography without the baggage of PKI. So I=20 > agree that this > flavor of digital signature ESP/AH is an important design goal. If X.509 certificate are allowed, as you suggest, how is it lightweight public key cryptography without the baggage of PKI? > ISSUE 4: In section 5 there is the statement: >=20 > "Use of this transform with a pair-wise key management=20 > system such as > the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of > using this transform for a pair-wise connection is limited, > considering the performance impact." >=20 > This statement precludes a policy that uses a digital=20 > signature for its > non-repudiation characteristic. This may be useful in an=20 > application for > which legal or economic policy requires that it can=20 > substantiate that only > one of the two parties could have sent the signed message. I=20 > would suggest > revising the text to say that local policy may elect to use=20 > this mechanism > for non-repudiation provided the public key length is=20 > increased for the > (presumably) longer period that the signature must be kept secure. I had a question/comment here: In the case of IPsec, can we talk of transitive non-repudiation? IKE can use authentication mechanism which allows public-key cryptography and hence non-repudiation. Since keys (shared secrets) generated as a result of IKE are used in IPsec,=20 non-repudiation of IKE can imply non-repudiation of IPsec? Just a=20 thought/question/doubt. If that is true, then we have an option of non-repudiation in IPsec already. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 16 15:18:58 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24608 for ; Mon, 16 Aug 2004 15:18:58 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CBD7F8CFEA; Mon, 16 Aug 2004 15:18: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 DA3BA8CF2E for ; Mon, 16 Aug 2004 15:18:56 -0400 (EDT) Received: (qmail 65093 invoked by uid 3269); 16 Aug 2004 19:18:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65090 invoked from network); 16 Aug 2004 19:18:56 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 16 Aug 2004 19:18:56 -0000 Received: (qmail 10379 invoked from network); 16 Aug 2004 19:18:54 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 16 Aug 2004 19:18:54 -0000 Received: (qmail 46347 invoked from network); 16 Aug 2004 15:18:53 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 16 Aug 2004 15:18:53 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7GGmpY03060; Mon, 16 Aug 2004 12:48:51 -0400 Date: Mon, 16 Aug 2004 12:48:50 -0400 (EDT) From: George Gross To: "Dondeti, Lakshminath" Subject: Re: [MSEC] comments on IPSEC RSA signature draft In-Reply-To: <4120F217.1010100@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi Lakshminath, On Mon, 16 Aug 2004, Dondeti, Lakshminath wrote: > My biggest concern with signing and hash chaining of IPsec packets is > that we would be providing non-repudiation without the user asking for > that capability (or burden :-)). Not sure I understand the "burden" you are referring to. Both parties that entered into this SA negotiated and agreed to its proposals, which in this case is *their* pair-wise policy, they decided it is not a burden. For IPsec with IKE-v2, digital signature authentication remains optional, whereas HMAC-SHA1 and its cousins are mandatory to support. In particular, couldn't IPsec set up two nested SA, and only use RSA signature on the inner ESP header, but not use the inner ESP header on every packet, just use it occasionally for the policy defined "critical packets" in the application's data stream? > Like many (they said it before I did) > in the IPsec world, I believe non-repudiation is not an IP layer > feature/requirement. It is an application layer feature/requirement. > > So, I think the "NOT RECOMMENDED" should stay. Once we put a tool like RSA signature ESP in the IPsec toolkit, it is no longer feasible for the IETF to prescribe its usage policy to its users unless you can justify how the tool could negatively impact security if misused. I do not see that being the case here. are you saying that the non-repudiation "burden" really exists in a legal sense? do we add a health warning label like "Don't use this tool if you anticipate later get entangled in a court of jurisprudence for whom this signature would be used as evidence in its proceedings." i.e. don't sign if you don't know who could use it against you ;o) George > > thanks, > Lakshminath > > George Gross wrote: > > > ISSUE 4: In section 5 there is the statement: > > > > "Use of this transform with a pair-wise key management system such as > > the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of > > using this transform for a pair-wise connection is limited, > > considering the performance impact." > > > > This statement precludes a policy that uses a digital signature for its > > non-repudiation characteristic. This may be useful in an application for > > which legal or economic policy requires that it can substantiate that > > only > > one of the two parties could have sent the signed message. I would > > suggest > > revising the text to say that local policy may elect to use this > > mechanism > > for non-repudiation provided the public key length is increased for the > > (presumably) longer period that the signature must be kept secure. > > > > br, > > George > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 16 16:03:18 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01646 for ; Mon, 16 Aug 2004 16:03:18 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4B3C98CC56; Mon, 16 Aug 2004 16:03:19 -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 A8B598CC0C for ; Mon, 16 Aug 2004 16:03:17 -0400 (EDT) Received: (qmail 73223 invoked by uid 3269); 16 Aug 2004 20:03:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73219 invoked from network); 16 Aug 2004 20:03:17 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 16 Aug 2004 20:03:17 -0000 Received: (qmail 19925 invoked from network); 16 Aug 2004 16:03:17 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 16 Aug 2004 16:03:17 -0400 Received: (qmail 71897 invoked from network); 16 Aug 2004 16:03:16 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 16 Aug 2004 16:03:16 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7GHXDJ03134; Mon, 16 Aug 2004 13:33:13 -0400 Date: Mon, 16 Aug 2004 13:33:13 -0400 (EDT) From: George Gross To: Subject: RE: [MSEC] comments on IPSEC RSA signature draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: gmgross@nac.net, 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 Hi Atul, On Mon, 16 Aug 2004 Atul.Sharma@nokia.com wrote: > Hi George, > > Some questions/comments inline. > > Thanks, > Atul > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext George Gross > > Sent: Monday, August 16, 2004 10:57 AM > > To: msec@securemulticast.org > > Cc: gmgross@nac.net > > Subject: [MSEC] comments on IPSEC RSA signature draft > > > > I realize that the intent here is to get the benefit of "lightweight" > > public key cryptography without the baggage of PKI. So I > > agree that this > > flavor of digital signature ESP/AH is an important design goal. > > If X.509 certificate are allowed, as you suggest, how is it lightweight > public key cryptography without the baggage of PKI? My goal here was to discover whether existing certified public keys are allowed/not allowed by the spec. I do not want to require traditional X.509 public keys for all use cases. HOwever, as an option, it seems to me that you may want that capability when two conditions both hold true: 1) your policy does not trust that the key management protocol will distribute trustworthy ephemeral public keys (e.g the vendor happened to not give the user a knob to set the key length to match local policy). 2) your cryptographic group already trusts a PKI and the application's policy deems that the overhead of using an enrolled strong public/private key pair is acceptable (e.g you only occasionally sign the "critical" packets). I saw no reason to preclude this usage case and I wanted the spec to clarify that it was allowed. > > (presumably) longer period that the signature must be kept secure. > > I had a question/comment here: In the case of IPsec, can we talk > of transitive non-repudiation? IKE can use authentication mechanism > which allows public-key cryptography and hence non-repudiation. Since > keys (shared secrets) generated as a result of IKE are used in IPsec, > non-repudiation of IKE can imply non-repudiation of IPsec? Just a > thought/question/doubt. Technically speaking, the term "non-repudiation" as we've been using it is abit sloppy. Non-repudiation is really a legal process that only gets interpreted correctly in a court of law by assembling evidence. The pair-wise secret MAC authentication key generated by IKE is not likely to suffice for a non-repudiation process. If one party recorded the IKE-v2 mutual authentication messages, that might be useful as non-repudiation evidence if it included the peer's signature. As a degenerate case, one of the IKE-v2 parties could present an anonymous self-signed public key certificate and then do a weak authentication using EAP methods. Then the evidence arguably becomes weaker. > If that is true, then we have an option of non-repudiation in IPsec > already. > all shades of grey until a court rules ;o) hth, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 17 16:01:35 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11935 for ; Tue, 17 Aug 2004 16:01:34 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 990328C700; Tue, 17 Aug 2004 16:01:35 -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 098FC8C670 for ; Tue, 17 Aug 2004 16:01:34 -0400 (EDT) Received: (qmail 68257 invoked by uid 3269); 17 Aug 2004 20:01:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68254 invoked from network); 17 Aug 2004 20:01:33 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 17 Aug 2004 20:01:33 -0000 X-BrightmailFiltered: true Received: from cisco.com (dhcp-128-107-163-162.cisco.com [128.107.163.162]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7HK1FE7012637; Tue, 17 Aug 2004 13:01:16 -0700 (PDT) Message-ID: <41226577.2060400@cisco.com> Date: Tue, 17 Aug 2004 13:07:19 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] comments on IPSEC RSA signature draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Dondeti, Lakshminath" , 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 Hi George, Regarding non-repudiation: I did not intend for the RSA Signatures draft to convey that! Nowhere is non-repudiation claimed in the IPsec architecture, or in any of the documents that fit within that framework (including IKE and IKEv2). Digital signatures are intended for authentication. This draft should follow suit. George Gross wrote: >Hi Lakshminath, > >On Mon, 16 Aug 2004, Dondeti, Lakshminath wrote: > > > >>My biggest concern with signing and hash chaining of IPsec packets is >>that we would be providing non-repudiation without the user asking for >>that capability (or burden :-)). >> >> > >Not sure I understand the "burden" you are referring to. Both parties that >entered into this SA negotiated and agreed to its proposals, which in this >case is *their* pair-wise policy, they decided it is not a burden. For >IPsec with IKE-v2, digital signature authentication remains optional, >whereas HMAC-SHA1 and its cousins are mandatory to support. > > > There is a certainly a processing burden. The object of using RSA Signatures as an IPsec transform is to provide source origin authentication. In the absence of non-repudiation, there is no source origin authentication advantage for a pair-wise IPsec SA to use a digital signature. To the contrary: there is a significant processing penalty to digital signature in the pair-wise case. Hence the guidance to the unwary. :-) >In particular, couldn't IPsec set up two nested SA, and only use RSA >signature on the inner ESP header, but not use the inner ESP header on >every packet, just use it occasionally for the policy defined "critical >packets" in the application's data stream? > > > You're basically describing using two sets of policy for one set of traffic selectors. In general, that's possible. but the encapsulating device must have a process for deciding which set of policy to use, and this may be problematic to implement. I wouldn't recommend it. >>Like many (they said it before I did) >>in the IPsec world, I believe non-repudiation is not an IP layer >>feature/requirement. It is an application layer feature/requirement. >> >>So, I think the "NOT RECOMMENDED" should stay. >> >> > >Once we put a tool like RSA signature ESP in the IPsec toolkit, it is no >longer feasible for the IETF to prescribe its usage policy to its users >unless you can justify how the tool could negatively impact security if >misused. I do not see that being the case here. > >are you saying that the non-repudiation "burden" really exists in a legal >sense? > IMO, there are always legal implications to claiming non-repudiation. >do we add a health warning label like "Don't use this tool if you >anticipate later get entangled in a court of jurisprudence for whom this >signature would be used as evidence in its proceedings." i.e. don't sign >if you don't know who could use it against you ;o) > > > :-) It's just easier to not claim it. > George > > >>thanks, >>Lakshminath >> >>George Gross wrote: >> >> >> >>>ISSUE 4: In section 5 there is the statement: >>> >>> "Use of this transform with a pair-wise key management system such as >>> the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of >>> using this transform for a pair-wise connection is limited, >>> considering the performance impact." >>> >>>This statement precludes a policy that uses a digital signature for its >>>non-repudiation characteristic. This may be useful in an application for >>>which legal or economic policy requires that it can substantiate that >>>only >>>one of the two parties could have sent the signed message. I would >>>suggest >>>revising the text to say that local policy may elect to use this >>>mechanism >>>for non-repudiation provided the public key length is increased for the >>>(presumably) longer period that the signature must be kept secure. >>> >>> I prefer to leave the NOT RECOMMENDED statement, unless there is a WG consensus that it should be changed. Thanks, Brian >>>br, >>> George >>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://six.pairlist.net/mailman/listinfo/msec >>> >>> >>> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://six.pairlist.net/mailman/listinfo/msec >> >> >> > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 17 17:58:10 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17302 for ; Tue, 17 Aug 2004 17:58:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 118A88C9C3; Tue, 17 Aug 2004 17:58: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 CE0398CA8A for ; Tue, 17 Aug 2004 17:58:10 -0400 (EDT) Received: (qmail 91198 invoked by uid 3269); 17 Aug 2004 21:58:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91195 invoked from network); 17 Aug 2004 21:58:10 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 17 Aug 2004 21:58:10 -0000 Received: (qmail 83668 invoked from network); 17 Aug 2004 21:58:09 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 17 Aug 2004 21:58:09 -0000 Received: (qmail 7863 invoked from network); 17 Aug 2004 17:58:08 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 17 Aug 2004 17:58:08 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7HJRsp06064; Tue, 17 Aug 2004 15:27:54 -0400 Date: Tue, 17 Aug 2004 15:27:54 -0400 (EDT) From: George Gross To: Brian Weis Subject: Re: [MSEC] comments on IPSEC RSA signature draft In-Reply-To: <41226577.2060400@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , "Dondeti, Lakshminath" , 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 Hi Brian, On Tue, 17 Aug 2004, Brian Weis wrote: > Hi George, > > Regarding non-repudiation: I did not intend for the RSA Signatures draft > to convey that! Nowhere is non-repudiation claimed in the IPsec > architecture, or in any of the documents that fit within that framework > (including IKE and IKEv2). Digital signatures are intended for > authentication. This draft should follow suit. I understand your intention, but those pesky lawyers may hijack your mechanism at any key lengths and interpret the digital signature as being a legal signature! This question's answer is shades of grey: at what key strength does a RSA signature transition from a source authentication mechanism into one that also assists the legal process of non-repudiation? Even at smaller key lengths, it may be relevant to that legal process because there is a window of time after the signature where it could argued that an adversary would not have a reasonable technical means to break the private key and forge the signature. So an observer within the cryptographic group could testify that its timestamped records show that the signature was within that "non-repudiation" window. => that said, digital signatures do NOT by themselves provide non-repudiation, they are only evidence in the non-repudiation legal process and a given signature may or may not persuade that court that the signature was relevant and binding to the signer. We can not and should not attempt to answer this question here, we'd chase out tail forever debating it. The RSA signature draft can only bring the above issues to the implementors and the users attention, and let them devise their policy in the context of their local legal jurisdiction. what the RSA signature IPsec draft should do is require a management interface that allows alot of control over the RSA key strength, and specify it such that both signing endpoints and verifying endpoints will inter-operate. I recommend a range from 512 to 2048 bits in increments of 64 bits (or whatever). replies to a few loose ends inline below... > > George Gross wrote: > > >Hi Lakshminath, > > > >On Mon, 16 Aug 2004, Dondeti, Lakshminath wrote: > > > > > > > >>My biggest concern with signing and hash chaining of IPsec packets is > >>that we would be providing non-repudiation without the user asking for > >>that capability (or burden :-)). > >> > >> > > > >Not sure I understand the "burden" you are referring to. Both parties that > >entered into this SA negotiated and agreed to its proposals, which in this > >case is *their* pair-wise policy, they decided it is not a burden. For > >IPsec with IKE-v2, digital signature authentication remains optional, > >whereas HMAC-SHA1 and its cousins are mandatory to support. > > > > > > > There is a certainly a processing burden. The object of using RSA > Signatures as an IPsec transform is to provide source origin > authentication. In the absence of non-repudiation, there is no source > origin authentication advantage for a pair-wise IPsec SA to use a > digital signature. To the contrary: there is a significant processing > penalty to digital signature in the pair-wise case. Hence the guidance > to the unwary. :-) as discussed above, there is no exemption that prevents a signature from being considered as a legal signature. Again, this is a policy decision. The signer party may explicitly want non-repudiation and the processing cost is moot. Example: I send a multicast message to an auction group containing my $$$ bid. Or I send it to my peer in a pair-wise SA. Either way, I'm okay with it being legally binding, that is my intent in this context. > > >In particular, couldn't IPsec set up two nested SA, and only use RSA > >signature on the inner ESP header, but not use the inner ESP header on > >every packet, just use it occasionally for the policy defined "critical > >packets" in the application's data stream? > > > > > > > You're basically describing using two sets of policy for one set of > traffic selectors. In general, that's possible. but the encapsulating > device must have a process for deciding which set of policy to use, and > this may be problematic to implement. I wouldn't recommend it. I certainly can envision a host-based IPsec subsystem with an API that allows an application layer process to delegate authority to the IPsec subsystem sign a packet on its behalf. For an example of another mechanism that can support IPsec signature authorization, you could use an attribute certificate. So I do not consider it to be problematic to implement. > > >>Like many (they said it before I did) > >>in the IPsec world, I believe non-repudiation is not an IP layer > >>feature/requirement. It is an application layer feature/requirement. > >> > >>So, I think the "NOT RECOMMENDED" should stay. > >> > >> > > > >Once we put a tool like RSA signature ESP in the IPsec toolkit, it is no > >longer feasible for the IETF to prescribe its usage policy to its users > >unless you can justify how the tool could negatively impact security if > >misused. I do not see that being the case here. > > > >are you saying that the non-repudiation "burden" really exists in a legal > >sense? > > > IMO, there are always legal implications to claiming non-repudiation. > > >do we add a health warning label like "Don't use this tool if you > >anticipate later get entangled in a court of jurisprudence for whom this > >signature would be used as evidence in its proceedings." i.e. don't sign > >if you don't know who could use it against you ;o) > > > > > > > :-) It's just easier to not claim it. > > > George > > > > > >>thanks, > >>Lakshminath > >> > >>George Gross wrote: > >> > >> > >> > >>>ISSUE 4: In section 5 there is the statement: > >>> > >>> "Use of this transform with a pair-wise key management system such as > >>> the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of > >>> using this transform for a pair-wise connection is limited, > >>> considering the performance impact." > >>> > >>>This statement precludes a policy that uses a digital signature for its > >>>non-repudiation characteristic. This may be useful in an application for > >>>which legal or economic policy requires that it can substantiate that > >>>only > >>>one of the two parties could have sent the signed message. I would > >>>suggest > >>>revising the text to say that local policy may elect to use this > >>>mechanism > >>>for non-repudiation provided the public key length is increased for the > >>>(presumably) longer period that the signature must be kept secure. > >>> > >>> > I prefer to leave the NOT RECOMMENDED statement, unless there is a WG > consensus that it should be changed. A more accurate recommendation is to say that RSA signatures may have legal conotations in some jurisdictions. Therefore, when setting the RSA key strength policy, consider that factor if it is relevant in your jurisdiction. Saying anything else, including the above "NOT RECOMMENDED" statement is attempting to tell the users how they implement policy for the RSA signature, which the IETF does not do in standards. br, George > > Thanks, > Brian > > >>>br, > >>> George > >>> > >>>_______________________________________________ > >>>msec mailing list > >>>msec@securemulticast.org > >>>http://six.pairlist.net/mailman/listinfo/msec > >>> > >>> > >>> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://six.pairlist.net/mailman/listinfo/msec > >> > >> > >> > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://six.pairlist.net/mailman/listinfo/msec > > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 17 20:09:53 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24092 for ; Tue, 17 Aug 2004 20:09:52 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 06B848C85C; Tue, 17 Aug 2004 20:09: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 D23498C81D for ; Tue, 17 Aug 2004 20:09:50 -0400 (EDT) Received: (qmail 12620 invoked by uid 3269); 18 Aug 2004 00:09:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12616 invoked from network); 18 Aug 2004 00:09:50 -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; 18 Aug 2004 00:09:50 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 17 Aug 2004 17:13:52 -0700 X-BrightmailFiltered: true Received: from cisco.com (dhcp-128-107-163-162.cisco.com [128.107.163.162]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7I09kNJ001747; Tue, 17 Aug 2004 17:09:46 -0700 (PDT) Message-ID: <41229FB6.5050703@cisco.com> Date: Tue, 17 Aug 2004 17:15:50 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] comments on IPSEC RSA signature draft References: 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 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 George, Thanks for your detailed comments. Replied are inline below. George Gross wrote: >Hi Brien, > > Generally this draft is in good shape, and I'm glad to see it >moving forward. I'm still working through how I would implement this >draft, and that process may uncover additional topics for discussion. In >the meantime, here's what I found on my first read: > >ISSUE 1: In the ESP/AH RSA signatures draft section 2, there is paragraph >that begins with the sentence: > > "Ephemeral RSA key pairs generated for use during the lifetime of an > SA may be generated." > > > There is a slight typo in this original text, for which I apologize. It did not mean to imply that *multiple keypairs* would be used during the life of a single SA. Rather, a key pair may be generated for the express use of an SA. But that's just a recommendation. The keypair could be a long term keypair. But if so, I do not assume the need for a certificate. (This is discussed later in these comments.) >I think I understand what this above sentence intends, but it is written >in passive voice and it leaves some important things unsaid. As a >clarification, how about replacing it with the following text: > >"The signing party MAY generate multiple ephemeral RSA key pairs during >the SA lifetime. The public key's distribution mechanism and its >replacement interval are a local policy matter. The SA key management >protocol MUST provide a certification mechanism for the ephemeral RSA >public key that complies with the profile in section 5.X. The signature >verifiers MUST use that certification mechanism to assure that they use >only an authentic and currently valid signature public key." > >The new sub-section 5.X would be entitled "Public Key Certification >Mechanism Requirements" or something like that. See ISSUE 3 below. > > > I like the idea of "The public key's distribution mechanism and its replacement interval are a local policy matter." But your text additionally brings in some new concepts that I'm not quite ready to embrace. I do not believe that a certification mechanism is required. Section 5 lists the mechanism that should be used for specifying the public key, which is to deliver it during group key management. Since this is a per-SA attribute, it gets deleted when the SA expires, and the receiver need pay it no more mind. I have not specified how it would work outside of the group key management case, because of the NOT RECOMMEND guidance (to which you object in ISSUE 4). I see that Section 5 of the document needs to be clearer with respect to the handing of the public key. >ISSUE 2: Does the same ESP SPI get used after each time that the key pair >has changed? I'm wondering if that would make sense. Otherwise, the >verifier would not know when the ESP packet stream has made its transition >to a new public key. Out of order packet delivery would magnify this >problem. Alternatively, the ESP authenticator must include a public key >identifier field, which might be a good thing to introduce anyway. > > > This issue is moot, due to a misunderstanding of my buggy text. Again, my apologies. >ISSUE 3: Ephermeral RSA key pairs creates a tough key management problem. >I realize it is too heavyweight to require that there be a RFC3280 >compliant certificate created for each ephermeral RSA key pair. OTOH, I >think we have the obligation to say how do we handle: > > - key revocation in the event of private key compromise? > > > This is no more an issue than if an AES key was compromised. Deletion of the IPsec SA would be the mechanism. > - verify the validity period for the public key's lifetime? > > - thwart an active attacker that partitions the group during > the transition between public keys. May be an unlikely case, > but if the attacker withheld the "new public key" announcement from > the group long enough, the attacker could crack the signature > private key and then forge packet signatures to the sub-group > under the attacker's control. > > - the public key's validation to a trust anchor when it is a > traditional X.509 signature certificate key pair rather than > an ephermeral key pair? I'm assuming you may use your X.509 > EE signature cert, this is not prohibited, right? > > > The above three issues assume the presence of a certificate. Without a certificate, there is no issue. >Specifying these key management mechanisms may be out of scope for this >spec, but it would be good for this document to mandate a profile >and requirements pointing at the mechanisms that handle these issues. >I realize that the intent here is to get the benefit of "lightweight" >public key cryptography without the baggage of PKI. So I agree that this >flavor of digital signature ESP/AH is an important design goal. > >OTOH, I am concerned that we'll create a potential inter-operability >problem unless we explicitly couple the RSA public key to something >analogous to the PKIX standards that can manage that ephermeral >public key's lifecycle. > > > If a PKI was needed, I would definitely refer to PKIX document. My goal is to be so simple as to not require any sort of certificate infrastructure, just bare public keys distributed on a per-SA basis. I'll start a new thread on this list shortly to describe with some background on why I am promulgating such a limited vision. Thanks, Brian >ISSUE 4: In section 5 there is the statement: > > "Use of this transform with a pair-wise key management system such as > the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of > using this transform for a pair-wise connection is limited, > considering the performance impact." > >This statement precludes a policy that uses a digital signature for its >non-repudiation characteristic. This may be useful in an application for >which legal or economic policy requires that it can substantiate that only >one of the two parties could have sent the signed message. I would suggest >revising the text to say that local policy may elect to use this mechanism >for non-repudiation provided the public key length is increased for the >(presumably) longer period that the signature must be kept secure. > >br, > George > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 17 21:06:54 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29197 for ; Tue, 17 Aug 2004 21:06:54 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9222A8CDBB; Tue, 17 Aug 2004 21:06:55 -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 C20A08CD7A for ; Tue, 17 Aug 2004 21:06:53 -0400 (EDT) Received: (qmail 21375 invoked by uid 3269); 18 Aug 2004 01:06:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21372 invoked from network); 18 Aug 2004 01:06:53 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 18 Aug 2004 01:06:53 -0000 X-BrightmailFiltered: true Received: from cisco.com (dhcp-128-107-163-162.cisco.com [128.107.163.162]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7I16VPV024198 for ; Tue, 17 Aug 2004 18:06:32 -0700 (PDT) Message-ID: <4122AD03.7030506@cisco.com> Date: Tue, 17 Aug 2004 18:12:35 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues 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 There have been some good questions around the specifications of the public keys with respect to draft-ietf-msec-ipsec-signatures-01.txt. The draft says very little regarding how the public keys are derived, certified, validated, etc., and I'd like to provide some background as to why. 1. Simplicity. Certificates have requirements that are onerous in this application. Case in point: the SEND WG at one time attempted to specify the use of RSA signatures for per-packet authentication of IPv6 neighbor discovery messages. The SEND messages originally used AH. Given the SEND trust model, it was necessary to carry certificates in every packet along with the signature. This led to so many issues they eventually dropped the use of AH for their own packet format. These same issues would apply if to one degree or another if the RSA signatures draft explicitly supported certificates. 2. Simplicity. This document is intended to be an IPsec transform draft, in the spirit of RFC 2404. Parameters of keying material (in this case, a public key) need to be carefully described. But you will find that IPsec transform documents do not discuss key management, or even how the keys are created or obtained. Therefore it is not appropriate for the RSA Signatures document to get too deep into these issues. It certainly should not discuss PKI issues! Those belong to key management. Because using such an expensive cryptographic transform on a data packet is a novelty, I did include some text giving some minimal explanation and guidance regarding the usage of this transform. This is the last two paragraphs of Section 5. This does go beyond the other IPsec transform drafts. There is no reason whatsoever that public keys with certificates could not be used. But PKI issues around those keys belong to key management, not this document. Brian -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 17 21:45:12 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00818 for ; Tue, 17 Aug 2004 21:45:11 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E4C0A8C520; Tue, 17 Aug 2004 21:45: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 AE1E78C4F6 for ; Tue, 17 Aug 2004 21:45:11 -0400 (EDT) Received: (qmail 33369 invoked by uid 3269); 18 Aug 2004 01:45:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 33365 invoked from network); 18 Aug 2004 01:45:11 -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; 18 Aug 2004 01:45:11 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 17 Aug 2004 18:49:15 -0700 X-BrightmailFiltered: true Received: from cisco.com (dhcp-128-107-163-162.cisco.com [128.107.163.162]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7I1j618018173; Tue, 17 Aug 2004 18:45:06 -0700 (PDT) Message-ID: <4122B610.9090101@cisco.com> Date: Tue, 17 Aug 2004 18:51:12 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] comments on IPSEC RSA signature draft References: 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 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 George, George Gross wrote: >Hi Brian, > >On Tue, 17 Aug 2004, Brian Weis wrote: > > > >>Hi George, >> >>Regarding non-repudiation: I did not intend for the RSA Signatures draft >>to convey that! Nowhere is non-repudiation claimed in the IPsec >>architecture, or in any of the documents that fit within that framework >>(including IKE and IKEv2). Digital signatures are intended for >>authentication. This draft should follow suit. >> >> > >I understand your intention, but those pesky lawyers may hijack your >mechanism at any key lengths and interpret the digital signature as being >a legal signature! > >This question's answer is shades of grey: at what key strength does a RSA >signature transition from a source authentication mechanism into one that >also assists the legal process of non-repudiation? Even at smaller key >lengths, it may be relevant to that legal process because there is a >window of time after the signature where it could argued that an adversary >would not have a reasonable technical means to break the private key and >forge the signature. So an observer within the cryptographic group could >testify that its timestamped records show that the signature was within >that "non-repudiation" window. > >=> that said, digital signatures do NOT by themselves provide >non-repudiation, they are only evidence in the non-repudiation legal >process and a given signature may or may not persuade that court that the >signature was relevant and binding to the signer. > >We can not and should not attempt to answer this question here, we'd chase >out tail forever debating it. > Agreed. >The RSA signature draft can only bring the >above issues to the implementors and the users attention, and let them >devise their policy in the context of their local legal jurisdiction. > > > I see no reason why the draft needs to discuss non-repudiation or other legal issues with public keys. For example, RFC 2409 (which also used digital signatures for authentication) was not required to make such a statement. >what the RSA signature IPsec draft should do is require a management >interface that allows alot of control over the RSA key strength, and >specify it such that both signing endpoints and verifying endpoints will >inter-operate. I recommend a range from 512 to 2048 bits in increments of >64 bits (or whatever). > > > This is done. Section 2 describes key sizes. Section 5 defines the SA management interface controlling the key strength. [snip] > > > > >>>In particular, couldn't IPsec set up two nested SA, and only use RSA >>>signature on the inner ESP header, but not use the inner ESP header on >>>every packet, just use it occasionally for the policy defined "critical >>>packets" in the application's data stream? >>> >>> >>> >>> >>> >>You're basically describing using two sets of policy for one set of >>traffic selectors. In general, that's possible. but the encapsulating >>device must have a process for deciding which set of policy to use, and >>this may be problematic to implement. I wouldn't recommend it. >> >> > >I certainly can envision a host-based IPsec subsystem with an API that >allows an application layer process to delegate authority to the IPsec >subsystem sign a packet on its behalf. For an example of another mechanism >that can support IPsec signature authorization, you could use an attribute >certificate. So I do not consider it to be problematic to implement. > > > By problematic, I was implying that existing mechanisms (including the pervasive PF_KEY API used to push IPsec SAs into the kernel) would not support this behavior. >>>>ISSUE 4: In section 5 there is the statement: >>>> >>>> "Use of this transform with a pair-wise key management system such as >>>> the Internet Key Exchange [IKEv2] is NOT RECOMMENDED. The value of >>>> using this transform for a pair-wise connection is limited, >>>> considering the performance impact." >>>> >>>>This statement precludes a policy that uses a digital signature for its >>>>non-repudiation characteristic. This may be useful in an application for >>>>which legal or economic policy requires that it can substantiate that >>>>only >>>>one of the two parties could have sent the signed message. I would >>>>suggest >>>>revising the text to say that local policy may elect to use this >>>>mechanism >>>>for non-repudiation provided the public key length is increased for the >>>>(presumably) longer period that the signature must be kept secure. >>>> >>>> >>>> >>>> >>I prefer to leave the NOT RECOMMENDED statement, unless there is a WG >>consensus that it should be changed. >> >> > >A more accurate recommendation is to say that RSA signatures may have >legal conotations in some jurisdictions. Therefore, when setting the RSA >key strength policy, consider that factor if it is relevant in your >jurisdiction. > This is not a statement I recall in any IETF standard, and I don't think is needed here. >Saying anything else, including the above "NOT RECOMMENDED" >statement is attempting to tell the users how they implement policy for >the RSA signature, which the IETF does not do in standards. > > Actually, I believe this recommendation is in line with RFC 2119, which does describe the use of "NOT RECOMMEND": "4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." The "full implications [which] should be understood and the case carefully weighed before implementing" are defined as being performance related. (Note that this is not the same restriction as MUST NOT, which is a statement that even I would find objectionable.) Thanks, Brian >br, > George > > > >>Thanks, >>Brian >> >> >> >>>>>br, >>>>> George >>>>> >>>>>_______________________________________________ >>>>>msec mailing list >>>>>msec@securemulticast.org >>>>>http://six.pairlist.net/mailman/listinfo/msec >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://six.pairlist.net/mailman/listinfo/msec >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://six.pairlist.net/mailman/listinfo/msec >>> >>> >>> >>> >>> >> >> >> > > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 01:08:51 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11014 for ; Wed, 18 Aug 2004 01:08:50 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B43E78CC2F; Wed, 18 Aug 2004 01:08: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 6FFAB8CC15 for ; Wed, 18 Aug 2004 01:08:49 -0400 (EDT) Received: (qmail 98906 invoked by uid 3269); 18 Aug 2004 05:08:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98902 invoked from network); 18 Aug 2004 05:08:49 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 18 Aug 2004 05:08:49 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i7I562c75660; Wed, 18 Aug 2004 01:06:02 -0400 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7I57wc51350; Wed, 18 Aug 2004 01:07:58 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i7I57ve36006; Wed, 18 Aug 2004 01:07:57 -0400 Date: Wed, 18 Aug 2004 01:07:56 -0400 (EDT) From: canetti To: Brian Weis Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues In-Reply-To: <4122AD03.7030506@cisco.com> Message-ID: References: <4122AD03.7030506@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Brian, I totally agree with your approach. There should probably be some text in the I-D explaining this. A couple remarks: * We use RSA signatures for authentication. The fact that they might be used also for non-repudiability is not a concern of this I-D. Thus, we do not need to carry certificates around. Making sure that both parties have the correct verification keys in their respective SAs is the job of the key management protocol. * Digital signatures do not necessarily provide non-repudiation, regardless of the length of the keys. In order to provide non-repudiation, the public key of the signature should be appropriately certified. In fact, if the public key to be used in the session is never explicitly signed by the parties during the key exchange, then signing packets with the corresponding secert key provides full repudiability (while still providing perfectly good authentication). Ran On Tue, 17 Aug 2004, Brian Weis wrote: > There have been some good questions around the specifications of the > public keys with respect to draft-ietf-msec-ipsec-signatures-01.txt. The > draft says very little regarding how the public keys are derived, > certified, validated, etc., and I'd like to provide some background as > to why. > > 1. Simplicity. Certificates have requirements that are onerous in this > application. Case in point: the SEND WG at one time attempted to specify > the use of RSA signatures for per-packet authentication of IPv6 neighbor > discovery messages. The SEND messages originally used AH. Given the SEND > trust model, it was necessary to carry certificates in every packet > along with the signature. This led to so many issues they eventually > dropped the use of AH for their own packet format. These same issues > would apply if to one degree or another if the RSA signatures draft > explicitly supported certificates. > > 2. Simplicity. This document is intended to be an IPsec transform draft, > in the spirit of RFC 2404. Parameters of keying material (in this case, > a public key) need to be carefully described. But you will find that > IPsec transform documents do not discuss key management, or even how the > keys are created or obtained. Therefore it is not appropriate for the > RSA Signatures document to get too deep into these issues. It certainly > should not discuss PKI issues! Those belong to key management. > > Because using such an expensive cryptographic transform on a data packet > is a novelty, I did include some text giving some minimal explanation > and guidance regarding the usage of this transform. This is the last two > paragraphs of Section 5. This does go beyond the other IPsec transform > drafts. > > There is no reason whatsoever that public keys with certificates could > not be used. But PKI issues around those keys belong to key management, > not this document. > > Brian > > -- > Brian Weis > Advanced Security Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > 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 Aug 18 10:25:31 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09121 for ; Wed, 18 Aug 2004 10:25:30 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D5F4C8CCF2; Wed, 18 Aug 2004 10:25:30 -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 003C68C9CE for ; Wed, 18 Aug 2004 10:25:29 -0400 (EDT) Received: (qmail 3939 invoked by uid 3269); 18 Aug 2004 14:25:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3936 invoked from network); 18 Aug 2004 14:25:29 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by klesh.pair.com with SMTP; 18 Aug 2004 14:25:29 -0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IEPSB00326; Wed, 18 Aug 2004 17:25:28 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 17:23:33 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i7IENX7q010950; Wed, 18 Aug 2004 17:23:33 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00ET0T7M; Wed, 18 Aug 2004 17:23:30 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IENTu23951; Wed, 18 Aug 2004 17:23:29 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 09:23:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Why the rsa-signatures draft doesn't explicitly deal withPKI issues Date: Wed, 18 Aug 2004 10:23:25 -0400 Message-ID: Thread-Topic: [MSEC] Why the rsa-signatures draft doesn't explicitly deal withPKI issues Thread-Index: AcSE4Zk6ExLGCbgaQDG7a+nn6T13pQASGaLw From: To: , X-OriginalArrivalTime: 18 Aug 2004 14:23:27.0058 (UTC) FILETIME=[ED5E3320:01C4852E] 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 I agree, non-repudiation should be an (possibly negotiable)option for the parties involved in the secure communication. It should=20 not be mandated. I guess that is why IKE has shy'd away from=20 mandating signatures with certificates. Also, Ran brings up a good argument: that signatures by themselves do not imply non-repudiation. It is in the proof of possession of the keys that we can imply non-repudiation. But at the same time, the issue of non-repudiation raised by George brings about few interesting questions: * How do we provide an option (not mandated) in IPsec protocols to provide non-repudiation? I had suggested a way using=20 transitive-non-repudiation using the non-repudiated optional IKE communication. Something to convey to the IPsec working=20 group. Not an MSEC WG item. * We are saying that this I-D talks about just usage of signatures not how keys used in the signatures are gotten/certified. But do we have a precedent in IETF, where signatures are used without certificates? Is there a standard/standards track document which conveys how signatures can optionally be used without certificates? Though not necessary, digital signatures do generally imply=20 certificates. * Though this I-D need not be worried about certificates, MSEC group=20 has to be mindful of this issue. What good be standardizing usage of signatures in MSEC, without telling how those signatures shall be gotten, from what keys, how those keys shall be gotten/certified? These are all implementation issues. And in IETF, at least, implementation is an integral part of the standardization process. * Do we want to make it a WG action item: signatures or rather public=20 keys without certificates an option in MSEC key management protocols? Just my thoughts on this issue. Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext canetti > Sent: Wednesday, August 18, 2004 1:08 AM > To: Brian Weis > Cc: msec@securemulticast.org > Subject: Re: [MSEC] Why the rsa-signatures draft doesn't=20 > explicitly deal > withPKI issues >=20 >=20 >=20 > Brian, I totally agree with your approach. > There should probably be some text in the I-D explaining this. >=20 > A couple remarks: >=20 > * We use RSA signatures for authentication. The fact that=20 > they might be > used also for non-repudiability is not a concern of this I-D.=20 > Thus, we do > not need to carry certificates around. Making sure that both=20 > parties have > the correct verification keys in their respective SAs is the=20 > job of the > key management protocol. >=20 > * Digital signatures do not necessarily provide non-repudiation, > regardless of the length of the keys. In order to provide=20 > non-repudiation, > the public key of the signature should be appropriately certified. > In fact, if the public key to be used in the session is never > explicitly signed by the parties during the key exchange, then signing > packets with the corresponding secert key provides full repudiability > (while still providing perfectly good authentication). >=20 > Ran >=20 >=20 > On Tue, 17 Aug 2004, Brian Weis wrote: >=20 > > There have been some good questions around the specifications of the > > public keys with respect to=20 > draft-ietf-msec-ipsec-signatures-01.txt. The > > draft says very little regarding how the public keys are derived, > > certified, validated, etc., and I'd like to provide some=20 > background as > > to why. > > > > 1. Simplicity. Certificates have requirements that are=20 > onerous in this > > application. Case in point: the SEND WG at one time=20 > attempted to specify > > the use of RSA signatures for per-packet authentication of=20 > IPv6 neighbor > > discovery messages. The SEND messages originally used AH.=20 > Given the SEND > > trust model, it was necessary to carry certificates in every packet > > along with the signature. This led to so many issues they eventually > > dropped the use of AH for their own packet format. These same issues > > would apply if to one degree or another if the RSA signatures draft > > explicitly supported certificates. > > > > 2. Simplicity. This document is intended to be an IPsec=20 > transform draft, > > in the spirit of RFC 2404. Parameters of keying material=20 > (in this case, > > a public key) need to be carefully described. But you will find that > > IPsec transform documents do not discuss key management, or=20 > even how the > > keys are created or obtained. Therefore it is not=20 > appropriate for the > > RSA Signatures document to get too deep into these issues.=20 > It certainly > > should not discuss PKI issues! Those belong to key management. > > > > Because using such an expensive cryptographic transform on=20 > a data packet > > is a novelty, I did include some text giving some minimal=20 > explanation > > and guidance regarding the usage of this transform. This is=20 > the last two > > paragraphs of Section 5. This does go beyond the other=20 > IPsec transform > > drafts. > > > > There is no reason whatsoever that public keys with=20 > certificates could > > not be used. But PKI issues around those keys belong to key=20 > management, > > not this document. > > > > Brian > > > > -- > > Brian Weis > > Advanced Security Development, ITD, Cisco Systems > > Telephone: +1 408 526 4796 > > Email: bew@cisco.com > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 10:35:20 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09782 for ; Wed, 18 Aug 2004 10:35:20 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A9B288CCD1; Wed, 18 Aug 2004 10:35:21 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 735038C676 for ; Wed, 18 Aug 2004 10:35:20 -0400 (EDT) Received: (qmail 6927 invoked by uid 3269); 18 Aug 2004 14:35:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6924 invoked from network); 18 Aug 2004 14:35:20 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by klesh.pair.com with SMTP; 18 Aug 2004 14:35:20 -0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IEZIB17630; Wed, 18 Aug 2004 17:35:18 +0300 (EET DST) X-Scanned: Wed, 18 Aug 2004 17:33:30 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7IEXURe026116; Wed, 18 Aug 2004 17:33:30 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00lPnvAp; Wed, 18 Aug 2004 17:33:29 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7IEXMn27702; Wed, 18 Aug 2004 17:33:23 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 18 Aug 2004 09:33:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Why the rsa-signatures draft doesn't explicitly dealwithPKI issues Date: Wed, 18 Aug 2004 10:33:10 -0400 Message-ID: Thread-Topic: [MSEC] Why the rsa-signatures draft doesn't explicitly dealwithPKI issues Thread-Index: AcSE4Zk6ExLGCbgaQDG7a+nn6T13pQASGaLwAAGGBvA= From: To: , , X-OriginalArrivalTime: 18 Aug 2004 14:33:12.0363 (UTC) FILETIME=[4A3CA7B0:01C48530] 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 > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext=20 > Sent: Wednesday, August 18, 2004 10:23 AM > To: canetti@watson.ibm.com; bew@cisco.com > Cc: msec@securemulticast.org > Subject: RE: [MSEC] Why the rsa-signatures draft doesn't explicitly > dealwithPKI issues > > > * How do we provide an option (not mandated) in IPsec protocols > to provide non-repudiation? I had suggested a way using=20 > transitive-non-repudiation using the non-repudiated optional > IKE communication. Something to convey to the IPsec working=20 > group. Not an MSEC WG item. May be I will write an I-D on this for IPsec WG. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 10:57:25 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11302 for ; Wed, 18 Aug 2004 10:57:24 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 380368D036; Wed, 18 Aug 2004 10:57: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 46B588D031 for ; Wed, 18 Aug 2004 10:57:24 -0400 (EDT) Received: (qmail 10929 invoked by uid 3269); 18 Aug 2004 14:57:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10926 invoked from network); 18 Aug 2004 14:57:24 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 18 Aug 2004 14:57:24 -0000 Received: (qmail 61861 invoked from network); 18 Aug 2004 10:57:11 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 18 Aug 2004 10:57:11 -0400 Received: (qmail 47949 invoked from network); 18 Aug 2004 10:57:10 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 18 Aug 2004 10:57:10 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7ICQn107269; Wed, 18 Aug 2004 08:26:49 -0400 Date: Wed, 18 Aug 2004 08:26:49 -0400 (EDT) From: George Gross To: Brian Weis Subject: Re: [MSEC] comments on IPSEC RSA signature draft In-Reply-To: <41229FB6.5050703@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , 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 Hi Brian, I hate to belabor this thread, but some things are still dangling... On Tue, 17 Aug 2004, Brian Weis wrote: > Hi George, > > Thanks for your detailed comments. Replied are inline below. > > George Gross wrote: > > >Hi Brien, > > > > Generally this draft is in good shape, and I'm glad to see it > >moving forward. I'm still working through how I would implement this > >draft, and that process may uncover additional topics for discussion. In > >the meantime, here's what I found on my first read: > > > >ISSUE 1: In the ESP/AH RSA signatures draft section 2, there is paragraph > >that begins with the sentence: > > > > "Ephemeral RSA key pairs generated for use during the lifetime of an > > SA may be generated." > > > > > > > There is a slight typo in this original text, for which I apologize. It > did not mean to imply that *multiple keypairs* would be used during the > life of a single SA. Rather, a key pair may be generated for the express > use of an SA. But that's just a recommendation. The keypair could be a > long term keypair. But if so, I do not assume the need for a > certificate. (This is discussed later in these comments.) > > >I think I understand what this above sentence intends, but it is written > >in passive voice and it leaves some important things unsaid. As a > >clarification, how about replacing it with the following text: > > > >"The signing party MAY generate multiple ephemeral RSA key pairs during > >the SA lifetime. The public key's distribution mechanism and its > >replacement interval are a local policy matter. The SA key management > >protocol MUST provide a certification mechanism for the ephemeral RSA > >public key that complies with the profile in section 5.X. The signature > >verifiers MUST use that certification mechanism to assure that they use > >only an authentic and currently valid signature public key." > > > >The new sub-section 5.X would be entitled "Public Key Certification > >Mechanism Requirements" or something like that. See ISSUE 3 below. > > > > > > > I like the idea of "The public key's distribution mechanism and its > replacement interval are a local policy matter." But your text > additionally brings in some new concepts that I'm not quite ready to > embrace. I do not believe that a certification mechanism is required. > Section 5 lists the mechanism that should be used for specifying the > public key, which is to deliver it during group key management. Since > this is a per-SA attribute, it gets deleted when the SA expires, and the > receiver need pay it no more mind. The IPsec RSA signature draft is under specified for its requirements on the group key management protocol, which is taking on the responsibility as the "public key certification" mechanism. I would like to see the draft's section 5 require that the group key management protocol specify the following things about the public key: 1. In the case where the Group Speaker generates its own public/private key pair, the group key management protocol MUST include a proof of possession of the signature private key exchange between the GC/KS and the Group Speaker. 2. The public key MUST be delivered to the group membership by the group key management protocol using an authenticated certification mechanism. For example, in GDOI this certification is the inclusion of the public key as signed data under the ISAKMP Signature payload [RFC2408 section 3.12] signed by a trusted GC/KS. Incidently, the RFC2408 text in section 3.12 *explicitly* says that the ISAKMP signature payload can be used in non-repudiation services. So the IPsec RSA signature public key is implicitly a certified key that can also offer non-repudiation services ;o) 3. The public key's validity period is the same as the SA lifetime, and there MUST be an accurate mechanism for all of the group members to detect when the public key has expired. When the validity period expires, any signature using that public key must be ignored, the packet discarded, and the SA deleted. 4. The group key management protocol SHOULD have a mechanism to announce that the private signature key has been compromised before the end of its validity period. This gives the group members the ability to examine/audit recently received datagrams and detect those that might be forgeries and potentially disregard them. Unlike a group traffic encryption key, the signature is a legal instrument that has this additional responsibility (even if this working group is uncomfortable with that status). 5. The group key managment protocol's management interface MUST have the ability to specify RSA key lengths ranging from 496 bits through 2048 bits. Note that the current IPsec RSA signature text in section 5 places no "MUST implement" obligation on the implementations to expose this parameter to be configurable. 6. The public key MAY be the public key from an X.509 end entity signature public key certficate. When it is this type of public key, then the group members MUST implement X.509 certificate validation in compliance with the cryptographic group's policies. > > I have not specified how it would work outside of the group key > management case, because of the NOT RECOMMEND guidance (to which you > object in ISSUE 4). > > I see that Section 5 of the document needs to be clearer with respect to > the handing of the public key. If you could please include language similar to what I've outlined above, then that would go a long way towards closing this issue. > > >ISSUE 3: Ephermeral RSA key pairs creates a tough key management problem. > >I realize it is too heavyweight to require that there be a RFC3280 > >compliant certificate created for each ephermeral RSA key pair. OTOH, I > >think we have the obligation to say how do we handle: > > > > - key revocation in the event of private key compromise? > > > > > > > This is no more an issue than if an AES key was compromised. Deletion of > the IPsec SA would be the mechanism. I see digital signature compromise as having additional responsibility. At the least, the key management protocol SHOULD have a mechanism to alert the signature verifiers of the compromise. As a matter of policy, you would not choose to use signatures with their computational overhead unless the signatures have additional importance (i.e. legal, economic, or system control). So compromise makes recent signature suspect. What one does after receiving that alert is application policy specific. > > > - verify the validity period for the public key's lifetime? > > > > - thwart an active attacker that partitions the group during > > the transition between public keys. May be an unlikely case, > > but if the attacker withheld the "new public key" announcement from > > the group long enough, the attacker could crack the signature > > private key and then forge packet signatures to the sub-group > > under the attacker's control. > > > > - the public key's validation to a trust anchor when it is a > > traditional X.509 signature certificate key pair rather than > > an ephermeral key pair? I'm assuming you may use your X.509 > > EE signature cert, this is not prohibited, right? > > > > > > > The above three issues assume the presence of a certificate. Without a > certificate, there is no issue. I respectfully disagree, these are real key management issues, and it is within scope of this draft to prescribe how they are managed. See above for specifics. > > > If a PKI was needed, I would definitely refer to PKIX document. My goal > is to be so simple as to not require any sort of certificate > infrastructure, just bare public keys distributed on a per-SA basis. Your basic premise is sound, but the draft still must specify the key management requirements as stated above. Granted, it is simpler than PKIX, but I am saying that there is a checklist that group key management protocol implementors MUST satisfy to use IPsec RSA signature securely. hth, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 11:34:16 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14298 for ; Wed, 18 Aug 2004 11:34:16 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3EDA18D2F7; Wed, 18 Aug 2004 11:33: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 D97418D2EB for ; Wed, 18 Aug 2004 11:33:46 -0400 (EDT) Received: (qmail 18141 invoked by uid 3269); 18 Aug 2004 15:33:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18138 invoked from network); 18 Aug 2004 15:33:46 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 18 Aug 2004 15:33:46 -0000 Received: (qmail 96139 invoked from network); 18 Aug 2004 11:33:45 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 18 Aug 2004 11:33:45 -0400 Received: (qmail 79447 invoked from network); 18 Aug 2004 11:33:45 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 18 Aug 2004 11:33:45 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7ID3OP07605; Wed, 18 Aug 2004 09:03:24 -0400 Date: Wed, 18 Aug 2004 09:03:24 -0400 (EDT) From: George Gross To: canetti Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Brian Weis , 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 Hi Ran, On Wed, 18 Aug 2004, canetti wrote: > > Brian, I totally agree with your approach. > There should probably be some text in the I-D explaining this. > > A couple remarks: > > * We use RSA signatures for authentication. The fact that they might be > used also for non-repudiability is not a concern of this I-D. Thus, we do > not need to carry certificates around. Making sure that both parties have > the correct verification keys in their respective SAs is the job of the > key management protocol. okay. > > * Digital signatures do not necessarily provide non-repudiation, > regardless of the length of the keys. In order to provide non-repudiation, > the public key of the signature should be appropriately certified. > In fact, if the public key to be used in the session is never > explicitly signed by the parties during the key exchange, then signing > packets with the corresponding secert key provides full repudiability > (while still providing perfectly good authentication). Perhaps you mispoke, but in my mind an uncertified public key provides no authentication. Are you suggesting pre-placed RSA public keys to avoid a TTP signature on the public key? Even if we avoid X.509 or PGP certificates, the key management protocol still uses some method to "certify" the public key. As noted in a parallel e-mail from me, RFC2408 section 3.12 Signature payload explicitly says that the signature may be used in non-repudiation services. Consider the implications for GDOI distributing the RSA public key as signed data under the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature certifies the RSA public key and consequently we get both authentication and non-repudiation service, not just authentication. Of course, the caveat is that YMMV wrt/ non-repudiation in the legal sense. In any case, my real issue is that the IPsec RSA signature draft specify the simple set of key management requirements that MUST be implemented to assure the secure use of a RSA public key that is not certified using traditional PKI. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 13:51:21 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25379 for ; Wed, 18 Aug 2004 13:51:11 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E6C7A8CCFE; Wed, 18 Aug 2004 13:50:55 -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 A511D8CCDF for ; Wed, 18 Aug 2004 13:50:54 -0400 (EDT) Received: (qmail 46774 invoked by uid 3269); 18 Aug 2004 17:50:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46771 invoked from network); 18 Aug 2004 17:50:54 -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; 18 Aug 2004 17:50:54 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2004 10:54:36 -0700 Received: from cisco.com (dhcp-128-107-178-179.cisco.com [128.107.178.179]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7IHoopX015876; Wed, 18 Aug 2004 10:50:51 -0700 (PDT) Message-ID: <41239869.90608@cisco.com> Date: Wed, 18 Aug 2004 10:56:57 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: canetti , 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 Hi George, George Gross wrote: >Hi Ran, > >On Wed, 18 Aug 2004, canetti wrote: > > >>* Digital signatures do not necessarily provide non-repudiation, >>regardless of the length of the keys. In order to provide non-repudiation, >>the public key of the signature should be appropriately certified. >>In fact, if the public key to be used in the session is never >>explicitly signed by the parties during the key exchange, then signing >>packets with the corresponding secert key provides full repudiability >>(while still providing perfectly good authentication). >> >> > >Perhaps you mispoke, but in my mind an uncertified public key provides no >authentication. Are you suggesting pre-placed RSA public keys to avoid a >TTP signature on the public key? > > > Pre-placed manually-entered RSA public keys would indeed be another key management alternative. I don't think it's a particularly good idea, but someone could do it. Recall that the RSA Signatures draft lives within the the RFC 2401 framework. In order for any IPsec implementation to be in compliance with RFC 2401 they are required to support manual keyed SAs. See Section 4.6 (as well as other sections) of RFC 2401. This is an artifact of writing a draft that fits into the IPsec framework, which is the sole goal of this document. >Even if we avoid X.509 or PGP certificates, the key management protocol >still uses some method to "certify" the public key. As noted in a parallel >e-mail from me, RFC2408 section 3.12 Signature payload explicitly says >that the signature may be used in non-repudiation services. Consider the >implications for GDOI distributing the RSA public key as signed data under >the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature >certifies the RSA public key and consequently we get both authentication >and non-repudiation service, not just authentication. Of course, the >caveat is that YMMV wrt/ non-repudiation in the legal sense. > > > Most usages of the word "certification" in the PKI world that I've observed describe this as a specific claim that a public key belongs to an identity, and the vehicle used to prove that claim is a public key signature. In your example, the ISAKMP/GDOI signature doesn't make any particular claim of validity of that public key, it just signs it as data, with the purpose of authenticating the entity sending the data. I really don't see where the non-repudiation comes in. Thank you for pointing out that ISAKMP mentions non-repudiation. But "may" does not mean "it could possible be, so you'd better assume that it is". Brian >In any case, my real issue is that the IPsec RSA signature draft specify >the simple set of key management requirements that MUST be implemented to >assure the secure use of a RSA public key that is not certified using >traditional PKI. > >br, > > George > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 14:44:14 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28356 for ; Wed, 18 Aug 2004 14:44:04 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EFDA58CC7E; Wed, 18 Aug 2004 14:44:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BFFB08CC3C for ; Wed, 18 Aug 2004 14:44:03 -0400 (EDT) Received: (qmail 58573 invoked by uid 3269); 18 Aug 2004 18:44:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58570 invoked from network); 18 Aug 2004 18:44:03 -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; 18 Aug 2004 18:44:03 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2004 11:47:46 -0700 Received: from cisco.com (dhcp-128-107-178-179.cisco.com [128.107.178.179]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7IIhxR2005983; Wed, 18 Aug 2004 11:43:59 -0700 (PDT) Message-ID: <4123A4DA.6030602@cisco.com> Date: Wed, 18 Aug 2004 11:50:02 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] comments on IPSEC RSA signature draft References: 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 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 George, Lets level set. What are these public keys being used for? They have one purpose in life: To validate an Integrity Check Value (ICV) placed in an IPsec encapsulated data packet. The goal of any ICV validation is to ensure that the packet came from a valid sender. In the case of group traffic, a receiver sometimes whats to know that the packet came from "the valid sender" rather than "a valid sender". In that case, they want the ICV validation to additionally provide Source Origin Authentication. But they still just want to ensure that "the valid sender" created an IPsec encapsulation. Once an ICV is verified, the ICV value (e.g., signature) is discarded, as it serves no further purpose. When the IPsec SA expires, then the mapping of any particular key used to validate the ICV (e.g., the public key) is also discarded. There is not explicit traceability, any more than there is any explicit traceability of which secret key was used for the SA. The receiver expects nothing more from a digital signature based ICV than an HMAC in this respect. This is a novel use of digital signatures, and this simplicity is non-intuitive and easy to forget. But the simplicity of purpose also frees us from many of the concerns of digital signatures: requirements for certificates, concerns of non-repudiation, etc. This is why I object to adding more requirements on these public keys to the draft. I will agree that there are some key management issues which have not been specified. (Atul pointed this out too.) But they belong in a key management document. For example, GDOI needs some updates to support this: it needs an addition in its namespace in the KD payload. It also could also describe some of the things you mention below, such as if there is a known lifetime for the key (e.g., from a certificate), that is must not use that key beyond the lifetime in the certificate. But these firmly belong in the key management draft, not in the IPsec transform draft describing how the RSA algorithm is applied to an ICV. Thanks, Brian George Gross wrote: >Hi Brian, > >I hate to belabor this thread, but some things are still dangling... > >On Tue, 17 Aug 2004, Brian Weis wrote: > > > >>Hi George, >> >>Thanks for your detailed comments. Replied are inline below. >> >>George Gross wrote: >> >> >> >>>Hi Brien, >>> >>> Generally this draft is in good shape, and I'm glad to see it >>>moving forward. I'm still working through how I would implement this >>>draft, and that process may uncover additional topics for discussion. In >>>the meantime, here's what I found on my first read: >>> >>>ISSUE 1: In the ESP/AH RSA signatures draft section 2, there is paragraph >>>that begins with the sentence: >>> >>> "Ephemeral RSA key pairs generated for use during the lifetime of an >>> SA may be generated." >>> >>> >>> >>> >>> >>There is a slight typo in this original text, for which I apologize. It >>did not mean to imply that *multiple keypairs* would be used during the >>life of a single SA. Rather, a key pair may be generated for the express >>use of an SA. But that's just a recommendation. The keypair could be a >>long term keypair. But if so, I do not assume the need for a >>certificate. (This is discussed later in these comments.) >> >> >> >>>I think I understand what this above sentence intends, but it is written >>>in passive voice and it leaves some important things unsaid. As a >>>clarification, how about replacing it with the following text: >>> >>>"The signing party MAY generate multiple ephemeral RSA key pairs during >>>the SA lifetime. The public key's distribution mechanism and its >>>replacement interval are a local policy matter. The SA key management >>>protocol MUST provide a certification mechanism for the ephemeral RSA >>>public key that complies with the profile in section 5.X. The signature >>>verifiers MUST use that certification mechanism to assure that they use >>>only an authentic and currently valid signature public key." >>> >>>The new sub-section 5.X would be entitled "Public Key Certification >>>Mechanism Requirements" or something like that. See ISSUE 3 below. >>> >>> >>> >>> >>> >>I like the idea of "The public key's distribution mechanism and its >>replacement interval are a local policy matter." But your text >>additionally brings in some new concepts that I'm not quite ready to >>embrace. I do not believe that a certification mechanism is required. >>Section 5 lists the mechanism that should be used for specifying the >>public key, which is to deliver it during group key management. Since >>this is a per-SA attribute, it gets deleted when the SA expires, and the >>receiver need pay it no more mind. >> >> > >The IPsec RSA signature draft is under specified for its requirements on >the group key management protocol, which is taking on the responsibility >as the "public key certification" mechanism. I would like to see the >draft's section 5 require that the group key management protocol specify >the following things about the public key: > >1. In the case where the Group Speaker generates its own public/private >key pair, the group key management protocol MUST include a proof of >possession of the signature private key exchange between the GC/KS and the >Group Speaker. > >2. The public key MUST be delivered to the group membership by the group >key management protocol using an authenticated certification mechanism. >For example, in GDOI this certification is the inclusion of the public key >as signed data under the ISAKMP Signature payload [RFC2408 section 3.12] >signed by a trusted GC/KS. > >Incidently, the RFC2408 text in section 3.12 *explicitly* says that the >ISAKMP signature payload can be used in non-repudiation services. So the >IPsec RSA signature public key is implicitly a certified key that can >also offer non-repudiation services ;o) > >3. The public key's validity period is the same as the SA lifetime, and >there MUST be an accurate mechanism for all of the group members to detect >when the public key has expired. When the validity period expires, any >signature using that public key must be ignored, the packet discarded, and >the SA deleted. > >4. The group key management protocol SHOULD have a mechanism to announce >that the private signature key has been compromised before the end of its >validity period. This gives the group members the ability to >examine/audit recently received datagrams and detect those that might be >forgeries and potentially disregard them. Unlike a group traffic >encryption key, the signature is a legal instrument that has this >additional responsibility (even if this working group is uncomfortable >with that status). > >5. The group key managment protocol's management interface MUST have the >ability to specify RSA key lengths ranging from 496 bits through 2048 >bits. Note that the current IPsec RSA signature text in section 5 places >no "MUST implement" obligation on the implementations to expose this >parameter to be configurable. > >6. The public key MAY be the public key from an X.509 end entity signature >public key certficate. When it is this type of public key, then the group >members MUST implement X.509 certificate validation in compliance with the >cryptographic group's policies. > > > > > >>I have not specified how it would work outside of the group key >>management case, because of the NOT RECOMMEND guidance (to which you >>object in ISSUE 4). >> >>I see that Section 5 of the document needs to be clearer with respect to >>the handing of the public key. >> >> > >If you could please include language similar to what I've outlined above, >then that would go a long way towards closing this issue. > > > > >>>ISSUE 3: Ephermeral RSA key pairs creates a tough key management problem. >>>I realize it is too heavyweight to require that there be a RFC3280 >>>compliant certificate created for each ephermeral RSA key pair. OTOH, I >>>think we have the obligation to say how do we handle: >>> >>>- key revocation in the event of private key compromise? >>> >>> >>> >>> >>> >>This is no more an issue than if an AES key was compromised. Deletion of >>the IPsec SA would be the mechanism. >> >> > >I see digital signature compromise as having additional responsibility. At >the least, the key management protocol SHOULD have a mechanism to alert >the signature verifiers of the compromise. As a matter of policy, you >would not choose to use signatures with their computational overhead >unless the signatures have additional importance (i.e. legal, economic, or >system control). So compromise makes recent signature suspect. What one >does after receiving that alert is application policy specific. > > > >>>- verify the validity period for the public key's lifetime? >>> >>>- thwart an active attacker that partitions the group during >>> the transition between public keys. May be an unlikely case, >>> but if the attacker withheld the "new public key" announcement from >>> the group long enough, the attacker could crack the signature >>> private key and then forge packet signatures to the sub-group >>> under the attacker's control. >>> >>>- the public key's validation to a trust anchor when it is a >>> traditional X.509 signature certificate key pair rather than >>> an ephermeral key pair? I'm assuming you may use your X.509 >>> EE signature cert, this is not prohibited, right? >>> >>> >>> >>> >>> >>The above three issues assume the presence of a certificate. Without a >>certificate, there is no issue. >> >> > >I respectfully disagree, these are real key management issues, and it is >within scope of this draft to prescribe how they are managed. See above >for specifics. > > > > >>If a PKI was needed, I would definitely refer to PKIX document. My goal >>is to be so simple as to not require any sort of certificate >>infrastructure, just bare public keys distributed on a per-SA basis. >> >> > >Your basic premise is sound, but the draft still must specify the key >management requirements as stated above. Granted, it is simpler than PKIX, >but I am saying that there is a checklist that group key management >protocol implementors MUST satisfy to use IPsec RSA signature securely. > >hth, > George > > > > > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 14:47:28 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28607 for ; Wed, 18 Aug 2004 14:47:17 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9AC348CC7E; Wed, 18 Aug 2004 14:47:18 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 0620F8CC34 for ; Wed, 18 Aug 2004 14:47:17 -0400 (EDT) Received: (qmail 59026 invoked by uid 3269); 18 Aug 2004 18:47:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59023 invoked from network); 18 Aug 2004 18:47:16 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 18 Aug 2004 18:47:16 -0000 Received: (qmail 94499 invoked from network); 18 Aug 2004 18:47:12 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 18 Aug 2004 18:47:12 -0000 Received: (qmail 2275 invoked from network); 18 Aug 2004 14:47:12 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 18 Aug 2004 14:47:12 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7IGGov08777; Wed, 18 Aug 2004 12:16:50 -0400 Date: Wed, 18 Aug 2004 12:16:50 -0400 (EDT) From: George Gross To: Brian Weis Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues In-Reply-To: <41239869.90608@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , canetti , 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 Hi Brian, On Wed, 18 Aug 2004, Brian Weis wrote: > Hi George, > > George Gross wrote: > > >Hi Ran, > > > >On Wed, 18 Aug 2004, canetti wrote: > > > > > >>* Digital signatures do not necessarily provide non-repudiation, > >>regardless of the length of the keys. In order to provide non-repudiation, > >>the public key of the signature should be appropriately certified. > >>In fact, if the public key to be used in the session is never > >>explicitly signed by the parties during the key exchange, then signing > >>packets with the corresponding secert key provides full repudiability > >>(while still providing perfectly good authentication). > >> > >> > > > >Perhaps you mispoke, but in my mind an uncertified public key provides no > >authentication. Are you suggesting pre-placed RSA public keys to avoid a > >TTP signature on the public key? > > > > > Pre-placed manually-entered RSA public keys would indeed be another key > management alternative. I don't think it's a particularly good idea, but > someone could do it. Recall that the RSA Signatures draft lives within > the the RFC 2401 framework. In order for any IPsec implementation to be > in compliance with RFC 2401 they are required to support manual keyed > SAs. See Section 4.6 (as well as other sections) of RFC 2401. > > This is an artifact of writing a draft that fits into the IPsec > framework, which is the sole goal of this document. I recognize that preplaced public keys are an alternative, but in the context of this thread they are not part of the main usage case. > > >Even if we avoid X.509 or PGP certificates, the key management protocol > >still uses some method to "certify" the public key. As noted in a parallel > >e-mail from me, RFC2408 section 3.12 Signature payload explicitly says > >that the signature may be used in non-repudiation services. Consider the > >implications for GDOI distributing the RSA public key as signed data under > >the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature > >certifies the RSA public key and consequently we get both authentication > >and non-repudiation service, not just authentication. Of course, the > >caveat is that YMMV wrt/ non-repudiation in the legal sense. > > > > > > > Most usages of the word "certification" in the PKI world that I've > observed describe this as a specific claim that a public key belongs to > an identity, and the vehicle used to prove that claim is a public key > signature. Clearly, we are dealing with certification outside of traditional PKI standards, but it is certification of the public key to a particular identity none the less. Otherwise, MITM attacks make the public key useless for source authentication. > In your example, the ISAKMP/GDOI signature doesn't make any > particular claim of validity of that public key, it just signs it as > data, I do not think so. ISAKMP is not signing just any data here. It is putting the RSA signature public key within the Signature payload's signature scope. This is tantamount to asserting "I certify that this RSA public key is authentic for the SA Group Speaker", along with the other SA keying material and attributes. If the GC/KS does not vouch for the Group Speaker identity represented by the public key, then that key's signature is useless for authentication. In effect, the GC/KS becomes a CA. > with the purpose of authenticating the entity sending the data. I > really don't see where the non-repudiation comes in. As I've explained on other occasions in this thread, much as we may want to disassociate the RSA signature from non-repudiation, the legal community gets to say otherwise. In this context, a chain of trust exists for the public key that could be used not only for authentication but also for non-repudiation services. The chain of trust spans the certificate path from root CA to the GC/KS and then from there the GC/KS signature of the Group Speaker public key. We can tip-toe past this by not saying anything in the draft (unlike RFC2408), but the non-repudiation side effect is there none the less. It is inherent to a digital signature with a chain of trust. > > Thank you for pointing out that ISAKMP mentions non-repudiation. But > "may" does not mean "it could possible be, so you'd better assume that > it is". I am sorry, but I do not understand what you were saying here, perhaps you could rephrase it? could you please explain why you are reluctant to acknowledge the presence of the non-repudiation side effect in the draft? > Brian > > >In any case, my real issue is that the IPsec RSA signature draft specify > >the simple set of key management requirements that MUST be implemented to > >assure the secure use of a RSA public key that is not certified using > >traditional PKI. Handling the non-repudiation issue is secondary; adding the key management requirements will strengthen the IPsec RSA signature spec considerably.... thx, George > > > >br, > > > > George > > > > > >_______________________________________________ > >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 Aug 18 16:04:05 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06893 for ; Wed, 18 Aug 2004 16:03:45 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F3FC38CA0C; Wed, 18 Aug 2004 16:03: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 52E4A8C976 for ; Wed, 18 Aug 2004 16:03:05 -0400 (EDT) Received: (qmail 75129 invoked by uid 3269); 18 Aug 2004 20:03:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75126 invoked from network); 18 Aug 2004 20:03:05 -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; 18 Aug 2004 20:03:05 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2004 13:06:48 -0700 Received: from cisco.com (dhcp-128-107-178-179.cisco.com [128.107.178.179]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7IJ2lU4011195; Wed, 18 Aug 2004 12:02:57 -0700 (PDT) Message-ID: <4123B754.4060306@cisco.com> Date: Wed, 18 Aug 2004 13:08:52 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: canetti , 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 Hi George, >>Thank you for pointing out that ISAKMP mentions non-repudiation. But >>"may" does not mean "it could possible be, so you'd better assume that >>it is". >> >> > >I am sorry, but I do not understand what you were saying here, perhaps you >could rephrase it? > > > Sorry for the confusion. I was trying to make the point that when RFC 2408 says "may", it is simply acknowledging that in some uses, the signature payload type could be used for non-repudiation purposes. But RFC 2408 simply defines a payload type. It cannot know the usage context of a signature payload, and thus can't make a statement on whether there is or is not non-repudiation for a particular usage. >could you please explain why you are reluctant to acknowledge the presence >of the non-repudiation side effect in the draft? > > > Because I do not agree that there is a non-repudiation side affect to using public keys as an ICV on an IPsec data packet. I'm afraid we're just going to have to disagree on this point. Thanks, Brian >>Brian >> >> >> >>>In any case, my real issue is that the IPsec RSA signature draft specify >>>the simple set of key management requirements that MUST be implemented to >>>assure the secure use of a RSA public key that is not certified using >>>traditional PKI. >>> >>> > >Handling the non-repudiation issue is secondary; adding the key management >requirements will strengthen the IPsec RSA signature spec considerably.... > >thx, > George > > > >>>br, >>> >>> George >>> >>> >>>_______________________________________________ >>>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 > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 18 16:37:35 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12771 for ; Wed, 18 Aug 2004 16:37:25 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C55FE8CC6A; Wed, 18 Aug 2004 16:37: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 9E1DE8C9AD for ; Wed, 18 Aug 2004 16:37:25 -0400 (EDT) Received: (qmail 81647 invoked by uid 3269); 18 Aug 2004 20:37:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81644 invoked from network); 18 Aug 2004 20:37:25 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 18 Aug 2004 20:37:25 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 18 Aug 2004 13:38:21 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn3-361.cisco.com [10.21.65.105]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7IKbJWj007554; Wed, 18 Aug 2004 13:37:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <605C7444-F156-11D8-B6B1-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Wed, 18 Aug 2004 13:37:09 -0700 To: acc@sparta.com, hh@sparta.com X-Mailer: Apple Mail (2.619) Cc: "Elisabetta Carrara (KI/EAB)" , msec@securemulticast.org Subject: [MSEC] http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-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: 7bit Andrea, Hugh Hugh asked me to take a look at the SRTP bindings in http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec -00.txt. These need to be consistent with RFC 3711, specifically page 36, and I think that they mostly are. I am using http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions -07.txt, pp. 11-18, to jog my memory. The policy token bindings for SRTP are missing the session parameters from http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions -07.txt, page 16. RTP has an RTCP feed-back channel and SRTCP can be configured to be encrypted or not. sdescriptions includes this parameter. So does p. 36 of RFC 3711 but it's not obvious that SRTP and SRTCP each have their own pair of transform definitions. Thus it's possible to use NULL encryption for SRTCP while use AES-CM or f8 for SRTP. What we have not supported in either sdescriptions, or MIKEY I think, is setting a different authentication or encryption algorithm for SRTCP and SRTP - beyond allowing NULL encryption for SRTCP. Also, authentication is not optional for SRTCP, but only for SRTP - and then it is NOT RECOMMENDED for anything but voice. So the authentication can't be OPTIONAL in the SRTCP case at least. Regarding From/To and MKI, there are two things that need to be conveyed. The first is a boolean that indicates whether either one are used for the session (as you note in the I-D, one can't use both). The second item is the length of the MKI when the MKI is used. Finally, there is FEC, which is specified for RTP and supported in SRTP. We have including three FEC orderings. I think more needs to be said about FEC and SRTP that is not covered in RFC 3711. But for our purposes, I think if you stick to the definitions inn RFC 3711, the policy token will at least be consistent. Mark _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 19 00:14:28 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14990 for ; Thu, 19 Aug 2004 00:14:25 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7BF3B8CB87; Thu, 19 Aug 2004 00:14:27 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id AD78A8C736 for ; Thu, 19 Aug 2004 00:14:25 -0400 (EDT) Received: (qmail 82190 invoked by uid 3269); 19 Aug 2004 04:14:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82187 invoked from network); 19 Aug 2004 04:14:25 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 19 Aug 2004 04:14:25 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i7J4B6c102188; Thu, 19 Aug 2004 00:11:07 -0400 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7J4D4n50956; Thu, 19 Aug 2004 00:13:04 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i7J4D2D31306; Thu, 19 Aug 2004 00:13:03 -0400 Date: Thu, 19 Aug 2004 00:13:02 -0400 (EDT) From: canetti To: George Gross Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Brian Weis , 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 George, On Wed, 18 Aug 2004, George Gross wrote: ... > > * Digital signatures do not necessarily provide non-repudiation, > > regardless of the length of the keys. In order to provide non-repudiation, > > the public key of the signature should be appropriately certified. > > In fact, if the public key to be used in the session is never > > explicitly signed by the parties during the key exchange, then signing > > packets with the corresponding secert key provides full repudiability > > (while still providing perfectly good authentication). > > Perhaps you mispoke, but in my mind an uncertified public key provides no > authentication. Are you suggesting pre-placed RSA public keys to avoid a > TTP signature on the public key? > > Even if we avoid X.509 or PGP certificates, the key management protocol > still uses some method to "certify" the public key. As noted in a parallel > e-mail from me, RFC2408 section 3.12 Signature payload explicitly says > that the signature may be used in non-repudiation services. Consider the > implications for GDOI distributing the RSA public key as signed data under > the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature > certifies the RSA public key and consequently we get both authentication > and non-repudiation service, not just authentication. Of course, the > caveat is that YMMV wrt/ non-repudiation in the legal sense. There is a difference between an "uncertified" public key and an "unauthenticated" one. For instance, if you and I already share an authenticated channel, and you send to me a public key on this channel, then I know that this key comes from you - thus i can use if for further authentication. But I cannot prove to a third party, that the key came from you - since you never certified it. (in other words, as far as the third party is concerned, i could have generated this public key myself and am falsely claiming that it came from you.) Now, It is up to the key management algorithm whether to sign the RSA public key to be used in ESP-RSA, or to authenticate it without signing (eg, by MACing it using a key derived fom the session key). It is indeed interesting to look at existing key management protocols and see whether they explicitly sign the SA exchange, or do they just MAC the SA exchange. But, I must say that this concern of "involuntary non-repudiation" seems like a secondary issue to me - I find it hard to believed that IP leyer packet signatures, that are not managed directly by any application or user, can be really used in court to prove non-repudiation. > > In any case, my real issue is that the IPsec RSA signature draft specify > the simple set of key management requirements that MUST be implemented to > assure the secure use of a RSA public key that is not certified using > traditional PKI. I'm not sure what you refer to. The ESP-RSA key will be simply sent to the group member by the GCKS, together with the rest of the SA information for that session. no? Best, Ran > > br, > > George > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 19 03:37:17 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09053 for ; Thu, 19 Aug 2004 03:37:17 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4ACF48C96B; Thu, 19 Aug 2004 03:37: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 1C39E8C946 for ; Thu, 19 Aug 2004 03:37:16 -0400 (EDT) Received: (qmail 40836 invoked by uid 3269); 19 Aug 2004 07:37:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40830 invoked from network); 19 Aug 2004 07:37:13 -0000 Received: from saturn.bt.com (HELO cbibipnt08.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 19 Aug 2004 07:37:13 -0000 Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id QWJ83XY1; Thu, 19 Aug 2004 08:37:17 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1092901036255; Thu, 19 Aug 2004 08:37:16 +0100 Received: from maat.jungle.bt.co.uk ([132.146.136.69]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i7J7ax7S027973; Thu, 19 Aug 2004 08:37:00 +0100 Message-Id: <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 19 Aug 2004 08:31:34 +0100 To: Mark Baugher , elisabetta.carrara@ericsson.com From: Bob Briscoe In-Reply-To: <200407211949.PAA17902@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org Subject: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Mark, Elisabetta, Thanks for the new SRTP-TESLA I-D draft 01. Below is a thorough review. I'm afraid these comments would have been more useful after draft 00. But I've moved on from group security, so I don't follow the list closely. My original motivation back in 1999 behind thinking up what became known as TESLA (in parallel with the co-authors of the TESLA intro) was to authenticate multicast RTP, so I hope you will find the suggested improvements below useful. Essentially, the goal with SRTP is to keep the packet size as low as possible. Although this is a bandwidth concern (as mentioned in your section 6), it is more a latency concern for many real-time applications, particularly interactive voice (conferencing) and to a lesser extent interactive video (conferencing). I explain below how you can trade-off sender memory/processing for smaller packet size. In this way, we can also do stronger immediate authentication than you have (against DoS) while keeping equally strong delayed authentication, but completely removing the need for 3 of your 4 byte headers per pkt. = 12 bytes less overhead out of your 38 bytes. As you say, implementations can also choose to do heavier truncation of the MAC etc, to get further overhead savings. I also explain below how we might even achieve interactive-quality latency in parallel to delayed authentication, rather than in series. The improved immediate authentication makes this feasible. I can send you a tech report I started in 1999, with RTP uppermost in my mind as an application. I'm afraid it's unfinished and therefore unpublished. But the body is finished - I just never got round to topping and tailing it. It gives the rationale and protocol details behind all the points below, plus other stuff like how I would envisage extensions to SDP for sending session security parameters for TESLA. Just ask if you want a copy (PDF, 19pp including 9 figures). If you believe some of the points below impact on the TESLA intro rather than SRTP-TESLA, say now. However, we have tried to accommodate all these possibilities in draft-ietf-msec-tesla-intro-03.txt just published. However, until re-reading my own report just now, I had forgotten how I had done stronger immediate authentication (point 3/ below)! 1/ Key index field is redundant with SRTP ---------------------------------------- The key index can be derived from the RTP timestamp in each message. This saves 4 bytes in each packet. If the sender buffers packets between adding the RTP timestamp and adding TESLA authentication fields, this will add to the TESLA authentication delay. But a good RTP implementation shouldn't be doing serious buffering here. 2/ Non-TESLA group authentication to protect against DoS should be optional --------------------------------------------------------------------------- The immediate authentication provided by your non-TESLA group authentication only protects against DoS by non-group members. It should be RECOMMENDED not REQUIRED (section 7). Two reasons: i) Imagine an Internet TV application, with millions of viewers. It would be silly to MANDATE the non-TESLA group authentication fields in such a scenario. An attacker isn't going to be prevented from mounting a DoS attack by being excluded from the group. Such large, publicly accessible groups are too easy to join for group authentication to make sense. ii) If there is no history of DoS attacks on a particular group, it is silly to add this overhead to every packet to protect against a threat of which there is no risk. Below, anyway, I show another way to do immediate authentication without these group authentication fields, and it's stronger. 3/ Non-TESLA group authentication to protect against DoS is redundant --------------------------------------------------------------------- If the time interval for switching to a new key is set to be the same as that for each RTP packet, the disclosed key allows an immediate rather than delayed test that affords good enough protection against DoS on its own (irrespective of whether attackers are within or outside the group). TESLA delayed authentication is still necessary to protect against attackers with some control over the network. But you get immediate 'network-dependent' authentication. I use this term to mean authentication dependent on the integrity of the network, but still protecting against malicious behaviour of end systems. Each time a packet arrives at a receiver, it will now contain a new disclosed key. An immediate check can be made as to whether: - this key has already been seen (in which case all later packets with duplicate keys are considered fake and ignored) - this new key fits into the key chain. The tech report gives a more exact definition of the tests. The only way an attacker can get hold of the next key in the chain is to receive the next authentic packet. It then has to extract the key and use it to create its own fake packet, then overtake the original packet's arrival at some or all the other receivers. This might be done in the following ways: - request better latency service (even then, receiving, processing, re-transmitting and overtaking the original packet is very hard) - use a parallel network (ditto) - watch for negative acks, and send retransmissions only to those receivers affected - conspire with a network provider, or take over a network node to delay or remove the original packets from the remainder of the multicast tree I believe this 'network-dependent' authentication, where all the above uses and abuses of the network are infeasible, is sufficient to protect against most DoS attacks. Indeed, it gives better protection against DoS than the group authentication MAC you use. Changing the key each packet requires more memory or processing at the sender. But the complexity only rises O(log(r)) where r is the key change rate, so this isn't a big hit. See refs [21, 22] in the TESLA intro draft for efficient hash traversal algorithms. BTW, this immediate authentication isn't novel. It is the basic S/KEY protocol that has been used for years (IETF RFC1760 based on Lamport). 4/ No need to include the key index, i, in the TESLA authenticated portion -------------------------------------------------------------------------- [If you accept my argument in 1/ that the key index is unnecessary, my point here is irrelevant.] The key index determines the operation of the verification algorithm - viz. which key to use to create a MAC to compare with the TESLA MAC field. There is no point in including this key index within the coverage of the TESLA MAC (end of section 4.2, section 4.5 & 4.6). If the key index is altered, the verification will fail, whether or not the key index is covered by the MAC. It doesn't really matter either way. It's just contrary to what the TESLA intro specifies, and therefore liable to lead to confused standardistion of implementations. BTW, it should be pointed out that the verification algo should check the key index is within an expected range before using it (e.g. only a small increment above the last highest verified key index seen). Otherwise, an attacker can tamper with this field to lead all receivers to run millions of hash operations unnecessarily. I prefer to call it a key-index *hint*, to remind me not to rely on it being correct. 5/ Discard if a packet cannot be authenticated should be optional ----------------------------------------------------------------- It is wrong to say a packet MUST be discarded if a safe condition does not hold (section 4.4 & 4.4.2). We have changed the lastest TESLA intro I-D to clarify this point. It is one thing for verification to fail. It is another for the verification test to not be possible (e.g. due to excessive delay). In the latter case, it should be application-dependent whether the packet is discarded. Instead, we have introduced the term "considered unauthenticated" for such packets. There might be an internal API between the verifier and the application to flag when packets are considered unauthenticated, rather than dropping them (a fairly dumb implicit API). An explicit API is likely to be preferred, to distinguish network loss from potential attacks. For instance, if there has been no history of verification failure, and the odd packet arrives too late to be verified safely, an application should be within its rights to assume the *probability* of such packets being authentic is high. Also, part of the application might involve analysing the cause of attacks. It would be wrong to mandate discard, thus removing the evidence such applications need. 6/ Play-out may be in parallel to buffering awaiting authentication ------------------------------------------------------------------- In the note at the end of section 4.4.2, you say decryption can be done optimistically before TESLA verification. I would ask you to add that some delay sensitive applications might even play-out the packets optimistically before TESLA verification (still buffering the packets in parallel). If TESLA verification subsequently fails, then roll-back would have to be achieved at the user interface level. We have given an example in the new TESLA intro. 7/ TESLA tail piece section required ------------------------------------ Perhaps after the TESLA bootstrapping section, a new section is required to explain the implications on SRTP of disclosing the remaining keys after all RTP data has finished. Nits ==== A general point of style: I found the spec had too much 'knitting together by reference' from other specs. As Ran said in an earlier posting, it needs at least some sketching of what is referred to. Otherwise it is unlikely to lead to safe standardisation of implementations. Particularly given that the references themselves are evolving, it becomes unsafe to expect people to find discrepancies when reviewing this draft by re-reading the latest drafts of the other specs each time. Sections 4.4. & 4.4.1 were particular culprits. However, I also have some sympathy with the view that duplication of parts of specs in other specs can lead to inconsistency. Throughout: To be consistent with the TESLA intro, the time-slot index, I, should be i (lower case). Sec 2. "...may often used..." --> "...may often be used..." Sec 3. "This specification assumes that the reader is familiar with TESLA" repeats the same sentence in Sec 1.1. Sec 3. TESLA synch protocol & initial bootstrapping outside scope, but presumably you will include a ref once one is available. Sec 4. "...and the delayed-authentication TESLA elements of procedure [TESLA]." Garbled sentence? Sec 4.1 "showed" --> "shown" Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." Sec 4.4 "If the safe condition does not hold,..." add "...and the event SHOULD be logged." Sec 5. TESLA doesn't assume local clocks don't drift too much. Rather it requires a bound on clock drift to be known. Sec 7. "...an in the TESLA specification..." --> "...and in the TESLA specification..." Sec 7. "...noted that the all TESLA security..." sentence garbled. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 19 11:27:58 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09793 for ; Thu, 19 Aug 2004 11:27:57 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 621E28C6F5; Thu, 19 Aug 2004 11:27: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 F011F8C286 for ; Thu, 19 Aug 2004 11:27:55 -0400 (EDT) Received: (qmail 24632 invoked by uid 3269); 19 Aug 2004 15:27:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24629 invoked from network); 19 Aug 2004 15:27:55 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 19 Aug 2004 15:27:55 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7JFRpg14870; Thu, 19 Aug 2004 11:27:51 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PPXP29XX; Thu, 19 Aug 2004 11:27:50 -0400 Received: from [47.16.67.20] (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QVY9ZKHA; Thu, 19 Aug 2004 11:27:50 -0400 Message-ID: <4124C6F5.3080907@nortelnetworks.com> Date: Thu, 19 Aug 2004 11:27:49 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Briscoe Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) References: <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> In-Reply-To: <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> 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 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 think some of the new "enhancements" you propose would make TESLA ineffective for the most part (should have read the new tesla-intro I-D; will do now). I also found it interesting that the "adversary" can become a member of a secure group easily (as in the IP Television example below, to make the case that we don't need to differentiate between members and non-members ), but which cannot take over someone's network connectivity. Some specific points: 1. I think the argument for immediate authentication is weak: for instance, in many networks, ARP spoofing might allow a user to act as a WiTM and successfully subvert TESLA authentication. Furthermore, an adversary can send a bogus packet and hope to succeed. If the adversary is nearer to the sender than at least another receiver, then receiving, processing, re-transmitting is not as hard to assume that we don't need to consider the possibility. Besides, if the goal is to try and confuse a receiver, the attack will work most of the time. 2. "Immediate authentication" combined with your suggestion of accepting unverifiable packets (#5 below) as legitimate, would be a disaster. I also think reliance on "history" is a bad idea: after a stock broker, say, has been tricked into trading based on what he thinks is legitimate information, realizing later that the information is bogus would be useless. I agree that unverifiable packets might be kept around for future analysis, however. I would agree that some enhancements are necessary for real-time and interactive applications, but they should not come at this cost! regards, Lakshminath PS: I was wondering if disclosing soon as in case of immediate authentication would mean tighter time synchronization requirement. Bob Briscoe wrote: > Mark, Elisabetta, > > Thanks for the new SRTP-TESLA I-D draft 01. > > Below is a thorough review. I'm afraid these comments would have been > more useful after draft 00. But I've moved on from group security, so > I don't follow the list closely. My original motivation back in 1999 > behind thinking up what became known as TESLA (in parallel with the > co-authors of the TESLA intro) was to authenticate multicast RTP, so I > hope you will find the suggested improvements below useful. > > Essentially, the goal with SRTP is to keep the packet size as low as > possible. Although this is a bandwidth concern (as mentioned in your > section 6), it is more a latency concern for many real-time > applications, particularly interactive voice (conferencing) and to a > lesser extent interactive video (conferencing). > > I explain below how you can trade-off sender memory/processing for > smaller packet size. In this way, we can also do stronger immediate > authentication than you have (against DoS) while keeping equally > strong delayed authentication, but completely removing the need for 3 > of your 4 byte headers per pkt. = 12 bytes less overhead out of your > 38 bytes. As you say, implementations can also choose to do heavier > truncation of the MAC etc, to get further overhead savings. > > I also explain below how we might even achieve interactive-quality > latency in parallel to delayed authentication, rather than in series. > The improved immediate authentication makes this feasible. > > I can send you a tech report I started in 1999, with RTP uppermost in > my mind as an application. I'm afraid it's unfinished and therefore > unpublished. But the body is finished - I just never got round to > topping and tailing it. It gives the rationale and protocol details > behind all the points below, plus other stuff like how I would > envisage extensions to SDP for sending session security parameters for > TESLA. Just ask if you want a copy (PDF, 19pp including 9 figures). > > If you believe some of the points below impact on the TESLA intro > rather than SRTP-TESLA, say now. However, we have tried to accommodate > all these possibilities in draft-ietf-msec-tesla-intro-03.txt just > published. However, until re-reading my own report just now, I had > forgotten how I had done stronger immediate authentication (point 3/ > below)! > > 1/ Key index field is redundant with SRTP > ---------------------------------------- > The key index can be derived from the RTP timestamp in each message. > This saves 4 bytes in each packet. > > If the sender buffers packets between adding the RTP timestamp and > adding TESLA authentication fields, this will add to the TESLA > authentication delay. But a good RTP implementation shouldn't be doing > serious buffering here. > > 2/ Non-TESLA group authentication to protect against DoS should be > optional > --------------------------------------------------------------------------- > > The immediate authentication provided by your non-TESLA group > authentication only protects against DoS by non-group members. It > should be RECOMMENDED not REQUIRED (section 7). Two reasons: > i) Imagine an Internet TV application, with millions of viewers. It > would be silly to MANDATE the non-TESLA group authentication fields in > such a scenario. An attacker isn't going to be prevented from mounting > a DoS attack by being excluded from the group. Such large, publicly > accessible groups are too easy to join for group authentication to > make sense. > ii) If there is no history of DoS attacks on a particular group, it is > silly to add this overhead to every packet to protect against a threat > of which there is no risk. > > Below, anyway, I show another way to do immediate authentication > without these group authentication fields, and it's stronger. > > 3/ Non-TESLA group authentication to protect against DoS is redundant > --------------------------------------------------------------------- > If the time interval for switching to a new key is set to be the same > as that for each RTP packet, the disclosed key allows an immediate > rather than delayed test that affords good enough protection against > DoS on its own (irrespective of whether attackers are within or > outside the group). TESLA delayed authentication is still necessary to > protect against attackers with some control over the network. But you > get immediate 'network-dependent' authentication. I use this term to > mean authentication dependent on the integrity of the network, but > still protecting against malicious behaviour of end systems. > > Each time a packet arrives at a receiver, it will now contain a new > disclosed key. An immediate check can be made as to whether: > - this key has already been seen (in which case all later packets with > duplicate keys are considered fake and ignored) > - this new key fits into the key chain. > The tech report gives a more exact definition of the tests. > > The only way an attacker can get hold of the next key in the chain is > to receive the next authentic packet. It then has to extract the key > and use it to create its own fake packet, then overtake the original > packet's arrival at some or all the other receivers. This might be > done in the following ways: > - request better latency service (even then, receiving, processing, > re-transmitting and overtaking the original packet is very hard) > - use a parallel network (ditto) > - watch for negative acks, and send retransmissions only to those > receivers affected > - conspire with a network provider, or take over a network node to > delay or remove the original packets from the remainder of the > multicast tree > > I believe this 'network-dependent' authentication, where all the above > uses and abuses of the network are infeasible, is sufficient to > protect against most DoS attacks. Indeed, it gives better protection > against DoS than the group authentication MAC you use. > > Changing the key each packet requires more memory or processing at the > sender. But the complexity only rises O(log(r)) where r is the key > change rate, so this isn't a big hit. See refs [21, 22] in the TESLA > intro draft for efficient hash traversal algorithms. > > BTW, this immediate authentication isn't novel. It is the basic S/KEY > protocol that has been used for years (IETF RFC1760 based on Lamport). > > 4/ No need to include the key index, i, in the TESLA authenticated > portion > -------------------------------------------------------------------------- > > [If you accept my argument in 1/ that the key index is unnecessary, my > point here is irrelevant.] > The key index determines the operation of the verification algorithm - > viz. which key to use to create a MAC to compare with the TESLA MAC > field. There is no point in including this key index within the > coverage of the TESLA MAC (end of section 4.2, section 4.5 & 4.6). If > the key index is altered, the verification will fail, whether or not > the key index is covered by the MAC. It doesn't really matter either > way. It's just contrary to what the TESLA intro specifies, and > therefore liable to lead to confused standardistion of implementations. > > BTW, it should be pointed out that the verification algo should check > the key index is within an expected range before using it (e.g. only a > small increment above the last highest verified key index seen). > Otherwise, an attacker can tamper with this field to lead all > receivers to run millions of hash operations unnecessarily. I prefer > to call it a key-index *hint*, to remind me not to rely on it being > correct. > > 5/ Discard if a packet cannot be authenticated should be optional > ----------------------------------------------------------------- > It is wrong to say a packet MUST be discarded if a safe condition does > not hold (section 4.4 & 4.4.2). We have changed the lastest TESLA > intro I-D to clarify this point. It is one thing for verification to > fail. It is another for the verification test to not be possible (e.g. > due to excessive delay). In the latter case, it should be > application-dependent whether the packet is discarded. > > Instead, we have introduced the term "considered unauthenticated" for > such packets. There might be an internal API between the verifier and > the application to flag when packets are considered unauthenticated, > rather than dropping them (a fairly dumb implicit API). An explicit > API is likely to be preferred, to distinguish network loss from > potential attacks. > > For instance, if there has been no history of verification failure, > and the odd packet arrives too late to be verified safely, an > application should be within its rights to assume the *probability* of > such packets being authentic is high. > > Also, part of the application might involve analysing the cause of > attacks. It would be wrong to mandate discard, thus removing the > evidence such applications need. > > 6/ Play-out may be in parallel to buffering awaiting authentication > ------------------------------------------------------------------- > In the note at the end of section 4.4.2, you say decryption can be > done optimistically before TESLA verification. I would ask you to add > that some delay sensitive applications might even play-out the packets > optimistically before TESLA verification (still buffering the packets > in parallel). If TESLA verification subsequently fails, then roll-back > would have to be achieved at the user interface level. We have given > an example in the new TESLA intro. > > 7/ TESLA tail piece section required > ------------------------------------ > Perhaps after the TESLA bootstrapping section, a new section is > required to explain the implications on SRTP of disclosing the > remaining keys after all RTP data has finished. > > Nits > ==== > A general point of style: I found the spec had too much 'knitting > together by reference' from other specs. As Ran said in an earlier > posting, it needs at least some sketching of what is referred to. > Otherwise it is unlikely to lead to safe standardisation of > implementations. Particularly given that the references themselves are > evolving, it becomes unsafe to expect people to find discrepancies > when reviewing this draft by re-reading the latest drafts of the other > specs each time. Sections 4.4. & 4.4.1 were particular culprits. > However, I also have some sympathy with the view that duplication of > parts of specs in other specs can lead to inconsistency. > > Throughout: To be consistent with the TESLA intro, the time-slot > index, I, should be i (lower case). > Sec 2. "...may often used..." --> "...may often be used..." > Sec 3. "This specification assumes that the reader is familiar with > TESLA" repeats the same sentence in Sec 1.1. > Sec 3. TESLA synch protocol & initial bootstrapping outside scope, but > presumably you will include a ref once one is available. > Sec 4. "...and the delayed-authentication TESLA elements of procedure > [TESLA]." Garbled sentence? > Sec 4.1 "showed" --> "shown" > Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." > Sec 4.4 "If the safe condition does not hold,..." add "...and the > event SHOULD be logged." > Sec 5. TESLA doesn't assume local clocks don't drift too much. Rather > it requires a bound on clock drift to be known. > Sec 7. "...an in the TESLA specification..." --> "...and in the TESLA > specification..." > Sec 7. "...noted that the all TESLA security..." sentence garbled. > > Bob > > > ____________________________________________________________________________ > > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT plc. > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > _______________________________________________ > 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 Aug 19 11:47:08 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11306 for ; Thu, 19 Aug 2004 11:47:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CE2CD8CAB9; Thu, 19 Aug 2004 11:47:08 -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 443E88C921 for ; Thu, 19 Aug 2004 11:47:07 -0400 (EDT) Received: (qmail 28087 invoked by uid 3269); 19 Aug 2004 15:47:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28084 invoked from network); 19 Aug 2004 15:47:07 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 19 Aug 2004 15:47:07 -0000 Received: (qmail 7538 invoked from network); 19 Aug 2004 11:47:06 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 19 Aug 2004 11:47:06 -0400 Received: (qmail 85438 invoked from network); 19 Aug 2004 11:47:05 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.46) by mail1.oct.nac.net with SMTP; 19 Aug 2004 11:47:05 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i7JDGXL10797; Thu, 19 Aug 2004 09:16:33 -0400 Date: Thu, 19 Aug 2004 09:16:33 -0400 (EDT) From: George Gross To: canetti Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , Brian Weis , 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 Hi Ran and Brian, On Thu, 19 Aug 2004, canetti wrote: > > George, > > > > On Wed, 18 Aug 2004, George Gross wrote: > > ... > > > > * Digital signatures do not necessarily provide non-repudiation, > > > regardless of the length of the keys. In order to provide non-repudiation, > > > the public key of the signature should be appropriately certified. > > > In fact, if the public key to be used in the session is never > > > explicitly signed by the parties during the key exchange, then signing > > > packets with the corresponding secert key provides full repudiability > > > (while still providing perfectly good authentication). > > > > Perhaps you mispoke, but in my mind an uncertified public key provides no > > authentication. Are you suggesting pre-placed RSA public keys to avoid a > > TTP signature on the public key? > > > > Even if we avoid X.509 or PGP certificates, the key management protocol > > still uses some method to "certify" the public key. As noted in a parallel > > e-mail from me, RFC2408 section 3.12 Signature payload explicitly says > > that the signature may be used in non-repudiation services. Consider the > > implications for GDOI distributing the RSA public key as signed data under > > the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature > > certifies the RSA public key and consequently we get both authentication > > and non-repudiation service, not just authentication. Of course, the > > caveat is that YMMV wrt/ non-repudiation in the legal sense. > > There is a difference between an "uncertified" public key and an > "unauthenticated" one. > > For instance, if you and I already share an authenticated channel, and you > send to me a public key on this channel, then I know that this key comes > from you - thus i can use if for further authentication. But I cannot prove > to a third party, that the key came from you - since you never > certified it. (in other words, as far as the third party is concerned, > i could have generated this public key myself and am falsely > claiming that it came from you.) In your example, the signature private key is known to two parties, so of course all bets are off wrt/ non-repudiation. As for authentication, if the GC/KS downloads the signature private key into a GM, there still has to be a trusted mechanism for the GC/KS, acting as the group's TTP, to tell the group membership: The public key "XYZ" belongs to the identity known as Group Speaker George. Otherwise, a rogue Group Speaker could assert public key "JKL" belongs to Group Speaker George ;o) To publish the public key's binding, the GC/KS would sign a message containing the RSA public key and multicast it to the group, right? > Now, It is up to the key management algorithm whether to sign the RSA public > key to be used in ESP-RSA, or to authenticate it without signing > (eg, by MACing it using a key derived fom the session key). ==> So your definition of public key "certification", as opposed to public key "authentication", requires that the Group Speaker demonstrate its exclusive POP for its signature private key to the GC/KS and the GC/KS sign an object (i.e. a certifying message) that it witnessed that POP? > It is indeed interesting to look at existing key management protocols and > see whether they explicitly sign the SA exchange, or do they just MAC the > SA exchange. Given exclusive POP of the private key is the critical litmus test, I now better understand Brian's statement in an earlier e-mail: bew> Because I do not agree that there is a non-repudiation side affect to bew> using public keys as an ICV on an IPsec data packet. I'm afraid we're bew> just going to have to disagree on this point. I see why there isn't a non-repudiation side effect for the GDOI/ISAKMP example that we were talking about, as in the GDOI/ISAKMP scenario the GC/KS knows and downloads the Group Speaker's private key. So in summary, the non-repudiation side effect is dependent on the key management protocol providing the chain of trust AND having a proof of possession evidence for the Group Speaker's self-generated signature private key (which is never shared with the GC/KS or any other party). As a thought experiment, I sketched out on the back of an envelope how GSAKMP could add a non-repudiation service using the IPsec RSA signature facility. I concluded it was technically possible to piggyback new payloads on the existing exchanges to achieve this. Note that I am not proposing this, it was for illustrative purposes only ;o) My point is that IPsec RSA signature could support a full-fledged non-repudiation service. However, it is something that the key management protocol has to explicitly add features to support. > But, I must say that this concern of "involuntary non-repudiation" seems > like a secondary issue to me - I find it hard to believed that IP leyer > packet signatures, that are not managed directly by any application or user, > can be really used in court to prove non-repudiation. > In my GSAKMP IPsec mapping draft, there is an attribute certificate payload that delegates an application endpoint's signature authority to the IP layer GSAKMP subsystem. Although intended for delegating GSAKMP message signatures, it would be feasible to add another authorization flag in that attribute cert for delegating the source origin authentication signature. Of course, this delegation is clearly voluntary on the part of the application issuing the attribute cert. The question whether that IP layer signature also supports non-repudiation boils down to the group key management protocol's design goals, as discussed above. I would like to suggest that the IPsec RSA signatures draft add the following language wrt/ the above non-repudiation topic in its Security Considerations section first paragraph's list of protections: " o Non-repudiation. The key management protocol MAY provide a non-repudiation service for the signatures generated by the RSA private/public key pair. The mechanisms that support that service are outside the scope of this specification." hth, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 19 19:58:01 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20640 for ; Thu, 19 Aug 2004 19:57:59 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BD5738CF60; Thu, 19 Aug 2004 19:57:59 -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 E01C08CDB3 for ; Thu, 19 Aug 2004 19:57:58 -0400 (EDT) Received: (qmail 16698 invoked by uid 3269); 19 Aug 2004 23:57:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16695 invoked from network); 19 Aug 2004 23:57:58 -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 Aug 2004 23:57:58 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 19 Aug 2004 17:02:22 -0700 X-BrightmailFiltered: true Received: from cisco.com (dhcp-128-107-178-179.cisco.com [128.107.178.179]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7JNvtH6003821; Thu, 19 Aug 2004 16:57:55 -0700 (PDT) Message-ID: <41253FF5.2060008@cisco.com> Date: Thu, 19 Aug 2004 17:04:05 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: canetti , 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 Hi George, George Gross wrote: >Hi Ran and Brian, > >On Thu, 19 Aug 2004, canetti wrote: > > > >>George, >> >> >> >>On Wed, 18 Aug 2004, George Gross wrote: >> >>... >> >> >> >>>>* Digital signatures do not necessarily provide non-repudiation, >>>>regardless of the length of the keys. In order to provide non-repudiation, >>>>the public key of the signature should be appropriately certified. >>>>In fact, if the public key to be used in the session is never >>>>explicitly signed by the parties during the key exchange, then signing >>>>packets with the corresponding secert key provides full repudiability >>>>(while still providing perfectly good authentication). >>>> >>>> >>>Perhaps you mispoke, but in my mind an uncertified public key provides no >>>authentication. Are you suggesting pre-placed RSA public keys to avoid a >>>TTP signature on the public key? >>> >>>Even if we avoid X.509 or PGP certificates, the key management protocol >>>still uses some method to "certify" the public key. As noted in a parallel >>>e-mail from me, RFC2408 section 3.12 Signature payload explicitly says >>>that the signature may be used in non-repudiation services. Consider the >>>implications for GDOI distributing the RSA public key as signed data under >>>the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature >>>certifies the RSA public key and consequently we get both authentication >>>and non-repudiation service, not just authentication. Of course, the >>>caveat is that YMMV wrt/ non-repudiation in the legal sense. >>> >>> >>There is a difference between an "uncertified" public key and an >>"unauthenticated" one. >> >>For instance, if you and I already share an authenticated channel, and you >>send to me a public key on this channel, then I know that this key comes >>from you - thus i can use if for further authentication. But I cannot prove >>to a third party, that the key came from you - since you never >>certified it. (in other words, as far as the third party is concerned, >>i could have generated this public key myself and am falsely >>claiming that it came from you.) >> >> > >In your example, the signature private key is known to two parties, so of >course all bets are off wrt/ non-repudiation. > No, only one party has the private key. Let me re-state Ran's example in hopes of making it clearer. 1. A sends B public key P1 in an authenticated channel. 2. A creates a message with content that is offensive to B and signs it with public key P1. 3. B is angry but cannot prove to a 3rd party that A sent the offensive message, because A never presented a certificate proving that its identity is associated with public key P1. 4. In fact, A can can delete the key pair and claim that B created the key pair and the message signed by it. This possibility of repudiation is what ruins the prospect of B claiming non-repudiation. Now you may argue that B can claim non-repudiation because the channel was authenticated. Perhaps the authenticated channel has a non-repudiation property, perhaps not. To know, you'd have to apply the same logic to that authentication method for that channel. Still, we cannot say that either B or a 3rd party can prove non-repudiation on the packet A sent to B. [snip] > >I would like to suggest that the IPsec RSA signatures draft add the >following language wrt/ the above non-repudiation topic in its Security >Considerations section first paragraph's list of protections: > >" o Non-repudiation. The key management protocol MAY provide a >non-repudiation service for the signatures generated by the RSA >private/public key pair. The mechanisms that support that service are >outside the scope of this specification." > > > This suggestion caused me to look at RFC 2552/BCP 72 "Guidelines for Writing RFC Text on Security Considerations" again. It has two interesting write-ups on non-repudiation, sections 2.2 and 4.3. After reading this text I really feel that the difficulties with non-repudiation are so great that it is inappropriate to claim it as a protection in the Security Considerations of this draft, even supposing that it were to be performed by key management. Thanks, Brian >hth, > > George > > > > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 19 23:37:06 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29706 for ; Thu, 19 Aug 2004 23:37:06 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9DCD48CC35; Thu, 19 Aug 2004 23:37: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 EA4A78CBD8 for ; Thu, 19 Aug 2004 23:37:05 -0400 (EDT) Received: (qmail 58351 invoked by uid 3269); 20 Aug 2004 03:37:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58348 invoked from network); 20 Aug 2004 03:37:05 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 20 Aug 2004 03:37:05 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i7K3Yrc117600; Thu, 19 Aug 2004 23:34:54 -0400 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7K3arM49092; Thu, 19 Aug 2004 23:36:53 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i7K3aps36076; Thu, 19 Aug 2004 23:36:51 -0400 Date: Thu, 19 Aug 2004 23:36:50 -0400 (EDT) From: canetti To: George Gross Subject: Re: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Brian Weis , 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 George, I agree with most of what you say below. One clarification though: In my example below only the party that generated the keys ("you") in the example knows the the private signing key. Similarly, in the group setting with a GC/KS, only the sender knows the secret signing key. The sender sends the public verification key to the GC/KS over an authenticated unicast channel, and the GC/KS sends this key to each member, again over an authenticated unicast channel. The point is, again, that authentication is different than non-repudiation. For authentication, I only need to know for myself that the message I receive is authentic. For non-repudiation, I haveto be able to prove this fact to a third party. Ran PS: Again, I think it will be useful if much of this discussion made it to the draft for clarification. On Thu, 19 Aug 2004, George Gross wrote: > Hi Ran and Brian, > > On Thu, 19 Aug 2004, canetti wrote: > > > > > George, > > > > > > > > On Wed, 18 Aug 2004, George Gross wrote: > > > > ... > > > > > > * Digital signatures do not necessarily provide non-repudiation, > > > > regardless of the length of the keys. In order to provide non-repudiation, > > > > the public key of the signature should be appropriately certified. > > > > In fact, if the public key to be used in the session is never > > > > explicitly signed by the parties during the key exchange, then signing > > > > packets with the corresponding secert key provides full repudiability > > > > (while still providing perfectly good authentication). > > > > > > Perhaps you mispoke, but in my mind an uncertified public key provides no > > > authentication. Are you suggesting pre-placed RSA public keys to avoid a > > > TTP signature on the public key? > > > > > > Even if we avoid X.509 or PGP certificates, the key management protocol > > > still uses some method to "certify" the public key. As noted in a parallel > > > e-mail from me, RFC2408 section 3.12 Signature payload explicitly says > > > that the signature may be used in non-repudiation services. Consider the > > > implications for GDOI distributing the RSA public key as signed data under > > > the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature > > > certifies the RSA public key and consequently we get both authentication > > > and non-repudiation service, not just authentication. Of course, the > > > caveat is that YMMV wrt/ non-repudiation in the legal sense. > > > > There is a difference between an "uncertified" public key and an > > "unauthenticated" one. > > > > For instance, if you and I already share an authenticated channel, and you > > send to me a public key on this channel, then I know that this key comes > > from you - thus i can use if for further authentication. But I cannot prove > > to a third party, that the key came from you - since you never > > certified it. (in other words, as far as the third party is concerned, > > i could have generated this public key myself and am falsely > > claiming that it came from you.) > > In your example, the signature private key is known to two parties, so of > course all bets are off wrt/ non-repudiation. As for authentication, if > the GC/KS downloads the signature private key into a GM, there still has > to be a trusted mechanism for the GC/KS, acting as the group's TTP, to > tell the group membership: The public key "XYZ" belongs to the identity > known as Group Speaker George. Otherwise, a rogue Group Speaker could > assert public key "JKL" belongs to Group Speaker George ;o) To publish the > public key's binding, the GC/KS would sign a message containing the RSA > public key and multicast it to the group, right? > > > Now, It is up to the key management algorithm whether to sign the RSA public > > key to be used in ESP-RSA, or to authenticate it without signing > > (eg, by MACing it using a key derived fom the session key). > > > ==> So your definition of public key "certification", as opposed to public > key "authentication", requires that the Group Speaker demonstrate its > exclusive POP for its signature private key to the GC/KS and the GC/KS > sign an object (i.e. a certifying message) that it witnessed that POP? > > > It is indeed interesting to look at existing key management protocols and > > see whether they explicitly sign the SA exchange, or do they just MAC the > > SA exchange. > > Given exclusive POP of the private key is the critical litmus test, I now > better understand Brian's statement in an earlier e-mail: > > bew> Because I do not agree that there is a non-repudiation side affect to > bew> using public keys as an ICV on an IPsec data packet. I'm afraid we're > bew> just going to have to disagree on this point. > > I see why there isn't a non-repudiation side effect for the GDOI/ISAKMP > example that we were talking about, as in the GDOI/ISAKMP scenario the > GC/KS knows and downloads the Group Speaker's private key. So in summary, > the non-repudiation side effect is dependent on the key management > protocol providing the chain of trust AND having a proof of possession > evidence for the Group Speaker's self-generated signature private key > (which is never shared with the GC/KS or any other party). > > As a thought experiment, I sketched out on the back of an envelope how > GSAKMP could add a non-repudiation service using the IPsec RSA signature > facility. I concluded it was technically possible to piggyback new > payloads on the existing exchanges to achieve this. Note that I am not > proposing this, it was for illustrative purposes only ;o) > > My point is that IPsec RSA signature could support a full-fledged > non-repudiation service. However, it is something that the key management > protocol has to explicitly add features to support. > > > But, I must say that this concern of "involuntary non-repudiation" seems > > like a secondary issue to me - I find it hard to believed that IP leyer > > packet signatures, that are not managed directly by any application or user, > > can be really used in court to prove non-repudiation. > > > > In my GSAKMP IPsec mapping draft, there is an attribute certificate > payload that delegates an application endpoint's signature authority to > the IP layer GSAKMP subsystem. Although intended for delegating GSAKMP > message signatures, it would be feasible to add another authorization flag > in that attribute cert for delegating the source origin authentication > signature. Of course, this delegation is clearly voluntary on the part of > the application issuing the attribute cert. > > The question whether that IP layer signature also supports non-repudiation > boils down to the group key management protocol's design goals, as > discussed above. > > I would like to suggest that the IPsec RSA signatures draft add the > following language wrt/ the above non-repudiation topic in its Security > Considerations section first paragraph's list of protections: > > " o Non-repudiation. The key management protocol MAY provide a > non-repudiation service for the signatures generated by the RSA > private/public key pair. The mechanisms that support that service are > outside the scope of this specification." > > hth, > > George > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 23 01:55:59 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28705 for ; Mon, 23 Aug 2004 01:55:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BAE018CD23; Mon, 23 Aug 2004 01:55: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 0862C8CCCA for ; Mon, 23 Aug 2004 01:55:55 -0400 (EDT) Received: (qmail 28405 invoked by uid 3269); 23 Aug 2004 05:55:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28402 invoked from network); 23 Aug 2004 05:55:54 -0000 Received: from unknown (HELO nevis?pune?xchg.pune.nevisnetworks.com) (203.124.166.180) by klesh.pair.com with SMTP; 23 Aug 2004 05:55:54 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Aug 2004 11:25:49 +0530 Message-ID: <36993D449C7FA647BF43568E0793AB3E390E14@nevis_pune_xchg.pune.nevisnetworks.com> Thread-Topic: Help Thread-Index: AcSI1deZrFYcZcI/TF6PKRrITrv0xA== From: "Anjanish Pandey" To: Subject: [MSEC] Help 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="===============0170211887==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0170211887== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C488D5.D77DF4A8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C488D5.D77DF4A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I am new to secure multicast topic. Can some person tell me, where I can get some documents, for understanding, the topic of Securing Multicast traffic.=20 =20 Regards Anjanish ------_=_NextPart_001_01C488D5.D77DF4A8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am new to secure multicast topic.

Can some person tell me, where I can get some = documents, for understanding, the topic of Securing Multicast traffic. =

 

Regards

Anjanish

=00 ------_=_NextPart_001_01C488D5.D77DF4A8-- --===============0170211887== 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 --===============0170211887==-- From msec-bounces@securemulticast.org Mon Aug 23 18:49:26 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24248 for ; Mon, 23 Aug 2004 18:49:12 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8FF168CC47; Mon, 23 Aug 2004 18:49:04 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 432388CB55 for ; Mon, 23 Aug 2004 18:49:03 -0400 (EDT) Received: (qmail 6445 invoked by uid 3269); 23 Aug 2004 22:49:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6438 invoked from network); 23 Aug 2004 22:49:02 -0000 Received: from ams-iport-1.cisco.com (144.254.224.140) by klesh.pair.com with SMTP; 23 Aug 2004 22:49:02 -0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2004 01:00:08 +0200 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn2-748.cisco.com [10.21.114.236]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7NMmuuS008400; Tue, 24 Aug 2004 00:48:57 +0200 (MEST) In-Reply-To: <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8060A6C7-F556-11D8-9262-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Mon, 23 Aug 2004 15:48:07 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: elisabetta.carrara@ericsson.com, 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 Bob Thanks for you comments. More below... On Aug 19, 2004, at 12:31 AM, Bob Briscoe wrote: > <.... > Essentially, the goal with SRTP is to keep the packet size as low as > possible. Although this is a bandwidth concern (as mentioned in your > section 6), it is more a latency concern for many real-time > applications, particularly interactive voice (conferencing) and to a > lesser extent interactive video (conferencing). I'd say that this is definitely an SRTP requirement for voice on low-bandwidth links. As we know, there is a security tradeoff to keeping the packet size as low as possible. When we drop the authentication tag and don't perform the integrity check, we're at risk for many types of attacks; it's arguably okay for voice packets in some environments but not in general, e.g. not for keying in a credit card using dial tones - it is a brittle solution that fails whenever one can't limit the channel to voice. I personally don't like this option in SRTP. In IP multicast environments, moreover, re-use of the RTP sequence number, rollover-counter and SSRC for AES counter mode also has its pitfalls: There's exposure during SSRC collisions of known plaintext fields in RTP packets, late-joiners need to get the ROC as part of initialization, but the ROC probably should not appear in application signaling any more than the SSRC belongs there. I personally don't like the current encryption transform in SRTP for multicast applications but did not grasp the problems until we took the specification out to the product development community. Given all of these considerations, I think we should be prudent regarding bandwidth optimizations in RFC 3711 for IP multicast. We sure don't want to multicast SRTP without some message authentication. We may want to consider changes to the encryption transform for multicast, but this is another story. > > I explain below how you can trade-off sender memory/processing for > smaller packet size. In this way, we can also do stronger immediate > authentication than you have (against DoS) while keeping equally > strong delayed authentication, but completely removing the need for 3 > of your 4 byte headers per pkt. = 12 bytes less overhead out of your > 38 bytes. As you say, implementations can also choose to do heavier > truncation of the MAC etc, to get further overhead savings. > > I also explain below how we might even achieve interactive-quality > latency in parallel to delayed authentication, rather than in series. > The improved immediate authentication makes this feasible. > > I can send you a tech report I started in 1999, with RTP uppermost in > my mind as an application. I'm afraid it's unfinished and therefore > unpublished. But the body is finished - I just never got round to > topping and tailing it. It gives the rationale and protocol details > behind all the points below, plus other stuff like how I would > envisage extensions to SDP for sending session security parameters for > TESLA. Just ask if you want a copy (PDF, 19pp including 9 figures). Please send it to me - unicast. > > If you believe some of the points below impact on the TESLA intro > rather than SRTP-TESLA, say now. However, we have tried to accommodate > all these possibilities in draft-ietf-msec-tesla-intro-03.txt just > published. However, until re-reading my own report just now, I had > forgotten how I had done stronger immediate authentication (point 3/ > below)! > > 1/ Key index field is redundant with SRTP > ---------------------------------------- > The key index can be derived from the RTP timestamp in each message. > This saves 4 bytes in each packet. I would not say that two fields are redundant if they perform different functions, which I think is the case here. We would need to do a complete analysis of how the timestamp is used today in RTP applications before we can evaluate how safe this would be for all applications. I'd prefer to not overload an existing field in this way if we can avoid it. > > If the sender buffers packets between adding the RTP timestamp and > adding TESLA authentication fields, this will add to the TESLA > authentication delay. But a good RTP implementation shouldn't be doing > serious buffering here. What about high-bandwidth, server/playback media such as movies? In fact, let me try this: What about an MPEG packetizer that does a lot of pre-processing of the MPEG AUs prior to assigning them to packets. This might happen because the AUs were encrypted and required a lot of pre-processing. Maybe there would be a two-step process applied to one or more AUs in which timetamps are assigned during some processing and then everything gets sent. Maybe such a problem can be avoided in packetizers. There are a lot of considerations when we take an existing field such as the RTP timestamp and add new functions to it. If the functions are really identical, then they are redundant. I tend to doubt that. > 2/ Non-TESLA group authentication to protect against DoS should be > optional > ----------------------------------------------------------------------- > ---- > The immediate authentication provided by your non-TESLA group > authentication only protects against DoS by non-group members. It > should be RECOMMENDED not REQUIRED (section 7). I think that this point should be resolved in the base TESLA specification, i.e. I don't think there is anything that is SRTP-specific to this point. But we did not treat it that way in SRTP-TESLA, and that's probably my fault. Nonetheless, I think it should be REQUIRED in base TESLA. > Two reasons: > i) Imagine an Internet TV application, with millions of viewers. It > would be silly to MANDATE the non-TESLA group authentication fields in > such a scenario. An attacker isn't going to be prevented from mounting > a DoS attack by being excluded from the group. Such large, publicly > accessible groups are too easy to join for group authentication to > make sense. I see your point. Maybe it should just be RECOMMENDED, but I still think that we will have a more robust solution at very little cost if the check were just done. There are >200 TV channels in US digital cable and satellite offerings today and this will grow to include more narrowcasting. We don't want a special interest channel to be vulnerable to the particular opponents of that special interest. Sure, the channel could be so large as to include opponents, but rogue members can be removed and the keys changed. I don't know why we would not err on the side of more cautious than less. > ii) If there is no history of DoS attacks on a particular group, it is > silly to add this overhead to every packet to protect against a threat > of which there is no risk. Phishing attacks were pretty much unknown before the mid-90s and worms prior to the late 80s. I'd say the existence of the vulnerability is what we should focus on, first and foremost, and not the history of exploits against the vulnerability. > > Below, anyway, I show another way to do immediate authentication > without these group authentication fields, and it's stronger. > > 3/ Non-TESLA group authentication to protect against DoS is redundant > --------------------------------------------------------------------- > If the time interval for switching to a new key is set to be the same > as that for each RTP packet, the disclosed key allows an immediate > rather than delayed test that affords good enough protection against > DoS on its own (irrespective of whether attackers are within or > outside the group). TESLA delayed authentication is still necessary to > protect against attackers with some control over the network. But you > get immediate 'network-dependent' authentication. I use this term to > mean authentication dependent on the integrity of the network, but > still protecting against malicious behaviour of end systems. I think I get your point and I think it's largely independent of the previous two points or at least, this stands by itself. The dos by a non-group member relies upon the fact that memory gets tied up while packets are buffered awaiting authentication. In this case, there is no buffering of multiple packets, just one packet during the disclosure interval. Do I understand you correctly? > > Each time a packet arrives at a receiver, it will now contain a new > disclosed key. An immediate check can be made as to whether: > - this key has already been seen (in which case all later packets with > duplicate keys are considered fake and ignored) > - this new key fits into the key chain. > The tech report gives a more exact definition of the tests. > > The only way an attacker can get hold of the next key in the chain is > to receive the next authentic packet. It then has to extract the key > and use it to create its own fake packet, then overtake the original > packet's arrival at some or all the other receivers. This might be > done in the following ways: > - request better latency service (even then, receiving, processing, > re-transmitting and overtaking the original packet is very hard) > - use a parallel network (ditto) > - watch for negative acks, and send retransmissions only to those > receivers affected > - conspire with a network provider, or take over a network node to > delay or remove the original packets from the remainder of the > multicast tree > > I believe this 'network-dependent' authentication, where all the above > uses and abuses of the network are infeasible, is sufficient to > protect against most DoS attacks. Indeed, it gives better protection > against DoS than the group authentication MAC you use. > > Changing the key each packet requires more memory or processing at the > sender. But the complexity only rises O(log(r)) where r is the key > change rate, so this isn't a big hit. See refs [21, 22] in the TESLA > intro draft for efficient hash traversal algorithms. > > BTW, this immediate authentication isn't novel. It is the basic S/KEY > protocol that has been used for years (IETF RFC1760 based on Lamport). Your proposal is a configuration option. This option requires that ALL SRTP-TESLA applications change the key on each packet, in order to forgo the MAC. But if this is true for SRTP, it's likely true for most TESLA applications. Are the TESLA authors quite sure that all or most TESLA applications can tolerate a key change per packet? If so, why not put this in the core TESLA specification. I'd say that if it belongs in SRTP-TESLA, then it belongs in the core specification. No? > 4/ No need to include the key index, i, in the TESLA authenticated > portion > ----------------------------------------------------------------------- > --- I agree. > [If you accept my argument in 1/ that the key index is unnecessary, my > point here is irrelevant.] > The key index determines the operation of the verification algorithm - > viz. which key to use to create a MAC to compare with the TESLA MAC > field. There is no point in including this key index within the > coverage of the TESLA MAC (end of section 4.2, section 4.5 & 4.6). If > the key index is altered, the verification will fail, whether or not > the key index is covered by the MAC. It doesn't really matter either > way. It's just contrary to what the TESLA intro specifies, and > therefore liable to lead to confused standardistion of > implementations. > > BTW, it should be pointed out that the verification algo should check > the key index is within an expected range before using it (e.g. only a > small increment above the last highest verified key index seen). > Otherwise, an attacker can tamper with this field to lead all > receivers to run millions of hash operations unnecessarily. I prefer > to call it a key-index *hint*, to remind me not to rely on it being > correct. This sounds like an argument for keeping the MAC. > > 5/ Discard if a packet cannot be authenticated should be optional > ----------------------------------------------------------------- > It is wrong to say a packet MUST be discarded if a safe condition does > not hold (section 4.4 & 4.4.2). We have changed the lastest TESLA > intro I-D to clarify this point. It is one thing for verification to > fail. It is another for the verification test to not be possible (e.g. > due to excessive delay). In the latter case, it should be > application-dependent whether the packet is discarded. > > Instead, we have introduced the term "considered unauthenticated" for > such packets. There might be an internal API between the verifier and > the application to flag when packets are considered unauthenticated, > rather than dropping them (a fairly dumb implicit API). An explicit > API is likely to be preferred, to distinguish network loss from > potential attacks. > > For instance, if there has been no history of verification failure, > and the odd packet arrives too late to be verified safely, an > application should be within its rights to assume the *probability* of > such packets being authentic is high. > > Also, part of the application might involve analysing the cause of > attacks. It would be wrong to mandate discard, thus removing the > evidence such applications need. This sounds reasonable to me. > > 6/ Play-out may be in parallel to buffering awaiting authentication > ------------------------------------------------------------------- > In the note at the end of section 4.4.2, you say decryption can be > done optimistically before TESLA verification. I would ask you to add > that some delay sensitive applications might even play-out the packets > optimistically before TESLA verification (still buffering the packets > in parallel). If TESLA verification subsequently fails, then roll-back > would have to be achieved at the user interface level. We have given > an example in the new TESLA intro. I intended to say that all processing might proceed optimistically for applications where roll-back or notification of authentication-failure is possible. > > 7/ TESLA tail piece section required > ------------------------------------ > Perhaps after the TESLA bootstrapping section, a new section is > required to explain the implications on SRTP of disclosing the > remaining keys after all RTP data has finished. Yes, David McGrew pointed this out to us previously. We'll refer to your editorial comments at the next revision. thanks, Mark > > Nits > ==== > A general point of style: I found the spec had too much 'knitting > together by reference' from other specs. As Ran said in an earlier > posting, it needs at least some sketching of what is referred to. > Otherwise it is unlikely to lead to safe standardisation of > implementations. Particularly given that the references themselves are > evolving, it becomes unsafe to expect people to find discrepancies > when reviewing this draft by re-reading the latest drafts of the other > specs each time. Sections 4.4. & 4.4.1 were particular culprits. > However, I also have some sympathy with the view that duplication of > parts of specs in other specs can lead to inconsistency. > > Throughout: To be consistent with the TESLA intro, the time-slot > index, I, should be i (lower case). > Sec 2. "...may often used..." --> "...may often be used..." > Sec 3. "This specification assumes that the reader is familiar with > TESLA" repeats the same sentence in Sec 1.1. > Sec 3. TESLA synch protocol & initial bootstrapping outside scope, but > presumably you will include a ref once one is available. > Sec 4. "...and the delayed-authentication TESLA elements of procedure > [TESLA]." Garbled sentence? > Sec 4.1 "showed" --> "shown" > Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." > Sec 4.4 "If the safe condition does not hold,..." add "...and the > event SHOULD be logged." > Sec 5. TESLA doesn't assume local clocks don't drift too much. Rather > it requires a bound on clock drift to be known. > Sec 7. "...an in the TESLA specification..." --> "...and in the TESLA > specification..." > Sec 7. "...noted that the all TESLA security..." sentence garbled. > > Bob > > > _______________________________________________________________________ > _____ > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT > plc. > _______________________________________________________________________ > _____ > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > _______________________________________________ > 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 Aug 30 11:09:58 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00699 for ; Mon, 30 Aug 2004 11:09:58 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 63DEE8CC6B; Mon, 30 Aug 2004 11:09:59 -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 854B08CC69 for ; Mon, 30 Aug 2004 11:09:58 -0400 (EDT) Received: (qmail 93464 invoked by uid 3269); 30 Aug 2004 15:09:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93461 invoked from network); 30 Aug 2004 15:09:58 -0000 Received: from saturn.bt.com (HELO cbibipnt08.hc.bt.com) (193.113.57.20) by klesh.pair.com with SMTP; 30 Aug 2004 15:09:58 -0000 Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RRCTMC0N; Mon, 30 Aug 2004 16:10:06 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.107.36]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a); id 1093878605893; Mon, 30 Aug 2004 16:10:05 +0100 Received: from mut.jungle.bt.co.uk ([132.146.127.89]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id i7UF9M7Z020833; Mon, 30 Aug 2004 16:09:46 +0100 Message-Id: <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 30 Aug 2004 13:51:16 +0100 To: Mark Baugher From: Bob Briscoe Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: <8060A6C7-F556-11D8-9262-000A95DC10F2@cisco.com> References: <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: elisabetta.carrara@ericsson.com, 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 Mark, At 23:48 23/08/2004, Mark Baugher wrote: >Bob > Thanks for you comments. More below... > >On Aug 19, 2004, at 12:31 AM, Bob Briscoe wrote: ><.... >>Essentially, the goal with SRTP is to keep the packet size as low as >>possible. Although this is a bandwidth concern (as mentioned in your >>section 6), it is more a latency concern for many real-time >>applications, particularly interactive voice (conferencing) and to a >>lesser extent interactive video (conferencing). > >I'd say that this is definitely an SRTP requirement for voice on >low-bandwidth links. As we know, there is a security tradeoff to >keeping the packet size as low as possible. When we drop the >authentication tag and don't perform the integrity check, we're at risk >for many types of attacks; it's arguably okay for voice packets in some >environments but not in general, e.g. not for keying in a credit card >using dial tones - it is a brittle solution that fails whenever one >can't limit the channel to voice. I personally don't like this option >in SRTP. I'm not sure whether you're misunderstanding me, or just agreeing, but sounding as if you disagree. In no way am I proposing anything that doesn't do strong integrity checking. TESLA can strongly verify packets from tone dialling as much as from any other application, whether voice or not. The ONLY point at issue with TESLA is that it doesn't protect against a flooding attack during the key disclosure delay. >In IP multicast environments, moreover, re-use of the RTP sequence >number, rollover-counter and SSRC for AES counter mode also has its >pitfalls: There's exposure during SSRC collisions of known plaintext >fields in RTP packets, late-joiners need to get the ROC as part of >initialization, but the ROC probably should not appear in application >signaling any more than the SSRC belongs there. I personally don't >like the current encryption transform in SRTP for multicast >applications but did not grasp the problems until we took the >specification out to the product development community. Relevant to the discussion of key indexes - see later. >Given all of these considerations, I think we should be prudent >regarding bandwidth optimizations in RFC 3711 for IP multicast. We >sure don't want t multicast SRTP without some message authentication. To be crystal clear, nowhere have I proposed anything that removes message authentication. TESLA authentication/integrity/replay checking is as good without the group authentication tag as with it, albeit delayed. The discussion is purely about how to protect against flooding attacks immediately on arrival of a packet, to prevent having to buffer attacker's packets until TESLA delayed authentication can be used once the TESLA key is disclosed. Having thought about it, I will be stronger than the last mail and say a group MAC will provide barely any additional protection in most circumstances so should not be the default. The logic of using a group MAC with TESLA looks like this: Sender's level of trust in group members not to spoof packets | using a group key? | Low High | | Use source authentication (ie TESLA). Use group authentication. | TESLA is vulnerable to DoS filling buffer until delayed auth | Use group authentication alongside TESLA (as in current SRTP draft) I hope this diagram helps highlight the broken logic. Group authentication is being MANDATED in the SRTP draft in a scenario which only ever arises where the group isn't trusted. Adding group authentication to TESLA only provides any additional value for the narrow range of scenarios where group members aren't trusted enough to use group authentication alone, but they are trusted sufficiently that group authentication might detect some DoS attacks - pretty slim odds. Worth allowing as an option, but surely not MANDATING. >We may want to consider changes to the encryption transform for >multicast, but this is another story. > >> >>I explain below how you can trade-off sender memory/processing for >>smaller packet size. In this way, we can also do stronger immediate >>authentication than you have (against DoS) while keeping equally >>strong delayed authentication, but completely removing the need for 3 >>of your 4 byte headers per pkt. = 12 bytes less overhead out of your >>38 bytes. As you say, implementations can also choose to do heavier >>truncation of the MAC etc, to get further overhead savings. >> >>I also explain below how we might even achieve interactive-quality >>latency in parallel to delayed authentication, rather than in series. >>The improved immediate authentication makes this feasible. >> >>I can send you a tech report I started in 1999, with RTP uppermost in >>my mind as an application. I'm afraid it's unfinished and therefore >>unpublished. But the body is finished - I just never got round to >>topping and tailing it. It gives the rationale and protocol details >>behind all the points below, plus other stuff like how I would >>envisage extensions to SDP for sending session security parameters for >>TESLA. Just ask if you want a copy (PDF, 19pp including 9 figures). > >Please send it to me - unicast. Sent. >>If you believe some of the points below impact on the TESLA intro >>rather than SRTP-TESLA, say now. However, we have tried to accommodate >>all these possibilities in draft-ietf-msec-tesla-intro-03.txt just >>published. However, until re-reading my own report just now, I had >>forgotten how I had done stronger immediate authentication (point 3/ >>below)! >> >>1/ Key index field is redundant with SRTP >>---------------------------------------- >>The key index can be derived from the RTP timestamp in each message. >>This saves 4 bytes in each packet. >I would not say that two fields are redundant if they perform different >functions, which I think is the case here. We would need to do a >complete analysis of how the timestamp is used today in RTP >applications before we can evaluate how safe this would be for all >applications. I'd prefer to not overload an existing field in this way >if we can avoid it. I had thought about the ramifications fairly carefully before saying this. I suggest that the way to deal with the TESLA time interval identifier, I, is to: - remove I from the default TESLA-SRTP packet format - explain how to derive I from the RTP timestamp - MANDATE that a sender authentication module should use a TESLA key interval derived from the RTP timestamp, not the clock - warn implementors that any delay in the sender stack will add to the TESLA authentication delay (but not weaken it) - (if we can think of any other problems ) warn implementors what to watch out for when overloading the RTP timestamp function (I'm fairly sure there aren't any - and I've thought long and hard) - make I optional in the TESLA-SRTP packet format for implementors to use if they are in one of these obscure scenarios >>If the sender buffers packets between adding the RTP timestamp and >>adding TESLA authentication fields, this will add to the TESLA >>authentication delay. But a good RTP implementation shouldn't be doing >>serious buffering here. > >What about high-bandwidth, server/playback media such as movies? In >fact, let me try this: What about an MPEG packetizer that does a lot >of pre-processing of the MPEG AUs prior to assigning them to packets. >This might happen because the AUs were encrypted and required a lot of >pre-processing. Maybe there would be a two-step process applied to one >or more AUs in which timetamps are assigned during some processing and >then everything gets sent. >Maybe such a problem can be avoided in packetizers. There are a lot of >considerations when we take an existing field such as the RTP timestamp >and add new functions to it. As long as we mandate that the TESLA sender uses the key appropriate to the time interval derived from the RTP timestamp (not from the clock), the protocol is safe. The TESLA safety test is still accurate. Any delay after RTP has determined its timestamp then folds into the delay between sender and receiver that TESLA is designed to handle safely. Of course, this makes the delay longer, which /delays/ authentication. But it doesn't /weaken/ authentication. See section 4 of the TESLA intro for discussion of similar scenarios (eg TCP buffering). If authentication delay is a problem for a particular scenario, and it's some odd scenario like you suggest where a large part of the delay is within the sender stack between RTP and TESLA, then the implementor can choose to use an explicit I in the packet. >If the functions are really identical, then they are redundant. I tend >to doubt that. I'd rather say that the functions of the two fields are invariably equivalent, but may not be in some scenarios, when it's up to the implementor to use the option of an explicit I. >>2/ Non-TESLA group authentication to protect against DoS should be >>optional >>----------------------------------------------------------------------- ---- >>The immediate authentication provided by your non-TESLA group >>authentication only protects against DoS by non-group members. It >>should be RECOMMENDED not REQUIRED (section 7). > >I think that this point should be resolved in the base TESLA >specification, i.e. I don't think there is anything that is >SRTP-specific to this point. But we did not treat it that way in >SRTP-TESLA, and that's probably my fault. Nonetheless, I think it >should be REQUIRED in base TESLA. Currently section 5 (security considerations) of the TESLA-intro mentions group authentication as one possible way of preventing flooding attacks during the key disclosure delay. But it doesn't MANDATE it. I'm simply taking issue with group authentication being MANDATED in SRTP-TESLA, as I don't think it's effective in many (most?) scenarios, making it unnecessary overhead. I have no problem with making a group MAC optional for scenarios where it does improve matters. >>Two reasons: >>i) Imagine an Internet TV application, with millions of viewers. It >>would be silly to MANDATE the non-TESLA group authentication fields in >>such a scenario. An attacker isn't going to be prevented from mounting >>a DoS attack by being excluded from the group. Such large, publicly >>accessible groups are too easy to join for group authentication to >>make sense. > >I see your point. Maybe it should just be RECOMMENDED, but I still >think that we will have a more robust solution at very little cost if >the check were just done. IMHO, a default of 10 octets per RTP packet is a high additional cost to MANDATE, which means interoperable implementations must carry it even when it serves no purpose. Whether or not you agree with me about the prevalence of scenarios that don't need it, you do agree that the TV one doesn't (and I give another example below). So why MANDATE something that isn't always needed? >There are >200 TV channels in US digital >cable and satellite offerings today and this will grow to include more >narrowcasting. We don't want a special interest channel to be >vulnerable to the particular opponents of that special interest. Sure, >the channel could be so large as to include opponents, but rogue >members can be removed and the keys changed. > >I don't know why we would not err on the side of more cautious than >less. Even if there were no alternative to protect against flooding (tho I believe 3/ below is an alternative), it would be wrong to MANDATE a field that sometimes serves no purpose. >>ii) If there is no history of DoS attacks on a particular group, it is >>silly to add this overhead to every packet to protect against a threat >>of which there is no risk. > >Phishing attacks were pretty much unknown before the mid-90s and worms >prior to the late 80s. I'd say the existence of the vulnerability is >what we should focus on, first and foremost, and not the history of >exploits against the vulnerability. Sorry, history was a distracting word. I meant likelihood. Imagine a video conf between senior execs of competing companies, or between representatives of mutually distrusting governments. They don't trust each other not to spoof what the other parties are saying, but they have no likelihood of one launching a flooding attack on the other (e.g. the whole thing is over a joint VPN). They need group authentication like a phish needs a bicycle. So why MANDATE it? >>Below, anyway, I show another way to do immediate authentication >>without these group authentication fields, and it's stronger. >> >>3/ Non-TESLA group authentication to protect against DoS is redundant >>--------------------------------------------------------------------- >>If the time interval for switching to a new key is set to be the same >>as that for each RTP packet, the disclosed key allows an immediate >>rather than delayed test that affords good enough protection against >>DoS on its own (irrespective of whether attackers are within or >>outside the group). TESLA delayed authentication is still necessary to >>protect against attackers with some control over the network. But you >>get immediate 'network-dependent' authentication. I use this term to >>mean authentication dependent on the integrity of the network, but >>still protecting against malicious behaviour of end systems. > >I think I get your point and I think it's largely independent of the >previous two points or at least, this stands by itself. Orthogonal-ish... if there is an alternative to a group MAC for detecting flooding, it makes a group MAC even less necessary to MANDATE (not wishing to labour the point ;) >The dos by a >non-group member or a group member >relies upon the fact that memory gets tied up while >packets are buffered awaiting authentication. In this case, there is >no buffering of multiple packets, just one packet during the disclosure >interval. Do I understand you correctly? No. The disclosure *interval* (delay) still spans multiple packets. The new feature depends on each key now only ever being *disclosed* once, rather than the same key being disclosed repeatedly as it was when there were multiple packets in the same TESLA time interval. As soon as a packet arrives, the disclosed key in it now has two purposes: - it's original TESLA purpose: to verify a packet received some time previously - to immediately show the receiver that the sender of this packet knew the next key back along the hash chain which is now only ever *disclosed* once So if more packets are received that *disclose* the same key, the receiver can assume (at least until the delayed TESLA verification) that only the first packet to disclose each key was genuine. If a network element is compromised, an attacker can discover the next disclosed key and overtake or replace a genuine packet with many others. But the receiver can still immediately discard all but the first to arrive, protecting itself from memory overflow. So the scheme has the following properties: - The receiver will never buffer more than one packet per packet sent by the genuine sender (so the receiver's buffer fill rate is still clocked by the party that reveals each new key backwards in the chain). - As each key is later disclosed, TESLA can do delayed verification of these stored packets. - if they pass delayed verfication, the messages must be genuine - if they fail delayed verfication, the messages must not have been genuine - The true message will have been lost in the latter case. But, then if an attacker can compromise a network element, it can discard the true messages anyway (a group MAC can't prevent this either ;) I need to fully document this. There are some corner cases not covered by the above. I've given an outline later. Obviously, this DoS protection idea hasn't had the same peer-review as TESLA, except it is essentially just S/KEY, which has had ample peer review (but perhaps not in a group setting). >>Each time a packet arrives at a receiver, it will now contain a new >>disclosed key. An immediate check can be made as to whether: >>- this key has already been seen (in which case all later packets with >>duplicate keys are considered fake and ignored) >>- this new key fits into the key chain. >>The tech report gives a more exact definition of the tests. For completeness, I'll give a more precise description of the change I'm proposing here. Note when I use the term key index, it might be derived from other info in the RTP header, rather than explicitly declared in each packet: The sender: The sender uses a new key back along the hash chain for each packet. It guarantees not to disclose any key for the disclosure delay. It must therefore delay disclosure for a number of packets (not a time), but calculated from the fastest sustained overall packet rate that it guarantees not to exceed for any future window of time with a duration of the disclosure delay. The receiver: 1/ Immediately on reception, the receiver does these tests: o) Session DoS mitigation tests: check arriving packets have valid IP addresses and port numbers for the session i) CPU DOS mitigation test: checks the key index of the arriving packet is within a reasonable distance (say 64) of the previous highest index received ii) S/KEY DoS mitigation test: checks that the TESLA key disclosed in the packet fits into the hash chain where its index says it should iii) flooding DoS mitigation test: discards second and subsequent disclosures of the same key (this test is complicated by packet misordering - I have held back 5 paras on that - this mail is already too long) iv) the regular TESLA delay safety test to determine whether the key used is guaranteed not to have been disclosed yet 2/ it then buffers the packet to await regular TESLA delayed verification if all tests pass 3/ Later, when the key for this packet is disclosed, the receiver does TESLA regular verification. >>The only way an attacker can get hold of the next key in the chain is >>to receive the next authentic packet. It then has to extract the key >>and use it to create its own fake packet, then overtake the original >>packet's arrival at some or all the other receivers. This might be >>done in the following ways: >>- request better latency service (even then, receiving, processing, >>re-transmitting and overtaking the original packet is very hard) >>- use a parallel network (ditto) >>- watch for negative acks, and send retransmissions only to those >>receivers affected >>- conspire with a network provider, or take over a network node to >>delay or remove the original packets from the remainder of the >>multicast tree >> >>I believe this 'network-dependent' authentication, where all the above >>uses and abuses of the network are infeasible, is sufficient to >>protect against most DoS attacks. Indeed, it gives better protection >>against DoS than the group authentication MAC you use. >> >>Changing the key each packet requires more memory or processing at the >>sender. But the complexity only rises O(log(r)) where r is the key >>change rate, so this isn't a big hit. See refs [21, 22] in the TESLA >>intro draft for efficient hash traversal algorithms. >> >>BTW, this immediate authentication isn't novel. It is the basic S/KEY >>protocol that has been used for years (IETF RFC1760 based on Lamport). > >Your proposal is a configuration option. This option requires that ALL >SRTP-TESLA applications change the key on each packet, in order to >forgo the MAC. But if this is true for SRTP, it's likely true for most >TESLA applications. Are the TESLA authors quite sure that all or most >TESLA applications can tolerate a key change per packet? As an option, it would only be used where the app could tolerate this. The key change per packet isn't a problem per se (just two more hashes for sndr & rcvr). It's the storage of the longer key chain for the sndr (O log(n)), or the alternative of only storing regular keys along it and re-running the calculations for those between. >If so, why >not put this in the core TESLA specification. I'd say that if it >belongs in SRTP-TESLA, then it belongs in the core specification. No? You are absolutely correct. We (the co-authors of the TESLA base spec) are discussing this off-line right now. It's my fault we didn't reach closure on it before TESLA got this far. I was originally pushing this as an option, but I think I never quite got myself understood. Somewhere in the mists of time I gave up. I've been taking a back seat on the TESLA work until just recently, so my brain obviously wasn't in gear when reviewing drafts. I forgot I'd got this option to attack the DoS problem. It was only through reveiwing the SRTP draft that the technique came back to me. Now, the more I argue about it, the better I think it is. However, it's not out of the woods yet. My co-authors are trying to break it. I believe I've defended it in the case of variable packet rate and packet misordering. But I'm expecting more attempts to break it (and, of course, anyone on this list is welcome to try as well). If it comes out intact, you should see text on it shortly. Otherwise, I guess the TESLA base spec will stay as it is. >>4/ No need to include the key index, i, in the TESLA authenticated >>portion >>----------------------------------------------------------------------- --- > >I agree. >>[If you accept my argument in 1/ that the key index is unnecessary, my >>point here is irrelevant.] >>The key index determines the operation of the verification algorithm - >>viz. which key to use to create a MAC to compare with the TESLA MAC >>field. There is no point in including this key index within the >>coverage of the TESLA MAC (end of section 4.2, section 4.5 & 4.6). If >>the key index is altered, the verification will fail, whether or not >>the key index is covered by the MAC. It doesn't really matter either >>way. It's just contrary to what the TESLA intro specifies, and >>therefore liable to lead to confused standardistion of >>implementations. >> >>BTW, it should be pointed out that the verification algo should check >>the key index is within an expected range before using it (e.g. only a >>small increment above the last highest verified key index seen). >>Otherwise, an attacker can tamper with this field to lead all >>receivers to run millions of hash operations unnecessarily. I prefer >>to call it a key-index *hint*, to remind me not to rely on it being >>correct. > >This sounds like an argument for keeping the MAC. No. It is an argument for watching that it doesn't appear to imply packets are extremely re-ordered (e.g. it must be no more than, say, 64 different from the previous highest index, cf the SRTP replay protection window). You /could/ use a group MAC to do an initial test of its integrity, but why waste 10 octets when you can do a test that uses none? And this would only work if you trusted the group members (recall, we are using TESLA because we don't trust them). The key index is implicitly authenticated (similar to the implicit header authentication in section 9.5.2 of the SRTP RFC) because the TESLA MAC depends on it. If the key index is tampered with, the authentication test will fail as it should. >>5/ Discard if a packet cannot be authenticated should be optional >>----------------------------------------------------------------- >>It is wrong to say a packet MUST be discarded if a safe condition does >>not hold (section 4.4 & 4.4.2). We have changed the lastest TESLA >>intro I-D to clarify this point. It is one thing for verification to >>fail. It is another for the verification test to not be possible (e.g. >>due to excessive delay). In the latter case, it should be >>application-dependent whether the packet is discarded. >> >>Instead, we have introduced the term "considered unauthenticated" for >>such packets. There might be an internal API between the verifier and >>the application to flag when packets are considered unauthenticated, >>rather than dropping them (a fairly dumb implicit API). An explicit >>API is likely to be preferred, to distinguish network loss from >>potential attacks. >> >>For instance, if there has been no history of verification failure, >>and the odd packet arrives too late to be verified safely, an >>application should be within its rights to assume the *probability* of >>such packets being authentic is high. >> >>Also, part of the application might involve analysing the cause of >>attacks. It would be wrong to mandate discard, thus removing the >>evidence such applications need. > >This sounds reasonable to me. >> >>6/ Play-out may be in parallel to buffering awaiting authentication >>------------------------------------------------------------------- >>In the note at the end of section 4.4.2, you say decryption can be >>done optimistically before TESLA verification. I would ask you to add >>that some delay sensitive applications might even play-out the packets >>optimistically before TESLA verification (still buffering the packets >>in parallel). If TESLA verification subsequently fails, then roll-back >>would have to be achieved at the user interface level. We have given >>an example in the new TESLA intro. > >I intended to say that all processing might proceed optimistically for >applications where roll-back or notification of authentication-failure >is possible. >> >>7/ TESLA tail piece section required >>------------------------------------ >>Perhaps after the TESLA bootstrapping section, a new section is >>required to explain the implications on SRTP of disclosing the >>remaining keys after all RTP data has finished. > >Yes, David McGrew pointed this out to us previously. > >We'll refer to your editorial comments at the next revision. I've added a couple more below... >thanks, Mark And many thanks to you too, for doing all the hard work on these drafts. more comments follow... >>Nits >>==== >>A general point of style: I found the spec had too much 'knitting >>together by reference' from other specs. As Ran said in an earlier >>posting, it needs at least some sketching of what is referred to. >>Otherwise it is unlikely to lead to safe standardisation of >>implementations. Particularly given that the references themselves are >>evolving, it becomes unsafe to expect people to find discrepancies >>when reviewing this draft by re-reading the latest drafts of the other >>specs each time. Sections 4.4. & 4.4.1 were particular culprits. >>However, I also have some sympathy with the view that duplication of >>parts of specs in other specs can lead to inconsistency. The particular point was that the TESLA delay safety test is missing from 4.4.2, but strictly you have said it must be done earlier (in 4.4) by referring to the TESLA-intro. I think it should be in the list of things the receiver should do. >>Throughout: To be consistent with the TESLA intro, the time-slot >>index, I, should be i (lower case). I now realise that lower case i would conflict with the SRTP spec. >>Sec 2. "...may often used..." --> "...may often be used..." >>Sec 3. "This specification assumes that the reader is familiar with >>TESLA" repeats the same sentence in Sec 1.1. >>Sec 3. TESLA synch protocol & initial bootstrapping outside scope, but >>presumably you will include a ref once one is available. >>Sec 4. "...and the delayed-authentication TESLA elements of procedure >>[TESLA]." Garbled sentence? >>Sec 4.1 "showed" --> "shown" >>Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." Sec 4.3 bullet 10, uses same n_c notation as bullet 2 (but for something else) >>Sec 4.4 "If the safe condition does not hold,..." add "...and the >>event SHOULD be logged." Sec 4.4.2: "...perform verification of the SRTP integrity protection tag..." this terminology hasn't been used in this draft (it was in SRTP). Here it is just labelled the SRTP MAC. Sec 4.4.2: "...using the rollover counter from the current packet,..." -> "...using the rollover counter from the current context,..." Sec 4.5: It might be worth starting this section by discussing the applicability of authenticating RTCP receiver reports in large-scale multicast settings. Possibly referring to section 11.2 and other parts of the SRTP spec on the applicability and scalability of RTCP authentication in multicast. >>Sec 5. TESLA doesn't assume local clocks don't drift too much. Rather >>it requires a bound on clock drift to be known. >>Sec 7. "...an in the TESLA specification..." --> "...and in the TESLA >>specification..." >>Sec 7. "...noted that the all TESLA security..." sentence garbled. Cheers Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 30 13:52:03 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12698 for ; Mon, 30 Aug 2004 13:52:02 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AE8E78C9FF; Mon, 30 Aug 2004 13:52: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 A1C358C856 for ; Mon, 30 Aug 2004 13:52:00 -0400 (EDT) Received: (qmail 25591 invoked by uid 3269); 30 Aug 2004 17:52:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25575 invoked from network); 30 Aug 2004 17:52:00 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 30 Aug 2004 17:52:00 -0000 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn5-1054.cisco.com [10.21.92.30]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7UHo11k009319; Mon, 30 Aug 2004 10:50:02 -0700 (PDT) In-Reply-To: <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040818123555.03388d30@pop3.jungle.bt.co.uk> <5.2.1.1.2.20040829115918.01a5b5d8@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Mon, 30 Aug 2004 10:49:52 -0700 To: Bob Briscoe X-Mailer: Apple Mail (2.619) Cc: elisabetta.carrara@ericsson.com, 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 Bob, I reply to many of your points below, but here is something I'd like for you and your co-authors to consider: Apart from reusing the RTP timestamp field the issue you raise in point 3 is a general TESLA issue and not an SRTP-TESLA issue. I think this is also true for guidance on the use or non-use of a group MAC, which is related to your point 3. I'd like to see these points treated in a general way so why not critique the base TESLA spec on this point and not SRTP-TESLA? More below... On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: > ... > I'm not sure whether you're misunderstanding me, or just agreeing, but > sounding as if you disagree. In no way am I proposing anything that > doesn't do strong integrity checking. I understand that. > ... > Having thought about it, I will be stronger than the last mail and say > a group MAC will provide barely any additional protection in most > circumstances so should not be the default. The logic of using a group > MAC with TESLA looks like this: > > Sender's level of trust in group members not to spoof packets > | using a group key? | > Low High > | | > Use source authentication (ie TESLA). Use group > authentication. > | > TESLA is vulnerable to DoS filling buffer > until delayed auth > | > Use group authentication alongside TESLA > (as in current SRTP draft) > > I hope this diagram helps highlight the broken logic. > Group authentication is being MANDATED in the SRTP draft in a scenario > which only ever arises where the group isn't trusted. Trusted to do or not do what? I think in this case, "trusted" means "trusted not to launch a denial of service attack against the group." There is also "trusted not to capture a disclosed key to successfully impersonate a group sender." Further, there is "trusted not to disclose a group key" - and so on. Treating something as complicated as this as "high" or "low" is not persuading me, personally. > dding group authentication to TESLA only provides any additional value > for the narrow range of scenarios where group members aren't trusted > enough to use group authentication alone, but they are trusted > sufficiently that group authentication might detect some DoS attacks - > pretty slim odds. Worth allowing as an option, but surely not > MANDATING. You see a waste of time and bandwidth for protection that is superfluous. I see a relatively cheap way to keep a group protected against anyone running a kiddie script who decides to send a burst of packets and overflow members' buffers. Let's gather some more opinion from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. > ... > > I had thought about the ramifications fairly carefully before saying > this. I suggest that the way to deal with the TESLA time interval > identifier, I, is to: > - remove I from the default TESLA-SRTP packet format > - explain how to derive I from the RTP timestamp I may have confused you in my last note in trying to explain all the ways that I think overloading protocol fields for security purposes is generally not a good idea. Let me try to state this clearly: The RTP timestamp is used for specific purposes for RTP payload types that are unrelated to sender authentication, and it is quite possible that we will either interfere with these uses by placing TESLA-induced constraints on that field or weaken TESLA security when we find surprising uses are made of that field by certain applications. Re-use of the RTP Timestamp in TESLA can be easily avoided by adding a TESLA timetamp field in the packet. I think the points you are raising are important and helpful to SRTP-TESLA. But it would helpful if you separated them I think. Re-use of the RTP timestamp, the non-mandatory group MAC, and your proposal under point 3 can stand by themselves. I think we have 3 threads here and not one. > - MANDATE that a sender authentication module should use a TESLA key > interval derived from the RTP timestamp, not the clock > - warn implementors that any delay in the sender stack will add to the > TESLA authentication delay (but not weaken it) > - (if we can think of any other problems ) warn implementors what to > watch out for when overloading the RTP timestamp function (I'm fairly > sure there aren't any - and I've thought long and hard) I'd prefer to use a separate field. At minimum, I would take this to AVT for further discussion. I don't think the gain from overloading is worth any unexpected pitfalls, particularly security pitfalls. RTP is a special beast because it is used in so many types of applications, from telephony to client/server multimedia, from unicast-pairwise to unicast-group, small multicast conferences to large-scale broadcast, etc. > - make I optional in the TESLA-SRTP packet format for implementors to > use if they are in one of these obscure scenarios > > >>> If the sender buffers packets between adding the RTP timestamp and >>> adding TESLA authentication fields, this will add to the TESLA >>> authentication delay. But a good RTP implementation shouldn't be >>> doing >>> serious buffering here. >> >> What about high-bandwidth, server/playback media such as movies? In >> fact, let me try this: What about an MPEG packetizer that does a lot >> of pre-processing of the MPEG AUs prior to assigning them to packets. >> This might happen because the AUs were encrypted and required a lot of >> pre-processing. Maybe there would be a two-step process applied to >> one >> or more AUs in which timetamps are assigned during some processing and >> then everything gets sent. >> Maybe such a problem can be avoided in packetizers. There are a lot >> of >> considerations when we take an existing field such as the RTP >> timestamp >> and add new functions to it. > > As long as we mandate that the TESLA sender uses the key appropriate > to the time interval derived from the RTP timestamp (not from the > clock), the protocol is safe. The TESLA safety test is still accurate. > > Any delay after RTP has determined its timestamp then folds into the > delay between sender and receiver that TESLA is designed to handle > safely. Of course, this makes the delay longer, which /delays/ > authentication. But it doesn't /weaken/ authentication. See section 4 > of the TESLA intro for discussion of similar scenarios (eg TCP > buffering). > > If authentication delay is a problem for a particular scenario, and > it's some odd scenario like you suggest where a large part of the > delay is within the sender stack between RTP and TESLA, then the > implementor can choose to use an explicit I in the packet. TESLA is complex enough without adding protocol dependencies like this in my view. > >> If the functions are really identical, then they are redundant. I >> tend >> to doubt that. > > I'd rather say that the functions of the two fields are invariably > equivalent, but may not be in some scenarios, when it's up to the > implementor to use the option of an explicit I. This new option will double the signaling, implementation, testing, and operational complexity of the protocol. > > >>> 2/ Non-TESLA group authentication to protect against DoS should be >>> optional >>> --------------------------------------------------------------------- >>> -- ---- >>> The immediate authentication provided by your non-TESLA group >>> authentication only protects against DoS by non-group members. It >>> should be RECOMMENDED not REQUIRED (section 7). >> >> I think that this point should be resolved in the base TESLA >> specification, i.e. I don't think there is anything that is >> SRTP-specific to this point. But we did not treat it that way in >> SRTP-TESLA, and that's probably my fault. Nonetheless, I think it >> should be REQUIRED in base TESLA. > > Currently section 5 (security considerations) of the TESLA-intro > mentions group authentication as one possible way of preventing > flooding attacks during the key disclosure delay. But it doesn't > MANDATE it. I'm simply taking issue with group authentication being > MANDATED in SRTP-TESLA, as I don't think it's effective in many > (most?) scenarios, making it unnecessary overhead. > > I have no problem with making a group MAC optional for scenarios where > it does improve matters. I don't have a lot of religious fervor on the topic either though I like to avoid options in security protocols whenever possible. What seemed fairly obvious to me obviously seems wasteful to you. I'd like to discuss this further in a separate thread. We are really discussing a security requirement for protecting groups. > ... > > Sorry, history was a distracting word. I meant likelihood. Imagine a > video conf between senior execs of competing companies, or between > representatives of mutually distrusting governments. They don't trust > each other not to spoof what the other parties are saying, but they > have no likelihood of one launching a flooding attack on the other > (e.g. the whole thing is over a joint VPN). They need group > authentication like a phish needs a bicycle. So why MANDATE it? We are beating this to death and confusing one another. The participants would not launch the flooding attack; an interloper would do it. If it's over a VPN, then the attack seems very unlikely - as is source spoofing in a small teleconference, for that matter. > ... > >> relies upon the fact that memory gets tied up while >> packets are buffered awaiting authentication. In this case, there is >> no buffering of multiple packets, just one packet during the >> disclosure >> interval. Do I understand you correctly? > > No. The disclosure *interval* (delay) still spans multiple packets. > The new feature depends on each key now only ever being *disclosed* > once, rather than the same key being disclosed repeatedly as it was > when there were multiple packets in the same TESLA time interval. Before we go any further into this, I'd like to understand why this disclosure scheme needs to be considered only for SRTP. You mention below that you also think that it belongs in the base TESLA specification and that you have raised the issue with your co-authors? I think the TESLA co-authors might want to consider discussing this on the list. That sounds better than treating SRTP-TESLA as the poster child for something that was maybe overlooked in the base TESLA document. I just got back from some personal time off and am working through several hundred messages - I prioritized yours. It would be a more efficient discussion to discuss this with the TESLA authors - on the msec list if possible. > > As soon as a packet arrives, the disclosed key in it now has two > purposes: > - it's original TESLA purpose: to verify a packet received some time > previously > - to immediately show the receiver that the sender of this packet knew > the next key back along the hash chain which is now only ever > *disclosed* once > > So if more packets are received that *disclose* the same key, the > receiver can assume (at least until the delayed TESLA verification) > that only the first packet to disclose each key was genuine. > > If a network element is compromised, an attacker can discover the next > disclosed key and overtake or replace a genuine packet with many > others. But the receiver can still immediately discard all but the > first to arrive, protecting itself from memory overflow. > > So the scheme has the following properties: > - The receiver will never buffer more than one packet per packet sent > by the genuine sender (so the receiver's buffer fill rate is still > clocked by the party that reveals each new key backwards in the > chain). > - As each key is later disclosed, TESLA can do delayed verification of > these stored packets. > - if they pass delayed verfication, the messages must be genuine > - if they fail delayed verfication, the messages must not have been > genuine > - The true message will have been lost in the latter case. But, then > if an attacker can compromise a network element, it can discard the > true messages anyway (a group MAC can't prevent this either ;) > > I need to fully document this. There are some corner cases not covered > by the above. I've given an outline later. Obviously, this DoS > protection idea hasn't had the same peer-review as TESLA, except it is > essentially just S/KEY, which has had ample peer review (but perhaps > not in a group setting). This sounds promising to me, but I would like to see the document - I have not read the one you sent me yet. And I would like to hear what the other TESLA authors have to say about it. > > ... >> If so, why >> not put this in the core TESLA specification. I'd say that if it >> belongs in SRTP-TESLA, then it belongs in the core specification. No? > > You are absolutely correct. > > We (the co-authors of the TESLA base spec) are discussing this > off-line right now. It's my fault we didn't reach closure on it before > TESLA got this far. I was originally pushing this as an option, but I > think I never quite got myself understood. Somewhere in the mists of > time I gave up. I've been taking a back seat on the TESLA work until > just recently, so my brain obviously wasn't in gear when reviewing > drafts. I forgot I'd got this option to attack the DoS problem. It was > only through reveiwing the SRTP draft that the technique came back to > me. Now, the more I argue about it, the better I think it is. > > However, it's not out of the woods yet. My co-authors are trying to > break it. I believe I've defended it in the case of variable packet > rate and packet misordering. But I'm expecting more attempts to break > it (and, of course, anyone on this list is welcome to try as well). > > If it comes out intact, you should see text on it shortly. Otherwise, > I guess the TESLA base spec will stay as it is. And this sizable email exchange would be in vain :?) > > ... >>> BTW, it should be pointed out that the verification algo should check >>> the key index is within an expected range before using it (e.g. only >>> a >>> small increment above the last highest verified key index seen). >>> Otherwise, an attacker can tamper with this field to lead all >>> receivers to run millions of hash operations unnecessarily. I prefer >>> to call it a key-index *hint*, to remind me not to rely on it being >>> correct. >> >> This sounds like an argument for keeping the MAC. > > No. It is an argument for watching that it doesn't appear to imply > packets are extremely re-ordered (e.g. it must be no more than, say, > 64 different from the previous highest index, cf the SRTP replay > protection window). You /could/ use a group MAC to do an initial test > of its integrity, but why waste 10 octets when you can do a test that > uses none? And this would only work if you trusted the group members > (recall, we are using TESLA because we don't trust them). The group MAC was originally 4 bytes and I need to check with Elisabetta to find out why it is now 10. I don't see why it needs to be larger than 4 bytes for group MAC purposes. If we manage to obviate the need for group MACs in TESLA, then it can be zero bytes and I'll be perfectly happy. > > The key index is implicitly authenticated (similar to the implicit > header authentication in section 9.5.2 of the SRTP RFC) because the > TESLA MAC depends on it. If the key index is tampered with, the > authentication test will fail as it should. Ok. > > ... >> >> We'll refer to your editorial comments at the next revision. > > I've added a couple more below... Good. How do you feel about my proposal to consider the proposed use of the RTP timestamp field separately from the group MAC. And treat the group MAC as a related question to your point 3 scheme? thanks, Mark > >> thanks, Mark > > And many thanks to you too, for doing all the hard work on these > drafts. > > more comments follow... > > >>> Nits >>> ==== >>> A general point of style: I found the spec had too much 'knitting >>> together by reference' from other specs. As Ran said in an earlier >>> posting, it needs at least some sketching of what is referred to. >>> Otherwise it is unlikely to lead to safe standardisation of >>> implementations. Particularly given that the references themselves >>> are >>> evolving, it becomes unsafe to expect people to find discrepancies >>> when reviewing this draft by re-reading the latest drafts of the >>> other >>> specs each time. Sections 4.4. & 4.4.1 were particular culprits. >>> However, I also have some sympathy with the view that duplication of >>> parts of specs in other specs can lead to inconsistency. > > The particular point was that the TESLA delay safety test is missing > from 4.4.2, but strictly you have said it must be done earlier (in > 4.4) by referring to the TESLA-intro. I think it should be in the list > of things the receiver should do. > > >>> Throughout: To be consistent with the TESLA intro, the time-slot >>> index, I, should be i (lower case). > > I now realise that lower case i would conflict with the SRTP spec. > >>> Sec 2. "...may often used..." --> "...may often be used..." >>> Sec 3. "This specification assumes that the reader is familiar with >>> TESLA" repeats the same sentence in Sec 1.1. >>> Sec 3. TESLA synch protocol & initial bootstrapping outside scope, >>> but >>> presumably you will include a ref once one is available. >>> Sec 4. "...and the delayed-authentication TESLA elements of procedure >>> [TESLA]." Garbled sentence? >>> Sec 4.1 "showed" --> "shown" >>> Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." > > Sec 4.3 bullet 10, uses same n_c notation as bullet 2 (but for > something else) > >>> Sec 4.4 "If the safe condition does not hold,..." add "...and the >>> event SHOULD be logged." > > Sec 4.4.2: "...perform verification of the SRTP integrity protection > tag..." this terminology hasn't been used in this draft (it was in > SRTP). Here it is just labelled the SRTP MAC. > Sec 4.4.2: "...using the rollover counter from the current packet,..." > -> "...using the rollover counter from the current context,..." > Sec 4.5: It might be worth starting this section by discussing the > applicability of authenticating RTCP receiver reports in large-scale > multicast settings. Possibly referring to section 11.2 and other parts > of the SRTP spec on the applicability and scalability of RTCP > authentication in multicast. > >>> Sec 5. TESLA doesn't assume local clocks don't drift too much. Rather >>> it requires a bound on clock drift to be known. >>> Sec 7. "...an in the TESLA specification..." --> "...and in the TESLA >>> specification..." >>> Sec 7. "...noted that the all TESLA security..." sentence garbled. > > > Cheers > > > > Bob > > > _______________________________________________________________________ > _____ > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT > plc. > _______________________________________________________________________ > _____ > Bob Briscoe, Networks Research Centre, BT > Research > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > _______________________________________________ > 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 Aug 30 14:41:08 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15565 for ; Mon, 30 Aug 2004 14:41:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E36A48C8B3; Mon, 30 Aug 2004 14:41:08 -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 93C7D8CA59 for ; Mon, 30 Aug 2004 14:41:07 -0400 (EDT) Received: (qmail 34532 invoked by uid 3269); 30 Aug 2004 18:41:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34529 invoked from network); 30 Aug 2004 18:41:06 -0000 Received: from mgw-x3.nokia.com (131.228.20.26) by klesh.pair.com with SMTP; 30 Aug 2004 18:41:06 -0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UIf4S04273; Mon, 30 Aug 2004 21:41:04 +0300 (EET DST) X-Scanned: Mon, 30 Aug 2004 21:40:10 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7UIeAUc027142; Mon, 30 Aug 2004 21:40:10 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00TsFHk6; Mon, 30 Aug 2004 21:40:09 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7UIe7Y25472; Mon, 30 Aug 2004 21:40:07 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 30 Aug 2004 13:39:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Mon, 30 Aug 2004 14:39:10 -0400 Message-ID: Thread-Topic: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Thread-Index: AcSOujYAsdU1Nch8SIav+m8zQCSRxwAA8IQg From: To: , X-OriginalArrivalTime: 30 Aug 2004 18:39:11.0646 (UTC) FILETIME=[A46983E0:01C48EC0] Cc: elisabetta.carrara@ericsson.com, 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 Just trying to understand from confusing inlining.... One of the high order bits of the discussion is the question: Should Group-MAC, to provide group authentication and prevent DoS attacks from outside the group, be MANDATED or NOT? and the related question: The base TESLA intro draft does not mandate it, how come SRTP-TESLA draft is mandating it? Thinking out loud, mandating Group-MAC has the advantage of less = interoperability woes. On the flip side making it optional has the advantage of saving = byte-overhead per packet and a bit of computation time, when Group-MAC is not used. = Mark, points out extra space needed should actually be 4 bytes as opposed to 10 bytes = mentioned in the SRTP-TESLA draft. Since presence of Group-MAC can be a group policy, which in the case of = Multicast security is enforced rather than negotiated, I would guess = interoperability issues should not crop up. So making it optional may not actually lead to = interoperability woes. What do other members on MSEC mailing list think? Mandate or not Mandate = Group-MAC in the base TESLA protocol? IMHO, Once we decide that, we can talk about = what to do in SRTP-TESLA, if at all any different. Best, Atul > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Mark Baugher > Sent: Monday, August 30, 2004 1:50 PM > To: Bob Briscoe > Cc: elisabetta.carrara@ericsson.com; msec@securemulticast.org > Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) >=20 >=20 > Bob, > I reply to many of your points below, but here is=20 > something I'd like =20 > for you and your co-authors to consider: Apart from reusing the RTP =20 > timestamp field the issue you raise in point 3 is a general=20 > TESLA issue =20 > and not an SRTP-TESLA issue. I think this is also true for=20 > guidance on =20 > the use or non-use of a group MAC, which is related to your=20 > point 3. =20 > I'd like to see these points treated in a general way so why not =20 > critique the base TESLA spec on this point and not SRTP-TESLA? >=20 > More below... > On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: > > > ... > > I'm not sure whether you're misunderstanding me, or just=20 > agreeing, but =20 > > sounding as if you disagree. In no way am I proposing=20 > anything that =20 > > doesn't do strong integrity checking. >=20 > I understand that. >=20 > > > ... > > Having thought about it, I will be stronger than the last=20 > mail and say =20 > > a group MAC will provide barely any additional protection in most =20 > > circumstances so should not be the default. The logic of=20 > using a group =20 > > MAC with TESLA looks like this: > > > > Sender's level of trust in group members not to spoof packets > > | using a group key? | > > Low High > > | | > > Use source authentication (ie TESLA). Use group =20 > > authentication. > > | > > TESLA is vulnerable to DoS filling buffer > > until delayed auth > > | > > Use group authentication alongside TESLA > > (as in current SRTP draft) > > > > I hope this diagram helps highlight the broken logic. > > Group authentication is being MANDATED in the SRTP draft in=20 > a scenario =20 > > which only ever arises where the group isn't trusted. >=20 > Trusted to do or not do what? I think in this case, "trusted" means =20 > "trusted not to launch a denial of service attack against the=20 > group." =20 > There is also "trusted not to capture a disclosed key to=20 > successfully =20 > impersonate a group sender." Further, there is "trusted not to =20 > disclose a group key" - and so on. Treating something as=20 > complicated =20 > as this as "high" or "low" is not persuading me, personally. >=20 > > dding group authentication to TESLA only provides any=20 > additional value =20 > > for the narrow range of scenarios where group members=20 > aren't trusted =20 > > enough to use group authentication alone, but they are trusted =20 > > sufficiently that group authentication might detect some=20 > DoS attacks - =20 > > pretty slim odds. Worth allowing as an option, but surely not =20 > > MANDATING. >=20 > You see a waste of time and bandwidth for protection that is =20 > superfluous. I see a relatively cheap way to keep a group protected =20 > against anyone running a kiddie script who decides to send a=20 > burst of =20 > packets and overflow members' buffers. Let's gather some=20 > more opinion =20 > from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. > > > ... > > > > I had thought about the ramifications fairly carefully=20 > before saying =20 > > this. I suggest that the way to deal with the TESLA time interval =20 > > identifier, I, is to: > > - remove I from the default TESLA-SRTP packet format > > - explain how to derive I from the RTP timestamp >=20 > I may have confused you in my last note in trying to explain all the =20 > ways that I think overloading protocol fields for security=20 > purposes is =20 > generally not a good idea. Let me try to state this clearly:=20 > The RTP =20 > timestamp is used for specific purposes for RTP payload types=20 > that are =20 > unrelated to sender authentication, and it is quite possible that we =20 > will either interfere with these uses by placing TESLA-induced =20 > constraints on that field or weaken TESLA security when we find =20 > surprising uses are made of that field by certain applications. >=20 > Re-use of the RTP Timestamp in TESLA can be easily avoided by=20 > adding a =20 > TESLA timetamp field in the packet. I think the points you=20 > are raising =20 > are important and helpful to SRTP-TESLA. But it would=20 > helpful if you =20 > separated them I think. Re-use of the RTP timestamp, the=20 > non-mandatory =20 > group MAC, and your proposal under point 3 can stand by=20 > themselves. I =20 > think we have 3 threads here and not one. >=20 > > - MANDATE that a sender authentication module should use a=20 > TESLA key =20 > > interval derived from the RTP timestamp, not the clock > > - warn implementors that any delay in the sender stack will=20 > add to the =20 > > TESLA authentication delay (but not weaken it) > > - (if we can think of any other problems ) warn=20 > implementors what to =20 > > watch out for when overloading the RTP timestamp function=20 > (I'm fairly =20 > > sure there aren't any - and I've thought long and hard) >=20 > I'd prefer to use a separate field. At minimum, I would take=20 > this to =20 > AVT for further discussion. I don't think the gain from=20 > overloading is =20 > worth any unexpected pitfalls, particularly security=20 > pitfalls. RTP is =20 > a special beast because it is used in so many types of applications, =20 > from telephony to client/server multimedia, from unicast-pairwise to =20 > unicast-group, small multicast conferences to large-scale broadcast, =20 > etc. >=20 > > - make I optional in the TESLA-SRTP packet format for=20 > implementors to =20 > > use if they are in one of these obscure scenarios > > > > > >>> If the sender buffers packets between adding the RTP timestamp and > >>> adding TESLA authentication fields, this will add to the TESLA > >>> authentication delay. But a good RTP implementation shouldn't be =20 > >>> doing > >>> serious buffering here. > >> > >> What about high-bandwidth, server/playback media such as=20 > movies? In > >> fact, let me try this: What about an MPEG packetizer that=20 > does a lot > >> of pre-processing of the MPEG AUs prior to assigning them=20 > to packets. > >> This might happen because the AUs were encrypted and=20 > required a lot of > >> pre-processing. Maybe there would be a two-step process=20 > applied to =20 > >> one > >> or more AUs in which timetamps are assigned during some=20 > processing and > >> then everything gets sent. > >> Maybe such a problem can be avoided in packetizers. There=20 > are a lot =20 > >> of > >> considerations when we take an existing field such as the RTP =20 > >> timestamp > >> and add new functions to it. > > > > As long as we mandate that the TESLA sender uses the key=20 > appropriate =20 > > to the time interval derived from the RTP timestamp (not from the =20 > > clock), the protocol is safe. The TESLA safety test is=20 > still accurate. > > > > Any delay after RTP has determined its timestamp then folds=20 > into the =20 > > delay between sender and receiver that TESLA is designed to handle =20 > > safely. Of course, this makes the delay longer, which /delays/ =20 > > authentication. But it doesn't /weaken/ authentication. See=20 > section 4 =20 > > of the TESLA intro for discussion of similar scenarios (eg TCP =20 > > buffering). > > > > If authentication delay is a problem for a particular=20 > scenario, and =20 > > it's some odd scenario like you suggest where a large part of the =20 > > delay is within the sender stack between RTP and TESLA, then the =20 > > implementor can choose to use an explicit I in the packet. >=20 > TESLA is complex enough without adding protocol dependencies=20 > like this =20 > in my view. >=20 > > > >> If the functions are really identical, then they are=20 > redundant. I =20 > >> tend > >> to doubt that. > > > > I'd rather say that the functions of the two fields are invariably =20 > > equivalent, but may not be in some scenarios, when it's up to the =20 > > implementor to use the option of an explicit I. >=20 > This new option will double the signaling, implementation,=20 > testing, and =20 > operational complexity of the protocol. > > > > > >>> 2/ Non-TESLA group authentication to protect against DoS should be > >>> optional > >>>=20 > ---------------------------------------------------------------------=20 > >>> -- ---- > >>> The immediate authentication provided by your non-TESLA group > >>> authentication only protects against DoS by non-group members. It > >>> should be RECOMMENDED not REQUIRED (section 7). > >> > >> I think that this point should be resolved in the base TESLA > >> specification, i.e. I don't think there is anything that is > >> SRTP-specific to this point. But we did not treat it that way in > >> SRTP-TESLA, and that's probably my fault. Nonetheless, I think it > >> should be REQUIRED in base TESLA. > > > > Currently section 5 (security considerations) of the TESLA-intro =20 > > mentions group authentication as one possible way of preventing =20 > > flooding attacks during the key disclosure delay. But it doesn't =20 > > MANDATE it. I'm simply taking issue with group=20 > authentication being =20 > > MANDATED in SRTP-TESLA, as I don't think it's effective in many =20 > > (most?) scenarios, making it unnecessary overhead. > > > > I have no problem with making a group MAC optional for=20 > scenarios where =20 > > it does improve matters. >=20 > I don't have a lot of religious fervor on the topic either though I =20 > like to avoid options in security protocols whenever possible. What =20 > seemed fairly obvious to me obviously seems wasteful to you. =20 > I'd like =20 > to discuss this further in a separate thread. We are really=20 > discussing =20 > a security requirement for protecting groups. > > > ... >=20 > > > > Sorry, history was a distracting word. I meant likelihood.=20 > Imagine a =20 > > video conf between senior execs of competing companies, or between =20 > > representatives of mutually distrusting governments. They=20 > don't trust =20 > > each other not to spoof what the other parties are saying,=20 > but they =20 > > have no likelihood of one launching a flooding attack on the other =20 > > (e.g. the whole thing is over a joint VPN). They need group =20 > > authentication like a phish needs a bicycle. So why MANDATE it? >=20 > We are beating this to death and confusing one another. The =20 > participants would not launch the flooding attack; an=20 > interloper would =20 > do it. If it's over a VPN, then the attack seems very=20 > unlikely - as is =20 > source spoofing in a small teleconference, for that matter. > > > ... > > > >> relies upon the fact that memory gets tied up while > >> packets are buffered awaiting authentication. In this=20 > case, there is > >> no buffering of multiple packets, just one packet during the =20 > >> disclosure > >> interval. Do I understand you correctly? > > > > No. The disclosure *interval* (delay) still spans multiple=20 > packets. =20 > > The new feature depends on each key now only ever being=20 > *disclosed* =20 > > once, rather than the same key being disclosed repeatedly=20 > as it was =20 > > when there were multiple packets in the same TESLA time interval. >=20 > Before we go any further into this, I'd like to understand why this =20 > disclosure scheme needs to be considered only for SRTP. You mention =20 > below that you also think that it belongs in the base TESLA =20 > specification and that you have raised the issue with your=20 > co-authors? =20 > I think the TESLA co-authors might want to consider=20 > discussing this on =20 > the list. That sounds better than treating SRTP-TESLA as the poster =20 > child for something that was maybe overlooked in the base TESLA =20 > document. >=20 > I just got back from some personal time off and am working through =20 > several hundred messages - I prioritized yours. It would be a more =20 > efficient discussion to discuss this with the TESLA authors - on the =20 > msec list if possible. >=20 > > > > As soon as a packet arrives, the disclosed key in it now has two =20 > > purposes: > > - it's original TESLA purpose: to verify a packet received=20 > some time =20 > > previously > > - to immediately show the receiver that the sender of this=20 > packet knew =20 > > the next key back along the hash chain which is now only ever =20 > > *disclosed* once > > > > So if more packets are received that *disclose* the same key, the =20 > > receiver can assume (at least until the delayed TESLA=20 > verification) =20 > > that only the first packet to disclose each key was genuine. > > > > If a network element is compromised, an attacker can=20 > discover the next =20 > > disclosed key and overtake or replace a genuine packet with many =20 > > others. But the receiver can still immediately discard all but the =20 > > first to arrive, protecting itself from memory overflow. > > > > So the scheme has the following properties: > > - The receiver will never buffer more than one packet per=20 > packet sent =20 > > by the genuine sender (so the receiver's buffer fill rate is still =20 > > clocked by the party that reveals each new key backwards in the =20 > > chain). > > - As each key is later disclosed, TESLA can do delayed=20 > verification of =20 > > these stored packets. > > - if they pass delayed verfication, the messages must be genuine > > - if they fail delayed verfication, the messages must not=20 > have been =20 > > genuine > > - The true message will have been lost in the latter case.=20 > But, then =20 > > if an attacker can compromise a network element, it can=20 > discard the =20 > > true messages anyway (a group MAC can't prevent this either ;) > > > > I need to fully document this. There are some corner cases=20 > not covered =20 > > by the above. I've given an outline later. Obviously, this DoS =20 > > protection idea hasn't had the same peer-review as TESLA,=20 > except it is =20 > > essentially just S/KEY, which has had ample peer review=20 > (but perhaps =20 > > not in a group setting). >=20 > This sounds promising to me, but I would like to see the=20 > document - I =20 > have not read the one you sent me yet. And I would like to=20 > hear what =20 > the other TESLA authors have to say about it. > > > > >=20 > ... > >> If so, why > >> not put this in the core TESLA specification. I'd say that if it > >> belongs in SRTP-TESLA, then it belongs in the core=20 > specification. No? > > > > You are absolutely correct. > > > > We (the co-authors of the TESLA base spec) are discussing this =20 > > off-line right now. It's my fault we didn't reach closure=20 > on it before =20 > > TESLA got this far. I was originally pushing this as an=20 > option, but I =20 > > think I never quite got myself understood. Somewhere in the=20 > mists of =20 > > time I gave up. I've been taking a back seat on the TESLA=20 > work until =20 > > just recently, so my brain obviously wasn't in gear when reviewing =20 > > drafts. I forgot I'd got this option to attack the DoS=20 > problem. It was =20 > > only through reveiwing the SRTP draft that the technique=20 > came back to =20 > > me. Now, the more I argue about it, the better I think it is. > > > > However, it's not out of the woods yet. My co-authors are=20 > trying to =20 > > break it. I believe I've defended it in the case of=20 > variable packet =20 > > rate and packet misordering. But I'm expecting more=20 > attempts to break =20 > > it (and, of course, anyone on this list is welcome to try as well). > > > > If it comes out intact, you should see text on it shortly.=20 > Otherwise, =20 > > I guess the TESLA base spec will stay as it is. >=20 > And this sizable email exchange would be in vain :?) > > > > >=20 > ... > >>> BTW, it should be pointed out that the verification algo=20 > should check > >>> the key index is within an expected range before using it=20 > (e.g. only =20 > >>> a > >>> small increment above the last highest verified key index seen). > >>> Otherwise, an attacker can tamper with this field to lead all > >>> receivers to run millions of hash operations=20 > unnecessarily. I prefer > >>> to call it a key-index *hint*, to remind me not to rely=20 > on it being > >>> correct. > >> > >> This sounds like an argument for keeping the MAC. > > > > No. It is an argument for watching that it doesn't appear to imply =20 > > packets are extremely re-ordered (e.g. it must be no more=20 > than, say, =20 > > 64 different from the previous highest index, cf the SRTP replay =20 > > protection window). You /could/ use a group MAC to do an=20 > initial test =20 > > of its integrity, but why waste 10 octets when you can do a=20 > test that =20 > > uses none? And this would only work if you trusted the=20 > group members =20 > > (recall, we are using TESLA because we don't trust them). >=20 > The group MAC was originally 4 bytes and I need to check with =20 > Elisabetta to find out why it is now 10. I don't see why it=20 > needs to =20 > be larger than 4 bytes for group MAC purposes. If we manage=20 > to obviate =20 > the need for group MACs in TESLA, then it can be zero bytes=20 > and I'll be =20 > perfectly happy. > > > > The key index is implicitly authenticated (similar to the implicit =20 > > header authentication in section 9.5.2 of the SRTP RFC)=20 > because the =20 > > TESLA MAC depends on it. If the key index is tampered with, the =20 > > authentication test will fail as it should. >=20 > Ok. > > > > > ... > >> > >> We'll refer to your editorial comments at the next revision. > > > > I've added a couple more below... >=20 > Good. How do you feel about my proposal to consider the=20 > proposed use =20 > of the RTP timestamp field separately from the group MAC. And treat =20 > the group MAC as a related question to your point 3 scheme? >=20 > thanks, Mark > > > >> thanks, Mark > > > > And many thanks to you too, for doing all the hard work on these =20 > > drafts. > > > > more comments follow... > > > > > >>> Nits > >>> =3D=3D=3D=3D > >>> A general point of style: I found the spec had too much 'knitting > >>> together by reference' from other specs. As Ran said in an earlier > >>> posting, it needs at least some sketching of what is referred to. > >>> Otherwise it is unlikely to lead to safe standardisation of > >>> implementations. Particularly given that the references=20 > themselves =20 > >>> are > >>> evolving, it becomes unsafe to expect people to find discrepancies > >>> when reviewing this draft by re-reading the latest drafts of the =20 > >>> other > >>> specs each time. Sections 4.4. & 4.4.1 were particular culprits. > >>> However, I also have some sympathy with the view that=20 > duplication of > >>> parts of specs in other specs can lead to inconsistency. > > > > The particular point was that the TESLA delay safety test=20 > is missing =20 > > from 4.4.2, but strictly you have said it must be done earlier (in =20 > > 4.4) by referring to the TESLA-intro. I think it should be=20 > in the list =20 > > of things the receiver should do. > > > > > >>> Throughout: To be consistent with the TESLA intro, the time-slot > >>> index, I, should be i (lower case). > > > > I now realise that lower case i would conflict with the SRTP spec. > > > >>> Sec 2. "...may often used..." --> "...may often be used..." > >>> Sec 3. "This specification assumes that the reader is=20 > familiar with > >>> TESLA" repeats the same sentence in Sec 1.1. > >>> Sec 3. TESLA synch protocol & initial bootstrapping=20 > outside scope, =20 > >>> but > >>> presumably you will include a ref once one is available. > >>> Sec 4. "...and the delayed-authentication TESLA elements=20 > of procedure > >>> [TESLA]." Garbled sentence? > >>> Sec 4.1 "showed" --> "shown" > >>> Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." > > > > Sec 4.3 bullet 10, uses same n_c notation as bullet 2 (but for =20 > > something else) > > > >>> Sec 4.4 "If the safe condition does not hold,..." add "...and the > >>> event SHOULD be logged." > > > > Sec 4.4.2: "...perform verification of the SRTP integrity=20 > protection =20 > > tag..." this terminology hasn't been used in this draft (it was in =20 > > SRTP). Here it is just labelled the SRTP MAC. > > Sec 4.4.2: "...using the rollover counter from the current=20 > packet,..." =20 > > -> "...using the rollover counter from the current context,..." > > Sec 4.5: It might be worth starting this section by discussing the =20 > > applicability of authenticating RTCP receiver reports in=20 > large-scale =20 > > multicast settings. Possibly referring to section 11.2 and=20 > other parts =20 > > of the SRTP spec on the applicability and scalability of RTCP =20 > > authentication in multicast. > > > >>> Sec 5. TESLA doesn't assume local clocks don't drift too=20 > much. Rather > >>> it requires a bound on clock drift to be known. > >>> Sec 7. "...an in the TESLA specification..." --> "...and=20 > in the TESLA > >>> specification..." > >>> Sec 7. "...noted that the all TESLA security..." sentence garbled. > > > > > > Cheers > > > > > > > > Bob > > > > > >=20 > ______________________________________________________________ > _________=20 > > _____ > > Notice: This contribution is the personal view of the=20 > author and does =20 > > not necessarily reflect the technical nor commercial=20 > direction of BT =20 > > plc. > >=20 > ______________________________________________________________ > _________=20 > > _____ > > Bob Briscoe, Networks Research=20 > Centre, BT =20 > > Research > > B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. =20 > +44 1473 =20 > > 645196 > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 30 16:00:33 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21900 for ; Mon, 30 Aug 2004 16:00:31 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1460E8C62B; Mon, 30 Aug 2004 16:00: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 0D25F8C5DC for ; Mon, 30 Aug 2004 16:00:09 -0400 (EDT) Received: (qmail 50052 invoked by uid 3269); 30 Aug 2004 20:00:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50049 invoked from network); 30 Aug 2004 20:00:08 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 30 Aug 2004 20:00:08 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 30 Aug 2004 13:00:14 -0700 X-BrightmailFiltered: true Received: from [192.168.0.10] (sjc-vpn5-528.cisco.com [10.21.90.16]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7UK05Xw021952 for ; Mon, 30 Aug 2004 13:00:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C0FDBFB-FABF-11D8-A596-000A95DC10F2@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Mon, 30 Aug 2004 12:59:59 -0700 To: msec@securemulticast.org X-Mailer: Apple Mail (2.619) 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 Thanks for the summary. There is also the point about re-using the RTP timestamp in place of the TESLA key identifier. And Bob has proposed a way to obviate the need for a group MAC with a TESLA innovation that his co-authors are considering. Even if Bob's idea is accepted, the discussion on whether or not to mandate group authentication in a TESLA protocol is probably time well spent. Mark On Aug 30, 2004, at 11:39 AM, wrote: > > Just trying to understand from confusing inlining.... > > One of the high order bits of the discussion is the question: > > Should Group-MAC, to provide group authentication and prevent > DoS attacks from outside the group, be MANDATED or NOT? > > and the related question: > > The base TESLA intro draft does not mandate it, how come > SRTP-TESLA draft is mandating it? > > Thinking out loud, mandating Group-MAC has the advantage of less > interoperability > woes. On the flip side making it optional has the advantage of saving > byte-overhead > per packet and a bit of computation time, when Group-MAC is not used. > Mark, points > out extra space needed should actually be 4 bytes as opposed to 10 > bytes mentioned > in the SRTP-TESLA draft. > > Since presence of Group-MAC can be a group policy, which in the case > of Multicast > security is enforced rather than negotiated, I would guess > interoperability issues > should not crop up. So making it optional may not actually lead to > interoperability > woes. > > What do other members on MSEC mailing list think? Mandate or not > Mandate Group-MAC > in the base TESLA protocol? IMHO, Once we decide that, we can talk > about what to do > in SRTP-TESLA, if at all any different. > > Best, > Atul > >> -----Original Message----- >> From: msec-bounces@securemulticast.org >> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Mark Baugher >> Sent: Monday, August 30, 2004 1:50 PM >> To: Bob Briscoe >> Cc: elisabetta.carrara@ericsson.com; msec@securemulticast.org >> Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) >> >> >> Bob, >> I reply to many of your points below, but here is >> something I'd like >> for you and your co-authors to consider: Apart from reusing the RTP >> timestamp field the issue you raise in point 3 is a general >> TESLA issue >> and not an SRTP-TESLA issue. I think this is also true for >> guidance on >> the use or non-use of a group MAC, which is related to your >> point 3. >> I'd like to see these points treated in a general way so why not >> critique the base TESLA spec on this point and not SRTP-TESLA? >> >> More below... >> On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: >>> >> ... >>> I'm not sure whether you're misunderstanding me, or just >> agreeing, but >>> sounding as if you disagree. In no way am I proposing >> anything that >>> doesn't do strong integrity checking. >> >> I understand that. >> >>> >> ... >>> Having thought about it, I will be stronger than the last >> mail and say >>> a group MAC will provide barely any additional protection in most >>> circumstances so should not be the default. The logic of >> using a group >>> MAC with TESLA looks like this: >>> >>> Sender's level of trust in group members not to spoof packets >>> | using a group key? | >>> Low High >>> | | >>> Use source authentication (ie TESLA). Use group >>> authentication. >>> | >>> TESLA is vulnerable to DoS filling buffer >>> until delayed auth >>> | >>> Use group authentication alongside TESLA >>> (as in current SRTP draft) >>> >>> I hope this diagram helps highlight the broken logic. >>> Group authentication is being MANDATED in the SRTP draft in >> a scenario >>> which only ever arises where the group isn't trusted. >> >> Trusted to do or not do what? I think in this case, "trusted" means >> "trusted not to launch a denial of service attack against the >> group." >> There is also "trusted not to capture a disclosed key to >> successfully >> impersonate a group sender." Further, there is "trusted not to >> disclose a group key" - and so on. Treating something as >> complicated >> as this as "high" or "low" is not persuading me, personally. >> >>> dding group authentication to TESLA only provides any >> additional value >>> for the narrow range of scenarios where group members >> aren't trusted >>> enough to use group authentication alone, but they are trusted >>> sufficiently that group authentication might detect some >> DoS attacks - >>> pretty slim odds. Worth allowing as an option, but surely not >>> MANDATING. >> >> You see a waste of time and bandwidth for protection that is >> superfluous. I see a relatively cheap way to keep a group protected >> against anyone running a kiddie script who decides to send a >> burst of >> packets and overflow members' buffers. Let's gather some >> more opinion >> from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. >>> >> ... >>> >>> I had thought about the ramifications fairly carefully >> before saying >>> this. I suggest that the way to deal with the TESLA time interval >>> identifier, I, is to: >>> - remove I from the default TESLA-SRTP packet format >>> - explain how to derive I from the RTP timestamp >> >> I may have confused you in my last note in trying to explain all the >> ways that I think overloading protocol fields for security >> purposes is >> generally not a good idea. Let me try to state this clearly: >> The RTP >> timestamp is used for specific purposes for RTP payload types >> that are >> unrelated to sender authentication, and it is quite possible that we >> will either interfere with these uses by placing TESLA-induced >> constraints on that field or weaken TESLA security when we find >> surprising uses are made of that field by certain applications. >> >> Re-use of the RTP Timestamp in TESLA can be easily avoided by >> adding a >> TESLA timetamp field in the packet. I think the points you >> are raising >> are important and helpful to SRTP-TESLA. But it would >> helpful if you >> separated them I think. Re-use of the RTP timestamp, the >> non-mandatory >> group MAC, and your proposal under point 3 can stand by >> themselves. I >> think we have 3 threads here and not one. >> >>> - MANDATE that a sender authentication module should use a >> TESLA key >>> interval derived from the RTP timestamp, not the clock >>> - warn implementors that any delay in the sender stack will >> add to the >>> TESLA authentication delay (but not weaken it) >>> - (if we can think of any other problems ) warn >> implementors what to >>> watch out for when overloading the RTP timestamp function >> (I'm fairly >>> sure there aren't any - and I've thought long and hard) >> >> I'd prefer to use a separate field. At minimum, I would take >> this to >> AVT for further discussion. I don't think the gain from >> overloading is >> worth any unexpected pitfalls, particularly security >> pitfalls. RTP is >> a special beast because it is used in so many types of applications, >> from telephony to client/server multimedia, from unicast-pairwise to >> unicast-group, small multicast conferences to large-scale broadcast, >> etc. >> >>> - make I optional in the TESLA-SRTP packet format for >> implementors to >>> use if they are in one of these obscure scenarios >>> >>> >>>>> If the sender buffers packets between adding the RTP timestamp and >>>>> adding TESLA authentication fields, this will add to the TESLA >>>>> authentication delay. But a good RTP implementation shouldn't be >>>>> doing >>>>> serious buffering here. >>>> >>>> What about high-bandwidth, server/playback media such as >> movies? In >>>> fact, let me try this: What about an MPEG packetizer that >> does a lot >>>> of pre-processing of the MPEG AUs prior to assigning them >> to packets. >>>> This might happen because the AUs were encrypted and >> required a lot of >>>> pre-processing. Maybe there would be a two-step process >> applied to >>>> one >>>> or more AUs in which timetamps are assigned during some >> processing and >>>> then everything gets sent. >>>> Maybe such a problem can be avoided in packetizers. There >> are a lot >>>> of >>>> considerations when we take an existing field such as the RTP >>>> timestamp >>>> and add new functions to it. >>> >>> As long as we mandate that the TESLA sender uses the key >> appropriate >>> to the time interval derived from the RTP timestamp (not from the >>> clock), the protocol is safe. The TESLA safety test is >> still accurate. >>> >>> Any delay after RTP has determined its timestamp then folds >> into the >>> delay between sender and receiver that TESLA is designed to handle >>> safely. Of course, this makes the delay longer, which /delays/ >>> authentication. But it doesn't /weaken/ authentication. See >> section 4 >>> of the TESLA intro for discussion of similar scenarios (eg TCP >>> buffering). >>> >>> If authentication delay is a problem for a particular >> scenario, and >>> it's some odd scenario like you suggest where a large part of the >>> delay is within the sender stack between RTP and TESLA, then the >>> implementor can choose to use an explicit I in the packet. >> >> TESLA is complex enough without adding protocol dependencies >> like this >> in my view. >> >>> >>>> If the functions are really identical, then they are >> redundant. I >>>> tend >>>> to doubt that. >>> >>> I'd rather say that the functions of the two fields are invariably >>> equivalent, but may not be in some scenarios, when it's up to the >>> implementor to use the option of an explicit I. >> >> This new option will double the signaling, implementation, >> testing, and >> operational complexity of the protocol. >>> >>> >>>>> 2/ Non-TESLA group authentication to protect against DoS should be >>>>> optional >>>>> >> --------------------------------------------------------------------- >>>>> -- ---- >>>>> The immediate authentication provided by your non-TESLA group >>>>> authentication only protects against DoS by non-group members. It >>>>> should be RECOMMENDED not REQUIRED (section 7). >>>> >>>> I think that this point should be resolved in the base TESLA >>>> specification, i.e. I don't think there is anything that is >>>> SRTP-specific to this point. But we did not treat it that way in >>>> SRTP-TESLA, and that's probably my fault. Nonetheless, I think it >>>> should be REQUIRED in base TESLA. >>> >>> Currently section 5 (security considerations) of the TESLA-intro >>> mentions group authentication as one possible way of preventing >>> flooding attacks during the key disclosure delay. But it doesn't >>> MANDATE it. I'm simply taking issue with group >> authentication being >>> MANDATED in SRTP-TESLA, as I don't think it's effective in many >>> (most?) scenarios, making it unnecessary overhead. >>> >>> I have no problem with making a group MAC optional for >> scenarios where >>> it does improve matters. >> >> I don't have a lot of religious fervor on the topic either though I >> like to avoid options in security protocols whenever possible. What >> seemed fairly obvious to me obviously seems wasteful to you. >> I'd like >> to discuss this further in a separate thread. We are really >> discussing >> a security requirement for protecting groups. >>> >> ... >> >>> >>> Sorry, history was a distracting word. I meant likelihood. >> Imagine a >>> video conf between senior execs of competing companies, or between >>> representatives of mutually distrusting governments. They >> don't trust >>> each other not to spoof what the other parties are saying, >> but they >>> have no likelihood of one launching a flooding attack on the other >>> (e.g. the whole thing is over a joint VPN). They need group >>> authentication like a phish needs a bicycle. So why MANDATE it? >> >> We are beating this to death and confusing one another. The >> participants would not launch the flooding attack; an >> interloper would >> do it. If it's over a VPN, then the attack seems very >> unlikely - as is >> source spoofing in a small teleconference, for that matter. >>> >> ... >>> >>>> relies upon the fact that memory gets tied up while >>>> packets are buffered awaiting authentication. In this >> case, there is >>>> no buffering of multiple packets, just one packet during the >>>> disclosure >>>> interval. Do I understand you correctly? >>> >>> No. The disclosure *interval* (delay) still spans multiple >> packets. >>> The new feature depends on each key now only ever being >> *disclosed* >>> once, rather than the same key being disclosed repeatedly >> as it was >>> when there were multiple packets in the same TESLA time interval. >> >> Before we go any further into this, I'd like to understand why this >> disclosure scheme needs to be considered only for SRTP. You mention >> below that you also think that it belongs in the base TESLA >> specification and that you have raised the issue with your >> co-authors? >> I think the TESLA co-authors might want to consider >> discussing this on >> the list. That sounds better than treating SRTP-TESLA as the poster >> child for something that was maybe overlooked in the base TESLA >> document. >> >> I just got back from some personal time off and am working through >> several hundred messages - I prioritized yours. It would be a more >> efficient discussion to discuss this with the TESLA authors - on the >> msec list if possible. >> >>> >>> As soon as a packet arrives, the disclosed key in it now has two >>> purposes: >>> - it's original TESLA purpose: to verify a packet received >> some time >>> previously >>> - to immediately show the receiver that the sender of this >> packet knew >>> the next key back along the hash chain which is now only ever >>> *disclosed* once >>> >>> So if more packets are received that *disclose* the same key, the >>> receiver can assume (at least until the delayed TESLA >> verification) >>> that only the first packet to disclose each key was genuine. >>> >>> If a network element is compromised, an attacker can >> discover the next >>> disclosed key and overtake or replace a genuine packet with many >>> others. But the receiver can still immediately discard all but the >>> first to arrive, protecting itself from memory overflow. >>> >>> So the scheme has the following properties: >>> - The receiver will never buffer more than one packet per >> packet sent >>> by the genuine sender (so the receiver's buffer fill rate is still >>> clocked by the party that reveals each new key backwards in the >>> chain). >>> - As each key is later disclosed, TESLA can do delayed >> verification of >>> these stored packets. >>> - if they pass delayed verfication, the messages must be genuine >>> - if they fail delayed verfication, the messages must not >> have been >>> genuine >>> - The true message will have been lost in the latter case. >> But, then >>> if an attacker can compromise a network element, it can >> discard the >>> true messages anyway (a group MAC can't prevent this either ;) >>> >>> I need to fully document this. There are some corner cases >> not covered >>> by the above. I've given an outline later. Obviously, this DoS >>> protection idea hasn't had the same peer-review as TESLA, >> except it is >>> essentially just S/KEY, which has had ample peer review >> (but perhaps >>> not in a group setting). >> >> This sounds promising to me, but I would like to see the >> document - I >> have not read the one you sent me yet. And I would like to >> hear what >> the other TESLA authors have to say about it. >>> >>> >> >> ... >>>> If so, why >>>> not put this in the core TESLA specification. I'd say that if it >>>> belongs in SRTP-TESLA, then it belongs in the core >> specification. No? >>> >>> You are absolutely correct. >>> >>> We (the co-authors of the TESLA base spec) are discussing this >>> off-line right now. It's my fault we didn't reach closure >> on it before >>> TESLA got this far. I was originally pushing this as an >> option, but I >>> think I never quite got myself understood. Somewhere in the >> mists of >>> time I gave up. I've been taking a back seat on the TESLA >> work until >>> just recently, so my brain obviously wasn't in gear when reviewing >>> drafts. I forgot I'd got this option to attack the DoS >> problem. It was >>> only through reveiwing the SRTP draft that the technique >> came back to >>> me. Now, the more I argue about it, the better I think it is. >>> >>> However, it's not out of the woods yet. My co-authors are >> trying to >>> break it. I believe I've defended it in the case of >> variable packet >>> rate and packet misordering. But I'm expecting more >> attempts to break >>> it (and, of course, anyone on this list is welcome to try as well). >>> >>> If it comes out intact, you should see text on it shortly. >> Otherwise, >>> I guess the TESLA base spec will stay as it is. >> >> And this sizable email exchange would be in vain :?) >>> >>> >> >> ... >>>>> BTW, it should be pointed out that the verification algo >> should check >>>>> the key index is within an expected range before using it >> (e.g. only >>>>> a >>>>> small increment above the last highest verified key index seen). >>>>> Otherwise, an attacker can tamper with this field to lead all >>>>> receivers to run millions of hash operations >> unnecessarily. I prefer >>>>> to call it a key-index *hint*, to remind me not to rely >> on it being >>>>> correct. >>>> >>>> This sounds like an argument for keeping the MAC. >>> >>> No. It is an argument for watching that it doesn't appear to imply >>> packets are extremely re-ordered (e.g. it must be no more >> than, say, >>> 64 different from the previous highest index, cf the SRTP replay >>> protection window). You /could/ use a group MAC to do an >> initial test >>> of its integrity, but why waste 10 octets when you can do a >> test that >>> uses none? And this would only work if you trusted the >> group members >>> (recall, we are using TESLA because we don't trust them). >> >> The group MAC was originally 4 bytes and I need to check with >> Elisabetta to find out why it is now 10. I don't see why it >> needs to >> be larger than 4 bytes for group MAC purposes. If we manage >> to obviate >> the need for group MACs in TESLA, then it can be zero bytes >> and I'll be >> perfectly happy. >>> >>> The key index is implicitly authenticated (similar to the implicit >>> header authentication in section 9.5.2 of the SRTP RFC) >> because the >>> TESLA MAC depends on it. If the key index is tampered with, the >>> authentication test will fail as it should. >> >> Ok. >>> >>> >> ... >>>> >>>> We'll refer to your editorial comments at the next revision. >>> >>> I've added a couple more below... >> >> Good. How do you feel about my proposal to consider the >> proposed use >> of the RTP timestamp field separately from the group MAC. And treat >> the group MAC as a related question to your point 3 scheme? >> >> thanks, Mark >>> >>>> thanks, Mark >>> >>> And many thanks to you too, for doing all the hard work on these >>> drafts. >>> >>> more comments follow... >>> >>> >>>>> Nits >>>>> ==== >>>>> A general point of style: I found the spec had too much 'knitting >>>>> together by reference' from other specs. As Ran said in an earlier >>>>> posting, it needs at least some sketching of what is referred to. >>>>> Otherwise it is unlikely to lead to safe standardisation of >>>>> implementations. Particularly given that the references >> themselves >>>>> are >>>>> evolving, it becomes unsafe to expect people to find discrepancies >>>>> when reviewing this draft by re-reading the latest drafts of the >>>>> other >>>>> specs each time. Sections 4.4. & 4.4.1 were particular culprits. >>>>> However, I also have some sympathy with the view that >> duplication of >>>>> parts of specs in other specs can lead to inconsistency. >>> >>> The particular point was that the TESLA delay safety test >> is missing >>> from 4.4.2, but strictly you have said it must be done earlier (in >>> 4.4) by referring to the TESLA-intro. I think it should be >> in the list >>> of things the receiver should do. >>> >>> >>>>> Throughout: To be consistent with the TESLA intro, the time-slot >>>>> index, I, should be i (lower case). >>> >>> I now realise that lower case i would conflict with the SRTP spec. >>> >>>>> Sec 2. "...may often used..." --> "...may often be used..." >>>>> Sec 3. "This specification assumes that the reader is >> familiar with >>>>> TESLA" repeats the same sentence in Sec 1.1. >>>>> Sec 3. TESLA synch protocol & initial bootstrapping >> outside scope, >>>>> but >>>>> presumably you will include a ref once one is available. >>>>> Sec 4. "...and the delayed-authentication TESLA elements >> of procedure >>>>> [TESLA]." Garbled sentence? >>>>> Sec 4.1 "showed" --> "shown" >>>>> Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." >>> >>> Sec 4.3 bullet 10, uses same n_c notation as bullet 2 (but for >>> something else) >>> >>>>> Sec 4.4 "If the safe condition does not hold,..." add "...and the >>>>> event SHOULD be logged." >>> >>> Sec 4.4.2: "...perform verification of the SRTP integrity >> protection >>> tag..." this terminology hasn't been used in this draft (it was in >>> SRTP). Here it is just labelled the SRTP MAC. >>> Sec 4.4.2: "...using the rollover counter from the current >> packet,..." >>> -> "...using the rollover counter from the current context,..." >>> Sec 4.5: It might be worth starting this section by discussing the >>> applicability of authenticating RTCP receiver reports in >> large-scale >>> multicast settings. Possibly referring to section 11.2 and >> other parts >>> of the SRTP spec on the applicability and scalability of RTCP >>> authentication in multicast. >>> >>>>> Sec 5. TESLA doesn't assume local clocks don't drift too >> much. Rather >>>>> it requires a bound on clock drift to be known. >>>>> Sec 7. "...an in the TESLA specification..." --> "...and >> in the TESLA >>>>> specification..." >>>>> Sec 7. "...noted that the all TESLA security..." sentence garbled. >>> >>> >>> Cheers >>> >>> >>> >>> Bob >>> >>> >>> >> ______________________________________________________________ >> _________ >>> _____ >>> Notice: This contribution is the personal view of the >> author and does >>> not necessarily reflect the technical nor commercial >> direction of BT >>> plc. >>> >> ______________________________________________________________ >> _________ >>> _____ >>> Bob Briscoe, Networks Research >> Centre, BT >>> Research >>> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >> +44 1473 >>> 645196 >>> >>> _______________________________________________ >>> msec mailing list >>> msec@securemulticast.org >>> http://six.pairlist.net/mailman/listinfo/msec >>> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://six.pairlist.net/mailman/listinfo/msec >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 31 00:18:43 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00327 for ; Tue, 31 Aug 2004 00:18:43 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 56F2C8C841; Tue, 31 Aug 2004 00:18:45 -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 673A18C3B8 for ; Tue, 31 Aug 2004 00:18:44 -0400 (EDT) Received: (qmail 74114 invoked by uid 3269); 31 Aug 2004 04:18:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74108 invoked from network); 31 Aug 2004 04:18:44 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 31 Aug 2004 04:18:44 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i7V4C6M31064; Tue, 31 Aug 2004 00:12:07 -0400 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i7V4ERe46298; Tue, 31 Aug 2004 00:14:27 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i7V4EQ836028; Tue, 31 Aug 2004 00:14:26 -0400 Date: Tue, 31 Aug 2004 00:14:25 -0400 (EDT) From: canetti To: Mark Baugher Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) In-Reply-To: <2C0FDBFB-FABF-11D8-A596-000A95DC10F2@cisco.com> Message-ID: References: <2C0FDBFB-FABF-11D8-A596-000A95DC10F2@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Jumping into a very long discussion, wanted to say few short things: 1. I think that the TESLA intro draft should contain a better comparative discussion of anti-DOS methods, including weaknesses and strengths, and recommendations for use in different scenarios. however I DONT think that the intro draft should (or can) mandate any one method. Remember, this is an informational draft, not a dtandard. In contrast, tesla-srtp, and also the comingrealsoonnow tesla-esp are standards, and therefore they should each choose one DOS protection method, that is suitable to their respective scenarios. I am ok with tesla-srtp using the current external MAC method, especially since SRTP already has an external MAC mechanism in place. But I dont feel strongly here at all, mainly since none of the suggested methods is completely superior to other methods. all have their own strengths and weaknesses. I'd thus opt for doing the simplest thing... whatever that might be. That said, I think it is reasonable to reduce the extenal MAC in tesla-srtp to RECOMMENDED. Indeed, as Bob points out, in some scenarios it might be totally unneeded and only be a babdwidth deadweitght. (still, the security considerations section ahould make it crystal clear what are the tradeoffs here. 2. I think that Bob's idea of having the receiver infer the interval number from the RTP timestamp may work in some/many cases. But it might make the programming more delicate and harder to get right. One potential solution is just to opt for a more robust design at the price of extra 4 bytes p.p. altenratively, we can make the interval number optional and leave it up to the implementation whether it wants to save the extra 4 bytes or not. Ran On Mon, 30 Aug 2004, Mark Baugher wrote: > Thanks for the summary. There is also the point about re-using the RTP > timestamp in place of the TESLA key identifier. And Bob has proposed a > way to obviate the need for a group MAC with a TESLA innovation that > his co-authors are considering. > > Even if Bob's idea is accepted, the discussion on whether or not to > mandate group authentication in a TESLA protocol is probably time well > spent. > > Mark > On Aug 30, 2004, at 11:39 AM, wrote: > > > > > Just trying to understand from confusing inlining.... > > > > One of the high order bits of the discussion is the question: > > > > Should Group-MAC, to provide group authentication and prevent > > DoS attacks from outside the group, be MANDATED or NOT? > > > > and the related question: > > > > The base TESLA intro draft does not mandate it, how come > > SRTP-TESLA draft is mandating it? > > > > Thinking out loud, mandating Group-MAC has the advantage of less > > interoperability > > woes. On the flip side making it optional has the advantage of saving > > byte-overhead > > per packet and a bit of computation time, when Group-MAC is not used. > > Mark, points > > out extra space needed should actually be 4 bytes as opposed to 10 > > bytes mentioned > > in the SRTP-TESLA draft. > > > > Since presence of Group-MAC can be a group policy, which in the case > > of Multicast > > security is enforced rather than negotiated, I would guess > > interoperability issues > > should not crop up. So making it optional may not actually lead to > > interoperability > > woes. > > > > What do other members on MSEC mailing list think? Mandate or not > > Mandate Group-MAC > > in the base TESLA protocol? IMHO, Once we decide that, we can talk > > about what to do > > in SRTP-TESLA, if at all any different. > > > > Best, > > Atul > > > >> -----Original Message----- > >> From: msec-bounces@securemulticast.org > >> [mailto:msec-bounces@securemulticast.org]On Behalf Of ext Mark Baugher > >> Sent: Monday, August 30, 2004 1:50 PM > >> To: Bob Briscoe > >> Cc: elisabetta.carrara@ericsson.com; msec@securemulticast.org > >> Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) > >> > >> > >> Bob, > >> I reply to many of your points below, but here is > >> something I'd like > >> for you and your co-authors to consider: Apart from reusing the RTP > >> timestamp field the issue you raise in point 3 is a general > >> TESLA issue > >> and not an SRTP-TESLA issue. I think this is also true for > >> guidance on > >> the use or non-use of a group MAC, which is related to your > >> point 3. > >> I'd like to see these points treated in a general way so why not > >> critique the base TESLA spec on this point and not SRTP-TESLA? > >> > >> More below... > >> On Aug 30, 2004, at 5:51 AM, Bob Briscoe wrote: > >>> > >> ... > >>> I'm not sure whether you're misunderstanding me, or just > >> agreeing, but > >>> sounding as if you disagree. In no way am I proposing > >> anything that > >>> doesn't do strong integrity checking. > >> > >> I understand that. > >> > >>> > >> ... > >>> Having thought about it, I will be stronger than the last > >> mail and say > >>> a group MAC will provide barely any additional protection in most > >>> circumstances so should not be the default. The logic of > >> using a group > >>> MAC with TESLA looks like this: > >>> > >>> Sender's level of trust in group members not to spoof packets > >>> | using a group key? | > >>> Low High > >>> | | > >>> Use source authentication (ie TESLA). Use group > >>> authentication. > >>> | > >>> TESLA is vulnerable to DoS filling buffer > >>> until delayed auth > >>> | > >>> Use group authentication alongside TESLA > >>> (as in current SRTP draft) > >>> > >>> I hope this diagram helps highlight the broken logic. > >>> Group authentication is being MANDATED in the SRTP draft in > >> a scenario > >>> which only ever arises where the group isn't trusted. > >> > >> Trusted to do or not do what? I think in this case, "trusted" means > >> "trusted not to launch a denial of service attack against the > >> group." > >> There is also "trusted not to capture a disclosed key to > >> successfully > >> impersonate a group sender." Further, there is "trusted not to > >> disclose a group key" - and so on. Treating something as > >> complicated > >> as this as "high" or "low" is not persuading me, personally. > >> > >>> dding group authentication to TESLA only provides any > >> additional value > >>> for the narrow range of scenarios where group members > >> aren't trusted > >>> enough to use group authentication alone, but they are trusted > >>> sufficiently that group authentication might detect some > >> DoS attacks - > >>> pretty slim odds. Worth allowing as an option, but surely not > >>> MANDATING. > >> > >> You see a waste of time and bandwidth for protection that is > >> superfluous. I see a relatively cheap way to keep a group protected > >> against anyone running a kiddie script who decides to send a > >> burst of > >> packets and overflow members' buffers. Let's gather some > >> more opinion > >> from msec on this point IF IT IS NOT MADE MOOT BY YOUR POINT 3, BELOW. > >>> > >> ... > >>> > >>> I had thought about the ramifications fairly carefully > >> before saying > >>> this. I suggest that the way to deal with the TESLA time interval > >>> identifier, I, is to: > >>> - remove I from the default TESLA-SRTP packet format > >>> - explain how to derive I from the RTP timestamp > >> > >> I may have confused you in my last note in trying to explain all the > >> ways that I think overloading protocol fields for security > >> purposes is > >> generally not a good idea. Let me try to state this clearly: > >> The RTP > >> timestamp is used for specific purposes for RTP payload types > >> that are > >> unrelated to sender authentication, and it is quite possible that we > >> will either interfere with these uses by placing TESLA-induced > >> constraints on that field or weaken TESLA security when we find > >> surprising uses are made of that field by certain applications. > >> > >> Re-use of the RTP Timestamp in TESLA can be easily avoided by > >> adding a > >> TESLA timetamp field in the packet. I think the points you > >> are raising > >> are important and helpful to SRTP-TESLA. But it would > >> helpful if you > >> separated them I think. Re-use of the RTP timestamp, the > >> non-mandatory > >> group MAC, and your proposal under point 3 can stand by > >> themselves. I > >> think we have 3 threads here and not one. > >> > >>> - MANDATE that a sender authentication module should use a > >> TESLA key > >>> interval derived from the RTP timestamp, not the clock > >>> - warn implementors that any delay in the sender stack will > >> add to the > >>> TESLA authentication delay (but not weaken it) > >>> - (if we can think of any other problems ) warn > >> implementors what to > >>> watch out for when overloading the RTP timestamp function > >> (I'm fairly > >>> sure there aren't any - and I've thought long and hard) > >> > >> I'd prefer to use a separate field. At minimum, I would take > >> this to > >> AVT for further discussion. I don't think the gain from > >> overloading is > >> worth any unexpected pitfalls, particularly security > >> pitfalls. RTP is > >> a special beast because it is used in so many types of applications, > >> from telephony to client/server multimedia, from unicast-pairwise to > >> unicast-group, small multicast conferences to large-scale broadcast, > >> etc. > >> > >>> - make I optional in the TESLA-SRTP packet format for > >> implementors to > >>> use if they are in one of these obscure scenarios > >>> > >>> > >>>>> If the sender buffers packets between adding the RTP timestamp and > >>>>> adding TESLA authentication fields, this will add to the TESLA > >>>>> authentication delay. But a good RTP implementation shouldn't be > >>>>> doing > >>>>> serious buffering here. > >>>> > >>>> What about high-bandwidth, server/playback media such as > >> movies? In > >>>> fact, let me try this: What about an MPEG packetizer that > >> does a lot > >>>> of pre-processing of the MPEG AUs prior to assigning them > >> to packets. > >>>> This might happen because the AUs were encrypted and > >> required a lot of > >>>> pre-processing. Maybe there would be a two-step process > >> applied to > >>>> one > >>>> or more AUs in which timetamps are assigned during some > >> processing and > >>>> then everything gets sent. > >>>> Maybe such a problem can be avoided in packetizers. There > >> are a lot > >>>> of > >>>> considerations when we take an existing field such as the RTP > >>>> timestamp > >>>> and add new functions to it. > >>> > >>> As long as we mandate that the TESLA sender uses the key > >> appropriate > >>> to the time interval derived from the RTP timestamp (not from the > >>> clock), the protocol is safe. The TESLA safety test is > >> still accurate. > >>> > >>> Any delay after RTP has determined its timestamp then folds > >> into the > >>> delay between sender and receiver that TESLA is designed to handle > >>> safely. Of course, this makes the delay longer, which /delays/ > >>> authentication. But it doesn't /weaken/ authentication. See > >> section 4 > >>> of the TESLA intro for discussion of similar scenarios (eg TCP > >>> buffering). > >>> > >>> If authentication delay is a problem for a particular > >> scenario, and > >>> it's some odd scenario like you suggest where a large part of the > >>> delay is within the sender stack between RTP and TESLA, then the > >>> implementor can choose to use an explicit I in the packet. > >> > >> TESLA is complex enough without adding protocol dependencies > >> like this > >> in my view. > >> > >>> > >>>> If the functions are really identical, then they are > >> redundant. I > >>>> tend > >>>> to doubt that. > >>> > >>> I'd rather say that the functions of the two fields are invariably > >>> equivalent, but may not be in some scenarios, when it's up to the > >>> implementor to use the option of an explicit I. > >> > >> This new option will double the signaling, implementation, > >> testing, and > >> operational complexity of the protocol. > >>> > >>> > >>>>> 2/ Non-TESLA group authentication to protect against DoS should be > >>>>> optional > >>>>> > >> --------------------------------------------------------------------- > >>>>> -- ---- > >>>>> The immediate authentication provided by your non-TESLA group > >>>>> authentication only protects against DoS by non-group members. It > >>>>> should be RECOMMENDED not REQUIRED (section 7). > >>>> > >>>> I think that this point should be resolved in the base TESLA > >>>> specification, i.e. I don't think there is anything that is > >>>> SRTP-specific to this point. But we did not treat it that way in > >>>> SRTP-TESLA, and that's probably my fault. Nonetheless, I think it > >>>> should be REQUIRED in base TESLA. > >>> > >>> Currently section 5 (security considerations) of the TESLA-intro > >>> mentions group authentication as one possible way of preventing > >>> flooding attacks during the key disclosure delay. But it doesn't > >>> MANDATE it. I'm simply taking issue with group > >> authentication being > >>> MANDATED in SRTP-TESLA, as I don't think it's effective in many > >>> (most?) scenarios, making it unnecessary overhead. > >>> > >>> I have no problem with making a group MAC optional for > >> scenarios where > >>> it does improve matters. > >> > >> I don't have a lot of religious fervor on the topic either though I > >> like to avoid options in security protocols whenever possible. What > >> seemed fairly obvious to me obviously seems wasteful to you. > >> I'd like > >> to discuss this further in a separate thread. We are really > >> discussing > >> a security requirement for protecting groups. > >>> > >> ... > >> > >>> > >>> Sorry, history was a distracting word. I meant likelihood. > >> Imagine a > >>> video conf between senior execs of competing companies, or between > >>> representatives of mutually distrusting governments. They > >> don't trust > >>> each other not to spoof what the other parties are saying, > >> but they > >>> have no likelihood of one launching a flooding attack on the other > >>> (e.g. the whole thing is over a joint VPN). They need group > >>> authentication like a phish needs a bicycle. So why MANDATE it? > >> > >> We are beating this to death and confusing one another. The > >> participants would not launch the flooding attack; an > >> interloper would > >> do it. If it's over a VPN, then the attack seems very > >> unlikely - as is > >> source spoofing in a small teleconference, for that matter. > >>> > >> ... > >>> > >>>> relies upon the fact that memory gets tied up while > >>>> packets are buffered awaiting authentication. In this > >> case, there is > >>>> no buffering of multiple packets, just one packet during the > >>>> disclosure > >>>> interval. Do I understand you correctly? > >>> > >>> No. The disclosure *interval* (delay) still spans multiple > >> packets. > >>> The new feature depends on each key now only ever being > >> *disclosed* > >>> once, rather than the same key being disclosed repeatedly > >> as it was > >>> when there were multiple packets in the same TESLA time interval. > >> > >> Before we go any further into this, I'd like to understand why this > >> disclosure scheme needs to be considered only for SRTP. You mention > >> below that you also think that it belongs in the base TESLA > >> specification and that you have raised the issue with your > >> co-authors? > >> I think the TESLA co-authors might want to consider > >> discussing this on > >> the list. That sounds better than treating SRTP-TESLA as the poster > >> child for something that was maybe overlooked in the base TESLA > >> document. > >> > >> I just got back from some personal time off and am working through > >> several hundred messages - I prioritized yours. It would be a more > >> efficient discussion to discuss this with the TESLA authors - on the > >> msec list if possible. > >> > >>> > >>> As soon as a packet arrives, the disclosed key in it now has two > >>> purposes: > >>> - it's original TESLA purpose: to verify a packet received > >> some time > >>> previously > >>> - to immediately show the receiver that the sender of this > >> packet knew > >>> the next key back along the hash chain which is now only ever > >>> *disclosed* once > >>> > >>> So if more packets are received that *disclose* the same key, the > >>> receiver can assume (at least until the delayed TESLA > >> verification) > >>> that only the first packet to disclose each key was genuine. > >>> > >>> If a network element is compromised, an attacker can > >> discover the next > >>> disclosed key and overtake or replace a genuine packet with many > >>> others. But the receiver can still immediately discard all but the > >>> first to arrive, protecting itself from memory overflow. > >>> > >>> So the scheme has the following properties: > >>> - The receiver will never buffer more than one packet per > >> packet sent > >>> by the genuine sender (so the receiver's buffer fill rate is still > >>> clocked by the party that reveals each new key backwards in the > >>> chain). > >>> - As each key is later disclosed, TESLA can do delayed > >> verification of > >>> these stored packets. > >>> - if they pass delayed verfication, the messages must be genuine > >>> - if they fail delayed verfication, the messages must not > >> have been > >>> genuine > >>> - The true message will have been lost in the latter case. > >> But, then > >>> if an attacker can compromise a network element, it can > >> discard the > >>> true messages anyway (a group MAC can't prevent this either ;) > >>> > >>> I need to fully document this. There are some corner cases > >> not covered > >>> by the above. I've given an outline later. Obviously, this DoS > >>> protection idea hasn't had the same peer-review as TESLA, > >> except it is > >>> essentially just S/KEY, which has had ample peer review > >> (but perhaps > >>> not in a group setting). > >> > >> This sounds promising to me, but I would like to see the > >> document - I > >> have not read the one you sent me yet. And I would like to > >> hear what > >> the other TESLA authors have to say about it. > >>> > >>> > >> > >> ... > >>>> If so, why > >>>> not put this in the core TESLA specification. I'd say that if it > >>>> belongs in SRTP-TESLA, then it belongs in the core > >> specification. No? > >>> > >>> You are absolutely correct. > >>> > >>> We (the co-authors of the TESLA base spec) are discussing this > >>> off-line right now. It's my fault we didn't reach closure > >> on it before > >>> TESLA got this far. I was originally pushing this as an > >> option, but I > >>> think I never quite got myself understood. Somewhere in the > >> mists of > >>> time I gave up. I've been taking a back seat on the TESLA > >> work until > >>> just recently, so my brain obviously wasn't in gear when reviewing > >>> drafts. I forgot I'd got this option to attack the DoS > >> problem. It was > >>> only through reveiwing the SRTP draft that the technique > >> came back to > >>> me. Now, the more I argue about it, the better I think it is. > >>> > >>> However, it's not out of the woods yet. My co-authors are > >> trying to > >>> break it. I believe I've defended it in the case of > >> variable packet > >>> rate and packet misordering. But I'm expecting more > >> attempts to break > >>> it (and, of course, anyone on this list is welcome to try as well). > >>> > >>> If it comes out intact, you should see text on it shortly. > >> Otherwise, > >>> I guess the TESLA base spec will stay as it is. > >> > >> And this sizable email exchange would be in vain :?) > >>> > >>> > >> > >> ... > >>>>> BTW, it should be pointed out that the verification algo > >> should check > >>>>> the key index is within an expected range before using it > >> (e.g. only > >>>>> a > >>>>> small increment above the last highest verified key index seen). > >>>>> Otherwise, an attacker can tamper with this field to lead all > >>>>> receivers to run millions of hash operations > >> unnecessarily. I prefer > >>>>> to call it a key-index *hint*, to remind me not to rely > >> on it being > >>>>> correct. > >>>> > >>>> This sounds like an argument for keeping the MAC. > >>> > >>> No. It is an argument for watching that it doesn't appear to imply > >>> packets are extremely re-ordered (e.g. it must be no more > >> than, say, > >>> 64 different from the previous highest index, cf the SRTP replay > >>> protection window). You /could/ use a group MAC to do an > >> initial test > >>> of its integrity, but why waste 10 octets when you can do a > >> test that > >>> uses none? And this would only work if you trusted the > >> group members > >>> (recall, we are using TESLA because we don't trust them). > >> > >> The group MAC was originally 4 bytes and I need to check with > >> Elisabetta to find out why it is now 10. I don't see why it > >> needs to > >> be larger than 4 bytes for group MAC purposes. If we manage > >> to obviate > >> the need for group MACs in TESLA, then it can be zero bytes > >> and I'll be > >> perfectly happy. > >>> > >>> The key index is implicitly authenticated (similar to the implicit > >>> header authentication in section 9.5.2 of the SRTP RFC) > >> because the > >>> TESLA MAC depends on it. If the key index is tampered with, the > >>> authentication test will fail as it should. > >> > >> Ok. > >>> > >>> > >> ... > >>>> > >>>> We'll refer to your editorial comments at the next revision. > >>> > >>> I've added a couple more below... > >> > >> Good. How do you feel about my proposal to consider the > >> proposed use > >> of the RTP timestamp field separately from the group MAC. And treat > >> the group MAC as a related question to your point 3 scheme? > >> > >> thanks, Mark > >>> > >>>> thanks, Mark > >>> > >>> And many thanks to you too, for doing all the hard work on these > >>> drafts. > >>> > >>> more comments follow... > >>> > >>> > >>>>> Nits > >>>>> ==== > >>>>> A general point of style: I found the spec had too much 'knitting > >>>>> together by reference' from other specs. As Ran said in an earlier > >>>>> posting, it needs at least some sketching of what is referred to. > >>>>> Otherwise it is unlikely to lead to safe standardisation of > >>>>> implementations. Particularly given that the references > >> themselves > >>>>> are > >>>>> evolving, it becomes unsafe to expect people to find discrepancies > >>>>> when reviewing this draft by re-reading the latest drafts of the > >>>>> other > >>>>> specs each time. Sections 4.4. & 4.4.1 were particular culprits. > >>>>> However, I also have some sympathy with the view that > >> duplication of > >>>>> parts of specs in other specs can lead to inconsistency. > >>> > >>> The particular point was that the TESLA delay safety test > >> is missing > >>> from 4.4.2, but strictly you have said it must be done earlier (in > >>> 4.4) by referring to the TESLA-intro. I think it should be > >> in the list > >>> of things the receiver should do. > >>> > >>> > >>>>> Throughout: To be consistent with the TESLA intro, the time-slot > >>>>> index, I, should be i (lower case). > >>> > >>> I now realise that lower case i would conflict with the SRTP spec. > >>> > >>>>> Sec 2. "...may often used..." --> "...may often be used..." > >>>>> Sec 3. "This specification assumes that the reader is > >> familiar with > >>>>> TESLA" repeats the same sentence in Sec 1.1. > >>>>> Sec 3. TESLA synch protocol & initial bootstrapping > >> outside scope, > >>>>> but > >>>>> presumably you will include a ref once one is available. > >>>>> Sec 4. "...and the delayed-authentication TESLA elements > >> of procedure > >>>>> [TESLA]." Garbled sentence? > >>>>> Sec 4.1 "showed" --> "shown" > >>>>> Sec 4.3 bullet 10 "...based up the..." --> "...based upon the..." > >>> > >>> Sec 4.3 bullet 10, uses same n_c notation as bullet 2 (but for > >>> something else) > >>> > >>>>> Sec 4.4 "If the safe condition does not hold,..." add "...and the > >>>>> event SHOULD be logged." > >>> > >>> Sec 4.4.2: "...perform verification of the SRTP integrity > >> protection > >>> tag..." this terminology hasn't been used in this draft (it was in > >>> SRTP). Here it is just labelled the SRTP MAC. > >>> Sec 4.4.2: "...using the rollover counter from the current > >> packet,..." > >>> -> "...using the rollover counter from the current context,..." > >>> Sec 4.5: It might be worth starting this section by discussing the > >>> applicability of authenticating RTCP receiver reports in > >> large-scale > >>> multicast settings. Possibly referring to section 11.2 and > >> other parts > >>> of the SRTP spec on the applicability and scalability of RTCP > >>> authentication in multicast. > >>> > >>>>> Sec 5. TESLA doesn't assume local clocks don't drift too > >> much. Rather > >>>>> it requires a bound on clock drift to be known. > >>>>> Sec 7. "...an in the TESLA specification..." --> "...and > >> in the TESLA > >>>>> specification..." > >>>>> Sec 7. "...noted that the all TESLA security..." sentence garbled. > >>> > >>> > >>> Cheers > >>> > >>> > >>> > >>> Bob > >>> > >>> > >>> > >> ______________________________________________________________ > >> _________ > >>> _____ > >>> Notice: This contribution is the personal view of the > >> author and does > >>> not necessarily reflect the technical nor commercial > >> direction of BT > >>> plc. > >>> > >> ______________________________________________________________ > >> _________ > >>> _____ > >>> Bob Briscoe, Networks Research > >> Centre, BT > >>> Research > >>> B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > >> +44 1473 > >>> 645196 > >>> > >>> _______________________________________________ > >>> msec mailing list > >>> msec@securemulticast.org > >>> http://six.pairlist.net/mailman/listinfo/msec > >>> > >> > >> _______________________________________________ > >> msec mailing list > >> msec@securemulticast.org > >> http://six.pairlist.net/mailman/listinfo/msec > >> > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 31 09:55:56 2004 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18738 for ; Tue, 31 Aug 2004 09:55:55 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B4DE08CD9F; Tue, 31 Aug 2004 09:55:55 -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 9C7258CCD7 for ; Tue, 31 Aug 2004 09:55:53 -0400 (EDT) Received: (qmail 83614 invoked by uid 3269); 31 Aug 2004 13:55:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83611 invoked from network); 31 Aug 2004 13:55:53 -0000 Received: from albatross.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 31 Aug 2004 13:55:53 -0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i7VDtpWR022320 for ; Tue, 31 Aug 2004 15:55:52 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 15:55:50 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 31 Aug 2004 15:55:47 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0C3BC398@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: msec@securemulticast.org Subject: RE: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long) Date: Tue, 31 Aug 2004 15:50:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 31 Aug 2004 13:55:50.0800 (UTC) FILETIME=[39880900:01C48F62] Cc: "'canetti'" , Mark Baugher 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 Hi I've not gone through all the mails (just arrived from vacation), however some thoughts.. > > Jumping into a very long discussion, wanted to say few short things: > > 1. I think that the TESLA intro draft should contain a better > comparative discussion of anti-DOS methods, including weaknesses and > strengths, and recommendations for use in different scenarios. > however I DONT think that the intro draft should (or can) > mandate any one > method. Remember, this is an informational draft, not a dtandard. > > In contrast, tesla-srtp, and also the comingrealsoonnow tesla-esp are > standards, and therefore they should each choose one DOS > protection method, > that is suitable to their respective scenarios. > > I am ok with tesla-srtp using the current external MAC > method, especially > since SRTP already has an external MAC mechanism in place. > But I dont feel > strongly here at all, mainly since none of the suggested methods is > completely superior to other methods. all have their own strengths and > weaknesses. I'd thus opt for doing the simplest thing... whatever that > might be. > > That said, I think it is reasonable to reduce the extenal MAC > in tesla-srtp to > RECOMMENDED. Indeed, as Bob points out, in some scenarios it might be > totally unneeded and only be a babdwidth deadweitght. (still, > the security > considerations section ahould make it crystal clear what are > the tradeoffs > here. We discussed of the possibility of making the external MAC optional, though we were mainly waiting for feedback from the TESLA authors. I'm personally ok with RECOMMENDED (actually, I'd prefer it), and I'd encourage the TESLA authors to discuss the DoS issue in the base TESLA draft. > > 2. I think that Bob's idea of having the receiver infer the interval > number from the RTP timestamp may work in some/many cases. > But it might > make the programming more delicate and harder to get right. > One potential > solution is just to opt for a more robust design at the price > of extra 4 > bytes p.p. altenratively, we can make the interval number > optional and > leave it up to the implementation whether it wants to save the extra 4 > bytes or not. That I know, the RTP timestamp is a weird beast. It is not monotonically increasing. Subsequent packets can have the same timestamp value, or there could be big jumps (e.g. if there is silent but it is not transmitted), and the value can even decrease. I feel better with the TESLA index ;o) Cheers /E _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec