From msec-admin@securemulticast.org Thu Oct 2 20:35:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02420 for ; Thu, 2 Oct 2003 20:35:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 835C85370B; Thu, 2 Oct 2003 20:35:14 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5E7C75370A for ; Thu, 2 Oct 2003 20:33:32 -0400 (EDT) Received: (qmail 72077 invoked by uid 3269); 3 Oct 2003 00:33:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72074 invoked from network); 3 Oct 2003 00:33:32 -0000 Received: from smtp018.mail.yahoo.com (216.136.174.115) by klesh.pair.com with SMTP; 3 Oct 2003 00:33:32 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.147.185.166 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Oct 2003 00:33:31 -0000 Message-Id: <5.2.1.1.2.20031002202943.00b03cc8@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com, thardjono@verisign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Call for MSEC agenda items for IETF-58 Minn. Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 02 Oct 2003 20:33:29 -0400 [nb. Apologies if this is late -- I've been away for the last 3 weeks without email access]. Folks, In the upcoming IETF-58 at Minn., MSEC will be meeting tentatively on Monday morning (Nov 9) at 9am. Its been a while since we have been assigned a morning time-slot :) Please send proposals for agenda items to Ran and myself. Best, Ran/Thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 05:03:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27890 for ; Fri, 3 Oct 2003 05:03:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2FBF453B97; Fri, 3 Oct 2003 04:58:48 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0D3B25355F for ; Thu, 2 Oct 2003 21:28:42 -0400 (EDT) Received: (qmail 85970 invoked by uid 3269); 3 Oct 2003 01:28:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85959 invoked from network); 3 Oct 2003 01:28:41 -0000 Received: from smtp100.mail.sc5.yahoo.com (216.136.174.138) by klesh.pair.com with SMTP; 3 Oct 2003 01:28:41 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.147.185.166 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Oct 2003 01:28:40 -0000 Message-Id: <5.2.1.1.2.20031002212235.00b03e00@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] WG Last Call for GKM-Architecture draft (closing date 17 October 2003) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 02 Oct 2003 21:28:33 -0400 Folks, Now that the GKM-Arch draft has been revised (currently version-06), I'd like to set a new closing date of 17 October (Friday) for WG Last Call. Please review the draft and post issues/questions to the list a.s.a.p. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 12:28:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15117 for ; Fri, 3 Oct 2003 12:28:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B2624536D4; Fri, 3 Oct 2003 12:28:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E59BC5360C for ; Fri, 3 Oct 2003 12:27:05 -0400 (EDT) Received: (qmail 71270 invoked by uid 3269); 3 Oct 2003 16:27:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71267 invoked from network); 3 Oct 2003 16:27:05 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 16:27:05 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93GR4Z6013948 for ; Fri, 3 Oct 2003 11:27:04 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93GR0U3006645 for ; Fri, 3 Oct 2003 11:27:02 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA13262 for ; Fri, 3 Oct 2003 12:26:59 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93GPQD07024 for msec@securemulticast.org; Fri, 3 Oct 2003 12:25:26 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 11: policy token payload digital signature Message-ID: <20031003122526.A6992@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Sat, Aug 09, 2003 at 08:25:35AM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 12:25:26 -0400 This is correct, this sentance makes an implication that we did not desire to convey. We suggest that this sentance be removed. To clarify this section, we suggest the rewording of the section as follows: The Policy Token Payload contains authenticatable group specific information that describes the group security relevant behaviors, access control parameters, and security mechanisms. Figure 5 shows ... Beyond this, we don't wish to levy any more specific requirements from GSAKMP on the Policy Token. UM On Sat, Aug 09, 2003 at 08:25:35AM -0400, George Gross wrote: > 2 of 4 e-mails that are being resent... > > GSAKMP issue 11 > > Section and relevant text passage: > > 6.3 Policy Token Payload > > The text that says "This information may contain a digital signature(s) to > prove authority and integrity of the information." > > Comment/issue description: > > The word "may" probably was intended to be "MUST" > > Suggested issue resolution: > > s/may/MUST/ > > If you really did mean to say "may", then explain when that is allowed. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 12:34:42 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15487 for ; Fri, 3 Oct 2003 12:34:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 09322538DD; Fri, 3 Oct 2003 12:34:16 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 29BDE5390E for ; Fri, 3 Oct 2003 12:32:47 -0400 (EDT) Received: (qmail 72347 invoked by uid 3269); 3 Oct 2003 16:32:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72344 invoked from network); 3 Oct 2003 16:32:47 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 16:32:47 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93GWkZ6014051 for ; Fri, 3 Oct 2003 11:32:46 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93GWjU3006826 for ; Fri, 3 Oct 2003 11:32:45 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA13347 for ; Fri, 3 Oct 2003 12:32:44 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93GVBC07049 for msec@securemulticast.org; Fri, 3 Oct 2003 12:31:11 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 12: Policy Token Payload table 9 Message-ID: <20031003123111.B6992@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Sat, Aug 09, 2003 at 08:27:36AM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 12:31:11 -0400 By looking at this table again, it is apparent that the values in this table are out of date, and correctly stated there is no designation of the MUST PT to be implemented. The table will be fixed to show correct values for types of Policy tokens. We are still working this through, but the values will be something of the sort: 0 GSAKMP v1 Policy Token (pointing to the current PT draft) 1 Another Policy Token format (pointing to that draft) etc. My understanding is that there is some offline discussions (Hugh and Goerge) in trying to determine another minimalistic token which might take to the MUST to implement case. UM On Sat, Aug 09, 2003 at 08:27:36AM -0400, George Gross wrote: > 3 of 4 e-mails resent > > GSAKMP issue 12 > > Section and relevant text passage: > > 6.3 Policy Token Payload, table 9 > > Comment/issue description: > > Did not state the "Group" policy token type is the default mandatory to implement value. > The "Auxillary" type is not defined, when is it used? > > Suggested issue resolution: > > elaborate on how there can be various policy token types, indicate "Group" is the default. > refer to a Normative Reference that defines the "Group" policy token. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 12:37:42 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15675 for ; Fri, 3 Oct 2003 12:37:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8105553988; Fri, 3 Oct 2003 12:36:16 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1B14553975 for ; Fri, 3 Oct 2003 12:34:49 -0400 (EDT) Received: (qmail 72729 invoked by uid 3269); 3 Oct 2003 16:34:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72726 invoked from network); 3 Oct 2003 16:34:49 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 16:34:49 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93GYnZ6014071 for ; Fri, 3 Oct 2003 11:34:49 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93GYmU3006886 for ; Fri, 3 Oct 2003 11:34:48 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA13367 for ; Fri, 3 Oct 2003 12:34:47 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93GXEq07060 for msec@securemulticast.org; Fri, 3 Oct 2003 12:33:14 -0400 From: Uri Meth To: msec@securemulticast.org Message-ID: <20031003123314.A7053@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Subject: [MSEC] flurry of responses Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 12:33:14 -0400 MSEC group, My appologies for clumping my responses in short order. I generally like to spread them out, but I have been in the office sporadically as of late and wanted to get all the information I have compiled over that past few weeks out to the list for discussion. Thanx for your indulgance. UM -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 12:42:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15874 for ; Fri, 3 Oct 2003 12:42:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 81BED5390E; Fri, 3 Oct 2003 12:42:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 136185396A for ; Fri, 3 Oct 2003 12:40:34 -0400 (EDT) Received: (qmail 73865 invoked by uid 3269); 3 Oct 2003 16:40:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73862 invoked from network); 3 Oct 2003 16:40:34 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 16:40:34 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93GeXZ6014223 for ; Fri, 3 Oct 2003 11:40:33 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93GeWU3007117 for ; Fri, 3 Oct 2003 11:40:32 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA13478 for ; Fri, 3 Oct 2003 12:40:31 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93Gcwu07085 for msec@securemulticast.org; Fri, 3 Oct 2003 12:38:58 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 13: Rekey Event Payload "ID Type" field Message-ID: <20031003123858.A7065@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Sat, Aug 09, 2003 at 08:28:55AM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 12:38:58 -0400 See inline comments. On Sat, Aug 09, 2003 at 08:28:55AM -0400, George Gross wrote: > 4 of 4 e-mails resent > > > GSAKMP issue 13 > > Section and relevant text passage: > > 6.5 Rekey Event Payload > > The "ID Type" field's definition. > > Comment/issue description: > > The "ID Type" field should be renamed "Rekey ID Type" so it is distinct from the > other fields with similar sounding names. Correct. As a matter of fact this is a problem in a lot of payloads within the spec. The whole spec will be scrubbed to make all of the "ID Type" fields unique. > > In table 11, when is "Group Recovery" specified versus "Maintenance"? Again, the values in this table no longer work in the current context. This table should be modified as follows: 0 None (This is the MUST implement) 1 GSAKMP LKH (This payload will contain LKH data in GSAKMP defined format) 2 - 255 RESERVED For the None case, the size of the "Rekey Event Data" field will be zero (0) bytes long. The purpose of a Rekey Even Payload with type None is when it is necessary to send out a new token with no rekey information. The Rekey Msg requires a Rekey Event PL, and in this instance it would have rekey data of type None. > > Suggested issue resolution: > > s/ID Type/Rekey ID Type/ > > I could make a guess, but the text should elaborate on the definition of > each of the values in table 11. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec UM -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 13:26:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17413 for ; Fri, 3 Oct 2003 13:26:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 05796535BC; Fri, 3 Oct 2003 13:26:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BC575535BC for ; Fri, 3 Oct 2003 13:24:37 -0400 (EDT) Received: (qmail 81908 invoked by uid 3269); 3 Oct 2003 17:24:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81905 invoked from network); 3 Oct 2003 17:24:37 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 17:24:37 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93HOaZ6014912 for ; Fri, 3 Oct 2003 12:24:36 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93HOYU3008527 for ; Fri, 3 Oct 2003 12:24:34 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA13935 for ; Fri, 3 Oct 2003 13:24:33 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93HMxs07252 for msec@securemulticast.org; Fri, 3 Oct 2003 13:22:59 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 14: Rekey Event Data field's reference to appendix A.3 Message-ID: <20031003132259.A7234@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:37:58PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:22:59 -0400 Good catch. A little confusion in the document format. In the spec, all LKH specific information is in Appendix B. At this time, the available rekey data is of type LKH. The definitions for Rekey Type (see posting for number 13) and Rekey Event Data will be fixed such that everything will point to the correct place. UM On Fri, Aug 08, 2003 at 03:37:58PM -0400, George Gross wrote: > > GSAKMP issue 14 > > Section and relevant text passage: > > 6.5 Rekey Event Payload > > The "Rekey Event Data" field's definition > > Comment/issue description: > > The format of this field is supposed to be in Appendix A.3. However, > that appendix does not have pictures or text for various "ID Type" > values. Or is the format of this field really meant to depend on the Rekey > Protocol/Algorithm rather than the "Rekey Event Type" found in table 11? > > Suggested issue resolution: > > fill-in appendix A.3 > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 13:26:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17443 for ; Fri, 3 Oct 2003 13:26:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 72CAA539D6; Fri, 3 Oct 2003 13:26:13 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C611B535AE for ; Fri, 3 Oct 2003 13:25:52 -0400 (EDT) Received: (qmail 82137 invoked by uid 3269); 3 Oct 2003 17:25:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82134 invoked from network); 3 Oct 2003 17:25:52 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 17:25:52 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93HPqZ6014924 for ; Fri, 3 Oct 2003 12:25:52 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93HPpU3008567 for ; Fri, 3 Oct 2003 12:25:51 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA13951 for ; Fri, 3 Oct 2003 13:25:50 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93HOGO07262 for msec@securemulticast.org; Fri, 3 Oct 2003 13:24:16 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 15: clarify "ID Type" field for Identification Payload Message-ID: <20031003132416.B7234@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:39:06PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:24:16 -0400 Agreed, this will be fixed in the general scrub of the spec to make all "ID Type" fields unique to the type of payload it is in. UM On Fri, Aug 08, 2003 at 03:39:06PM -0400, George Gross wrote: > > GSAKMP issue 15 > > Section and relevant text passage: > > 6.6 Identification Payload > > The "ID Type" field's definition > > Comment/issue description: > > The name of this field should be changed to make unambiguous. > > Suggested issue resolution: > > s/ID Type/ID Data Type/ > > The caption for Table 12 should say "Identification Data Types" > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 13:30:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17553 for ; Fri, 3 Oct 2003 13:30:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4C03F535BC; Fri, 3 Oct 2003 13:30:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A0574539E8 for ; Fri, 3 Oct 2003 13:28:04 -0400 (EDT) Received: (qmail 82544 invoked by uid 3269); 3 Oct 2003 17:28:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82541 invoked from network); 3 Oct 2003 17:28:04 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 17:28:04 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93HS1Z6014954 for ; Fri, 3 Oct 2003 12:28:01 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93HRxU3008637 for ; Fri, 3 Oct 2003 12:27:59 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA14033 for ; Fri, 3 Oct 2003 13:27:58 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93HQPQ07276 for msec@securemulticast.org; Fri, 3 Oct 2003 13:26:25 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 16: allow other signature types besides DSA? Message-ID: <20031003132625.C7234@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:39:55PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:26:25 -0400 Yes, this will be allowed in that RSA and other types can be registered with IANA when necessary. BTW< we are still in the process of getting IANA registration of values which will facilitate this addition. UM On Fri, Aug 08, 2003 at 03:39:55PM -0400, George Gross wrote: > > GSAKMP issue 16 > > Section and relevant text passage: > > 6.8 Signature Payload table 14 > > Comment/issue description: > > Would it be reasonable to allow RSA signature as an optional signature type? > > Suggested issue resolution: > > Leave DSS as the mandatory to implement, add RSA (would need to add > informative refs to PKCS specs too I'd guess). > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 13:34:29 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17681 for ; Fri, 3 Oct 2003 13:34:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 29B26539A8; Fri, 3 Oct 2003 13:34:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 53826539A8 for ; Fri, 3 Oct 2003 13:32:34 -0400 (EDT) Received: (qmail 83295 invoked by uid 3269); 3 Oct 2003 17:32:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83292 invoked from network); 3 Oct 2003 17:32:34 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 17:32:34 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93HWXZ6015049 for ; Fri, 3 Oct 2003 12:32:33 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93HWWU3008801 for ; Fri, 3 Oct 2003 12:32:33 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA14135 for ; Fri, 3 Oct 2003 13:32:32 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93HUvQ07421 for msec@securemulticast.org; Fri, 3 Oct 2003 13:30:57 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 17: clarify authorization roles Message-ID: <20031003133057.D7234@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:40:48PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:30:57 -0400 Upon further reflection and investigation, the information of Signature ID Role is superfluous. I really don't care what the SigPL tells me his role is, this must be checked against the Policy Token. Therefore, this information should really be deleted from this PL. This way, there is no need to save (irrelevant) state information, we always check everything against the source, the Policy Token. UM On Fri, Aug 08, 2003 at 03:40:48PM -0400, George Gross wrote: > > GSAKMP issue 17 > > Section and relevant text passage: > > 6.8 Signature Payload table 16 authorization types > > Comment/issue description: > > The authorization roles appear to be something that the GM must save as GSA > state information. Then when a rekey message arrives, if the rekey originated > from a party who is not a key server then the message should be ignored. right? > > Suggested issue resolution: > > the text should explain how the group member interprets this field, and uses > its for authorization screening. It should suggest error logging by the GM. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 13:43:14 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17978 for ; Fri, 3 Oct 2003 13:43:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7BB5753A20; Fri, 3 Oct 2003 13:40:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 81F7A53A1A for ; Fri, 3 Oct 2003 13:38:49 -0400 (EDT) Received: (qmail 84360 invoked by uid 3269); 3 Oct 2003 17:38:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84357 invoked from network); 3 Oct 2003 17:38:49 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 17:38:49 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93HcnZ6015123 for ; Fri, 3 Oct 2003 12:38:49 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93HcmU3008986 for ; Fri, 3 Oct 2003 12:38:48 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA14248 for ; Fri, 3 Oct 2003 13:38:47 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93HbDE07697 for msec@securemulticast.org; Fri, 3 Oct 2003 13:37:13 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 18: use of Notify to assist data synchronization Message-ID: <20031003133713.E7234@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:42:19PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:37:13 -0400 Upon further reflection, this is a piece of holdover information from ISAKMP which really makes no sense here. It is really not used for anything. Therefore, we recomment it be removed. UM On Fri, Aug 08, 2003 at 03:42:19PM -0400, George Gross wrote: > > GSAKMP issue 18 > > Section and relevant text passage: > > 6.9 Notification Payload, the text that says: > > "For example, a secure front end or security gateway may use > the Notify message to synchronize SA communication. Table 18 > presents the Notification Payload Status Types. > > Comment/issue description: > > This text indicating how to achieve synchronization should be cloned > to other parts of the spec so it is not overlooked. The table 18 > does not offer enough information to know how to do this synchronization > with the various "status types". When are these flavors of Notify > sent by the GCKS? or the GM? > > Suggested issue resolution: > > explain the synchronization solution in a new section. include > a protocol ladder diagram. modify the section 7 state diagram > to reflect these improvements. > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 3 13:45:05 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18068 for ; Fri, 3 Oct 2003 13:45:05 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5452453636; Fri, 3 Oct 2003 13:42:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C279553554 for ; Fri, 3 Oct 2003 13:40:45 -0400 (EDT) Received: (qmail 84751 invoked by uid 3269); 3 Oct 2003 17:40:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84748 invoked from network); 3 Oct 2003 17:40:45 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Oct 2003 17:40:45 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h93HejZ6015189 for ; Fri, 3 Oct 2003 12:40:45 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h93HeiU3009083 for ; Fri, 3 Oct 2003 12:40:45 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA14275 for ; Fri, 3 Oct 2003 13:40:44 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h93HdAF07709 for msec@securemulticast.org; Fri, 3 Oct 2003 13:39:10 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 19: Notify payload type trigger conditions Message-ID: <20031003133910.F7234@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:43:24PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 3 Oct 2003 13:39:10 -0400 Yes, this table needs an explanation for each type in it. This will be added in the next rev of the spec (sort of what IKEv2 did for a lot of its values in tables). Boy, I sure have a lot of writeups to get out there :-o) Have a great weekend everybody. See you next week. UM On Fri, Aug 08, 2003 at 03:43:24PM -0400, George Gross wrote: > > GSAKMP issue 19 > > Section and relevant text passage: > > 6.9 Notify Payload table 17 > > Comment/issue description: > > Some of the payload types do not have obvious > trigger conditions. these are: > > - Situation-not-supported (where is the situation specified?) > - Invalid-version (as mentioned in other issues) > - Invalid-Sequence-ID (given packets can delivery out of order) > - Invalid-ID-Information (which ID?) > - Notify-GSA-Lifetime (is this to say the group needs to self-destruct?) > - Unable-to-take-requested-role (for which message would a node do this?) > > Suggested issue resolution: > > Add descriptive text at this point in the spec, or else at the point > where the Notify could be generated by verification processing. > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Oct 5 19:52:18 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29618 for ; Sun, 5 Oct 2003 19:52:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8D0B253961; Sun, 5 Oct 2003 19:48:44 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3DA975363D for ; Sun, 5 Oct 2003 19:46:59 -0400 (EDT) Received: (qmail 18017 invoked by uid 3269); 5 Oct 2003 23:46:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18014 invoked from network); 5 Oct 2003 23:46:59 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 5 Oct 2003 23:46:59 -0000 Received: (qmail 89276 invoked by uid 1000); 5 Oct 2003 23:46:56 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.023162 secs); 05 Oct 2003 23:46:56 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 5 Oct 2003 23:46:56 -0000 Received: (qmail 36944 invoked from network); 5 Oct 2003 23:46:55 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.165) by smtp-auth.nac.net with SMTP; 5 Oct 2003 23:46:55 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h95LY1f31140; Sun, 5 Oct 2003 17:34:01 -0400 From: George Gross To: Uri Meth Cc: Subject: Re: [MSEC] GSAKMP issue 18: use of Notify to assist data synchronization In-Reply-To: <20031003133713.E7234@charlie.columbia.sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 5 Oct 2003 17:34:01 -0400 (EDT) Hi Uri, ok, I'm fine with removing the text in question... br, George On Fri, 3 Oct 2003, Uri Meth wrote: > Upon further reflection, this is a piece of holdover information from > ISAKMP which really makes no sense here. It is really not used for > anything. Therefore, we recomment it be removed. > > UM > > On Fri, Aug 08, 2003 at 03:42:19PM -0400, George Gross wrote: > > > > GSAKMP issue 18 > > > > Section and relevant text passage: > > > > 6.9 Notification Payload, the text that says: > > > > "For example, a secure front end or security gateway may use > > the Notify message to synchronize SA communication. Table 18 > > presents the Notification Payload Status Types. > > > > Comment/issue description: > > > > This text indicating how to achieve synchronization should be cloned > > to other parts of the spec so it is not overlooked. The table 18 > > does not offer enough information to know how to do this synchronization > > with the various "status types". When are these flavors of Notify > > sent by the GCKS? or the GM? > > > > Suggested issue resolution: > > > > explain the synchronization solution in a new section. include > > a protocol ladder diagram. modify the section 7 state diagram > > to reflect these improvements. > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Oct 5 19:55:25 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29684 for ; Sun, 5 Oct 2003 19:55:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9EE4E537B5; Sun, 5 Oct 2003 19:53:36 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 21DBA537BF for ; Sun, 5 Oct 2003 19:51:57 -0400 (EDT) Received: (qmail 18576 invoked by uid 3269); 5 Oct 2003 23:51:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18573 invoked from network); 5 Oct 2003 23:51:57 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 5 Oct 2003 23:51:57 -0000 Received: (qmail 97770 invoked by uid 1000); 5 Oct 2003 23:51:56 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.040033 secs); 05 Oct 2003 23:51:56 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 5 Oct 2003 23:51:55 -0000 Received: (qmail 53273 invoked from network); 5 Oct 2003 23:51:55 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.165) by smtp-auth.nac.net with SMTP; 5 Oct 2003 23:51:55 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h95Ld1H31161; Sun, 5 Oct 2003 17:39:01 -0400 From: George Gross To: Uri Meth Cc: Subject: Re: [MSEC] GSAKMP issue 17: clarify authorization roles In-Reply-To: <20031003133057.D7234@charlie.columbia.sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 5 Oct 2003 17:39:01 -0400 (EDT) Hi Uri, On Fri, 3 Oct 2003, Uri Meth wrote: > Upon further reflection and investigation, the information of Signature > ID Role is superfluous. I really don't care what the SigPL tells me his > role is, this must be checked against the Policy Token. Therefore, this > information should really be deleted from this PL. This way, there is > no need to save (irrelevant) state information, we always check > everything against the source, the Policy Token. this makes sense. so long as there is some text explaining the authorization check on the re-key message's source, verifying that it is a GCKS, and describing the GM's error response when it isn't a GCKS, then this issue is closed. thx, George > > UM > > On Fri, Aug 08, 2003 at 03:40:48PM -0400, George Gross wrote: > > > > GSAKMP issue 17 > > > > Section and relevant text passage: > > > > 6.8 Signature Payload table 16 authorization types > > > > Comment/issue description: > > > > The authorization roles appear to be something that the GM must save as GSA > > state information. Then when a rekey message arrives, if the rekey originated > > from a party who is not a key server then the message should be ignored. right? > > > > Suggested issue resolution: > > > > the text should explain how the group member interprets this field, and uses > > its for authorization screening. It should suggest error logging by the GM. > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Oct 5 20:00:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29830 for ; Sun, 5 Oct 2003 20:00:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A8BDB53600; Sun, 5 Oct 2003 20:00:19 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1281D53600 for ; Sun, 5 Oct 2003 19:58:26 -0400 (EDT) Received: (qmail 19500 invoked by uid 3269); 5 Oct 2003 23:58:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19497 invoked from network); 5 Oct 2003 23:58:26 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 5 Oct 2003 23:58:26 -0000 Received: (qmail 8873 invoked by uid 1000); 5 Oct 2003 23:58:25 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.023071 secs); 05 Oct 2003 23:58:25 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 5 Oct 2003 23:58:24 -0000 Received: (qmail 75519 invoked from network); 5 Oct 2003 23:58:24 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.165) by smtp-auth.nac.net with SMTP; 5 Oct 2003 23:58:24 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h95LjUX31185; Sun, 5 Oct 2003 17:45:30 -0400 From: George Gross To: Uri Meth Cc: Subject: Re: [MSEC] GSAKMP issue 19: Notify payload type trigger conditions In-Reply-To: <20031003133910.F7234@charlie.columbia.sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 5 Oct 2003 17:45:30 -0400 (EDT) Hi Uri, On Fri, 3 Oct 2003, Uri Meth wrote: > Yes, this table needs an explanation for each type in it. This will be > added in the next rev of the spec (sort of what IKEv2 did for a lot of > its values in tables). thx, that will help this section alot. > > Boy, I sure have a lot of writeups to get out there :-o) if it is any consolation for all the revision effort, I think the resulting draft will be miles closer to what will work for future implementors and IESG review. thanks for moving forward on these issues! br, George > > Have a great weekend everybody. See you next week. P.S. thx, it was great weekend, too bad it was sooo short... ;o) > > UM > > On Fri, Aug 08, 2003 at 03:43:24PM -0400, George Gross wrote: > > > > GSAKMP issue 19 > > > > Section and relevant text passage: > > > > 6.9 Notify Payload table 17 > > > > Comment/issue description: > > > > Some of the payload types do not have obvious > > trigger conditions. these are: > > > > - Situation-not-supported (where is the situation specified?) > > - Invalid-version (as mentioned in other issues) > > - Invalid-Sequence-ID (given packets can delivery out of order) > > - Invalid-ID-Information (which ID?) > > - Notify-GSA-Lifetime (is this to say the group needs to self-destruct?) > > - Unable-to-take-requested-role (for which message would a node do this?) > > > > Suggested issue resolution: > > > > Add descriptive text at this point in the spec, or else at the point > > where the Notify could be generated by verification processing. > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 7 11:06:36 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05800 for ; Tue, 7 Oct 2003 11:06:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8AC4A53909; Tue, 7 Oct 2003 11:06:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BE05653898 for ; Tue, 7 Oct 2003 11:05:44 -0400 (EDT) Received: (qmail 83127 invoked by uid 3269); 7 Oct 2003 15:05:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83124 invoked from network); 7 Oct 2003 15:05:44 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 7 Oct 2003 15:05:44 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05704; Tue, 7 Oct 2003 11:05:34 -0400 (EDT) Message-Id: <200310071505.LAA05704@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-dhhmac-04.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 07 Oct 2003 11:05:34 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : HMAC-authenticated Diffie-Hellman for MIKEY Author(s) : M. Euchner Filename : draft-ietf-msec-mikey-dhhmac-04.txt Pages : 28 Date : 2003-10-7 This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-dhhmac-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-7111023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-dhhmac-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-7111023.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 7 12:23:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10531 for ; Tue, 7 Oct 2003 12:22:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4CEB253755; Tue, 7 Oct 2003 12:22:18 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9B97F53613 for ; Tue, 7 Oct 2003 12:20:56 -0400 (EDT) Received: (qmail 98412 invoked by uid 3269); 7 Oct 2003 16:20:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98406 invoked from network); 7 Oct 2003 16:20:56 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 7 Oct 2003 16:20:56 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id h97GHEx48262 for ; Tue, 7 Oct 2003 12:17:14 -0400 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7) with ESMTP id h97GKtu29762 for ; Tue, 7 Oct 2003 12:20:55 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) with ESMTP id MAA30838 for ; Tue, 7 Oct 2003 12:20:54 -0400 From: canetti To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] DHHMAC draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 7 Oct 2003 12:20:54 -0400 (EDT) Folks, The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has recently completed its last call with no remarks. Infact, there seemed to have been little discussion on this draft on the list. In light of this, we'd like to poll the WG on whether there is interest in advancing this draft to proposed standard, along with MIKEY. Please speak your mind. Best, Thomas and Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 7 13:13:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12111 for ; Tue, 7 Oct 2003 13:13:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 85DF1538EB; Tue, 7 Oct 2003 13:12:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F0D2E5366D for ; Tue, 7 Oct 2003 13:10:18 -0400 (EDT) Received: (qmail 6924 invoked by uid 3269); 7 Oct 2003 17:10:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6921 invoked from network); 7 Oct 2003 17:10:18 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 7 Oct 2003 17:10:18 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h97HA5M01552; Tue, 7 Oct 2003 12:10:05 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S5BDXT2M; Tue, 7 Oct 2003 10:10:05 -0700 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TRQTBF0T; Tue, 7 Oct 2003 13:10:03 -0400 Message-ID: <3F82F36A.2060700@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: canetti Cc: msec@securemulticast.org, Thomas Hardjono Subject: Re: [MSEC] DHHMAC draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 07 Oct 2003 13:10:02 -0400 Content-Transfer-Encoding: 7bit This may have been brought up before (it was in another context). But, has the following question been answered for dhhmac I-D "Do we need the IETF standardizing yet another DH-based key management protocol?" regards, Lakshminath canetti wrote: >Folks, > >The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has recently >completed its last call with no remarks. Infact, there seemed to have been >little discussion on this draft on the list. In light of this, we'd like >to poll the WG on whether there is interest in advancing this draft to >proposed standard, along with MIKEY. Please speak your mind. > >Best, > >Thomas and Ran > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 7 15:55:16 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19646 for ; Tue, 7 Oct 2003 15:55:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 102C353709; Tue, 7 Oct 2003 15:54:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E3F1753770 for ; Tue, 7 Oct 2003 15:52:40 -0400 (EDT) Received: (qmail 35987 invoked by uid 3269); 7 Oct 2003 19:52:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35984 invoked from network); 7 Oct 2003 19:52:40 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 7 Oct 2003 19:52:40 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h97JqeZ6002712; Tue, 7 Oct 2003 14:52:40 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h97JqcU3004294; Tue, 7 Oct 2003 14:52:39 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA10495; Tue, 7 Oct 2003 15:52:37 -0400 (EDT) Subject: Re: [MSEC] DHHMAC draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: msec@securemulticast.org To: canetti From: Hugh Harney In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 7 Oct 2003 15:52:37 -0400 Content-Transfer-Encoding: 7bit Ran, With the caveat that was included in the spec. Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond a point-to-point constellation; thus, both MIKEY Diffie-Hellman protocols do not support group-based keying for any group size larger than two entities. Very little can be said about this draft from the perspective of group security. Hugh I just worry that people will automatically On Tuesday, Oct 7, 2003, at 12:20 US/Eastern, canetti wrote: > > Folks, > > The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has recently > completed its last call with no remarks. Infact, there seemed to have > been > little discussion on this draft on the list. In light of this, we'd > like > to poll the WG on whether there is interest in advancing this draft to > proposed standard, along with MIKEY. Please speak your mind. > > Best, > > Thomas and Ran > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 7 17:10:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22634 for ; Tue, 7 Oct 2003 17:10:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 494A5539A9; Tue, 7 Oct 2003 17:08:55 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7625A539D5 for ; Tue, 7 Oct 2003 17:07:12 -0400 (EDT) Received: (qmail 49571 invoked by uid 3269); 7 Oct 2003 21:07:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49568 invoked from network); 7 Oct 2003 21:07:12 -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; 7 Oct 2003 21:07:12 -0000 Received: from cscoamera13263.cisco.com (rtp-vpn2-586.cisco.com [10.82.242.74]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h97L7802024516; Tue, 7 Oct 2003 17:07:09 -0400 (EDT) Message-Id: <6.0.0.22.2.20031007140630.03b50fc8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] DHHMAC draft Cc: canetti , msec@securemulticast.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 07 Oct 2003 14:07:05 -0700 Hugh, At 12:52 PM 10/7/2003, Hugh Harney wrote: >Ran, > >With the caveat that was included in the spec. > > Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond > a point-to-point constellation; thus, both MIKEY Diffie-Hellman > protocols do not support group-based keying for any group size larger > than two entities. > >Very little can be said about this draft from the perspective of group >security. It's appropriate to a registration protocol for group security. Mark >Hugh > >I just worry that people will automatically >On Tuesday, Oct 7, 2003, at 12:20 US/Eastern, canetti wrote: > >> >>Folks, >> >>The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has recently >>completed its last call with no remarks. Infact, there seemed to have been >>little discussion on this draft on the list. In light of this, we'd like >>to poll the WG on whether there is interest in advancing this draft to >>proposed standard, along with MIKEY. Please speak your mind. >> >>Best, >> >>Thomas and Ran >> >> >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> >Hugh Harney Sparta, Inc. >hh@sparta.com 7075 Samuel Morse >Drive >(410) 872-1515 x203 Columbia, MD, 21046 > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 7 17:47:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23724 for ; Tue, 7 Oct 2003 17:47:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0049453673; Tue, 7 Oct 2003 17:46:14 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B810B538E0 for ; Tue, 7 Oct 2003 17:44:42 -0400 (EDT) Received: (qmail 56261 invoked by uid 3269); 7 Oct 2003 21:44:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56256 invoked from network); 7 Oct 2003 21:44:42 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 7 Oct 2003 21:44:42 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h97LicZ6004495; Tue, 7 Oct 2003 16:44:38 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h97LibU3008133; Tue, 7 Oct 2003 16:44:37 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id RAA12209; Tue, 7 Oct 2003 17:44:35 -0400 (EDT) Subject: Re: [MSEC] DHHMAC draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: canetti , msec@securemulticast.org To: Mark Baugher From: Hugh Harney In-Reply-To: <6.0.0.22.2.20031007140630.03b50fc8@mira-sjc5-6.cisco.com> Message-Id: <70DE7280-F90F-11D7-99D5-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 7 Oct 2003 17:44:34 -0400 Content-Transfer-Encoding: 7bit Mark, Yes it is a registration protocol. It's very narrowly focused to a specific architecture. Hugh On Tuesday, Oct 7, 2003, at 17:07 US/Eastern, Mark Baugher wrote: > Hugh, > > At 12:52 PM 10/7/2003, Hugh Harney wrote: >> Ran, >> >> With the caveat that was included in the spec. >> >> Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond >> a point-to-point constellation; thus, both MIKEY Diffie-Hellman >> protocols do not support group-based keying for any group size >> larger >> than two entities. >> >> Very little can be said about this draft from the perspective of >> group security. > > It's appropriate to a registration protocol for group security. > > Mark > > >> Hugh >> >> I just worry that people will automatically >> On Tuesday, Oct 7, 2003, at 12:20 US/Eastern, canetti wrote: >> >>> >>> Folks, >>> >>> The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has recently >>> completed its last call with no remarks. Infact, there seemed to >>> have been >>> little discussion on this draft on the list. In light of this, we'd >>> like >>> to poll the WG on whether there is interest in advancing this draft >>> to >>> proposed standard, along with MIKEY. Please speak your mind. >>> >>> Best, >>> >>> Thomas and Ran >>> >>> >>> >>> _______________________________________________ >>> msec mailing list >>> msec@securemulticast.org >>> http://www.pairlist.net/mailman/listinfo/msec >>> >> Hugh Harney >> Sparta, Inc. >> hh@sparta.com 7075 Samuel >> Morse Drive >> (410) 872-1515 x203 Columbia, MD, >> 21046 >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 7 20:52:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29866 for ; Tue, 7 Oct 2003 20:52:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1BC6B53803; Tue, 7 Oct 2003 20:52:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7E5D153613 for ; Tue, 7 Oct 2003 20:51:19 -0400 (EDT) Received: (qmail 87550 invoked by uid 3269); 8 Oct 2003 00:51:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87547 invoked from network); 8 Oct 2003 00:51:19 -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; 8 Oct 2003 00:51:19 -0000 Received: from cscoamera13263.cisco.com (rtp-vpn2-586.cisco.com [10.82.242.74]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h980pE5h026986; Tue, 7 Oct 2003 20:51:15 -0400 (EDT) Message-Id: <6.0.0.22.2.20031007174214.0349f118@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] DHHMAC draft Cc: canetti , msec@securemulticast.org In-Reply-To: <70DE7280-F90F-11D7-99D5-000A956E63C6@sparta.com> References: <6.0.0.22.2.20031007140630.03b50fc8@mira-sjc5-6.cisco.com> <70DE7280-F90F-11D7-99D5-000A956E63C6@sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 07 Oct 2003 17:43:33 -0700 Hugh, At 02:44 PM 10/7/2003, Hugh Harney wrote: >Mark, > >Yes it is a registration protocol. > >It's very narrowly focused to a specific architecture. I understand. It can go either way whether IP telephony protocols stay strictly pairwise in their security or employ group-key methods. So if it seems out of scope for group security, I think this is why. Mark >Hugh > > >On Tuesday, Oct 7, 2003, at 17:07 US/Eastern, Mark Baugher wrote: > >>Hugh, >> >>At 12:52 PM 10/7/2003, Hugh Harney wrote: >>>Ran, >>> >>>With the caveat that was included in the spec. >>> >>> Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale beyond >>> a point-to-point constellation; thus, both MIKEY Diffie-Hellman >>> protocols do not support group-based keying for any group size larger >>> than two entities. >>> >>>Very little can be said about this draft from the perspective of group >>>security. >> >>It's appropriate to a registration protocol for group security. >> >>Mark >> >> >>>Hugh >>> >>>I just worry that people will automatically >>>On Tuesday, Oct 7, 2003, at 12:20 US/Eastern, canetti wrote: >>> >>>> >>>>Folks, >>>> >>>>The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has recently >>>>completed its last call with no remarks. Infact, there seemed to have been >>>>little discussion on this draft on the list. In light of this, we'd like >>>>to poll the WG on whether there is interest in advancing this draft to >>>>proposed standard, along with MIKEY. Please speak your mind. >>>> >>>>Best, >>>> >>>>Thomas and Ran >>>> >>>> >>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://www.pairlist.net/mailman/listinfo/msec >>>Hugh Harney >>>Sparta, Inc. >>>hh@sparta.com 7075 Samuel >>>Morse Drive >>>(410) 872-1515 x203 Columbia, MD, 21046 >>> >>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://www.pairlist.net/mailman/listinfo/msec >> >> >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> >Hugh Harney Sparta, Inc. >hh@sparta.com 7075 Samuel Morse >Drive >(410) 872-1515 x203 Columbia, MD, 21046 > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 8 02:25:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28900 for ; Wed, 8 Oct 2003 02:25:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E76D2536D8; Wed, 8 Oct 2003 02:25:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B6A04536D8 for ; Wed, 8 Oct 2003 02:22:25 -0400 (EDT) Received: (qmail 76233 invoked by uid 3269); 8 Oct 2003 06:22:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76227 invoked from network); 8 Oct 2003 06:22:25 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 8 Oct 2003 06:22:25 -0000 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h986MMh13016; Wed, 8 Oct 2003 08:22:23 +0200 (MEST) Received: from mars.cert.siemens.de (ust.mchp.siemens.de [139.23.201.17]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h986MKT24474; Wed, 8 Oct 2003 08:22:20 +0200 (MEST) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mars.cert.siemens.de (8.12.10/8.12.10/$SiemensCERT: mail/cert.mc,v 1.50 2003/10/07 11:00:28 ust Exp $) with ESMTP id h986LxQ4078065; Wed, 8 Oct 2003 08:22:08 +0200 (CEST) Received: from mhpaba5c (mhpaba5c [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id h986LuEk014298; Wed, 8 Oct 2003 08:21:56 +0200 (MEST) From: "Steffen Fries" Organization: Siemens AG To: Hugh Harney , Mark Baugher MIME-Version: 1.0 Subject: Re: [MSEC] DHHMAC draft Reply-To: steffen.fries@siemens.com Cc: canetti , msec@securemulticast.org Message-ID: <3F83C920.833.4639C64@localhost> Priority: normal In-reply-to: <6.0.0.22.2.20031007174214.0349f118@mira-sjc5-6.cisco.com> References: <70DE7280-F90F-11D7-99D5-000A956E63C6@sparta.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 08 Oct 2003 08:21:52 +0200 Content-Transfer-Encoding: 7BIT Mark, Hugh, yes, it may be used as a registration protocol for group security purposes. In IP telephony environemnts it may appropriate for group based communication using a centralized entity providing the group based key to all communicating entities. Here, the approach the DHHMAC draft discusses, provides for a secure registration at the group controller. Regards Steffen To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] DHHMAC draft Copies to: canetti , msec@securemulticast.org Date sent: Tue, 07 Oct 2003 17:43:33 -0700 > Hugh, > > At 02:44 PM 10/7/2003, Hugh Harney wrote: > >Mark, > > > >Yes it is a registration protocol. > > > >It's very narrowly focused to a specific architecture. > > I understand. It can go either way whether IP telephony protocols > stay strictly pairwise in their security or employ group-key methods. > So if it seems out of scope for group security, I think this is why. > > Mark > > > >Hugh > > > > > >On Tuesday, Oct 7, 2003, at 17:07 US/Eastern, Mark Baugher wrote: > > > >>Hugh, > >> > >>At 12:52 PM 10/7/2003, Hugh Harney wrote: > >>>Ran, > >>> > >>>With the caveat that was included in the spec. > >>> > >>> Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale > >>> beyond a point-to-point constellation; thus, both MIKEY > >>> Diffie-Hellman protocols do not support group-based keying for > >>> any group size larger than two entities. > >>> > >>>Very little can be said about this draft from the perspective of > >>>group security. > >> > >>It's appropriate to a registration protocol for group security. > >> > >>Mark > >> > >> > >>>Hugh > >>> > >>>I just worry that people will automatically > >>>On Tuesday, Oct 7, 2003, at 12:20 US/Eastern, canetti wrote: > >>> > >>>> > >>>>Folks, > >>>> > >>>>The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has > >>>>recently completed its last call with no remarks. Infact, there > >>>>seemed to have been little discussion on this draft on the list. > >>>>In light of this, we'd like to poll the WG on whether there is > >>>>interest in advancing this draft to proposed standard, along with > >>>>MIKEY. Please speak your mind. > >>>> > >>>>Best, > >>>> > >>>>Thomas and Ran > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>msec mailing list > >>>>msec@securemulticast.org > >>>>http://www.pairlist.net/mailman/listinfo/msec > >>>Hugh Harney > >>>Sparta, Inc. > >>>hh@sparta.com 7075 Samuel > >>>Morse Drive > >>>(410) 872-1515 x203 Columbia, MD, > >>>21046 > >>> > >>> > >>>_______________________________________________ > >>>msec mailing list > >>>msec@securemulticast.org > >>>http://www.pairlist.net/mailman/listinfo/msec > >> > >> > >> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://www.pairlist.net/mailman/listinfo/msec > >> > >Hugh Harney Sparta, Inc. > >hh@sparta.com 7075 Samuel Morse > >Drive (410) 872-1515 x203 Columbia, > >MD, 21046 > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 8 09:42:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14670 for ; Wed, 8 Oct 2003 09:42:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 32DDF5372E; Wed, 8 Oct 2003 09:42:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1C1325360C for ; Wed, 8 Oct 2003 09:40:30 -0400 (EDT) Received: (qmail 59633 invoked by uid 3269); 8 Oct 2003 13:40:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59630 invoked from network); 8 Oct 2003 13:40:29 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 8 Oct 2003 13:40:29 -0000 Received: from ambrosius.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h98DePZ6011559; Wed, 8 Oct 2003 08:40:25 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by ambrosius.sparta.com (8.12.8/8.12.8) with ESMTP id h98DeNU3022482; Wed, 8 Oct 2003 08:40:24 -0500 Received: from sparta.com (dhcp-17.columbia.sparta.com [157.185.80.17]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA21726; Wed, 8 Oct 2003 09:40:22 -0400 (EDT) Subject: Re: [MSEC] DHHMAC draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Mark Baugher , canetti , msec@securemulticast.org To: steffen.fries@siemens.com From: Hugh Harney In-Reply-To: <3F83C920.833.4639C64@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 8 Oct 2003 09:40:21 -0400 Content-Transfer-Encoding: 7bit Steffen, I agree with you on the registration at the group controller. My point was that you only have a single controller AND that controller knows a lot about the group members AND the GMs have pre-stored knowledge of the GC. Your architecture and assumptions about pre-existing knowledge between the GC and the GM greatly simplifies the process of setting up a secure cryptographic group. For example, your architecture makes sure that the GMs know that the GC is authorized to download key for this group. This is a fair assumption, if you have a common server based architecture in mind. However, things get trickier if the GMs don't know which server to go to. Or if the GMs don't have pre-stored knowledge of the GC and trust it to download key. Also, the GMs trust the GC to make the appropriate access control decision for their data. The GMs in your architecture don't have to verify the access control rules to make sure that they are appropriate for data the GM is protecting. This is to say that the GMs pretty much blindly trust the GC to make the right decision for them. Hugh On Wednesday, Oct 8, 2003, at 02:21 US/Eastern, Steffen Fries wrote: > Mark, Hugh, > > yes, it may be used as a registration protocol for group > security purposes. > > In IP telephony environemnts it may appropriate for group based > communication using a centralized entity providing the group > based key to all communicating entities. Here, the approach the > DHHMAC draft discusses, provides for a secure registration at > the group controller. > > Regards > Steffen > > To: Hugh Harney > From: Mark Baugher > Subject: Re: [MSEC] DHHMAC draft > Copies to: canetti , > msec@securemulticast.org > Date sent: Tue, 07 Oct 2003 17:43:33 -0700 > >> Hugh, >> >> At 02:44 PM 10/7/2003, Hugh Harney wrote: >>> Mark, >>> >>> Yes it is a registration protocol. >>> >>> It's very narrowly focused to a specific architecture. >> >> I understand. It can go either way whether IP telephony protocols >> stay strictly pairwise in their security or employ group-key methods. >> So if it seems out of scope for group security, I think this is why. >> >> Mark >> >> >>> Hugh >>> >>> >>> On Tuesday, Oct 7, 2003, at 17:07 US/Eastern, Mark Baugher wrote: >>> >>>> Hugh, >>>> >>>> At 12:52 PM 10/7/2003, Hugh Harney wrote: >>>>> Ran, >>>>> >>>>> With the caveat that was included in the spec. >>>>> >>>>> Like the MIKEY Diffie-Hellman protocol, DHHMAC does not scale >>>>> beyond a point-to-point constellation; thus, both MIKEY >>>>> Diffie-Hellman protocols do not support group-based keying for >>>>> any group size larger than two entities. >>>>> >>>>> Very little can be said about this draft from the perspective of >>>>> group security. >>>> >>>> It's appropriate to a registration protocol for group security. >>>> >>>> Mark >>>> >>>> >>>>> Hugh >>>>> >>>>> I just worry that people will automatically >>>>> On Tuesday, Oct 7, 2003, at 12:20 US/Eastern, canetti wrote: >>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> The DHHMAC draft (draft-ietf-msec-mikey-dhhmac-03.txt) has >>>>>> recently completed its last call with no remarks. Infact, there >>>>>> seemed to have been little discussion on this draft on the list. >>>>>> In light of this, we'd like to poll the WG on whether there is >>>>>> interest in advancing this draft to proposed standard, along with >>>>>> MIKEY. Please speak your mind. >>>>>> >>>>>> Best, >>>>>> >>>>>> Thomas and Ran >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> msec mailing list >>>>>> msec@securemulticast.org >>>>>> http://www.pairlist.net/mailman/listinfo/msec >>>>> Hugh Harney >>>>> Sparta, Inc. >>>>> hh@sparta.com 7075 Samuel >>>>> Morse Drive >>>>> (410) 872-1515 x203 Columbia, MD, >>>>> 21046 >>>>> >>>>> >>>>> _______________________________________________ >>>>> msec mailing list >>>>> msec@securemulticast.org >>>>> http://www.pairlist.net/mailman/listinfo/msec >>>> >>>> >>>> >>>> _______________________________________________ >>>> msec mailing list >>>> msec@securemulticast.org >>>> http://www.pairlist.net/mailman/listinfo/msec >>>> >>> Hugh Harney Sparta, Inc. >>> hh@sparta.com 7075 Samuel Morse >>> Drive (410) 872-1515 x203 Columbia, >>> MD, 21046 >>> >>> >>> _______________________________________________ >>> msec mailing list >>> msec@securemulticast.org >>> http://www.pairlist.net/mailman/listinfo/msec >> >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec >> > > > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 8 15:01:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02934 for ; Wed, 8 Oct 2003 15:01:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6F30053871; Wed, 8 Oct 2003 14:58:45 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1435F539BB for ; Wed, 8 Oct 2003 14:57:05 -0400 (EDT) Received: (qmail 17530 invoked by uid 3269); 8 Oct 2003 18:57:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17527 invoked from network); 8 Oct 2003 18:57:05 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 8 Oct 2003 18:57:05 -0000 Received: (qmail 9237 invoked by uid 1000); 8 Oct 2003 18:57:04 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.108923 secs); 08 Oct 2003 18:57:04 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 8 Oct 2003 18:57:04 -0000 Received: (qmail 77415 invoked from network); 8 Oct 2003 18:56:59 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.187) by smtp-auth.nac.net with SMTP; 8 Oct 2003 18:56:59 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h98GhcT06627; Wed, 8 Oct 2003 12:43:38 -0400 From: George Gross To: In-Reply-To: <5.2.1.1.2.20031002212235.00b03e00@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] msec-gkmarch-06.txt: GCKS implosion, scalability Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 8 Oct 2003 12:43:38 -0400 (EDT) Hi, I've taken a look see at this draft, it is in very good shape, kudos to the co-authors for their hard work ;o) a few minor Qs/comments: 1. Section 5.5 discusses various techniques to deal with implosion. As noted on page 19 in section 5.3, the group member could open a conventional unsecured TCP connection to the GCKS to resync with the GCKS. Why not talk to a peer group member instead? this side steps the implosion issue by distributing the resync requests across the group. the rekey message sent by the local recovery peer would still be encrypted/source authenticated in the same form as the peer had received it from the GCKS. the local peer's address could be a parameter downloaded at registration time (or some other mechanism). 2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not clear from the text here why this extra identifier was needed in addition to the SPI? 3. section 7.0 last paragraph asserts that scalability using delegated GCKS is an area that needs "...more analysis and work to be done on the protocol...". That may be true, however, it is my understanding that GSAKMP already specifies such a solution through its policy token role authorization rules. Perhaps this section could mention as an example that GSAKMP uses the policy token within the rekey message to facilitate delegate GCKS scalability. all and all, a good read, and largely ready to go forward to RFC... br, George On Thu, 2 Oct 2003, Thomas Hardjono wrote: > > Folks, > > Now that the GKM-Arch draft has been revised (currently version-06), I'd > like to set a new closing date of 17 October (Friday) for WG Last Call. > > Please review the draft and post issues/questions to the list a.s.a.p. > > thomas > ------ > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 8 21:35:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18395 for ; Wed, 8 Oct 2003 21:35:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EB05A53760; Wed, 8 Oct 2003 21:35:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8568E53664 for ; Wed, 8 Oct 2003 21:32:03 -0400 (EDT) Received: (qmail 99524 invoked by uid 3269); 9 Oct 2003 01:32:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99521 invoked from network); 9 Oct 2003 01:32:02 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 9 Oct 2003 01:32:02 -0000 Received: (qmail 73150 invoked by uid 1000); 9 Oct 2003 01:32:02 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.026308 secs); 09 Oct 2003 01:32:02 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 9 Oct 2003 01:32:01 -0000 Received: (qmail 25149 invoked from network); 9 Oct 2003 01:31:55 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.163) by smtp-auth.nac.net with SMTP; 9 Oct 2003 01:31:55 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h98NIW207105; Wed, 8 Oct 2003 19:18:32 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GKM arch editorial comments... Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 8 Oct 2003 19:18:32 -0400 (EDT) Hi, in follow up to my prior e-mail, this one is just editorial nits... 1. figure 2 may be easier to understand if there was a way to distinquish between protocol communication and internal API primitives. I would expect that the SAD/SPD/cred interactions would be an API primitive, not a protocol. 2. section 5.1, first use of the acronym GKMA is not defined 3. section 6.1, the sentence on page 24 that says: "information is externally managed." was confusing. Externally managed by whom/what component? would this be a group policy server? or the group owner? or its administrator? 4. section 6.3.3 caption has a typo 5. reference JKKV94 has the title listed twice... br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Oct 9 10:06:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20620 for ; Thu, 9 Oct 2003 10:06:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B46DC53840; Thu, 9 Oct 2003 10:04:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7BC485369F for ; Thu, 9 Oct 2003 10:02:30 -0400 (EDT) Received: (qmail 55998 invoked by uid 3269); 9 Oct 2003 14:02:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55994 invoked from network); 9 Oct 2003 14:02:30 -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; 9 Oct 2003 14:02:30 -0000 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 07:03:28 -0700 Received: from cscoamera13263.cisco.com (rtp-vpn2-3.cisco.com [10.82.240.3]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h99E2Q5h023302; Thu, 9 Oct 2003 10:02:26 -0400 (EDT) Message-Id: <6.0.0.22.2.20031009064704.0352bff8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: George Gross From: Mark Baugher Subject: Re: [MSEC] GKM arch editorial comments... Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 09 Oct 2003 06:55:08 -0700 thanks, George At 04:18 PM 10/8/2003, George Gross wrote: >Hi, > in follow up to my prior e-mail, this one is just editorial >nits... > >1. figure 2 may be easier to understand if there was a way to distinquish >between protocol communication and internal API primitives. I would expect >that the SAD/SPD/cred interactions would be an API primitive, not a >protocol. That should be easy to do for the msec gkm protocol: We could make the arrow ==> instead of --> but in general, there is no necessary distinction between an API implemented on top of some RPC and the box-to-box protocols that are the subject of the I-D. But a lot of what's in that diagram is supportive of msec gkm and incidental to it. We should point that out in the diagram. >2. section 5.1, first use of the acronym GKMA is not defined I believe it is in section 5.0. >3. section 6.1, the sentence on page 24 that says: "information is >externally managed." was confusing. Externally managed by whom/what >component? would this be a group policy server? or the group owner? or its >administrator? how about "externally management by a security-policy management function that is outside the scope of this document" or something like that? >4. section 6.3.3 caption has a typo Somebody's been subjected to too much spam :!) >5. reference JKKV94 has the title listed twice... thanks, Mark >br, > George > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Oct 9 10:41:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22861 for ; Thu, 9 Oct 2003 10:41:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4F25A53635; Thu, 9 Oct 2003 10:40:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6C65553838 for ; Thu, 9 Oct 2003 10:39:25 -0400 (EDT) Received: (qmail 63132 invoked by uid 3269); 9 Oct 2003 14:39:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63129 invoked from network); 9 Oct 2003 14:39:25 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 9 Oct 2003 14:39:25 -0000 Received: (qmail 72679 invoked by uid 1000); 9 Oct 2003 14:39:24 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.059502 secs); 09 Oct 2003 14:39:24 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 9 Oct 2003 14:39:24 -0000 Received: (qmail 80270 invoked from network); 9 Oct 2003 14:39:21 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.190) by smtp-auth.nac.net with SMTP; 9 Oct 2003 14:39:21 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h99CPqm07885; Thu, 9 Oct 2003 08:25:52 -0400 From: George Gross To: Mark Baugher Cc: George Gross , Subject: Re: [MSEC] GKM arch editorial comments... In-Reply-To: <6.0.0.22.2.20031009064704.0352bff8@mira-sjc5-6.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 9 Oct 2003 08:25:52 -0400 (EDT) Hi, On Thu, 9 Oct 2003, Mark Baugher wrote: > thanks, George > At 04:18 PM 10/8/2003, George Gross wrote: > >Hi, > > in follow up to my prior e-mail, this one is just editorial > >nits... > > > >1. figure 2 may be easier to understand if there was a way to distinquish > >between protocol communication and internal API primitives. I would expect > >that the SAD/SPD/cred interactions would be an API primitive, not a > >protocol. > > That should be easy to do for the msec gkm protocol: We could make the > arrow ==> instead of --> but in general, there is no necessary distinction > between an API implemented on top of some RPC and the box-to-box protocols > that are the subject of the I-D. But a lot of what's in that diagram is > supportive of msec gkm and incidental to it. We should point that out in > the diagram. ok > > > >2. section 5.1, first use of the acronym GKMA is not defined > > I believe it is in section 5.0. got it, I missed that on first read. > > > >3. section 6.1, the sentence on page 24 that says: "information is > >externally managed." was confusing. Externally managed by whom/what > >component? would this be a group policy server? or the group owner? or its > >administrator? > > how about "externally management by a security-policy management function > that is outside the scope of this document" or something like that? close. Or how about: "...configured by a security policy manager. The security policy manager's design and its interface to the policy repository is outside the scope of this architecture." BTW, I noticed a preceeding sentence: "Thus group security policy will be represented in a policy repository and accessible using a policy protocol." which seems to preclude multicasting the policy token in a message (e.g. GSAKMP), which is not what I think you intended to say, right? How about adding: "Alternatively, the group security policy also can be multicast distributed from a group policy server to the group's candidate membership in a source authenticated message." > > > >4. section 6.3.3 caption has a typo > > Somebody's been subjected to too much spam :!) > > > >5. reference JKKV94 has the title listed twice... > > thanks, Mark > > > >br, > > George > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Oct 9 11:41:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24908 for ; Thu, 9 Oct 2003 11:41:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AA19253986; Thu, 9 Oct 2003 11:41:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 729B3536DA for ; Thu, 9 Oct 2003 11:39:05 -0400 (EDT) Received: (qmail 75390 invoked by uid 3269); 9 Oct 2003 15:39:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75387 invoked from network); 9 Oct 2003 15:39:05 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 9 Oct 2003 15:39:05 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h99Fcj322005; Thu, 9 Oct 2003 11:38:46 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZWAP282; Thu, 9 Oct 2003 11:38:45 -0400 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TRQTB2C2; Thu, 9 Oct 2003 11:38:44 -0400 Message-ID: <3F858104.3070906@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Cc: George Gross , msec@securemulticast.org Subject: Re: [MSEC] GKM arch editorial comments... References: <6.0.0.22.2.20031009064704.0352bff8@mira-sjc5-6.cisco.com> In-Reply-To: <6.0.0.22.2.20031009064704.0352bff8@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 09 Oct 2003 11:38:44 -0400 Content-Transfer-Encoding: 7bit Thanks for the review, George. 6.3.3.'s title is what I got when I married protection and encryption :-)! More later, Lakshminath Mark Baugher wrote: > thanks, George > At 04:18 PM 10/8/2003, George Gross wrote: > >> Hi, >> in follow up to my prior e-mail, this one is just editorial >> nits... >> >> 1. figure 2 may be easier to understand if there was a way to >> distinquish >> between protocol communication and internal API primitives. I would >> expect >> that the SAD/SPD/cred interactions would be an API primitive, not a >> protocol. > > > That should be easy to do for the msec gkm protocol: We could make > the arrow ==> instead of --> but in general, there is no necessary > distinction between an API implemented on top of some RPC and the > box-to-box protocols that are the subject of the I-D. But a lot of > what's in that diagram is supportive of msec gkm and incidental to > it. We should point that out in the diagram. > > >> 2. section 5.1, first use of the acronym GKMA is not defined > > > I believe it is in section 5.0. > > >> 3. section 6.1, the sentence on page 24 that says: "information is >> externally managed." was confusing. Externally managed by whom/what >> component? would this be a group policy server? or the group owner? >> or its >> administrator? > > > how about "externally management by a security-policy management > function that is outside the scope of this document" or something like > that? > > >> 4. section 6.3.3 caption has a typo > > > Somebody's been subjected to too much spam :!) > > >> 5. reference JKKV94 has the title listed twice... > > > thanks, Mark > > >> br, >> George >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Oct 9 13:44:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01092 for ; Thu, 9 Oct 2003 13:44:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DD439539DC; Thu, 9 Oct 2003 13:40:20 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C71065386A for ; Thu, 9 Oct 2003 13:38:48 -0400 (EDT) Received: (qmail 98703 invoked by uid 3269); 9 Oct 2003 17:38:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98698 invoked from network); 9 Oct 2003 17:38:48 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 9 Oct 2003 17:38:48 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h99Hca914263; Thu, 9 Oct 2003 10:38:36 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S5BD6ZKH; Thu, 9 Oct 2003 10:38:36 -0700 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TRQTB2HL; Thu, 9 Oct 2003 13:38:34 -0400 Message-ID: <3F859D19.9030506@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Cc: msec@securemulticast.org Subject: Re: [MSEC] msec-gkmarch-06.txt: GCKS implosion, scalability References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 09 Oct 2003 13:38:33 -0400 Content-Transfer-Encoding: 7bit Comments inline: George Gross wrote: >Hi, > > I've taken a look see at this draft, it is in very good shape, >kudos to the co-authors for their hard work ;o) > >a few minor Qs/comments: > >1. Section 5.5 discusses various techniques to deal with implosion. As >noted on page 19 in section 5.3, the group member could open a >conventional unsecured TCP connection to the GCKS to resync with the GCKS. >Why not talk to a peer group member instead? this side steps the >implosion issue by distributing the resync requests across the group. the >rekey message sent by the local recovery peer would still be >encrypted/source authenticated in the same form as the peer had received >it from the GCKS. the local peer's address could be a parameter downloaded >at registration time (or some other mechanism). > Let us discuss and write about distributed operation of GCKS services once the centralized architecture is complete. Replay protection may become tricky in case of member retransmissions. You know "local recovery" brings old RMRG/RMT discussions to memory! >2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not >clear from the text here why this extra identifier was needed in >addition to the SPI? > The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec. >3. section 7.0 last paragraph asserts that scalability using delegated >GCKS is an area that needs "...more analysis and work to be done on the >protocol...". That may be true, however, it is my understanding that >GSAKMP already specifies such a solution through its policy token role >authorization rules. Perhaps this section could mention as an example that >GSAKMP uses the policy token within the rekey message to facilitate >delegate GCKS scalability. > We will make a reference to GSAKMP here (I made a note to self on that after I submitted the I-D)! thanks again, Lakshminath >all and all, a good read, and largely ready to go forward to RFC... > >br, > George > >On Thu, 2 Oct 2003, Thomas Hardjono wrote: > > > >>Folks, >> >>Now that the GKM-Arch draft has been revised (currently version-06), I'd >>like to set a new closing date of 17 October (Friday) for WG Last Call. >> >>Please review the draft and post issues/questions to the list a.s.a.p. >> >>thomas >>------ >> >> >> >> >> >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> >> >> > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 15 05:58:28 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22834 for ; Wed, 15 Oct 2003 05:58:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 280F053888; Wed, 15 Oct 2003 05:58:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B3FB053690 for ; Wed, 15 Oct 2003 05:56:44 -0400 (EDT) Received: (qmail 45949 invoked by uid 3269); 15 Oct 2003 09:56:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45943 invoked from network); 15 Oct 2003 09:56:44 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by klesh.pair.com with SMTP; 15 Oct 2003 09:56:44 -0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9F9ugd08786 for ; Wed, 15 Oct 2003 12:56:43 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 12:56:42 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:56:41 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:56:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2BF0AD29BC31FE46B788773211440431038165E6@trebe003.europe.nokia.com> Thread-Topic: Multicast Session/Service/etc discovery & announcement Thread-Index: AcOS9gsoVA8cELvBTy+SKp1fLS1jzg== From: To: , , , , Cc: X-OriginalArrivalTime: 15 Oct 2003 09:56:39.0866 (UTC) FILETIME=[A11B89A0:01C39302] Subject: [MSEC] Multicast Session/Service/etc discovery & announcement Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 15 Oct 2003 12:56:38 +0300 Content-Transfer-Encoding: quoted-printable Does our current effort to summarize multicast service discovery = requirements in MMUSIC meet your needs? Internet Media Guide requirements: = http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt Clearly, exchanging/announcing session/etc parameters effects joining = (SSM and ASM), involves security risks and enable multicast content = services - like streaming media and file delivery. So any comments, = criticisms, ideas and beers are welcome. (Speaking of service = announcements, does Minneapolis offer the same excellent range of Ales = as San Francisco?) Cheers, Rod. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 15 17:57:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25636 for ; Wed, 15 Oct 2003 17:57:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C66565377F; Wed, 15 Oct 2003 17:56:59 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id AA8D1536E3 for ; Wed, 15 Oct 2003 17:55:17 -0400 (EDT) Received: (qmail 76537 invoked by uid 3269); 15 Oct 2003 21:55:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76534 invoked from network); 15 Oct 2003 21:55:17 -0000 Received: from sj-iport-5.cisco.com (171.68.10.87) by klesh.pair.com with SMTP; 15 Oct 2003 21:55:17 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 15 Oct 2003 14:55:45 -0700 Received: from cisco.com ([128.107.177.199]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9FLtESw009824; Wed, 15 Oct 2003 14:55:14 -0700 (PDT) Message-ID: <3F8DC241.C8EC0BE9@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: George Gross , msec@securemulticast.org Subject: Re: [MSEC] msec-gkmarch-06.txt: GCKS implosion, scalability References: <3F859D19.9030506@americasm06.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 15 Oct 2003 14:55:13 -0700 Content-Transfer-Encoding: 7bit Hi Lakshminath, Lakshminath Dondeti wrote: > > Comments inline: > > George Gross wrote: [snip] > >2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not > >clear from the text here why this extra identifier was needed in > >addition to the SPI? > > > The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec. I'm still confused ... why would we need a protocol id to identify a rekey message? I can see where a group identifier (as defined in Section 6.3.1) could be useful to uniquely identifier a rekey message as being part of a specific group, but not why the rekey message would need its own protocol type? In GDOI, a receiver of a rekey message recognizes a rekey message matching {protocol, src addr/port, dst addr/port, SPI}. Strictly speaking, there is neither a group identifier nor a rekey identifier. I can see where adding a group identifier might be useful in the rare case that two GDOI groups used the same network layer address, and also chose the same SPIs. But how would a rekey identifier help? Thanks, Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 15 18:35:59 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28130 for ; Wed, 15 Oct 2003 18:35:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CF763536BB; Wed, 15 Oct 2003 18:35:32 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E85EF536FA for ; Wed, 15 Oct 2003 18:32:27 -0400 (EDT) Received: (qmail 84461 invoked by uid 3269); 15 Oct 2003 22:32:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84458 invoked from network); 15 Oct 2003 22:32:27 -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; 15 Oct 2003 22:32:27 -0000 Received: from cisco.com ([128.107.177.199]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9FMWPSw013184 for ; Wed, 15 Oct 2003 15:32:25 -0700 (PDT) Message-ID: <3F8DCAF8.5314767F@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] GKM Comments Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 15 Oct 2003 15:32:24 -0700 Content-Transfer-Encoding: 7bit Draft draft-ietf-msec-gkmarch-06.txt looks good to me! I have just a few minor comments: 1. Use of "MSEC". In the Abstract and Section 1.0 you define MSEC as "multicast security" rather than referring to the MSEC WG. I think that's a good idea, since the MSEC WG will be gone someday whereas Informational RFCs last forever! But there are other references to "MSEC" in the document which seem to imply the WG. E.g., 4th paragraph in section 1.0 talks about "MSEC literature". I'd suggest omitting or rewording those. 2. Appendix 1. This is related to comment 1. Do you really want the document to list the the MSEC WG roadmap in perpetuity? 3. Section 5.1. This listing of rekey protocol goals is nice, but I couldn't help wondering why there wasn't a similar list of goals for the registration protocol? Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Oct 16 13:12:46 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11459 for ; Thu, 16 Oct 2003 13:12:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E201253795; Thu, 16 Oct 2003 13:12:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DC81B535A6 for ; Thu, 16 Oct 2003 13:10:25 -0400 (EDT) Received: (qmail 29004 invoked by uid 3269); 16 Oct 2003 17:10:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29001 invoked from network); 16 Oct 2003 17:10:25 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 16 Oct 2003 17:10:25 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9GHABj02409; Thu, 16 Oct 2003 13:10:12 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZWAQ3J6; Thu, 16 Oct 2003 13:10:10 -0400 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TRQTBNXB; Thu, 16 Oct 2003 13:10:11 -0400 Message-ID: <3F8ED0F1.8050902@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Weis Cc: msec@securemulticast.org Subject: Re: [MSEC] GKM Comments References: <3F8DCAF8.5314767F@cisco.com> In-Reply-To: <3F8DCAF8.5314767F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 16 Oct 2003 13:10:09 -0400 Content-Transfer-Encoding: 7bit Brian, Many thanks for the review and comments. I will address them in detail in the next few days. After that, we will revise and resubmit before the Oct 27th deadline. regards, Lakshminath Brian Weis wrote: >Draft draft-ietf-msec-gkmarch-06.txt looks good to me! I have just a few >minor comments: > >1. Use of "MSEC". In the Abstract and Section 1.0 you define MSEC as >"multicast security" rather than referring to the MSEC WG. I think >that's a good idea, since the MSEC WG will be gone someday whereas >Informational RFCs last forever! But there are other references to >"MSEC" in the document which seem to imply the WG. E.g., 4th paragraph >in section 1.0 talks about "MSEC literature". I'd suggest omitting or >rewording those. > >2. Appendix 1. This is related to comment 1. Do you really want the >document to list the the MSEC WG roadmap in perpetuity? > >3. Section 5.1. This listing of rekey protocol goals is nice, but I >couldn't help wondering why there wasn't a similar list of goals for the >registration protocol? > >Brian > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Oct 20 23:19:08 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20491 for ; Mon, 20 Oct 2003 23:19:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A820753600; Mon, 20 Oct 2003 23:18:34 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 80BBD53544 for ; Mon, 20 Oct 2003 23:14:43 -0400 (EDT) Received: (qmail 10401 invoked by uid 3269); 21 Oct 2003 03:14:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10398 invoked from network); 21 Oct 2003 03:14:41 -0000 Received: from mail0.yrp.nttdocomo.co.jp (202.245.184.18) by klesh.pair.com with SMTP; 21 Oct 2003 03:14:41 -0000 Received: from mml.yrp.nttdocomo.co.jp (mml.yrp.nttdocomo.co.jp [172.21.48.50]) by mail0.yrp.nttdocomo.co.jp (8.12.10/YRPHUB0-8820020412) with ESMTP id h9L3Ee8w006565 for ; Tue, 21 Oct 2003 12:14:40 +0900 (JST) Received: from [172.21.51.159] (hueno-at920c.mml-ad.yrp.nttdocomo.co.jp [172.21.51.159]) by mml.yrp.nttdocomo.co.jp (8.12.6/8.12.6) with ESMTP id h9L3Ed7W017832 for ; Tue, 21 Oct 2003 12:14:39 +0900 (JST) From: Hidetoshi Ueno To: msec@securemulticast.org Message-Id: <20031021121432.5334.UENO@mml.yrp.nttdocomo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 Subject: [MSEC] MESP question Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 21 Oct 2003 12:14:39 +0900 Content-Transfer-Encoding: 7bit Hi all, Let me ask a quick question regarding MESP. Is it possible to use MESP over UDP/IP? or Is it only possible to use MESP for IP layer? Although the SMuG data transform draft (draft-data-transforms.txt) stats that the protocol can be used for network layer transform as well as application layer transform, the MESP draft (draft-ietf-msec-mesp-01.txt) doesn't state that. I would appriciate your any help. Thank you. Hidetoshi Ueno NTT DoCoMo, Inc. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 21 14:54:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00343 for ; Tue, 21 Oct 2003 14:54:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B45805378C; Tue, 21 Oct 2003 14:54:13 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 92D1B5378C for ; Tue, 21 Oct 2003 14:52:22 -0400 (EDT) Received: (qmail 6119 invoked by uid 3269); 21 Oct 2003 18:52:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6116 invoked from network); 21 Oct 2003 18:52:22 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by klesh.pair.com with SMTP; 21 Oct 2003 18:52:22 -0000 Received: from cscoamera13263.cisco.com (rtp-vpn1-459.cisco.com [10.82.225.203]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LIqGFI020577; Tue, 21 Oct 2003 14:52:18 -0400 (EDT) Message-Id: <6.0.0.22.2.20031021114724.03e75e30@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Hidetoshi Ueno From: Mark Baugher Subject: Re: [MSEC] MESP question Cc: msec@securemulticast.org In-Reply-To: <20031021121432.5334.UENO@mml.yrp.nttdocomo.co.jp> References: <20031021121432.5334.UENO@mml.yrp.nttdocomo.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 21 Oct 2003 11:52:15 -0700 Hello, At 08:14 PM 10/20/2003, Hidetoshi Ueno wrote: >Hi all, > >Let me ask a quick question regarding MESP. > >Is it possible to use MESP over UDP/IP? >or >Is it only possible to use MESP for IP layer? We no longer recommend using MESP but instead recommend the current working draft of IPsec ESP since the new IPsec ESP draft incorporates the needed functionality from MESP. This is the result of work that msec had done with ipsec and the security ADs last Spring. >Although the SMuG data transform draft (draft-data-transforms.txt) stats >that the protocol can be used for network layer transform as well as >application layer transform, the MESP draft (draft-ietf-msec-mesp-01.txt) >doesn't state that. The SMuG draft is no longer relevant. I am sorry for the confusion and hopefully we will clean up these drafts shortly after the next IETF meeting. >I would appriciate your any help. I hope this helps. It is good news because we can use one protocol, IPsec ESP, instead of having two. But you need to refer to the current working draft of IPsec ESP (not the RFC) from the IPsec Working Group directory. Best Regards, Mark >Thank you. >Hidetoshi Ueno >NTT DoCoMo, Inc. > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Oct 23 09:19:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17669 for ; Thu, 23 Oct 2003 09:19:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3CCFB53944; Thu, 23 Oct 2003 09:18:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C2FDE53944 for ; Thu, 23 Oct 2003 09:17:37 -0400 (EDT) Received: (qmail 27449 invoked by uid 3269); 23 Oct 2003 13:17:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27443 invoked from network); 23 Oct 2003 13:17:37 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 23 Oct 2003 13:17:37 -0000 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9NDHWoq014383 for ; Thu, 23 Oct 2003 15:17:36 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <45JSZ49Q>; Thu, 23 Oct 2003 15:18:33 +0200 Message-ID: <1F55F6582266314A85A55F6241509B67078E5555@Esealnt863.al.sw.ericsson.se> From: "Karl Norrman (KI/EAB)" To: "'msec@securemulticast.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: More IESG Comments on draft-ietf-msec-mikey-07 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 23 Oct 2003 15:14:42 +0200 Dear all, Here is our reply to the comments on "MIKEY" received so far. We appreciate the reviewers input, it will certainly improve the spec. = = = = = = = Comments from Steve Bellovin. = = = = = = = 4.1.3 says "let n = inkey_len / 512, rounded up to the nearest integer". Is it rounded up, or to the nearest integer? If the division yields an integral result, is it bumped by 1? The same comment applies to m. [Reply:] We will clarify (that rounding up is done only when the quantities are not already integers). Explain what relevance 512 has to SHA1, which externally takes messages of any size. Are you referring to SHA1 internals? What should be used [Reply:] Considering the change suggested below, it should no longer be an issue, but we will clarify anyhow (refering to the "block size" and "message digest size" as used in the FIPS). for hash functions that don't have SHA1's internal 512-bit structure? I suggest that you require than any new PRF be defined by its own RFC, rather than trying to give guidance here. [Reply:] We agree. Not becuase there would be any problem in specifying the parameters in a clear way, but rather becuase the PRF is based on a HMAC construction using said hash, not on the hash directly. Therefore, Although HMAC_SHAx (x = 256, 384, 512) could easily be specified refering to RFC2104 and FIPS 180-2, it would probably be "safer" to refer to an equivavlent of RFC2404 (but for SHA2), so since no such RFC exists, we will remove the option, unless we hear strong objection from the IETF community. 4.2.2: what parameters corresponding to 512 and 160 should be used for SHA-256, -384, or -512? [Reply:] Again, this could be easily defined (refering to FIPS 180-2) but we will do as you suggested above. 4.2.9: what process (per rfc 2434) is needed for new parameter registration? How does this relate to Section 10? [Reply:] Per RFC 2434, the following registration process should be used (from Sect 10, paragraph 2): "...values in the range 0-240 for each name space should be approved by the process of IETF consensus and values in the range 241-255 are reserved for Private Use." A reference to 2434 seem to be lacking (so this will of course be added). 5.4 suggests dropping messages from attacking peers. Of course, until the message is authenticated you don't know whom it's from, which still leaves the door open to a CPU DoS attack. [Reply:] "Dropping" is intended to be based on source address filtering, in which case there is no point in trying to authenticate messages from "banned" peers. Of course, this might mean that an attacker who can spoof IP addresses could "block" a legitimate user, causing other DoS effect. As you say, it would therefore be more robust to actually do the authentication. In the symmetric key case, it might indeed be feasible to really authenticate the source cryptographically up to quite high traffic rates, but there is of course always a limit above which we would need to resort to more opportunistic ways... We should probably expand the text and elaborate on pros and cons of these approaches. 5.5: what is done to avoid congestion? [Reply:] We agree this section is perhaps too simplistic, and we would consider dropping the section if it had not been for the fact that we have some indication people want to run MIKEY over e.g. UDP. Rather than giving a wrong impression on what adequate reliability means, we propose the whole section is replaced by: "MIKEY assumes reliable transport. If an unreliable transport protocol, e.g., UDP, is used, a reliability mechanism MUST be added (see for instance [Stevens]) Reference: [Stevens] R. Stevens: UNIX network programming: Networking APIs: Sockets and XTI, Prentice Hall, 1998 (Section 20.5)" 6.11 Cite RFC 1750? (Also cite it when discussing DH exponents.) [Reply:] Thanks, will do so. (Perhaps also in the beginning of the doc size random/pseudo random is used here and there.) = = = = = = = Comments from Ted Hardie. = = = = = = = This is a weak DISCUSS, and I could be pretty easily persuaded to drop it. Essentially, I'm concerned about section 5.4, which describes the replay protection mechanisms. The language in the draft is a bit hard to parse in places, and there seem to be some assumptions that we may not be able to meet. In particular, it cites as an assumption: "* If the clocks are to be synchronized over the network, a secure network clock synchronization protocol is used." [Reply:] First, since MIKEY's intention is not to specify a security solution of any specific timestamping protocol, "...is used." should be replaced by "...SHOULD be used." Is there a solution available for this? NTP v3 is cited in the references (not in this paragraph), but I don't think that quite fits this bill, and the STIME work doesn't seem to be done. The Security Considerations Section (9.3) does discuss this briefly, but basically points back to 5.4 and hints that practical experience with other protocols indicates that manual configuration may be okay. [Reply:] There are indeed standardized secure time stamping protocols, and we should probably expand the list of references. What comes into mind directly are the protocols of the ISO/IEC 18014 series. This language also seemed strange: In a client-server scenario, servers may be the entities that will have the highest workload. It is therefore RECOMMENDED that the servers are the Initiators of MIKEY. This will result in that the servers will not need to manage any significant replay cache as they will refuse all incoming messages that are not a response to an already (by the server) sent message. as it seems to imply that the initiation should follow a particular pattern, regardless of the pattern of the underlying protocol. In other words, it sounds like it is recommending that clients wishing to initiate should instead tell the server to initiate, then respond, so that the server replay cache would not have to be large. This wasn't entirely clear, though, and some tightened language might help. [Reply:] We agree the formulation is unclear. It could indeed be impractical in some cases to arrange so that the server initiates. We will imporve the wording. In general, an editing pass through this section by a native speaker might be a good idea. [Reply:] Agreed. /Mikey authors >-----Original Message----- >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: den 21 oktober 2003 00:01 >To: thardjono@verisign.com; canetti@watson.ibm.com; Jari >Arkko (JO/LMF); >Elisabetta Carrara (KI/EAB); Fredrik Lindholm (KI/EAB); Mats Näslund >(KI/EAB); Karl Norrman (KI/EAB) >Subject: More IESG Comments on draft-ietf-msec-mikey-07 > > >Here are some comments from Ted Hardie. Comments may be >coming from other >Area Directors, but I thought I would pass these along so you >could get >started. > >Also, there are non-ASCII characters in the document. > >The document is on the agenda for 30 October. It would be >nice if the >comments that I sent last week and these comment can be >reviewed before the >meeting. If there are straightforward responses, I need to know them. > >Russ > >= = = = = = = > >This is a weak DISCUSS, and I could be pretty easily >persuaded to drop it. >Essentially, I'm concerned about section 5.4, which describes >the replay >protection mechanisms. The language in the draft is a bit >hard to parse >in places, and there seem to be some assumptions >that we may not be able to meet. In particular, it cites as >an assumption: > >"* If the clocks are to be synchronized over the network, a secure > network clock synchronization protocol is used." > >Is there a solution available for this? NTP v3 is cited in >the references >(not in this paragraph), >but I don't think that quite fits this bill, and the STIME >work doesn't >seem to be done. > >The Security Considerations Section (9.3) does discuss this >briefly, but >basically points back >to 5.4 and hints that practical experience with other >protocols indicates >that manual configuration >may be okay. > >This language also seemed strange: > > In a client-server scenario, servers may be the entities that will > have the highest workload. It is therefore RECOMMENDED that the > servers are the Initiators of MIKEY. This will result in that the > servers will not need to manage any significant replay >cache as they > will refuse all incoming messages that are not a response to an > already (by the server) sent message. > >as it seems to imply that the initiation should follow a >particular pattern, >regardless of the pattern of the underlying protocol. In other words, >it sounds like it is recommending that clients wishing to >initiate should >instead tell the server to initiate, then respond, so that >the server replay >cache would not have to be large. This wasn't entirely clear, though, >and some tightened language might help. > >In general, an editing pass through this section by a native >speaker might >be a good idea. > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Oct 24 14:31:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21857 for ; Fri, 24 Oct 2003 14:31:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D24E553A45; Fri, 24 Oct 2003 14:31:19 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0661153A3E for ; Fri, 24 Oct 2003 14:28:16 -0400 (EDT) Received: (qmail 80473 invoked by uid 3269); 24 Oct 2003 18:28:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80463 invoked from network); 24 Oct 2003 18:28:15 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 24 Oct 2003 18:28:15 -0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.10/) with ESMTP id h9OISEBi019171; Fri, 24 Oct 2003 11:28:15 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 11:28:14 -0700 Message-ID: From: "Hardjono, Thomas" To: "'msec@securemulticast.org'" Cc: "'canetti@watson.ibm.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [MSEC] MSEC Agenda for IETF-58 Minneapolis as of today Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 24 Oct 2003 11:28:09 -0700 Folks, The next IETF in Minneapolis, MN is only about 3 weeks away. Please email Ran/myself for agenda items. MSEC WG Agenda: --------------- - Review of WG status (T. Hardjono/R. Canetti) - GSAKMP Update (H. Harney/A. Colegrove) - MSEC and AAA/Diameter (G. Gross) - Please email Ran/Thomas for corrections/additions. Note that at the moment MSEC will meet on: MONDAY, November 10, 2003 0900-1130 Morning Sessions Regards Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Oct 27 09:20:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14993 for ; Mon, 27 Oct 2003 09:20:32 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B3DF253603; Mon, 27 Oct 2003 09:20:08 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3B8F4535EE for ; Mon, 27 Oct 2003 09:18:22 -0500 (EST) Received: (qmail 13909 invoked by uid 3269); 27 Oct 2003 14:18:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 13906 invoked from network); 27 Oct 2003 14:18:21 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 27 Oct 2003 14:18:21 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14405; Mon, 27 Oct 2003 09:18:10 -0500 (EST) Message-Id: <200310271418.JAA14405@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-gsakmp-sec-04.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 27 Oct 2003 09:18:10 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : GSAKMP Author(s) : H. Harney Filename : draft-ietf-msec-gsakmp-sec-04.txt Pages : 86 Date : 2003-10-24 This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gsakmp-sec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24160759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gsakmp-sec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24160759.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Oct 27 17:13:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20066 for ; Mon, 27 Oct 2003 17:13:39 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 84CED53561; Mon, 27 Oct 2003 17:12:54 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6658553547 for ; Mon, 27 Oct 2003 17:11:24 -0500 (EST) Received: (qmail 5872 invoked by uid 3269); 27 Oct 2003 22:11:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5695 invoked from network); 27 Oct 2003 22:10:53 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 27 Oct 2003 22:10:53 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19300; Mon, 27 Oct 2003 17:10:28 -0500 (EST) Message-Id: <200310272210.RAA19300@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-gsakmp-sec-04.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 27 Oct 2003 17:10:26 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : GSAKMP Author(s) : H. Harney Filename : draft-ietf-msec-gsakmp-sec-04.txt Pages : 86 Date : 2003-10-24 This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gsakmp-sec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gsakmp-sec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171352.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec