From mailman-bounces@six.pairlist.net Wed Jun 1 05:04:44 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07656 for ; Wed, 1 Jun 2005 05:04:43 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 268BF8D1E3 for ; Wed, 1 Jun 2005 05:04:37 -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: Wed, 01 Jun 2005 05:02:23 -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 Wed Jun 1 15:55:35 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22536 for ; Wed, 1 Jun 2005 15:55:33 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 779E18C932; Wed, 1 Jun 2005 15:55: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 888A48C6A9 for ; Wed, 1 Jun 2005 15:55:31 -0400 (EDT) Received: (qmail 97268 invoked by uid 3269); 1 Jun 2005 19:55:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97262 invoked from network); 1 Jun 2005 19:55:31 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 1 Jun 2005 19:55:31 -0000 Received: (qmail 40314 invoked from network); 1 Jun 2005 15:55:28 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 1 Jun 2005 15:55:28 -0400 Received: (qmail 33528 invoked from network); 1 Jun 2005 15:55:22 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.13) by mail1.oct.nac.net with SMTP; 1 Jun 2005 15:55:22 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j51GifE09499; Wed, 1 Jun 2005 12:44:41 -0400 Date: Wed, 1 Jun 2005 12:44:41 -0400 (EDT) From: George Gross To: Lakshminath Dondeti Subject: Re: [MSEC] Consensus call on draft-ietf-msec-ipsec-signatures-05.txt In-Reply-To: <429CC985.2080605@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hartmans-ietf@mit.edu, Ran Canetti , Russ Housley , 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 Brian, I have one clarifying question inline below; in all other regards this draft is ready for movement to RFC... br, George On Tue, 31 May 2005, Lakshminath Dondeti wrote: > > 5. Section 4.0 contains new text on combined modes and states in part > "The RSA signatures algorithm cannot be used with an ESP Combined Mode > algorithm that includes an explicit ICV." > > There is an explanation as to why. I looked at this section, and it wasn't immediately obvious why there was this restriction, x'cus me if this is a dense question ;o) Why could you not define an ESP header/trailer that has both the ESP Combined Mode algorithm ICV and the RSA signature authenticator, and do the combined mode's authenticate/encrypt payload processing with the RSA signature data field set to zero? After the sender executes ESP Combined Mode, it then computes the RSA signature, and fills in the zeroed field with the signature data. On the receiver side, reserve a copy of the signature data, zero fill the signature data field, then apply ESP Combined Mode decryption and group authentication verification. If the group authentication passes, then proceed to do RSA signature verification on the original (i.e. encrypted) ESP payload that had been signed. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jun 1 17:33:42 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11009 for ; Wed, 1 Jun 2005 17:33:41 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5B2A18CC33; Wed, 1 Jun 2005 17:33:43 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id A23018CBD5 for ; Wed, 1 Jun 2005 17:33:42 -0400 (EDT) Received: (qmail 16921 invoked by uid 3269); 1 Jun 2005 21:33:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16918 invoked from network); 1 Jun 2005 21:33:42 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 1 Jun 2005 21:33:42 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j51LXNCK020189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jun 2005 14:33:24 -0700 (PDT) Received: from [10.50.66.80] (qconnect-10-50-66-80.qualcomm.com [10.50.66.80]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j51LXDbS020502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2005 14:33:18 -0700 (PDT) Message-ID: <429E2997.9030707@qualcomm.com> Date: Wed, 01 Jun 2005 17:33:11 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Perrig References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> <4297286C.9050802@qualcomm.com> <425c417e57be178d968105723ab2a260@cisco.com> <42976154.5000803@qualcomm.com> <429B1188.8090301@ece.cmu.edu> <0556c1f631f485172bf342a58ce6e4de@cisco.com> In-Reply-To: <0556c1f631f485172bf342a58ce6e4de@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tygar@cs.berkeley.edu, tschofenig Hannes , dawnsong@cmu.edu, canetti@watson.ibm.com, Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Elisabetta Carrara , Mark Baugher , Sam Hartman , Fries Steffen Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Adrian, Mark's suggestion sounds good to me. I can't say there is any consensus on this one way or another, but we need to close this ASAP. All, We need opinions on this to reach consensus. regards, Lakshminath Mark Baugher wrote: > Adrian > We might want to summarize this discussion in a sentence or two in > the I-D in order to document what is known. > > Mark > On May 30, 2005, at 6:13 AM, Adrian Perrig wrote: > >> Hi, >> >> Given the limited usefulness of dynamically altering the disclosure >> delay and the security vulnerability that is created by dynamically >> shortening the disclosure delay, I vote to remove this section. >> For the argument that "it's good to keep it to discuss potential >> implementation errors," we would need to add a lot of other potential >> errors as well. Best, >> Adrian >> >>> Mark, >>> Thanks for sharing your thoughts on this. >>> I don't have a specific use case in mind for this feature. However, >>> given where we are in the process, and also considering that this is >>> an informational RFC, my inclination is to suggest providing >>> information on the proverbial "what happens if we do this vs. that" >>> in the soon to be RFC. Deleting the section and all references to >>> that section is certainly an option too. I am proposing that >>> providing that information would be useful (a record of the >>> discussion so to speak). >>> When it comes to TESLA-SPEC, perhaps I will agree with a SHOULD NOT >>> for changing the disclosure delay within a TESLA session. Of course >>> that goes along with a security considerations section that contains >>> a summary of this discussion on what happens if the disclosure delay >>> were to be changed. >>> best regards, >>> Lakshminath >>> (NOT as MSEC co-chair) >>> Mark Baugher wrote: >>> >>>> Lakshminath, >>>> I don't see any value to altering the disclosure delay. >>>> >>>> Mark >>>> On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote: >>>> >>>>> Adrian, >>>>> >>>>> Thanks. As Steffen notes, if the receiver receives any >>>>> legitimate packet after the disclosure delay change, then it >>>>> would know that the delay has changed, right? (Of course there >>>>> is the threat of an adversary acting as a MiTM after a disclosure >>>>> delay reduction and modify all pertinent information to continue >>>>> to fool the victim). Furthermore, isn't increasing the >>>>> disclosure delay ok? >>>>> >>>>> I am thinking perhaps Section 3.7 could remain but with >>>>> appropriate modifications to reflect your notes below and perhaps >>>>> answering some of the questions above. (As a side note, that >>>>> will allow all references to Section 3.7 to remain, and the >>>>> reader -- this is an Informational RFC -- would have information >>>>> on whether or not dynamically changing disclosure delay is ok). >>>>> >>>>> Thoughts? >>>>> >>>>> regards, >>>>> Lakshminath >>>>> NOT as co-chair of the group >>>>> >>>>> >>>>> Adrian Perrig wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Allowing a sender to dynamically alter the disclosure schedule of >>>>>> keys >>>>>> is very dangerous, and removes the property of TESLA to be robust to >>>>>> packet loss. Consider the following example. In packet P_i, a sender >>>>>> would announce that K_j that was supposed to be published after time >>>>>> T_j is now going to be published earlier. If a receiver misses this >>>>>> packet, the receiver will still believe that K_j is published after >>>>>> time T_j, so an attacker can forge packets for that receiver when >>>>>> obtaining K_j before time T_j. >>>>>> >>>>>> This example illustrates that it is dangerous to alter a disclosure >>>>>> schedule and that is why I suggested removing Section 3.7. This >>>>>> section was supposed to be removed earlier, but maybe due to version >>>>>> control issues it has somehow survived. >>>>>> Adrian >>>>>> >>>>>> >>>>>>> Hi all, > >>>>>>> **Please note that this document is in RFC Editor Auth-48 stage, so >>>>>>> please respond as soon as you can.** >>>>>>> >>>>>>> Adrian suggests that Section 3.7 from >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro >>>>>>> -04.txt >>>>>>> be deleted (please see Adrian's note below). >>>>>>> >>>>>>> I have several requests: >>>>>>> >>>>>>> * I-D authors referring to this document: please check to see >>>>>>> if this >>>>>>> impacts your documents. >>>>>>> * All WG members: please comment on whether you are ok with >>>>>>> removing >>>>>>> Section 3.7. >>>>>>> * Adrian: please elaborate on the vulnerability (or post a >>>>>>> link to a >>>>>>> reference that does). >>>>>>> >>>>>>> Note: This is to be an informational RFC. >>>>>>> >>>>>>> thanks and regards, >>>>>>> Lakshminath >>>>>>> >>>>>>> >>>>>>> Russ Housley wrote: >>>>>>> >>>>>>> >>>>>>>> Adrian: >>>>>>>> >>>>>>>> This is a fairly large change at this stage. Since this is a >>>>>>>> MSEC WG >>>>>>>> document, it should be coordinated with the WG. >>>>>>>> >>>>>>>> MSEC WG Chairs: >>>>>>>> >>>>>>>> Please confirm that this change does not impact consensus. >>>>>>>> >>>>>>>> Russ >>>>>>>> >>>>>>>> At 07:27 PM 5/23/2005, Adrian Perrig wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Section 3.7: >>>>>>>>> The entire section must be deleted. Dynamically >>>>>>>>> changing time >>>>>>>>> intervals introduces a security vulnerability and TESLA loses the >>>>>>>>> resilience to packet loss property. >>>>>>>> >> > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 2 00:12:41 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08227 for ; Thu, 2 Jun 2005 00:12:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 79AF68C99B; Thu, 2 Jun 2005 00:12: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 76D0D8C998 for ; Thu, 2 Jun 2005 00:12:40 -0400 (EDT) Received: (qmail 10336 invoked by uid 3269); 2 Jun 2005 04:12:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10332 invoked from network); 2 Jun 2005 04:12:40 -0000 Received: from smtp.us1.net2.com.br (HELO us1.net2.com.br) (64.246.27.17) by klesh.pair.com with SMTP; 2 Jun 2005 04:12:40 -0000 Received: (qmail 28226 invoked by uid 513); 2 Jun 2005 04:00:30 -0000 Received: from atv@alan.pro.br by us1.net2.com.br by uid 101 with qmail-scanner-1.22 (f-prot: 4.4.1/3.14.11. Clear:RC:0(201.9.186.5):. Processed in 7.889941 secs); 02 Jun 2005 04:00:30 -0000 Received: from 201009186005.user.veloxzone.com.br (HELO alansempron) (atv@alan.pro.br@201.9.186.5) by us1.net2.com.br with SMTP; 2 Jun 2005 04:00:13 -0000 Message-ID: <005b01c56729$449c4820$060aa8c0@alansempron> From: "Alan Tamer Vasques" To: Date: Thu, 2 Jun 2005 01:12:00 -0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Subject: [MSEC] Multisender environment 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="===============0506704963==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============0506704963== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C56710.14672990" This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C56710.14672990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all, I'm studying multicast security in multisender scenarios but I'm not = understanding some topics, mainly in the anti-replay protection. Well, GSAKMP supports this kind of scenario without trouble, because = each sender has its own SA (i.e. Data Security SA), right? On the other hand, the newer IPSec drafts (AH, ESP, IKE) say that the SA = is shared among the senders and, like that, the sequence number replay = protection doesn't work accordingly in multisender environment. My questions are: - If GSAKMP has the solution to multisender environment, why doesn't = IPSec WG adopts it in the official implementation? - Will the MSEC protocols be aggregated with IPSec? - If not, why IPSec is trying to support multicast? Thanks in advance. Regards, Alan Tamer Vasques www.alan.pro.br ------=_NextPart_000_0058_01C56710.14672990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, all,
 
I'm studying multicast security in = multisender=20 scenarios but I'm not understanding some topics, mainly in the = anti-replay=20 protection.
 
Well, GSAKMP supports this kind of = scenario=20 without trouble, because each sender has its own SA (i.e. Data Security=20 SA), right?
 
On the other hand, the newer IPSec = drafts (AH,=20 ESP, IKE) say that the SA is shared among the senders and, like that, = the=20 sequence number replay protection doesn't work accordingly in = multisender=20 environment.
 
My questions are:
 
- If GSAKMP has the solution to = multisender=20 environment, why doesn't IPSec WG adopts it in the official=20 implementation?
- Will the MSEC protocols be = aggregated with=20 IPSec?
- If not, why IPSec is trying to = support=20 multicast?
 
Thanks in advance.
 
Regards,

Alan Tamer Vasques
www.alan.pro.br
------=_NextPart_000_0058_01C56710.14672990-- --===============0506704963== 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 --===============0506704963==-- From msec-bounces@securemulticast.org Thu Jun 2 01:11:07 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11608 for ; Thu, 2 Jun 2005 01:11:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 83CE38C69D; Thu, 2 Jun 2005 01:10: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 B599F8C673 for ; Thu, 2 Jun 2005 01:10:56 -0400 (EDT) Received: (qmail 40829 invoked by uid 3269); 2 Jun 2005 05:10:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40826 invoked from network); 2 Jun 2005 05:10:56 -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; 2 Jun 2005 05:10:56 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2005 22:10:56 -0700 X-IronPort-AV: i="3.93,160,1115017200"; d="scan'208"; a="640380505:sNHT30557300" Received: from [10.32.244.213] (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j525Amlw010422; Wed, 1 Jun 2005 22:10:49 -0700 (PDT) Message-ID: <429E94D5.1010404@cisco.com> Date: Wed, 01 Jun 2005 22:10:45 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] Consensus call on draft-ietf-msec-ipsec-signatures-05.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hartmans-ietf@mit.edu, Russ Housley , Ran 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 Brian, > > I have one clarifying question inline below; in all other regards this > draft is ready for movement to RFC... Thanks for the feedback on this. One clarifying comment at end. > br, > George > > On Tue, 31 May 2005, Lakshminath Dondeti wrote: > > > >>5. Section 4.0 contains new text on combined modes and states in part >>"The RSA signatures algorithm cannot be used with an ESP Combined Mode >>algorithm that includes an explicit ICV." >> >>There is an explanation as to why. > > > I looked at this section, and it wasn't immediately obvious why there was > this restriction, x'cus me if this is a dense question ;o) > > Why could you not define an ESP header/trailer that has both the ESP > Combined Mode algorithm ICV and the RSA signature authenticator, and do > the combined mode's authenticate/encrypt payload processing with the RSA > signature data field set to zero? After the sender executes ESP Combined > Mode, it then computes the RSA signature, and fills in the zeroed field > with the signature data. On the receiver side, reserve a copy of the > signature data, zero fill the signature data field, then apply ESP > Combined Mode decryption and group authentication verification. If the > group authentication passes, then proceed to do RSA signature > verification on the original (i.e. encrypted) ESP payload that had been > signed. What you describe seems very feasible to me. However, in my opinion that's a bit more definition than should be found in a single transform document such as this. I.e., perhaps such a description would belong in some definition of ESP. Since ESP currently doesn't allow the ICV field to be used by two transforms, I expect that it would have to describe how the two transforms interact (which you've documented above). That's the heart of the change -- defining how the transforms interact, which is an ESP issue. So in the absence of the ESP modification, I was advised to put in a comment saying that this transform won't work with such a combined transform. Thanks, Brian > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 2 01:16:59 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11817 for ; Thu, 2 Jun 2005 01:16:59 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6638F8C929; Thu, 2 Jun 2005 01:16: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 501738C91E for ; Thu, 2 Jun 2005 01:16:58 -0400 (EDT) Received: (qmail 42189 invoked by uid 3269); 2 Jun 2005 05:16:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42186 invoked from network); 2 Jun 2005 05:16:58 -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; 2 Jun 2005 05:16:58 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2005 22:16:57 -0700 Received: from [10.32.244.213] (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j525Gpbw025371; Wed, 1 Jun 2005 22:16:52 -0700 (PDT) Message-ID: <429E9640.7050605@cisco.com> Date: Wed, 01 Jun 2005 22:16:48 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Tamer Vasques Subject: Re: [MSEC] Multisender environment References: <005b01c56729$449c4820$060aa8c0@alansempron> In-Reply-To: <005b01c56729$449c4820$060aa8c0@alansempron> 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 Alan, Alan Tamer Vasques wrote: > Hi, all, > > I'm studying multicast security in multisender scenarios but I'm not > understanding some topics, mainly in the anti-replay protection. > > Well, GSAKMP supports this kind of scenario without trouble, because > each sender has its own SA (i.e. Data Security SA), right? > > On the other hand, the newer IPSec drafts (AH, ESP, IKE) say that the SA > is shared among the senders and, like that, the sequence number replay > protection doesn't work accordingly in multisender environment. These documents should say that the SA *could* be shared among the senders. It would still be possible to define an individual IPsec SA for each sender, just as you describe above. > My questions are: > > - If GSAKMP has the solution to multisender environment, why doesn't > IPSec WG adopts it in the official implementation? > - Will the MSEC protocols be aggregated with IPSec? Yes. You're right that anti-replay protection is an open topic. We may address this in an upcoming MSEC draft document that clarifies some of the issues with using IPsec to protect IP multicast packets. Thanks, Brian > - If not, why IPSec is trying to support multicast? > > Thanks in advance. > > Regards, > > Alan Tamer Vasques > www.alan.pro.br > > > ------------------------------------------------------------------------ > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 2 08:16:32 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08337 for ; Thu, 2 Jun 2005 08:16:30 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6AB458C8E9; Thu, 2 Jun 2005 08:16: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 E077B8C8A6 for ; Thu, 2 Jun 2005 08:16:28 -0400 (EDT) Received: (qmail 24320 invoked by uid 3269); 2 Jun 2005 12:16:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24315 invoked from network); 2 Jun 2005 12:16:27 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 2 Jun 2005 12:16:27 -0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j52CEHCK020909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2005 05:14:18 -0700 (PDT) Received: from [10.50.65.38] (qconnect-10-50-65-38.qualcomm.com [10.50.65.38]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j52CE78A028347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2005 05:14:13 -0700 (PDT) Message-ID: <429EF80E.4050706@qualcomm.com> Date: Thu, 02 Jun 2005 08:14:06 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Weis Subject: Re: [MSEC] Consensus call on draft-ietf-msec-ipsec-signatures-05.txt References: <429E94D5.1010404@cisco.com> In-Reply-To: <429E94D5.1010404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hartmans-ietf@mit.edu, George Gross , Ran Canetti , Russ Housley , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi George, That is a good question, especially since I asked the same question :-). But, Brian is right (and I think Steve Kent or Sam Hartman who pointed this out are too). The ESPv3 definition is what it is today. Within that scope, we cannot put two ICVs into one field. If and when we define a multicast ESP, we can rewrite that part of the spec. thanks and regards, Lakshminath Brian Weis wrote: > Hi George, > > George Gross wrote: > >> Hi Brian, >> >> I have one clarifying question inline below; in all other regards this >> draft is ready for movement to RFC... > > > Thanks for the feedback on this. One clarifying comment at end. > >> br, >> George >> >> On Tue, 31 May 2005, Lakshminath Dondeti wrote: >> >> >> >>> 5. Section 4.0 contains new text on combined modes and states in part >>> "The RSA signatures algorithm cannot be used with an ESP Combined Mode >>> algorithm that includes an explicit ICV." >>> >>> There is an explanation as to why. >> >> >> >> I looked at this section, and it wasn't immediately obvious why there >> was >> this restriction, x'cus me if this is a dense question ;o) >> >> Why could you not define an ESP header/trailer that has both the ESP >> Combined Mode algorithm ICV and the RSA signature authenticator, and do >> the combined mode's authenticate/encrypt payload processing with the RSA >> signature data field set to zero? After the sender executes ESP Combined >> Mode, it then computes the RSA signature, and fills in the zeroed field >> with the signature data. On the receiver side, reserve a copy of the >> signature data, zero fill the signature data field, then apply ESP >> Combined Mode decryption and group authentication verification. If the >> group authentication passes, then proceed to do RSA signature >> verification on the original (i.e. encrypted) ESP payload that had been >> signed. > > > What you describe seems very feasible to me. However, in my opinion > that's a bit more definition than should be found in a single > transform document such as this. I.e., perhaps such a description > would belong in some definition of ESP. Since ESP currently doesn't > allow the ICV field to be used by two transforms, I expect that it > would have to describe how the two transforms interact (which you've > documented above). That's the heart of the change -- defining how the > transforms interact, which is an ESP issue. > > So in the absence of the ESP modification, I was advised to put in a > comment saying that this transform won't work with such a combined > transform. > > Thanks, > Brian > >> >> > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 2 08:18:24 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08440 for ; Thu, 2 Jun 2005 08:18:24 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DBAE58C91C; Thu, 2 Jun 2005 08:18: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 405748C8F1 for ; Thu, 2 Jun 2005 08:18:23 -0400 (EDT) Received: (qmail 24586 invoked by uid 3269); 2 Jun 2005 12:18:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24583 invoked from network); 2 Jun 2005 12:18:23 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 2 Jun 2005 12:18:23 -0000 Received: (qmail 28111 invoked from network); 2 Jun 2005 08:18:22 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 2 Jun 2005 08:18:22 -0400 Received: (qmail 9100 invoked from network); 2 Jun 2005 08:18:22 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.13) by mail1.oct.nac.net with SMTP; 2 Jun 2005 08:18:22 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j5297dX11122; Thu, 2 Jun 2005 05:07:39 -0400 Date: Thu, 2 Jun 2005 05:07:39 -0400 (EDT) From: George Gross To: Brian Weis Subject: Re: [MSEC] Consensus call on draft-ietf-msec-ipsec-signatures-05.txt In-Reply-To: <429E94D5.1010404@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Russ Housley , George Gross , Ran Canetti , hartmans-ietf@mit.edu, 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, ok, your explaination makes the origin of the restriction clearer. it sounds like the way around the restriction is to nest ESP within ESP. The outer ESP being combined mode encryption and group authentication and the inner ESP being RSA signature authentication with null encryption. I noticed that section 6.7 already talks about this option. If you think that it makes sense, would you mind adding a sentence pointing to this workaround option in that section? That would soften the restriction on AES-GCM or AES-CCM, albeit with some ESP overhead. thx, George On Wed, 1 Jun 2005, Brian Weis wrote: > Hi George, > > George Gross wrote: > > Hi Brian, > > > > I have one clarifying question inline below; in all other regards this > > draft is ready for movement to RFC... > > Thanks for the feedback on this. One clarifying comment at end. > > > br, > > George > > > > On Tue, 31 May 2005, Lakshminath Dondeti wrote: > > > > > > > >>5. Section 4.0 contains new text on combined modes and states in part > >>"The RSA signatures algorithm cannot be used with an ESP Combined Mode > >>algorithm that includes an explicit ICV." > >> > >>There is an explanation as to why. > > > > > > I looked at this section, and it wasn't immediately obvious why there was > > this restriction, x'cus me if this is a dense question ;o) > > > > Why could you not define an ESP header/trailer that has both the ESP > > Combined Mode algorithm ICV and the RSA signature authenticator, and do > > the combined mode's authenticate/encrypt payload processing with the RSA > > signature data field set to zero? After the sender executes ESP Combined > > Mode, it then computes the RSA signature, and fills in the zeroed field > > with the signature data. On the receiver side, reserve a copy of the > > signature data, zero fill the signature data field, then apply ESP > > Combined Mode decryption and group authentication verification. If the > > group authentication passes, then proceed to do RSA signature > > verification on the original (i.e. encrypted) ESP payload that had been > > signed. > > What you describe seems very feasible to me. However, in my opinion > that's a bit more definition than should be found in a single transform > document such as this. I.e., perhaps such a description would belong in > some definition of ESP. Since ESP currently doesn't allow the ICV field > to be used by two transforms, I expect that it would have to describe > how the two transforms interact (which you've documented above). That's > the heart of the change -- defining how the transforms interact, which > is an ESP issue. > > So in the absence of the ESP modification, I was advised to put in a > comment saying that this transform won't work with such a combined > transform. > > Thanks, > Brian > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 2 08:20:09 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08547 for ; Thu, 2 Jun 2005 08:20:07 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BD7AD8C9DD; Thu, 2 Jun 2005 08:20: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 3931B8C8F1 for ; Thu, 2 Jun 2005 08:20:07 -0400 (EDT) Received: (qmail 24821 invoked by uid 3269); 2 Jun 2005 12:20:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24817 invoked from network); 2 Jun 2005 12:20:07 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 2 Jun 2005 12:20:07 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j52CJwCK021269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2005 05:19:59 -0700 (PDT) Received: from [10.50.65.38] (qconnect-10-50-65-38.qualcomm.com [10.50.65.38]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j52CJpbS005883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2005 05:19:56 -0700 (PDT) Message-ID: <429EF966.9070209@qualcomm.com> Date: Thu, 02 Jun 2005 08:19:50 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Tamer Vasques Subject: Re: [MSEC] Multisender environment References: <005b01c56729$449c4820$060aa8c0@alansempron> In-Reply-To: <005b01c56729$449c4820$060aa8c0@alansempron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Alan, Those are excellent questions and I think Brian addresses them to an extent in his email. But since multisender replay protection might be one of the topics that might be under discussion for some new work we are pursuing, I encourage you to open a discussion thread so Brian and others can share their thoughts too and we can work toward consensus on what's doable. best, Lakshminath Alan Tamer Vasques wrote: > Hi, all, > > I'm studying multicast security in multisender scenarios but I'm not > understanding some topics, mainly in the anti-replay protection. > > Well, GSAKMP supports this kind of scenario without trouble, because > each sender has its own SA (i.e. Data Security SA), right? > > On the other hand, the newer IPSec drafts (AH, ESP, IKE) say that the > SA is shared among the senders and, like that, the sequence number > replay protection doesn't work accordingly in multisender environment. > > My questions are: > > - If GSAKMP has the solution to multisender environment, why doesn't > IPSec WG adopts it in the official implementation? > - Will the MSEC protocols be aggregated with IPSec? > - If not, why IPSec is trying to support multicast? > > Thanks in advance. > > Regards, > > Alan Tamer Vasques > www.alan.pro.br > >------------------------------------------------------------------------ > >_______________________________________________ >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 Jun 2 10:26:07 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19703 for ; Thu, 2 Jun 2005 10:26:06 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9AA4D8CC90; Thu, 2 Jun 2005 10:26: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 8BFE78CB86 for ; Thu, 2 Jun 2005 10:24:06 -0400 (EDT) Received: (qmail 51509 invoked by uid 3269); 2 Jun 2005 14:24:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51505 invoked from network); 2 Jun 2005 14:24:06 -0000 Received: from smtp.us1.net2.com.br (HELO us1.net2.com.br) (64.246.27.17) by klesh.pair.com with SMTP; 2 Jun 2005 14:24:06 -0000 Received: (qmail 30128 invoked by uid 513); 2 Jun 2005 14:11:55 -0000 Received: from atv@alan.pro.br by us1.net2.com.br by uid 101 with qmail-scanner-1.22 (f-prot: 4.4.1/3.14.11. Clear:RC:1(200.157.179.240):. Processed in 0.376435 secs); 02 Jun 2005 14:11:55 -0000 Received: from m1.net2.com.br (200.157.179.240) by us1.net2.com.br with SMTP; 2 Jun 2005 14:11:54 -0000 Received: from 200.129.132.210 (SquirrelMail authenticated user atv@alan.pro.br) by m1.net2.com.br with HTTP; Thu, 2 Jun 2005 12:24:38 -0300 (BRT) Message-ID: <2124.200.129.132.210.1117725878.squirrel@m1.net2.com.br> In-Reply-To: <429E9640.7050605@cisco.com> References: <005b01c56729$449c4820$060aa8c0@alansempron> <429E9640.7050605@cisco.com> Date: Thu, 2 Jun 2005 12:24:38 -0300 (BRT) Subject: Re: [MSEC] Multisender environment From: "Alan Tamer Vasques" To: "Brian Weis" User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal 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 Brian, Actually, the ESPv3 draft ( http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-10.txt ) says: "Sharing an SA among multiple senders is permitted, though generally not recommended. ESP provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Thus, for a multi-sender SA, the anti-replay features of ESP are not available." AH draft has the same text. You said that it's possible to define an individual IPsec SA for each sender, but imagine this scenario: I have two GCKS that manage a multi-sender group (where each GCKS is responsible for one or more senders) and a receiver that listens to all senders. If the group controllers attribute the same SPI (it can happen) to two different senders, how the receiver can identify the correct one? Replay protection will not function correctly, right? Regards, Alan Tamer Vasques www.alan.pro.br Brian Weis disse: > Hi Alan, > > Alan Tamer Vasques wrote: >> Hi, all, >> >> I'm studying multicast security in multisender scenarios but I'm not >> understanding some topics, mainly in the anti-replay protection. >> >> Well, GSAKMP supports this kind of scenario without trouble, because >> each sender has its own SA (i.e. Data Security SA), right? >> >> On the other hand, the newer IPSec drafts (AH, ESP, IKE) say that the SA >> is shared among the senders and, like that, the sequence number replay >> protection doesn't work accordingly in multisender environment. > > These documents should say that the SA *could* be shared among the > senders. It would still be possible to define an individual IPsec SA for > each sender, just as you describe above. > >> My questions are: >> >> - If GSAKMP has the solution to multisender environment, why doesn't >> IPSec WG adopts it in the official implementation? >> - Will the MSEC protocols be aggregated with IPSec? > > Yes. You're right that anti-replay protection is an open topic. We may > address this in an upcoming MSEC draft document that clarifies some of > the issues with using IPsec to protect IP multicast packets. > > Thanks, > Brian > >> - If not, why IPSec is trying to support multicast? >> >> Thanks in advance. >> >> Regards, >> >> Alan Tamer Vasques >> www.alan.pro.br _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 2 12:34:56 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05220 for ; Thu, 2 Jun 2005 12:34:55 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 087A08C707; Thu, 2 Jun 2005 12:34: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 572818C6C2 for ; Thu, 2 Jun 2005 12:34:56 -0400 (EDT) Received: (qmail 81265 invoked by uid 3269); 2 Jun 2005 16:34:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81262 invoked from network); 2 Jun 2005 16:34:56 -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; 2 Jun 2005 16:34:56 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2005 09:34:55 -0700 X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="273268158:sNHT29577644" Received: from [10.32.244.213] (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j52GYqbw016349; Thu, 2 Jun 2005 09:34:53 -0700 (PDT) Message-ID: <429F3526.4010403@cisco.com> Date: Thu, 02 Jun 2005 09:34:46 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Tamer Vasques Subject: Re: [MSEC] Multisender environment References: <005b01c56729$449c4820$060aa8c0@alansempron> <429E9640.7050605@cisco.com> <2124.200.129.132.210.1117725878.squirrel@m1.net2.com.br> In-Reply-To: <2124.200.129.132.210.1117725878.squirrel@m1.net2.com.br> 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 Alan, Alan Tamer Vasques wrote: > Hi Brian, > > Actually, the ESPv3 draft ( > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-10.txt ) says: > > "Sharing an SA among multiple senders is permitted, though generally not > recommended. ESP provides no means of synchronizing packet counters among > multiple senders or meaningfully managing a receiver packet counter and > window in the context of multiple senders. Thus, for a multi-sender SA, > the anti-replay features of ESP are not available." > > AH draft has the same text. Right, now anti-replay is currently "not available" for a multi-sender SA because how to do it has not been agreed upon and specified. We're hoping to fix that. > You said that it's possible to define an individual IPsec SA for each > sender, but imagine this scenario: I have two GCKS that manage a > multi-sender group (where each GCKS is responsible for one or more > senders) and a receiver that listens to all senders. If the group > controllers attribute the same SPI (it can happen) to two different > senders, how the receiver can identify the correct one? Replay protection > will not function correctly, right? Actually, this is a matter of making sure the SA lookup finds the correct SA. You're correct that in RFC 2401 this is a problem because the three-tuples of {protocol, destination, SPI} of the two SAs would be identical. This was corrected in RFC2401bis. Section 4.1 of http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-06.txt describes when the source address is used in the SA lookup. This was added for the exact case you mention. Once the correct SA is found, replay protection should function correctly. Thanks, Brian > Regards, > > Alan Tamer Vasques > www.alan.pro.br > > > Brian Weis disse: > >>Hi Alan, >> >>Alan Tamer Vasques wrote: >> >>>Hi, all, >>> >>>I'm studying multicast security in multisender scenarios but I'm not >>>understanding some topics, mainly in the anti-replay protection. >>> >>>Well, GSAKMP supports this kind of scenario without trouble, because >>>each sender has its own SA (i.e. Data Security SA), right? >>> >>>On the other hand, the newer IPSec drafts (AH, ESP, IKE) say that the SA >>>is shared among the senders and, like that, the sequence number replay >>>protection doesn't work accordingly in multisender environment. >> >>These documents should say that the SA *could* be shared among the >>senders. It would still be possible to define an individual IPsec SA for >>each sender, just as you describe above. >> >> >>>My questions are: >>> >>>- If GSAKMP has the solution to multisender environment, why doesn't >>>IPSec WG adopts it in the official implementation? >>>- Will the MSEC protocols be aggregated with IPSec? >> >>Yes. You're right that anti-replay protection is an open topic. We may >>address this in an upcoming MSEC draft document that clarifies some of >>the issues with using IPsec to protect IP multicast packets. >> >>Thanks, >>Brian >> >> >>>- If not, why IPSec is trying to support multicast? >>> >>>Thanks in advance. >>> >>>Regards, >>> >>>Alan Tamer Vasques >>>www.alan.pro.br > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 2 14:08:02 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12435 for ; Thu, 2 Jun 2005 14:08:02 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 40EA88C6F9; Thu, 2 Jun 2005 14:08: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 A5AAC8C08E for ; Thu, 2 Jun 2005 14:08:02 -0400 (EDT) Received: (qmail 98370 invoked by uid 3269); 2 Jun 2005 18:08:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98367 invoked from network); 2 Jun 2005 18:08:02 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 2 Jun 2005 18:08:02 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j52I7qCK023196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2005 11:07:52 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j52I7lFH006627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Jun 2005 11:07:48 -0700 (PDT) Message-ID: <429F4B01.4070108@qualcomm.com> Date: Thu, 02 Jun 2005 14:08:01 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti , Russ Housley , aboba@internaut.com, jmandin@streetwaves-networks.com Subject: [MSEC] [Fwd: MSEC review of 802.16e MBS security] X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi all, This is in response to a formal request for review from the 802.16 group. I am cc'ing the IETF liaison (Bernard Aboba) and the AD so they are aware of our efforts. Jeff Mandin is the 802.16 liaison to the IETF. The liaison letters are available from below: http://ieee802.org/16/liaison/docs/L80216-05_025.pdf http://ieee802.org/16/liaison/docs/L80216-05_039.pdf We need a few volunteers to review a few sections (related to multicast and broadcast security) in the 802.16e specification, and prepare what amounts to a security considerations (identify any vulnerabilities in the 16e specification and suggest mitigation techniques or strategies) document. I know a bit about the 802.16 specification, and speaking from experience, it should not take more than a few hours of your time given this group's knowledge in multicast and group security protocols. Please volunteer and read Jeff's proposed outline below. If you are interested, please send Ran and I an email. Thanks in advance. best regards, Lakshminath -------- Original Message -------- Subject: MSEC review of 802.16e MBS security Date: Wed, 1 Jun 2005 12:38:59 +0200 From: Jeff Mandin Reply-To: jmandin@streetwaves-networks.com To: ldondeti@qualcomm.com Lakshminath hi, Hope things are going well at Qualcomm. Now that the EAP WG's review is in full swing, I'd like to move ahead with the MSEC review discussed before. The material to be reviewed would be section 7.8.3 of 802.16e draft D8, and any additional sections that are perceived by the reviewers as relevant (ie. 7.8.4.1 AES-CTR and 7.2.2.2 key derivation). The purpose of the review would of course be to note any security issues and assist 16e in resolving them. The EAP review is probably a good model for how this can work: - 2-3 people from MSEC would be the formal reviewers - a mailing list would be set up and include the reviewers, 1-3 people from 802.16 (probably me and 1-2 of the people behind MBS), and perhaps other specific people from MSEC if there is interest. Initial reflector discussions (and hopefully telecons) would focus on understanding what's actually in the 802.16 spec. - MSEC would then prepare an initial review document outlining any issues and make it available to a broader group of .16 members for response and discussion of solutions. - .16e would then propose changes at the next recirc, and MSEC would send a formal liaison letter to 802.16 in advance of the 7/17 San Francisco 802 meeting. How does this sound? If it's feasible, then we can put together a specific timeline for the next 6 weeks. BRs, - Jeff _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Jun 3 20:01:58 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26562 for ; Fri, 3 Jun 2005 20:01:58 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DA76C8C537; Fri, 3 Jun 2005 20:01: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 06AB88C4EE for ; Fri, 3 Jun 2005 20:01:57 -0400 (EDT) Received: (qmail 37778 invoked by uid 3269); 4 Jun 2005 00:01:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37775 invoked from network); 4 Jun 2005 00:01:56 -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; 4 Jun 2005 00:01:56 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Jun 2005 17:00:43 -0700 X-IronPort-AV: i="3.93,168,1115017200"; d="scan'208"; a="274115418:sNHT8771982432" Received: from [128.107.163.230] (dhcp-128-107-163-230.cisco.com [128.107.163.230]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5400dlw026748; Fri, 3 Jun 2005 17:00:40 -0700 (PDT) Message-ID: <42A0EF24.5040806@cisco.com> Date: Fri, 03 Jun 2005 17:00:36 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ijackson@chiark.greenend.org.uk Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org Subject: [MSEC] Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Ian, This email is a response to Last Call comments you made some time ago regarding an MSEC WG draft. Unfortunately your comments did not actually make it onto the WG mailing list. Sam Hartman recently forwarded them to us. We are now at draft-ietf-msec-ipsec-signatures-05.txt, and I believe we have resolved or answered the issues you raise below. However, I've also answered them directly below inline between snippets of your original comments. >1. It is unclear what is specified >---------------------------------- > >The whole point of the RSA-ESP/EH specification is to unambiguously >tie the concepts and protocol elements specified in RSA (RFC3447) to >those specified in ESP (currently envisaged by the RSA-ESP/EH draft as >draft-ietf-ipsec-esp-v3-09.txt). > >It appears that section 2.0 `Algorithm and Mode' of >draft-ietf-msec-ipsec-signatures-03.txt is intended to do this. > >It should explicitly state, in the terminology of >draft-ietf-ipsec-esp-v3 and RFC3447: > >* Which value in RFC3447 corresponds to the byte string whose ICV > is to be calculated (this byte stream is defined by the ESP and > AH specifications). > >* Whether padding is required (see eg draft-ietf-ipsec-esp-v3-09 > 3.3.2.1 final paragraph). (It seems unlikely that a sensible RSA > embedding in IPSEC would require padding.) > >* Which value from RFC3447 corresponds to the ICV. > >* What the length of the ICV is (eg draft-ietf-ipsec-esp-v3-09 2.8) > or if it varies per packet, how the length is encoded. > >etc. The above specification elements were indeed missing, and have been added to Section 2.0. >2. Specified algorithm is not best current cryptographic practice >----------------------------------------------------------------- > >Guessing the answers to the questions above, it seems that what is >specified is some kind of ad-hoc variation on RSA OAEP. OAEP is an >_encryption_ sheme, intended to provide _confidentiality_ and is >completely inappropriate as an integrity mechanism. This was indeed a horrible mistake. The original intent was to do what IKEv1 specified for signatures, especially given that IKEv2 does little better in specifying the padding method. IKEv1 specifies an _encryption_ PKCS#1.5 padding, with the rationale of not needing to encode the hash algorithm in the signature as required by RSASSA-PKCS1-v1_5 in RFC 3447. The draft you reviewed followed suit, because the expectation is that it will be deployed in the same products containing IKE, and there would be considerable implementation value to performing the same operations. However, awareness of the IKEv2 padding under-specification has now been raised in the IPsec community, and it is not clear what kinds of padding will be used with IKEv2. Therefore it is no longer clear that there is any value at all to the IKEv1 scheme. As a result, version 05 of the IPsec signatures draft now specifies the integrity padding methods as defined in RFC 3447. This matches your recommendation of using an integrity mechanism. >3. Best cryptographic practice is to use PSS (RFC3447's RSASSA-PSS) >------------------------------------------------------------------- > >RSA PSS (RFC3447's RSASSA-PSS) is widely acknowledged in the >cryptographic community to be significantly superior to earlier RSA >padding schemes. There is no good reason presented in >draft-ietf-msec-ipsec-signatures-03 for not using it, and there >probably is no good reason not to use it. Although PSS is acknowledged to be superior to PKCS#1.5, it has the difficulties that 1) it is not as widely deployed as PKCS#1.5, and 2) it has not been explicitly cleared for use by the IETF by the PSS patent holder. Therefore, it is not reasonable to require the use of PSS. PSS has been included in the draft as a choice, but not as a MUST. If you have any further comments or questions on the draft, please send them directly to msec@securemulticast.org. Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 6 15:21:03 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01275 for ; Mon, 6 Jun 2005 15:21:03 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E855F8C46F; Mon, 6 Jun 2005 15:21: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 1A7C48C00D for ; Mon, 6 Jun 2005 15:21:02 -0400 (EDT) Received: (qmail 89824 invoked by uid 3269); 6 Jun 2005 19:21:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89818 invoked from network); 6 Jun 2005 19:21:01 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 6 Jun 2005 19:21:01 -0000 Received: (qmail 67609 invoked from network); 6 Jun 2005 15:20:59 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 6 Jun 2005 15:20:59 -0400 Received: (qmail 18510 invoked from network); 6 Jun 2005 15:20:58 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.13) by mail1.oct.nac.net with SMTP; 6 Jun 2005 15:20:58 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j56G9XM22845; Mon, 6 Jun 2005 12:09:33 -0400 Date: Mon, 6 Jun 2005 12:09:33 -0400 (EDT) From: George Gross To: , ran canetti , andrea Colegrove , hugh Harney , Subject: Re: [MSEC] MSEC WG Last Call: draft-ietf-msec-policy-token-sec-02.txt (closing June 10, 2005) In-Reply-To: <428CD7F0.7010909@qualcomm.com> 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 Hi, I have reviewed and compiled (using eSNACC v1.7) the core policy token ASN.1 specified in this v02 draft's appendices. there were a few minor syntaxical corrections needed to get to a clean compile, and I've worked off the list with Andrea wrt/ those. I'd like to see these published in the next rev of the Internet Draft. Overall, I support the advancement of this core PT draft to Proposed Standard. The set of group security policies expressible by the core PT is a reasonable starting point for growing application-specific group security policy ASN.1 specs based on this spec. That said, there are several areas in the current draft that I would like to hear the opinion of other MSEC members, especially those with ASN.1 design experience in other IETF standards. since I am relatively new to using ASN.1 as a designer, there is a certain amount of wisdom through experience that would influence how one would encode group policy for the following design problems: 1) The merits/drawbacks of encoding the "SecuritySuite" as an OID versus an INTEGER. 2) The merits/drawbacks of introducing a GSAKMPIdType as an enumerated list for the GSAKMPID object, with the enumeration's values matching those declared the GSAKMP protocol spec Table 19. 3) Should the "KeyIdentifier" OID definition be imported from the certificate extensions ASN spec rather than using the explicit definition found in the draft's appendices? 4) The registration, de-registration, and rekey protocols are all currently defined as being of type "GroupMngmtProtocol", which turns to be "protocolInfo OCTET STRING". In effect, this is a textual convention that requires the implementor to validate the OCTET STRING rather than rely on ASN syntax checking. IMHO, I would have thought it would a more extensible syntax to have defined a CHOICE for each of these protocols with an ANY type as one of the choices. This resembles the construct used for a GeneralName within the SubjectAltNames of a certificate. For example, the rekey protocol choice would be expressed as follows in this alternative method: ------------------------------------------------------------ -- RekeyProtocol RekeyProtocol ::= CHOICE { other-rekey [0] Other-Rekey, none [1] NULL, gsakmp-rekey-v01 [2] GSAKMPv1RekeyInfo } Other-Rekey ::= SEQUENCE { rekey-proto-id OBJECT IDENTIFIER, rekey-type ANY DEFINED BY rekey-proto-id } what do people think of this alternative encoding using CHOICE in combination with "ANY DEFINED BY"? tia, George On Thu, 19 May 2005, Lakshminath Dondeti wrote: > Hi all, > > This is an MSEC WG last call for comments on > http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-02.txt > closing on > June 10, 2005 AOE. > > Track: Standards Track, Proposed Standard > > If you have questions or if you think the draft is not ready to move > forward, please send your comments to the list. If you think that it > looks ready to be forwarded to the IESG, we want to hear from you also. > If you don't care, we want to know that as well :-). > > Note that the Policy Token is generic and can be used with GDOI as well > as other key management protocols in addition to GSAKMP. So, please > take some time to review this. > > We would also like to hear about any implementations of the policy token > spec (Andrea, do you know of any implementations?). > > regards, > Lakshminath > > Draft details: > Title: Group Policy Token V1 with Application to GSAKMP > Authors: A. Colegrove and H. Harney > > Abstract: > > The Policy Token is a structure used to specify the security > policy and configurable parameters for a cryptographic group, such > as a secure multicast group. This document specifies the structure > of such a token in order to securely bind system-level security to > protocols supporting the management of cryptographic groups. > > _______________________________________________ > 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 Jun 7 13:01:34 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11203 for ; Tue, 7 Jun 2005 13:01:33 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 131DA8CAE0; Tue, 7 Jun 2005 13:01: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 298178CAB2 for ; Tue, 7 Jun 2005 13:01:35 -0400 (EDT) Received: (qmail 46510 invoked by uid 3269); 7 Jun 2005 17:01:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46507 invoked from network); 7 Jun 2005 17:01:35 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 7 Jun 2005 17:01:35 -0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j57H19dv015527; Tue, 7 Jun 2005 10:01:09 -0700 (PDT) Received: from [129.46.75.106] (ldondeti.na.qualcomm.com [129.46.75.106]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j57H148u001976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jun 2005 10:01:05 -0700 (PDT) Message-ID: <42A5D2CB.7040703@qualcomm.com> Date: Tue, 07 Jun 2005 13:00:59 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Perrig , tygar@cs.berkeley.edu, dawnsong@cmu.edu, bob.briscoe@bt.com Subject: Re: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> <4297286C.9050802@qualcomm.com> <425c417e57be178d968105723ab2a260@cisco.com> <42976154.5000803@qualcomm.com> <429B1188.8090301@ece.cmu.edu> <0556c1f631f485172bf342a58ce6e4de@cisco.com> <429E2997.9030707@qualcomm.com> In-Reply-To: <429E2997.9030707@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Hartman , canetti@watson.ibm.com, Russ Housley , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi Adrian/Dawn/Bob/Doug/Ran, I saw several OoO messages in response to my emails last week, with back in office time as this week. Let us please close discussion on this I-D/RFC and make the necessary changes so the RFC Editor can publish it. I strongly think it does not hurt to keep the content of Section 3.7 (revised of course). If you feel that section must be deleted, please include a few sentences in the security considerations on this topic. I think that is a fair compromise so we can move forward. Please respond to this email on your decision and send your changes to the RFC Editor. If 3.7 is to be deleted, please make sure -- as Bob noted -- that all references to 3.7 are also deleted. Many thanks for your work on this and also for your thorough reviews. best regards, Lakshminath PS: I am going to be taking time-off on Wed and Thu, so might not be able to hold an email conversation. Lakshminath Dondeti wrote: > Hi Adrian, > > Mark's suggestion sounds good to me. I can't say there is any > consensus on this one way or another, but we need to close this ASAP. > > All, > > We need opinions on this to reach consensus. > > regards, > Lakshminath > > > Mark Baugher wrote: > >> Adrian >> We might want to summarize this discussion in a sentence or two in >> the I-D in order to document what is known. >> >> Mark >> On May 30, 2005, at 6:13 AM, Adrian Perrig wrote: >> >>> Hi, >>> >>> Given the limited usefulness of dynamically altering the disclosure >>> delay and the security vulnerability that is created by dynamically >>> shortening the disclosure delay, I vote to remove this section. >>> For the argument that "it's good to keep it to discuss potential >>> implementation errors," we would need to add a lot of other >>> potential errors as well. Best, >>> Adrian >>> >>>> Mark, >>>> Thanks for sharing your thoughts on this. >>>> I don't have a specific use case in mind for this feature. >>>> However, given where we are in the process, and also considering >>>> that this is an informational RFC, my inclination is to suggest >>>> providing information on the proverbial "what happens if we do this >>>> vs. that" in the soon to be RFC. Deleting the section and all >>>> references to that section is certainly an option too. I am >>>> proposing that providing that information would be useful (a record >>>> of the discussion so to speak). >>>> When it comes to TESLA-SPEC, perhaps I will agree with a SHOULD NOT >>>> for changing the disclosure delay within a TESLA session. Of >>>> course that goes along with a security considerations section that >>>> contains a summary of this discussion on what happens if the >>>> disclosure delay were to be changed. >>>> best regards, >>>> Lakshminath >>>> (NOT as MSEC co-chair) >>>> Mark Baugher wrote: >>>> >>>>> Lakshminath, >>>>> I don't see any value to altering the disclosure delay. >>>>> >>>>> Mark >>>>> On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote: >>>>> >>>>>> Adrian, >>>>>> >>>>>> Thanks. As Steffen notes, if the receiver receives any >>>>>> legitimate packet after the disclosure delay change, then it >>>>>> would know that the delay has changed, right? (Of course there >>>>>> is the threat of an adversary acting as a MiTM after a >>>>>> disclosure delay reduction and modify all pertinent information >>>>>> to continue to fool the victim). Furthermore, isn't increasing >>>>>> the disclosure delay ok? >>>>>> >>>>>> I am thinking perhaps Section 3.7 could remain but with >>>>>> appropriate modifications to reflect your notes below and >>>>>> perhaps answering some of the questions above. (As a side note, >>>>>> that will allow all references to Section 3.7 to remain, and the >>>>>> reader -- this is an Informational RFC -- would have information >>>>>> on whether or not dynamically changing disclosure delay is ok). >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> regards, >>>>>> Lakshminath >>>>>> NOT as co-chair of the group >>>>>> >>>>>> >>>>>> Adrian Perrig wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Allowing a sender to dynamically alter the disclosure schedule >>>>>>> of keys >>>>>>> is very dangerous, and removes the property of TESLA to be >>>>>>> robust to >>>>>>> packet loss. Consider the following example. In packet P_i, a >>>>>>> sender >>>>>>> would announce that K_j that was supposed to be published after >>>>>>> time >>>>>>> T_j is now going to be published earlier. If a receiver misses this >>>>>>> packet, the receiver will still believe that K_j is published after >>>>>>> time T_j, so an attacker can forge packets for that receiver when >>>>>>> obtaining K_j before time T_j. >>>>>>> >>>>>>> This example illustrates that it is dangerous to alter a disclosure >>>>>>> schedule and that is why I suggested removing Section 3.7. This >>>>>>> section was supposed to be removed earlier, but maybe due to >>>>>>> version >>>>>>> control issues it has somehow survived. >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>>> Hi all, > >>>>>>>> **Please note that this document is in RFC Editor Auth-48 >>>>>>>> stage, so >>>>>>>> please respond as soon as you can.** >>>>>>>> >>>>>>>> Adrian suggests that Section 3.7 from >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro >>>>>>>> -04.txt >>>>>>>> be deleted (please see Adrian's note below). >>>>>>>> >>>>>>>> I have several requests: >>>>>>>> >>>>>>>> * I-D authors referring to this document: please check to see >>>>>>>> if this >>>>>>>> impacts your documents. >>>>>>>> * All WG members: please comment on whether you are ok with >>>>>>>> removing >>>>>>>> Section 3.7. >>>>>>>> * Adrian: please elaborate on the vulnerability (or post a >>>>>>>> link to a >>>>>>>> reference that does). >>>>>>>> >>>>>>>> Note: This is to be an informational RFC. >>>>>>>> >>>>>>>> thanks and regards, >>>>>>>> Lakshminath >>>>>>>> >>>>>>>> >>>>>>>> Russ Housley wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Adrian: >>>>>>>>> >>>>>>>>> This is a fairly large change at this stage. Since this is a >>>>>>>>> MSEC WG >>>>>>>>> document, it should be coordinated with the WG. >>>>>>>>> >>>>>>>>> MSEC WG Chairs: >>>>>>>>> >>>>>>>>> Please confirm that this change does not impact consensus. >>>>>>>>> >>>>>>>>> Russ >>>>>>>>> >>>>>>>>> At 07:27 PM 5/23/2005, Adrian Perrig wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Section 3.7: >>>>>>>>>> The entire section must be deleted. Dynamically >>>>>>>>>> changing time >>>>>>>>>> intervals introduces a security vulnerability and TESLA loses >>>>>>>>>> the >>>>>>>>>> resilience to packet loss property. >>>>>>>>> >>>>>>>>> >>> >> > _______________________________________________ > 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 Jun 10 09:51:06 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21178 for ; Fri, 10 Jun 2005 09:51:05 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0ABDE8CAC0; Fri, 10 Jun 2005 09:50: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 457508CAA5 for ; Fri, 10 Jun 2005 09:50:49 -0400 (EDT) Received: (qmail 91547 invoked by uid 3269); 10 Jun 2005 13:50:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91544 invoked from network); 10 Jun 2005 13:50:49 -0000 Received: from bache.ece.cmu.edu (128.2.129.23) by klesh.pair.com with SMTP; 10 Jun 2005 13:50:49 -0000 Received: from FINCH.ECE.CMU.EDU (FINCH.ECE.CMU.EDU [128.2.134.43]) by bache.ece.cmu.edu (Postfix) with ESMTP id 27FCC74; Fri, 10 Jun 2005 09:50:48 -0400 (EDT) Date: Fri, 10 Jun 2005 09:50:48 -0400 (EDT) From: Adrian Perrig To: Lakshminath Dondeti Subject: Re: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted) In-Reply-To: <42A5D2CB.7040703@qualcomm.com> Message-ID: References: <20050518231230.GQ2760@isi.edu> <429266E7.6080302@ece.cmu.edu> <6.2.1.2.2.20050524114414.03c82de0@mail.binhost.com> <429350A3.2000808@qualcomm.com> <4297286C.9050802@qualcomm.com> <425c417e57be178d968105723ab2a260@cisco.com> <42976154.5000803@qualcomm.com> <429B1188.8090301@ece.cmu.edu> <0556c1f631f485172bf342a58ce6e4de@cisco.com> <429E2997.9030707@qualcomm.com> <42A5D2CB.7040703@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Doug Tygar , Dawn Xiaodong Song , Ran Canetti , Russ Housley , bob.briscoe@bt.com, msec@securemulticast.org, Alice Hagens , Sam Hartman , RFC Editor 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, Sorry for the delay with this, I have been traveling. Given the consensus of the MSEC community, we have worked out the following changes to the draft, for completeness, I also add my earlier changes and the second round of changes that Bob Briscoe suggested. Best wishes, Adrian Section 5 (Security Considerations), add the following as second paragraph. NEW: It should be noted that a change to the key disclosure schedule for a message stream should never be declared within the message stream itself. This would introduce a vulnerability, because a receiver that did not receive the notification of the change would still believe in the old key disclosure schedule. >Section 2, last line of the bullet list: >OLD: > others later. > >NEW: > a third party. > >Section 2.2, first sentence of first item. >OLD: > 1. The sender and the receiver must be > able to synchronize loosely. > >NEW: > 1. The sender and the receiver must be > loosely time synchronized. > ^^^^^^^^^^^^^^^^^^^^^^^^^ > >Section 2.2, final item (unitemize). >OLD: > 4. We would like to emphasize that the security of TESLA does NOT > rely on any assumptions about network propagation delay. >NEW: > We would like to emphasize that the security of TESLA does NOT > rely on any assumptions about network propagation delay. > >Section 3.2, 4th paragraph >OLD: > It is stressed that the scheme remains secure for any > values of T_int and d. >NEW: > It is stressed that the scheme remains secure for any > values of T_int and d>0. > ^^ >Section 3.3, last sentence of 2nd bullet >OLD: > signature against the public key of the signer.) >NEW: > signature with the public key of the signer.) > ^^^^ >Section 3.3, 3rd bullet >OLD: > - T_0, the start time of interval 1. >NEW: > - T_0, the start time of interval 0. > ^ >Section 3.7: > The entire section must be deleted. Dynamically changing time > intervals introduces a security vulnerability and TESLA loses the > resilience to packet loss property. Table of Contents OLD: 3.7. An Alternative Delay Description Method ...................13 3.8. Denial of Service Protection ..............................14 3.8.1. Additional Group Authentication ....................15 3.8.2. Not Re-using Keys ..................................15 3.8.3. Sender Buffering ...................................18 NEW (page numbering will also need altering): 3.7. Denial of Service Protection ..............................14 3.7.1. Additional Group Authentication ....................15 3.7.2. Not Re-using Keys ..................................15 3.7.3. Sender Buffering ...................................18 Section 3.6 penultimate paragraph. (Delete last sentence) OLD: If such authentication delay is too pessimistic, the adaptive approach of Section 3.7 may be an alternative, with the expense of extra packet overhead. NEW: (sentence deleted) Section 3.7.2 (renumber to section 3.7.2) OLD: The rule of thumb for calculating d, the key disclosure delay, remains unchanged from that given in Section 3.6; or the explicit disclosure delay method in Section 3.7 can also be used. NEW: (last clause deleted) The rule of thumb for calculating d, the key disclosure delay, remains unchanged from that given in Section 3.6. ^ >Section 7 > >OLD: > [6] P. Rohatgi, "A hybrid signature scheme for multicast source > authentication", Work in Progress, June 1999. > >NEW (drop reference as it is redundant with reference [5]: _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 13 17:28:01 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07547 for ; Mon, 13 Jun 2005 17:28:00 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D2AB58C31C; Mon, 13 Jun 2005 17: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 934AA8C12C for ; Mon, 13 Jun 2005 17:27:59 -0400 (EDT) Received: (qmail 56884 invoked by uid 3269); 13 Jun 2005 21:27:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56880 invoked from network); 13 Jun 2005 21:27:59 -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; 13 Jun 2005 21:27:59 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2005 14:27:12 -0700 X-IronPort-AV: i="3.93,195,1115017200"; d="txt'208?scan'208,208"; a="278206453:sNHT1304811036" Received: from [128.107.163.236] (dhcp-128-107-163-236.cisco.com [128.107.163.236]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5DLR9lq017409; Mon, 13 Jun 2005 14:27:10 -0700 (PDT) Message-ID: <42ADFA2E.6050602@cisco.com> Date: Mon, 13 Jun 2005 14:27:10 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard References: <42A0EF24.5040806@cisco.com> In-Reply-To: <42A0EF24.5040806@cisco.com> Content-Type: multipart/mixed; boundary="------------070501050200040705090904" Cc: ijackson@chiark.greenend.org.uk 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. --------------070501050200040705090904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Jackson had the attached comments on draft-ietf-msec-ipsec-signatures-05.txt. He was not able to post them to the list directly. Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --------------070501050200040705090904 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ian_jackson_comments.txt" Content-Disposition: inline; filename="ian_jackson_comments.txt" Content-Transfer-Encoding: 7bit Subject: Re: Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard From: Ian Jackson Date: Mon, 6 Jun 2005 12:37:38 +0100 To: Brian Weis, msec@multicast.org, msec@securemulticast.org Brian Weis writes: >> We are now at draft-ietf-msec-ipsec-signatures-05.txt, and I believe >> we have resolved or answered the issues you raise below. However, >> I've also answered them directly below inline between snippets of >> your original comments. Thanks. (I have reformatted your mail when quoting it, as it had serious wrap damage. You need to get better email software.) I've reviewed the -05 draft and I think it's barely adequate; there are things that really should to be improved if it's not too late in the process. I'm still disappointed by the lack of quality and precision in draft-05's s2.0, which is the heart of the specification. >>> >1. It is unclear what is specified >>> > >>> >The whole point of the RSA-ESP/EH specification is to unambiguously >>> >tie the concepts and protocol elements specified in RSA (RFC3447) >>> >to those specified in ESP (currently envisaged by the RSA-ESP/EH >>> >draft as draft-ietf-ipsec-esp-v3-09.txt). ... >> The above specification elements were indeed missing, >> and have been added to Section 2.0. The new language in section 2 is now just about adequate. A really close reading by an honest reader leaves no other interpretation but the one presumably intended. A careless or disingenuous reader (for example, a busy implementor, and then later the same implementor having implemented something different) might manage to come up with a deviant reading. It's still very oblique. My experience with documents of this kind - which refer to parts of other protocols which have different terminologies and backgrounds - is that it is best to be explicit, and to explicitly and carefully use the terminology from the two documents being joined. Specifically, in this case, draft-05 s2.0 says `The authenticated portion of the AH or ESP packet is given to the signature generation function'. The term `signature generation function' is not defined by PKCS#1; and `given to' is somewhat vague. The RSA-AH document should explicitly state the name given to the corresponding value in PKCS#1, ie `M'. It should say something like `the authenticated portion of the AH or ESP packet ([AH] 3.3.3) is used as the message M and passed to the signature generation operation ([RSA] 8.1.1, 8.2.1). draft-05 s2.0 doesn't explicitly say what's done with the signature; it doesn't talk about the `ICV' (RFC2402 2.6) - preferring its own term `authenticator value' - and it doesn't mention S (PKCS#1 8.1.1, 8.2.1) let alone state that S and the ICV are identical. draft-05 s2.0 does say that the ICV (which it calls the `authenticator value') `is equal to the size of the RSA modulus' which is at least somewhat helpful but strictly speaking incorrect - it is in fact equal _in size_ to the RSA modulus; the ICV value is not equal to the modulus size. This is perhaps less explicit than RFC2402's requirement that `The authentication algorithm specification MUST specify the length of the ICV' since it's not clear whether it refers to a bit length or byte length or should perhaps even be rounded up. RFC2402 also says `The authentication algorithm specification MUST specify [...] the comparison rules and processing steps for validation' which draft-05 does not. >> As a result, version 05 of the IPsec signatures draft now specifies >> the integrity padding methods as defined in RFC 3447. This matches >> your recommendation of using an integrity mechanism. So I see. This is good. >> Although PSS is acknowledged to be superior to PKCS#1.5, it has the >> difficulties that 1) it is not as widely deployed as PKCS#1.5, and >> 2) it has not been explicitly cleared for use by the IETF by the PSS >> patent holder. Therefore, it is not reasonable to require the use >> of PSS. PSS has been included in the draft as a choice, but not as a >> MUST. Lack of wide deployment is not a reason not to specify a superior algorithm in a new standard. The PSS patent isn't really a problem, is it ? The University of California have said they'll licence it appropriately if it is made an IEEE standard - can't we get a similar statement for the IETF ? >> If you have any further comments or questions on the draft, please >> send them directly to msec@securemulticast.org. I did so with my previous comments, but you say that the WG didn't receive them. I note that the domain name in your own CC was `multicast.org' rather than `securemulticast.org'. I've CC'd both. Ian. Re: Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard.eml Content-Type: message/rfc822 --------------070501050200040705090904 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 --------------070501050200040705090904-- From msec-bounces@securemulticast.org Mon Jun 13 17:35:52 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08111 for ; Mon, 13 Jun 2005 17:35:52 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 503BE8C715; Mon, 13 Jun 2005 17:35: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 8F4038C729 for ; Mon, 13 Jun 2005 17:35:52 -0400 (EDT) Received: (qmail 58389 invoked by uid 3269); 13 Jun 2005 21:35:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58378 invoked from network); 13 Jun 2005 21:35:51 -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; 13 Jun 2005 21:35:51 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2005 14:35:51 -0700 X-IronPort-AV: i="3.93,195,1115017200"; d="scan'208"; a="643328181:sNHT30303406" Received: from [128.107.163.236] (dhcp-128-107-163-236.cisco.com [128.107.163.236]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5DLZmlq025010; Mon, 13 Jun 2005 14:35:49 -0700 (PDT) Message-ID: <42ADFC3A.9050302@cisco.com> Date: Mon, 13 Jun 2005 14:35:54 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ijackson@chiark.greenend.org.uk Subject: Re: [MSEC] Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard References: <42A0EF24.5040806@cisco.com> In-Reply-To: <42A0EF24.5040806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list 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 Ian, > >>> >1. It is unclear what is specified > >>> > > >>> >The whole point of the RSA-ESP/EH specification is to unambiguously > >>> >tie the concepts and protocol elements specified in RSA (RFC3447) > >>> >to those specified in ESP (currently envisaged by the RSA-ESP/EH > >>> >draft as draft-ietf-ipsec-esp-v3-09.txt). > > ... > > >> The above specification elements were indeed missing, > >> and have been added to Section 2.0. > > > The new language in section 2 is now just about adequate. A really > close reading by an honest reader leaves no other interpretation but > the one presumably intended. A careless or disingenuous reader (for > example, a busy implementor, and then later the same implementor > having implemented something different) might manage to come up with a > deviant reading. It's still very oblique. > > My experience with documents of this kind - which refer to parts of > other protocols which have different terminologies and backgrounds - > is that it is best to be explicit, and to explicitly and carefully use > the terminology from the two documents being joined. Thanks for pointing this out ... it's good advice. I have some suggested replacement text below to map the two terminologies. Comments on the replacement text are welcome. > Specifically, in this case, draft-05 s2.0 says `The authenticated > portion of the AH or ESP packet is given to the signature generation > function'. The term `signature generation function' is not defined by > PKCS#1; and `given to' is somewhat vague. The RSA-AH document should > explicitly state the name given to the corresponding value in PKCS#1, > ie `M'. It should say something like `the authenticated portion of > the AH or ESP packet ([AH] 3.3.3) is used as the message M and passed > to the signature generation operation ([RSA] 8.1.1, 8.2.1). > > draft-05 s2.0 doesn't explicitly say what's done with the signature; > it doesn't talk about the `ICV' (RFC2402 2.6) - preferring its own > term `authenticator value' - and it doesn't mention S (PKCS#1 8.1.1, > 8.2.1) let alone state that S and the ICV are identical. The following text addresses comments in the previous two paragraphs. "Digital signature generation is performed as described in [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1-v1_5). The authenticated portion of the AH or ESP packet ([AH, Section 3.3.3], [ESP, Section 3.3.2]) is used as the message M, which is passed to the signature generation function. The signer's RSA private key is passed as K. Summarizing, the signature generation process computes a SHA-1 hash of the authenticated packet bytes, signs the SHA-1 hash using the private key, and encodes the result with the specified RSA encoding type. This process results in a value S, which is known as the ICV in AH and ESP." > draft-05 s2.0 does say that the ICV (which it calls the `authenticator > value') `is equal to the size of the RSA modulus' which is at least > somewhat helpful but strictly speaking incorrect - it is in fact equal > _in size_ to the RSA modulus; the ICV value is not equal to the > modulus size. This is perhaps less explicit than RFC2402's > requirement that `The authentication algorithm specification MUST > specify the length of the ICV' since it's not clear whether it refers > to a bit length or byte length or should perhaps even be rounded up. This comment regarding 'bit length or byte length' caused me re-visit the topic of ESP and AH padding requirements. I believe the sentence in -05 stating "No ICV Padding bits are necessary" is incorrect. There's also an issue in that ESP does not state how to handle an ICV that is not a multiple of 8 bits, which can happen with an RSA modulus that is not a multiple of 8 bits, because ESP does not specify the use of explicit padding bits. I believe the following two paragraphs thoroughly define ESP and AH padding. "When specified for ESP, the ICV is equal in size to the RSA modulus, unless the RSA modulus is not a multiple of 8 bits. In this case, the ICV MUST be prepended with between 1 and 7 bits set to zero such that the ICV is a multiple of 8 bits. This specification matches the output S [RSA, Section 8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1-v1_5) when the RSA modulus is not a multiple of 8 bits. No implicit ESP ICV Padding bits are necessary. When specified for AH, the ICV is equal in size of the RSA modulus, unless the RSA modulus is not a multiple of 32 bits (IPv4) or 64 bits (IPv6) [AH, Section 2.6]. In this case, explicit ICV Padding bits are necessary to create a suitably sized ICV [AH, Section 3.3.3.2.1]." Note that there is no need to specify the format of the AH padding bits. The referenced section declares that "The content of the padding field is arbitrarily selected by the sender." > RFC2402 also says `The authentication algorithm specification MUST > specify [...] the comparison rules and processing steps for > validation' which draft-05 does not. The last paragraph of section 2.0 (appearing at the top of page 4 of -05) specifies comparison rules and validating steps. However, in the spirit of precision I believe the following replacement paragraph is better: "Digital signature verification is performed as described in [RSA, Section 8.1.2] (RSASSA-PSS) and [RSA, Section 8.2.2](RSASSA-PKCS1-v1_5). Upon receipt, the ICV is passed to the verification function as S. The authenticated portion of the AH or ESP packet is used as the message M, and the RSA public key is passed as (n, e). In summary, the verification function computes a SHA-1 hash of the authenticated packet bytes, decrypts the SHA-1 hash in the ICV, and validates that the appropriate encoding was applied and was correct. The two SHA-1 hashes are compared, and if they are identical the validation is successful." > >> Although PSS is acknowledged to be superior to PKCS#1.5, it has the > >> difficulties that 1) it is not as widely deployed as PKCS#1.5, and > >> 2) it has not been explicitly cleared for use by the IETF by the PSS > >> patent holder. Therefore, it is not reasonable to require the use > >> of PSS. PSS has been included in the draft as a choice, but not as a > >> MUST. > > > Lack of wide deployment is not a reason not to specify a superior > algorithm in a new standard. The PSS patent isn't really a problem, > is it ? The University of California have said they'll licence it > appropriately if it is made an IEEE standard - can't we get a similar > statement for the IETF ? They've been asked to do this, but to date have not submitted any statement. > Ian. Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jun 13 18:22:28 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13351 for ; Mon, 13 Jun 2005 18:22:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A03368C605; Mon, 13 Jun 2005 18:22: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 80A738C5F6 for ; Mon, 13 Jun 2005 18:22:28 -0400 (EDT) Received: (qmail 66398 invoked by uid 3269); 13 Jun 2005 22:22:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66395 invoked from network); 13 Jun 2005 22:22:28 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 13 Jun 2005 22:22:28 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2005 15:22:27 -0700 Received: from [128.107.163.236] (dhcp-128-107-163-236.cisco.com [128.107.163.236]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5DMMIlw014754; Mon, 13 Jun 2005 15:22:19 -0700 (PDT) Message-ID: <42AE071E.1040908@cisco.com> Date: Mon, 13 Jun 2005 15:22:22 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [MSEC] Consensus call on draft-ietf-msec-ipsec-signatures-05.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: George Gross , Ran Canetti , Russ Housley , 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 Sam, Sam Hartman wrote: > If you do talk about nesting ESP within ESP, make sure that your > description is 2401bis-centric not 2401-centric. IN particular, under > 2401bis you would need to send a packet across the protection barrier > twice (something not all implementations will support); you only get > one decapsulation/encapsulation for each transition. Thanks for the reminder. I believe that it is still possible within 2401bis to specify a pair of AH and ESP transforms as a single policy. E.g., (AH with an HMAC) and (ESP with RSA signatures). This would not cause the extra trip across the protection barrier. Do you agree? Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 14 09:32:09 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17737 for ; Tue, 14 Jun 2005 09:32:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 780A68C2A5; Tue, 14 Jun 2005 09:32: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 E69F18CC3D for ; Tue, 14 Jun 2005 09:32:06 -0400 (EDT) Received: (qmail 56586 invoked by uid 3269); 14 Jun 2005 13:32:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56581 invoked from network); 14 Jun 2005 13:32:06 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 14 Jun 2005 13:32:06 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id j5EDVsBD032449; Tue, 14 Jun 2005 08:31:54 -0500 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id j5EDVsq7010618; Tue, 14 Jun 2005 08:31:54 -0500 Received: from columbia.sparta.com ([192.168.1.47]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id j5EDVl6h007905; Tue, 14 Jun 2005 09:31:48 -0400 (EDT) Message-ID: <42AEDC3E.1080703@columbia.sparta.com> Date: Tue, 14 Jun 2005 09:31:42 -0400 From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] MSEC WG Last Call: draft-ietf-msec-policy-token-sec-02.txt (closing June 10, 2005) References: In-Reply-To: Cc: andrea Colegrove , hugh Harney , ran 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: , Content-Type: multipart/mixed; boundary="===============1937929700==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1937929700== Content-Type: multipart/alternative; boundary="------------090708000302000909030500" This is a multi-part message in MIME format. --------------090708000302000909030500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, A couple of comments on your email are included below: George Gross wrote: >Hi, > I have reviewed and compiled (using eSNACC v1.7) the core policy >token ASN.1 specified in this v02 draft's appendices. > > there were a few minor syntaxical corrections needed to get to a >clean compile, and I've worked off the list with Andrea wrt/ those. I'd >like to see these published in the next rev of the Internet Draft. > > Yes -- all minor changes are being incorporated. Thanks. > Overall, I support the advancement of this core PT draft to >Proposed Standard. The set of group security policies expressible by the >core PT is a reasonable starting point for growing application-specific >group security policy ASN.1 specs based on this spec. > > That said, there are several areas in the current draft that I >would like to hear the opinion of other MSEC members, especially those >with ASN.1 design experience in other IETF standards. since I am >relatively new to using ASN.1 as a designer, there is a certain amount of >wisdom through experience that would influence how one would encode group >policy for the following design problems: > >1) The merits/drawbacks of encoding the "SecuritySuite" as an OID versus >an INTEGER. > Object identifiers provide a nice way of extending our "CHOICES" without requiring us to open up the spec. By only importing modules that we wish to use, we limit wrt size and local policy. I am eating humble pie here as I too used to argue vigorously for explicit definitions within the specs, but have come to see the headaches associated with constantly updating a full spec in favor writing a companion spec that extends a protocol via the OID mechanism. > >2) The merits/drawbacks of introducing a GSAKMPIdType as an enumerated >list for the GSAKMPID object, with the enumeration's values matching those >declared the GSAKMP protocol spec Table 19. > Each time a new GSAKMPIdType were to be added to GSAKMP, the token spec would also need to be opened up to add it to that spec if we were to use enumerated values. I prefer that we do not change this as it would become a never-ending coupling in the IETF. > >3) Should the "KeyIdentifier" OID definition be imported from the >certificate extensions ASN spec rather than using the explicit definition >found in the draft's appendices? > KeyIdentifier is imported as follows: IMPORTS LifeDate FROM PolicyToken {TBD} KeyIdentifier FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }; If it is inadvertantly redefined elsewhere, I haven't caught that, please point out where. > >4) The registration, de-registration, and rekey protocols are all >currently defined as being of type "GroupMngmtProtocol", which turns to be >"protocolInfo OCTET STRING". In effect, this is a textual convention that >requires the implementor to validate the OCTET STRING rather than rely on >ASN syntax checking. IMHO, I would have thought it would a more extensible >syntax to have defined a CHOICE for each of these protocols with an ANY >type as one of the choices. This resembles the construct used for a >GeneralName within the SubjectAltNames of a certificate. For example, the >rekey protocol choice would be expressed as follows in this alternative >method: > >------------------------------------------------------------ > -- RekeyProtocol > >RekeyProtocol ::= CHOICE { > other-rekey [0] Other-Rekey, > none [1] NULL, > gsakmp-rekey-v01 [2] GSAKMPv1RekeyInfo >} > > >Other-Rekey ::= SEQUENCE { > rekey-proto-id OBJECT IDENTIFIER, > rekey-type ANY DEFINED BY rekey-proto-id >} > >what do people think of this alternative encoding using CHOICE in >combination with "ANY DEFINED BY"? > > For other than the options tagged [1] and [2], I do not see the benefit. The hybrid CHOICE/OID option doesn't seem very elegant. As far as trying to do most protocol options as CHOICEs, that is not very extensible as we have the spec "re-opening" problem as discussed above. I do believe that the spec should say that we need to limit (check receipt of) the OIDs processed to those acceptable to the implementation and that local policy should be able to configure these via "knobs". BTW, we have tried to follow the RFC 3852 convention for this. >EncapsulatedContentInfo ::= SEQUENCE { > eContentType ContentType, > eContent [0] EXPLICIT OCTET STRING OPTIONAL } > > ContentType ::= OBJECT IDENTIFIER > If I have missed a nuance of CMS then we should definitely make changes. I don't believe, however, that we should make changes that make the draft less extensible in favor of slightly easier implementation. Thanks for the comments and raising these discussion points. --- Andrea > > --------------090708000302000909030500 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
    A couple of comments on your email are included below:

George Gross wrote:
Hi,
	I have reviewed and compiled (using eSNACC v1.7) the core policy
token ASN.1 specified in this v02 draft's appendices.

	there were a few minor syntaxical corrections needed to get to a
clean compile, and I've worked off the list with Andrea wrt/ those. I'd
like to see these published in the next rev of the Internet Draft.
Yes -- all minor changes are being incorporated. Thanks.
	Overall, I support the advancement of this core PT draft to
Proposed Standard.  The set of group security policies expressible by the
core PT is a reasonable starting point for growing application-specific
group security policy ASN.1 specs based on this spec.

	That said, there are several areas in the current draft that I
would like to hear the opinion of other MSEC members, especially those
with ASN.1 design experience in other IETF standards. since I am
relatively new to using ASN.1 as a designer, there is a certain amount of
wisdom through experience that would influence how one would encode group
policy for the following design problems:

1) The merits/drawbacks of encoding the "SecuritySuite" as an OID versus
an INTEGER.
Object identifiers provide a nice way of extending our "CHOICES" without requiring us to open up the spec.  By only importing modules that we wish to use, we limit wrt size and local policy.  I am eating humble pie here as I too used to argue vigorously for explicit definitions within the specs, but have come to see the headaches associated with constantly updating a full spec in favor writing a companion spec that extends a protocol via the OID mechanism.

2) The merits/drawbacks of introducing a GSAKMPIdType as an enumerated
list for the GSAKMPID object, with the enumeration's values matching those
declared the GSAKMP protocol spec Table 19.
Each time a new GSAKMPIdType were to be added to GSAKMP, the token spec would also need to be opened up to add it to that spec if we were to use enumerated values.  I prefer that we do not change this as it would become a never-ending coupling in the IETF.

3) Should the "KeyIdentifier" OID definition be imported from the
certificate extensions ASN spec rather than using the explicit definition
found in the draft's appendices?
KeyIdentifier is imported as follows:

IMPORTS
        LifeDate
            FROM PolicyToken {TBD}

        KeyIdentifier
            FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) };

If it is inadvertantly redefined elsewhere, I haven't caught that, please point out where.

4) The registration, de-registration, and rekey protocols are all
currently defined as being of type "GroupMngmtProtocol", which turns to be
"protocolInfo OCTET STRING". In effect, this is a textual convention that
requires the implementor to validate the OCTET STRING rather than rely on
ASN syntax checking. IMHO, I would have thought it would a more extensible
syntax to have defined a CHOICE for each of these protocols with an ANY
type as one of the choices. This resembles the construct used for a
GeneralName within the SubjectAltNames of a certificate.  For example, the
rekey protocol choice would be expressed as follows in this alternative
method:

------------------------------------------------------------
    -- RekeyProtocol

RekeyProtocol ::= CHOICE {
  other-rekey      [0] Other-Rekey,
  none             [1] NULL,
  gsakmp-rekey-v01 [2] GSAKMPv1RekeyInfo
}


Other-Rekey ::= SEQUENCE {
     rekey-proto-id   OBJECT IDENTIFIER,
     rekey-type       ANY DEFINED BY rekey-proto-id
}

what do people think of this alternative encoding using CHOICE in
combination with "ANY DEFINED BY"?
For other than the options tagged [1] and [2], I do not see the benefit.  The hybrid CHOICE/OID option doesn't seem very elegant.

As far as trying to do most protocol options as CHOICEs, that is not very extensible as we have the spec "re-opening" problem as discussed above.

I do believe that the spec should say that we need to limit (check receipt of) the OIDs processed to those acceptable to the implementation and that local policy should be able to configure these via "knobs".

BTW, we have tried to follow the RFC 3852 convention for this.
EncapsulatedContentInfo ::= SEQUENCE {
        eContentType ContentType,
        eContent [0] EXPLICIT OCTET STRING OPTIONAL }

      ContentType ::= OBJECT IDENTIFIER
If I have missed a nuance of CMS then we should definitely make changes.  I don't believe, however, that we should make changes that make the draft less extensible in favor of slightly easier implementation.

Thanks for the comments and raising these discussion points.

--- Andrea
--------------090708000302000909030500-- --===============1937929700== 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 --===============1937929700==-- From msec-bounces@securemulticast.org Tue Jun 14 14:31:39 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16008 for ; Tue, 14 Jun 2005 14:31:39 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6B9538C6BD; Tue, 14 Jun 2005 14:31: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 0EEB58C69D for ; Tue, 14 Jun 2005 14:31:38 -0400 (EDT) Received: (qmail 15801 invoked by uid 3269); 14 Jun 2005 18:31:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15791 invoked from network); 14 Jun 2005 18:31:35 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 14 Jun 2005 18:31:35 -0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5EIVUdv007604 for ; Tue, 14 Jun 2005 11:31:30 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5EIVQ5O001056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Jun 2005 11:31:27 -0700 (PDT) Message-ID: <42AF2270.30007@qualcomm.com> Date: Tue, 14 Jun 2005 14:31:12 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] MSEC WG Last Call: draft-ietf-msec-policy-token-sec-02.txt (closing June 10, 2005) References: <428CD7F0.7010909@qualcomm.com> In-Reply-To: <428CD7F0.7010909@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com, ran canetti , andrea Colegrove , hugh Harney , msec@securemulticast.org 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 folks, This last call closed on Friday. However, there is an ongoing discussion between George Gross and the authors. Ran and I invite you to chime in, so we can achieve consensus one way or another. thanks and regards, Lakshminath Lakshminath Dondeti wrote: > Hi all, > > This is an MSEC WG last call for comments on > http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-02.txt > closing on > June 10, 2005 AOE. > Track: Standards Track, Proposed Standard > > If you have questions or if you think the draft is not ready to move > forward, please send your comments to the list. If you think that it > looks ready to be forwarded to the IESG, we want to hear from you > also. If you don't care, we want to know that as well :-). > > Note that the Policy Token is generic and can be used with GDOI as > well as other key management protocols in addition to GSAKMP. So, > please take some time to review this. > > We would also like to hear about any implementations of the policy > token spec (Andrea, do you know of any implementations?). > > regards, > Lakshminath > > Draft details: > Title: Group Policy Token V1 with Application to GSAKMP > Authors: A. Colegrove and H. Harney > > Abstract: > The Policy Token is a structure used to specify the security > policy and configurable parameters for a cryptographic group, such > as a secure multicast group. This document specifies the structure > of such a token in order to securely bind system-level security to > protocols supporting the management of cryptographic groups. > > _______________________________________________ > 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 Jun 14 14:50:10 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18179 for ; Tue, 14 Jun 2005 14:50:10 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EE8A08C022; Tue, 14 Jun 2005 14:49:44 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 990118CB1F for ; Tue, 14 Jun 2005 14:49:43 -0400 (EDT) Received: (qmail 19289 invoked by uid 3269); 14 Jun 2005 18:49:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19286 invoked from network); 14 Jun 2005 18:49:43 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 14 Jun 2005 18:49:43 -0000 Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j5EIp43O027046 for ; Tue, 14 Jun 2005 14:51:04 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j5EIngp545364 for ; Tue, 14 Jun 2005 14:49:42 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j5EInf3545362 for ; Tue, 14 Jun 2005 14:49:41 -0400 Received: from prf.watson.ibm.com ([9.2.16.112]) by mgsmtp00.watson.ibm.com (IMF.2005.06.13.1011.haw) with SMTP ID IMFd1118774850.32131; Tue, 14 Jun 2005 14:47:30 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j5EInf932418 for ; Tue, 14 Jun 2005 14:49:41 -0400 Date: Tue, 14 Jun 2005 14:49:40 -0400 (EDT) From: canetti To: msec@securemulticast.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Re: New work item? X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, Several people have expressed interest in advancing this draft. It thus seems appropriate to accept it as an MSEC work item. Best, Ran On Mon, 25 Apr 2005, canetti wrote: > > > Folks, > > The following private I-D: > > http://www.ietf.org/internet-drafts/draft-ignjatic-msec-mikey-rsa-r-00.txt > > was presented and well received at the IETF meeting in Minneapolis. > > Essentially, it proposes a new MIKEY mode that works in one round-trip, > and is aimed at situations where the initiator does not know in advance > the public key/certificate of the responder. > > I'd like to get a sense if there is interest in making this into an MSEC > work item. > > Thanks, > > Ran > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 14 17:24:40 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07367 for ; Tue, 14 Jun 2005 17:24:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3C98B8C722; Tue, 14 Jun 2005 17:24:34 -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 819218C702 for ; Tue, 14 Jun 2005 17:24:32 -0400 (EDT) Received: (qmail 51253 invoked by uid 3269); 14 Jun 2005 21:24:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51250 invoked from network); 14 Jun 2005 21:24:32 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 14 Jun 2005 21:24:32 -0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ELOLdv025881; Tue, 14 Jun 2005 14:24:22 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ELOGt1006323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2005 14:24:18 -0700 (PDT) Message-ID: <42AF4B02.9070801@qualcomm.com> Date: Tue, 14 Jun 2005 17:24:18 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] [Fwd: MSEC review of 802.16e MBS security] References: <429F4B01.4070108@qualcomm.com> In-Reply-To: <429F4B01.4070108@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jmandin@streetwaves-networks.com, Ran Canetti , Russ Housley , aboba@internaut.com X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi folks, I have heard back from one person about this, but no one has signed up for this work yet. So, here is my pitch again, especially to grad students on the list. As you might recall/know, an analysis on the 802.11i 4-way exchange was accepted for publication/presentation at this year's (or last year's) NDSS conference. This may be your chance to read the 802.16e specification (the draft specification is not publicly available), analyze it so the 16e group can improve it and so forth, and for you to perhaps get a publication out of it. You might also get to know other MSEC contributors along the way so you can network etc. **So, please sign up!!** Thanks in advance. best regards, Lakshminath Lakshminath Dondeti wrote: > Hi all, > > This is in response to a formal request for review from the 802.16 > group. I am cc'ing the IETF liaison (Bernard Aboba) and the AD so > they are aware of our efforts. Jeff Mandin is the 802.16 liaison to > the IETF. The liaison letters are available from below: > > http://ieee802.org/16/liaison/docs/L80216-05_025.pdf > http://ieee802.org/16/liaison/docs/L80216-05_039.pdf > > We need a few volunteers to review a few sections (related to > multicast and broadcast security) in the 802.16e specification, and > prepare what amounts to a security considerations (identify any > vulnerabilities in the 16e specification and suggest mitigation > techniques or strategies) document. > > I know a bit about the 802.16 specification, and speaking from > experience, it should not take more than a few hours of your time > given this group's knowledge in multicast and group security protocols. > > Please volunteer and read Jeff's proposed outline below. If you are > interested, please send Ran and I an email. Thanks in advance. > > best regards, > Lakshminath > > -------- Original Message -------- > Subject: MSEC review of 802.16e MBS security > Date: Wed, 1 Jun 2005 12:38:59 +0200 > From: Jeff Mandin > Reply-To: jmandin@streetwaves-networks.com > To: ldondeti@qualcomm.com > > > > Lakshminath hi, > > Hope things are going well at Qualcomm. Now that the EAP WG's review > is in full swing, I'd like to move ahead with the MSEC review > discussed before. > > The material to be reviewed would be section 7.8.3 of 802.16e draft > D8, and any additional sections that are perceived by the reviewers as > relevant (ie. 7.8.4.1 AES-CTR and 7.2.2.2 key derivation). The > purpose of the review would of course be to note any security issues > and assist 16e in resolving them. > > The EAP review is probably a good model for how this can work: > > - 2-3 people from MSEC would be the formal reviewers > > - a mailing list would be set up and include the reviewers, 1-3 > people from 802.16 (probably me and 1-2 of the people behind MBS), and > perhaps other specific people from MSEC if there is interest. Initial > reflector discussions (and hopefully telecons) would focus on > understanding what's actually in the 802.16 spec. > > - MSEC would then prepare an initial review document outlining any > issues and make it available to a broader group of .16 members for > response and discussion of solutions. > > - .16e would then propose changes at the next recirc, and MSEC would > send a formal liaison letter to 802.16 in advance of the 7/17 San > Francisco 802 meeting. > > How does this sound? If it's feasible, then we can put together a > specific timeline for the next 6 weeks. > > BRs, > > - Jeff > > > _______________________________________________ > 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 Jun 15 10:16:46 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19661 for ; Wed, 15 Jun 2005 10:16:45 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9772B8C064; Wed, 15 Jun 2005 10:16:44 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 92A068BF97 for ; Wed, 15 Jun 2005 10:16:43 -0400 (EDT) Received: (qmail 71460 invoked by uid 3269); 15 Jun 2005 14:16:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71457 invoked from network); 15 Jun 2005 14:16:43 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 15 Jun 2005 14:16:43 -0000 Received: (qmail 78400 invoked from network); 15 Jun 2005 14:16:40 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 15 Jun 2005 14:16:40 -0000 Received: (qmail 76787 invoked from network); 15 Jun 2005 10:16:40 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.78) by mail1.oct.nac.net with SMTP; 15 Jun 2005 10:16:40 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j5FB4Vk13710; Wed, 15 Jun 2005 07:04:31 -0400 Date: Wed, 15 Jun 2005 07:04:31 -0400 (EDT) From: George Gross To: Andrea Colegrove Subject: Re: [MSEC] MSEC WG Last Call: draft-ietf-msec-policy-token-sec-02.txt (closing June 10, 2005) In-Reply-To: <42AEDC3E.1080703@columbia.sparta.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 Andrea, we have different perceptions of the rate of change for the core PT branchs. this leads to different conclusions about how to engineer the ASN.1 extension mechanism/syntax. In general, I observe that the rate of change for several of these core PT objects that we're discussing is on the timescale of IETF standards action. OTOH, I suspect the SecuritySuite would change more frequently than that. In other words, the core PT spec will have infrequent change, with years of the usual standards review lifecycle between RFC revisions ;o) more inline below... On Tue, 14 Jun 2005, Andrea Colegrove wrote: > Hi, > A couple of comments on your email are included below: > > George Gross wrote: > > > > > That said, there are several areas in the current draft that I > >would like to hear the opinion of other MSEC members, especially those > >with ASN.1 design experience in other IETF standards. since I am > >relatively new to using ASN.1 as a designer, there is a certain amount of > >wisdom through experience that would influence how one would encode group > >policy for the following design problems: > > > >1) The merits/drawbacks of encoding the "SecuritySuite" as an OID versus > >an INTEGER. > > > Object identifiers provide a nice way of extending our "CHOICES" without > requiring us to open up the spec. By only importing modules that we wish > to use, we limit wrt size and local policy. I am eating humble pie here > as I too used to argue vigorously for explicit definitions within the > specs, but have come to see the headaches associated with constantly > updating a full spec in favor writing a companion spec that extends a > protocol via the OID mechanism. For the "SecuritySuite" OID, my point of view is that its rate of change is faster than IETF standards action due to two factors: 1) flux in cryptographic algorithm status (i.e. the demise of MD5 and the cloud over SHA-1) 2) diversity in the multicast application-specific security policies, which will ammend or replace the default GSAKMP SecuritySuite 1. so help me understand, do you register a new security suite OID every time you change one of the parameters with the security suite's profile? in your view, when does one define a new SecuritySuite OID? what is the process through which one acquires that OID, is it an IANA allocation everytime? Said another way, if SecuritySuite is meant to enumerate choices available within a local registry of group crypto-suites implemented by an Enterprise's multicast applications, then does it make sense to use OID or INTEGER? > > > > >2) The merits/drawbacks of introducing a GSAKMPIdType as an enumerated > >list for the GSAKMPID object, with the enumeration's values matching those > >declared the GSAKMP protocol spec Table 19. > > > Each time a new GSAKMPIdType were to be added to GSAKMP, the token spec > would also need to be opened up to add it to that spec if we were to use > enumerated values. I prefer that we do not change this as it would > become a never-ending coupling in the IETF. The set of GSAKMPIdType that have been defined in Table 19 are one for one matched to those in widespread use by the rest of the Internet security community (i.e. PKIX,IKE). So adding a new GSAKMPIdType is not very probable from what I can see, and would add new types at a slow rate governed by standards action. Please explain why you see lots of new GSAKMPIdType identifiers on the future horizon (and private use does not require IETF standards action). > > > > >3) Should the "KeyIdentifier" OID definition be imported from the > >certificate extensions ASN spec rather than using the explicit definition > >found in the draft's appendices? > > > KeyIdentifier is imported as follows: > > IMPORTS > LifeDate > FROM PolicyToken {TBD} > > KeyIdentifier > FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }; > > If it is inadvertantly redefined elsewhere, I haven't caught that, > please point out where. Okay, I do not have a ASN.1 module named "PKIX1Implicit88" in my SNACC compiler's distribution. So I can only infer that the module I imported is equivalent to the "PKIXImplicit88" module, but has a different name. > > > > >4) The registration, de-registration, and rekey protocols are all > >currently defined as being of type "GroupMngmtProtocol", which turns to be > >"protocolInfo OCTET STRING". In effect, this is a textual convention that > >requires the implementor to validate the OCTET STRING rather than rely on > >ASN syntax checking. IMHO, I would have thought it would a more extensible > >syntax to have defined a CHOICE for each of these protocols with an ANY > >type as one of the choices. This resembles the construct used for a > >GeneralName within the SubjectAltNames of a certificate. For example, the > >rekey protocol choice would be expressed as follows in this alternative > >method: > > > >------------------------------------------------------------ > > -- RekeyProtocol > > > >RekeyProtocol ::= CHOICE { > > other-rekey [0] Other-Rekey, > > none [1] NULL, > > gsakmp-rekey-v01 [2] GSAKMPv1RekeyInfo > >} > > > > > >Other-Rekey ::= SEQUENCE { > > rekey-proto-id OBJECT IDENTIFIER, > > rekey-type ANY DEFINED BY rekey-proto-id > >} > > > >what do people think of this alternative encoding using CHOICE in > >combination with "ANY DEFINED BY"? > > > > > For other than the options tagged [1] and [2], I do not see the benefit. > The hybrid CHOICE/OID option doesn't seem very elegant. > > As far as trying to do most protocol options as CHOICEs, that is not > very extensible as we have the spec "re-opening" problem as discussed above. > > I do believe that the spec should say that we need to limit (check > receipt of) the OIDs processed to those acceptable to the implementation > and that local policy should be able to configure these via "knobs". > > BTW, we have tried to follow the RFC 3852 convention for this. > > >EncapsulatedContentInfo ::= SEQUENCE { > > eContentType ContentType, > > eContent [0] EXPLICIT OCTET STRING OPTIONAL } > > > > ContentType ::= OBJECT IDENTIFIER > > > If I have missed a nuance of CMS then we should definitely make changes. > I don't believe, however, that we should make changes that make the > draft less extensible in favor of slightly easier implementation. > > Thanks for the comments and raising these discussion points. hmmm... when I read your criteria stated wrt/ SecuritySuite, we should be using CHOICES and object identifiers for the registration protocol, rekey protocol, and de-registration protocol. We are not often adding changes here, e.g. when in our lifetime do you expect to publish GSAKMP v2 registration protocol in the IETF? even the foreseeable future universe of IETF standardized rekey protocols does not present a large number of CHOICES. As I expressed above, I do not foresee a high rate of expansion in the set of group key management protocols defined by the IETF. Most of the forseeable change is due to defining new GSAKMP versions on a timescale of years. so the extensibility overhead of "open'ing the spec" is not onerous. Of course, OCTET STRING syntax can be made to work. My main problem with using OCTET STRING in this context is that historically OCTET STRING with textual conventions have been where vendor-specific undocumented data structures can creep in (or bugs in a vendor's encoding of the standard). So the core PT spec must state a procedure saying how one error checks each octet in the OCTET STRING for standards compliance, and how to gracefully skip things you don't understand. if this procedure is underspecified then we could stumble into inter-op problems. br, George > > --- Andrea > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Jun 15 11:16:13 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25653 for ; Wed, 15 Jun 2005 11:16:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1CB148C24D; Wed, 15 Jun 2005 11:16: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 A27048C181 for ; Wed, 15 Jun 2005 11:16:13 -0400 (EDT) Received: (qmail 82558 invoked by uid 3269); 15 Jun 2005 15:16:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82555 invoked from network); 15 Jun 2005 15:16:13 -0000 Received: from ithilien.qualcomm.com (129.46.51.59) by klesh.pair.com with SMTP; 15 Jun 2005 15:16:13 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5FFGAdv008405; Wed, 15 Jun 2005 08:16:10 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5FFG6uo006556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Jun 2005 08:16:07 -0700 (PDT) Message-ID: <42B0463A.6070306@qualcomm.com> Date: Wed, 15 Jun 2005 11:16:10 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "can >> Ran Canetti" Subject: [MSEC] Tools that make all our lives easier X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit All, You may find the following IETF web sites very informative and useful: http://tools.ietf.org/wg/msec/ http://ietf.levkowetz.com/tools/rfcdiff/rfcdiff.pyht http://ietf.levkowetz.com/tools/idnits/idnits.pyht Document editors may find these pages and tools beneficial in many ways, including avoiding having your submission bounce from IETF I-D admin. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 16 02:42:55 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19166 for ; Thu, 16 Jun 2005 02:42:52 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7CF398C81F; Thu, 16 Jun 2005 02:42: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 A96488C80F for ; Thu, 16 Jun 2005 02:42:55 -0400 (EDT) Received: (qmail 80089 invoked by uid 3269); 16 Jun 2005 06:42:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80086 invoked from network); 16 Jun 2005 06:42:55 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 16 Jun 2005 06:42:55 -0000 Received: (qmail 34284 invoked from network); 16 Jun 2005 06:42:54 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 16 Jun 2005 06:42:54 -0000 Received: (qmail 51607 invoked from network); 16 Jun 2005 02:42:54 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.78) by mail1.oct.nac.net with SMTP; 16 Jun 2005 02:42:54 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j5G3Udf15034; Wed, 15 Jun 2005 23:30:39 -0400 Date: Wed, 15 Jun 2005 23:30:39 -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] registration protocol PT omissions? 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 Andrea, Perhaps this was overlooked because they are optional, but should not the ASN.1 GSAKMPv1RegistrationSA definition have a BOOLEAN flag to indicate whether cookies are required by the GO policy in the registration exchange? also, whether the GO requires that the registration exchange will occur in terse/verbose mode? a similar mode flag also would be required in the definition of GSAKMPv1DeRegistrationSA. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jun 16 11:02:28 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29217 for ; Thu, 16 Jun 2005 11:02:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C93898C045; Thu, 16 Jun 2005 11:02:32 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DAEEF8BFBC for ; Thu, 16 Jun 2005 11:02:31 -0400 (EDT) Received: (qmail 76409 invoked by uid 3269); 16 Jun 2005 15:02:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76406 invoked from network); 16 Jun 2005 15:02:31 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 16 Jun 2005 15:02:31 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id j5GF2Rfn021462; Thu, 16 Jun 2005 10:02:27 -0500 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id j5GF2Qrf029110; Thu, 16 Jun 2005 10:02:27 -0500 Received: from columbia.sparta.com ([10.207.1.120]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id j5GF2H6h009422; Thu, 16 Jun 2005 11:02:23 -0400 (EDT) Message-ID: <42B19471.1000307@columbia.sparta.com> Date: Thu, 16 Jun 2005 11:02:09 -0400 From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] registration protocol PT omissions? 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 George, The ability to turn cookies on/off is a dynamic local capability of the (S/)GCKSs, which is signalled inband based upon network conditions -- so this should not be set in the PT. Terse/verbose is indicated in the OpInfo structure. Thanks, Andrea George Gross wrote: >Hi Andrea, > > Perhaps this was overlooked because they are optional, but should >not the ASN.1 GSAKMPv1RegistrationSA definition have a BOOLEAN flag to >indicate whether cookies are required by the GO policy in the registration >exchange? also, whether the GO requires that the registration exchange >will occur in terse/verbose mode? a similar mode flag also would be >required in the definition of GSAKMPv1DeRegistrationSA. > >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 Thu Jun 16 11:23:50 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01212 for ; Thu, 16 Jun 2005 11:23:49 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 00BCD8C7DF; Thu, 16 Jun 2005 11:23: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 A4CA68C776 for ; Thu, 16 Jun 2005 11:23:51 -0400 (EDT) Received: (qmail 80868 invoked by uid 3269); 16 Jun 2005 15:23:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80864 invoked from network); 16 Jun 2005 15:23:51 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 16 Jun 2005 15:23:51 -0000 Received: (qmail 18914 invoked from network); 16 Jun 2005 15:23:48 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 16 Jun 2005 15:23:48 -0000 Received: (qmail 57922 invoked from network); 16 Jun 2005 11:23:48 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.78) by mail1.oct.nac.net with SMTP; 16 Jun 2005 11:23:48 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j5GCBT615500; Thu, 16 Jun 2005 08:11:29 -0400 Date: Thu, 16 Jun 2005 08:11:29 -0400 (EDT) From: George Gross To: Andrea Colegrove Subject: Re: [MSEC] registration protocol PT omissions? In-Reply-To: <42B19471.1000307@columbia.sparta.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 Andrea, On Thu, 16 Jun 2005, Andrea Colegrove wrote: > George, > The ability to turn cookies on/off is a dynamic local capability of > the (S/)GCKSs, which is signalled inband based upon network conditions > -- so this should not be set in the PT. But we've made cookies support optional in GSAKMP section 5.2.2. So how does a GC/KS know whether a candidate group member even supports the cookies exchange? It would be reasonable policy for the GO to specify that cookies are *not* to be used, because the GO knows that some subset of the legitimate group member endpoints do not support cookies. Conversely, the GO may require that all candidate GM support cookies as a matter of policy. > > Terse/verbose is indicated in the OpInfo structure. Apparently a minor typo got into the spec's OpInfo declaration on page 21, which is mis-declared as follows: OpInfo ::= SEQUENCE { timeOut LifeDate } whereas the descriptive text on page 17 has it correctly stated (and which I missed because I was only looking at my compiled ASN.1 source). hth, George > > Thanks, > > Andrea > > George Gross wrote: > > >Hi Andrea, > > > > Perhaps this was overlooked because they are optional, but should > >not the ASN.1 GSAKMPv1RegistrationSA definition have a BOOLEAN flag to > >indicate whether cookies are required by the GO policy in the registration > >exchange? also, whether the GO requires that the registration exchange > >will occur in terse/verbose mode? a similar mode flag also would be > >required in the definition of GSAKMPv1DeRegistrationSA. > > > >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 Thu Jun 16 14:01:40 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20527 for ; Thu, 16 Jun 2005 14:01:39 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 32B958C4D3; Thu, 16 Jun 2005 14:01: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 920E28C301 for ; Thu, 16 Jun 2005 14:01:40 -0400 (EDT) Received: (qmail 11115 invoked by uid 3269); 16 Jun 2005 18:01:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11112 invoked from network); 16 Jun 2005 18:01:39 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 16 Jun 2005 18:01:39 -0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id j5GI1b5r031840; Thu, 16 Jun 2005 13:01:37 -0500 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id j5GI1Zav004275; Thu, 16 Jun 2005 13:01:36 -0500 Received: from columbia.sparta.com ([10.207.1.120]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id j5GI1U6h012555; Thu, 16 Jun 2005 14:01:35 -0400 (EDT) Message-ID: <42B1BE75.9010604@columbia.sparta.com> Date: Thu, 16 Jun 2005 14:01:25 -0400 From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] registration protocol PT omissions? References: In-Reply-To: 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: , Content-Type: multipart/mixed; boundary="===============1642592951==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1642592951== Content-Type: multipart/alternative; boundary="------------040408000607070600060801" This is a multi-part message in MIME format. --------------040408000607070600060801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi George, >George, > The ability to turn cookies on/off is a dynamic local capability of >the (S/)GCKSs, which is signalled inband based upon network conditions >-- so this should not be set in the PT. > > > >But we've made cookies support optional in GSAKMP section 5.2.2. So how >does a GC/KS know whether a candidate group member even supports the >cookies exchange? It would be reasonable policy for the GO to specify that >cookies are *not* to be used, because the GO knows that some subset of the >legitimate group member endpoints do not support cookies. Conversely, the >GO may require that all candidate GM support cookies as a matter of >policy. > > I do understand your concern, but DoS protections are for the benefit of the servers not the clients. To tell a server that they cannot use cookies would impose policy on them from the GO. A GCKS should only accept a policy if it doesn't violate local policy. Furthermore, keep in mind that clients "MUST" respond with a cookie -- the cookie state is really optional for servers. > > >> Terse/verbose is indicated in the OpInfo structure. >> >> > >Apparently a minor typo got into the spec's OpInfo declaration on page 21, >which is mis-declared as follows: > >OpInfo ::= SEQUENCE { > timeOut LifeDate >} > >whereas the descriptive text on page 17 has it correctly stated (and which >I missed because I was only looking at my compiled ASN.1 source). > My error. I will add this to the typo fixes. Thanks for catching it. --- Andrea > >hth, > George > > > >>Thanks, >> >>Andrea >> >>George Gross wrote: >> >> >> >>>Hi Andrea, >>> >>> Perhaps this was overlooked because they are optional, but should >>>not the ASN.1 GSAKMPv1RegistrationSA definition have a BOOLEAN flag to >>>indicate whether cookies are required by the GO policy in the registration >>>exchange? also, whether the GO requires that the registration exchange >>>will occur in terse/verbose mode? a similar mode flag also would be >>>required in the definition of GSAKMPv1DeRegistrationSA. >>> >>>br, >>> George >>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://six.pairlist.net/mailman/listinfo/msec >>> >>> >>> >>> >>> >>> > > > > > --------------040408000607070600060801 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi George,

George,
    The ability to turn cookies on/off is a dynamic local capability of
the (S/)GCKSs, which is signalled inband based upon network conditions
-- so this should not be set in the PT.
  

But we've made cookies support optional in GSAKMP section 5.2.2. So how
does a GC/KS know whether a candidate group member even supports the
cookies exchange? It would be reasonable policy for the GO to specify that
cookies are *not* to be used, because the GO knows that some subset of the
legitimate group member endpoints do not support cookies. Conversely, the
GO may require that all candidate GM support cookies as a matter of
policy.
I do understand your concern, but DoS protections are for the benefit of the servers not the clients.  To tell a server that they cannot use cookies would impose policy on them from the GO.  A GCKS should only accept a policy if it doesn't violate local policy.  Furthermore, keep in mind that clients "MUST" respond with a cookie -- the cookie state is really optional for servers.

  
    Terse/verbose is indicated in the OpInfo structure.
    

Apparently a minor typo got into the spec's OpInfo declaration on page 21,
which is mis-declared as follows:

OpInfo ::= SEQUENCE {
  timeOut LifeDate
}

whereas the descriptive text on page 17 has it correctly stated (and which
I missed because I was only looking at my compiled ASN.1 source).
My error.  I will add this to the typo fixes.  Thanks for catching it.

--- Andrea 

hth,
	George

  
Thanks,

Andrea

George Gross wrote:

    
Hi Andrea,

	Perhaps this was overlooked because they are optional, but should
not the ASN.1 GSAKMPv1RegistrationSA definition have a BOOLEAN flag to
indicate whether cookies are required by the GO policy in the registration
exchange? also, whether the GO requires that the registration exchange
will occur in terse/verbose mode? a similar mode flag also would be
required in the definition of GSAKMPv1DeRegistrationSA.

br,
	George

_______________________________________________
msec mailing list
msec@securemulticast.org
http://six.pairlist.net/mailman/listinfo/msec
--------------040408000607070600060801-- --===============1642592951== 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 --===============1642592951==-- From msec-bounces@securemulticast.org Tue Jun 21 17:14:24 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15090 for ; Tue, 21 Jun 2005 17:14:24 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 579048C782; Tue, 21 Jun 2005 17:14:23 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 71EDF8C208 for ; Tue, 21 Jun 2005 17:14:21 -0400 (EDT) Received: (qmail 20009 invoked by uid 3269); 21 Jun 2005 21:14:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20006 invoked from network); 21 Jun 2005 21:14:21 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 21 Jun 2005 21:14:21 -0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5LLEHgj004967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2005 14:14:17 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5LLEDWb017512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2005 14:14:14 -0700 (PDT) Message-ID: <42B88328.1050409@qualcomm.com> Date: Tue, 21 Jun 2005 17:14:16 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti Subject: [MSEC] Deadline for WG-00 approvals is on July 5th X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi all, I will be sending the following WG-00- approvals to the I-D admin on Thursday. Please send your comments to the list (or contact Ran and me if you prefer :-)), if you have suggestions or thoughts . * draft-ietf-msec-mikey-ecc (this was approved by Thomas before the MSP meeting, but I did not see a -00- posted on the I-D repository). * draft-ietf-msec-ipsec-extensions (this was the work requested by Russ H., at the MSP meeting that Brian, George and Dragan are working on. I am officially on the hook for approving this) * draft-ietf-msec-mikey-rsa-r (this was work approved by Ran -- I can't do it as I am a co-author -- and posted to the list recently) thanks and regards, Lakshminath PS: I now have the timelines for all the pending work, so will have the secretary update the charter on the MSEC page this week. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Jun 24 12:10:46 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20810 for ; Fri, 24 Jun 2005 12:10:46 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A339D8C4A2; Fri, 24 Jun 2005 12:10: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 DC80C8C12D for ; Fri, 24 Jun 2005 12:10:44 -0400 (EDT) Received: (qmail 88423 invoked by uid 3269); 24 Jun 2005 16:10:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88420 invoked from network); 24 Jun 2005 16:10:44 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 24 Jun 2005 16:10:44 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Jun 2005 09:10:28 -0700 X-IronPort-AV: i="3.93,227,1115017200"; d="scan'208"; a="194035319:sNHT27626126" Received: from [10.32.244.213] (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id j5OGAQ6p024222 for ; Fri, 24 Jun 2005 09:10:26 -0700 (PDT) Message-ID: <42BC3073.8090000@cisco.com> Date: Fri, 24 Jun 2005 09:10:27 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] New IPsec signatures 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 Content-Transfer-Encoding: 7bit Draft 06 of the IPsec signatures draft is available: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-06.txt There are two substantive changes since draft 05: 1. Added language clarifying IPsec and PKCS#1 terms, which addressed Ian Jackson's comments. These proposed changes were posted to the list, and no dissent was registered. 2. Removed a claim that PSS "does not offer extra protection", which was based on unpublished research which can't yet be referenced. If there are no further comments, I will ask the Security ADs to take this draft under consideration. Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Jun 24 12:36:45 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22999 for ; Fri, 24 Jun 2005 12:36:45 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8392E8C140; Fri, 24 Jun 2005 12:36: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 7BF4B8C13A for ; Fri, 24 Jun 2005 12:36:40 -0400 (EDT) Received: (qmail 94583 invoked by uid 3269); 24 Jun 2005 16:36:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94567 invoked from network); 24 Jun 2005 16:36:26 -0000 Received: from numenor.qualcomm.com (129.46.51.58) by klesh.pair.com with SMTP; 24 Jun 2005 16:36:26 -0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OGXEgj015602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Jun 2005 09:33:15 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OGXAHV027425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jun 2005 09:33:11 -0700 (PDT) Message-ID: <42BC35C2.6060605@qualcomm.com> Date: Fri, 24 Jun 2005 12:33:06 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] New IPsec signatures draft References: <42BC3073.8090000@cisco.com> In-Reply-To: <42BC3073.8090000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brian Weis X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Thanks Brian. We will wait until Monday 5:00 PM AOE for anyone to take the time to review the diffs and comment on. The ADs asked for WG consensus since the changes (in 05 and now in 06) are substantial from the -04- version. thanks and regards, Lakshminath Brian Weis wrote: > Draft 06 of the IPsec signatures draft is available: > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-06.txt > > > There are two substantive changes since draft 05: > > 1. Added language clarifying IPsec and PKCS#1 terms, which addressed > Ian Jackson's comments. These proposed changes were posted to the > list, and no dissent was registered. > > 2. Removed a claim that PSS "does not offer extra protection", which > was based on unpublished research which can't yet be referenced. > > If there are no further comments, I will ask the Security ADs to take > this draft under consideration. > > Thanks, > Brian > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jun 28 10:05:16 2005 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10844 for ; Tue, 28 Jun 2005 10:05:13 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 026BE8C662; Tue, 28 Jun 2005 10:05: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 D14EE8C658 for ; Tue, 28 Jun 2005 10:05:09 -0400 (EDT) Received: (qmail 55813 invoked by uid 3269); 28 Jun 2005 14:05:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55804 invoked from network); 28 Jun 2005 14:05:08 -0000 Received: from bj45-160.i.netease.com (HELO 126.com) (202.108.45.160) by klesh.pair.com with SMTP; 28 Jun 2005 14:05:08 -0000 Received: from thinker (unknown [202.115.28.189]) by smtp3 (Coremail) with SMTP id Q8I7gw1ZwUIfMVUv.1 for ; Tue, 28 Jun 2005 22:05:02 +0800 (CST) X-Originating-IP: [202.115.28.189] Date: Tue, 28 Jun 2005 22:04:55 +0800 From: "QinKe" To: "msec" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050628140509.D14EE8C658@six.pairlist.net> Subject: [MSEC] a question about address preservation 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="===============0592422254==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============0592422254== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBCcmlhbiBXZWlzOg0KDQpJbiB0aGUgZG9jdW1lbnQgbXNlYzktSUVURjYwLUlQc2VjLVNp Z25hbGF0dXJlcy5wZGYsIHBhZ2UgNywgeW91IHByb3Bvc2VkIHBvc3NpYmxlIHNvbHV0aW9ucy4g WW91IHNhaWQgobBVc2UgdHVubmVsIGVuY2Fwc3VsYXRpb24sIGJ1dCBwcmVzZXJ2ZSB0aGUgb3Jp Z2luYWwgYWRkcmVzc2VzobEuIEkgYW0gYSBsaXR0bGUgY29uZnVzZWQuIElmIGEgdHVubmVsIGlz IGVzdGFibGlzaGVkIGJldHdlZW4gdHdvIHJvdXRlcnMgQSBhbmQgQiwgdGhlbiB0aGV5IHdpbGwg Y29tbXVuaWNhdGUgdW5kZXIgdGhlIHByb3RlY3Rpb24gb2YgdGhlIFNBIHRoYXQgdGhleSBuZWdv dGlhdGVkLiBTbyBpZiBhbiBJUHNlYyBnYXRld2F5IEEgcHJlc2VydmVzIHRoZSBvcmlnaW5hbCBh ZGRyZXNzZXMsIGFmdGVyIHJvdXRlciBCIHJlY2lldmVkIHBhY2tldHMgZnJvbSByb3V0ZXIgQSwg aGUgd2lsbCBmaW5kIHRoZSBwYWNrZXQncyBzb3VyY2UgaXMgb3JpZ2luYWwgc291cmNlIFNSQyxO T1QgQSwgc28gaG93IHdpbGwgQiBmaW5kcyB0aGUgY29ycmVjdCBTUEk/IEkgaGF2ZSBub3QgcmVh ZCBhbnkgZG9jdW1lbnRzIGFib3V0IHRoaXMgQWRkcmVzcyBQcmVzZXJ2YXRpb24uIFdvdWxkIHlv dSBzZW5kIG1lIGEgY29weSBvciB0ZWxsIG1lIHdoZXJlIGNhbiBJIGZpbmQgb25lPyANCg0KDQog ICAgICAgICAgICAgICAgIC0tLS0tLSAgICAgICAgICAtLS0tLS0gICAgICAgICB0dW5uZWwgICAg ICAgICAgLS0tLS0tLQ0KICAgICAgICAgICAgICAgIHwgU1JDICB8PD09PT09PiB8ICBBICAgfDw9 PT09PT09PT09PT09PT09PT09PT4gfCAgIEIgICB8DQogICAgICAgICAgICAgICAgIC0tLS0tLSAg ICAgICAgICAtLS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLQ0KDQoNCqGhoaGh oaGhCQkJUWluS2UNCqGhoaGhoaGhoaGhoaGhoaF5dXh1YW5xa0AxMjYuY29tDQqhoaGhoaGhoaGh oaGhoaGhoaGhoTIwMDUtMDYtMjgNCg== --===============0592422254== 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 --===============0592422254==-- From msec-bounces@securemulticast.org Tue Jun 28 16:01:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMGV-0003G0-EQ for msec-archive@megatron.ietf.org; Tue, 28 Jun 2005 16:01:03 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14259 for ; Tue, 28 Jun 2005 16:01:01 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 45E828C8AB; Tue, 28 Jun 2005 16:01: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 159418C883 for ; Tue, 28 Jun 2005 16:01:01 -0400 (EDT) Received: (qmail 32724 invoked by uid 3269); 28 Jun 2005 20:01:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32721 invoked from network); 28 Jun 2005 20:01:00 -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; 28 Jun 2005 20:01:00 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2005 13:01:00 -0700 Received: from [128.107.178.183] (dhcp-128-107-178-183.cisco.com [128.107.178.183]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5SK0uod019318; Tue, 28 Jun 2005 13:00:56 -0700 (PDT) Message-ID: <42C1AC7F.1020305@cisco.com> Date: Tue, 28 Jun 2005 13:01:03 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: QinKe Subject: Re: [MSEC] a question about address preservation References: <20050628140509.D14EE8C658@six.pairlist.net> In-Reply-To: <20050628140509.D14EE8C658@six.pairlist.net> Content-Type: text/plain; charset=GB2312 Cc: msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14259 Hi QinKe, QinKe wrote: > Dear Brian Weis: > =20 > In the document msec9-IETF60-IPsec-Signalatures.pdf, page 7, you propos= ed > possible solutions. You said Use tunnel encapsulation, but preserve the > original addresses. I am a little confused. If a tunnel is established = between > two routers A and B, then they will communicate under the protection of= the SA > that they negotiated. So if an IPsec gateway A preserves the original > addresses, after router B recieved packets from router A, he will find = the > packet's source is original source SRC,NOT A, so how will B finds the c= orrect > SPI?=20 The SA lookup on B must follow the rules in Section 4.1 of draft-ietf-ipsec-rfc2401bis-06.txt. In some cases, the SA lookup for a multicast packet does not include the source address -- only the {SPI, destination} is used for the SA lookup. In this case, the source of the packet doesn't matter to IPsec. In other cases {SPI, destination, source} is used for the SA lookup. In that case, the group key management protocol must install the SA with source=3DSRC and destination=3Dmulticast-address. In this way, B will find the correct SPI. I have not read any documents about this Address Preservation. Would you > send me a copy or tell me where can I find one?=20 The slide you found is currently the only place this is mentioned. A document will be submitted to MSEC soon that will describe Address Preservation more fully. Brian >=20 > ------ ------ tunnel ------- > | SRC |<=3D=3D=3D=3D=3D> | A |<=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> | B | > ------ ------ ------- >=20 >=20 > =A1=A1=A1=A1=A1=A1=A1=A1 QinKe > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1yuxuanqk@126.com > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-06-28 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec --=20 Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec