From msec-admin@securemulticast.org Fri Aug 1 00:34:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26224 for ; Fri, 1 Aug 2003 00:34:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BE1F6536B2; Fri, 1 Aug 2003 00:34: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 1863553787 for ; Fri, 1 Aug 2003 00:32:18 -0400 (EDT) Received: (qmail 27748 invoked by uid 3269); 1 Aug 2003 04:32:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27745 invoked from network); 1 Aug 2003 04:32:17 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 1 Aug 2003 04:32:17 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h714WEF9022802; Thu, 31 Jul 2003 21:32:15 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.73 [10.26.128.73]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P09SKV2N; Thu, 31 Jul 2003 21:32:14 -0700 Message-Id: <5.2.1.1.2.20030731211935.022ba730@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com, smb@research.att.com, housley@vigilsec.com, martin.euchner@siemens.com, thardjono@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] WG Last Call for DHHMAC-for-MIKEY (closing date 1 September 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, 31 Jul 2003 21:32:01 -0700 Folks, Now that MIKEY has passed both WG Last Call and IESG Last Call, we need to move-on to do a WG Last Call for the DHHMAC-MIKEY draft. This closing date (1 Sept 2003) is one of the actions items coming out of the Vienna IETF. Please send your comments to the mailing list a.s.a.p. Regards. Thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 1 00:52:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26606 for ; Fri, 1 Aug 2003 00:52:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id ED948537AC; Fri, 1 Aug 2003 00:52: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 276E3537A7 for ; Fri, 1 Aug 2003 00:51:43 -0400 (EDT) Received: (qmail 31529 invoked by uid 3269); 1 Aug 2003 04:51:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 31526 invoked from network); 1 Aug 2003 04:51:43 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 1 Aug 2003 04:51:43 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h714pfF9027670; Thu, 31 Jul 2003 21:51:41 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.147 [10.26.128.147]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P09SKXKH; Thu, 31 Jul 2003 21:51:40 -0700 Message-Id: <5.2.1.1.2.20030731214031.022bf800@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.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 1 September 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, 31 Jul 2003 21:51:28 -0700 Folks, Another action item from the Vienna IETF was the last call for the GKM-Arch document, which has been in discussion for some time now. Therefore, I would like to begin WG Last Call for the GKM-Architecture document, with a closing date of 1 September 2003. Please send your comments to the list a.s.a.p. Thanks. Thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 1 11:24:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26447 for ; Fri, 1 Aug 2003 11:24:46 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C864253669; Fri, 1 Aug 2003 11:24: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 2948D53611 for ; Fri, 1 Aug 2003 11:23:59 -0400 (EDT) Received: (qmail 45838 invoked by uid 3269); 1 Aug 2003 15:23:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45833 invoked from network); 1 Aug 2003 15:23:58 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 1 Aug 2003 15:23:58 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn4-891.cisco.com [10.21.83.122]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h71FNlpq015208; Fri, 1 Aug 2003 08:23:47 -0700 (PDT) Message-Id: <5.1.1.5.2.20030801082250.061ee820@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Thomas Hardjono From: Mark Baugher Subject: Re: [MSEC] WG Last Call for GKM-Architecture draft (closing date 1 September 2003) Cc: msec@securemulticast.org, housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.com, Lakshminath Dondeti , Fredrik.Lindholm@era.ericsson.se In-Reply-To: <5.2.1.1.2.20030731214031.022bf800@pop.mail.yahoo.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: Fri, 01 Aug 2003 08:23:46 -0700 Thomas, This draft is not ready to go to WG Last Call. I am sorry but we need to update it with a section on the question of reliable multicast. Mark At 09:51 PM 7/31/2003 -0700, Thomas Hardjono wrote: >Folks, > >Another action item from the Vienna IETF was the last call for the >GKM-Arch document, which has been in discussion for some time now. > >Therefore, I would like to begin WG Last Call for the GKM-Architecture >document, with a closing date of 1 September 2003. > >Please send your comments to the list a.s.a.p. > > >Thanks. > >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 Fri Aug 1 12:51:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29795 for ; Fri, 1 Aug 2003 12:51:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2455E535FA; Fri, 1 Aug 2003 12:50:58 -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 88F71537F4 for ; Fri, 1 Aug 2003 12:49:36 -0400 (EDT) Received: (qmail 60910 invoked by uid 3269); 1 Aug 2003 16:49:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60905 invoked from network); 1 Aug 2003 16:49:36 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 1 Aug 2003 16:49:36 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h71GnLF9017468; Fri, 1 Aug 2003 09:49:21 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Aug 2003 09:49:21 -0700 Message-ID: <9F4EAC17FAE99D4AB9CB27A54D86AD8B02C2976B@vhqpostal3.verisign.com> From: "Hardjono, Thomas" To: "'Mark Baugher'" , "Hardjono, Thomas" Cc: msec@securemulticast.org, housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.com, Lakshminath Dondeti , Fredrik.Lindholm@era.ericsson.se Subject: RE: [MSEC] WG Last Call for GKM-Architecture draft (closing date 1 September 2003) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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, 1 Aug 2003 09:49:16 -0700 Mark, I'm quite open to providing some more time for the doc. Can the authors give an exact date when the document will be ready for WG Last Call? cheers, thomas ------ > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: Friday, August 01, 2003 8:24 AM > To: Thomas Hardjono > Cc: msec@securemulticast.org; housley@vigilsec.com; > smb@research.att.com; canetti@watson.ibm.com; > thardjono@yahoo.com; Lakshminath Dondeti; > Fredrik.Lindholm@era.ericsson.se > Subject: Re: [MSEC] WG Last Call for GKM-Architecture draft > (closing date 1 September 2003) > > > Thomas, > This draft is not ready to go to WG Last Call. I am sorry > but we need > to update it with a section on the question of reliable multicast. > > Mark > At 09:51 PM 7/31/2003 -0700, Thomas Hardjono wrote: > > >Folks, > > > >Another action item from the Vienna IETF was the last call for the > >GKM-Arch document, which has been in discussion for some time now. > > > >Therefore, I would like to begin WG Last Call for the > GKM-Architecture > >document, with a closing date of 1 September 2003. > > > >Please send your comments to the list a.s.a.p. > > > > > >Thanks. > > > >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 Mon Aug 4 10:16:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28192 for ; Mon, 4 Aug 2003 10:16:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1A70E53603; Mon, 4 Aug 2003 10:16:15 -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 629BB535FA for ; Mon, 4 Aug 2003 10:15:03 -0400 (EDT) Received: (qmail 96470 invoked by uid 3269); 4 Aug 2003 14:15:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96467 invoked from network); 4 Aug 2003 14:15:03 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 4 Aug 2003 14:15:03 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27520; Mon, 4 Aug 2003 10:14:58 -0400 (EDT) Message-Id: <200308041414.KAA27520@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-03.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, 04 Aug 2003 10:14:58 -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 : GSAKMP Author(s) : H. Harney et al. Filename : draft-ietf-msec-gsakmp-sec-03.txt Pages : 53 Date : 2003-8-4 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-03.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-03.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-03.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-8-4094244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gsakmp-sec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-4094244.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 Aug 4 13:50:56 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05420 for ; Mon, 4 Aug 2003 13:50:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3DE7253807; Mon, 4 Aug 2003 13:50:22 -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 1E4CA53805 for ; Mon, 4 Aug 2003 13:49:12 -0400 (EDT) Received: (qmail 36935 invoked by uid 3269); 4 Aug 2003 17:49:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36932 invoked from network); 4 Aug 2003 17:49:10 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 4 Aug 2003 17:49:10 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn3-756.cisco.com [10.21.66.244]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h74Hn5uH015163; Mon, 4 Aug 2003 10:49:05 -0700 (PDT) Message-Id: <5.1.1.5.2.20030731133701.0221d828@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: In-Reply-To: References: <5.1.1.5.2.20030731100154.05e8c318@mira-sjc5-6.cisco.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: Thu, 31 Jul 2003 14:21:44 -0700 George, At 11:58 AM 7/31/2003 -0400, George Gross wrote: <...> > > > > I should take a look at the latest word on this but someone can surely > > > > present to the IETF any invention, system or apparatus for which > they have > > > > previously filed a patent without invalidating the patent in any way. > >These days, no Internet Draft gets published unless it contains the >RFC2026 boilerplate pledging compliance to IETF IPR policy. There is the "posting" of an I-D and the "publication" of an I-D. What you say is true for publication, at which point the I-D becomes some sort of RFC. It is obviously possible to post an I-D without the IPR statement since this was done with the SD I-D two years ago. >The IPR >working group has been refining that policy, and has several drafts out. I >would anticipate that several of them will publish as informational RFC >this year and will become part of the IETF process too. > >So a new SDR draft will have to match those IPR guidelines. > >Wrt/ to Subset Difference Rekeying (SDR) and reliability, I think it is >germane to mention a paper I encountered recently: > >"Adding Reliable and Self-Healing Key Distribution to the Subset >Difference Group Re-keying Method for Secure Multicast" > >by S. Zhu, S. Setia, and S. Jajodia > >The paper underscores that although SDR is "stateless", it still needs >reliable multicast transport. In other words, the stateless property as >defined here means that if a group member does get the rekey multicast >packet, he/she has all the info needed to acquire the new group key >without dependency on state info received in other rekey packets. But >members that don't get the rekey packet are out of luck until the next >rekey message is sent, unless there is a recovery mechanism. > >The paper goes on to explain how adding FEC and Batched Key >Re-transmission (BKR) to SDR could address the reliablity problem. > >I largely concur with Mark's outline, in that having the GKM-arch specify >the base error recovery is a minimum starting point. However, I would also >require that the group policy token have the hooks (i.e. reserved TLV) for >describing the group's mandatory RMT protocol and its operating >parameters. This finesses the "there are many deployment scenarios..." >issues by specifying the extensibility that must be built into the GKM >protocol and its policy token. > >To get this capability, at first sight it seems we need: an RMT protocol >identifier space as an IANA consideration for the GKM-arch or else the >group policy token spec. thoughts? I would not put an identifier into a group key management protocol for an RMT protocol when there are no standard RMT protocols. If reliable multicast were more important to group key management then I perceive it to be, we could add numbers for Experimental RFCs (IKE did that for SPKI). But I don't think we lose anything with the status quo, which is to use a sequence number and periodic retransmission of the re-key message. Mark > > > > > > > > Mark > > > > > > > > > > > > >--- Andrea > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >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 > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 4 21:33:20 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17389 for ; Mon, 4 Aug 2003 21:33:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 91D2F53803; Mon, 4 Aug 2003 21:32:38 -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 C27BD53801 for ; Mon, 4 Aug 2003 21:30:40 -0400 (EDT) Received: (qmail 14939 invoked by uid 3269); 5 Aug 2003 01:30:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14906 invoked from network); 5 Aug 2003 01:30:39 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 5 Aug 2003 01:30:39 -0000 Received: (qmail 43310 invoked from network); 5 Aug 2003 01:30:38 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.162) by mail.nac.net with SMTP; 5 Aug 2003 01:30:38 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h74NNVQ30887; Mon, 4 Aug 2003 19:23:31 -0400 From: George Gross To: Mark Baugher Cc: George Gross , Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <5.1.1.5.2.20030731133701.0221d828@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: Mon, 4 Aug 2003 19:23:31 -0400 (EDT) Hi Mark, On Thu, 31 Jul 2003, Mark Baugher wrote: > George, > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > >I largely concur with Mark's outline, in that having the GKM-arch specify > >the base error recovery is a minimum starting point. However, I would also > >require that the group policy token have the hooks (i.e. reserved TLV) for > >describing the group's mandatory RMT protocol and its operating > >parameters. This finesses the "there are many deployment scenarios..." > >issues by specifying the extensibility that must be built into the GKM > >protocol and its policy token. > > > >To get this capability, at first sight it seems we need: an RMT protocol > >identifier space as an IANA consideration for the GKM-arch or else the > >group policy token spec. thoughts? > > I would not put an identifier into a group key management protocol for an > RMT protocol when there are no standard RMT protocols. If reliable > multicast were more important to group key management then I perceive it to > be, we could add numbers for Experimental RFCs (IKE did that for > SPKI). But I don't think we lose anything with the status quo, which is to > use a sequence number and periodic retransmission of the re-key message. > > Mark Hmmmm, I think we do lose/miss something. Suppose that in the future, a RMT protocol is standardized, and that the MSEC policy token v2 was "extended" to include the formerly unspecified but now standard RMT identifier. The endpoints that are running MSEC v1 will be unable to reliably participate in the group, as they get dropped after the first lost rekey packet. There will not be retransmission of the rekey message because the GCKS expects the v1 endpoints to handle the RMT. Detecting the next rekey message's sequence number mismatch could be an unacceptably long wait... At the very least, this case raises a requirement in the registration protocol to have the v1 endpoint tell the GCKS its version number and/or supported RMT set. That way, the GCKS can straddle the v1 and v2 group subsets with their respective RMT rekey policies. RMT aside, I would think we need this capability to allow v1 endpoints to participate with v1 rekey protocols in parallel to v2 endpoints using a "new" rekey protocol. AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 5 11:32:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16226 for ; Tue, 5 Aug 2003 11:32:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8014453752; Tue, 5 Aug 2003 11:28: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 386A9537B9 for ; Tue, 5 Aug 2003 11:25:30 -0400 (EDT) Received: (qmail 88575 invoked by uid 3269); 5 Aug 2003 15:25:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88571 invoked from network); 5 Aug 2003 15:25:29 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 5 Aug 2003 15:25:29 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h75FOXIJ011060; Tue, 5 Aug 2003 10:24:34 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h75FPMk5017898; Tue, 5 Aug 2003 10:25:23 -0500 Received: from sparta.com (dhcp-7.columbia.sparta.com [157.185.80.8]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA27768; Tue, 5 Aug 2003 11:25:19 -0400 (EDT) Subject: Re: [MSEC] Next gkmarch I-D Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: George Gross From: Hugh Harney In-Reply-To: Message-Id: <09071D10-C759-11D7-972B-000393DAD548@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, 5 Aug 2003 11:25:24 -0400 Content-Transfer-Encoding: 7bit George, I think that the key management architecture and security policy definitions should be separated from the communications network mechanisms. I understand your concerns about different network reliability characteristics perhaps presenting problems for rekey actions. I believe the answer is to identify how the security protocols will handle failures in the communications system (ref: GSAKMP protocol state diagram). The answer is not to have the security system start managing the communications network. GSAKMP does not need to identify the RMT protocol supporting rekey. GSAKMP passes information to the GM about the life-span of the keys, and the rekey frequency to be expected. If either of these parameters is exceeded GSAKMP closes out the group and can then try to rejoin. This failing to a secure state is critical in high assurance key management protocols. That said. The GSAKMP Policy Token is defined for GSAKMP and IPSec, using multiple transmissions as the reliability mechanism for rekey. If another protocol or architecture wants to use the GSAKMP PT, we allow them to branch at the protocol ID field in the protocol. If someone takes that branch they can define the "Protocol Something Else" to include the identification of RMT protocol. We hopefully will make their job easier since they have a worked example to follow. Hugh On Monday, Aug 4, 2003, at 19:23 US/Eastern, George Gross wrote: > Hi Mark, > > On Thu, 31 Jul 2003, Mark Baugher wrote: > >> George, >> >> At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > >>> I largely concur with Mark's outline, in that having the GKM-arch >>> specify >>> the base error recovery is a minimum starting point. However, I >>> would also >>> require that the group policy token have the hooks (i.e. reserved >>> TLV) for >>> describing the group's mandatory RMT protocol and its operating >>> parameters. This finesses the "there are many deployment >>> scenarios..." >>> issues by specifying the extensibility that must be built into the >>> GKM >>> protocol and its policy token. >>> >>> To get this capability, at first sight it seems we need: an RMT >>> protocol >>> identifier space as an IANA consideration for the GKM-arch or else >>> the >>> group policy token spec. thoughts? >> >> I would not put an identifier into a group key management protocol >> for an >> RMT protocol when there are no standard RMT protocols. If reliable >> multicast were more important to group key management then I perceive >> it to >> be, we could add numbers for Experimental RFCs (IKE did that for >> SPKI). But I don't think we lose anything with the status quo, which >> is to >> use a sequence number and periodic retransmission of the re-key >> message. >> >> Mark > > Hmmmm, I think we do lose/miss something. Suppose that in the future, a > RMT protocol is standardized, and that the MSEC policy token v2 was > "extended" to include the formerly unspecified but now standard RMT > identifier. The endpoints that are running MSEC v1 will be unable to > reliably participate in the group, as they get dropped after the first > lost rekey packet. There will not be retransmission of the rekey > message > because the GCKS expects the v1 endpoints to handle the RMT. Detecting > the > next rekey message's sequence number mismatch could be an unacceptably > long wait... > > At the very least, this case raises a requirement in the registration > protocol to have the v1 endpoint tell the GCKS its version number > and/or > supported RMT set. That way, the GCKS can straddle the v1 and v2 group > subsets with their respective RMT rekey policies. RMT aside, I would > think > we need this capability to allow v1 endpoints to participate with v1 > rekey > protocols in parallel to v2 endpoints using a "new" rekey protocol. > > AFAIK, neither GDOI nor the GSAKMP registration protocol handle this > case. > > br, > George > > > _______________________________________________ > 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 Aug 5 14:54:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23068 for ; Tue, 5 Aug 2003 14:54:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 396FC53658; Tue, 5 Aug 2003 14:54:04 -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 A485D53660 for ; Tue, 5 Aug 2003 14:52:25 -0400 (EDT) Received: (qmail 24110 invoked by uid 3269); 5 Aug 2003 18:52:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24107 invoked from network); 5 Aug 2003 18:52:25 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 5 Aug 2003 18:52:25 -0000 Received: (qmail 54010 invoked from network); 5 Aug 2003 18:52:23 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.187) by mail.nac.net with SMTP; 5 Aug 2003 18:52:23 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h75GjAH32422; Tue, 5 Aug 2003 12:45:10 -0400 From: George Gross To: Hugh Harney Cc: George Gross , Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <09071D10-C759-11D7-972B-000393DAD548@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: Tue, 5 Aug 2003 12:45:10 -0400 (EDT) Hugh, On Tue, 5 Aug 2003, Hugh Harney wrote: > George, > > I think that the key management architecture and security policy > definitions should be separated from the communications network > mechanisms. > > I understand your concerns about different network reliability > characteristics perhaps presenting problems for rekey actions. I > believe the answer is to identify how the security protocols will > handle failures in the communications system (ref: GSAKMP protocol > state diagram). The answer is not to have the security system start > managing the communications network. If I understand what you're saying, then you would be adding a new event/signal to the GSAKMP finite state machine in the v04 version of the GSAKMP ID, right? The event would be something like: "RMT service had an unrecoverable error for these group members". For GSAKMP v1, the RMT service is simply the rudimentary retransmission policy we have discussed on the list, and this "RMT error" event would be unlikely to occur. However, my example below discussed a hetrogenous group composed of both v1 and v2 endpoints. Your response does not fully speak to backward compatibility for a group formed from a mixture of endpoints. Please explain to me how you would anticipate that GSAKMP v2 will interoperate with a GSAKMP v1 embedded base? In prior e-mails, I had been using RMT as a litmus test for my thinking about this scenario. Setting aside RMT, there are likely to be other parameters in v2 not known to a v1 endpoint. There should be a way to express that a policy parameter is "critical" in that it can not be ignored if it is not implemented. Other parameters could be safely ignored. This extensibility needs to be in v1 even if it is not being used yet. Also, wouldn't it make sense to have the group member identify its GSAKMP version in the RTJ? Or are you saying that a group can't have a mixture of endpoints where both GSAKMP versions co-exist concurrently? If so, then that must be highlighted as a restriction in the spec. > > GSAKMP does not need to identify the RMT protocol supporting rekey. > GSAKMP passes information to the GM about the life-span of the keys, > and the rekey frequency to be expected. If either of these parameters > is exceeded GSAKMP closes out the group and can then try to rejoin. | I assume you are saying "the group member times out" here? So after a rekey packet loss the endpoint stalls for the duration of the time (i.e. minutes?) that elapses until the next rekey? > This failing to a secure state is critical in high assurance key > management protocols. > > That said. The GSAKMP Policy Token is defined for GSAKMP and IPSec, > using multiple transmissions as the reliability mechanism for rekey. If > another protocol or architecture wants to use the GSAKMP PT, we allow > them to branch at the protocol ID field in the protocol. If someone > takes that branch they can define the "Protocol Something Else" to > include the identification of RMT protocol. Perhaps I've overlooked it, but where in GSAKMP or the policy token does one declare vendor-specific extensions? The "Protocol ID" field makes no mention of this capability. An old GSAKMP ID (v02?) I have floating around mentions that the Vendor ID payload was removed but did not explain why. There is no IANA considerations section in msec-tokenspec-sec-00.txt for this and other identifier fields. > We hopefully will make > their job easier since they have a worked example to follow. > > Hugh > > > On Monday, Aug 4, 2003, at 19:23 US/Eastern, George Gross wrote: > > > Hi Mark, > > > > On Thu, 31 Jul 2003, Mark Baugher wrote: > > > >> George, > >> > >> At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > >>> I largely concur with Mark's outline, in that having the GKM-arch > >>> specify > >>> the base error recovery is a minimum starting point. However, I > >>> would also > >>> require that the group policy token have the hooks (i.e. reserved > >>> TLV) for > >>> describing the group's mandatory RMT protocol and its operating > >>> parameters. This finesses the "there are many deployment > >>> scenarios..." > >>> issues by specifying the extensibility that must be built into the > >>> GKM > >>> protocol and its policy token. > >>> > >>> To get this capability, at first sight it seems we need: an RMT > >>> protocol > >>> identifier space as an IANA consideration for the GKM-arch or else > >>> the > >>> group policy token spec. thoughts? > >> > >> I would not put an identifier into a group key management protocol > >> for an > >> RMT protocol when there are no standard RMT protocols. If reliable > >> multicast were more important to group key management then I perceive > >> it to > >> be, we could add numbers for Experimental RFCs (IKE did that for > >> SPKI). But I don't think we lose anything with the status quo, which > >> is to > >> use a sequence number and periodic retransmission of the re-key > >> message. > >> > >> Mark > > > > Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > RMT protocol is standardized, and that the MSEC policy token v2 was > > "extended" to include the formerly unspecified but now standard RMT > > identifier. The endpoints that are running MSEC v1 will be unable to > > reliably participate in the group, as they get dropped after the first > > lost rekey packet. There will not be retransmission of the rekey > > message > > because the GCKS expects the v1 endpoints to handle the RMT. Detecting > > the > > next rekey message's sequence number mismatch could be an unacceptably > > long wait... > > > > At the very least, this case raises a requirement in the registration > > protocol to have the v1 endpoint tell the GCKS its version number > > and/or > > supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > subsets with their respective RMT rekey policies. RMT aside, I would > > think > > we need this capability to allow v1 endpoints to participate with v1 > > rekey > > protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > AFAIK, neither GDOI nor the GSAKMP registration protocol handle this > > case. > > > > br, > > George > > > > > > _______________________________________________ > > 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 Aug 6 01:32:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09510 for ; Wed, 6 Aug 2003 01:32:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 86F25536C6; Wed, 6 Aug 2003 01:32: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 4E02D53629 for ; Wed, 6 Aug 2003 01:30:55 -0400 (EDT) Received: (qmail 64830 invoked by uid 3269); 6 Aug 2003 05:30:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64825 invoked from network); 6 Aug 2003 05:30:55 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 6 Aug 2003 05:30:55 -0000 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2003 22:30:54 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn2-253.cisco.com [10.21.112.253]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h765UouH003501; Tue, 5 Aug 2003 22:30:51 -0700 (PDT) Message-Id: <5.1.1.5.2.20030805222839.0651b1f8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: George Gross , In-Reply-To: References: <5.1.1.5.2.20030731133701.0221d828@mira-sjc5-6.cisco.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, 05 Aug 2003 22:30:48 -0700 hi George, I think the interoperability issue that you mention below could happen on any element of policy. Somehow the policy is determined and if it has advanced or new features than some legacy members don't support, then there will be an interoperability problem. Best regards, Mark At 07:23 PM 8/4/2003 -0400, George Gross wrote: >Hi Mark, > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > George, > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > >I largely concur with Mark's outline, in that having the GKM-arch specify > > >the base error recovery is a minimum starting point. However, I would also > > >require that the group policy token have the hooks (i.e. reserved TLV) for > > >describing the group's mandatory RMT protocol and its operating > > >parameters. This finesses the "there are many deployment scenarios..." > > >issues by specifying the extensibility that must be built into the GKM > > >protocol and its policy token. > > > > > >To get this capability, at first sight it seems we need: an RMT protocol > > >identifier space as an IANA consideration for the GKM-arch or else the > > >group policy token spec. thoughts? > > > > I would not put an identifier into a group key management protocol for an > > RMT protocol when there are no standard RMT protocols. If reliable > > multicast were more important to group key management then I perceive it to > > be, we could add numbers for Experimental RFCs (IKE did that for > > SPKI). But I don't think we lose anything with the status quo, which is to > > use a sequence number and periodic retransmission of the re-key message. > > > > Mark > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a >RMT protocol is standardized, and that the MSEC policy token v2 was >"extended" to include the formerly unspecified but now standard RMT >identifier. The endpoints that are running MSEC v1 will be unable to >reliably participate in the group, as they get dropped after the first >lost rekey packet. There will not be retransmission of the rekey message >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the >next rekey message's sequence number mismatch could be an unacceptably >long wait... > >At the very least, this case raises a requirement in the registration >protocol to have the v1 endpoint tell the GCKS its version number and/or >supported RMT set. That way, the GCKS can straddle the v1 and v2 group >subsets with their respective RMT rekey policies. RMT aside, I would think >we need this capability to allow v1 endpoints to participate with v1 rekey >protocols in parallel to v2 endpoints using a "new" rekey protocol. > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > >br, > George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 6 10:07:01 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17114 for ; Wed, 6 Aug 2003 10:07:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1446153803; Wed, 6 Aug 2003 10:06: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 6A8B6536C6 for ; Wed, 6 Aug 2003 10:04:01 -0400 (EDT) Received: (qmail 49238 invoked by uid 3269); 6 Aug 2003 14:04:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49233 invoked from network); 6 Aug 2003 14:04:01 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 6 Aug 2003 14:04:01 -0000 Received: (qmail 13255 invoked from network); 6 Aug 2003 14:04:00 -0000 Received: from unknown (HELO nsx.garage) (64.21.175.173) by mail.nac.net with SMTP; 6 Aug 2003 14:04:00 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h76BucD01880; Wed, 6 Aug 2003 07:56:38 -0400 From: George Gross To: Mark Baugher Cc: George Gross , Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <5.1.1.5.2.20030805222839.0651b1f8@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: Wed, 6 Aug 2003 07:56:38 -0400 (EDT) Hi Mark, On Tue, 5 Aug 2003, Mark Baugher wrote: > hi George, > I think the interoperability issue that you mention below could happen > on any element of policy. Somehow the policy is determined and if it has > advanced or new features than some legacy members don't support, then there > will be an interoperability problem. > > Best regards, Mark Ok, so would you agree then that a version number should be introduced in the group member's registration "request to join" message? Also, in a related post to this list, I had proposed the protocol feature of having a "critical" or mandatory to implement flag in the key management protocol's Type/Length/Value encodings. This mechanism specifically addresses this backward compatibility interoperability issue. I would not expect this to be a controversial concept to require in GSAKMP or GDOI. It is a basic protocol design feature, examples of which can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is illegal to mark a vendor specific TLV critical. br, George > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > >Hi Mark, > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > George, > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch specify > > > >the base error recovery is a minimum starting point. However, I would also > > > >require that the group policy token have the hooks (i.e. reserved TLV) for > > > >describing the group's mandatory RMT protocol and its operating > > > >parameters. This finesses the "there are many deployment scenarios..." > > > >issues by specifying the extensibility that must be built into the GKM > > > >protocol and its policy token. > > > > > > > >To get this capability, at first sight it seems we need: an RMT protocol > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > >group policy token spec. thoughts? > > > > > > I would not put an identifier into a group key management protocol for an > > > RMT protocol when there are no standard RMT protocols. If reliable > > > multicast were more important to group key management then I perceive it to > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > SPKI). But I don't think we lose anything with the status quo, which is to > > > use a sequence number and periodic retransmission of the re-key message. > > > > > > Mark > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > >RMT protocol is standardized, and that the MSEC policy token v2 was > >"extended" to include the formerly unspecified but now standard RMT > >identifier. The endpoints that are running MSEC v1 will be unable to > >reliably participate in the group, as they get dropped after the first > >lost rekey packet. There will not be retransmission of the rekey message > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > >next rekey message's sequence number mismatch could be an unacceptably > >long wait... > > > >At the very least, this case raises a requirement in the registration > >protocol to have the v1 endpoint tell the GCKS its version number and/or > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > >subsets with their respective RMT rekey policies. RMT aside, I would think > >we need this capability to allow v1 endpoints to participate with v1 rekey > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > >br, > > George > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 6 13:14:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25152 for ; Wed, 6 Aug 2003 13:14:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 59655536A7; Wed, 6 Aug 2003 13:14:10 -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 6D12D536A7 for ; Wed, 6 Aug 2003 13:13:15 -0400 (EDT) Received: (qmail 81805 invoked by uid 3269); 6 Aug 2003 17:13:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81802 invoked from network); 6 Aug 2003 17:13:15 -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; 6 Aug 2003 17:13:15 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn4-809.cisco.com [10.21.83.40]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h76HDB7G005221; Wed, 6 Aug 2003 10:13:12 -0700 (PDT) Message-Id: <5.1.1.5.2.20030806101103.0641c5c0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: In-Reply-To: References: <5.1.1.5.2.20030805222839.0651b1f8@mira-sjc5-6.cisco.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: Wed, 06 Aug 2003 10:13:10 -0700 George, GDOI has a version number in it. So does GSAKMP. Perhaps we should mention this need in gkmarch. Mark At 07:56 AM 8/6/2003 -0400, George Gross wrote: >Hi Mark, > > >On Tue, 5 Aug 2003, Mark Baugher wrote: > > > hi George, > > I think the interoperability issue that you mention below could happen > > on any element of policy. Somehow the policy is determined and if it has > > advanced or new features than some legacy members don't support, then there > > will be an interoperability problem. > > > > Best regards, Mark > >Ok, so would you agree then that a version number should be introduced in >the group member's registration "request to join" message? > >Also, in a related post to this list, I had proposed the protocol feature >of having a "critical" or mandatory to implement flag in the key >management protocol's Type/Length/Value encodings. This mechanism >specifically addresses this backward compatibility interoperability issue. > >I would not expect this to be a controversial concept to require in >GSAKMP or GDOI. It is a basic protocol design feature, examples of which >can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is >illegal to mark a vendor specific TLV critical. > >br, > George > > > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > > >Hi Mark, > > > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > > > George, > > > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch > specify > > > > >the base error recovery is a minimum starting point. However, I > would also > > > > >require that the group policy token have the hooks (i.e. reserved > TLV) for > > > > >describing the group's mandatory RMT protocol and its operating > > > > >parameters. This finesses the "there are many deployment scenarios..." > > > > >issues by specifying the extensibility that must be built into the GKM > > > > >protocol and its policy token. > > > > > > > > > >To get this capability, at first sight it seems we need: an RMT > protocol > > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > > >group policy token spec. thoughts? > > > > > > > > I would not put an identifier into a group key management protocol > for an > > > > RMT protocol when there are no standard RMT protocols. If reliable > > > > multicast were more important to group key management then I > perceive it to > > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > > SPKI). But I don't think we lose anything with the status quo, > which is to > > > > use a sequence number and periodic retransmission of the re-key > message. > > > > > > > > Mark > > > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > >RMT protocol is standardized, and that the MSEC policy token v2 was > > >"extended" to include the formerly unspecified but now standard RMT > > >identifier. The endpoints that are running MSEC v1 will be unable to > > >reliably participate in the group, as they get dropped after the first > > >lost rekey packet. There will not be retransmission of the rekey message > > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > > >next rekey message's sequence number mismatch could be an unacceptably > > >long wait... > > > > > >At the very least, this case raises a requirement in the registration > > >protocol to have the v1 endpoint tell the GCKS its version number and/or > > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > >subsets with their respective RMT rekey policies. RMT aside, I would think > > >we need this capability to allow v1 endpoints to participate with v1 rekey > > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > > > >br, > > > George > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 6 17:28:08 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05710 for ; Wed, 6 Aug 2003 17:28:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 51E4E5359C; Wed, 6 Aug 2003 17:27: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 BC0EF53818 for ; Wed, 6 Aug 2003 17:23:39 -0400 (EDT) Received: (qmail 23764 invoked by uid 3269); 6 Aug 2003 21:23:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23761 invoked from network); 6 Aug 2003 21:23:39 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 6 Aug 2003 21:23:39 -0000 Received: (qmail 26502 invoked from network); 6 Aug 2003 21:23:38 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.187) by mail.nac.net with SMTP; 6 Aug 2003 21:23:38 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h76JGDM02879; Wed, 6 Aug 2003 15:16:13 -0400 From: George Gross To: Mark Baugher Cc: George Gross , Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <5.1.1.5.2.20030806101103.0641c5c0@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: Wed, 6 Aug 2003 15:16:13 -0400 (EDT) Mark, On Wed, 6 Aug 2003, Mark Baugher wrote: > George, > GDOI has a version number in it. So does GSAKMP. Oops, sorry, my e-mail was not precise. What I really should have said was "the semantics for mismatched version numbers between GCKS and group member are currently underspecified...". In GSAKMP, there are Notify payloads for invalid version numbers, but I did not find any text explaining when that would be triggered. I think that this needs to be added, in alignment with the requirement for backward compatibility. In GDOI there is no explicit discussion of version number processing. In fact, RFC3547 does not have the word "error" in it at all. Amazing, an error free protocol ;o) The text in section 3.2.2 seems to hint ISAKMP version error processing is implied? it would be reasonable for GDOI v2 to say more here.... > Perhaps we should > mention this need in gkmarch. Yes, I might go so far as to say that backward compatibility would be important to have specified as a MUST. If we are talking about large-scale multicast, it is likely that a protocol software upgrade transition from v1->v2 will straddle large numbers of endpoints, and could take many weeks/months. In other words, the GCKS is required to accept any group member protocol version less than or equal to the highest version the GCKS supports. George > > Mark > At 07:56 AM 8/6/2003 -0400, George Gross wrote: > >Hi Mark, > > > > > >On Tue, 5 Aug 2003, Mark Baugher wrote: > > > > > hi George, > > > I think the interoperability issue that you mention below could happen > > > on any element of policy. Somehow the policy is determined and if it has > > > advanced or new features than some legacy members don't support, then there > > > will be an interoperability problem. > > > > > > Best regards, Mark > > > >Ok, so would you agree then that a version number should be introduced in > >the group member's registration "request to join" message? > > > >Also, in a related post to this list, I had proposed the protocol feature > >of having a "critical" or mandatory to implement flag in the key > >management protocol's Type/Length/Value encodings. This mechanism > >specifically addresses this backward compatibility interoperability issue. > > > >I would not expect this to be a controversial concept to require in > >GSAKMP or GDOI. It is a basic protocol design feature, examples of which > >can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is > >illegal to mark a vendor specific TLV critical. > > > >br, > > George > > > > > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > > > >Hi Mark, > > > > > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > > > > > George, > > > > > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch > > specify > > > > > >the base error recovery is a minimum starting point. However, I > > would also > > > > > >require that the group policy token have the hooks (i.e. reserved > > TLV) for > > > > > >describing the group's mandatory RMT protocol and its operating > > > > > >parameters. This finesses the "there are many deployment scenarios..." > > > > > >issues by specifying the extensibility that must be built into the GKM > > > > > >protocol and its policy token. > > > > > > > > > > > >To get this capability, at first sight it seems we need: an RMT > > protocol > > > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > > > >group policy token spec. thoughts? > > > > > > > > > > I would not put an identifier into a group key management protocol > > for an > > > > > RMT protocol when there are no standard RMT protocols. If reliable > > > > > multicast were more important to group key management then I > > perceive it to > > > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > > > SPKI). But I don't think we lose anything with the status quo, > > which is to > > > > > use a sequence number and periodic retransmission of the re-key > > message. > > > > > > > > > > Mark > > > > > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > > >RMT protocol is standardized, and that the MSEC policy token v2 was > > > >"extended" to include the formerly unspecified but now standard RMT > > > >identifier. The endpoints that are running MSEC v1 will be unable to > > > >reliably participate in the group, as they get dropped after the first > > > >lost rekey packet. There will not be retransmission of the rekey message > > > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > > > >next rekey message's sequence number mismatch could be an unacceptably > > > >long wait... > > > > > > > >At the very least, this case raises a requirement in the registration > > > >protocol to have the v1 endpoint tell the GCKS its version number and/or > > > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > > >subsets with their respective RMT rekey policies. RMT aside, I would think > > > >we need this capability to allow v1 endpoints to participate with v1 rekey > > > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > > > > > >br, > > > > George > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 6 18:06:20 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07127 for ; Wed, 6 Aug 2003 18:06:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8DC3C53536; Wed, 6 Aug 2003 18:05:39 -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 1B50253536 for ; Wed, 6 Aug 2003 18:03:40 -0400 (EDT) Received: (qmail 28990 invoked by uid 3269); 6 Aug 2003 22:03:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28987 invoked from network); 6 Aug 2003 22:03:40 -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; 6 Aug 2003 22:03:40 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2003 15:08:26 -0700 Received: from cisco.com ([128.107.177.101]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h76M3btp017693; Wed, 6 Aug 2003 15:03:37 -0700 (PDT) Message-ID: <3F317B38.F697A55A@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: George Gross Cc: Mark Baugher , msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D References: 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, 06 Aug 2003 15:03:36 -0700 Content-Transfer-Encoding: 7bit Hi George, George Gross wrote: > In GDOI there is no explicit discussion of version number processing. In > fact, RFC3547 does not have the word "error" in it at all. Amazing, an > error free protocol ;o) The text in section 3.2.2 seems to hint ISAKMP > version error processing is implied? it would be reasonable for GDOI v2 to > say more here.... I absolutely agree with your conclusion. New attributes can be added to GDOI (e.g., KEK attributes), and these could add a new policy attribute such as "must use a reliable multicast protocol". But as you imply, there is no clear specification of how a receiver would deal with the new attribute (e.g., ignore, or drop the session). That should be made more clear in GDOI v2 as well. > > Perhaps we should > > mention this need in gkmarch. > > Yes, I might go so far as to say that backward compatibility would be > important to have specified as a MUST. If we are talking about large-scale > multicast, it is likely that a protocol software upgrade transition from > v1->v2 will straddle large numbers of endpoints, and could take many > weeks/months. > > In other words, the GCKS is required to accept any group member protocol > > version less than or equal to the highest version the GCKS supports. I'm not sure if requiring this is a good idea. If v1 had a security problem that v2 fixed, I'm not sure all protocols supporting v2 should be required to speak the insecure v1 version. But a discussion of the migration issue might be a good idea, with recommendations on what to do. Thanks, Brian > George > > > > > Mark > > At 07:56 AM 8/6/2003 -0400, George Gross wrote: > > >Hi Mark, > > > > > > > > >On Tue, 5 Aug 2003, Mark Baugher wrote: > > > > > > > hi George, > > > > I think the interoperability issue that you mention below could happen > > > > on any element of policy. Somehow the policy is determined and if it has > > > > advanced or new features than some legacy members don't support, then there > > > > will be an interoperability problem. > > > > > > > > Best regards, Mark > > > > > >Ok, so would you agree then that a version number should be introduced in > > >the group member's registration "request to join" message? > > > > > >Also, in a related post to this list, I had proposed the protocol feature > > >of having a "critical" or mandatory to implement flag in the key > > >management protocol's Type/Length/Value encodings. This mechanism > > >specifically addresses this backward compatibility interoperability issue. > > > > > >I would not expect this to be a controversial concept to require in > > >GSAKMP or GDOI. It is a basic protocol design feature, examples of which > > >can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is > > >illegal to mark a vendor specific TLV critical. > > > > > >br, > > > George > > > > > > > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > > > > >Hi Mark, > > > > > > > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > > > > > > > George, > > > > > > > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > > > > > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch > > > specify > > > > > > >the base error recovery is a minimum starting point. However, I > > > would also > > > > > > >require that the group policy token have the hooks (i.e. reserved > > > TLV) for > > > > > > >describing the group's mandatory RMT protocol and its operating > > > > > > >parameters. This finesses the "there are many deployment scenarios..." > > > > > > >issues by specifying the extensibility that must be built into the GKM > > > > > > >protocol and its policy token. > > > > > > > > > > > > > >To get this capability, at first sight it seems we need: an RMT > > > protocol > > > > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > > > > >group policy token spec. thoughts? > > > > > > > > > > > > I would not put an identifier into a group key management protocol > > > for an > > > > > > RMT protocol when there are no standard RMT protocols. If reliable > > > > > > multicast were more important to group key management then I > > > perceive it to > > > > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > > > > SPKI). But I don't think we lose anything with the status quo, > > > which is to > > > > > > use a sequence number and periodic retransmission of the re-key > > > message. > > > > > > > > > > > > Mark > > > > > > > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > > > >RMT protocol is standardized, and that the MSEC policy token v2 was > > > > >"extended" to include the formerly unspecified but now standard RMT > > > > >identifier. The endpoints that are running MSEC v1 will be unable to > > > > >reliably participate in the group, as they get dropped after the first > > > > >lost rekey packet. There will not be retransmission of the rekey message > > > > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > > > > >next rekey message's sequence number mismatch could be an unacceptably > > > > >long wait... > > > > > > > > > >At the very least, this case raises a requirement in the registration > > > > >protocol to have the v1 endpoint tell the GCKS its version number and/or > > > > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > > > >subsets with their respective RMT rekey policies. RMT aside, I would think > > > > >we need this capability to allow v1 endpoints to participate with v1 rekey > > > > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > > > > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > > > > > > > >br, > > > > > George > > > > > > > > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- 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 Aug 6 18:11:26 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07665 for ; Wed, 6 Aug 2003 18:11:26 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 19EDA537FD; Wed, 6 Aug 2003 18:10:28 -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 0D3ED53800 for ; Wed, 6 Aug 2003 18:08:33 -0400 (EDT) Received: (qmail 29580 invoked by uid 3269); 6 Aug 2003 22:08:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29577 invoked from network); 6 Aug 2003 22:08:33 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 6 Aug 2003 22:08:33 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Aug 2003 15:08:33 -0700 Received: from cisco.com ([128.107.177.101]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h76M8VLH011225 for ; Wed, 6 Aug 2003 15:08:31 -0700 (PDT) Message-ID: <3F317C5E.D81117E5@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] New proposed MSEC Arch Security Considerations 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, 06 Aug 2003 15:08:30 -0700 Content-Transfer-Encoding: 7bit This is a reminder that the last call for the MSEC Architecture documents ends on Friday, August 8. I haven't seen any comments posted against the -02 document yet. Also, I noticed that the Security Considerations section is particularly weak. I'd like to propose the following complete replacement text. Thanks, Brian 6. Security Considerations This document describes a an architectural framework for protecting multicast and group traffic with cryptographic protocols. Three functional areas are identified within the framework. Each functional area has unique security considerations, and these are discussed below. This architectural framework is end-to-end, and does not rely upon the network that connects group controllers and group members. As such, denial of service, message deletion, and other active attacks on the unicast or multicast routing infrastructures are not addressed by this framework. 6.1 Multicast Data Handling Cryptographic protocols protecting multicast data are responsible for providing confidentiality, group authentication, and replay protection. They should also be able to provide source authentication to uniquely identify senders to the group. Section 3.1 elaborates on the security requirements for this area. 6.2 Group Key Management Group key management protocols provide cryptographic keys and policy to group members. They are responsible for authenticating and authorizing group members before revealing those keys, and for providing confidentiality and authentication of those keys during transit. They are also responsible for providing a means for rekeying the group, in the case that the policy specifies a lifetime for the keys. They also are responsible for revocation of group membership, once one or more group members have had their authorization to be a group member revoked. Section 3.2 describes the security requirements of this area in more detail. 6.3 Multicast Security Policies Cryptographic protocols providing multicast security policies are responsible for distributing that policy such that the integrity of the policy is maintained. If the policy itself is confidential, they also are responsible for authenticating group controllers and group members, and providing confidentiality of the policy during transit. -- 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 Fri Aug 8 00:10:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14645 for ; Fri, 8 Aug 2003 00:10:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 973D45365C; Fri, 8 Aug 2003 00:10: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 D61E45358E for ; Fri, 8 Aug 2003 00:08:19 -0400 (EDT) Received: (qmail 53216 invoked by uid 3269); 8 Aug 2003 04:08:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53213 invoked from network); 8 Aug 2003 04:08:19 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 04:08:19 -0000 Received: (qmail 64127 invoked from network); 8 Aug 2003 04:08:18 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.191) by mail.nac.net with SMTP; 8 Aug 2003 04:08:18 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7820f205915; Thu, 7 Aug 2003 22:00:41 -0400 From: George Gross To: Brian Weis Cc: Subject: Re: [MSEC] New proposed MSEC Arch Security Considerations In-Reply-To: <3F317C5E.D81117E5@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, 7 Aug 2003 22:00:40 -0400 (EDT) Hi Brian, The rev'd security considerations and the v02 ID look good, and essentially ready for pub. A few dinkies: o In section 1.1, the phrase "... then the connectivity of the senders and receivers may be affected." would be clearer if it said "adversely affected". BTW, did I correctly infer that the case that you are referring to is: RFC1918_realm_A =>NAT=>public_Internet=>NAT=>RFC1918_realm_B o Last paragraph in section 1.1 the phrase "by a lack of availability." may read more easily as "by the omission of that capability from a deployment." o Page 20, Reference BHHW is now RFC3547 not an ID ;o) Honestly, I haven't waded through my e-mail archive to look at every item we ever talked about on this list, but clearly the major items have been accomodated and moved to a good place, thank you! AFAIC, its time to ship it ;o) br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 12:52:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17342 for ; Fri, 8 Aug 2003 12:52:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1DDBA536B5; Fri, 8 Aug 2003 12:52: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 22951535FB for ; Fri, 8 Aug 2003 12:51:11 -0400 (EDT) Received: (qmail 16485 invoked by uid 3269); 8 Aug 2003 16:51:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16479 invoked from network); 8 Aug 2003 16:51:09 -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; 8 Aug 2003 16:51:09 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Aug 2003 09:56:22 -0700 Received: from cisco.com ([128.107.177.101]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h78Gp6LH024359; Fri, 8 Aug 2003 09:51:07 -0700 (PDT) Message-ID: <3F33D4FA.5699225E@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: George Gross Cc: msec@securemulticast.org Subject: Re: [MSEC] New proposed MSEC Arch Security Considerations References: 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: Fri, 08 Aug 2003 09:51:06 -0700 Content-Transfer-Encoding: 7bit Hi George, George Gross wrote: > > Hi Brian, > > The rev'd security considerations and the v02 ID look good, and > essentially ready for pub. A few dinkies: > > o In section 1.1, the phrase "... then the connectivity of the senders and > receivers may be affected." would be clearer if it said "adversely > affected". BTW, did I correctly infer that the case that you are referring Ok, I've added the word "adversely". > to is: > > RFC1918_realm_A =>NAT=>public_Internet=>NAT=>RFC1918_realm_B Actually, I think even the case of RFC1918_realm_A =>NAT=>public_Internet would be a problem, because then the source IP address for an SA distributed by key management wouldn't match the actual source IP address on the packet. That's fits into the basic class of NAT issues of a signaling protocol reporting the original IP address, when actually NAT has changed it. > o Last paragraph in section 1.1 the phrase "by a lack of availability." > may read more easily as "by the omission of that capability from a > deployment." Your wording sounds fine, thanks. > o Page 20, Reference BHHW is now RFC3547 not an ID ;o) Got it. :-) > Honestly, I haven't waded through my e-mail archive to look at every item > we ever talked about on this list, but clearly the major items have been > accomodated and moved to a good place, thank you! > > AFAIC, its time to ship it ;o) Great! Thanks for all your good input. Brian > br, > George > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- 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 Fri Aug 8 17:25:06 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26615 for ; Fri, 8 Aug 2003 17:25:05 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 03071537C6; Fri, 8 Aug 2003 17:24:33 -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 DEACE537C4 for ; Fri, 8 Aug 2003 17:22:35 -0400 (EDT) Received: (qmail 58492 invoked by uid 3269); 8 Aug 2003 21:22:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58489 invoked from network); 8 Aug 2003 21:22:35 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:22:35 -0000 Received: (qmail 74569 invoked from network); 8 Aug 2003 21:22:34 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:22:34 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JEoa06997; Fri, 8 Aug 2003 15:14:50 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] comments on msec-gsakmp-sec-03.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: Fri, 8 Aug 2003 15:14:50 -0400 (EDT) Hi, I've completed a first pass review of GSAKMP. Rather than pouring all of the comments into one homungous e-mail, I will be splitting it into about two dozen smaller e-mails, each having more or less one comment/issue each and a distinct subject line. Some of these are dangling from my earlier e-mails to this list, dated July 4 and August 5th. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:33:38 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26802 for ; Fri, 8 Aug 2003 17:33:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7AE1C53767; Fri, 8 Aug 2003 17:33: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 362D053767 for ; Fri, 8 Aug 2003 17:31:28 -0400 (EDT) Received: (qmail 59625 invoked by uid 3269); 8 Aug 2003 21:31:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59622 invoked from network); 8 Aug 2003 21:31:28 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:31:28 -0000 Received: (qmail 27385 invoked from network); 8 Aug 2003 21:31:22 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:31:22 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JNd807032; Fri, 8 Aug 2003 15:23:39 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 01: GSAKMP and policy token should advance in sync to PS 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, 8 Aug 2003 15:23:38 -0400 (EDT) GSAKMP issue 01 Section and relevant text passage: The Section 2 definition of a "policy token" refers to a non-normative reference [HCLM00]. Comment/issue description: The GSAKMP protocol is strongly bound to the policy token specification. The specification currently only refers to an Internet Draft work in progress. The spec should indicate a MUST and a reference to a normative reference (i.e. RFC). In other words, GSAKMP and the group policy token must advance into the RFC editors queue in unison. Suggested issue resolution: Section 3.2 should add a new section explaining the GSAKMP dependency on the group policy token. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:34:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26826 for ; Fri, 8 Aug 2003 17:34:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B84785379C; Fri, 8 Aug 2003 17:34:15 -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 0FE095372F for ; Fri, 8 Aug 2003 17:32:24 -0400 (EDT) Received: (qmail 59698 invoked by uid 3269); 8 Aug 2003 21:32:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59695 invoked from network); 8 Aug 2003 21:32:24 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:32:24 -0000 Received: (qmail 33754 invoked from network); 8 Aug 2003 21:32:23 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:32:23 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JOdA07038; Fri, 8 Aug 2003 15:24:39 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 02: security assumptions discussion 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, 8 Aug 2003 15:24:39 -0400 (EDT) GSAKMP issue 02 Section and relevant text passage: section 3 "Security Assumptions" Comment/issue description: This section needs to add some text explaining its assumption wrt/ the multicast routing protocols, NAT, GSAKMP protocol version mismatch between GCKS and GM, and the reliable multicast transport protocols. It also should make an explicit statement about whether the trust model for "Security Suite 1" assumes that active attackers might compromise a Group Member(s) and whether the group can recover from such a compromise. Suggested issue resolution: The above topics each deserve their own sub-section 3.x. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:35:54 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26859 for ; Fri, 8 Aug 2003 17:35:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6A47A537DF; Fri, 8 Aug 2003 17:34:51 -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 3A22D537B0 for ; Fri, 8 Aug 2003 17:33:38 -0400 (EDT) Received: (qmail 59932 invoked by uid 3269); 8 Aug 2003 21:33:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59929 invoked from network); 8 Aug 2003 21:33:37 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:33:37 -0000 Received: (qmail 40344 invoked from network); 8 Aug 2003 21:33:32 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:33:32 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JPnm07044; Fri, 8 Aug 2003 15:25:49 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 03: recipient ID 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, 8 Aug 2003 15:25:49 -0400 (EDT) GSAKMP issue 03 Section and relevant text passage: section 4.2.1: "Within the GSAKMP header is a group ID. Because the member may be served by any Key Server within a group, this ID provides sufficient granularity for the recipient ID for the Request to Join message. Other messages sent by the potential member will contain the recipient ID for the GCKS serving that member." Comment/issue description: The term "recipient ID" is not previously defined, and it is not explicitly mentioned anywhere else in the document. In what namespace is the "recipient ID" allocated? Suggested issue resolution: Add an example of a "recipient ID", e.g. is it an IP-v4 address in the globally routable Internet? an X.509 D.N? point to a table defining the possible namespaces. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:36:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26890 for ; Fri, 8 Aug 2003 17:36:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CF752537BA; Fri, 8 Aug 2003 17:36: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 03A1F537BE for ; Fri, 8 Aug 2003 17:34:34 -0400 (EDT) Received: (qmail 60059 invoked by uid 3269); 8 Aug 2003 21:34:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60056 invoked from network); 8 Aug 2003 21:34:34 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:34:34 -0000 Received: (qmail 46701 invoked from network); 8 Aug 2003 21:34:32 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:34:32 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JQms07050; Fri, 8 Aug 2003 15:26:48 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 04: Process RTJ needs additional definition 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, 8 Aug 2003 15:26:48 -0400 (EDT) GSAKMP issue 04 Section and relevant text passage: section 4.2.1.1 Request to Join " If the results of indicate that the GCKS should reject the request, the session MUST be terminated..." Comment/issue description: The semantics of the section are underspecified: a. The text does not say that the GCKS should send a Notify to the GM nor does it enumerate which Notify error status could be sent. b. This section should recommend how many times the GM should resend a Request To Join and at what time out interval, before giving up after hearing no response. c. The text should explain the algorithm by which the freshness of the NONCE_I is verified. d. This section and the section that follows (4.2.1.2) make forward references to the abbreviation NONCE_I, NONCE_R, and NONCE_C, which is not defined until section 6.11. This is confusing. e. The text should explain GCKS versus GM version number mismatch semantics here. It should be possible for a v1 GSAKMP GM to interoperate and participate with a GCKS v2. Suggested issue resolution: Each of the above sub-issues should be explained in the revised text. A complete list of the error response should be given in a table. The policy token spec should also be rev'd to allow declaring a _list_ of permitted GM version numbers. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:37:19 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26921 for ; Fri, 8 Aug 2003 17:37:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 61D1F537EC; Fri, 8 Aug 2003 17:36:43 -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 1687D537BA for ; Fri, 8 Aug 2003 17:35:40 -0400 (EDT) Received: (qmail 60166 invoked by uid 3269); 8 Aug 2003 21:35:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60163 invoked from network); 8 Aug 2003 21:35:39 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:35:39 -0000 Received: (qmail 54295 invoked from network); 8 Aug 2003 21:35:38 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:35:38 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JRte07056; Fri, 8 Aug 2003 15:27:55 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 05: Key Download processing needs clarification 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, 8 Aug 2003 15:27:55 -0400 (EDT) GSAKMP issue 05 Section and relevant text passage: section 4.2.1.2 Key Download also, the text that says: "GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination." is ambiguous, as it is not clear whether "GSAKMP" in this context refers to the GCKS or the GM. Comment/issue description: The Key Download verification processing is under specified. Suggested issue resolution: Similar to what was indicated for the comment wrt/ Request To Join processing, the set of error response should be listed in a table. The nonce related verification should be described. The number of Key Download retries and timeouts should be specified. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:38:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26992 for ; Fri, 8 Aug 2003 17:38:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BA18B537BA; Fri, 8 Aug 2003 17:38: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 37AAF537DF for ; Fri, 8 Aug 2003 17:36:38 -0400 (EDT) Received: (qmail 60286 invoked by uid 3269); 8 Aug 2003 21:36:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60283 invoked from network); 8 Aug 2003 21:36:37 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:36:37 -0000 Received: (qmail 60534 invoked from network); 8 Aug 2003 21:36:36 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:36:36 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JSrF07062; Fri, 8 Aug 2003 15:28:53 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 06: GTEK synchronizaton upon new member arrival 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, 8 Aug 2003 15:28:53 -0400 (EDT) GSAKMP issue 06 Section and relevant text passage: section 4.2.2 figure 2 GSAKMP ladder diagram Comment/issue description: It is not clear from this diagram or the text how the new GM synchronizes with the new GTEK key when group policy requires backward secrecy. One interpretation is that the GCKS rekeys the group with a new key before it sends the "Key Download" to the new GM. But this is not shown in the ladder diagram. If the GCKS waits until it receives the GM Notify ACK, then it is possible in the race condition for the new GM to speak packets to the group that the group can not understand yet. Suggested issue resolution: The figure 2 ladder diagram should show when the GCKS rekeys the group relative to the new member's arrival. The text should discuss how to avoid/minimize the GTEK key synchronization problem. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:40:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27030 for ; Fri, 8 Aug 2003 17:40:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 20E9E537DD; Fri, 8 Aug 2003 17:40: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 E42BC536C2 for ; Fri, 8 Aug 2003 17:38:05 -0400 (EDT) Received: (qmail 60506 invoked by uid 3269); 8 Aug 2003 21:38:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60503 invoked from network); 8 Aug 2003 21:38:05 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:38:05 -0000 Received: (qmail 68324 invoked from network); 8 Aug 2003 21:38:03 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:38:03 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JUIb07070; Fri, 8 Aug 2003 15:30:18 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 07: Leave Group semantics unspecified 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, 8 Aug 2003 15:30:18 -0400 (EDT) GSAKMP issue 07 Section and relevant text passage: section 4.3.1 Member Joins/Leaves Comment/issue description: Hmmm.... it appears that a Group Member can never leave the group. I'm reminded of the 60's era TV spy show "The Prisoner" :o) Both the voluntary leave and member eviction cases need to be dealt with... Suggested issue resolution: Is this text cast this way because the mandatory to implement GTEK Rekey method does not support forward secrecy? Even if that is the case, since optional LKH (or other vendor specific) rekey has to be supported, then it seems reasonable to require that the GSAKMP protocol should have a "Leave Group Request" message exchange. The state diagram in section 7 should add transitions for this set of cases. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:41:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27074 for ; Fri, 8 Aug 2003 17:41:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E32BE5380F; Fri, 8 Aug 2003 17:40: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 D5727537E3 for ; Fri, 8 Aug 2003 17:39:07 -0400 (EDT) Received: (qmail 60633 invoked by uid 3269); 8 Aug 2003 21:39:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60630 invoked from network); 8 Aug 2003 21:39:07 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:39:07 -0000 Received: (qmail 74367 invoked from network); 8 Aug 2003 21:39:02 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:39:02 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JVJk07076; Fri, 8 Aug 2003 15:31:19 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 08: Group ID should allow IP-v6 and also IKE-v2 identifiers 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, 8 Aug 2003 15:31:19 -0400 (EDT) GSAKMP issue 08 Section and relevant text passage: section 6.1 GSAKMP Header, table 6 Comment/issue description: The table should be expanded to at least allow IPv6 group ID. We should consider allowing other types of ID, similar to what IKE-v2 allows. Suggested issue resolution: Add an IP-v6 multicast address and serial number. For both IP-v4 and IP-v6, explain how the serial number is generated and maintained by the GCKS such that is unique across all groups sharing that multicast address. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:43:03 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27221 for ; Fri, 8 Aug 2003 17:43:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7BB675372F; Fri, 8 Aug 2003 17:42: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 401FB5381E for ; Fri, 8 Aug 2003 17:40:16 -0400 (EDT) Received: (qmail 60798 invoked by uid 3269); 8 Aug 2003 21:40:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60790 invoked from network); 8 Aug 2003 21:40:16 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:40:16 -0000 Received: (qmail 80205 invoked from network); 8 Aug 2003 21:40:14 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:40:14 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JWVb07082; Fri, 8 Aug 2003 15:32:31 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 09: Rekey "Sequence ID" rollover semantics 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, 8 Aug 2003 15:32:31 -0400 (EDT) GSAKMP issue 09 Section and relevant text passage: 6.1 GSAKMP Header, Sequence ID text: "GCKS/SGCKS MUST also garantee that this value does not suffer from rollover problems..." Comment/issue description: s/garantee/guarantee/ Granted, this is a corner case, but the text does seem vague here. If the GCKS had the misfortune to generate an initial random Sequence ID that was close to 2^32 AND then the group was long-lived AND it had lots of rekey events, then one might have to deal with this. So what do you do? Suggested issue resolution: The text should specify that rollover is allowed, and indicate an algorithm in an appendix that would gracefully accept wrap around. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:43:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27297 for ; Fri, 8 Aug 2003 17:43:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 16439537F4; Fri, 8 Aug 2003 17:43:12 -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 901A8537E0 for ; Fri, 8 Aug 2003 17:41:27 -0400 (EDT) Received: (qmail 60981 invoked by uid 3269); 8 Aug 2003 21:41:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60978 invoked from network); 8 Aug 2003 21:41:27 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:41:27 -0000 Received: (qmail 86902 invoked from network); 8 Aug 2003 21:41:25 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:41:25 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JXg607088; Fri, 8 Aug 2003 15:33:42 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 10: GSAKMP payload header should align with IKE-v2 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, 8 Aug 2003 15:33:42 -0400 (EDT) GSAKMP issue 10 Section and relevant text passage: 6.2 Generic Payload Header Comment/issue description: The payload header should be aligned with the IKE-v2 payload header syntax and critical bit semantics. The text should indicate it follows the IKE-v2 policy with respect to padding. I would assume that GSAKMP currently does not attempt to do modulo-4 payload header alignment? (Neither does IKE-v2, but then other protocols do e.g. Diameter) The text does not say so, but I would have to guess the Payload length is in network byte order. Suggested issue resolution: The text should explicitly define the syntax and semantics wrt/ the above to match IKE-v2. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 17:47:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27416 for ; Fri, 8 Aug 2003 17:47:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 932FC537BA; Fri, 8 Aug 2003 17:46:28 -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 20623536C2 for ; Fri, 8 Aug 2003 17:45:44 -0400 (EDT) Received: (qmail 61513 invoked by uid 3269); 8 Aug 2003 21:45:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61510 invoked from network); 8 Aug 2003 21:45:43 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:45:43 -0000 Received: (qmail 13936 invoked from network); 8 Aug 2003 21:45:42 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:45:42 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JbwK07113; Fri, 8 Aug 2003 15:37:58 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 14: Rekey Event Data field's reference to appendix A.3 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, 8 Aug 2003 15:37:58 -0400 (EDT) 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 From msec-admin@securemulticast.org Fri Aug 8 17:53:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27491 for ; Fri, 8 Aug 2003 17:53:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 41219536C2; Fri, 8 Aug 2003 17:48:35 -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 A0CA653614 for ; Fri, 8 Aug 2003 17:47:40 -0400 (EDT) Received: (qmail 61754 invoked by uid 3269); 8 Aug 2003 21:47:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61751 invoked from network); 8 Aug 2003 21:47:40 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:47:40 -0000 Received: (qmail 27260 invoked from network); 8 Aug 2003 21:47:39 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:47:39 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78Jdtb07125; Fri, 8 Aug 2003 15:39:55 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 16: allow other signature types besides DSA? 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, 8 Aug 2003 15:39:55 -0400 (EDT) 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 From msec-admin@securemulticast.org Fri Aug 8 17:56:38 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27609 for ; Fri, 8 Aug 2003 17:56:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 02B295357C; Fri, 8 Aug 2003 17:49: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 1038D537F1 for ; Fri, 8 Aug 2003 17:46:51 -0400 (EDT) Received: (qmail 61639 invoked by uid 3269); 8 Aug 2003 21:46:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61636 invoked from network); 8 Aug 2003 21:46:51 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:46:51 -0000 Received: (qmail 21537 invoked from network); 8 Aug 2003 21:46:49 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:46:49 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78Jd6K07119; Fri, 8 Aug 2003 15:39:06 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 15: clarify "ID Type" field for Identification Payload 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, 8 Aug 2003 15:39:06 -0400 (EDT) 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 From msec-admin@securemulticast.org Fri Aug 8 17:57:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27644 for ; Fri, 8 Aug 2003 17:57:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AF2475380A; Fri, 8 Aug 2003 17:50: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 1D412537FD for ; Fri, 8 Aug 2003 17:48:22 -0400 (EDT) Received: (qmail 61876 invoked by uid 3269); 8 Aug 2003 21:48:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61870 invoked from network); 8 Aug 2003 21:48:21 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 8 Aug 2003 21:48:21 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn3-313.cisco.com [10.21.65.57]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h78LmHpq025916; Fri, 8 Aug 2003 14:48:18 -0700 (PDT) Message-Id: <5.1.1.5.2.20030808144729.06617e70@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] comments on msec-gsakmp-sec-03.txt Cc: In-Reply-To: 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: Fri, 08 Aug 2003 14:48:16 -0700 At 03:14 PM 8/8/2003 -0400, George Gross wrote: >Hi, > I've completed a first pass review of GSAKMP. Rather than pouring >all of the comments into one homungous e-mail, I will be splitting it into >about two dozen smaller e-mails, this was a poor choice, George >each having more or less one >comment/issue each and a distinct subject line. Some of these are dangling >from my earlier e-mails to this list, dated July 4 and August 5th. > >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 Fri Aug 8 17:58:55 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27670 for ; Fri, 8 Aug 2003 17:58:55 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8E3E253854; Fri, 8 Aug 2003 17:50:54 -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 B63CC537FD for ; Fri, 8 Aug 2003 17:48:39 -0400 (EDT) Received: (qmail 61906 invoked by uid 3269); 8 Aug 2003 21:48:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61903 invoked from network); 8 Aug 2003 21:48:39 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:48:39 -0000 Received: (qmail 33634 invoked from network); 8 Aug 2003 21:48:33 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:48:33 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JemY07133; Fri, 8 Aug 2003 15:40:48 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 17: clarify authorization roles 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, 8 Aug 2003 15:40:48 -0400 (EDT) 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 From msec-admin@securemulticast.org Fri Aug 8 17:59:55 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27715 for ; Fri, 8 Aug 2003 17:59:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4D6A453857; Fri, 8 Aug 2003 17:52: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 A3B4A53851 for ; Fri, 8 Aug 2003 17:50:10 -0400 (EDT) Received: (qmail 62057 invoked by uid 3269); 8 Aug 2003 21:50:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62054 invoked from network); 8 Aug 2003 21:50:10 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:50:10 -0000 Received: (qmail 43825 invoked from network); 8 Aug 2003 21:50:08 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:50:08 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JgJe07139; Fri, 8 Aug 2003 15:42:19 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 18: use of Notify to assist data synchronization 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, 8 Aug 2003 15:42:19 -0400 (EDT) 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 From msec-admin@securemulticast.org Fri Aug 8 18:00:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27774 for ; Fri, 8 Aug 2003 18:00:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DD6AB5386E; Fri, 8 Aug 2003 17:52:41 -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 4EC8453857 for ; Fri, 8 Aug 2003 17:51:12 -0400 (EDT) Received: (qmail 62214 invoked by uid 3269); 8 Aug 2003 21:51:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62211 invoked from network); 8 Aug 2003 21:51:12 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:51:12 -0000 Received: (qmail 48930 invoked from network); 8 Aug 2003 21:51:08 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:51:08 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JhPu07145; Fri, 8 Aug 2003 15:43:25 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 19: Notify payload type trigger conditions 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, 8 Aug 2003 15:43:24 -0400 (EDT) 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 From msec-admin@securemulticast.org Fri Aug 8 18:01:25 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27805 for ; Fri, 8 Aug 2003 18:01:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5511E53771; Fri, 8 Aug 2003 17:54: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 AC1A65387B for ; Fri, 8 Aug 2003 17:53:00 -0400 (EDT) Received: (qmail 62452 invoked by uid 3269); 8 Aug 2003 21:53:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62449 invoked from network); 8 Aug 2003 21:53:00 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:53:00 -0000 Received: (qmail 59534 invoked from network); 8 Aug 2003 21:52:59 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:52:59 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JjF507157; Fri, 8 Aug 2003 15:45:15 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 21: Pack Type should allow private/experimental use 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, 8 Aug 2003 15:45:15 -0400 (EDT) GSAKMP issue 21 Section and relevant text passage: Appendix B.2.4 Key Pack Data Comment/issue description: The "Pack Type" should reserve values for vendor specific/private/experimental use Suggested issue resolution: split off 129->255 of the Pack Type space for private use _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 18:02:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27837 for ; Fri, 8 Aug 2003 18:02:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4C52A537EC; Fri, 8 Aug 2003 17:54:17 -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 4C7E15376B for ; Fri, 8 Aug 2003 17:52:03 -0400 (EDT) Received: (qmail 62364 invoked by uid 3269); 8 Aug 2003 21:52:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62361 invoked from network); 8 Aug 2003 21:52:03 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:52:03 -0000 Received: (qmail 53885 invoked from network); 8 Aug 2003 21:52:01 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:52:01 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JiHR07151; Fri, 8 Aug 2003 15:44:17 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 20: refining the state diagram 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, 8 Aug 2003 15:44:17 -0400 (EDT) GSAKMP issue 20 Section and relevant text passage: 7. GSAKMP State Diagram table 23 Comment/issue description: The text for these transitions is too terse and understated. Suggested issue resolution: The text should elaborate, and also refer to the section that specifies exactly what happens for each transition. Transition 1a should say "Send Request To Join" group command Transition 2a should say "Receive Key Download and Send Ack" _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 18:02:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27863 for ; Fri, 8 Aug 2003 18:02:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 40D45536DE; Fri, 8 Aug 2003 17:56: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 3DEA153610 for ; Fri, 8 Aug 2003 17:54:07 -0400 (EDT) Received: (qmail 62591 invoked by uid 3269); 8 Aug 2003 21:54:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62588 invoked from network); 8 Aug 2003 21:54:07 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:54:07 -0000 Received: (qmail 65206 invoked from network); 8 Aug 2003 21:54:05 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:54:05 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JkMo07163; Fri, 8 Aug 2003 15:46:22 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 22: GTEK rekey support is a MUST 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, 8 Aug 2003 15:46:22 -0400 (EDT) GSAKMP issue 22 Section and relevant text passage: Appendix B.2.4 Pack Data Formats Comment/issue description: The text should indicate that GTEK rekey is a MUST implement capability Suggested issue resolution: s/legal/defined/ add the sentence: The GTEK Pack Type MUST be implemented. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 18:03:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27921 for ; Fri, 8 Aug 2003 18:03:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0B39C537C6; Fri, 8 Aug 2003 17:58:04 -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 2BD8D53843 for ; Fri, 8 Aug 2003 17:56:17 -0400 (EDT) Received: (qmail 62831 invoked by uid 3269); 8 Aug 2003 21:56:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62828 invoked from network); 8 Aug 2003 21:56:17 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 8 Aug 2003 21:56:17 -0000 Received: (qmail 77468 invoked from network); 8 Aug 2003 21:56:15 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.163) by mail.nac.net with SMTP; 8 Aug 2003 21:56:15 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h78JmWC07169; Fri, 8 Aug 2003 15:48:32 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 23: Vendor-ID payload 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, 8 Aug 2003 15:48:31 -0400 (EDT) GSAKMP issue 23 Section and relevant text passage: section 6 GSAKMP Payload Structure Comment/issue description: Add a section for a Vendor-ID payload, like as is defined for IKE-v2 Suggested issue resolution: We will need to set a policy that assure a Vendor does not set the "critical" bit for a vendor-specific GSAKMP extension, as that would obstruct inter-operability. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 8 22:44:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04727 for ; Fri, 8 Aug 2003 22:44:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BBD885366F; Fri, 8 Aug 2003 22:44: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 92BC953604 for ; Fri, 8 Aug 2003 22:42:21 -0400 (EDT) Received: (qmail 8223 invoked by uid 3269); 9 Aug 2003 02:42:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8220 invoked from network); 9 Aug 2003 02:42:21 -0000 Received: from tosh.netlab.uky.edu (204.198.76.200) by klesh.pair.com with SMTP; 9 Aug 2003 02:42:21 -0000 Received: from ozark.netlab.uky.edu (ozark.netlab.uky.edu [204.198.76.63]) by tosh.netlab.uky.edu (Postfix) with ESMTP id 47831CE82 for ; Fri, 8 Aug 2003 22:42:21 -0400 (EDT) From: Ken Calvert To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 07: Leave Group semantics unspecified In-Reply-To: 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: Fri, 8 Aug 2003 22:42:20 -0400 (EDT) > section 4.3.1 Member Joins/Leaves > > Comment/issue description: > > Hmmm.... it appears that a Group Member can never leave the group. I'm > reminded of the 60's era TV spy show "The Prisoner" :o) > > Both the voluntary leave and member eviction cases need to be dealt with... > > Suggested issue resolution: > > Is this text cast this way because the mandatory to > implement GTEK Rekey method does not support forward > secrecy? Even if that is the case, since optional LKH (or > other vendor specific) rekey has to be supported, then it > seems reasonable to require that the GSAKMP protocol > should have a "Leave Group Request" message exchange. The > state diagram in section 7 should add transitions for this > set of cases. More general comment: I've never really understood the connection between voluntary member departure and forward secrecy. If the member's authorization status hasn't changed from the policy point of view, why should GCKS care whether the member is still listening? I guess there might be resources (e.g. logical tree positions) the member holds that the GCKS might want to reclaim? But the tradeoffs are not clear, and it is certainly not clear to me that a "leave group request" exchange is warranted. Policy change is a different. I can see the case for an "eviction notification" more clearly... KC _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Aug 9 02:00:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08968 for ; Sat, 9 Aug 2003 02:00:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1BC3153655; Sat, 9 Aug 2003 02:00:22 -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 68FF7535FE for ; Sat, 9 Aug 2003 01:59:40 -0400 (EDT) Received: (qmail 66486 invoked by uid 3269); 9 Aug 2003 05:59:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66480 invoked from network); 9 Aug 2003 05:59:40 -0000 Received: from linux.royaleng.com (HELO linux.grifflink.com) (216.83.131.67) by klesh.pair.com with SMTP; 9 Aug 2003 05:59:40 -0000 Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h795uDsT019416; Fri, 8 Aug 2003 23:56:13 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h795wbin010576; Fri, 8 Aug 2003 23:58:37 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h795wQdc010565; Fri, 8 Aug 2003 23:58:26 -0600 Message-Id: <200308090558.h795wQdc010565@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: calvert@netlab.uky.edu Cc: msec@securemulticast.org In-reply-to: Yourmessage Subject: Re: [MSEC] GSAKMP issue 07: Leave Group semantics unspecified 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, 8 Aug 2003 23:58:26 -0600 I agree that voluntary leave does not require forward secrecy, but I suppose a member might ask for a rekey upon leaving so that she would not be accused later of having listened. Hilarie _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Aug 9 10:11:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28991 for ; Sat, 9 Aug 2003 10:11:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DED0D535A2; Sat, 9 Aug 2003 10:10: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 2372E53561 for ; Sat, 9 Aug 2003 10:08:07 -0400 (EDT) Received: (qmail 55144 invoked by uid 3269); 9 Aug 2003 14:08:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55139 invoked from network); 9 Aug 2003 14:08:06 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 9 Aug 2003 14:08:06 -0000 Received: (qmail 43647 invoked from network); 9 Aug 2003 14:08:06 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.189) by mail.nac.net with SMTP; 9 Aug 2003 14:08:06 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h79C0Eu08010; Sat, 9 Aug 2003 08:00:14 -0400 From: George Gross To: Mark Baugher Cc: George Gross , Subject: Re: [MSEC] comments on msec-gsakmp-sec-03.txt In-Reply-To: <5.1.1.5.2.20030808144729.06617e70@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: Sat, 9 Aug 2003 08:00:14 -0400 (EDT) Hi Mark, I conceed it is unorthodox to launch a volley of e-mail as I did, and normally I would not, however: - GSAKMP aspires to become PS - it is approaching working group last call (9/03 in the charter) - the list has been fairly quiet wrt/ this ID - IMHO it had many issues that would need MSEC group consenus before advancing - a separate subject line/e-mail makes it easier to track threads in the archive, and establish which ones are open or closed. this is common practice in other working groups. in the future, I'll meter out my comments at a more leisurely pace... br, George On Fri, 8 Aug 2003, Mark Baugher wrote: > At 03:14 PM 8/8/2003 -0400, George Gross wrote: > >Hi, > > I've completed a first pass review of GSAKMP. Rather than pouring > >all of the comments into one homungous e-mail, I will be splitting it into > >about two dozen smaller e-mails, > > this was a poor choice, George > > >each having more or less one > >comment/issue each and a distinct subject line. Some of these are dangling > >from my earlier e-mails to this list, dated July 4 and August 5th. > > > >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 Sat Aug 9 10:32:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29737 for ; Sat, 9 Aug 2003 10:32:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 52D585366F; Sat, 9 Aug 2003 10:32: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 0DD5753544 for ; Sat, 9 Aug 2003 10:31:45 -0400 (EDT) Received: (qmail 59219 invoked by uid 3269); 9 Aug 2003 14:31:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59216 invoked from network); 9 Aug 2003 14:31:45 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 9 Aug 2003 14:31:45 -0000 Received: (qmail 38817 invoked from network); 9 Aug 2003 14:31:43 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.189) by mail.nac.net with SMTP; 9 Aug 2003 14:31:43 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h79CNrT08308; Sat, 9 Aug 2003 08:23:53 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 00: IANA considerations 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: Sat, 9 Aug 2003 08:23:53 -0400 (EDT) Hi, This e-mail and three others inexplicably did not make it to the list (see the archive). My apologies if you receive a dupe. br, George GSAKMP issue 00 Section and relevant text passage: The document as a whole is missing a comprehensive IANA considerations section. Also the relationship of GSAKMP identifiers to similar ones found in IKE is unspecified. Comment/issue description: This is similar to the stuff found in IKE-v2 section 6, where there are numerous payload identifiers and crypto algorithms/suites referenced that need IANA to maintain the registry. WHile the spec points to IKE as its template, it is not clear whether you expect to coordinate the GSAKMP payload identifier space (or any of the other identifier spaces, see below) with IKE. Where feasible, it would make sense to either converge to a common set with the IKE-v2 set of identifiers or else use an non-colliding set of GSAKMP reserved identifiers within the IKE-v2 space. Suggested issue resolution: 1. Every one of the various tables in the GSAKMP protocol specification that define identifiers should be discussed in the IANA considerations section: - table 6 group identification types - table 7 payload types, coordinate with IKE-v2 section 3.2 - table 8 exchange types, coordinate with IKE-v2 - table 9 policy token types - table 10 key download data types - table 11 rekey event types - table 12 identification payload types, coordinate with IKE-v2 section 3.5 - table 13 certificate payload types, coordinate with IKE-v2 section 3.6 - table 14 signature types - table 15 signature ID types - table 16 authorization types - table 17 Notify payload types, coordinate with IKE-v2 section 3.10.1 - table 18 Notify status types, coordinate with IKE-v2 section 3.10.1 - table 19 acknowledgement types - table 20 key creation type - table 21 nonce type 2. The section 1.2 "Protocol Considerations" belongs as sub-section in the IANA section. This section should specify that GSAKMP is in a UDP payload. 3. The generic header payload encoding should be aligned with IKE-v2 section 3.2, and it should include the "critical" bit semantics. The GSAKMP mandated payloads should have this bit clear, as explained by the rationale in IKE-v2. 4. All of the above identifier/type tables in GSAKMP should have a portion of their identifier space reserved for private/experimental use between consenting parties _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Aug 9 10:34:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29777 for ; Sat, 9 Aug 2003 10:34:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 349BC5364B; Sat, 9 Aug 2003 10: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 B75CB535FB for ; Sat, 9 Aug 2003 10:33:27 -0400 (EDT) Received: (qmail 59421 invoked by uid 3269); 9 Aug 2003 14:33:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59418 invoked from network); 9 Aug 2003 14:33:27 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 9 Aug 2003 14:33:27 -0000 Received: (qmail 45608 invoked from network); 9 Aug 2003 14:33:26 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.189) by mail.nac.net with SMTP; 9 Aug 2003 14:33:26 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h79CPZZ08314; Sat, 9 Aug 2003 08:25:35 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 11: policy token payload digital signature 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: Sat, 9 Aug 2003 08:25:35 -0400 (EDT) 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 From msec-admin@securemulticast.org Sat Aug 9 10:36:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29839 for ; Sat, 9 Aug 2003 10:36:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DF3A35364B; Sat, 9 Aug 2003 10:36:04 -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 E7EDA5364B for ; Sat, 9 Aug 2003 10:35:27 -0400 (EDT) Received: (qmail 59714 invoked by uid 3269); 9 Aug 2003 14:35:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59711 invoked from network); 9 Aug 2003 14:35:27 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 9 Aug 2003 14:35:27 -0000 Received: (qmail 53308 invoked from network); 9 Aug 2003 14:35:26 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.189) by mail.nac.net with SMTP; 9 Aug 2003 14:35:26 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h79CRa708321; Sat, 9 Aug 2003 08:27:36 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 12: Policy Token Payload table 9 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: Sat, 9 Aug 2003 08:27:36 -0400 (EDT) 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 From msec-admin@securemulticast.org Sat Aug 9 10:38:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29883 for ; Sat, 9 Aug 2003 10:38:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5426C536BE; Sat, 9 Aug 2003 10:38:17 -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 4B68A53684 for ; Sat, 9 Aug 2003 10:36:47 -0400 (EDT) Received: (qmail 59832 invoked by uid 3269); 9 Aug 2003 14:36:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59829 invoked from network); 9 Aug 2003 14:36:47 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 9 Aug 2003 14:36:47 -0000 Received: (qmail 58271 invoked from network); 9 Aug 2003 14:36:46 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.189) by mail.nac.net with SMTP; 9 Aug 2003 14:36:46 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h79CStD08327; Sat, 9 Aug 2003 08:28:55 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 13: Rekey Event Payload "ID Type" field 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: Sat, 9 Aug 2003 08:28:55 -0400 (EDT) 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. In table 11, when is "Group Recovery" specified versus "Maintenance"? 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 From msec-admin@securemulticast.org Sat Aug 9 13:04:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02044 for ; Sat, 9 Aug 2003 13:04:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6F857535A2; Sat, 9 Aug 2003 13:04:12 -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 E3DD75354C for ; Sat, 9 Aug 2003 13:03:09 -0400 (EDT) Received: (qmail 80047 invoked by uid 3269); 9 Aug 2003 17:03:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80044 invoked from network); 9 Aug 2003 17:03:09 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 9 Aug 2003 17:03:09 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn3-253.cisco.com [10.21.64.253]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h79H36uH029191; Sat, 9 Aug 2003 10:03:07 -0700 (PDT) Message-Id: <5.1.1.5.2.20030809095541.06727ea0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] comments on msec-gsakmp-sec-03.txt Cc: In-Reply-To: References: <5.1.1.5.2.20030808144729.06617e70@mira-sjc5-6.cisco.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: Sat, 09 Aug 2003 10:03:06 -0700 George I think there is no real issue here. I should have included a smiley face with my comment. Mark At 08:00 AM 8/9/2003 -0400, George Gross wrote: >Hi Mark, > > I conceed it is unorthodox to launch a volley of e-mail as I did, >and normally I would not, however: > > - GSAKMP aspires to become PS > - it is approaching working group last call (9/03 in the charter) > - the list has been fairly quiet wrt/ this ID > - IMHO it had many issues that would need MSEC group consenus before >advancing > - a separate subject line/e-mail makes it easier to track threads in the >archive, and establish which ones are open or closed. this is common >practice in other working groups. > >in the future, I'll meter out my comments at a more leisurely pace... > >br, > George > >On Fri, 8 Aug 2003, Mark Baugher wrote: > > > At 03:14 PM 8/8/2003 -0400, George Gross wrote: > > >Hi, > > > I've completed a first pass review of GSAKMP. Rather than pouring > > >all of the comments into one homungous e-mail, I will be splitting it into > > >about two dozen smaller e-mails, > > > > this was a poor choice, George > > > > >each having more or less one > > >comment/issue each and a distinct subject line. Some of these are dangling > > >from my earlier e-mails to this list, dated July 4 and August 5th. > > > > > >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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 11 09:34:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15542 for ; Mon, 11 Aug 2003 09:34:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 37A57536D0; Mon, 11 Aug 2003 09:34: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 6612253647 for ; Mon, 11 Aug 2003 09:33:47 -0400 (EDT) Received: (qmail 28167 invoked by uid 3269); 11 Aug 2003 13:33:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28164 invoked from network); 11 Aug 2003 13:33:47 -0000 Received: from tosh.netlab.uky.edu (204.198.76.200) by klesh.pair.com with SMTP; 11 Aug 2003 13:33:47 -0000 Received: from ozark.netlab.uky.edu (ozark.netlab.uky.edu [204.198.76.63]) by tosh.netlab.uky.edu (Postfix) with ESMTP id E9C26CE99 for ; Mon, 11 Aug 2003 09:33:46 -0400 (EDT) From: Ken Calvert To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 07: Leave Group semantics unspecified In-Reply-To: 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: Mon, 11 Aug 2003 09:33:46 -0400 (EDT) On Sat, 9 Aug 2003, George Gross wrote: > an example use case is an interactive gaming group with the $ > meter running for every minute consumed. > So in that case the member is really asking that the policy be changed (so she doesn't get charged). Should policy-change mechanisms (like the proposed LEAVE request) be part of the key-management protocol? I would argue that they should not, just due to the amount of application-variability. For example, in the above example the departing member may want a signed/timestamped confirmation that the policy has been changed, but that may not be true in all cases. KC _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 11 10:34:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18446 for ; Mon, 11 Aug 2003 10:34:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 45374535AB; Mon, 11 Aug 2003 10: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 E1D6B5354E for ; Mon, 11 Aug 2003 10:33:48 -0400 (EDT) Received: (qmail 37873 invoked by uid 3269); 11 Aug 2003 14:33:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37866 invoked from network); 11 Aug 2003 14:33:48 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 11 Aug 2003 14:33:48 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BEXjb27930; Mon, 11 Aug 2003 10:33:45 -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 3ZF0RC6K; Mon, 11 Aug 2003 10:33:44 -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 3ZF93616; Mon, 11 Aug 2003 10:33:44 -0400 Message-ID: <3F37A948.3090509@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] GSAKMP issue 01: GSAKMP and policy token should advance in sync to PS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: Mon, 11 Aug 2003 10:33:44 -0400 Content-Transfer-Encoding: 7bit We have had a discussion on this at the meeting in Vienna. From the meeting notes: Thomas: A possible way forward would be to define a "base-profile" for the token containing fields common to the various key management protocols. Area-specific needs would then be satisfied by adding additional fields ("extensions") to the Token. George, Would that be sufficient in your opinion? cheers, Lakshminath George Gross wrote: >GSAKMP issue 01 > >Section and relevant text passage: > >The Section 2 definition of a "policy token" refers to a non-normative >reference [HCLM00]. > >Comment/issue description: > >The GSAKMP protocol is strongly bound to the policy token specification. The specification >currently only refers to an Internet Draft work in progress. The spec should indicate a MUST >and a reference to a normative reference (i.e. RFC). In other words, GSAKMP and the group >policy token must advance into the RFC editors queue in unison. > >Suggested issue resolution: > >Section 3.2 should add a new section explaining the GSAKMP dependency on the group policy token. > > >_______________________________________________ >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 Mon Aug 11 10: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 KAA19345 for ; Mon, 11 Aug 2003 10:58:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 704A25360C; Mon, 11 Aug 2003 10:58: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 2452353600 for ; Mon, 11 Aug 2003 10:56:21 -0400 (EDT) Received: (qmail 41163 invoked by uid 3269); 11 Aug 2003 14:56:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41160 invoked from network); 11 Aug 2003 14:56:21 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 11 Aug 2003 14:56:21 -0000 Received: (qmail 35333 invoked from network); 11 Aug 2003 14:56:19 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.181) by mail.nac.net with SMTP; 11 Aug 2003 14:56:19 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7BCm7E16729; Mon, 11 Aug 2003 08:48:07 -0400 From: George Gross To: Ken Calvert Cc: Subject: Re: [MSEC] GSAKMP issue 07: Leave Group semantics unspecified In-Reply-To: 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: Mon, 11 Aug 2003 08:48:07 -0400 (EDT) Hi, inline.... br, George On Mon, 11 Aug 2003, Ken Calvert wrote: > > On Sat, 9 Aug 2003, George Gross wrote: > > > an example use case is an interactive gaming group with the $ > > meter running for every minute consumed. > > > > So in that case the member is really asking that > the policy be changed (so she doesn't get charged). I don't see a policy change here, just a membership set change to assure that she does not continue to watch content that was not paid for. The group key changes, but not the group's policy. > > Should policy-change mechanisms (like the proposed LEAVE > request) be part of the key-management protocol? I would > argue that they should not, just due to the amount of > application-variability. I do not see things the same way as you ;o) MPOV: The protocol is incomplete and not interoperable until it adds a basic "leave group" mechanism that covers the cases discussed below. If the application doesn't ever need members to leave, they don't use the leave mechanism. But omitting definition of the mechanism is a sure way to promote non-inter-operability between those implementations that need that capability. Note that GSAKMP is a network layer service, and by definition it must have the versatility to serve such a diverse set of application layer requirements. The application requirements boil down to three cases: 1. no "leave group" events are reported to the GCKS 2. Leave Group Request and its ACK are authenticated by the registration SA keying material, with the implied SA state storage requirement 3. Leave Group Request is authenticated by digital signature by the GM and the GCKS for the ACK messages in the exchange. No SA state storage. Your commment does identify the requirement on the Group Policy Token to express the leave group policy, with an enumerated value for each of the above cases. > For example, in the above example > the departing member may want a signed/timestamped > confirmation that the policy has been changed, but that may > not be true in all cases. If the GCKS sends the former group member an "ACK" for their "leave group request" then the exchange could be authenticated by the registration SA key known only to the GCKS and the group member. That way the former group member has basic assurance that the $ meter stopped. In the case you bring up, if "receipt requested" flag was set on the Leave Group Request (or in the group policy) then the ACK could include the GCKS signature on a nonce or notarized timestamp supplied by the Leave Group Request. The GCKS could include its own notarized timestamp in the ACK if group policy required it. However.... I think the above extra steps for a timstamped receipt that supports non-repudiation in a court of law are an example of extensions beyond the base specification. The base specification MUST have a Leave Group Request/Ack exchange. This is an example of an engineering decision that assures inter-operability across a wide cross section of use cases, and yet it leaves room for future standardization as the market matures. FWIW, At a certain point, it becomes a credit card dispute, and in all the disputes I've had with Internet based vendors to date, the case was resolved without the credit card company needing a timestamped digital signature ;o) > > KC > > > _______________________________________________ > 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 Mon Aug 11 11:29:48 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20289 for ; Mon, 11 Aug 2003 11:29:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9C080535DB; Mon, 11 Aug 2003 11:29: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 081F653533 for ; Mon, 11 Aug 2003 11:27:01 -0400 (EDT) Received: (qmail 46767 invoked by uid 3269); 11 Aug 2003 15:27:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46764 invoked from network); 11 Aug 2003 15:27:00 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 11 Aug 2003 15:27:00 -0000 Received: (qmail 96154 invoked from network); 11 Aug 2003 15:26:58 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.181) by mail.nac.net with SMTP; 11 Aug 2003 15:26:58 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7BDIkF16775; Mon, 11 Aug 2003 09:18:46 -0400 From: George Gross To: Lakshminath Dondeti Cc: George Gross , Subject: Re: [MSEC] GSAKMP issue 01: GSAKMP and policy token should advance in sync to PS In-Reply-To: <3F37A948.3090509@americasm06.nt.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: Mon, 11 Aug 2003 09:18:46 -0400 (EDT) Hi Lakshminath, On Mon, 11 Aug 2003, Lakshminath Dondeti wrote: > We have had a discussion on this at the meeting in Vienna. > > From the meeting notes: > > Thomas: A possible way forward would be to define a "base-profile" > for the token containing fields common to the various key management > protocols. Area-specific needs would then be satisfied by adding > additional fields ("extensions") to the Token. > > George, > > Would that be sufficient in your opinion? It is a start in the right direction. however, some things are missing from that statement. Like in which document do the "GSAKMP-specific extensions" get specified? Naturally, I'd like to see all the issues I've raised (and for that matter, anyone else on the list can chime in) wrt/ GSAKMP brought to closure, so we know exactly what changes to the GPT are required before it advances to PS. Having just a base GPT document goto PS by itself is not enough for GSAKMP to advance to PS unless the GSAKMP spec includes its GPT extensions or it else explicitly states that it requires no extensions to the base GPT. know this sounds finicky, but I'm trying to avoid surprizes... > > cheers, > Lakshminath > > George Gross wrote: > > >GSAKMP issue 01 > > > >Section and relevant text passage: > > > >The Section 2 definition of a "policy token" refers to a non-normative > >reference [HCLM00]. > > > >Comment/issue description: > > > >The GSAKMP protocol is strongly bound to the policy token specification. The specification > >currently only refers to an Internet Draft work in progress. The spec should indicate a MUST > >and a reference to a normative reference (i.e. RFC). In other words, GSAKMP and the group > >policy token must advance into the RFC editors queue in unison. > > > >Suggested issue resolution: > > > >Section 3.2 should add a new section explaining the GSAKMP dependency on the group policy token. > > > > > >_______________________________________________ > >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 Mon Aug 11 11:53:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20855 for ; Mon, 11 Aug 2003 11:53:16 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3F5C25370F; Mon, 11 Aug 2003 11:52:51 -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 A484053533 for ; Mon, 11 Aug 2003 11:40:52 -0400 (EDT) Received: (qmail 50218 invoked by uid 3269); 11 Aug 2003 15:40:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50215 invoked from network); 11 Aug 2003 15:40:47 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 11 Aug 2003 15:40:47 -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 h7BFein17318; Mon, 11 Aug 2003 11:40:44 -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 3ZF0RDW4; Mon, 11 Aug 2003 11:40:43 -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 3ZF936KZ; Mon, 11 Aug 2003 11:40:43 -0400 Message-ID: <3F37B8FA.9050904@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] GSAKMP issue 01: GSAKMP and policy token should advance in sync to PS 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: Mon, 11 Aug 2003 11:40:43 -0400 Content-Transfer-Encoding: 7bit My recollection is that base-profile will be in the GSAKMP document. Thomas or Hugh might have a more definitive answer. regards, Lakshminath George Gross wrote: >Hi Lakshminath, > >On Mon, 11 Aug 2003, Lakshminath Dondeti wrote: > > > >>We have had a discussion on this at the meeting in Vienna. >> >> From the meeting notes: >> >> Thomas: A possible way forward would be to define a "base-profile" >> for the token containing fields common to the various key management >> protocols. Area-specific needs would then be satisfied by adding >> additional fields ("extensions") to the Token. >> >>George, >> >>Would that be sufficient in your opinion? >> >> > >It is a start in the right direction. however, some things are missing >from that statement. Like in which document do the "GSAKMP-specific >extensions" get specified? > >Naturally, I'd like to see all the issues I've raised (and for that >matter, anyone else on the list can chime in) wrt/ GSAKMP brought to >closure, so we know exactly what changes to the GPT are required before it >advances to PS. > >Having just a base GPT document goto PS by itself is not enough for GSAKMP >to advance to PS unless the GSAKMP spec includes its GPT extensions or it >else explicitly states that it requires no extensions to the base GPT. > > know this sounds finicky, but I'm trying to avoid surprizes... > > > > > >>cheers, >>Lakshminath >> >>George Gross wrote: >> >> >> >>>GSAKMP issue 01 >>> >>>Section and relevant text passage: >>> >>>The Section 2 definition of a "policy token" refers to a non-normative >>>reference [HCLM00]. >>> >>>Comment/issue description: >>> >>>The GSAKMP protocol is strongly bound to the policy token specification. The specification >>>currently only refers to an Internet Draft work in progress. The spec should indicate a MUST >>>and a reference to a normative reference (i.e. RFC). In other words, GSAKMP and the group >>>policy token must advance into the RFC editors queue in unison. >>> >>>Suggested issue resolution: >>> >>>Section 3.2 should add a new section explaining the GSAKMP dependency on the group policy token. >>> >>> >>>_______________________________________________ >>>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 Mon Aug 11 12:07:06 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21255 for ; Mon, 11 Aug 2003 12:07:05 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E2AE2535AB; Mon, 11 Aug 2003 12:06: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 0ADF65358F for ; Mon, 11 Aug 2003 12:03:46 -0400 (EDT) Received: (qmail 53139 invoked by uid 3269); 11 Aug 2003 16:03:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53136 invoked from network); 11 Aug 2003 16:03:44 -0000 Received: from pigeon.verisign.com (65.205.251.71) by klesh.pair.com with SMTP; 11 Aug 2003 16:03:44 -0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h7BG2hOQ017973; Mon, 11 Aug 2003 09:02:43 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 09:02:43 -0700 Message-ID: <9F4EAC17FAE99D4AB9CB27A54D86AD8B02C2979B@vhqpostal3.verisign.com> From: "Hardjono, Thomas" To: "'Lakshminath Dondeti'" , George Gross Cc: msec@securemulticast.org Subject: RE: [MSEC] GSAKMP issue 01: GSAKMP and policy token should advanc e in sync to PS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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, 11 Aug 2003 09:02:40 -0700 If the base-profile is going to be shared across various key management protocols, would it make sense to separate it (or include it into the Policy Token draft)? thomas ------ > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@nortelnetworks.com] > Sent: Monday, August 11, 2003 11:41 AM > To: George Gross > Cc: msec@securemulticast.org > Subject: Re: [MSEC] GSAKMP issue 01: GSAKMP and policy token > should advance in sync to PS > > > My recollection is that base-profile will be in the GSAKMP document. > Thomas or Hugh might have a more definitive answer. > > regards, > Lakshminath > > George Gross wrote: > > >Hi Lakshminath, > > > >On Mon, 11 Aug 2003, Lakshminath Dondeti wrote: > > > > > > > >>We have had a discussion on this at the meeting in Vienna. > >> > >> From the meeting notes: > >> > >> Thomas: A possible way forward would be to define a "base-profile" > >> for the token containing fields common to the various > key management > >> protocols. Area-specific needs would then be satisfied by adding > >> additional fields ("extensions") to the Token. > >> > >>George, > >> > >>Would that be sufficient in your opinion? > >> > >> > > > >It is a start in the right direction. however, some things > are missing > >from that statement. Like in which document do the "GSAKMP-specific > >extensions" get specified? > > > >Naturally, I'd like to see all the issues I've raised (and for that > >matter, anyone else on the list can chime in) wrt/ GSAKMP brought to > >closure, so we know exactly what changes to the GPT are > required before > >it advances to PS. > > > >Having just a base GPT document goto PS by itself is not enough for > >GSAKMP to advance to PS unless the GSAKMP spec includes its GPT > >extensions or it else explicitly states that it requires no > extensions > >to the base GPT. > > > > know this sounds finicky, but I'm trying to avoid surprizes... > > > > > > > > > > >>cheers, > >>Lakshminath > >> > >>George Gross wrote: > >> > >> > >> > >>>GSAKMP issue 01 > >>> > >>>Section and relevant text passage: > >>> > >>>The Section 2 definition of a "policy token" refers to a > >>>non-normative reference [HCLM00]. > >>> > >>>Comment/issue description: > >>> > >>>The GSAKMP protocol is strongly bound to the policy token > >>>specification. The specification currently only refers to > an Internet > >>>Draft work in progress. The spec should indicate a MUST and a > >>>reference to a normative reference (i.e. RFC). In other > words, GSAKMP > >>>and the group policy token must advance into the RFC > editors queue in > >>>unison. > >>> > >>>Suggested issue resolution: > >>> > >>>Section 3.2 should add a new section explaining the GSAKMP > dependency > >>>on the group policy token. > >>> > >>> > >>>_______________________________________________ > >>>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 Mon Aug 11 12:17:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21610 for ; Mon, 11 Aug 2003 12:17:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1E2DA535E8; Mon, 11 Aug 2003 12:15: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 7A2B753603 for ; Mon, 11 Aug 2003 12:13:33 -0400 (EDT) Received: (qmail 55261 invoked by uid 3269); 11 Aug 2003 16:13:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55258 invoked from network); 11 Aug 2003 16:13:13 -0000 Received: from smtp011.mail.yahoo.com (216.136.173.31) by klesh.pair.com with SMTP; 11 Aug 2003 16:13:13 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@66.30.225.187 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Aug 2003 16:13:12 -0000 Message-Id: <5.2.1.1.2.20030811121240.031c2db8@vhqpostal3.verisign.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Mark Baugher , George Gross From: Thomas Hardjono Subject: Re: [MSEC] comments on msec-gsakmp-sec-03.txt Cc: msec@securemulticast.org In-Reply-To: <5.1.1.5.2.20030809095541.06727ea0@mira-sjc5-6.cisco.com> References: <5.1.1.5.2.20030808144729.06617e70@mira-sjc5-6.cisco.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: Mon, 11 Aug 2003 12:13:09 -0400 Mark, Actually, I agree with George. Splitting the issues into separate threads may be a better approach. It seems to work in other WGs (e.g. EAP WG). It also allows the GSAKMP authors to focus per issue. thomas ------ At 8/9/2003||10:03 AM, Mark Baugher wrote: >George > I think there is no real issue here. I should have included a smiley > face with my comment. > >Mark > >At 08:00 AM 8/9/2003 -0400, George Gross wrote: >>Hi Mark, >> >> I conceed it is unorthodox to launch a volley of e-mail as I did, >>and normally I would not, however: >> >> - GSAKMP aspires to become PS >> - it is approaching working group last call (9/03 in the charter) >> - the list has been fairly quiet wrt/ this ID >> - IMHO it had many issues that would need MSEC group consenus before >>advancing >> - a separate subject line/e-mail makes it easier to track threads in the >>archive, and establish which ones are open or closed. this is common >>practice in other working groups. >> >>in the future, I'll meter out my comments at a more leisurely pace... >> >>br, >> George >> >>On Fri, 8 Aug 2003, Mark Baugher wrote: >> >> > At 03:14 PM 8/8/2003 -0400, George Gross wrote: >> > >Hi, >> > > I've completed a first pass review of GSAKMP. Rather than >> pouring >> > >all of the comments into one homungous e-mail, I will be splitting it >> into >> > >about two dozen smaller e-mails, >> > >> > this was a poor choice, George >> > >> > >each having more or less one >> > >comment/issue each and a distinct subject line. Some of these are >> dangling >> > >from my earlier e-mails to this list, dated July 4 and August 5th. >> > > >> > >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 > > > >_______________________________________________ >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 Mon Aug 11 12:20:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21703 for ; Mon, 11 Aug 2003 12:20:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F423A5360C; Mon, 11 Aug 2003 12:19:47 -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 5372E535CC for ; Mon, 11 Aug 2003 12:05:51 -0400 (EDT) Received: (qmail 53427 invoked by uid 3269); 11 Aug 2003 16:05:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53424 invoked from network); 11 Aug 2003 16:05:51 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 11 Aug 2003 16:05:51 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7BG5kil016491; Mon, 11 Aug 2003 09:05:46 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.21 [10.26.128.21]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQ0H4FF5; Mon, 11 Aug 2003 09:05:46 -0700 Message-Id: <5.2.1.1.2.20030811120348.02cec528@vhqpostal3.verisign.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Mark Baugher , George Gross From: Thomas Hardjono Subject: Re: [MSEC] comments on msec-gsakmp-sec-03.txt Cc: In-Reply-To: <5.1.1.5.2.20030809095541.06727ea0@mira-sjc5-6.cisco.com> References: <5.1.1.5.2.20030808144729.06617e70@mira-sjc5-6.cisco.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: Mon, 11 Aug 2003 12:05:37 -0400 Mark, Actually, I agree with George. Splitting the issues into separate threads may be a better approach. It seems to work in other WGs (e.g. EAP WG). It also allows the GSAKMP authors to focus per issue. thomas ------ At 8/9/2003||10:03 AM, Mark Baugher wrote: >George > I think there is no real issue here. I should have included a smiley > face with my comment. > >Mark > >At 08:00 AM 8/9/2003 -0400, George Gross wrote: >>Hi Mark, >> >> I conceed it is unorthodox to launch a volley of e-mail as I did, >>and normally I would not, however: >> >> - GSAKMP aspires to become PS >> - it is approaching working group last call (9/03 in the charter) >> - the list has been fairly quiet wrt/ this ID >> - IMHO it had many issues that would need MSEC group consenus before >>advancing >> - a separate subject line/e-mail makes it easier to track threads in the >>archive, and establish which ones are open or closed. this is common >>practice in other working groups. >> >>in the future, I'll meter out my comments at a more leisurely pace... >> >>br, >> George >> >>On Fri, 8 Aug 2003, Mark Baugher wrote: >> >> > At 03:14 PM 8/8/2003 -0400, George Gross wrote: >> > >Hi, >> > > I've completed a first pass review of GSAKMP. Rather than >> pouring >> > >all of the comments into one homungous e-mail, I will be splitting it >> into >> > >about two dozen smaller e-mails, >> > >> > this was a poor choice, George >> > >> > >each having more or less one >> > >comment/issue each and a distinct subject line. Some of these are >> dangling >> > >from my earlier e-mails to this list, dated July 4 and August 5th. >> > > >> > >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 > > > >_______________________________________________ >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 Aug 12 05:41:00 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06490 for ; Tue, 12 Aug 2003 05:41:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6C0C953774; Tue, 12 Aug 2003 05:40: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 265B953704 for ; Tue, 12 Aug 2003 05:39:37 -0400 (EDT) Received: (qmail 54060 invoked by uid 3269); 12 Aug 2003 09:39:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54057 invoked from network); 12 Aug 2003 09:39:36 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 12 Aug 2003 09:39:36 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h7C9dY000651; Tue, 12 Aug 2003 11:39:34 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h7C9dYO12298; Tue, 12 Aug 2003 11:39:34 +0200 (MEST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA00536; Tue, 12 Aug 2003 11:38:19 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 11:38:53 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7023B841E@mchh2a8e.mchh.siemens.de> From: Euchner Martin To: "'Fredrik Lindholm (KI/EAB)'" , Euchner Martin , msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] Responder-initiated TGK re-keying/CSB updating allowed in MIKEY? 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, 12 Aug 2003 11:38:52 +0200 Dear experts, MIKEY-07 describes means how the initiator can update the CSB or re-key the TGK (see section 4.5). Questions are: What about responder-initiated key update etc where the responder requests key update actions from the initiator? Is this possible using MIKEY? Is that something that can be done with some non-MIKEY (request) message from the responder to the initiator? I believe yes, but 1) it's non-standard and 2) yields a 2- or 3-way handshake. Is some role change during an active CSB allowed where the responder takes over the initiator role for the purpose of key updating? Would that really work? My understanding is, that the initiator or responder roles are static throughout the lifetime of the protocol instantiation. The definition in 1.3 is not entirely precise about that, but I infer this more from statements like "...This is done by executing the transport/exchange phase once again to obtain a new TGK (....". With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 12 10:45:20 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17571 for ; Tue, 12 Aug 2003 10:45:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CA68E53704; Tue, 12 Aug 2003 10:44:28 -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 F06D253704 for ; Tue, 12 Aug 2003 10:42:19 -0400 (EDT) Received: (qmail 98417 invoked by uid 3269); 12 Aug 2003 14:42:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98414 invoked from network); 12 Aug 2003 14:42:20 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 12 Aug 2003 14:42:19 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h7CEf2JD007286; Tue, 12 Aug 2003 09:41:02 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h7CEgHk5032143; Tue, 12 Aug 2003 09:42:17 -0500 Received: from communityuse (communityuse.columbia.sparta.com [157.185.80.60]) by columbia.sparta.com (8.9.1a/8.9.1) with SMTP id KAA09318; Tue, 12 Aug 2003 10:42:16 -0400 (EDT) Message-ID: <017801c360df$ed343120$3c50b99d@communityuse> From: "Hugh Harney" To: "George Gross" , References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [MSEC] George's comments / splitting token from protocol 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, 12 Aug 2003 10:42:15 -0400 Content-Transfer-Encoding: 7bit George, Given the number of comments and detailed nature it will take a few days for us to respond. We appreciate the detailed analysis you put into this effort and we plan on addressing all your comments. I will address your first comment now. We struggled the decision to split the GSAKMP Policy Token into it's own draft. We decided to do this for two reasons. First, The token specificaiton can and will change as the GSAKMP is used to support more and more applications. We wanted to allow the Policy Token RFC to evolve at a different rate than the protocol spec. Second, the current I-D GSAKMP Policy Token Spec will probably be aimed at becoming an experimental RFC. The original GSAKMP implementations use it to specify the security policy. However, in the future GSAKMP could use a number of policy tokens or frameworks as they become more developed. Specification of the Policy Token within the Protocol Spec could hinder adaptation of GSAKMP to other security policy mechanisms. Third, the GSAKMP Policy Token could be used by other protocols if there is a similar need for a security policy definition. We wrote the GSAKMP security policy token to contain branching fields that would allow other implementors to use it. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 12 10:57:28 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17853 for ; Tue, 12 Aug 2003 10:57:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5B5EA53612; Tue, 12 Aug 2003 10:56: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 63CA45357E for ; Tue, 12 Aug 2003 10:54:44 -0400 (EDT) Received: (qmail 202 invoked by uid 3269); 12 Aug 2003 14:54:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 198 invoked from network); 12 Aug 2003 14:54:44 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 12 Aug 2003 14:54:44 -0000 Received: (qmail 71540 invoked from network); 12 Aug 2003 14:54:42 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.165) by mail.nac.net with SMTP; 12 Aug 2003 14:54:42 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7CCkLK20216; Tue, 12 Aug 2003 08:46:21 -0400 From: George Gross To: "Hardjono, Thomas" Cc: "'Lakshminath Dondeti'" , George Gross , Subject: RE: [MSEC] GSAKMP issue 01: GSAKMP and policy token should advanc e in sync to PS In-Reply-To: <9F4EAC17FAE99D4AB9CB27A54D86AD8B02C2979B@vhqpostal3.verisign.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: Tue, 12 Aug 2003 08:46:21 -0400 (EDT) Hi Thomas, On Mon, 11 Aug 2003, Hardjono, Thomas wrote: > > If the base-profile is going to be shared across various key management > protocols, would it make sense to separate it (or include it into the Policy > Token draft)? If the policy token is gonna be extensible across various key management protocols and future flavors of group policy parameters then it will need to move to a TLV header form of encoding. As for the base profile, my first inclination is to do something analogous in spirit as: draft-ietf-ipsec-ikev2-algorithms-02.txt in that the existing policy token spec that would enumerate the MUST/SHOULD/MAY values for every policy token TLV parameter. The base profile would be the combination of MUSTs from that definition naturally. Incidently, I think the set of MSEC MUST/SHOULD encryption and authentication algorithms would do well to match IKE-v2, and also add AES-CCM, AES-CTR. The RC4 and RC2 algorithms got discussed on IPSEC list awhile ago, and got dropped. So I think I'd like to hear from Hugh et al what they think... br, George > > thomas > ------ > > > -----Original Message----- > > From: Lakshminath Dondeti [mailto:ldondeti@nortelnetworks.com] > > Sent: Monday, August 11, 2003 11:41 AM > > To: George Gross > > Cc: msec@securemulticast.org > > Subject: Re: [MSEC] GSAKMP issue 01: GSAKMP and policy token > > should advance in sync to PS > > > > > > My recollection is that base-profile will be in the GSAKMP document. > > Thomas or Hugh might have a more definitive answer. > > > > regards, > > Lakshminath > > > > George Gross wrote: > > > > >Hi Lakshminath, > > > > > >On Mon, 11 Aug 2003, Lakshminath Dondeti wrote: > > > > > > > > > > > >>We have had a discussion on this at the meeting in Vienna. > > >> > > >> From the meeting notes: > > >> > > >> Thomas: A possible way forward would be to define a "base-profile" > > >> for the token containing fields common to the various > > key management > > >> protocols. Area-specific needs would then be satisfied by adding > > >> additional fields ("extensions") to the Token. > > >> > > >>George, > > >> > > >>Would that be sufficient in your opinion? > > >> > > >> > > > > > >It is a start in the right direction. however, some things > > are missing > > >from that statement. Like in which document do the "GSAKMP-specific > > >extensions" get specified? > > > > > >Naturally, I'd like to see all the issues I've raised (and for that > > >matter, anyone else on the list can chime in) wrt/ GSAKMP brought to > > >closure, so we know exactly what changes to the GPT are > > required before > > >it advances to PS. > > > > > >Having just a base GPT document goto PS by itself is not enough for > > >GSAKMP to advance to PS unless the GSAKMP spec includes its GPT > > >extensions or it else explicitly states that it requires no > > extensions > > >to the base GPT. > > > > > > know this sounds finicky, but I'm trying to avoid surprizes... > > > > > > > > > > > > > > > >>cheers, > > >>Lakshminath > > >> > > >>George Gross wrote: > > >> > > >> > > >> > > >>>GSAKMP issue 01 > > >>> > > >>>Section and relevant text passage: > > >>> > > >>>The Section 2 definition of a "policy token" refers to a > > >>>non-normative reference [HCLM00]. > > >>> > > >>>Comment/issue description: > > >>> > > >>>The GSAKMP protocol is strongly bound to the policy token > > >>>specification. The specification currently only refers to > > an Internet > > >>>Draft work in progress. The spec should indicate a MUST and a > > >>>reference to a normative reference (i.e. RFC). In other > > words, GSAKMP > > >>>and the group policy token must advance into the RFC > > editors queue in > > >>>unison. > > >>> > > >>>Suggested issue resolution: > > >>> > > >>>Section 3.2 should add a new section explaining the GSAKMP > > dependency > > >>>on the group policy token. > > >>> > > >>> > > >>>_______________________________________________ > > >>>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 > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 12 11:20:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18597 for ; Tue, 12 Aug 2003 11:20:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 565455364D; Tue, 12 Aug 2003 11:20: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 02D005364D for ; Tue, 12 Aug 2003 11:19:57 -0400 (EDT) Received: (qmail 4883 invoked by uid 3269); 12 Aug 2003 15:19:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4880 invoked from network); 12 Aug 2003 15:19:57 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 12 Aug 2003 15:19:57 -0000 Received: (qmail 66417 invoked from network); 12 Aug 2003 15:19:56 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.165) by mail.nac.net with SMTP; 12 Aug 2003 15:19:56 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7CDBYh20528; Tue, 12 Aug 2003 09:11:34 -0400 From: George Gross To: Hugh Harney Cc: George Gross , Subject: Re: [MSEC] George's comments / splitting token from protocol In-Reply-To: <017801c360df$ed343120$3c50b99d@communityuse> 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: Tue, 12 Aug 2003 09:11:34 -0400 (EDT) Hi Hugh, our e-mails crossed paths! see inline below... br, George On Tue, 12 Aug 2003, Hugh Harney wrote: > George, > > Given the number of comments and detailed nature it will take a few days for > us to respond. We appreciate the detailed analysis you put into this effort > and we plan on addressing all your comments. You're welcome, I look forward to hearing your responses... > > I will address your first comment now. > > We struggled the decision to split the GSAKMP Policy Token into it's own > draft. We decided to do this for two reasons. > > First, The token specificaiton can and will change as the GSAKMP is used to > support more and more applications. We wanted to allow the Policy Token RFC > to evolve at a different rate than the protocol spec. > > Second, the current I-D GSAKMP Policy Token Spec will probably be aimed at > becoming an experimental RFC. The original GSAKMP implementations use it to > specify the security policy. However, in the future GSAKMP could use a > number of policy tokens or frameworks as they become more developed. > Specification of the Policy Token within the Protocol Spec could hinder > adaptation of GSAKMP to other security policy mechanisms. I was not aware that it was aimed at Experimental status. I infer then that a new independent ID will become the standards track Policy Token spec? > > Third, the GSAKMP Policy Token could be used by other protocols if there is > a similar need for a security policy definition. We wrote the GSAKMP > security policy token to contain branching fields that would allow other > implementors to use it. I have no problem with the standards track Policy Token spec being a separate document from GSAKMP, but their inter-dependency for advancement to PS remains, agreed? Having the policy token as a common structure across key management protocols makes sense. As mentioned in my e-mail that raced with yours, I would advocate that the policy token morph into an extensible TLV style encoding, a similar design pattern as is seen in many other IETF protocols. I would also follow precedents/MUSTs from IKE-v2 where feasible. Once the GSAKMP related issues I've brought up have been figured out and have rough consensus, then I am likely to turn more of my attention to the policy token. It is an interesting problem ;o) > > > > _______________________________________________ > 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 Aug 12 12:13:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20138 for ; Tue, 12 Aug 2003 12:13:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4CCA15374F; Tue, 12 Aug 2003 12:13: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 8D1565372F for ; Tue, 12 Aug 2003 12:08:46 -0400 (EDT) Received: (qmail 11509 invoked by uid 3269); 12 Aug 2003 16:08:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11496 invoked from network); 12 Aug 2003 16:08:46 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 12 Aug 2003 16:08:46 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h7CG6dV110158 for ; Tue, 12 Aug 2003 12:06:39 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h7CG8ja620534 for ; Tue, 12 Aug 2003 12:08:45 -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 MAA29954 for ; Tue, 12 Aug 2003 12:08:45 -0400 From: canetti To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd) 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, 12 Aug 2003 12:08:44 -0400 (EDT) ---------- Forwarded message ---------- Date: Tue, 12 Aug 2003 09:51:21 -0400 From: The IESG To: IETF-Announce: ; Cc: canetti@watson.ibm.com, thardjono@verisign.com Subject: WG Action: RECHARTER: Multicast Security (msec) The charter of the Multicast Security (msec) working group in the Security Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Multicast Security (msec) ------------------------- Current Status: Active Working Group Chairs: Ran Canetti Thomas Hardjono Security Area Director(s): Russell Housley Steven Bellovin Mailing Lists: General Discussion: msec@securemulticast.org To Subscribe: msec-request@securemulticast.org In Body: subscribe Archive: Description of Working Group: The purpose of the MSEC WG is to standardize protocols for securing group communication over internets, and in particular over the global Internet. Initial efforts will focus on scalable solutions for groups with a single source and a very large number of recipients. Additional emphasis will be put on groups where the data is transmitted via IP-layer multicast routing protocols (with or without guaranteed reliability). The developed standard will assume that each group has a single trusted entity (the Group Controller) that sets the security policy and controls the group membership. The standard will strive to provide at least the following basic security guarantees: + Only legitimate group members will have access to current group communication. This includes groups with highly dynamic membership. + Legitimate group members will be able to authenticate the source and contents of the group communication. This includes cases where group members do not trust each other. An additional goal of the standard will be to protect against denial-of-service attacks, whenever possible. Due to the large number of one-to-many multicast applications and the sometimes conflicting requirements these applications exhibit, it is believed that a single protocol will be unable to meet the requirements of all applications. Therefore, the WG will first specify a general Reference Framework that includes a number of functional building blocks. Each such building block will be instantiated by one or more protocols that will be interchanable. The Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. In addition, as a secondary goal the MSEC WG will also focus on distributed architectures for group key management and group policy management, where for scalability purposes multiple trusted entities (such as Key Distributors) are deployed in a distributed fashion. For this purpose, the Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. MSEC will generate at least the following documents, which could be considered as base documents: 1. An RFC describing the security requirements of multicast security and an RFC describing the MSEC Architecture. 2. An RFC describing the Group Key Management Architecture and an RFC describing Group Policy Management Architecture in MSEC. 3. Several RFCs describing specifications for protocols that implement source authentication, group key management and group policy management. As multicast security covers a broad range of issues, and therefore touches other Working Groups in the IETF, the MSEC WG will work closely with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well as other Working Groups which maybe considered a "consumer" of the technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). With this in mind, the MSEC WG is open to receiving new work items, whenever it is considered appropriate to be homed in the MSEC WG. Such drafts will be matured in conjunction with the MSEC base documents. Goals and Milestones: DONE Working Group Last Call on GDOI Protocol. DONE Working Group Last Call on MIKEY Protocol. Sep 03 WG Last Call on Group Key Management Architecture draft. Sep 03 WG Last Call on MSEC Architecture draft. Sep 03 WG Last Call on DHHMAC for MIKEY. Sep 03 WG Last Call on Data Security Architecture draft Dec 03 WG Last Call on Security Requirements draft. Mar 04 WG Last Call on Group Security Policy Architecture draft Mar 04 WG Last Call on MESP (Multicast ESP) draft. Mar 04 WG Last call on MESP-TESLA draft. Mar 04 WG Last Call on GSAKMP-Light protocol. Jul 04 WG re-charter for other work items (or disband). _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 12 14:40:58 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23974 for ; Tue, 12 Aug 2003 14:40:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 51B24536E8; Tue, 12 Aug 2003 14:40:24 -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 F327C5361A for ; Tue, 12 Aug 2003 14:39:53 -0400 (EDT) Received: (qmail 36191 invoked by uid 3269); 12 Aug 2003 18:39:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36188 invoked from network); 12 Aug 2003 18:39:53 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 12 Aug 2003 18:39:53 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CIdns23240; Tue, 12 Aug 2003 11:39:49 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QYJZCPQ4; Tue, 12 Aug 2003 11:39:49 -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 QYF9RDN8; Tue, 12 Aug 2003 14:39:47 -0400 Message-ID: <3F393473.9050108@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 Subject: Re: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd) 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, 12 Aug 2003 14:39:47 -0400 Content-Transfer-Encoding: 7bit It would have been more informative if each of the work items had a track tag (informational/experimental/standards) next to it. Hope you can do that for the charter page on the IETF site. Thanks, Lakshminath canetti wrote: >---------- Forwarded message ---------- >Date: Tue, 12 Aug 2003 09:51:21 -0400 >From: The IESG >To: IETF-Announce: ; >Cc: canetti@watson.ibm.com, thardjono@verisign.com >Subject: WG Action: RECHARTER: Multicast Security (msec) > >The charter of the Multicast Security (msec) working group in the >Security Area of the IETF has been updated. For additional >information, please contact the Area Directors or the working >group Chairs. > >Multicast Security (msec) >------------------------- >Current Status: Active Working Group > >Chairs: > >Ran Canetti >Thomas Hardjono > >Security Area Director(s): > >Russell Housley >Steven Bellovin > >Mailing Lists: > >General Discussion: msec@securemulticast.org >To Subscribe: msec-request@securemulticast.org >In Body: subscribe >Archive: > >Description of Working Group: > >The purpose of the MSEC WG is to standardize protocols for securing >group communication over internets, and in particular over the global >Internet. Initial efforts will focus on scalable solutions for groups >with a single source and a very large number of recipients. Additional >emphasis will be put on groups where the data is transmitted via >IP-layer multicast routing protocols (with or without guaranteed >reliability). The developed standard will assume that each group has a >single trusted entity (the Group Controller) that sets the security >policy and controls the group membership. The standard will strive >to provide at least the following basic security guarantees: > >+ Only legitimate group members will have access to current group >communication. This includes groups with highly dynamic membership. > >+ Legitimate group members will be able to authenticate the source >and contents of the group communication. This includes cases where >group members do not trust each other. > >An additional goal of the standard will be to protect against >denial-of-service attacks, whenever possible. > >Due to the large number of one-to-many multicast applications and the >sometimes conflicting requirements these applications exhibit, it is >believed that a single protocol will be unable to meet the requirements >of all applications. Therefore, the WG will first specify a general >Reference Framework that includes a number of functional building >blocks. Each such building block will be instantiated by one or more >protocols that will be interchanable. The Reference Framework will not >only describe one-to-many multicast, but also many-to-many multicast. > >In addition, as a secondary goal the MSEC WG will also focus on >distributed architectures for group key management and group policy >management, where for scalability purposes multiple trusted entities >(such as Key Distributors) are deployed in a distributed fashion. For >this purpose, the Reference Framework will not only describe >one-to-many multicast, but also many-to-many multicast. > >MSEC will generate at least the following documents, which could be >considered as base documents: > >1. An RFC describing the security requirements of multicast security and >an RFC describing the MSEC Architecture. > >2. An RFC describing the Group Key Management Architecture and an RFC >describing Group Policy Management Architecture in MSEC. > >3. Several RFCs describing specifications for protocols that implement >source authentication, group key management and group policy management. >As multicast security covers a broad range of issues, and therefore >touches other Working Groups in the IETF, the MSEC WG will work closely >with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well >as other Working Groups which maybe considered a "consumer" of the >technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may >have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). > >With this in mind, the MSEC WG is open to receiving new work items, >whenever it is considered appropriate to be homed in the MSEC WG. Such >drafts will be matured in conjunction with the MSEC base documents. > >Goals and Milestones: > >DONE Working Group Last Call on GDOI Protocol. > >DONE Working Group Last Call on MIKEY Protocol. > >Sep 03 WG Last Call on Group Key Management Architecture draft. > >Sep 03 WG Last Call on MSEC Architecture draft. > >Sep 03 WG Last Call on DHHMAC for MIKEY. > >Sep 03 WG Last Call on Data Security Architecture draft > >Dec 03 WG Last Call on Security Requirements draft. > >Mar 04 WG Last Call on Group Security Policy Architecture draft > >Mar 04 WG Last Call on MESP (Multicast ESP) draft. > >Mar 04 WG Last call on MESP-TESLA draft. > >Mar 04 WG Last Call on GSAKMP-Light protocol. > >Jul 04 WG re-charter for other work items (or disband). > > > > > >_______________________________________________ >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 Aug 12 15:31:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27194 for ; Tue, 12 Aug 2003 15:31:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7D8955374F; Tue, 12 Aug 2003 15:31:04 -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 E2DE55367E for ; Tue, 12 Aug 2003 15:29:42 -0400 (EDT) Received: (qmail 43970 invoked by uid 3269); 12 Aug 2003 19:29:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43967 invoked from network); 12 Aug 2003 19:29:41 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 12 Aug 2003 19:29:41 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h7CJRTV44300; Tue, 12 Aug 2003 15:27:30 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h7CJTZa1078722; Tue, 12 Aug 2003 15:29:35 -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 PAA35758; Tue, 12 Aug 2003 15:29:35 -0400 From: canetti To: Lakshminath Dondeti Cc: msec@securemulticast.org Subject: Re: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd) In-Reply-To: <3F393473.9050108@americasm06.nt.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: Tue, 12 Aug 2003 15:29:34 -0400 (EDT) You're right. Will do. Ran On Tue, 12 Aug 2003, Lakshminath Dondeti wrote: > It would have been more informative if each of the work items had a > track tag (informational/experimental/standards) next to it. Hope you > can do that for the charter page on the IETF site. > > Thanks, > Lakshminath > > canetti wrote: > > >---------- Forwarded message ---------- > >Date: Tue, 12 Aug 2003 09:51:21 -0400 > >From: The IESG > >To: IETF-Announce: ; > >Cc: canetti@watson.ibm.com, thardjono@verisign.com > >Subject: WG Action: RECHARTER: Multicast Security (msec) > > > >The charter of the Multicast Security (msec) working group in the > >Security Area of the IETF has been updated. For additional > >information, please contact the Area Directors or the working > >group Chairs. > > > >Multicast Security (msec) > >------------------------- > >Current Status: Active Working Group > > > >Chairs: > > > >Ran Canetti > >Thomas Hardjono > > > >Security Area Director(s): > > > >Russell Housley > >Steven Bellovin > > > >Mailing Lists: > > > >General Discussion: msec@securemulticast.org > >To Subscribe: msec-request@securemulticast.org > >In Body: subscribe > >Archive: > > > >Description of Working Group: > > > >The purpose of the MSEC WG is to standardize protocols for securing > >group communication over internets, and in particular over the global > >Internet. Initial efforts will focus on scalable solutions for groups > >with a single source and a very large number of recipients. Additional > >emphasis will be put on groups where the data is transmitted via > >IP-layer multicast routing protocols (with or without guaranteed > >reliability). The developed standard will assume that each group has a > >single trusted entity (the Group Controller) that sets the security > >policy and controls the group membership. The standard will strive > >to provide at least the following basic security guarantees: > > > >+ Only legitimate group members will have access to current group > >communication. This includes groups with highly dynamic membership. > > > >+ Legitimate group members will be able to authenticate the source > >and contents of the group communication. This includes cases where > >group members do not trust each other. > > > >An additional goal of the standard will be to protect against > >denial-of-service attacks, whenever possible. > > > >Due to the large number of one-to-many multicast applications and the > >sometimes conflicting requirements these applications exhibit, it is > >believed that a single protocol will be unable to meet the requirements > >of all applications. Therefore, the WG will first specify a general > >Reference Framework that includes a number of functional building > >blocks. Each such building block will be instantiated by one or more > >protocols that will be interchanable. The Reference Framework will not > >only describe one-to-many multicast, but also many-to-many multicast. > > > >In addition, as a secondary goal the MSEC WG will also focus on > >distributed architectures for group key management and group policy > >management, where for scalability purposes multiple trusted entities > >(such as Key Distributors) are deployed in a distributed fashion. For > >this purpose, the Reference Framework will not only describe > >one-to-many multicast, but also many-to-many multicast. > > > >MSEC will generate at least the following documents, which could be > >considered as base documents: > > > >1. An RFC describing the security requirements of multicast security and > >an RFC describing the MSEC Architecture. > > > >2. An RFC describing the Group Key Management Architecture and an RFC > >describing Group Policy Management Architecture in MSEC. > > > >3. Several RFCs describing specifications for protocols that implement > >source authentication, group key management and group policy management. > >As multicast security covers a broad range of issues, and therefore > >touches other Working Groups in the IETF, the MSEC WG will work closely > >with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well > >as other Working Groups which maybe considered a "consumer" of the > >technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may > >have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). > > > >With this in mind, the MSEC WG is open to receiving new work items, > >whenever it is considered appropriate to be homed in the MSEC WG. Such > >drafts will be matured in conjunction with the MSEC base documents. > > > >Goals and Milestones: > > > >DONE Working Group Last Call on GDOI Protocol. > > > >DONE Working Group Last Call on MIKEY Protocol. > > > >Sep 03 WG Last Call on Group Key Management Architecture draft. > > > >Sep 03 WG Last Call on MSEC Architecture draft. > > > >Sep 03 WG Last Call on DHHMAC for MIKEY. > > > >Sep 03 WG Last Call on Data Security Architecture draft > > > >Dec 03 WG Last Call on Security Requirements draft. > > > >Mar 04 WG Last Call on Group Security Policy Architecture draft > > > >Mar 04 WG Last Call on MESP (Multicast ESP) draft. > > > >Mar 04 WG Last call on MESP-TESLA draft. > > > >Mar 04 WG Last Call on GSAKMP-Light protocol. > > > >Jul 04 WG re-charter for other work items (or disband). > > > > > > > > > > > >_______________________________________________ > >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 Aug 13 11:08:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22776 for ; Wed, 13 Aug 2003 11:08:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7B6E853696; Wed, 13 Aug 2003 11:08: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 14955536AB for ; Wed, 13 Aug 2003 11:06:16 -0400 (EDT) Received: (qmail 58665 invoked by uid 3269); 13 Aug 2003 15:06:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58662 invoked from network); 13 Aug 2003 15:06:15 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 13 Aug 2003 15:06:15 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h7DF4pJD022968; Wed, 13 Aug 2003 10:04:51 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h7DF67k5031188; Wed, 13 Aug 2003 10:06:08 -0500 Received: from DGKFL721 (dhcp-1.columbia.sparta.com [157.185.80.1]) by columbia.sparta.com (8.9.1a/8.9.1) with SMTP id LAA24101; Wed, 13 Aug 2003 11:05:59 -0400 (EDT) Message-ID: <009501c361ac$6b0a4450$0150b99d@DGKFL721> From: "hugh harney" To: "George Gross" Cc: "George Gross" , References: Subject: Re: [MSEC] George's comments / splitting token from protocol MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 13 Aug 2003 11:05:58 -0400 Content-Transfer-Encoding: 7bit George, My comments in-line. > > I was not aware that it was aimed at Experimental status. I infer then > that a new independent ID will become the standards track Policy Token > spec? I think a generic MSEC security policy token should be developed. However, I don't think GSAKMP should be dependant on the new MSEC PT. The GSAKMP Policy Token is our shot at a PT that supports GSAKMP, IPSec, Distributed operation, and LKH. It provides a great deal of flexibility, but is not yet fully inclusive of all potential group applications. I think the advancement of the current GSAKMP PT to an RFC is adiquate to provide an strong reference in the GSAKMP protocol spec. We are writing an expanded version of the GSAKMP PT that provides a complete reference for implementers of GSAKMP. Implementers will be able to parse the GSAKMP PT and interoperate. I think any policy token is an Experimental RFC because it is not a protocol. It is information that supports a protocol. > I have no problem with the standards track Policy Token spec being a > separate document from GSAKMP, but their inter-dependency for advancement > to PS remains, agreed? The only inter-dependency I see between GSAKMP and the GSAKMP Policy Token is that GSAKMP should not be any references to an I-D. GSAKMP should be able to point to an RFC for a representation of a policy token. > Having the policy token as a common structure across key management > protocols makes sense. Yes, it does. However, GSAKMP is ready to be a standard, based on the current PT. I do not want to have to wait for all other potential users of the PT to hack at the PT spec. I'd like to document the current work on the PT. Then allow a more generic PT to be specified for general use and all potential network states. GSAKMP (the protocol) can use any policy token that is developed in the future, without modification. In the end, GSAKMP only needs the policy engine to respond with a binary go or stop. > As mentioned in my e-mail that raced with yours, I would advocate that the > policy token morph into an extensible TLV style encoding, a similar design > pattern as is seen in many other IETF protocols. I would also follow > precedents/MUSTs from IKE-v2 where feasible. I think a more flexible encoding is good for the MSEC PT that will come after the current GSAKMP PT is captured. GSAKMP today only needs the specified GSAKMP PT to provide distributed operation, delegation of operation, and key management for many to many multicast. I'd like to decouple the GSAKMP spec from the R&D into generic MSEC security policy. As for IKE-v2, I think we need to be careful to adopt only those things that make sense. IKE-v2 operates in a different paradigm than GSAKMP. > Once the GSAKMP related issues I've brought up have been figured out and > have rough consensus, then I am likely to turn more of my attention to the > policy token. It is an interesting problem ;o) Yes it is. The truth of the situation is that a key management system is only as good at the security policy enforcement. In the end, keys only represent policy enforcement. I look forward to your comments on the GSAKMP PT and working on the MSEC PT with you. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 13 13:22:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26527 for ; Wed, 13 Aug 2003 13:22:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DCF8B535AF; Wed, 13 Aug 2003 13: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 50ACA53568 for ; Wed, 13 Aug 2003 13:21:12 -0400 (EDT) Received: (qmail 83859 invoked by uid 3269); 13 Aug 2003 17:21:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83856 invoked from network); 13 Aug 2003 17:21:11 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 13 Aug 2003 17:21:11 -0000 Received: (qmail 7367 invoked from network); 13 Aug 2003 17:21:10 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.172) by mail.nac.net with SMTP; 13 Aug 2003 17:21:10 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7DFCcP23834; Wed, 13 Aug 2003 11:12:38 -0400 From: George Gross To: hugh harney Cc: , George Gross Subject: Re: [MSEC] George's comments / splitting token from protocol In-Reply-To: <008301c361ac$2cae5e80$0150b99d@DGKFL721> 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: Wed, 13 Aug 2003 11:12:38 -0400 (EDT) Hi Hugh, as a way for us to get to a common point of view on this topic, I'd suggest that you please have a look at RFC3160, the Tao of the IETF. Please look at specifically sections 6.4.2 and 6.5, which discuss the criteria for Normative Reference and an Experimental RFC. the reminder my comments are inline below... br, George On Wed, 13 Aug 2003, hugh harney wrote: > George, > > My comments in-line. > > > > > I was not aware that it was aimed at Experimental status. I infer then > > that a new independent ID will become the standards track Policy Token > > spec? > > I think a generic MSEC security policy token should be developed. I don't > think GSAKMP should be dependant on the new MSEC PT. > > The GSAKMP Policy Token is our shot at a PT that supports GSAKMP, IPSec, > Distributed operation, and LKH. It provides a great deal of flexibility, but > is not yet fully inclusive of all potential group applications. > > I think the advancement of the current GSAKMP PT to an RFC is adiquate to > provide an strong reference in the GSAKMP protocol spec. I respectfully disagree. THe Experimental RFC policy token is embedded within the policy token payload sent in the GSAKMP "Key Download" message. In other words, it is part of the bits on the wire specification. BTW, this is not an invitation to remove that payload from that message. Rather, I am saying that the dependency on the policy token explicitly exists in the GSKAMP protocol. What is more, by virtue of aspiring to be a Proposed Standard, the GSAKMP protocol specification must refer to Normative References that are also at Proposed Standards status, not Experimental RFC status. > We are writing an > expanded version of the GSAKMP PT that provides a complete reference for > implementers of GSAKMP. Implementers will be able to parse the GSAKMP PT and > interoperate. > > I think any policy token is an Experimental RFC because it is not a > protocol. It is information that supports a protocol. the policy token payload is part of the GSAKMP protocol. > > > I have no problem with the standards track Policy Token spec being a > > separate document from GSAKMP, but their inter-dependency for advancement > > to PS remains, agreed? > > The only inter-dependency I see between GSAKMP and the GSAKMP Policy Token > is that GSAKMP should not be any references to an I-D. GSAKMP should be able > to point to an RFC for a representation of a policy token. As indicated above, the Tao of the IETF does not align with that view when one RFC is experimental and the other RFC is proposed standard... > > > Having the policy token as a common structure across key management > > protocols makes sense. > > Yes, it does. However, GSAKMP is ready to be a standard, based on the > current PT. Candidly, I see GSAKMP married with the standard policy token and the schedule (whatever that turns out to be) for its movement to PS. The experimental policy token is relevant to the earlier (experimental) incarnations of GSAKMP. > I do not want to have to wait for all other potential users of > the PT to hack at the PT spec. Well, emm... didn't realize we were so much a part of the GSAKMP schedule... I mean, since this the policy token is on the GSAKMP critical path, then this type of discussion would have done well to have started sooner than now. Rest assured, I am willing to work with you, and I'm sure the rest of this group is to, to assure that the standard policy token arrives at the finish line in as expedient manner as is feasible. As always, this is a process of arriving at rough consensus, so it will take time. Unfortunately, as it stands, I hear you asking this working group to standardize a dependency on a vendor specific experimental policy token. AFAIK, that is not gonna happen, the bar is set higher than that. In particular, I don't want the standard policy token design painted into a corner to comply with the precedent set by that experimental policy token, such as its bits on the wire encoding or semantics, simply because GSAKMP mistakingly refered to it as a normative reference. >I'd like to document the current work on the > PT. Then allow a more generic PT to be specified for general use and all > potential network states. GSAKMP (the protocol) can use any policy token > that is developed in the future, without modification. I don't see the current GKAKMP Policy Token Payload being as extensible as your above assertion would indicate. This is related to another comment that I've had, that there is a good case for having the payload TLV header be similar as defined for IKE-v2, with critical bit semantics. Also a mechanism for vendor-specific payloads and code points. If you want to define a vendor-specific policy token payload, that is fine, but the hole in the GSAKMP protocol for that role should filled by be the standards track policy token, which has not even had an ID published. > In the end, GSAKMP > only needs the policy engine to respond with a binary go or stop. not quite, as the GM needs a copy of the policy to know the rules of the day > > > As mentioned in my e-mail that raced with yours, I would advocate that the > > policy token morph into an extensible TLV style encoding, a similar design > > pattern as is seen in many other IETF protocols. I would also follow > > precedents/MUSTs from IKE-v2 where feasible. > > I think a more flexible encoding is good for the MSEC PT that will come > after the current GSAKMP PT is captured. Agreed. > > GSAKMP today only needs the specified GSAKMP PT to provide distributed > operation, delegation of operation, and key management for many to many > multicast. I'd like to decouple the GSAKMP spec from the R&D into generic > MSEC security policy. I was not expecting to do group policy token R&D in this arena, my expectation is that a well engineered extensible policy token could be defined using the known state of the art. The experimental policy token certainly provides a reasonable design starting point, and no doubt others will contribute to it. > > As for IKE-v2, I think we need to be careful to adopt only those things that > make sense. IKE-v2 operates in a different paradigm than GSAKMP. Please clarify. There are several aspects of IKE-v2 that are good protocol design: extensible TLV, strong review by the crypto community of which algorithms are preferable for standardization. A variety of Notify payloads that deal with topics like NAT and traffic selectors that aren not even mentioned in GSAKMP or the policy token. > > > Once the GSAKMP related issues I've brought up have been figured out and > > have rough consensus, then I am likely to turn more of my attention to the > > policy token. It is an interesting problem ;o) > > Yes it is. The truth of the situation is that a key management system is > only as good at the security policy enforcement. In the end, keys only > represent policy enforcement. > > I look forward to your comments on the GSAKMP PT and working on the MSEC PT > with you. I am confident we can work out a rough consensus to this and the remaining topics/issues. I encourage others to participate too... George > > Hugh > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 13 14:34:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29722 for ; Wed, 13 Aug 2003 14:34:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 63CED53599; Wed, 13 Aug 2003 14:34:04 -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 D7A4A53552 for ; Wed, 13 Aug 2003 14:32:30 -0400 (EDT) Received: (qmail 95896 invoked by uid 3269); 13 Aug 2003 18:32:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95892 invoked from network); 13 Aug 2003 18:32:30 -0000 Received: from pintail.mail.pas.earthlink.net (207.217.120.122) by klesh.pair.com with SMTP; 13 Aug 2003 18:32:30 -0000 Received: from user-uiveqcd.dsl.mindspring.com ([165.247.105.141] helo=stealth) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19n0Q0-0004T5-00; Wed, 13 Aug 2003 11:32:21 -0700 Message-ID: <023601c361c9$3ad1e1e0$9865fea9@stealth> From: "Andrea Colegrove" To: "George Gross" , "hugh harney" Cc: , "George Gross" References: Subject: Re: [MSEC] George's comments / splitting token from protocol MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 13 Aug 2003 14:32:17 -0400 Content-Transfer-Encoding: 7bit George, I believe that changing the token payload to contain an identifier of the token type will accomplish what we intended, in that multiple token types may be supported, with the GSAKMP v1 token as the initial choice. Re: Experimental. I am the source of some misinformation here. I had looked at RFC 2026 a while back and recalled that there was an alternate path, being the best practices path. I mentioned this to Hugh and I am afraid that I didn't communicate it well. On review of 2026, I don't think that a BCP is a good path for a token at all. I believe that we need to revise the token payload to allow extensibility here so that as new token types become available, these may be supported. The GSAKMP token will provide a means of initial operation, but will probably not provide a generic enough standard in the long run. As we all agree, a nice TLV spec, perhaps ASN.1 DER, may be in order here. I believe however that GSAKMP should not be held up because of a lack of a generic token. The protocol will be independent of the data it carries. I apologize again for spreading misinformation. --- Andrea ----- Original Message ----- From: "George Gross" To: "hugh harney" Cc: ; "George Gross" Sent: Wednesday, August 13, 2003 11:12 AM Subject: Re: [MSEC] George's comments / splitting token from protocol > Hi Hugh, > > as a way for us to get to a common point of view on this topic, > I'd suggest that you please have a look at RFC3160, the Tao of the IETF. > Please look at specifically sections 6.4.2 and 6.5, which discuss the > criteria for Normative Reference and an Experimental RFC. > > the reminder my comments are inline below... > > br, > George > > On Wed, 13 Aug 2003, hugh harney wrote: > > > George, > > > > My comments in-line. > > > > > > > > I was not aware that it was aimed at Experimental status. I infer then > > > that a new independent ID will become the standards track Policy Token > > > spec? > > > > I think a generic MSEC security policy token should be developed. I don't > > think GSAKMP should be dependant on the new MSEC PT. > > > > The GSAKMP Policy Token is our shot at a PT that supports GSAKMP, IPSec, > > Distributed operation, and LKH. It provides a great deal of flexibility, but > > is not yet fully inclusive of all potential group applications. > > > > I think the advancement of the current GSAKMP PT to an RFC is adiquate to > > provide an strong reference in the GSAKMP protocol spec. > > I respectfully disagree. THe Experimental RFC policy token is embedded > within the policy token payload sent in the GSAKMP "Key Download" message. > In other words, it is part of the bits on the wire specification. BTW, > this is not an invitation to remove that payload from that message. > Rather, I am saying that the dependency on the policy token explicitly > exists in the GSKAMP protocol. What is more, by virtue of aspiring to be a > Proposed Standard, the GSAKMP protocol specification must refer to > Normative References that are also at Proposed Standards status, not > Experimental RFC status. > > > We are writing an > > expanded version of the GSAKMP PT that provides a complete reference for > > implementers of GSAKMP. Implementers will be able to parse the GSAKMP PT and > > interoperate. > > > > I think any policy token is an Experimental RFC because it is not a > > protocol. It is information that supports a protocol. > > the policy token payload is part of the GSAKMP protocol. > > > > > > I have no problem with the standards track Policy Token spec being a > > > separate document from GSAKMP, but their inter-dependency for advancement > > > to PS remains, agreed? > > > > The only inter-dependency I see between GSAKMP and the GSAKMP Policy Token > > is that GSAKMP should not be any references to an I-D. GSAKMP should be able > > to point to an RFC for a representation of a policy token. > > As indicated above, the Tao of the IETF does not align with that view > when one RFC is experimental and the other RFC is proposed standard... > > > > > > Having the policy token as a common structure across key management > > > protocols makes sense. > > > > Yes, it does. However, GSAKMP is ready to be a standard, based on the > > current PT. > > Candidly, I see GSAKMP married with the standard policy token and the > schedule (whatever that turns out to be) for its movement to PS. The > experimental policy token is relevant to the earlier (experimental) > incarnations of GSAKMP. > > > I do not want to have to wait for all other potential users of > > the PT to hack at the PT spec. > > Well, emm... didn't realize we were so much a part of the GSAKMP > schedule... I mean, since this the policy token is on the GSAKMP critical > path, then this type of discussion would have done well to have started > sooner than now. > > Rest assured, I am willing to work with you, and I'm sure the rest of this > group is to, to assure that the standard policy token arrives at the > finish line in as expedient manner as is feasible. As always, this is a > process of arriving at rough consensus, so it will take time. > > Unfortunately, as it stands, I hear you asking this working group to > standardize a dependency on a vendor specific experimental policy token. > AFAIK, that is not gonna happen, the bar is set higher than that. > > In particular, I don't want the standard policy token design painted into > a corner to comply with the precedent set by that experimental policy > token, such as its bits on the wire encoding or semantics, simply because > GSAKMP mistakingly refered to it as a normative reference. > > >I'd like to document the current work on the > > PT. Then allow a more generic PT to be specified for general use and all > > potential network states. GSAKMP (the protocol) can use any policy token > > that is developed in the future, without modification. > > I don't see the current GKAKMP Policy Token Payload being as extensible as > your above assertion would indicate. This is related to another comment > that I've had, that there is a good case for having the payload TLV header > be similar as defined for IKE-v2, with critical bit semantics. Also a > mechanism for vendor-specific payloads and code points. If you want to > define a vendor-specific policy token payload, that is fine, but the hole > in the GSAKMP protocol for that role should filled by be the standards > track policy token, which has not even had an ID published. > > > In the end, GSAKMP > > only needs the policy engine to respond with a binary go or stop. > > not quite, as the GM needs a copy of the policy to know the rules of the > day > > > > > > As mentioned in my e-mail that raced with yours, I would advocate that the > > > policy token morph into an extensible TLV style encoding, a similar design > > > pattern as is seen in many other IETF protocols. I would also follow > > > precedents/MUSTs from IKE-v2 where feasible. > > > > I think a more flexible encoding is good for the MSEC PT that will come > > after the current GSAKMP PT is captured. > > Agreed. > > > > > GSAKMP today only needs the specified GSAKMP PT to provide distributed > > operation, delegation of operation, and key management for many to many > > multicast. I'd like to decouple the GSAKMP spec from the R&D into generic > > MSEC security policy. > > I was not expecting to do group policy token R&D in this arena, my > expectation is that a well engineered extensible policy token could be > defined using the known state of the art. The experimental policy token > certainly provides a reasonable design starting point, and no doubt others > will contribute to it. > > > > > As for IKE-v2, I think we need to be careful to adopt only those things that > > make sense. IKE-v2 operates in a different paradigm than GSAKMP. > > Please clarify. There are several aspects of IKE-v2 that are good protocol > design: extensible TLV, strong review by the crypto community of which > algorithms are preferable for standardization. A variety of Notify > payloads that deal with topics like NAT and traffic selectors that aren > not even mentioned in GSAKMP or the policy token. > > > > > > Once the GSAKMP related issues I've brought up have been figured out and > > > have rough consensus, then I am likely to turn more of my attention to the > > > policy token. It is an interesting problem ;o) > > > > Yes it is. The truth of the situation is that a key management system is > > only as good at the security policy enforcement. In the end, keys only > > represent policy enforcement. > > > > I look forward to your comments on the GSAKMP PT and working on the MSEC PT > > with you. > > I am confident we can work out a rough consensus to this and the remaining > topics/issues. I encourage others to participate too... > > George > > > > > Hugh > > > > > > > > > _______________________________________________ > 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 Aug 13 15:32:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03218 for ; Wed, 13 Aug 2003 15:32:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9382B536FB; Wed, 13 Aug 2003 15:32: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 8B1EB536DF for ; Wed, 13 Aug 2003 15:31:24 -0400 (EDT) Received: (qmail 6788 invoked by uid 3269); 13 Aug 2003 19:31:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6785 invoked from network); 13 Aug 2003 19:31:24 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 13 Aug 2003 19:31:24 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h7DJU0JD027327; Wed, 13 Aug 2003 14:30:00 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h7DJVKk5008218; Wed, 13 Aug 2003 14:31:21 -0500 Received: from DGKFL721 (dhcp-1.columbia.sparta.com [157.185.80.1]) by columbia.sparta.com (8.9.1a/8.9.1) with SMTP id PAA27818; Wed, 13 Aug 2003 15:31:19 -0400 (EDT) Message-ID: <007101c361d1$7832a530$0150b99d@DGKFL721> From: "hugh harney" To: "George Gross" Cc: , "George Gross" References: Subject: Re: [MSEC] George's comments / splitting token from protocol MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 13 Aug 2003 15:31:17 -0400 Content-Transfer-Encoding: 7bit George, I agree with Andrea. If we were to add a policy token identity field in the GSAKMP spec, then several policy tokens could be supported. I believe the first policy token identified could be very close to the current GSAKMP Policy Token (well the as yet to be released version 2). All upgrades to the PT could be identified seperatly. I'll address your other issues as soon as I can. hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 13 16:42:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05200 for ; Wed, 13 Aug 2003 16:42:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 39E7F536AD; Wed, 13 Aug 2003 16: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 AF87F535B6 for ; Wed, 13 Aug 2003 16:40:22 -0400 (EDT) Received: (qmail 19913 invoked by uid 3269); 13 Aug 2003 20:40:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19910 invoked from network); 13 Aug 2003 20:40:22 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 13 Aug 2003 20:40:22 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h7DKc2V118854; Wed, 13 Aug 2003 16:38:02 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h7DKeAa1128138; Wed, 13 Aug 2003 16:40:10 -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 QAA30604; Wed, 13 Aug 2003 16:40:09 -0400 From: canetti To: George Gross Cc: Mark Baugher , msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: 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: Wed, 13 Aug 2003 16:40:08 -0400 (EDT) George, Your proposal to add a (currently unused) field to the policy token specifying the RMT protocl in use ofr rekeying sounds like a reasonable thing to do. The cost is minimal, and although the chance it will ever be used are small, if we do need it and dont have it it will be ugly. But I'm weary of the requirement that future versions must be backwards compatible. You sometime want future versions to explicitly NOT be backwards compatible, eg when there is a security hole found in the old version. In fact, in such a case you;d want to protect against "version rollback" attacks. (cf the SSL v2/v3 story). Ran On Wed, 6 Aug 2003, George Gross wrote: > Mark, > > On Wed, 6 Aug 2003, Mark Baugher wrote: > > > George, > > GDOI has a version number in it. So does GSAKMP. > > Oops, sorry, my e-mail was not precise. What I really should have said was > "the semantics for mismatched version numbers between GCKS and group > member are currently underspecified...". > > In GSAKMP, there are Notify payloads for invalid version numbers, but I > did not find any text explaining when that would be triggered. I think > that this needs to be added, in alignment with the requirement for > backward compatibility. > > In GDOI there is no explicit discussion of version number processing. In > fact, RFC3547 does not have the word "error" in it at all. Amazing, an > error free protocol ;o) The text in section 3.2.2 seems to hint ISAKMP > version error processing is implied? it would be reasonable for GDOI v2 to > say more here.... > > > Perhaps we should > > mention this need in gkmarch. > > Yes, I might go so far as to say that backward compatibility would be > important to have specified as a MUST. If we are talking about large-scale > multicast, it is likely that a protocol software upgrade transition from > v1->v2 will straddle large numbers of endpoints, and could take many > weeks/months. > > In other words, the GCKS is required to accept any group member protocol > version less than or equal to the highest version the GCKS supports. > > George > > > > > Mark > > At 07:56 AM 8/6/2003 -0400, George Gross wrote: > > >Hi Mark, > > > > > > > > >On Tue, 5 Aug 2003, Mark Baugher wrote: > > > > > > > hi George, > > > > I think the interoperability issue that you mention below could happen > > > > on any element of policy. Somehow the policy is determined and if it has > > > > advanced or new features than some legacy members don't support, then there > > > > will be an interoperability problem. > > > > > > > > Best regards, Mark > > > > > >Ok, so would you agree then that a version number should be introduced in > > >the group member's registration "request to join" message? > > > > > >Also, in a related post to this list, I had proposed the protocol feature > > >of having a "critical" or mandatory to implement flag in the key > > >management protocol's Type/Length/Value encodings. This mechanism > > >specifically addresses this backward compatibility interoperability issue. > > > > > >I would not expect this to be a controversial concept to require in > > >GSAKMP or GDOI. It is a basic protocol design feature, examples of which > > >can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is > > >illegal to mark a vendor specific TLV critical. > > > > > >br, > > > George > > > > > > > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > > > > >Hi Mark, > > > > > > > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > > > > > > > George, > > > > > > > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > > > > > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch > > > specify > > > > > > >the base error recovery is a minimum starting point. However, I > > > would also > > > > > > >require that the group policy token have the hooks (i.e. reserved > > > TLV) for > > > > > > >describing the group's mandatory RMT protocol and its operating > > > > > > >parameters. This finesses the "there are many deployment scenarios..." > > > > > > >issues by specifying the extensibility that must be built into the GKM > > > > > > >protocol and its policy token. > > > > > > > > > > > > > >To get this capability, at first sight it seems we need: an RMT > > > protocol > > > > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > > > > >group policy token spec. thoughts? > > > > > > > > > > > > I would not put an identifier into a group key management protocol > > > for an > > > > > > RMT protocol when there are no standard RMT protocols. If reliable > > > > > > multicast were more important to group key management then I > > > perceive it to > > > > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > > > > SPKI). But I don't think we lose anything with the status quo, > > > which is to > > > > > > use a sequence number and periodic retransmission of the re-key > > > message. > > > > > > > > > > > > Mark > > > > > > > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > > > >RMT protocol is standardized, and that the MSEC policy token v2 was > > > > >"extended" to include the formerly unspecified but now standard RMT > > > > >identifier. The endpoints that are running MSEC v1 will be unable to > > > > >reliably participate in the group, as they get dropped after the first > > > > >lost rekey packet. There will not be retransmission of the rekey message > > > > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > > > > >next rekey message's sequence number mismatch could be an unacceptably > > > > >long wait... > > > > > > > > > >At the very least, this case raises a requirement in the registration > > > > >protocol to have the v1 endpoint tell the GCKS its version number and/or > > > > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > > > >subsets with their respective RMT rekey policies. RMT aside, I would think > > > > >we need this capability to allow v1 endpoints to participate with v1 rekey > > > > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > > > > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > > > > > > > >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 Aug 14 07:19:42 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06554 for ; Thu, 14 Aug 2003 07:19:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 82CBC536C9; Thu, 14 Aug 2003 07:18: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 C6AA4535FE for ; Thu, 14 Aug 2003 07:16:29 -0400 (EDT) Received: (qmail 2668 invoked by uid 3269); 14 Aug 2003 11:16:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2665 invoked from network); 14 Aug 2003 11:16:29 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 14 Aug 2003 11:16:29 -0000 Received: (qmail 94504 invoked from network); 14 Aug 2003 11:16:28 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.174) by mail.nac.net with SMTP; 14 Aug 2003 11:16:28 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7E97me25372; Thu, 14 Aug 2003 05:07:48 -0400 From: George Gross To: canetti Cc: George Gross , Mark Baugher , Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: 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, 14 Aug 2003 05:07:48 -0400 (EDT) Hi Ran, On Wed, 13 Aug 2003, canetti wrote: > George, > > Your proposal to add a (currently unused) field to the policy token > specifying the RMT protocl in use ofr rekeying sounds like a reasonable > thing to do. The cost is minimal, and although the chance it will ever be > used are small, if we do need it and dont have it it will be ugly. good, I think this parameter will prove its worth in the long-term... given the discussions on the policy token in a parallel thread, I'd like to hear the GSAKMP folk weigh in on this parameter too... > > But I'm weary of the requirement that future versions must be backwards > compatible. You sometime want future versions to explicitly NOT be > backwards compatible, eg when there is a security hole found in the old > version. In fact, in such a case you;d want to protect against "version > rollback" attacks. (cf the SSL v2/v3 story). Yup, see what you mean...so each GSAKMP (or GDOI) GCKS needs to be able to refuse a GM request to join for those protocol versions that are on the "drain bamaged" version list ;o) and in the inverse direction, GM should be able to decline membership in a group whose GCKS software version is on that list. Would the "drain bamaged version list" make sense to add to the policy token? I'm leaning towards "yes", as it would allow a GM to offer a mutually acceptable version in the request to join... George > > Ran > > > On Wed, 6 Aug 2003, George Gross wrote: > > > Mark, > > > > On Wed, 6 Aug 2003, Mark Baugher wrote: > > > > > George, > > > GDOI has a version number in it. So does GSAKMP. > > > > Oops, sorry, my e-mail was not precise. What I really should have said was > > "the semantics for mismatched version numbers between GCKS and group > > member are currently underspecified...". > > > > In GSAKMP, there are Notify payloads for invalid version numbers, but I > > did not find any text explaining when that would be triggered. I think > > that this needs to be added, in alignment with the requirement for > > backward compatibility. > > > > In GDOI there is no explicit discussion of version number processing. In > > fact, RFC3547 does not have the word "error" in it at all. Amazing, an > > error free protocol ;o) The text in section 3.2.2 seems to hint ISAKMP > > version error processing is implied? it would be reasonable for GDOI v2 to > > say more here.... > > > > > Perhaps we should > > > mention this need in gkmarch. > > > > Yes, I might go so far as to say that backward compatibility would be > > important to have specified as a MUST. If we are talking about large-scale > > multicast, it is likely that a protocol software upgrade transition from > > v1->v2 will straddle large numbers of endpoints, and could take many > > weeks/months. > > > > In other words, the GCKS is required to accept any group member protocol > > version less than or equal to the highest version the GCKS supports. > > > > George > > > > > > > > Mark > > > At 07:56 AM 8/6/2003 -0400, George Gross wrote: > > > >Hi Mark, > > > > > > > > > > > >On Tue, 5 Aug 2003, Mark Baugher wrote: > > > > > > > > > hi George, > > > > > I think the interoperability issue that you mention below could happen > > > > > on any element of policy. Somehow the policy is determined and if it has > > > > > advanced or new features than some legacy members don't support, then there > > > > > will be an interoperability problem. > > > > > > > > > > Best regards, Mark > > > > > > > >Ok, so would you agree then that a version number should be introduced in > > > >the group member's registration "request to join" message? > > > > > > > >Also, in a related post to this list, I had proposed the protocol feature > > > >of having a "critical" or mandatory to implement flag in the key > > > >management protocol's Type/Length/Value encodings. This mechanism > > > >specifically addresses this backward compatibility interoperability issue. > > > > > > > >I would not expect this to be a controversial concept to require in > > > >GSAKMP or GDOI. It is a basic protocol design feature, examples of which > > > >can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is > > > >illegal to mark a vendor specific TLV critical. > > > > > > > >br, > > > > George > > > > > > > > > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > > > > > >Hi Mark, > > > > > > > > > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > > > > > > > > > George, > > > > > > > > > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > > > > > > > > > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch > > > > specify > > > > > > > >the base error recovery is a minimum starting point. However, I > > > > would also > > > > > > > >require that the group policy token have the hooks (i.e. reserved > > > > TLV) for > > > > > > > >describing the group's mandatory RMT protocol and its operating > > > > > > > >parameters. This finesses the "there are many deployment scenarios..." > > > > > > > >issues by specifying the extensibility that must be built into the GKM > > > > > > > >protocol and its policy token. > > > > > > > > > > > > > > > >To get this capability, at first sight it seems we need: an RMT > > > > protocol > > > > > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > > > > > >group policy token spec. thoughts? > > > > > > > > > > > > > > I would not put an identifier into a group key management protocol > > > > for an > > > > > > > RMT protocol when there are no standard RMT protocols. If reliable > > > > > > > multicast were more important to group key management then I > > > > perceive it to > > > > > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > > > > > SPKI). But I don't think we lose anything with the status quo, > > > > which is to > > > > > > > use a sequence number and periodic retransmission of the re-key > > > > message. > > > > > > > > > > > > > > Mark > > > > > > > > > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > > > > >RMT protocol is standardized, and that the MSEC policy token v2 was > > > > > >"extended" to include the formerly unspecified but now standard RMT > > > > > >identifier. The endpoints that are running MSEC v1 will be unable to > > > > > >reliably participate in the group, as they get dropped after the first > > > > > >lost rekey packet. There will not be retransmission of the rekey message > > > > > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > > > > > >next rekey message's sequence number mismatch could be an unacceptably > > > > > >long wait... > > > > > > > > > > > >At the very least, this case raises a requirement in the registration > > > > > >protocol to have the v1 endpoint tell the GCKS its version number and/or > > > > > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > > > > >subsets with their respective RMT rekey policies. RMT aside, I would think > > > > > >we need this capability to allow v1 endpoints to participate with v1 rekey > > > > > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > > > > > > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > > > > > > > > > >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 Aug 14 11:15:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14557 for ; Thu, 14 Aug 2003 11:15:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9BD81535FE; Thu, 14 Aug 2003 11:14: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 D776C536D4 for ; Thu, 14 Aug 2003 11:13:21 -0400 (EDT) Received: (qmail 46062 invoked by uid 3269); 14 Aug 2003 15:13:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46059 invoked from network); 14 Aug 2003 15:13:21 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 14 Aug 2003 15:13:21 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h7EFAtV92448; Thu, 14 Aug 2003 11:10:55 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h7EFD4a1211944; Thu, 14 Aug 2003 11:13:04 -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 LAA25936; Thu, 14 Aug 2003 11:13:03 -0400 From: canetti To: George Gross Cc: Mark Baugher , msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: 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, 14 Aug 2003 11:13:03 -0400 (EDT) See inline: On Thu, 14 Aug 2003, George Gross wrote: > Hi Ran, > > On Wed, 13 Aug 2003, canetti wrote: > > > George, > > > > Your proposal to add a (currently unused) field to the policy token > > specifying the RMT protocl in use ofr rekeying sounds like a reasonable > > thing to do. The cost is minimal, and although the chance it will ever be > > used are small, if we do need it and dont have it it will be ugly. > > good, I think this parameter will prove its worth in the long-term... > > given the discussions on the policy token in a parallel thread, I'd like > to hear the GSAKMP folk weigh in on this parameter too... > > > > > But I'm weary of the requirement that future versions must be backwards > > compatible. You sometime want future versions to explicitly NOT be > > backwards compatible, eg when there is a security hole found in the old > > version. In fact, in such a case you;d want to protect against "version > > rollback" attacks. (cf the SSL v2/v3 story). > > Yup, see what you mean...so each GSAKMP (or GDOI) GCKS needs to be able to > refuse a GM request to join for those protocol versions that are on the > "drain bamaged" version list ;o) and in the inverse direction, GM should > be able to decline membership in a group whose GCKS software version is on > that list. > > Would the "drain bamaged version list" make sense to add to the policy > token? I'm leaning towards "yes", as it would allow a GM to offer a > mutually acceptable version in the request to join... > In principle you're right. But this is another one of those "extension fields" that may well never be necessary. Perhaps it will suffice to leave some "currently unused" fields in the policy token. If the need ever comes up, it should be easy to update the standard (and its implementations) to pur concrete meaning to those fields. Ran > George > > > > > Ran > > > > > > On Wed, 6 Aug 2003, George Gross wrote: > > > > > Mark, > > > > > > On Wed, 6 Aug 2003, Mark Baugher wrote: > > > > > > > George, > > > > GDOI has a version number in it. So does GSAKMP. > > > > > > Oops, sorry, my e-mail was not precise. What I really should have said was > > > "the semantics for mismatched version numbers between GCKS and group > > > member are currently underspecified...". > > > > > > In GSAKMP, there are Notify payloads for invalid version numbers, but I > > > did not find any text explaining when that would be triggered. I think > > > that this needs to be added, in alignment with the requirement for > > > backward compatibility. > > > > > > In GDOI there is no explicit discussion of version number processing. In > > > fact, RFC3547 does not have the word "error" in it at all. Amazing, an > > > error free protocol ;o) The text in section 3.2.2 seems to hint ISAKMP > > > version error processing is implied? it would be reasonable for GDOI v2 to > > > say more here.... > > > > > > > Perhaps we should > > > > mention this need in gkmarch. > > > > > > Yes, I might go so far as to say that backward compatibility would be > > > important to have specified as a MUST. If we are talking about large-scale > > > multicast, it is likely that a protocol software upgrade transition from > > > v1->v2 will straddle large numbers of endpoints, and could take many > > > weeks/months. > > > > > > In other words, the GCKS is required to accept any group member protocol > > > version less than or equal to the highest version the GCKS supports. > > > > > > George > > > > > > > > > > > Mark > > > > At 07:56 AM 8/6/2003 -0400, George Gross wrote: > > > > >Hi Mark, > > > > > > > > > > > > > > >On Tue, 5 Aug 2003, Mark Baugher wrote: > > > > > > > > > > > hi George, > > > > > > I think the interoperability issue that you mention below could happen > > > > > > on any element of policy. Somehow the policy is determined and if it has > > > > > > advanced or new features than some legacy members don't support, then there > > > > > > will be an interoperability problem. > > > > > > > > > > > > Best regards, Mark > > > > > > > > > >Ok, so would you agree then that a version number should be introduced in > > > > >the group member's registration "request to join" message? > > > > > > > > > >Also, in a related post to this list, I had proposed the protocol feature > > > > >of having a "critical" or mandatory to implement flag in the key > > > > >management protocol's Type/Length/Value encodings. This mechanism > > > > >specifically addresses this backward compatibility interoperability issue. > > > > > > > > > >I would not expect this to be a controversial concept to require in > > > > >GSAKMP or GDOI. It is a basic protocol design feature, examples of which > > > > >can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is > > > > >illegal to mark a vendor specific TLV critical. > > > > > > > > > >br, > > > > > George > > > > > > > > > > > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > > > > > > >Hi Mark, > > > > > > > > > > > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > > > > > > > > > > > George, > > > > > > > > > > > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch > > > > > specify > > > > > > > > >the base error recovery is a minimum starting point. However, I > > > > > would also > > > > > > > > >require that the group policy token have the hooks (i.e. reserved > > > > > TLV) for > > > > > > > > >describing the group's mandatory RMT protocol and its operating > > > > > > > > >parameters. This finesses the "there are many deployment scenarios..." > > > > > > > > >issues by specifying the extensibility that must be built into the GKM > > > > > > > > >protocol and its policy token. > > > > > > > > > > > > > > > > > >To get this capability, at first sight it seems we need: an RMT > > > > > protocol > > > > > > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > > > > > > >group policy token spec. thoughts? > > > > > > > > > > > > > > > > I would not put an identifier into a group key management protocol > > > > > for an > > > > > > > > RMT protocol when there are no standard RMT protocols. If reliable > > > > > > > > multicast were more important to group key management then I > > > > > perceive it to > > > > > > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > > > > > > SPKI). But I don't think we lose anything with the status quo, > > > > > which is to > > > > > > > > use a sequence number and periodic retransmission of the re-key > > > > > message. > > > > > > > > > > > > > > > > Mark > > > > > > > > > > > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > > > > > >RMT protocol is standardized, and that the MSEC policy token v2 was > > > > > > >"extended" to include the formerly unspecified but now standard RMT > > > > > > >identifier. The endpoints that are running MSEC v1 will be unable to > > > > > > >reliably participate in the group, as they get dropped after the first > > > > > > >lost rekey packet. There will not be retransmission of the rekey message > > > > > > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > > > > > > >next rekey message's sequence number mismatch could be an unacceptably > > > > > > >long wait... > > > > > > > > > > > > > >At the very least, this case raises a requirement in the registration > > > > > > >protocol to have the v1 endpoint tell the GCKS its version number and/or > > > > > > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > > > > > >subsets with their respective RMT rekey policies. RMT aside, I would think > > > > > > >we need this capability to allow v1 endpoints to participate with v1 rekey > > > > > > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > > > > > > > > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > > > > > > > > > > > >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 Aug 14 11:36:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15444 for ; Thu, 14 Aug 2003 11:36:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BAD69536F1; Thu, 14 Aug 2003 11:36: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 5A5C7535CF for ; Thu, 14 Aug 2003 11:35:14 -0400 (EDT) Received: (qmail 52027 invoked by uid 3269); 14 Aug 2003 15:35:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52024 invoked from network); 14 Aug 2003 15:35:14 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 14 Aug 2003 15:35:14 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h7EFX4V65458 for ; Thu, 14 Aug 2003 11:33:04 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h7EFZDa1200824 for ; Thu, 14 Aug 2003 11:35:13 -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 LAA27602 for ; Thu, 14 Aug 2003 11:35:13 -0400 From: canetti To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Simple(r) resynch methods and the policy token 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, 14 Aug 2003 11:35:12 -0400 (EDT) Folks, Currently the GKMARCH draft says that if a group member becomes out-of-synch with the group key then it should re-register with the GCKS. However, in many cases there are other, simpler methods for re-synching with the group: - The member can open a simple, unprotected connection (say, TCP) with the GCKS and obtain the current (or several recent) rekey messages. Note that there is no need in authentication or encryption here, since the rekey message is already signed and is anyway multicased in the clear. [Remark: One may think that this opens the GCKS to DoS attacks by many bogus such requests. But this doesnt seem to worsen the situation: in fact, bombarding the GCKS with bogus resynch requests would be much more problematic...] - The GCKS can post the rekey messages on some public site (say, web site) and the out-of-synch memeber can obtain the rekey messages from that site. We'd like to include these re-synching methods in the upcoming version of GKMARCH. We see two ways to go about this. Our question to the list is which one seems preferable: Option 1: It is mandated that the GCKS Always provides all three ways of resynching (ie, re-registration, simple TCP, and public posting). This way, it is up to the member to choose how to resynch and we do not need any additional fleilds in the policy token. Option 2: Add a field in the policy token specifying which method(s) should be used for re-synching. What do people say? Mark, Ran, Lakshminath, Frederik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 14 11:39:22 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15520 for ; Thu, 14 Aug 2003 11:39:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CBD6E535CF; Thu, 14 Aug 2003 11:38:49 -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 0CE0E5360F for ; Thu, 14 Aug 2003 11:37:37 -0400 (EDT) Received: (qmail 52506 invoked by uid 3269); 14 Aug 2003 15:37:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52503 invoked from network); 14 Aug 2003 15:37:36 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 14 Aug 2003 15:37:36 -0000 Received: (qmail 42229 invoked from network); 14 Aug 2003 15:37:35 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.174) by mail.nac.net with SMTP; 14 Aug 2003 15:37:35 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7EDStq25914; Thu, 14 Aug 2003 09:28:55 -0400 From: George Gross To: canetti Cc: Mark Baugher , Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: 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, 14 Aug 2003 09:28:54 -0400 (EDT) Hi Ran, On Thu, 14 Aug 2003, canetti wrote: > > In principle you're right. But this is another one of those "extension > fields" that may well never be necessary. Perhaps it will suffice to leave > some "currently unused" fields in the policy token. If the need ever comes > up, it should be easy to update the standard (and its implementations) to > pur concrete meaning to those fields. I am not comfortable with a fixed data structure policy token, that does not have the ability to extend gracefully. As I mentioned in the parallel policy token e-mail thread, I think a strong extensibility case can be made for TLV encoded group policy token. The set of TLV not explicitly present in a given token would have an implicit default value and semantics. In the cases we've been discussing, we've identified two candidate TLV: RMT policy, version blacklist. Once we've decided the "minumum MUST implement set", I could easily imagine many other TLV being added in an incremental way as our understanding of the problem space matures... George > > Ran > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 14 11:42:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15602 for ; Thu, 14 Aug 2003 11:42:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DD3625374F; Thu, 14 Aug 2003 11:41:38 -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 4CF195360F for ; Thu, 14 Aug 2003 11:39:17 -0400 (EDT) Received: (qmail 52791 invoked by uid 3269); 14 Aug 2003 15:39:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52786 invoked from network); 14 Aug 2003 15:39:17 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 14 Aug 2003 15:39:17 -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 h7EFdC317033; Thu, 14 Aug 2003 08:39:13 -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 QZVA7ZRP; Thu, 14 Aug 2003 08:39:13 -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 QZX3KM9V; Thu, 14 Aug 2003 11:39:11 -0400 Message-ID: <3F3BAD1C.2090609@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 Subject: Re: [MSEC] Simple(r) resynch methods and the policy token 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, 14 Aug 2003 11:39:08 -0400 Content-Transfer-Encoding: 7bit One small change in the wording: s/mandated/suggested/ regards, Lakshminath canetti wrote: >Folks, > > >Currently the GKMARCH draft says that if a group member becomes >out-of-synch with the group key then it should re-register with the GCKS. >However, in many cases there are other, simpler methods for re-synching >with the group: > >- The member can open a simple, unprotected connection (say, TCP) >with the GCKS and obtain the current (or several recent) rekey messages. >Note that there is no need in authentication or encryption here, since the >rekey message is already signed and is anyway multicased in the clear. >[Remark: One may think that this opens the GCKS to DoS attacks by many >bogus such requests. But this doesnt seem to worsen the situation: in >fact, bombarding the GCKS with bogus resynch requests would be much more >problematic...] > >- The GCKS can post the rekey messages on some public site (say, web site) >and the out-of-synch memeber can obtain the rekey messages from that >site. > >We'd like to include these re-synching methods in the upcoming version of >GKMARCH. We see two ways to go about this. Our question to the list is >which one seems preferable: > >Option 1: It is mandated that the GCKS Always provides all three >ways of resynching (ie, re-registration, simple TCP, and public >posting). This way, it is up to the member to choose how to resynch >and we do not need any additional fleilds in the policy token. > >Option 2: Add a field in the policy token specifying which method(s) >should be used for re-synching. > > >What do people say? > > >Mark, Ran, Lakshminath, Frederik > > >_______________________________________________ >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 Aug 14 13:33:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19149 for ; Thu, 14 Aug 2003 13:33:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9FF1C53669; Thu, 14 Aug 2003 13:32:51 -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 8501E53680 for ; Thu, 14 Aug 2003 13:30:09 -0400 (EDT) Received: (qmail 71198 invoked by uid 3269); 14 Aug 2003 17:30:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71195 invoked from network); 14 Aug 2003 17:30:09 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 14 Aug 2003 17:30:09 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7EHU2il010825; Thu, 14 Aug 2003 10:30:02 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.25.170.47]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQ0H9CBG; Thu, 14 Aug 2003 10:30:01 -0700 Message-Id: <5.2.1.1.2.20030814102610.02cc8bd0@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: "Lakshminath Dondeti" , canetti From: Thomas Hardjono Subject: Re: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd) Cc: msec@securemulticast.org In-Reply-To: <3F393473.9050108@americasm06.nt.com> 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, 14 Aug 2003 10:29:53 -0700 Following Lakshminath's excellent suggestion, I have modified the page into a table with three columns: (a) The name of the draft (b) Destination track (c) Current Status. Please take a look and verify/correct (ps. bound to be some errors :) http://www.securemulticast.org/msec-drafts.htm thomas ------ At 8/12/2003||02:39 PM, Lakshminath Dondeti wrote: >It would have been more informative if each of the work items had a track >tag (informational/experimental/standards) next to it. Hope you can do >that for the charter page on the IETF site. > >Thanks, >Lakshminath > >canetti wrote: > >>---------- Forwarded message ---------- >>Date: Tue, 12 Aug 2003 09:51:21 -0400 >>From: The IESG >>To: IETF-Announce: ; >>Cc: canetti@watson.ibm.com, thardjono@verisign.com >>Subject: WG Action: RECHARTER: Multicast Security (msec) >> >>The charter of the Multicast Security (msec) working group in the >>Security Area of the IETF has been updated. For additional >>information, please contact the Area Directors or the working >>group Chairs. >> >>Multicast Security (msec) >>------------------------- >>Current Status: Active Working Group >> >>Chairs: >> >>Ran Canetti >>Thomas Hardjono >> >>Security Area Director(s): >> >>Russell Housley >>Steven Bellovin >> >>Mailing Lists: >> >>General Discussion: msec@securemulticast.org >>To Subscribe: msec-request@securemulticast.org >>In Body: subscribe >>Archive: >> >>Description of Working Group: >> >>The purpose of the MSEC WG is to standardize protocols for securing >>group communication over internets, and in particular over the global >>Internet. Initial efforts will focus on scalable solutions for groups >>with a single source and a very large number of recipients. Additional >>emphasis will be put on groups where the data is transmitted via >>IP-layer multicast routing protocols (with or without guaranteed >>reliability). The developed standard will assume that each group has a >>single trusted entity (the Group Controller) that sets the security >>policy and controls the group membership. The standard will strive >>to provide at least the following basic security guarantees: >> >>+ Only legitimate group members will have access to current group >>communication. This includes groups with highly dynamic membership. >> >>+ Legitimate group members will be able to authenticate the source >>and contents of the group communication. This includes cases where >>group members do not trust each other. >> >>An additional goal of the standard will be to protect against >>denial-of-service attacks, whenever possible. >> >>Due to the large number of one-to-many multicast applications and the >>sometimes conflicting requirements these applications exhibit, it is >>believed that a single protocol will be unable to meet the requirements >>of all applications. Therefore, the WG will first specify a general >>Reference Framework that includes a number of functional building >>blocks. Each such building block will be instantiated by one or more >>protocols that will be interchanable. The Reference Framework will not >>only describe one-to-many multicast, but also many-to-many multicast. >> >>In addition, as a secondary goal the MSEC WG will also focus on >>distributed architectures for group key management and group policy >>management, where for scalability purposes multiple trusted entities >>(such as Key Distributors) are deployed in a distributed fashion. For >>this purpose, the Reference Framework will not only describe >>one-to-many multicast, but also many-to-many multicast. >> >>MSEC will generate at least the following documents, which could be >>considered as base documents: >> >>1. An RFC describing the security requirements of multicast security and >>an RFC describing the MSEC Architecture. >> >>2. An RFC describing the Group Key Management Architecture and an RFC >>describing Group Policy Management Architecture in MSEC. >> >>3. Several RFCs describing specifications for protocols that implement >>source authentication, group key management and group policy management. >>As multicast security covers a broad range of issues, and therefore >>touches other Working Groups in the IETF, the MSEC WG will work closely >>with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well >>as other Working Groups which maybe considered a "consumer" of the >>technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may >>have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). >> >>With this in mind, the MSEC WG is open to receiving new work items, >>whenever it is considered appropriate to be homed in the MSEC WG. Such >>drafts will be matured in conjunction with the MSEC base documents. >> >>Goals and Milestones: >> >>DONE Working Group Last Call on GDOI Protocol. >> >>DONE Working Group Last Call on MIKEY Protocol. >> >>Sep 03 WG Last Call on Group Key Management Architecture draft. >> >>Sep 03 WG Last Call on MSEC Architecture draft. >> >>Sep 03 WG Last Call on DHHMAC for MIKEY. >> >>Sep 03 WG Last Call on Data Security Architecture draft >> >>Dec 03 WG Last Call on Security Requirements draft. >> >>Mar 04 WG Last Call on Group Security Policy Architecture draft >> >>Mar 04 WG Last Call on MESP (Multicast ESP) draft. >> >>Mar 04 WG Last call on MESP-TESLA draft. >> >>Mar 04 WG Last Call on GSAKMP-Light protocol. >> >>Jul 04 WG re-charter for other work items (or disband). >> >> >> >> >> >>_______________________________________________ >>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 Aug 14 14:09:16 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20716 for ; Thu, 14 Aug 2003 14:09:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 847EC53789; Thu, 14 Aug 2003 14:04: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 6BA1253669 for ; Thu, 14 Aug 2003 14:02:04 -0400 (EDT) Received: (qmail 76271 invoked by uid 3269); 14 Aug 2003 18:02:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76267 invoked from network); 14 Aug 2003 18:02:04 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 14 Aug 2003 18:02:04 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h7EI0XJD008530; Thu, 14 Aug 2003 13:00:33 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h7EI1Ik5001610; Thu, 14 Aug 2003 13:01:20 -0500 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id OAA11488; Thu, 14 Aug 2003 14:01:16 -0400 (EDT) Message-ID: <3F3BCDDB.9020000@columbia.sparta.com> From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross , "msec@securemulticast.org" Subject: Re: [MSEC] George's comments / splitting token from protocol References: Content-Type: multipart/alternative; boundary="------------040309070601080306070003" 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, 14 Aug 2003 13:58:51 -0400 --------------040309070601080306070003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George, George Gross wrote: >Hi Andrea, > >On Wed, 13 Aug 2003, Andrea Colegrove wrote: > > > >>George, >> I believe that changing the token payload to contain an identifier of >>the token type will accomplish what we intended, in that multiple token >>types may be supported, with the GSAKMP v1 token as the initial choice. >> >> > >So if I read between the electrons, you're saying whatever we got for a >policy token today is what you want to standardize, rather than move it to >Experimental? hmmm... see below. > > > The space between the electrons didn't actually contain that much information. Just as ISAKMP is independent of the certificates used in the protocol framework, so GSAKMP should be independent of the infrastructure support mechanisms. The infrastructure is needed, but is not coupled with the protocols. ISAKMP wasn't held up because of SDSI/SPKI progress. > > > > >> I believe that we need to revise the token payload to allow >>extensibility here so that as new token types become available, these may be >>supported. >> >> The GSAKMP token will provide a means of initial operation, but will >>probably not provide a generic enough standard in the long run. As we all >>agree, a nice TLV spec, perhaps ASN.1 DER, may be in order here. >> >> > >Introducing a group policy token encoding along these lines (TLV encoded) >would go a long way towards adding extensibility. I perceive that is >mandatory given the token will be handling many flavors of policy and at >least two protocols in the future. In other words, if the next rev of the >Group Policy Token ID moved to this more flexible position, it would >support GSAKMP's advancement to PS, and GSAKMP could advance to PS when >this rev'd GPT advances. It would enable GDOI-v2 related extensibility >too. > >Caveat: this statement assumes that the other issues that I've brought up >wrt/ to the GSAKMP and the policy token have gotten to rough consensus. >Also, I have not yet delved into the GPT as deeply as GSAKMP yet, I may >yet discover nooks and crannies that have other issues. > >To date, there have been several GPT related changes brought up by me. If >you are unable to change the existing GPT definition due to installed >base, then it really should be "Experimental", and the generic GPT should >be the only one that the rest of us have to implement. > > > > GPT and GSAKMP should be independent issues. > > >> I believe however that GSAKMP should not be held up because of a lack of >>a generic token. >> >> > >My experiences in prior lives in other IETF protocol design exercises >argues strongly against this approach. In the context of L2TP, some of the >things I argued should go into L2TP v1 to support broadband (as opposed to >dial-up) PPP did not make it, and L2TP v2 with those features did not >publish until 4 years later. The good news was that in the interrim, you >could get that capability by defining vendor-specific TLV between the LAC >and LNS. > > Along similar lines of other working group experience: The current token would be analagous to some of PPP's initial authentication mechanisms (CHAP and the like). A more extensible token would be analagous to EAP. EAP can now be used by both PPP and other protocols. >So what ever we put into policy token V1 is what we are stuck with for >years into the future. And while others on this list have said that GSAKMP >and GDOI are "in separate markets" I do not buy that POV, as it is one >Internet. We will face the pain of groups that straddle both GSAKMP and >GDOI endpoints. I'd rather my GCKS has one policy token syntax, even if it >has a mixture of TLV that are common, GSAKMP-specific, GDOI-specific, and >vendor-specific. > Disagree. Progress of the IETF working groups relies on being able to decompose problems into independently solvable pieces. Otherwise, we have working groups that never satisfy their charters ... that seems to make AD's a little touchy. > >We agree that a TLV style encoding will be required, so I say it is _now_ >that we should introduce that capability. It is much better to re-vamp the >definition now, than to have running code widely deployed with this known >handicap of a fixed structure that is glued to GSAKMP v1. > Code base and protocol specification are different. We shouldn't be worried about code bases here, but rather on standards and interoperability of implementations of those standards. I think that the problem at hand is more that we need to consider as a working group of how to be able to decompose the group security management problems so that we are not hobbled by needing to advance lockstep through the process because of a lack of prior standardization of group mechanisms. It was very good of you to point out the normative problem, but it appears that the intent of these requirements on references is to make sure that the reference is stable and does not change. I do not see how an Experimental protocol violates that. --- Andrea --------------040309070601080306070003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit George,

George Gross wrote:
Hi Andrea,

On Wed, 13 Aug 2003, Andrea Colegrove wrote:

  
George,
    I believe that changing the token payload to contain an identifier of
the token type will accomplish what we intended, in that multiple token
types may be supported, with the GSAKMP v1 token as the initial choice.
    

So if I read between the electrons, you're saying whatever we got for a
policy token today is what you want to standardize, rather than move it to
Experimental? hmmm... see below.
The space between the electrons didn't actually contain that much information.  Just as ISAKMP is independent of the certificates used in the protocol framework, so GSAKMP should be independent of the infrastructure support mechanisms.  The infrastructure is needed, but is not coupled with the protocols.  ISAKMP wasn't held up because of SDSI/SPKI progress.
  
  
    I believe that we need to revise the token payload to allow
extensibility here so that as new token types become available, these may be
supported.

    The GSAKMP token will provide a means of initial operation, but will
probably not provide a generic enough standard in the long run.  As we all
agree, a nice TLV spec, perhaps ASN.1 DER, may be in order here.
    

Introducing a group policy token encoding along these lines (TLV encoded)
would go a long way towards adding extensibility. I perceive that is
mandatory given the token will be handling many flavors of policy and at
least two protocols in the future. In other words, if the next rev of the
Group Policy Token ID moved to this more flexible position, it would
support GSAKMP's advancement to PS, and GSAKMP could advance to PS when
this rev'd GPT advances. It would enable GDOI-v2 related extensibility
too.

Caveat: this statement assumes that the other issues that I've brought up
wrt/ to the GSAKMP and the policy token have gotten to rough consensus.
Also, I have not yet delved into the GPT as deeply as GSAKMP yet, I may
yet discover nooks and crannies that have other issues.

To date, there have been several GPT related changes brought up by me. If
you are unable to change the existing GPT definition due to installed
base, then it really should be "Experimental", and the generic GPT should
be the only one that the rest of us have to implement.

 >
GPT and GSAKMP should be independent issues.
  
    I believe however that GSAKMP should not be held up because of a lack of
a generic token.
    

My experiences in prior lives in other IETF protocol design exercises
argues strongly against this approach. In the context of L2TP, some of the
things I argued should go into L2TP v1 to support broadband (as opposed to
dial-up) PPP did not make it, and L2TP v2 with those features did not
publish until 4 years later. The good news was that in the interrim, you
could get that capability by defining vendor-specific TLV between the LAC
and LNS.
Along similar lines of other working group experience:  The current token would be analagous to some of PPP's initial authentication mechanisms (CHAP and the like).  A more extensible token would be analagous to EAP.  EAP can now be used by both PPP and other protocols.
So what ever we put into policy token V1 is what we are stuck with for
years into the future. And while others on this list have said that GSAKMP
and GDOI are "in separate markets" I do not buy that POV, as it is one
Internet. We will face the pain of groups that straddle both GSAKMP and
GDOI endpoints. I'd rather my GCKS has one policy token syntax, even if it
has a mixture of TLV that are common, GSAKMP-specific, GDOI-specific, and
vendor-specific.
Disagree.
Progress of the IETF working groups relies on being able to decompose problems into independently solvable pieces.  Otherwise, we have working groups that never satisfy their charters ... that seems to make AD's a little touchy.

We agree that a TLV style encoding will be required, so I say it is _now_
that we should introduce that capability. It is much better to re-vamp the
definition now, than to have running code widely deployed with this known
handicap of a fixed structure that is glued to GSAKMP v1.
Code base and protocol specification are different.  We shouldn't be worried about code bases here, but rather on standards and interoperability of implementations of those standards.

I think that the problem at hand is more that we need to consider as a working group of how to be able to decompose the group security management problems so that we are not hobbled by needing to advance lockstep through the process because of a lack of prior standardization of group mechanisms. It was very good of you to point out the normative problem, but it appears that the  intent of these requirements on references is to make sure that the reference is stable and does not change.  I do not see how an Experimental protocol violates that.

--- Andrea
--------------040309070601080306070003-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 14 14:11:00 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20834 for ; Thu, 14 Aug 2003 14:11:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 71172537CB; Thu, 14 Aug 2003 14:06:15 -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 6E8AF53785 for ; Thu, 14 Aug 2003 14:04:20 -0400 (EDT) Received: (qmail 76753 invoked by uid 3269); 14 Aug 2003 18:04:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76750 invoked from network); 14 Aug 2003 18:04:20 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 14 Aug 2003 18:04:20 -0000 Received: (qmail 23793 invoked from network); 14 Aug 2003 18:04:16 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.174) by mail.nac.net with SMTP; 14 Aug 2003 18:04:16 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7EFtXa26165; Thu, 14 Aug 2003 11:55:33 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] test 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, 14 Aug 2003 11:55:33 -0400 (EDT) ping'ing the list. pls regard, thx George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 14 14:21:11 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20998 for ; Thu, 14 Aug 2003 14:21:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3EE0B53677; Thu, 14 Aug 2003 14:20:39 -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 6AC0653677 for ; Thu, 14 Aug 2003 14:19:41 -0400 (EDT) Received: (qmail 80722 invoked by uid 3269); 14 Aug 2003 18:19:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80719 invoked from network); 14 Aug 2003 18:19:41 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 14 Aug 2003 18:19:41 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7EIJdil021883; Thu, 14 Aug 2003 11:19:39 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.25.170.47]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QQ0H91XQ; Thu, 14 Aug 2003 11:19:39 -0700 Message-Id: <5.2.1.1.2.20030814111056.02cc8ca0@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: "hugh harney" , "George Gross" From: Thomas Hardjono Subject: Re: [MSEC] George's comments / splitting token from protocol Cc: msec@securemulticast.org, thardjono@yahoo.com In-Reply-To: <007101c361d1$7832a530$0150b99d@DGKFL721> 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, 14 Aug 2003 11:19:31 -0700 Just to add more juice to this discussion, we did have a GSPT document that expired. http://www.securemulticast.org/draft-ietf-msec-gspt-01.txt I think a possible way forward could be: (1) Make the GSPT draft the general document explaining the notion of a token, why, its uses, its relationship with KM-protocols and defining the base-profile of a token and possible extensions. (2) Rename "GSAKMP Token Specification" to become more specific, say something like "GSAKMP Token for IPsec". (3) Write/define other token-drafts for other KM-protocols (e.g. for GDOI). One of the reasons GSPT expired was the lack of people-power. Perhaps we could resurrect it. (PS. George, would you be open to contributing? ) thomas ------ At 8/13/2003||03:31 PM, hugh harney wrote: >George, > >I agree with Andrea. > >If we were to add a policy token identity field in the GSAKMP spec, then >several policy tokens could be supported. I believe the first policy token >identified could be very close to the current GSAKMP Policy Token (well the >as yet to be released version 2). All upgrades to the PT could be identified >seperatly. > >I'll address your other issues as soon as I can. > >hugh > > >_______________________________________________ >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 Aug 14 14:35:01 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21414 for ; Thu, 14 Aug 2003 14:35:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1794853659; Thu, 14 Aug 2003 14:32:29 -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 F044053636 for ; Thu, 14 Aug 2003 14:31:12 -0400 (EDT) Received: (qmail 82315 invoked by uid 3269); 14 Aug 2003 18:31:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82312 invoked from network); 14 Aug 2003 18:31:12 -0000 Received: from ckmso1.att.com (HELO ckmso1.proxy.att.com) (12.20.58.69) by klesh.pair.com with SMTP; 14 Aug 2003 18:31:12 -0000 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7EIUn82005823 for ; Thu, 14 Aug 2003 14:31:12 -0400 Received: from acclust04evs1.ugd.att.com (135.37.16.12) by attrh2i.attrh.att.com (6.5.032) id 3F25C3E40034FAD8 for msec@securemulticast.org; Thu, 14 Aug 2003 14:30:19 -0400 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] George's comments / splitting token from protocol Message-ID: Thread-Topic: [MSEC] George's comments / splitting token from protocol Thread-Index: AcNikSVUt+c3EKQQQyyhd5U12YAyvwAAHMSA From: "Lough, Peter B, SOLGV" To: 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, 14 Aug 2003 14:31:12 -0400 Content-Transfer-Encoding: quoted-printable As an FYI, an updated version of the GSPT is in the works. It's undergoing some revisions and should be submitted to the list with the next couple of weeks. This update conforms a bit more to your second point with more information and text added from your first point. I don't think it goes as far as being a generally extensible token for MSEC, but hope for it to be used as a framework for a follow-on document in the group that would address that. We certainly will welcome the thorough reviews once the paper hits the list and hopefully it will be able to advance toward a standard in support of GSAKMP and help launch work on a general MSEC token. Peter Lough AT&T Government Solutions > -----Original Message----- > From: Thomas Hardjono [mailto:thardjono@verisign.com] > Sent: Thursday, August 14, 2003 2:20 PM > To: hugh harney; George Gross > Cc: msec@securemulticast.org; thardjono@yahoo.com > Subject: Re: [MSEC] George's comments / splitting token from protocol >=20 >=20 >=20 > Just to add more juice to this discussion, we did have a GSPT=20 > document that=20 > expired. http://www.securemulticast.org/draft-ietf-msec-gspt-01.txt >=20 > I think a possible way forward could be: >=20 > (1) Make the GSPT draft the general document explaining the notion > of a token, why, its uses, its relationship with KM-protocols > and defining the base-profile of a token and possible extensions. >=20 > (2) Rename "GSAKMP Token Specification" to become more specific, say > something like "GSAKMP Token for IPsec". >=20 > (3) Write/define other token-drafts for other KM-protocols=20 > (e.g. for GDOI). >=20 > One of the reasons GSPT expired was the lack of people-power.=20 > Perhaps we=20 > could resurrect it. >=20 > (PS. George, would you be open to contributing? ) >=20 > thomas > ------ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > At 8/13/2003||03:31 PM, hugh harney wrote: > >George, > > > >I agree with Andrea. > > > >If we were to add a policy token identity field in the=20 > GSAKMP spec, then > >several policy tokens could be supported. I believe the=20 > first policy token > >identified could be very close to the current GSAKMP Policy=20 > Token (well the > >as yet to be released version 2). All upgrades to the PT=20 > could be identified > >seperatly. > > > >I'll address your other issues as soon as I can. > > > >hugh > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec >=20 >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 14 14:44:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21651 for ; Thu, 14 Aug 2003 14:44:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DE96653751; Thu, 14 Aug 2003 14:44:22 -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 3447053636 for ; Thu, 14 Aug 2003 14:43:05 -0400 (EDT) Received: (qmail 83914 invoked by uid 3269); 14 Aug 2003 18:43:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83911 invoked from network); 14 Aug 2003 18:43:05 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 14 Aug 2003 18:43:05 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7EIgxi16293; Thu, 14 Aug 2003 14:42:59 -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 Q8AX5H0J; Thu, 14 Aug 2003 14:42:59 -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 QZX3KNFY; Thu, 14 Aug 2003 14:42:59 -0400 Message-ID: <3F3BD832.9080300@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: "Lough, Peter B, SOLGV" Cc: msec@securemulticast.org Subject: Re: [MSEC] George's comments / splitting token from protocol 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, 14 Aug 2003 14:42:58 -0400 Content-Transfer-Encoding: 7bit At this point I am close to being thoroughly confused! My understanding was that the Policy Token is a generic structure, and that an instantiation was being specified for downloading an IPsec SA via GSAKMP (protocol). Is that still the case? If so, I would say the generic policy token should be an informational track I-D and all instantiations should be standards track I-Ds. regards, Lakshminath Lough, Peter B, SOLGV wrote: >As an FYI, an updated version of the GSPT is in the works. It's >undergoing some revisions and should be submitted to the list with the >next couple of weeks. > >This update conforms a bit more to your second point with more >information and text added from your first point. I don't think it goes >as far as being a generally extensible token for MSEC, but hope for it >to be used as a framework for a follow-on document in the group that >would address that. > >We certainly will welcome the thorough reviews once the paper hits the >list and hopefully it will be able to advance toward a standard in >support of GSAKMP and help launch work on a general MSEC token. > >Peter Lough >AT&T Government Solutions > > > >>-----Original Message----- >>From: Thomas Hardjono [mailto:thardjono@verisign.com] >>Sent: Thursday, August 14, 2003 2:20 PM >>To: hugh harney; George Gross >>Cc: msec@securemulticast.org; thardjono@yahoo.com >>Subject: Re: [MSEC] George's comments / splitting token from protocol >> >> >> >>Just to add more juice to this discussion, we did have a GSPT >>document that >>expired. http://www.securemulticast.org/draft-ietf-msec-gspt-01.txt >> >>I think a possible way forward could be: >> >>(1) Make the GSPT draft the general document explaining the notion >> of a token, why, its uses, its relationship with KM-protocols >> and defining the base-profile of a token and possible extensions. >> >>(2) Rename "GSAKMP Token Specification" to become more specific, say >> something like "GSAKMP Token for IPsec". >> >>(3) Write/define other token-drafts for other KM-protocols >>(e.g. for GDOI). >> >>One of the reasons GSPT expired was the lack of people-power. >> Perhaps we >>could resurrect it. >> >>(PS. George, would you be open to contributing? ) >> >>thomas >>------ >> >> >> >> >> >> >> >>At 8/13/2003||03:31 PM, hugh harney wrote: >> >> >>>George, >>> >>>I agree with Andrea. >>> >>>If we were to add a policy token identity field in the >>> >>> >>GSAKMP spec, then >> >> >>>several policy tokens could be supported. I believe the >>> >>> >>first policy token >> >> >>>identified could be very close to the current GSAKMP Policy >>> >>> >>Token (well the >> >> >>>as yet to be released version 2). All upgrades to the PT >>> >>> >>could be identified >> >> >>>seperatly. >>> >>>I'll address your other issues as soon as I can. >>> >>>hugh >>> >>> >>>_______________________________________________ >>>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 > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 14 14:58:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22005 for ; Thu, 14 Aug 2003 14:58:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 89C4053677; Thu, 14 Aug 2003 14:58: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 D6F18535CF for ; Thu, 14 Aug 2003 14:56:16 -0400 (EDT) Received: (qmail 85975 invoked by uid 3269); 14 Aug 2003 18:56:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85972 invoked from network); 14 Aug 2003 18:56:16 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 14 Aug 2003 18:56:16 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h7EIsRJD009729; Thu, 14 Aug 2003 13:54:27 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h7EItZk5003924; Thu, 14 Aug 2003 13:55:35 -0500 Received: from DGKFL721 (dhcp-1.columbia.sparta.com [157.185.80.1]) by columbia.sparta.com (8.9.1a/8.9.1) with SMTP id OAA12461; Thu, 14 Aug 2003 14:55:22 -0400 (EDT) Message-ID: <01b701c36295$9d9b84d0$0150b99d@DGKFL721> From: "hugh harney" To: "George Gross" , "canetti" Cc: "George Gross" , "Mark Baugher" , References: Subject: Re: [MSEC] Next gkmarch I-D MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 14 Aug 2003 14:55:21 -0400 Content-Transfer-Encoding: 7bit George, I believe that we are just scratching surface of the capabilities of a security policy token. There are many more fields that can be useful given different applications (IPSec, SMIME, collaborative environments...) and different communication architectures (IP networks, space networks, wireless...). This is NOT GSAKMP centric. This expandable Policy Token that will be good for the foreseeable future is a goal onto itself. GSAKMP should reference a GSAKMP policy token that is optimized for the current target applications. GSAKMP "the protocol" will specify a policy token ID field to allow the incorporation of future Policy Tokens. There are two efforts taking place - GSAKMP is moving forward using a workable Policy Token AND the MSEC community is beginning to discuss and specify generic security policy tokens. The two efforts are separate. The GSAKMP protocol should not be held up from advancement unnecessarily. I feel that the convergence to a general Policy Token that will accommodate a wide range of applications and communication environments will evolve over several years. I'm strongly in favor of decoupling these two efforts. Let GSAKMP proceed to standardization with a simple policy token, and with the mechanisms to accommodate upgraded versions. Let the working group proceed with the definition of the next version of a Policy Token. GSAKMP will ensure that the mechanisms to accommodate future versions of the MSEC Policy Token are planned for in the basic protocol. Hugh ----- Original Message ----- From: "George Gross" To: "canetti" Cc: "George Gross" ; "Mark Baugher" ; Sent: Thursday, August 14, 2003 5:07 AM Subject: Re: [MSEC] Next gkmarch I-D > Hi Ran, > > On Wed, 13 Aug 2003, canetti wrote: > > > George, > > > > Your proposal to add a (currently unused) field to the policy token > > specifying the RMT protocl in use ofr rekeying sounds like a reasonable > > thing to do. The cost is minimal, and although the chance it will ever be > > used are small, if we do need it and dont have it it will be ugly. > > good, I think this parameter will prove its worth in the long-term... > > given the discussions on the policy token in a parallel thread, I'd like > to hear the GSAKMP folk weigh in on this parameter too... > > > > > But I'm weary of the requirement that future versions must be backwards > > compatible. You sometime want future versions to explicitly NOT be > > backwards compatible, eg when there is a security hole found in the old > > version. In fact, in such a case you;d want to protect against "version > > rollback" attacks. (cf the SSL v2/v3 story). > > Yup, see what you mean...so each GSAKMP (or GDOI) GCKS needs to be able to > refuse a GM request to join for those protocol versions that are on the > "drain bamaged" version list ;o) and in the inverse direction, GM should > be able to decline membership in a group whose GCKS software version is on > that list. > > Would the "drain bamaged version list" make sense to add to the policy > token? I'm leaning towards "yes", as it would allow a GM to offer a > mutually acceptable version in the request to join... > > George > > > > > Ran > > > > > > On Wed, 6 Aug 2003, George Gross wrote: > > > > > Mark, > > > > > > On Wed, 6 Aug 2003, Mark Baugher wrote: > > > > > > > George, > > > > GDOI has a version number in it. So does GSAKMP. > > > > > > Oops, sorry, my e-mail was not precise. What I really should have said was > > > "the semantics for mismatched version numbers between GCKS and group > > > member are currently underspecified...". > > > > > > In GSAKMP, there are Notify payloads for invalid version numbers, but I > > > did not find any text explaining when that would be triggered. I think > > > that this needs to be added, in alignment with the requirement for > > > backward compatibility. > > > > > > In GDOI there is no explicit discussion of version number processing. In > > > fact, RFC3547 does not have the word "error" in it at all. Amazing, an > > > error free protocol ;o) The text in section 3.2.2 seems to hint ISAKMP > > > version error processing is implied? it would be reasonable for GDOI v2 to > > > say more here.... > > > > > > > Perhaps we should > > > > mention this need in gkmarch. > > > > > > Yes, I might go so far as to say that backward compatibility would be > > > important to have specified as a MUST. If we are talking about large-scale > > > multicast, it is likely that a protocol software upgrade transition from > > > v1->v2 will straddle large numbers of endpoints, and could take many > > > weeks/months. > > > > > > In other words, the GCKS is required to accept any group member protocol > > > version less than or equal to the highest version the GCKS supports. > > > > > > George > > > > > > > > > > > Mark > > > > At 07:56 AM 8/6/2003 -0400, George Gross wrote: > > > > >Hi Mark, > > > > > > > > > > > > > > >On Tue, 5 Aug 2003, Mark Baugher wrote: > > > > > > > > > > > hi George, > > > > > > I think the interoperability issue that you mention below could happen > > > > > > on any element of policy. Somehow the policy is determined and if it has > > > > > > advanced or new features than some legacy members don't support, then there > > > > > > will be an interoperability problem. > > > > > > > > > > > > Best regards, Mark > > > > > > > > > >Ok, so would you agree then that a version number should be introduced in > > > > >the group member's registration "request to join" message? > > > > > > > > > >Also, in a related post to this list, I had proposed the protocol feature > > > > >of having a "critical" or mandatory to implement flag in the key > > > > >management protocol's Type/Length/Value encodings. This mechanism > > > > >specifically addresses this backward compatibility interoperability issue. > > > > > > > > > >I would not expect this to be a controversial concept to require in > > > > >GSAKMP or GDOI. It is a basic protocol design feature, examples of which > > > > >can be found in IKE, Diameter, L2TP, etc... BTW in these protocols, it is > > > > >illegal to mark a vendor specific TLV critical. > > > > > > > > > >br, > > > > > George > > > > > > > > > > > At 07:23 PM 8/4/2003 -0400, George Gross wrote: > > > > > > >Hi Mark, > > > > > > > > > > > > > >On Thu, 31 Jul 2003, Mark Baugher wrote: > > > > > > > > > > > > > > > George, > > > > > > > > > > > > > > > > At 11:58 AM 7/31/2003 -0400, George Gross wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >I largely concur with Mark's outline, in that having the GKM-arch > > > > > specify > > > > > > > > >the base error recovery is a minimum starting point. However, I > > > > > would also > > > > > > > > >require that the group policy token have the hooks (i.e. reserved > > > > > TLV) for > > > > > > > > >describing the group's mandatory RMT protocol and its operating > > > > > > > > >parameters. This finesses the "there are many deployment scenarios..." > > > > > > > > >issues by specifying the extensibility that must be built into the GKM > > > > > > > > >protocol and its policy token. > > > > > > > > > > > > > > > > > >To get this capability, at first sight it seems we need: an RMT > > > > > protocol > > > > > > > > >identifier space as an IANA consideration for the GKM-arch or else the > > > > > > > > >group policy token spec. thoughts? > > > > > > > > > > > > > > > > I would not put an identifier into a group key management protocol > > > > > for an > > > > > > > > RMT protocol when there are no standard RMT protocols. If reliable > > > > > > > > multicast were more important to group key management then I > > > > > perceive it to > > > > > > > > be, we could add numbers for Experimental RFCs (IKE did that for > > > > > > > > SPKI). But I don't think we lose anything with the status quo, > > > > > which is to > > > > > > > > use a sequence number and periodic retransmission of the re-key > > > > > message. > > > > > > > > > > > > > > > > Mark > > > > > > > > > > > > > >Hmmmm, I think we do lose/miss something. Suppose that in the future, a > > > > > > >RMT protocol is standardized, and that the MSEC policy token v2 was > > > > > > >"extended" to include the formerly unspecified but now standard RMT > > > > > > >identifier. The endpoints that are running MSEC v1 will be unable to > > > > > > >reliably participate in the group, as they get dropped after the first > > > > > > >lost rekey packet. There will not be retransmission of the rekey message > > > > > > >because the GCKS expects the v1 endpoints to handle the RMT. Detecting the > > > > > > >next rekey message's sequence number mismatch could be an unacceptably > > > > > > >long wait... > > > > > > > > > > > > > >At the very least, this case raises a requirement in the registration > > > > > > >protocol to have the v1 endpoint tell the GCKS its version number and/or > > > > > > >supported RMT set. That way, the GCKS can straddle the v1 and v2 group > > > > > > >subsets with their respective RMT rekey policies. RMT aside, I would think > > > > > > >we need this capability to allow v1 endpoints to participate with v1 rekey > > > > > > >protocols in parallel to v2 endpoints using a "new" rekey protocol. > > > > > > > > > > > > > >AFAIK, neither GDOI nor the GSAKMP registration protocol handle this case. > > > > > > > > > > > > > >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 Fri Aug 15 03:35:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20574 for ; Fri, 15 Aug 2003 03:35:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A417753651; Fri, 15 Aug 2003 03:34:39 -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 04B7F53741 for ; Fri, 15 Aug 2003 03:32:20 -0400 (EDT) Received: (qmail 39460 invoked by uid 3269); 15 Aug 2003 07:32:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39457 invoked from network); 15 Aug 2003 07:32:20 -0000 Received: from albatross-ext.wise.edt.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 15 Aug 2003 07:32:20 -0000 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7F7WJ7W008290; Fri, 15 Aug 2003 09:32:19 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 15 Aug 2003 09:32:30 +0200 Message-ID: <1F55F6582266314A85A55F6241509B6707EF4D8C@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (KI/EAB)" To: "'Euchner Martin'" Cc: 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: Responder-initiated TGK re-keying/CSB updating allowed in MIK EY? 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, 15 Aug 2003 09:30:34 +0200 Hi Martin, sorry for the late reply. > > Dear experts, > > MIKEY-07 describes means how the initiator can update the CSB > or re-key the TGK (see section 4.5). > > Questions are: What about responder-initiated key update etc > where the responder requests key update actions from the > initiator? Is this possible using MIKEY? You mean a message that can be sent from any member to the initiator (or group controller) that requests the group key to be changed? No, that is not possible to do in MIKEY. > Is that something that can be done with some non-MIKEY > (request) message from the responder to the initiator? I > believe yes, but 1) it's non-standard and 2) yields a 2- or > 3-way handshake. > > Is some role change during an active CSB allowed where the > responder takes over the initiator role for the purpose of > key updating? Would that really work? The exchange mechanisms would work even if the roles changes. However, to allow for role change we are then coming into the area of authorization, i.e. who is allowed to add/change/remove new members and information. We didn't define any special authorization token to allow for delegation of authorization (the policy token work that are discussed on the list, will be one way to achieve this). Though, I would imaging that for a peer-to-peer case (as the DH-HMAC), you might not need an explicit authorization token to allow for this role change (but rely on the initial authorization). BR, Fredrik > My understanding is, that the initiator or responder roles > are static throughout the lifetime of the protocol > instantiation. The definition in 1.3 is not entirely precise > about that, but I infer this more from statements like > "...This is done by executing the transport/exchange phase > once again to obtain a new TGK (....". > > > With kind regards > > Martin Euchner. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 15 12:53:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03398 for ; Fri, 15 Aug 2003 12:53:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 45852535F4; Fri, 15 Aug 2003 12:52: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 F245D53561 for ; Fri, 15 Aug 2003 12:51:04 -0400 (EDT) Received: (qmail 19462 invoked by uid 3269); 15 Aug 2003 16:51:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19459 invoked from network); 15 Aug 2003 16:51:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 15 Aug 2003 16:51:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03220; Fri, 15 Aug 2003 12:50:59 -0400 (EDT) Message-Id: <200308151650.MAA03220@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-arch-03.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: Fri, 15 Aug 2003 12:50:59 -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 : The Multicast Security Architecture Author(s) : T. Hardjono, B. Weis Filename : draft-ietf-msec-arch-03.txt Pages : 23 Date : 2003-8-15 This document provides an overview and rationale of the multicast security architecture used for large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-03.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-arch-03.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-arch-03.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-8-15124020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124020.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 15 13:22:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05763 for ; Fri, 15 Aug 2003 13:22:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C719B536BF; Fri, 15 Aug 2003 13:21: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 75C0C536BF for ; Fri, 15 Aug 2003 13:17:19 -0400 (EDT) Received: (qmail 24183 invoked by uid 3269); 15 Aug 2003 17:17:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24180 invoked from network); 15 Aug 2003 17:17:19 -0000 Received: from mx03.forces.gc.ca (131.137.245.203) by klesh.pair.com with SMTP; 15 Aug 2003 17:17:19 -0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 4891220660B for ; Fri, 15 Aug 2003 13:15:45 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19nhoP-0001o0-Ae for ietf-announce-list@asgard.ietf.org; Fri, 15 Aug 2003 12:52:25 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19nhn7-0001kZ-4X for all-ietf@asgard.ietf.org; Fri, 15 Aug 2003 12:51:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03220; Fri, 15 Aug 2003 12:50:59 -0400 (EDT) Message-Id: <200308151650.MAA03220@ietf.org> To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+113669_78187125826255_6699936357" Subject: [MSEC] I-D ACTION:draft-ietf-msec-arch-03.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 15 Aug 2003 12:50:59 -0400 --MIMEStream=_0+113669_78187125826255_6699936357 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 : The Multicast Security Architecture Author(s) : T. Hardjono, B. Weis Filename : draft-ietf-msec-arch-03.txt Pages : 23 Date : 2003-8-15 This document provides an overview and rationale of the multicast security architecture used for large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-03.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-arch-03.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-arch-03.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. --MIMEStream=_0+113669_78187125826255_6699936357 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+111243_8559261779227_86186858471" --MIMEStream=_1+111243_8559261779227_86186858471 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-15124020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-arch-03.txt --MIMEStream=_1+111243_8559261779227_86186858471 Content-Type: Message/External-body; name="draft-ietf-msec-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124020.I-D@ietf.org> --MIMEStream=_1+111243_8559261779227_86186858471-- --MIMEStream=_0+113669_78187125826255_6699936357-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 18 09:54:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18997 for ; Mon, 18 Aug 2003 09:54:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7114053680; Mon, 18 Aug 2003 09:54: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 8A09F536A3 for ; Mon, 18 Aug 2003 09:52:54 -0400 (EDT) Received: (qmail 3600 invoked by uid 3269); 18 Aug 2003 13:52:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3596 invoked from network); 18 Aug 2003 13:52:54 -0000 Received: from goliath.siemens.de (192.35.17.28) by klesh.pair.com with SMTP; 18 Aug 2003 13:52:54 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h7IDqqM03508; Mon, 18 Aug 2003 15:52:52 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h7IDqpO18441; Mon, 18 Aug 2003 15:52:52 +0200 (MEST) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA01613; Mon, 18 Aug 2003 15:52:51 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Mon, 18 Aug 2003 15:52:10 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7023B8442@mchh2a8e.mchh.siemens.de> From: Euchner Martin To: "'Fredrik Lindholm (KI/EAB)'" , Euchner Martin Cc: msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: Responder-initiated TGK re-keying/CSB updating allowed in MIK EY? 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, 18 Aug 2003 15:52:01 +0200 Fredrik, Thanks for your reply. Please find my comments embedded below. > Questions are: What about responder-initiated key update etc > where the responder requests key update actions from the > initiator? Is this possible using MIKEY? You mean a message that can be sent from any member to the initiator (or group controller) that requests the group key to be changed? No, that is not possible to do in MIKEY. MEU:> ok, that is also my understanding. > Is some role change during an active CSB allowed where the > responder takes over the initiator role for the purpose of > key updating? Would that really work? The exchange mechanisms would work even if the roles changes. However, to allow for role change we are then coming into the area of authorization, i.e. who is allowed to add/change/remove new members and information. We didn't define any special authorization token to allow for delegation of authorization (the policy token work that are discussed on the list, will be one way to achieve this). Though, I would imaging that for a peer-to-peer case (as the DH-HMAC), you might not need an explicit authorization token to allow for this role change (but rely on the initial authorization). MEU:> I'm not talking about invoking group membership changes by some non-initiator member. This is clearly a separate problem that deserves or course some authorization means. My question is simply: Can the responder request a new (group) key from the initiator? For example, the responder could be aware that the current group key on his/her own machine has expired/has been compromized or that the key will soon to expire etc, while the initiator considers the TGK secure for much longer time. Could the responder communicate this matter (using MIKEY) to the initiator, and trigger the initiator to distribute a new TGK? This should be something that does not require any deeper authorization, does it? Cheers Martin _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 18 10:01:01 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19146 for ; Mon, 18 Aug 2003 10:01:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 782615364A; Mon, 18 Aug 2003 10:00: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 B53DC5353A for ; Mon, 18 Aug 2003 09:59:21 -0400 (EDT) Received: (qmail 5169 invoked by uid 3269); 18 Aug 2003 13:59:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5166 invoked from network); 18 Aug 2003 13:59:21 -0000 Received: from penguin-ext.wise.edt.ericsson.se (193.180.251.47) by klesh.pair.com with SMTP; 18 Aug 2003 13:59:21 -0000 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7IDxJgM013675; Mon, 18 Aug 2003 15:59:19 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 18 Aug 2003 15:59:43 +0200 Message-ID: <1F55F6582266314A85A55F6241509B6707EF4D98@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (KI/EAB)" To: "'Euchner Martin'" Cc: 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: Responder-initiated TGK re-keying/CSB updating allowed in MIK EY? 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, 18 Aug 2003 15:57:32 +0200 > Fredrik, > > Thanks for your reply. Please find my comments embedded below. > > > > Questions are: What about responder-initiated key update etc > > where the responder requests key update actions from the > > initiator? Is this possible using MIKEY? > > You mean a message that can be sent from any member to the > initiator (or group controller) that requests the group key > to be changed? No, that is not possible to do in MIKEY. > > MEU:> ok, that is also my understanding. > > > Is some role change during an active CSB allowed where the > > responder takes over the initiator role for the purpose of > > key updating? Would that really work? > > The exchange mechanisms would work even if the roles changes. > However, to allow for role change we are then coming into the > area of authorization, i.e. who is allowed to add/change/remove > new members and information. We didn't define any special > authorization token to allow for delegation of authorization > (the policy token work that are discussed on the list, will > be one way to achieve this). Though, I would imaging that for > a peer-to-peer case (as the DH-HMAC), you might not need an > explicit authorization token to allow for this role change > (but rely on the initial authorization). > > MEU:> I'm not talking about invoking group membership changes > by some non-initiator member. This is clearly a separate > problem that deserves or course some authorization means. > > My question is simply: Can the responder request a new > (group) key from the initiator? For example, the responder > could be aware that the current group key on his/her own > machine has expired/has been compromized or that the key will > soon to expire etc, while the initiator considers the TGK > secure for much longer time. Could the responder communicate > this matter (using MIKEY) to the initiator, and trigger the > initiator to distribute a new TGK? No. Cheers, Fredrik > > > This should be something that does not require any deeper > authorization, does it? > > > Cheers > > Martin > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 18 10:26:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20755 for ; Mon, 18 Aug 2003 10:26:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F0AC0536A7; Mon, 18 Aug 2003 10:26: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 04956535B3 for ; Mon, 18 Aug 2003 10:24:32 -0400 (EDT) Received: (qmail 9572 invoked by uid 3269); 18 Aug 2003 14:24:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9568 invoked from network); 18 Aug 2003 14:24:31 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 18 Aug 2003 14:24:31 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h7IEOKK00720; Mon, 18 Aug 2003 16:24:20 +0200 (MEST) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h7IEOJO18702; Mon, 18 Aug 2003 16:24:20 +0200 (MEST) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id QAA20945; Mon, 18 Aug 2003 16:23:03 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Mon, 18 Aug 2003 16:23:39 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7023B8443@mchh2a8e.mchh.siemens.de> From: Euchner Martin To: "'Thomas Hardjono'" , Lakshminath Dondeti , canetti , Euchner Martin Cc: msec@securemulticast.org Subject: RE: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" 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, 18 Aug 2003 16:23:36 +0200 Thomas, I checked the web page entry wrt. DHHMAC draft. Please update the URL to the document to point to the -03 version. The last column says that "WG Last Call Completed.". This is not quite correct, as far as I understand the current process. I believe that this WG LC is still ongoing and will go on until the end of August 2003. So it would be more accurate to say "currently in WG Last Call". BTW: It appears that the IESG ID tracker tool does not know about the WG LC state. https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=MSEC&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=&search_area_acronym=&search_button=SEARCH (take care of broken URL). I'm a bit confused that some entries in the table reference not just the current version but also older, sometimes even expired versions of an ID. Isn't this a bit too confusing and not quite inline with the practice of referencing IDs? With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Thomas Hardjono [mailto:thardjono@verisign.com] Sent: Thursday, August 14, 2003 7:30 PM To: Lakshminath Dondeti; canetti Cc: msec@securemulticast.org Subject: Re: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd) Following Lakshminath's excellent suggestion, I have modified the page into a table with three columns: (a) The name of the draft (b) Destination track (c) Current Status. Please take a look and verify/correct (ps. bound to be some errors :) http://www.securemulticast.org/msec-drafts.htm thomas ------ At 8/12/2003||02:39 PM, Lakshminath Dondeti wrote: >It would have been more informative if each of the work items had a track >tag (informational/experimental/standards) next to it. Hope you can do >that for the charter page on the IETF site. > >Thanks, >Lakshminath > >canetti wrote: > >>---------- Forwarded message ---------- >>Date: Tue, 12 Aug 2003 09:51:21 -0400 >>From: The IESG >>To: IETF-Announce: ; >>Cc: canetti@watson.ibm.com, thardjono@verisign.com >>Subject: WG Action: RECHARTER: Multicast Security (msec) >> >>The charter of the Multicast Security (msec) working group in the >>Security Area of the IETF has been updated. For additional >>information, please contact the Area Directors or the working >>group Chairs. >> >>Multicast Security (msec) >>------------------------- >>Current Status: Active Working Group >> >>Chairs: >> >>Ran Canetti >>Thomas Hardjono >> >>Security Area Director(s): >> >>Russell Housley >>Steven Bellovin >> >>Mailing Lists: >> >>General Discussion: msec@securemulticast.org >>To Subscribe: msec-request@securemulticast.org >>In Body: subscribe >>Archive: >> >>Description of Working Group: >> >>The purpose of the MSEC WG is to standardize protocols for securing >>group communication over internets, and in particular over the global >>Internet. Initial efforts will focus on scalable solutions for groups >>with a single source and a very large number of recipients. Additional >>emphasis will be put on groups where the data is transmitted via >>IP-layer multicast routing protocols (with or without guaranteed >>reliability). The developed standard will assume that each group has a >>single trusted entity (the Group Controller) that sets the security >>policy and controls the group membership. The standard will strive >>to provide at least the following basic security guarantees: >> >>+ Only legitimate group members will have access to current group >>communication. This includes groups with highly dynamic membership. >> >>+ Legitimate group members will be able to authenticate the source >>and contents of the group communication. This includes cases where >>group members do not trust each other. >> >>An additional goal of the standard will be to protect against >>denial-of-service attacks, whenever possible. >> >>Due to the large number of one-to-many multicast applications and the >>sometimes conflicting requirements these applications exhibit, it is >>believed that a single protocol will be unable to meet the requirements >>of all applications. Therefore, the WG will first specify a general >>Reference Framework that includes a number of functional building >>blocks. Each such building block will be instantiated by one or more >>protocols that will be interchanable. The Reference Framework will not >>only describe one-to-many multicast, but also many-to-many multicast. >> >>In addition, as a secondary goal the MSEC WG will also focus on >>distributed architectures for group key management and group policy >>management, where for scalability purposes multiple trusted entities >>(such as Key Distributors) are deployed in a distributed fashion. For >>this purpose, the Reference Framework will not only describe >>one-to-many multicast, but also many-to-many multicast. >> >>MSEC will generate at least the following documents, which could be >>considered as base documents: >> >>1. An RFC describing the security requirements of multicast security and >>an RFC describing the MSEC Architecture. >> >>2. An RFC describing the Group Key Management Architecture and an RFC >>describing Group Policy Management Architecture in MSEC. >> >>3. Several RFCs describing specifications for protocols that implement >>source authentication, group key management and group policy management. >>As multicast security covers a broad range of issues, and therefore >>touches other Working Groups in the IETF, the MSEC WG will work closely >>with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well >>as other Working Groups which maybe considered a "consumer" of the >>technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may >>have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). >> >>With this in mind, the MSEC WG is open to receiving new work items, >>whenever it is considered appropriate to be homed in the MSEC WG. Such >>drafts will be matured in conjunction with the MSEC base documents. >> >>Goals and Milestones: >> >>DONE Working Group Last Call on GDOI Protocol. >> >>DONE Working Group Last Call on MIKEY Protocol. >> >>Sep 03 WG Last Call on Group Key Management Architecture draft. >> >>Sep 03 WG Last Call on MSEC Architecture draft. >> >>Sep 03 WG Last Call on DHHMAC for MIKEY. >> >>Sep 03 WG Last Call on Data Security Architecture draft >> >>Dec 03 WG Last Call on Security Requirements draft. >> >>Mar 04 WG Last Call on Group Security Policy Architecture draft >> >>Mar 04 WG Last Call on MESP (Multicast ESP) draft. >> >>Mar 04 WG Last call on MESP-TESLA draft. >> >>Mar 04 WG Last Call on GSAKMP-Light protocol. >> >>Jul 04 WG re-charter for other work items (or disband). >> >> >> >> >> >>_______________________________________________ >>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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 18 13:31:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26690 for ; Mon, 18 Aug 2003 13:31:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 51103535C6; Mon, 18 Aug 2003 13:30:57 -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 F261453586 for ; Mon, 18 Aug 2003 13:28:07 -0400 (EDT) Received: (qmail 45127 invoked by uid 3269); 18 Aug 2003 17:28:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45124 invoked from network); 18 Aug 2003 17:28:07 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 18 Aug 2003 17:28:07 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h7IHRrYf009895; Mon, 18 Aug 2003 10:27:54 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 10:27:53 -0700 Message-ID: From: "Hardjono, Thomas" To: "'Euchner Martin'" , "Hardjono, Thomas" , Lakshminath Dondeti , canetti Cc: msec@securemulticast.org Subject: RE: [MSEC] WG Action: RECHARTER: Multicast Security (msec) (fwd) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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, 18 Aug 2003 10:27:51 -0700 Martin, Apologies for the typo. Let me update the page. Let me also see what to do about the ID tracker. cheers, thomas ------ > -----Original Message----- > From: Euchner Martin [mailto:martin.euchner@siemens.com] > Sent: Monday, August 18, 2003 7:24 AM > To: 'Thomas Hardjono'; Lakshminath Dondeti; canetti; Euchner Martin > Cc: msec@securemulticast.org > Subject: RE: [MSEC] WG Action: RECHARTER: Multicast Security > (msec) (fwd) > > > Thomas, > > I checked the web page entry wrt. DHHMAC draft. > > Please update the URL to the document to point to the -03 version. > > The last column says that "WG Last Call Completed.". This is > not quite correct, as far as I understand the current > process. I believe that this WG LC is still ongoing and will > go on until the end of August 2003. > > So it would be more accurate to say "currently in WG Last Call". > > BTW: It appears that the IESG ID tracker tool does not know > about the WG LC state. > > https://datatracker.ietf.org/public/pidtracker.cgi?command=sea > rch_list&search_job_owner=0&search_group_acronym=MSEC&search_s > tatus_id=&search_cur_state=&sub_state_id=6&search_filename=&se > arch_rfcnumber=&search_area_acronym=&search_button=SEARCH > > (take care of broken URL). > > I'm a bit confused that some entries in the table reference > not just the current version but also older, sometimes even > expired versions of an ID. Isn't this a bit too confusing and > not quite inline with the practice of referencing IDs? > > > > With kind regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Rapporteur Q.G/SG16 > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 62366 > | ICN M SR 3 mailto:Martin.Euchner@siemens.com > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > -------------------------------------------------------------- > --------- > > -----Original Message----- > From: Thomas Hardjono [mailto:thardjono@verisign.com] > Sent: Thursday, August 14, 2003 7:30 PM > To: Lakshminath Dondeti; canetti > Cc: msec@securemulticast.org > Subject: Re: [MSEC] WG Action: RECHARTER: Multicast > Security (msec) (fwd) > > > Following Lakshminath's excellent suggestion, I have modified > the page into > a table with three columns: > > (a) The name of the draft > (b) Destination track > (c) Current Status. > > Please take a look and verify/correct (ps. bound to be some > errors :) http://www.securemulticast.org/msec-drafts.htm > > thomas > ------ > > > > > At 8/12/2003||02:39 PM, Lakshminath Dondeti wrote: > >It would have been more informative if each of the work items had a > >track > >tag (informational/experimental/standards) next to it. Hope > you can do > >that for the charter page on the IETF site. > > > >Thanks, > >Lakshminath > > > >canetti wrote: > > > >>---------- Forwarded message ---------- > >>Date: Tue, 12 Aug 2003 09:51:21 -0400 > >>From: The IESG > >>To: IETF-Announce: ; > >>Cc: canetti@watson.ibm.com, thardjono@verisign.com > >>Subject: WG Action: RECHARTER: Multicast Security (msec) > >> > >>The charter of the Multicast Security (msec) working group in the > >>Security Area of the IETF has been updated. For additional > >>information, please contact the Area Directors or the working group > >>Chairs. > >> > >>Multicast Security (msec) > >>------------------------- > >>Current Status: Active Working Group > >> > >>Chairs: > >> > >>Ran Canetti > >>Thomas Hardjono > >> > >>Security Area Director(s): > >> > >>Russell Housley > >>Steven Bellovin > >> > >>Mailing Lists: > >> > >>General Discussion: msec@securemulticast.org > >>To Subscribe: msec-request@securemulticast.org > >>In Body: subscribe > >>Archive: > >> > >>Description of Working Group: > >> > >>The purpose of the MSEC WG is to standardize protocols for securing > >>group communication over internets, and in particular over > the global > >>Internet. Initial efforts will focus on scalable solutions > for groups > >>with a single source and a very large number of recipients. > Additional > >>emphasis will be put on groups where the data is transmitted via > >>IP-layer multicast routing protocols (with or without guaranteed > >>reliability). The developed standard will assume that each > group has a > >>single trusted entity (the Group Controller) that sets the security > >>policy and controls the group membership. The standard will > strive to > >>provide at least the following basic security guarantees: > >> > >>+ Only legitimate group members will have access to current group > >>communication. This includes groups with highly dynamic membership. > >> > >>+ Legitimate group members will be able to authenticate the source > >>and contents of the group communication. This includes cases where > >>group members do not trust each other. > >> > >>An additional goal of the standard will be to protect against > >>denial-of-service attacks, whenever possible. > >> > >>Due to the large number of one-to-many multicast > applications and the > >>sometimes conflicting requirements these applications > exhibit, it is > >>believed that a single protocol will be unable to meet the > >>requirements of all applications. Therefore, the WG will > first specify > >>a general Reference Framework that includes a number of functional > >>building blocks. Each such building block will be > instantiated by one > >>or more protocols that will be interchanable. The Reference > Framework > >>will not only describe one-to-many multicast, but also many-to-many > >>multicast. > >> > >>In addition, as a secondary goal the MSEC WG will also focus on > >>distributed architectures for group key management and group policy > >>management, where for scalability purposes multiple trusted > entities > >>(such as Key Distributors) are deployed in a distributed > fashion. For > >>this purpose, the Reference Framework will not only describe > >>one-to-many multicast, but also many-to-many multicast. > >> > >>MSEC will generate at least the following documents, which could be > >>considered as base documents: > >> > >>1. An RFC describing the security requirements of multicast > security > >>and an RFC describing the MSEC Architecture. > >> > >>2. An RFC describing the Group Key Management Architecture > and an RFC > >>describing Group Policy Management Architecture in MSEC. > >> > >>3. Several RFCs describing specifications for protocols > that implement > >>source authentication, group key management and group policy > >>management. As multicast security covers a broad range of > issues, and > >>therefore touches other Working Groups in the IETF, the > MSEC WG will > >>work closely with othersecurity-related Working Groups (e.g. IPsec, > >>IPSP), as well as other Working Groups which maybe considered a > >>"consumer" of the technologies produced in the MSEC WG (e.g. AVT, > >>MMUSIC) or which may have a multicast focus (e.g. PIM, RMT, IDRM, > >>MAGMA). > >> > >>With this in mind, the MSEC WG is open to receiving new work items, > >>whenever it is considered appropriate to be homed in the > MSEC WG. Such > >>drafts will be matured in conjunction with the MSEC base documents. > >> > >>Goals and Milestones: > >> > >>DONE Working Group Last Call on GDOI Protocol. > >> > >>DONE Working Group Last Call on MIKEY Protocol. > >> > >>Sep 03 WG Last Call on Group Key Management Architecture draft. > >> > >>Sep 03 WG Last Call on MSEC Architecture draft. > >> > >>Sep 03 WG Last Call on DHHMAC for MIKEY. > >> > >>Sep 03 WG Last Call on Data Security Architecture draft > >> > >>Dec 03 WG Last Call on Security Requirements draft. > >> > >>Mar 04 WG Last Call on Group Security Policy Architecture draft > >> > >>Mar 04 WG Last Call on MESP (Multicast ESP) draft. > >> > >>Mar 04 WG Last call on MESP-TESLA draft. > >> > >>Mar 04 WG Last Call on GSAKMP-Light protocol. > >> > >>Jul 04 WG re-charter for other work items (or disband). > >> > >> > >> > >> > >> > >>_______________________________________________ > >>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 > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 18 17:40:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05629 for ; Mon, 18 Aug 2003 17:40:16 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1F7B1536E8; Mon, 18 Aug 2003 17:39:42 -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 21637535C6 for ; Mon, 18 Aug 2003 17:25:45 -0400 (EDT) Received: (qmail 84976 invoked by uid 3269); 18 Aug 2003 21:25:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84973 invoked from network); 18 Aug 2003 21:25:45 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 18 Aug 2003 21:25:45 -0000 Received: from cisco.com ([128.107.177.101]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7ILPg7F026114; Mon, 18 Aug 2003 14:25:42 -0700 (PDT) Message-ID: <3F414455.C89305BB@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: canetti , msec@securemulticast.org Subject: Re: [MSEC] Simple(r) resynch methods and the policy token References: <3F3BAD1C.2090609@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: Mon, 18 Aug 2003 14:25:41 -0700 Content-Transfer-Encoding: 7bit Dear GKMARCH authors, Option 1 results in too many required mechanisms, if the word "mandated" is kept. Not all mechanisms are feasible in all applications, either. Option 1 is fine, if the word "suggested" is used. Note that this becomes a "SHOULD" condition. The group controller gets to choose which methods he is capable and willing to provide. But now in order for the group member to be able to choose which method ot can use, the group controller has to describe which methods it supports in the policy it gives the group members. But then, Option 2 becomes complementary to Option 1. Option 2 is a natural way of providing that policy, in the case where a policy token is used in the protocol. If there is no policy token (e.g., GDOI), then the policy would need to be provided using a different mechanism. (e.g., GDOI could specify a new KEK Attribute sent in the SA_KEK payload). Thanks, Brian Lakshminath Dondeti wrote: > > One small change in the wording: s/mandated/suggested/ > > regards, > Lakshminath > > canetti wrote: > > >Folks, > > > > > >Currently the GKMARCH draft says that if a group member becomes > >out-of-synch with the group key then it should re-register with the GCKS. > >However, in many cases there are other, simpler methods for re-synching > >with the group: > > > >- The member can open a simple, unprotected connection (say, TCP) > >with the GCKS and obtain the current (or several recent) rekey messages. > >Note that there is no need in authentication or encryption here, since the > >rekey message is already signed and is anyway multicased in the clear. > >[Remark: One may think that this opens the GCKS to DoS attacks by many > >bogus such requests. But this doesnt seem to worsen the situation: in > >fact, bombarding the GCKS with bogus resynch requests would be much more > >problematic...] > > > >- The GCKS can post the rekey messages on some public site (say, web site) > >and the out-of-synch memeber can obtain the rekey messages from that > >site. > > > >We'd like to include these re-synching methods in the upcoming version of > >GKMARCH. We see two ways to go about this. Our question to the list is > >which one seems preferable: > > > >Option 1: It is mandated that the GCKS Always provides all three > >ways of resynching (ie, re-registration, simple TCP, and public > >posting). This way, it is up to the member to choose how to resynch > >and we do not need any additional fleilds in the policy token. > > > >Option 2: Add a field in the policy token specifying which method(s) > >should be used for re-synching. > > > > > >What do people say? > > > > > >Mark, Ran, Lakshminath, Frederik > > > > > >_______________________________________________ > >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 -- 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 Mon Aug 18 18:58:29 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08529 for ; Mon, 18 Aug 2003 18:58:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 21FED536FD; Mon, 18 Aug 2003 18: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 8E0ED53709 for ; Mon, 18 Aug 2003 18:56:06 -0400 (EDT) Received: (qmail 96230 invoked by uid 3269); 18 Aug 2003 22:56:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96225 invoked from network); 18 Aug 2003 22:56:06 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 18 Aug 2003 22:56:06 -0000 Received: (qmail 86891 invoked from network); 18 Aug 2003 22:55:57 -0000 Received: from unknown (HELO nsx.garage) (gmgross@64.21.175.76) by smtp-auth.nac.net with SMTP; 18 Aug 2003 22:55:57 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7IKoqB02954; Mon, 18 Aug 2003 16:50:52 -0400 From: George Gross To: Brian Weis Cc: Lakshminath Dondeti , canetti , Subject: Re: [MSEC] Simple(r) resynch methods and the policy token In-Reply-To: <3F414455.C89305BB@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: Mon, 18 Aug 2003 16:50:52 -0400 (EDT) Hi Brian, things are not as simple as one would hope here...inline below... On Mon, 18 Aug 2003, Brian Weis wrote: > Dear GKMARCH authors, > > Option 1 results in too many required mechanisms, if the word "mandated" > is kept. Not all mechanisms are feasible in all applications, either. > > Option 1 is fine, if the word "suggested" is used. Note that this > becomes a "SHOULD" condition. The group controller gets to choose which > methods he is capable and willing to provide. But now in order for the > group member to be able to choose which method ot can use, the group > controller has to describe which methods it supports in the policy it > gives the group members. The catch is that unless one re-sync mechanism is a MUST implement for all endpoints, then GCKS and GM from different vendors will not inter-operate. The alternative is that a GM endpoint must implement _all_ of the potential re-sync mechanisms because it will never know what type of GCKS it will talk to next. After all, if the GM attempts to join group A having vendor X GCKS that only offers resync method 1, and then at a later time that same GM endpoint wanted to join group B having vendor Y GCKS that only supported resync method 2... So the revised wording is: "re-sync method Foo is the MUST implement method, and re-sync methods Bar and Zoo SHOULD be implemented." I leave to the group's consensus whether the re-sync method is negotiable at group join time. > > But then, Option 2 becomes complementary to Option 1. Option 2 is a > natural way of providing that policy, in the case where a policy token > is used in the protocol. I agree with this, but would take it one step further... > > If there is no policy token (e.g., GDOI), then the policy would need to > be provided using a different mechanism. (e.g., GDOI could specify a new > KEK Attribute sent in the SA_KEK payload). Brian, I like to suggest the possibility that GDOI-v2 (where this new re-sync mechanism information would be specified) could introduce a generic group policy payload rather than trying to exhaustively anticipate and specify every possible policy attribute. The GDOI group policy payload would encapsulate an extensible policy token syntax, as a syntaxically well formed list of TLV (a.k.a. AVP in other protocols). The set of TLV that are MUST supported in a particular context would a profile on the universe of all TLV, and spec'd in standards track RFC. From what I have seen from discussion on this list, there is alot of diversity in the application domains where GKM protocols are applied and the policies they need to encode. That said, I do see enough commonality across those application domains that we could standardize a core set of policy token TLV across the three protocols: GSAKMP, GDOI, and MIKE. Beyond the core set, one would define the protocol specific TLV. This approach resembles the Diameter AAA protocol, wherein a base protocol is common to all application specific extensions to that base. thoughts? br, George > > Thanks, > Brian > > Lakshminath Dondeti wrote: > > > > One small change in the wording: s/mandated/suggested/ > > > > regards, > > Lakshminath > > > > canetti wrote: > > > > >Folks, > > > > > > > > >Currently the GKMARCH draft says that if a group member becomes > > >out-of-synch with the group key then it should re-register with the GCKS. > > >However, in many cases there are other, simpler methods for re-synching > > >with the group: > > > > > >- The member can open a simple, unprotected connection (say, TCP) > > >with the GCKS and obtain the current (or several recent) rekey messages. > > >Note that there is no need in authentication or encryption here, since the > > >rekey message is already signed and is anyway multicased in the clear. > > >[Remark: One may think that this opens the GCKS to DoS attacks by many > > >bogus such requests. But this doesnt seem to worsen the situation: in > > >fact, bombarding the GCKS with bogus resynch requests would be much more > > >problematic...] > > > > > >- The GCKS can post the rekey messages on some public site (say, web site) > > >and the out-of-synch memeber can obtain the rekey messages from that > > >site. > > > > > >We'd like to include these re-synching methods in the upcoming version of > > >GKMARCH. We see two ways to go about this. Our question to the list is > > >which one seems preferable: > > > > > >Option 1: It is mandated that the GCKS Always provides all three > > >ways of resynching (ie, re-registration, simple TCP, and public > > >posting). This way, it is up to the member to choose how to resynch > > >and we do not need any additional fleilds in the policy token. > > > > > >Option 2: Add a field in the policy token specifying which method(s) > > >should be used for re-synching. > > > > > > > > >What do people say? > > > > > > > > >Mark, Ran, Lakshminath, Frederik > > > > > > > > >_______________________________________________ > > >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 Mon Aug 18 23:46:29 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13710 for ; Mon, 18 Aug 2003 23:46:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BEE285367E; Mon, 18 Aug 2003 23:46: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 16B24535EF for ; Mon, 18 Aug 2003 23:45:16 -0400 (EDT) Received: (qmail 43369 invoked by uid 3269); 19 Aug 2003 03:45:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43366 invoked from network); 19 Aug 2003 03:45:16 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 19 Aug 2003 03:45:16 -0000 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2003 20:45:15 -0700 Received: from cscoamera13263.cisco.com (rtp-vpn2-492.cisco.com [10.82.241.236]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7J3jBYZ005913; Mon, 18 Aug 2003 23:45:12 -0400 (EDT) Message-Id: <5.1.1.5.2.20030818202553.05a62d10@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Brian Weis , canetti From: Mark Baugher Subject: Re: [MSEC] Simple(r) resynch methods and the policy token Cc: Lakshminath Dondeti , msec@securemulticast.org In-Reply-To: <3F414455.C89305BB@cisco.com> References: <3F3BAD1C.2090609@americasm06.nt.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: Mon, 18 Aug 2003 20:45:09 -0700 hi Brian, Ran I don't think options 1 or 2 are necessarily meaningful for msec key management protocols. If the resync method is registration, then that is certainly handled in the protocols; nothing more needs to be said about it. If the method uses tcp or some other reliable connection protocol, then that is outside the scope of msec key management protocols. If it relies on the caching of re-key messages, then that is also outside the scope of key management protocols since the messages are intended to be sent over a network that is under the control of an attacker; the protection should be sufficient so that messages can be cached and distributed using other, even insecure, protocols. The latter two cases are pretty much the same though a GCKS might not allow unauthenticated connections as a matter of policy. As I see it, we're discussing GCKS policy and that does not need to be a key management protocol issue. It's an msec policy token thing. If the key management protocol incorporates the policy token, then it's of course managed by the key management protocol. But the msec group key management architecture does not require that the policy token be integrated into key management. It could use, say, internet session description protocol (SDP) or other means to securely communicate the group policy. I agree with Brian that we don't want to mandate that a GCKS support all three ways of re-synchronizing the rekey. I think the issue is what elements of the policy token must be supported versus may or should be supported. This is something to be considered in the policy token work. Mark At 02:25 PM 8/18/2003 -0700, Brian Weis wrote: >Dear GKMARCH authors, > >Option 1 results in too many required mechanisms, if the word "mandated" >is kept. Not all mechanisms are feasible in all applications, either. > >Option 1 is fine, if the word "suggested" is used. Note that this >becomes a "SHOULD" condition. The group controller gets to choose which >methods he is capable and willing to provide. But now in order for the >group member to be able to choose which method ot can use, the group >controller has to describe which methods it supports in the policy it >gives the group members. > >But then, Option 2 becomes complementary to Option 1. Option 2 is a >natural way of providing that policy, in the case where a policy token >is used in the protocol. > >If there is no policy token (e.g., GDOI), then the policy would need to >be provided using a different mechanism. (e.g., GDOI could specify a new >KEK Attribute sent in the SA_KEK payload). > >Thanks, >Brian > >Lakshminath Dondeti wrote: > > > > One small change in the wording: s/mandated/suggested/ > > > > regards, > > Lakshminath > > > > canetti wrote: > > > > >Folks, > > > > > > > > >Currently the GKMARCH draft says that if a group member becomes > > >out-of-synch with the group key then it should re-register with the GCKS. > > >However, in many cases there are other, simpler methods for re-synching > > >with the group: > > > > > >- The member can open a simple, unprotected connection (say, TCP) > > >with the GCKS and obtain the current (or several recent) rekey messages. > > >Note that there is no need in authentication or encryption here, since the > > >rekey message is already signed and is anyway multicased in the clear. > > >[Remark: One may think that this opens the GCKS to DoS attacks by many > > >bogus such requests. But this doesnt seem to worsen the situation: in > > >fact, bombarding the GCKS with bogus resynch requests would be much more > > >problematic...] > > > > > >- The GCKS can post the rekey messages on some public site (say, web site) > > >and the out-of-synch memeber can obtain the rekey messages from that > > >site. > > > > > >We'd like to include these re-synching methods in the upcoming version of > > >GKMARCH. We see two ways to go about this. Our question to the list is > > >which one seems preferable: > > > > > >Option 1: It is mandated that the GCKS Always provides all three > > >ways of resynching (ie, re-registration, simple TCP, and public > > >posting). This way, it is up to the member to choose how to resynch > > >and we do not need any additional fleilds in the policy token. > > > > > >Option 2: Add a field in the policy token specifying which method(s) > > >should be used for re-synching. > > > > > > > > >What do people say? > > > > > > > > >Mark, Ran, Lakshminath, Frederik > > > > > > > > >_______________________________________________ > > >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 > >-- >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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 19 10:08:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11958 for ; Tue, 19 Aug 2003 10:08:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B7F5853605; Tue, 19 Aug 2003 10:08:24 -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 EC4DC53536 for ; Tue, 19 Aug 2003 10:07:59 -0400 (EDT) Received: (qmail 72632 invoked by uid 3269); 19 Aug 2003 14:08:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72629 invoked from network); 19 Aug 2003 14:07:59 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 19 Aug 2003 14:07:59 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11792; Tue, 19 Aug 2003 10:07:55 -0400 (EDT) Message-Id: <200308191407.KAA11792@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-gspt-02.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, 19 Aug 2003 10:07:54 -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 : The MSEC Group Security Policy Token Author(s) : T. Hardjono et al. Filename : draft-ietf-msec-gspt-02.txt Pages : 26 Date : 2003-8-19 This document provides a definition for Group Security Policy, describes the set of elements that make-up an instance of group policy for a given group, and provides an explanation of the intended functions of each element of a group security policy as expressed in the form of the Policy Token or Policy Certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gspt-02.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-gspt-02.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-gspt-02.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-8-19101454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gspt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gspt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101454.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 Aug 19 10:34:54 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14939 for ; Tue, 19 Aug 2003 10:34:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 207A15376E; Tue, 19 Aug 2003 10:34:12 -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 4470E53751 for ; Tue, 19 Aug 2003 10:32:22 -0400 (EDT) Received: (qmail 77256 invoked by uid 3269); 19 Aug 2003 14:32:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77250 invoked from network); 19 Aug 2003 14:32:22 -0000 Received: from mx03.forces.gc.ca (131.137.245.203) by klesh.pair.com with SMTP; 19 Aug 2003 14:32:22 -0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 6988D206607 for ; Tue, 19 Aug 2003 10:30:47 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19p79Z-0008Av-UJ for ietf-announce-list@asgard.ietf.org; Tue, 19 Aug 2003 10:08:05 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19p79U-00087a-6c for all-ietf@asgard.ietf.org; Tue, 19 Aug 2003 10:08:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11792; Tue, 19 Aug 2003 10:07:55 -0400 (EDT) Message-Id: <200308191407.KAA11792@ietf.org> To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+148192_3194109518440_42150623625" Subject: [MSEC] I-D ACTION:draft-ietf-msec-gspt-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 19 Aug 2003 10:07:54 -0400 --MIMEStream=_0+148192_3194109518440_42150623625 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 : The MSEC Group Security Policy Token Author(s) : T. Hardjono et al. Filename : draft-ietf-msec-gspt-02.txt Pages : 26 Date : 2003-8-19 This document provides a definition for Group Security Policy, describes the set of elements that make-up an instance of group policy for a given group, and provides an explanation of the intended functions of each element of a group security policy as expressed in the form of the Policy Token or Policy Certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gspt-02.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-gspt-02.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-gspt-02.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. --MIMEStream=_0+148192_3194109518440_42150623625 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+280034_89719168312327_1007557243" --MIMEStream=_1+280034_89719168312327_1007557243 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19101454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gspt-02.txt --MIMEStream=_1+280034_89719168312327_1007557243 Content-Type: Message/External-body; name="draft-ietf-msec-gspt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101454.I-D@ietf.org> --MIMEStream=_1+280034_89719168312327_1007557243-- --MIMEStream=_0+148192_3194109518440_42150623625-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 19 11:23:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17804 for ; Tue, 19 Aug 2003 11:23:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A4F9753772; Tue, 19 Aug 2003 11:22:40 -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 3BD2E53722 for ; Tue, 19 Aug 2003 11:21:48 -0400 (EDT) Received: (qmail 86751 invoked by uid 3269); 19 Aug 2003 15:21:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86748 invoked from network); 19 Aug 2003 15:21:47 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 19 Aug 2003 15:21:47 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7JFL7a00322; Tue, 19 Aug 2003 11:21:08 -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 Q0DA3X83; Tue, 19 Aug 2003 11:21:07 -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 QZX3KQPR; Tue, 19 Aug 2003 11:21:07 -0400 Message-ID: <3F42405F.9010702@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: Brian Weis , canetti , msec@securemulticast.org Subject: Re: [MSEC] Simple(r) resynch methods and the policy token 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, 19 Aug 2003 11:21:03 -0400 Content-Transfer-Encoding: 7bit Brian and George, I was going to reply soon after I saw Brian's message, but could not get to it. The discussion on MUST/SHOULD/MAY is moot w.r.t. the gkmarch I-D as it is informational. That's why I corrected Ran's "mandated" to "suggested." regards, Lakshminath George Gross wrote: >Hi Brian, > > things are not as simple as one would hope here...inline below... > >On Mon, 18 Aug 2003, Brian Weis wrote: > > > >>Dear GKMARCH authors, >> >>Option 1 results in too many required mechanisms, if the word "mandated" >>is kept. Not all mechanisms are feasible in all applications, either. >> >>Option 1 is fine, if the word "suggested" is used. Note that this >>becomes a "SHOULD" condition. The group controller gets to choose which >>methods he is capable and willing to provide. But now in order for the >>group member to be able to choose which method ot can use, the group >>controller has to describe which methods it supports in the policy it >>gives the group members. >> >> > >The catch is that unless one re-sync mechanism is a MUST implement for all >endpoints, then GCKS and GM from different vendors will not inter-operate. >The alternative is that a GM endpoint must implement _all_ of the >potential re-sync mechanisms because it will never know what type of GCKS >it will talk to next. After all, if the GM attempts to join group A having >vendor X GCKS that only offers resync method 1, and then at a later time >that same GM endpoint wanted to join group B having vendor Y GCKS that >only supported resync method 2... > >So the revised wording is: "re-sync method Foo is the MUST implement >method, and re-sync methods Bar and Zoo SHOULD be implemented." > >I leave to the group's consensus whether the re-sync method is negotiable >at group join time. > > > >>But then, Option 2 becomes complementary to Option 1. Option 2 is a >>natural way of providing that policy, in the case where a policy token >>is used in the protocol. >> >> > >I agree with this, but would take it one step further... > > > >>If there is no policy token (e.g., GDOI), then the policy would need to >>be provided using a different mechanism. (e.g., GDOI could specify a new >>KEK Attribute sent in the SA_KEK payload). >> >> > >Brian, I like to suggest the possibility that GDOI-v2 (where this new >re-sync mechanism information would be specified) could introduce a >generic group policy payload rather than trying to exhaustively anticipate >and specify every possible policy attribute. The GDOI group policy payload >would encapsulate an extensible policy token syntax, as a syntaxically >well formed list of TLV (a.k.a. AVP in other protocols). The set of TLV >that are MUST supported in a particular context would a profile on the >universe of all TLV, and spec'd in standards track RFC. > >>From what I have seen from discussion on this list, there is alot of >diversity in the application domains where GKM protocols are applied and >the policies they need to encode. That said, I do see enough commonality >across those application domains that we could standardize a core set of >policy token TLV across the three protocols: GSAKMP, GDOI, and MIKE. >Beyond the core set, one would define the protocol specific TLV. This >approach resembles the Diameter AAA protocol, wherein a base protocol is >common to all application specific extensions to that base. > >thoughts? > >br, > George > > >>Thanks, >>Brian >> >>Lakshminath Dondeti wrote: >> >> >>>One small change in the wording: s/mandated/suggested/ >>> >>>regards, >>>Lakshminath >>> >>>canetti wrote: >>> >>> >>> >>>>Folks, >>>> >>>> >>>>Currently the GKMARCH draft says that if a group member becomes >>>>out-of-synch with the group key then it should re-register with the GCKS. >>>>However, in many cases there are other, simpler methods for re-synching >>>>with the group: >>>> >>>>- The member can open a simple, unprotected connection (say, TCP) >>>>with the GCKS and obtain the current (or several recent) rekey messages. >>>>Note that there is no need in authentication or encryption here, since the >>>>rekey message is already signed and is anyway multicased in the clear. >>>>[Remark: One may think that this opens the GCKS to DoS attacks by many >>>>bogus such requests. But this doesnt seem to worsen the situation: in >>>>fact, bombarding the GCKS with bogus resynch requests would be much more >>>>problematic...] >>>> >>>>- The GCKS can post the rekey messages on some public site (say, web site) >>>>and the out-of-synch memeber can obtain the rekey messages from that >>>>site. >>>> >>>>We'd like to include these re-synching methods in the upcoming version of >>>>GKMARCH. We see two ways to go about this. Our question to the list is >>>>which one seems preferable: >>>> >>>>Option 1: It is mandated that the GCKS Always provides all three >>>>ways of resynching (ie, re-registration, simple TCP, and public >>>>posting). This way, it is up to the member to choose how to resynch >>>>and we do not need any additional fleilds in the policy token. >>>> >>>>Option 2: Add a field in the policy token specifying which method(s) >>>>should be used for re-synching. >>>> >>>> >>>>What do people say? >>>> >>>> >>>>Mark, Ran, Lakshminath, Frederik >>>> >>>> >>>>_______________________________________________ >>>>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 Aug 20 15:10:05 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01163 for ; Wed, 20 Aug 2003 15:10:05 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7538153837; Wed, 20 Aug 2003 15:09:31 -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 C834753780 for ; Wed, 20 Aug 2003 14:25:45 -0400 (EDT) Received: (qmail 90881 invoked by uid 3269); 20 Aug 2003 18:25:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90878 invoked from network); 20 Aug 2003 18:25:45 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 20 Aug 2003 18:25:45 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h7KIO0JD023299 for ; Wed, 20 Aug 2003 13:24:00 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h7KIOu8B028521 for ; Wed, 20 Aug 2003 13:24:57 -0500 Received: from DGKFL721 (dhcp-1.columbia.sparta.com [157.185.80.1]) by columbia.sparta.com (8.9.1a/8.9.1) with SMTP id OAA06449 for ; Wed, 20 Aug 2003 14:25:36 -0400 (EDT) Message-ID: <07a401c36748$74dc3280$0150b99d@DGKFL721> From: "hugh harney" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07A1_01C36726.ED17E450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [MSEC] Generic Policy Token issues 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, 20 Aug 2003 14:25:38 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_07A1_01C36726.ED17E450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, Several side exchanges have gone between George and I concerning the = Generic Policy Token. Mostly, we were trying to understand each others = issues and concerns. As is the nature of these exchanges, some technical suggestions have = been made and we wanted to put these suggestions in front to the MSEC = group for consideration. In a side exchange George Gross suggested the following: "1. We borrow the Diameter protocol base specification's Attribute Value-Pair (AVP) syntax and framework for encoding the policy token. See attached e-mail wrt/ to Diameter status, it is in the RFC editors queue. Diameter offers a comprehensive encoding scheme for all types of data, = and includes mechanisms for digital signature and encryption based on CMS. 2. We do not require implementation of the Diameter base protocol specification, we simply reserve from IANA a set of AVP codes for MSEC usage, the first set of which are allocated for the GSAKMP policy token related AVP. 3. For each parameter in the current GSAKMP policy token, we do a one = for one mapping of the fields into a corresponding "group AVP" as characterized in section 4.4 of the Diameter specification. We define a syntax for the mandatory and optional AVP for each group AVP." My questions to the group and to George are:=20 If we (the Generic Policy Token work) focus on the core aspects of the = policy token for version 1 of the Generic Policy Token, how long would = it take to get this written? This is assuming that the Diameter framework is universally acceptable. = Is this true? Hugh ------=_NextPart_000_07A1_01C36726.ED17E450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
 
Several side exchanges have gone = between George and=20 I concerning the Generic Policy Token. Mostly, we were trying to = understand each=20 others issues and concerns.
 
As is the nature of these exchanges, = some technical=20 suggestions have been made and we wanted to put these suggestions in = front to=20 the MSEC group for consideration.

In a side exchange = George Gross=20 suggested the following:

"1. We borrow the Diameter protocol base = specification's Attribute
Value-Pair (AVP) syntax and framework for = encoding=20 the policy token. See
attached e-mail wrt/ to Diameter status, it is = in the=20 RFC editors queue.
Diameter offers a comprehensive encoding scheme = for all=20 types of data, and
includes mechanisms for digital signature and = encryption=20 based on CMS.

2. We do not require implementation of the Diameter = base=20 protocol
specification, we simply reserve from IANA a set of AVP = codes for=20 MSEC
usage, the first set of which are allocated for the GSAKMP = policy=20 token
related AVP.

3. For each parameter in the current GSAKMP = policy=20 token, we do a one for
one mapping of the fields into a corresponding = "group=20 AVP" as
characterized in section 4.4 of the Diameter specification. = We define=20 a
syntax for the mandatory and optional AVP for each group = AVP."
 
My questions to the group = and to George=20 are:

If we (the Generic Policy Token work) focus on the core aspects = of the=20 policy token for version 1 of the Generic Policy Token, how long would = it take=20 to get this written?

This is assuming that the Diameter framework = is=20 universally acceptable. Is this=20 true?

Hugh

 ------=_NextPart_000_07A1_01C36726.ED17E450-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 20 15:20:36 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02166 for ; Wed, 20 Aug 2003 15:20:35 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1D13B536F1; Wed, 20 Aug 2003 15:20: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 B395753865 for ; Wed, 20 Aug 2003 15:18:13 -0400 (EDT) Received: (qmail 1336 invoked by uid 3269); 20 Aug 2003 19:18:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1333 invoked from network); 20 Aug 2003 19:18:13 -0000 Received: from turkey.mail.pas.earthlink.net (207.217.120.126) by klesh.pair.com with SMTP; 20 Aug 2003 19:18:13 -0000 Received: from user-2inig28.dialup.mindspring.com ([165.121.64.72] helo=stealth) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19pYSz-0000ux-00; Wed, 20 Aug 2003 12:17:58 -0700 Message-ID: <01c001c3674f$c31b9d30$9865fea9@stealth> From: "Andrea Colegrove" To: "hugh harney" , References: <07a401c36748$74dc3280$0150b99d@DGKFL721> Subject: Re: [MSEC] Generic Policy Token issues MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BD_01C3672E.3945FB30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 20 Aug 2003 15:17:52 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_01BD_01C3672E.3945FB30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given that probably most of the working group does not have the = extensive experience in Diameter that George has, it might be of benefit = to both provide members time to review Diameter as well as perhaps for = George to highlight some of the reasons why Diameter is a good starting = point for the msec token. This is probably a case where no immediate = objection does not mean consensus. --- Andrea This is assuming that the Diameter framework is universally = acceptable. Is this true? ------=_NextPart_000_01BD_01C3672E.3945FB30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Given that probably most of the working = group does=20 not have the extensive experience in Diameter that George has, it might = be of=20 benefit to both provide members time to review Diameter as well as = perhaps for=20 George to highlight some of the reasons why Diameter is a good starting = point=20 for the msec token.  This is probably a case where no immediate = objection=20 does not mean consensus.
 
--- Andrea
This is assuming that the Diameter = framework is=20 universally acceptable. Is this=20 true?
------=_NextPart_000_01BD_01C3672E.3945FB30-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 20 15:21:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02269 for ; Wed, 20 Aug 2003 15:21:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 682145385A; Wed, 20 Aug 2003 15:20: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 3DE82536A4 for ; Wed, 20 Aug 2003 15:18:48 -0400 (EDT) Received: (qmail 1426 invoked by uid 3269); 20 Aug 2003 19:18:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1421 invoked from network); 20 Aug 2003 19:18:48 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 20 Aug 2003 19:18:48 -0000 Received: (qmail 71993 invoked from network); 20 Aug 2003 19:18:47 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.186) by smtp-auth.nac.net with SMTP; 20 Aug 2003 19:18:47 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7KHDPt09249; Wed, 20 Aug 2003 13:13:25 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Protocol Action: Diameter Base Protocol to Proposed Standard (fwd) 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, 20 Aug 2003 13:13:25 -0400 (EDT) Hi, In follow up to Hugh's e-mail, here is the IESG announcement of the Diameter protocol spec's transition to Proposed Standard. br, George ---------- Forwarded message ---------- Date: Mon, 27 Jan 2003 20:55:47 -0500 From: The IESG To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , aaa-wg@merit.edu Subject: Protocol Action: Diameter Base Protocol to Proposed Standard The IESG has approved the Internet-Draft 'Diameter Base Protocol' as a Proposed Standard. This document is the product of the Authentication, Authorization and Accounting Working Group. The IESG contact persons are Randy Bush and Bert Wijnen. Technical Summary This document is the base for the proposed new IETF AAA protocol suite. The base protocol is intended to provide an AAA framework for applications such as network access and IP mobility. Diameter is also intended to work in both local AAA and in roaming situations. This draft specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application MUST be supported by all Diameter implementations. Working Group Summary There was no technical dissent to this document in the aaa working group or during IETF last call. Protocol Quality This document was reviewed for the IESG by Randy Bush, and many others. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 20 16:48:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10040 for ; Wed, 20 Aug 2003 16:48:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D69C053844; Wed, 20 Aug 2003 16:48: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 EC34F53819 for ; Wed, 20 Aug 2003 16:46:03 -0400 (EDT) Received: (qmail 18142 invoked by uid 3269); 20 Aug 2003 20:46:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18139 invoked from network); 20 Aug 2003 20:46:04 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 20 Aug 2003 20:46:04 -0000 Received: (qmail 95148 invoked from network); 20 Aug 2003 20:46:02 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.186) by smtp-auth.nac.net with SMTP; 20 Aug 2003 20:46:02 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7KIeeT09569; Wed, 20 Aug 2003 14:40:40 -0400 From: George Gross To: Andrea Colegrove Cc: hugh harney , Subject: Re: [MSEC] Generic Policy Token issues In-Reply-To: <01c001c3674f$c31b9d30$9865fea9@stealth> 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: Wed, 20 Aug 2003 14:40:40 -0400 (EDT) Hi, at the moment, I don't have time for an elaborate reply, so I'll focus on a short version, and elaborate in future e-mails as cycles permit... The essence of why one would to consider the Diameter framework for the policy token is simple: network service operators use Authentication, Authorization, and Accounting (AAA) for their back office operations that assure the bill gets paid for those services that span administrative (and business) domains. In its first application, Diameter is being standardized for roaming network access. Another application is the Mobile IP AAA. Diameter has a rich model for multi-party sessions that include brokers, so it scales well. Now let's look at secure multicast as a billable multi-realm network service. As a representative example, let's suppose that the home administrative domain is an Enterprise that wants to do secure collaborative teleconferencing. The visited administrative domain may be a Streaming Media Service Provider, and an employee of the Enterprise wants to join the teleconference while he/she is traveling and staying at a hotel that offers Internet access with that Service Provider. Diameter as currently formulated could provide the AAA capabilities to do vanilla Internet access, but it does not currently have an extension defined for secure multicast services. In all likelyhood, such a definition is quite away down the road, but the generic policy token is a first step on that road. The Enterprise home admin domain is the secure multicast group owner (i.e. the entity who pays the bill). It stands to reason that the group policy token signed by the owner needs to be placed in a Diameter framework, and conveyed to the GCKS that resides in the visited admin domain. What's more, the policy token contains information that both that GCKS and the group members would need to decrypt and interpret. Diameter has mechanisms to assure confidentiality and integrity on a per AVP basis. The GCKS would be in a position to handle authentication that interacts with the Enterprise's Authentication server, enforce authorization for the service, meter its usage, and generate accounting records. My conviction is that to become commercially widespread, secure multicast must interact with the AAA infrastructure already being used by Service Providers. Encoding the policy token in the Diameter framework is a natural step towards that objective, as policy and AAA are really close cousins of one another. more to come later (putting on flame-proof suit)... br, George On Wed, 20 Aug 2003, Andrea Colegrove wrote: > Given that probably most of the working group does not have the extensive experience in Diameter that George has, it might be of benefit to both provide members time to review Diameter as well as perhaps for George to highlight some of the reasons why Diameter is a good starting point for the msec token. This is probably a case where no immediate objection does not mean consensus. > > --- Andrea > This is assuming that the Diameter framework is universally acceptable. Is this true? > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 21 07:39:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29579 for ; Thu, 21 Aug 2003 07:39:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 26A435379D; Thu, 21 Aug 2003 07:38: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 3A2FE536FE for ; Thu, 21 Aug 2003 07:36:34 -0400 (EDT) Received: (qmail 91265 invoked by uid 3269); 21 Aug 2003 11:36:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91262 invoked from network); 21 Aug 2003 11:36:33 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 21 Aug 2003 11:36:33 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19pnjQ-0005If-00; Thu, 21 Aug 2003 12:35:56 +0100 Message-ID: <3F44AE98.EE458412@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: hugh harney Cc: msec@securemulticast.org Subject: Re: [MSEC] Generic Policy Token issues References: <07a401c36748$74dc3280$0150b99d@DGKFL721> Content-Type: multipart/alternative; boundary="------------547792B2E193C14A1BB7A657" X-Spam-Status: No, hits=-104.1 required=5.5 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_20_30,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM, USER_IN_WHITELIST version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19pnjQ-0005If-00*oOn4oYIiGyo* (SECM, UniS) 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, 21 Aug 2003 12:35:52 +0100 --------------547792B2E193C14A1BB7A657 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I have one comment about Diameter usage for the security policy distribution in relation to GSAKMP protocol: One important property of GSAKMP, that I like, is that it is SELF CONTAINED, and does not depend on any other protocols. So, why we should rely on Diameter within a GSAKMP managed group, this adds more interworking complications. May be, Diameter is useful for interworking between GSAKMP and others such as MIKEY and future versions of GDOI (GDOI with policy). My suggestion is that for the generic Policy Token (PT), there should be an option to carry the PT within the protocol itself in order to reduce the dependency on Diameter, if it is not available. Any comments are welcome. Haitham hugh harney wrote: > All, Several side exchanges have gone between George and I concerning > the Generic Policy Token. Mostly, we were trying to understand each > others issues and concerns. As is the nature of these exchanges, some > technical suggestions have been made and we wanted to put these > suggestions in front to the MSEC group for consideration. > In a side exchange George Gross suggested the following: > > "1. We borrow the Diameter protocol base specification's Attribute > Value-Pair (AVP) syntax and framework for encoding the policy token. > See > attached e-mail wrt/ to Diameter status, it is in the RFC editors > queue. > Diameter offers a comprehensive encoding scheme for all types of data, > and > includes mechanisms for digital signature and encryption based on CMS. > > 2. We do not require implementation of the Diameter base protocol > specification, we simply reserve from IANA a set of AVP codes for MSEC > > usage, the first set of which are allocated for the GSAKMP policy > token > related AVP. > > 3. For each parameter in the current GSAKMP policy token, we do a one > for > one mapping of the fields into a corresponding "group AVP" as > characterized in section 4.4 of the Diameter specification. We define > a > syntax for the mandatory and optional AVP for each group AVP." My > questions to the group and to George are: > If we (the Generic Policy Token work) focus on the core aspects of the > policy token for version 1 of the Generic Policy Token, how long would > it take to get this written? > > This is assuming that the Diameter framework is universally > acceptable. Is this true? > > Hugh > -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ --------------547792B2E193C14A1BB7A657 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

I have one comment about Diameter usage for the security policy distribution in relation to GSAKMP protocol: One important property of GSAKMP, that I like, is
that it is SELF CONTAINED, and does not depend on any other protocols. So, why we should rely on Diameter within a GSAKMP managed group, this
adds more interworking complications.  May be, Diameter is useful for interworking between GSAKMP and others such as MIKEY and future versions of
GDOI (GDOI with policy).

My suggestion is that for the generic Policy Token (PT), there should be an option to carry the PT within the protocol itself in order to reduce the dependency on Diameter, if it is not available.

Any comments are welcome.
Haitham

hugh harney wrote:

All, Several side exchanges have gone between George and I concerning the Generic Policy Token. Mostly, we were trying to understand each others issues and concerns. As is the nature of these exchanges, some technical suggestions have been made and we wanted to put these suggestions in front to the MSEC group for consideration. 
In a side exchange George Gross suggested the following:

"1. We borrow the Diameter protocol base specification's Attribute
Value-Pair (AVP) syntax and framework for encoding the policy token. See
attached e-mail wrt/ to Diameter status, it is in the RFC editors queue.
Diameter offers a comprehensive encoding scheme for all types of data, and
includes mechanisms for digital signature and encryption based on CMS.

2. We do not require implementation of the Diameter base protocol
specification, we simply reserve from IANA a set of AVP codes for MSEC
usage, the first set of which are allocated for the GSAKMP policy token
related AVP.

3. For each parameter in the current GSAKMP policy token, we do a one for
one mapping of the fields into a corresponding "group AVP" as
characterized in section 4.4 of the Diameter specification. We define a
syntax for the mandatory and optional AVP for each group AVP." My questions to the group and to George are: 
If we (the Generic Policy Token work) focus on the core aspects of the policy token for version 1 of the Generic Policy Token, how long would it take to get this written?

This is assuming that the Diameter framework is universally acceptable. Is this true?

Hugh
 

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
  --------------547792B2E193C14A1BB7A657-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 21 15:38:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25552 for ; Thu, 21 Aug 2003 15:38:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 564A553844; Thu, 21 Aug 2003 15:38:22 -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 C86BD53844 for ; Thu, 21 Aug 2003 15:37:28 -0400 (EDT) Received: (qmail 74725 invoked by uid 3269); 21 Aug 2003 19:37:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74722 invoked from network); 21 Aug 2003 19:37:28 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 21 Aug 2003 19:37:28 -0000 Received: (qmail 97757 invoked from network); 21 Aug 2003 19:37:25 -0000 Received: from unknown (HELO nsx.garage) (gmgross@64.21.175.46) by smtp-auth.nac.net with SMTP; 21 Aug 2003 19:37:25 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7LHVrW11274; Thu, 21 Aug 2003 13:31:53 -0400 From: George Gross To: Haitham Cruickshank Cc: hugh harney , Subject: Re: [MSEC] Generic Policy Token issues In-Reply-To: <3F44AE98.EE458412@eim.surrey.ac.uk> 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, 21 Aug 2003 13:31:53 -0400 (EDT) Hi Haitham, On Thu, 21 Aug 2003, Haitham Cruickshank wrote: > Hi All, > > I have one comment about Diameter usage for the security policy > distribution in relation to GSAKMP protocol: One important property of > GSAKMP, that I like, is > that it is SELF CONTAINED, and does not depend on any other protocols. It is still self contained, albeit one does need to be able to parse the Diameter AVP syntax and then understand the semantics for the repertorie of only those AVP defined for a GSAKMP policy token. We would not mandate implementation of a Diameter base protocol and its secure multicast extension, although there may be powerful economic incentives for a network operator to want to do that in a deployment. Also, I anticipate that GSAKMP will have an option for you to define and "roll your own" policy token payload by setting the "policy token ID type" field to a non-standard value (see section 6.3 of msec-gsakmp-sec-03.txt). Of course, that private policy token would not interoperate with anyone other than consenting parties who understand that private token type. > So, why we should rely on Diameter within a GSAKMP managed group, this > adds more interworking complications. May be, Diameter is useful for > interworking between GSAKMP and others such as MIKEY and future versions > of > GDOI (GDOI with policy). Yes, that is a very compelling advantage, that earlier e-mails did not mention or emphasize. It would be a good thing for the group owner to encode and sign one policy token syntax that is endpoint protocol independent. the group owner that signs the token would not have to know which protocols are in use amongst the group members: GSAKMP, GDOI-v2, or MIKE. The latter two would have to rev their design v1->v2 to add the policy token concept. Note that using the AVP encoding scheme, some Diameter AVP could be considered "base" and used across multiple MSEC protocols, whereas other AVP may be protocol-specific. > > My suggestion is that for the generic Policy Token (PT), there should be > an option to carry the PT within the protocol itself in order to reduce > the dependency on Diameter, if it is not available. ummmm... if I understand what you are saying, I think you will get that capability. The Diameter encoded generic policy token would be the contents of the policy token data field within a GSAKMP policy token payload. See section 6.3 in the GSAKMP protocol spec. hth, George > > Any comments are welcome. > Haitham > > hugh harney wrote: > > > All, Several side exchanges have gone between George and I concerning > > the Generic Policy Token. Mostly, we were trying to understand each > > others issues and concerns. As is the nature of these exchanges, some > > technical suggestions have been made and we wanted to put these > > suggestions in front to the MSEC group for consideration. > > In a side exchange George Gross suggested the following: > > > > "1. We borrow the Diameter protocol base specification's Attribute > > Value-Pair (AVP) syntax and framework for encoding the policy token. > > See > > attached e-mail wrt/ to Diameter status, it is in the RFC editors > > queue. > > Diameter offers a comprehensive encoding scheme for all types of data, > > and > > includes mechanisms for digital signature and encryption based on CMS. > > > > 2. We do not require implementation of the Diameter base protocol > > specification, we simply reserve from IANA a set of AVP codes for MSEC > > > > usage, the first set of which are allocated for the GSAKMP policy > > token > > related AVP. > > > > 3. For each parameter in the current GSAKMP policy token, we do a one > > for > > one mapping of the fields into a corresponding "group AVP" as > > characterized in section 4.4 of the Diameter specification. We define > > a > > syntax for the mandatory and optional AVP for each group AVP." My > > questions to the group and to George are: > > If we (the Generic Policy Token work) focus on the core aspects of the > > policy token for version 1 of the Generic Policy Token, how long would > > it take to get this written? > > > > This is assuming that the Diameter framework is universally > > acceptable. Is this true? > > > > Hugh > > > > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow in Communications > Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 25 12:56:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28278 for ; Mon, 25 Aug 2003 12:56:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3C40D537A1; Mon, 25 Aug 2003 12:54:37 -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 050B0536FB for ; Mon, 25 Aug 2003 12:53:09 -0400 (EDT) Received: (qmail 82480 invoked by uid 3269); 25 Aug 2003 16:53:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82477 invoked from network); 25 Aug 2003 16:53:09 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 25 Aug 2003 16:53:09 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h7PGp7JD017912 for ; Mon, 25 Aug 2003 11:51:07 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h7PGrp8B025374 for ; Mon, 25 Aug 2003 11:53:51 -0500 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA28223 for ; Mon, 25 Aug 2003 12:53:06 -0400 (EDT) Message-ID: <3F4A3E2D.6050201@columbia.sparta.com> From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "msec@securemulticast.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MSEC] msec spec language 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, 25 Aug 2003 12:49:49 -0400 Content-Transfer-Encoding: 7bit All, Discussions of the future msec token have been in the forefront of this list recently. Obviously, the content of the token is and will continue to be hotly debated. Another issue that should be carefully considered, though, is the specification language of the token. One of the recent proposals has been for Diameter's AVP framework. Having very little experience (none) with AVP in the past, I spent a little bit of time looking at it the past couple of days. It does provide a structural framework for defining many different types of parameters -- security and others. It does allow for some "grouping" and nesting of attributes. While quite suitable for many types of policy, I am sure, I don't think that it is the best choice for the msec policy token. ASN.1 seems to provide much more flexibility in expressing content choices and constraints. More importantly, it is the specification language for the main security infrastructure (X.509) in use. ASN.1 will allow us to use many of the mechanism and naming conventions already defined by the security community. Using encoding techniques such as DER will allow us to interface easily with the infrastructure and will also allow us to define major structural components without needing to manually keep track of type assigments for internal structures. As I admitted above, my lack of familiarity with AVP may have caused me to inadvertantly overlook some of its features. Given what I have seen, however, I feel that ASN.1 is much more suitable. --- Andrea _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 25 14:11:19 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06118 for ; Mon, 25 Aug 2003 14:11:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B1638537D6; Mon, 25 Aug 2003 14:10:38 -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 C6200537DE for ; Mon, 25 Aug 2003 14:08:59 -0400 (EDT) Received: (qmail 96550 invoked by uid 3269); 25 Aug 2003 18:08:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96547 invoked from network); 25 Aug 2003 18:08:59 -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; 25 Aug 2003 18:08:59 -0000 Received: from cisco.com (jharper-w2k.cisco.com [128.107.163.44]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7PI8ui1025219; Mon, 25 Aug 2003 11:08:57 -0700 (PDT) Message-ID: <3F4A50B8.A78ED7A9@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: Andrea Colegrove Cc: "msec@securemulticast.org" Subject: Re: [MSEC] msec spec language References: <3F4A3E2D.6050201@columbia.sparta.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: Mon, 25 Aug 2003 11:08:56 -0700 Content-Transfer-Encoding: 7bit One consideration in the choice of specification language would be to consider what functional code unit will be constructing and processing it, and then choose a specification language that is native to that code unit. For example, will the key management code be more likely to process the policy token itself, or pass it on to a policy subsystem? I believe the suggestion of AVPs came from a believe that the key management code will often hand the policy token over to a AAA subsystem for actual processing. In that case, AVPs make a lot of sense. Group key management protocols based on ISAKMP (e.g., GDOI) might find ISAKMP TLVs and TVs to be most efficient, if they are going to process the policy token code themselves. Andrea's suggestion of ASN.1 implies that the key management will be more likely to process the policy token. If the key management code is already doing ASN.1 processing locally, then that makes a lot of sense. To summarize, I think we need to understand the whole interaction between the Policy and Key Management areas before we choose a policy token specification language. Thanks, Brian Andrea Colegrove wrote: > > All, > Discussions of the future msec token have been in the forefront of > this list recently. Obviously, the content of the token is and will > continue to be hotly debated. Another issue that should be carefully > considered, though, is the specification language of the token. One of > the recent proposals has been for Diameter's AVP framework. > > Having very little experience (none) with AVP in the past, I spent a > little bit of time looking at it the past couple of days. It does > provide a structural framework for defining many different types of > parameters -- security and others. It does allow for some "grouping" > and nesting of attributes. While quite suitable for many types of > policy, I am sure, I don't think that it is the best choice for the msec > policy token. > > ASN.1 seems to provide much more flexibility in expressing content > choices and constraints. More importantly, it is the specification > language for the main security infrastructure (X.509) in use. ASN.1 > will allow us to use many of the mechanism and naming conventions > already defined by the security community. Using encoding techniques > such as DER will allow us to interface easily with the infrastructure > and will also allow us to define major structural components without > needing to manually keep track of type assigments for internal structures. > > As I admitted above, my lack of familiarity with AVP may have caused > me to inadvertantly overlook some of its features. Given what I have > seen, however, I feel that ASN.1 is much more suitable. > > --- Andrea > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- 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 Tue Aug 26 13:56:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17287 for ; Tue, 26 Aug 2003 13:56:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 477E953599; Tue, 26 Aug 2003 13:56: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 DC7F15360C for ; Tue, 26 Aug 2003 13:50:46 -0400 (EDT) Received: (qmail 67588 invoked by uid 3269); 26 Aug 2003 17:50:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67583 invoked from network); 26 Aug 2003 17:50:46 -0000 Received: from smtp2.su.se (130.237.93.212) by klesh.pair.com with SMTP; 26 Aug 2003 17:50:46 -0000 Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id 553BC200090; Tue, 26 Aug 2003 19:50:45 +0200 (CEST) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07616-01; Tue, 26 Aug 2003 19:50:45 +0200 (CEST) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp2.su.se (Postfix) with ESMTP id E6441200007; Tue, 26 Aug 2003 19:50:44 +0200 (CEST) Received: from unni.dsv.su.se (localhost [127.0.0.1]) by spamcheck.local (Postfix) with ESMTP id C29158B34E; Tue, 26 Aug 2003 19:50:44 +0200 (CEST) Received: from SeadMuftic (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with SMTP id D45A08B339; Tue, 26 Aug 2003 19:50:43 +0200 (CEST) Message-Id: <3.0.32.20030826135043.00af7330@mail.dsv.su.se> X-Sender: sead@mail.dsv.su.se X-Mailer: Windows Eudora Pro Version 3.0 (32) To: "Hugh Harney" , From: Sead Muftic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by amavisd-new at su.se Subject: [MSEC] Splitting token from protocol 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, 26 Aug 2003 13:50:44 -0400 Hugh and other MSEC friends: >We struggled the decision to split the GSAKMP Policy Token into it's own >draft. We decided to do this for two reasons. Based on our current implementation of the GSAKMP and the first secure group application using GSAKMP, we fully support your decision. Decoupling GSAKMP from the Policy Token has several advantages. In principle, as you also suggest: (a) GSAKMP may use alternative authorization policies, and (b) Policy Token may itself be used as the specification of the authorization policy for other security protocols/applications, not only GSAKMP. So, separation of the GSAKMP from Policy Token would be really very helpful. Regards, Sead Muftic CSPRI/GWU _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 26 13:59:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17402 for ; Tue, 26 Aug 2003 13:59:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AEBE353672; Tue, 26 Aug 2003 13:58:35 -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 3A8ED53599 for ; Tue, 26 Aug 2003 13:55:15 -0400 (EDT) Received: (qmail 68307 invoked by uid 3269); 26 Aug 2003 17:55:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68304 invoked from network); 26 Aug 2003 17:55:15 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 26 Aug 2003 17:55:15 -0000 Received: (qmail 14498 invoked from network); 26 Aug 2003 17:55:11 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.186) by smtp-auth.nac.net with SMTP; 26 Aug 2003 17:55:11 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7QFmj527359; Tue, 26 Aug 2003 11:48:45 -0400 From: George Gross To: Brian Weis Cc: Andrea Colegrove , "msec@securemulticast.org" Subject: Re: [MSEC] msec spec language In-Reply-To: <3F4A50B8.A78ED7A9@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: Tue, 26 Aug 2003 11:48:45 -0400 (EDT) Hi Brian, On Mon, 25 Aug 2003, Brian Weis wrote: > One consideration in the choice of specification language would be to > consider what functional code unit will be constructing and processing > it, and then choose a specification language that is native to that code > unit. I would say another criteria for selection is minimizing the incremental development and operational cost of adding the secure multicast capability to the AAA infrastructure. That criteria includes minimizing the amount of re-inventing the wheel that we as a working group must do. When I take stock of the Diameter base AVP lexicon, and augment it with a subset of the network access application lexicon, my hunch is that we will discover reuse for secure multicast group policy tokens. Examples include AVP for re-authentication timers, filtering rules for what endpoints are authorized to talk to other endpoints, interaction with Enterprise authentication systems... > > For example, will the key management code be more likely to process the > policy token itself, or pass it on to a policy subsystem? > > I believe the suggestion of AVPs came from a believe that the key > management code will often hand the policy token over to a AAA subsystem > for actual processing. In that case, AVPs make a lot of sense. > > Group key management protocols based on ISAKMP (e.g., GDOI) might find > ISAKMP TLVs and TVs to be most efficient, if they are going to process > the policy token code themselves. > > Andrea's suggestion of ASN.1 implies that the key management will be > more likely to process the policy token. If the key management code is > already doing ASN.1 processing locally, then that makes a lot of sense. > > To summarize, I think we need to understand the whole interaction > between the Policy and Key Management areas before we choose a policy > token specification language. That's a fair expectation. It sounds like you'd like to see an architectural model/framework, and a usage case showing the policy token flow through the components in that framework. would that help the decision process? br, George > > Thanks, > Brian > > Andrea Colegrove wrote: > > > > All, > > Discussions of the future msec token have been in the forefront of > > this list recently. Obviously, the content of the token is and will > > continue to be hotly debated. Another issue that should be carefully > > considered, though, is the specification language of the token. One of > > the recent proposals has been for Diameter's AVP framework. > > > > Having very little experience (none) with AVP in the past, I spent a > > little bit of time looking at it the past couple of days. It does > > provide a structural framework for defining many different types of > > parameters -- security and others. It does allow for some "grouping" > > and nesting of attributes. While quite suitable for many types of > > policy, I am sure, I don't think that it is the best choice for the msec > > policy token. > > > > ASN.1 seems to provide much more flexibility in expressing content > > choices and constraints. More importantly, it is the specification > > language for the main security infrastructure (X.509) in use. ASN.1 > > will allow us to use many of the mechanism and naming conventions > > already defined by the security community. Using encoding techniques > > such as DER will allow us to interface easily with the infrastructure > > and will also allow us to define major structural components without > > needing to manually keep track of type assigments for internal structures. > > > > As I admitted above, my lack of familiarity with AVP may have caused > > me to inadvertantly overlook some of its features. Given what I have > > seen, however, I feel that ASN.1 is much more suitable. > > > > --- Andrea > > > > _______________________________________________ > > 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 Aug 26 16:21:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05472 for ; Tue, 26 Aug 2003 16:21:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A53F7536AA; Tue, 26 Aug 2003 16:20:57 -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 F130A53664 for ; Tue, 26 Aug 2003 16:16:59 -0400 (EDT) Received: (qmail 99234 invoked by uid 3269); 26 Aug 2003 20:17:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99228 invoked from network); 26 Aug 2003 20:16:59 -0000 Received: from smtp2.su.se (130.237.93.212) by klesh.pair.com with SMTP; 26 Aug 2003 20:16:59 -0000 Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id B68D02005AF for ; Tue, 26 Aug 2003 22:16:58 +0200 (CEST) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11815-07 for ; Tue, 26 Aug 2003 22:16:58 +0200 (CEST) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp2.su.se (Postfix) with ESMTP id 674BB20045E for ; Tue, 26 Aug 2003 22:16:58 +0200 (CEST) Received: from unni.dsv.su.se (localhost [127.0.0.1]) by spamcheck.local (Postfix) with ESMTP id 40E838B34F for ; Tue, 26 Aug 2003 22:16:58 +0200 (CEST) Received: from SeadMuftic (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with SMTP id 9C2338B339 for ; Tue, 26 Aug 2003 22:16:57 +0200 (CEST) Message-Id: <3.0.32.20030826161656.00af7330@mail.dsv.su.se> X-Sender: sead@mail.dsv.su.se X-Mailer: Windows Eudora Pro Version 3.0 (32) To: msec@securemulticast.org From: Sead Muftic Subject: [MSEC] Various Aspects of the Policy Token Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by amavisd-new at su.se 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, 26 Aug 2003 16:16:57 -0400 MSEC friends: Wrt Policy Token I think there are three issues to be addressed: (1) The scope (and eventually form) of the Authorization Policy which the token will represent (equivalence to the PKI Certificate Policy) (2) The contents of the token (in particular it should provide the possibility to specify/enforce different types of policies), and (3) Encoding format > As I admitted above, my lack of familiarity with AVP may have caused >me to inadvertantly overlook some of its features. Given what I have >seen, however, I feel that ASN.1 is much more suitable. > Wrt (3) I support Andrea, ASN.1 has proven to be the most suitable encoding standard for many types of objects in a variety of other standards. (1) and (2) may be topics for further discussion. The first decision, I believe, is whether we want Policy Token to be used only by the GSAKMP or by other (group security) protocols and second, whether we want to have simple "Yes/No" access to protected group resources or we need more detailed, fine-grained policy decisions. Finally, many of the newest WS standards reference some type of the policy, so I wonder (after separating Policy Token from the GSAKMP protocol) whether we'd like to go towards more general secure group authorization policies or not. Regards, Sead Muftic CSPRI/GWU _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 27 13:45:12 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21606 for ; Wed, 27 Aug 2003 13:45:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3CD645375D; Wed, 27 Aug 2003 13:44:43 -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 7BA365356E for ; Wed, 27 Aug 2003 13:42:43 -0400 (EDT) Received: (qmail 51631 invoked by uid 3269); 27 Aug 2003 17:42:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51626 invoked from network); 27 Aug 2003 17:42:42 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 27 Aug 2003 17:42:42 -0000 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2003 10:52:42 -0700 Received: from cisco.com (dhcp-128-107-163-153.cisco.com [128.107.163.153]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7RHgdi1004468; Wed, 27 Aug 2003 10:42:40 -0700 (PDT) Message-ID: <3F4CED8F.F4973EA8@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: George Gross Cc: "msec@securemulticast.org" Subject: Re: [MSEC] msec spec language References: 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, 27 Aug 2003 10:42:39 -0700 Content-Transfer-Encoding: 7bit Hi George, George Gross wrote: > > Hi Brian, > > On Mon, 25 Aug 2003, Brian Weis wrote: > > > One consideration in the choice of specification language would be to > > consider what functional code unit will be constructing and processing > > it, and then choose a specification language that is native to that code > > unit. > > I would say another criteria for selection is minimizing the incremental > development and operational cost of adding the secure multicast capability > to the AAA infrastructure. That criteria includes minimizing the amount of > re-inventing the wheel that we as a working group must do. When I take > stock of the Diameter base AVP lexicon, and augment it with a subset of > the network access application lexicon, my hunch is that we will discover > reuse for secure multicast group policy tokens. Examples include AVP for > re-authentication timers, filtering rules for what endpoints are > authorized to talk to other endpoints, interaction with Enterprise > authentication systems... When you ay "reuse for secure multicast group policy tokens", do you mean adding more policy to the policy token, or re-using the basic structure for unicast protocols? The examples you mention above could be both, I think. > > > > For example, will the key management code be more likely to process the > > policy token itself, or pass it on to a policy subsystem? > > > > I believe the suggestion of AVPs came from a believe that the key > > management code will often hand the policy token over to a AAA subsystem > > for actual processing. In that case, AVPs make a lot of sense. > > > > Group key management protocols based on ISAKMP (e.g., GDOI) might find > > ISAKMP TLVs and TVs to be most efficient, if they are going to process > > the policy token code themselves. > > > > Andrea's suggestion of ASN.1 implies that the key management will be > > more likely to process the policy token. If the key management code is > > already doing ASN.1 processing locally, then that makes a lot of sense. > > > > To summarize, I think we need to understand the whole interaction > > between the Policy and Key Management areas before we choose a policy > > token specification language. > > That's a fair expectation. It sounds like you'd like to see an > architectural model/framework, and a usage case showing the policy token > flow through the components in that framework. would that help the > decision process? That's a great idea. In fact, it could very well fit into the Policy Architecture document that we originally thought would be written. There seem to be different views on how the policy token can be used, and getting those written down somewhere would be beneficial. I'm not sure what the best document structure would be. Thanks, Brian > br, > George > > > > > Thanks, > > Brian > > > > Andrea Colegrove wrote: > > > > > > All, > > > Discussions of the future msec token have been in the forefront of > > > this list recently. Obviously, the content of the token is and will > > > continue to be hotly debated. Another issue that should be carefully > > > considered, though, is the specification language of the token. One of > > > the recent proposals has been for Diameter's AVP framework. > > > > > > Having very little experience (none) with AVP in the past, I spent a > > > little bit of time looking at it the past couple of days. It does > > > provide a structural framework for defining many different types of > > > parameters -- security and others. It does allow for some "grouping" > > > and nesting of attributes. While quite suitable for many types of > > > policy, I am sure, I don't think that it is the best choice for the msec > > > policy token. > > > > > > ASN.1 seems to provide much more flexibility in expressing content > > > choices and constraints. More importantly, it is the specification > > > language for the main security infrastructure (X.509) in use. ASN.1 > > > will allow us to use many of the mechanism and naming conventions > > > already defined by the security community. Using encoding techniques > > > such as DER will allow us to interface easily with the infrastructure > > > and will also allow us to define major structural components without > > > needing to manually keep track of type assigments for internal structures. > > > > > > As I admitted above, my lack of familiarity with AVP may have caused > > > me to inadvertantly overlook some of its features. Given what I have > > > seen, however, I feel that ASN.1 is much more suitable. > > > > > > --- Andrea > > > > > > _______________________________________________ > > > 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 -- 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 Aug 27 14:42:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25453 for ; Wed, 27 Aug 2003 14:42:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4FFEB53772; Wed, 27 Aug 2003 14:42: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 42DF153679 for ; Wed, 27 Aug 2003 14:40:06 -0400 (EDT) Received: (qmail 61994 invoked by uid 3269); 27 Aug 2003 18:40:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61991 invoked from network); 27 Aug 2003 18:40:06 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 27 Aug 2003 18:40:06 -0000 Received: (qmail 32316 invoked from network); 27 Aug 2003 18:38:57 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.181) by smtp-auth.nac.net with SMTP; 27 Aug 2003 18:38:57 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7RGWQY24081; Wed, 27 Aug 2003 12:32:26 -0400 From: George Gross To: Brian Weis Cc: George Gross , "msec@securemulticast.org" Subject: Re: [MSEC] msec spec language In-Reply-To: <3F4CED8F.F4973EA8@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: Wed, 27 Aug 2003 12:32:26 -0400 (EDT) Hi Brian, On Wed, 27 Aug 2003, Brian Weis wrote: > Hi George, > > George Gross wrote: > > > > Hi Brian, > > > > On Mon, 25 Aug 2003, Brian Weis wrote: > > > > > One consideration in the choice of specification language would be to > > > consider what functional code unit will be constructing and processing > > > it, and then choose a specification language that is native to that code > > > unit. > > > > I would say another criteria for selection is minimizing the incremental > > development and operational cost of adding the secure multicast capability > > to the AAA infrastructure. That criteria includes minimizing the amount of > > re-inventing the wheel that we as a working group must do. When I take > > stock of the Diameter base AVP lexicon, and augment it with a subset of > > the network access application lexicon, my hunch is that we will discover > > reuse for secure multicast group policy tokens. Examples include AVP for > > re-authentication timers, filtering rules for what endpoints are > > authorized to talk to other endpoints, interaction with Enterprise > > authentication systems... > > When you ay "reuse for secure multicast group policy tokens", do you > mean adding more policy to the policy token, or re-using the basic > structure for unicast protocols? The examples you mention above could be > both, I think. yes, I do see reuse of the AVP syntax and semantics for both unicast and multicast cases of distributing the policy token. where I'm fuzzy at the moment is which AVP for which sender/recipients pairings. understanding that more precisely is kinda coupled to the framework/model that describes policy token flow, as per our discussion below. > > > > > > > For example, will the key management code be more likely to process the > > > policy token itself, or pass it on to a policy subsystem? > > > > > > I believe the suggestion of AVPs came from a believe that the key > > > management code will often hand the policy token over to a AAA subsystem > > > for actual processing. In that case, AVPs make a lot of sense. > > > > > > Group key management protocols based on ISAKMP (e.g., GDOI) might find > > > ISAKMP TLVs and TVs to be most efficient, if they are going to process > > > the policy token code themselves. > > > > > > Andrea's suggestion of ASN.1 implies that the key management will be > > > more likely to process the policy token. If the key management code is > > > already doing ASN.1 processing locally, then that makes a lot of sense. > > > > > > To summarize, I think we need to understand the whole interaction > > > between the Policy and Key Management areas before we choose a policy > > > token specification language. > > > > That's a fair expectation. It sounds like you'd like to see an > > architectural model/framework, and a usage case showing the policy token > > flow through the components in that framework. would that help the > > decision process? > > That's a great idea. In fact, it could very well fit into the Policy > Architecture document that we originally thought would be written. There > seem to be different views on how the policy token can be used, and > getting those written down somewhere would be beneficial. I'm not sure > what the best document structure would be. My working view was that would be a candidate sub-section in the msec-gspt-02.txt draft. Starting a new "policy token arch" draft has alot of inertia to get off the block. I sorta had foreseen the need for this framework/model, but had been assuming it would be oriented towards showing the linkage of the GCKS/group owner/group member to a Diameter/AAA approach. So I was thinking I'd float some text for the msec-gspt-02.txt draft once I had enough cycles free to flesh it out early next week. Adding a discussion of tradeoffs for policy token preferred encoding scheme had not been on my radar until now. I'll perk on this over the weekend... I'd welcome your contribution of text/ASCII art on this topic ;o) br, George > > Thanks, > Brian > > > br, > > George > > > > > > > > Thanks, > > > Brian > > > > > > Andrea Colegrove wrote: > > > > > > > > All, > > > > Discussions of the future msec token have been in the forefront of > > > > this list recently. Obviously, the content of the token is and will > > > > continue to be hotly debated. Another issue that should be carefully > > > > considered, though, is the specification language of the token. One of > > > > the recent proposals has been for Diameter's AVP framework. > > > > > > > > Having very little experience (none) with AVP in the past, I spent a > > > > little bit of time looking at it the past couple of days. It does > > > > provide a structural framework for defining many different types of > > > > parameters -- security and others. It does allow for some "grouping" > > > > and nesting of attributes. While quite suitable for many types of > > > > policy, I am sure, I don't think that it is the best choice for the msec > > > > policy token. > > > > > > > > ASN.1 seems to provide much more flexibility in expressing content > > > > choices and constraints. More importantly, it is the specification > > > > language for the main security infrastructure (X.509) in use. ASN.1 > > > > will allow us to use many of the mechanism and naming conventions > > > > already defined by the security community. Using encoding techniques > > > > such as DER will allow us to interface easily with the infrastructure > > > > and will also allow us to define major structural components without > > > > needing to manually keep track of type assigments for internal structures. > > > > > > > > As I admitted above, my lack of familiarity with AVP may have caused > > > > me to inadvertantly overlook some of its features. Given what I have > > > > seen, however, I feel that ASN.1 is much more suitable. > > > > > > > > --- Andrea > > > > > > > > _______________________________________________ > > > > 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 Aug 28 23:01:59 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16246 for ; Thu, 28 Aug 2003 23:01:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4663D535B4; Thu, 28 Aug 2003 23:00:54 -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 51088536B9 for ; Thu, 28 Aug 2003 22:58:46 -0400 (EDT) Received: (qmail 41368 invoked by uid 3269); 29 Aug 2003 02:58:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41365 invoked from network); 29 Aug 2003 02:58:44 -0000 Received: from pigeon.verisign.com (65.205.251.71) by klesh.pair.com with SMTP; 29 Aug 2003 02:58:44 -0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h7T2whip019679 for ; Thu, 28 Aug 2003 19:58:43 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 19:58:43 -0700 Message-ID: From: "Hardjono, Thomas" To: "'msec@securemulticast.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [MSEC] test - pls ignore 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, 28 Aug 2003 19:58:43 -0700 test - pls ignore _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 28 23:05:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16567 for ; Thu, 28 Aug 2003 23:05:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3598A535D2; Thu, 28 Aug 2003 23:04:43 -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 976EB53614 for ; Thu, 28 Aug 2003 23:02:02 -0400 (EDT) Received: (qmail 41693 invoked by uid 3269); 29 Aug 2003 03:02:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41690 invoked from network); 29 Aug 2003 03:02:02 -0000 Received: from smtp101.mail.sc5.yahoo.com (216.136.174.139) by klesh.pair.com with SMTP; 29 Aug 2003 03:02:02 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@66.30.225.187 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Aug 2003 03:01:58 -0000 Message-Id: <5.2.1.1.2.20030828230136.02368a58@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: thardjono@verisign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] test -- ignore 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, 28 Aug 2003 23:01:55 -0400 test -- ignore test -- ignore _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 29 08:40:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18349 for ; Fri, 29 Aug 2003 08:40:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C8D71535BF; Fri, 29 Aug 2003 08:40: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 ACD7C535BF for ; Fri, 29 Aug 2003 08:37:23 -0400 (EDT) Received: (qmail 62915 invoked by uid 3269); 29 Aug 2003 12:37:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62912 invoked from network); 29 Aug 2003 12:37:23 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 29 Aug 2003 12:37:23 -0000 Received: (qmail 65694 invoked from network); 29 Aug 2003 12:37:22 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.173) by smtp-auth.nac.net with SMTP; 29 Aug 2003 12:37:22 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7TAUYR27031; Fri, 29 Aug 2003 06:30:34 -0400 From: George Gross To: Cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length 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, 29 Aug 2003 06:30:34 -0400 (EDT) Hi Hugh, The following issue is dangling from an e-mail I had sent to the MSEC list on July 4th, and there was no discussion of it subsequently. So, to avoid it being lost in the weeds, I decided to revive it, and tag it similar to the other comments I've noted wrt/ GSAKMP. Its been about 3 weeks since I sent those e-mails. When addressing them, please reply to the list using the same subject line as the original e-mail so it is feasible to track the thread in the mail archive. Please do not simply re-issue the v04 draft with changes, as it would be best to have discussion on this list first. thank you, George P.S. this e-mail is a resend, as it never made to the MSEC mail archive (or back to my own e-mail address). My apologies if from your mailbox perspective it is duplicate of the one I sent yesterday. GSAKMP issue 24 Section and relevant text passage: Section 4.2.1.2, the spec says: "The Policy Token and Key Download payloads are sent encrypted in the KEK generated by the Key Creation payload information using the mechanisms defined in the group announcment." Comment/issue description: However, the group announcement is done out of band and it is not defined within this specification. Yet here it directly impacts what algorithms and key lengths one would expect to encounter in the Key Download message. This seems to imply you can't connect to the group unless a candidate member is privy to some non-standard pre-arranged convention, which is overly restrictive and non-interoperable. Suggested issue resolution: I think that the "mechanisms defined in the group announcement" should also be copied as a new set of fields in the Request To Join message. That way, the GCKS can accept group members who did not hear the group announcement, or may have heard an older version of the group announcement that specified a different KEK algorithm, mode, and key length than a more recent version of that announcement. Further, the protocol spec should mandate at least one algorithm, mode, and key length that both GCKS and group members are both required to implement for the KEK. This seems to be a place where you would say something like: "...using the mechanisms defined in the group announcement, which are required to be identical to the set defined for IKEv2, or the IANA registry's current set of algorithms. This includes the same MUST implement requirements as IKEv2" or some words to that effect (wordsmithing TBD). _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 29 08:56:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19873 for ; Fri, 29 Aug 2003 08:56:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 65106535BF; Fri, 29 Aug 2003 08:55: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 C6C8453667 for ; Fri, 29 Aug 2003 08:54:00 -0400 (EDT) Received: (qmail 65460 invoked by uid 3269); 29 Aug 2003 12:54:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65457 invoked from network); 29 Aug 2003 12:54:00 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 29 Aug 2003 12:54:00 -0000 Received: (qmail 38083 invoked from network); 29 Aug 2003 12:53:59 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.173) by smtp-auth.nac.net with SMTP; 29 Aug 2003 12:53:59 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7TAlB627062; Fri, 29 Aug 2003 06:47:11 -0400 From: George Gross To: Brian Weis Cc: Subject: Re: [MSEC] msec spec language In-Reply-To: <3F4E49C6.CA1352FF@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: Fri, 29 Aug 2003 06:47:11 -0400 (EDT) Hi Brian, this is a resend of my e-mail originally sent yesterday that did not make it to the MSEC list archive or make it back to my own e-mail address from msec@securemulticast.org. George On Wed, 27 Aug 2003, Brian Weis wrote: > > > Hi George, > > George Gross wrote: > > > > Hi Brian, > > > > On Mon, 25 Aug 2003, Brian Weis wrote: > > > > > One consideration in the choice of specification language would be to > > > consider what functional code unit will be constructing and processing > > > it, and then choose a specification language that is native to that code > > > unit. > > > > I would say another criteria for selection is minimizing the incremental > > development and operational cost of adding the secure multicast capability > > to the AAA infrastructure. That criteria includes minimizing the amount of > > re-inventing the wheel that we as a working group must do. When I take > > stock of the Diameter base AVP lexicon, and augment it with a subset of > > the network access application lexicon, my hunch is that we will discover > > reuse for secure multicast group policy tokens. Examples include AVP for > > re-authentication timers, filtering rules for what endpoints are > > authorized to talk to other endpoints, interaction with Enterprise > > authentication systems... > > When you ay "reuse for secure multicast group policy tokens", do you > mean adding more policy to the policy token, or re-using the basic > structure for unicast protocols? The examples you mention above could be > both, I think. > > yes, I do see reuse of the AVP syntax and semantics for both unicast and multicast cases of distributing the policy token. where I'm fuzzy at the moment is which AVP for which sender/recipients pairings. understanding that more precisely is kinda coupled to the framework/model that describes policy token flow, as per our discussion below. > > > > > > > > > For example, will the key management code be more likely to process the > > > policy token itself, or pass it on to a policy subsystem? > > > > > > I believe the suggestion of AVPs came from a believe that the key > > > management code will often hand the policy token over to a AAA subsystem > > > for actual processing. In that case, AVPs make a lot of sense. > > > > > > Group key management protocols based on ISAKMP (e.g., GDOI) might find > > > ISAKMP TLVs and TVs to be most efficient, if they are going to process > > > the policy token code themselves. > > > > > > Andrea's suggestion of ASN.1 implies that the key management will be > > > more likely to process the policy token. If the key management code is > > > already doing ASN.1 processing locally, then that makes a lot of sense. > > > > > > To summarize, I think we need to understand the whole interaction > > > between the Policy and Key Management areas before we choose a policy > > > token specification language. > > > > That's a fair expectation. It sounds like you'd like to see an > > architectural model/framework, and a usage case showing the policy token > > flow through the components in that framework. would that help the > > decision process? > > That's a great idea. In fact, it could very well fit into the Policy > Architecture document that we originally thought would be written. There > seem to be different views on how the policy token can be used, and > getting those written down somewhere would be beneficial. I'm not sure > what the best document structure would be. > > My working view was that would be a candidate sub-section in the msec-gspt-02.txt draft. Starting a new "policy token arch" draft has alot of inertia to get off the block. I sorta had foreseen the need for this framework/model, but had been assuming it would be oriented towards showing the linkage of the GCKS/group owner/group member to a Diameter/AAA approach. So I was thinking I'd float some text for the msec-gspt-02.txt draft once I had enough cycles free to flesh it out early next week. Adding a discussion of tradeoffs for policy token preferred encoding scheme had not been on my radar until now. I'll perk on this over the weekend... I'd welcome your contribution of text/ASCII art on this topic ;o) br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 29 11:06:23 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01269 for ; Fri, 29 Aug 2003 11:06:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0034C537B4; Fri, 29 Aug 2003 11:04:50 -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 2197553669 for ; Fri, 29 Aug 2003 11:01:41 -0400 (EDT) Received: (qmail 85952 invoked by uid 3269); 29 Aug 2003 15:01:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85949 invoked from network); 29 Aug 2003 15:01:41 -0000 Received: from gull.mail.pas.earthlink.net (207.217.120.84) by klesh.pair.com with SMTP; 29 Aug 2003 15:01:41 -0000 Received: from user-2ivekt8.dialup.mindspring.com ([165.247.83.168] helo=stealth) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19skks-0002fM-00; Fri, 29 Aug 2003 08:01:39 -0700 Message-ID: <002101c36e3e$7170a020$9865fea9@stealth> From: "Andrea Colegrove" To: "George Gross" , Cc: References: Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 29 Aug 2003 11:01:34 -0400 Content-Transfer-Encoding: 7bit George, I am afraid that I cannot agree with the suggestion on the RTJ. The strength and choice of mechanisms for group keys must be consistent with every key download sent to each member. To vary this would destroy the integrity of the protection of group data. It is inconsistent to decide to download the information in algorithm SUPERSTRONG for one join and in DES for the next, because of what is supported by the potential member. If the potential member cannot support SUPERSTRONG, then that member doesn't have the necessary mechanisms to support the group SA and thus should not be in the group. Knowledge of the existence of a group and its "address" is obtained in some sort of group announcement. It is not any more of an operational problem to obtain initial mechanism support requirements in this manner as well. --- Andrea ----- Original Message ----- From: "George Gross" To: Cc: Sent: Friday, August 29, 2003 6:30 AM Subject: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length > Hi Hugh, > > The following issue is dangling from an e-mail I had sent to the MSEC list > on July 4th, and there was no discussion of it subsequently. So, to avoid it being > lost in the weeds, I decided to revive it, and tag it similar to the other comments I've > noted wrt/ GSAKMP. Its been about 3 weeks since I sent those e-mails. When addressing them, > please reply to the list using the same subject line as the original e-mail so it is > feasible to track the thread in the mail archive. Please do not simply re-issue the > v04 draft with changes, as it would be best to have discussion on this list first. > > thank you, > > George > > P.S. this e-mail is a resend, as it never made to the MSEC mail archive > (or back to my own e-mail address). My apologies if from your mailbox > perspective it is duplicate of the one I sent yesterday. > > GSAKMP issue 24 > > Section and relevant text passage: > > Section 4.2.1.2, the spec says: > > "The Policy Token and Key Download payloads are sent encrypted in the KEK > generated by the Key Creation payload information using the mechanisms > defined in the group announcment." > > Comment/issue description: > > However, the group announcement is done out of band and it is not defined > within this specification. Yet here it directly impacts what algorithms > and key lengths one would expect to encounter in the Key Download message. > This seems to imply you can't connect to the group unless a candidate > member is privy to some non-standard pre-arranged convention, which is > overly restrictive and non-interoperable. > > Suggested issue resolution: > > I think that the "mechanisms defined in the group announcement" should also be > copied as a new set of fields in the Request To Join message. That way, the GCKS > can accept group members who did not hear the group announcement, or may have heard an > older version of the group announcement that specified a different KEK algorithm, > mode, and key length than a more recent version of that announcement. > > Further, the protocol spec should mandate at least one algorithm, mode, and key > length that both GCKS and group members are both required to implement for the KEK. > > This seems to be a place where you would say something like: > > "...using the mechanisms defined in the group announcement, which are > required to be identical to the set defined for IKEv2, or the IANA > registry's current set of algorithms. This includes the same MUST > implement requirements as IKEv2" > > or some words to that effect (wordsmithing TBD). > > > _______________________________________________ > 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 Fri Aug 29 12:14:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08801 for ; Fri, 29 Aug 2003 12:14:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BF0C053800; Fri, 29 Aug 2003 12:14:04 -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 1605053565 for ; Fri, 29 Aug 2003 12:12:27 -0400 (EDT) Received: (qmail 98485 invoked by uid 3269); 29 Aug 2003 16:12:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98482 invoked from network); 29 Aug 2003 16:12:27 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 29 Aug 2003 16:12:27 -0000 Received: (qmail 68124 invoked from network); 29 Aug 2003 16:12:13 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.173) by smtp-auth.nac.net with SMTP; 29 Aug 2003 16:12:13 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h7TE5NY27280; Fri, 29 Aug 2003 10:05:23 -0400 From: George Gross To: Andrea Colegrove Cc: George Gross , Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length In-Reply-To: <002101c36e3e$7170a020$9865fea9@stealth> 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: Fri, 29 Aug 2003 10:05:23 -0400 (EDT) Hi Andrea, On Fri, 29 Aug 2003, Andrea Colegrove wrote: > George, > I am afraid that I cannot agree with the suggestion on the RTJ. > > The strength and choice of mechanisms for group keys must be consistent > with every key download sent to each member. To vary this would destroy the > integrity of the protection of group data. No, the GCKS always has the right to refuse membership if the asserted Key Download KEK algorithm/mode/key length does not align with group policy. See below for additional considerations and configurations that GSAKMP must support. > It is inconsistent to decide to > download the information in algorithm SUPERSTRONG for one join and in DES > for the next, because of what is supported by the potential member. Not having this mechanism in the RTJ will hardwire a particular group policy decision into the GSAKMP protocol. By adding this information to the RTJ, we are allowing hetrogenous group memberships as new versions of the protocol and algorithms arrive in the field. It is an unreasonable migration obstacle for the protocol to expect a flash cut of the membership to newer versions. For example, if AES-128 is the norm for version 1, and version 2 also supported AES-192, and local group policy allowed it, there is no reason to deny membership for version 1 endpoints using AES-128. > > If the > potential member cannot support SUPERSTRONG, then that member doesn't have > the necessary mechanisms to support the group SA and thus should not be in > the group. As noted above, the GCKS passes judgement on the RTJ. If it denies membership, it would send a NACK. > Knowledge of the existence of a group and its "address" is obtained in > some sort of group announcement. The "some sort of group announcement" is an example of unspecified information that will cripple inter-operability. Every vendor who implements GSAKMP is gonna roll their own "group announcement" mechanism? That does not foster inter-operability, but if you are unable to standardize that mechanism as a protocol then it is incumbent on the GSAKMP specification to: 1) exactly prescribe what information the group announcement must contain and the valid values for those parameters, including the MUST implement values. 2) Specify that the RTJ in a vendor-independent way tell the GCKS what the candidate member heard in that vendor-specific group announcement In a multi-vendor Internet, you can not make GSAKMP dependent on knowledge of an unspecified and non-standardized group announcement. If we are unable to standardize the group announcement, then the RTJ must standardize the information extracted from the vendor-specific group announcement. In other words, given: 1) a group announcement by vendor A who openly publishes their spec, 2) group member using GSAKMP from vendor B, that understands vendor A's group announcement, 3) and GCKS using GSAKMP from vendor C that doesn't implement vendor A's spec for group announcments. They should all be able to work together. The network operator should not have to deploy vendor C's group announcment mechanism, nor should they expect all group members to be from vendor C. They just need to be able to configure the GCKS so that its view of the group announcement matches what vendor A advertises even if the GCKS couldn't understand the bits on the wire of that vendor A advertisement's encoding. And the GCKS must be able to inter-operate with vendor B endpoints, and vendor A's, and vendor D's.... > It is not any more of an operational > problem to obtain initial mechanism support requirements in this manner as > well. As seen above, there are clearly issues about multiple versions and multiple vendors deploying GSAKMP. These are real issues, and they have the potential of making GSAKMP unusable in the field. In my mind, this is a litmus test for the GSAKMP co-authors to alter the specification to meet the higher bar required for a proposed standard. George > > --- Andrea > > ----- Original Message ----- > From: "George Gross" > To: > Cc: > Sent: Friday, August 29, 2003 6:30 AM > Subject: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK > algorithm, mode, key length > > > > Hi Hugh, > > > > The following issue is dangling from an e-mail I had sent to the MSEC list > > on July 4th, and there was no discussion of it subsequently. So, to avoid > it being > > lost in the weeds, I decided to revive it, and tag it similar to the other > comments I've > > noted wrt/ GSAKMP. Its been about 3 weeks since I sent those e-mails. When > addressing them, > > please reply to the list using the same subject line as the original > e-mail so it is > > feasible to track the thread in the mail archive. Please do not simply > re-issue the > > v04 draft with changes, as it would be best to have discussion on this > list first. > > > > thank you, > > > > George > > > > P.S. this e-mail is a resend, as it never made to the MSEC mail archive > > (or back to my own e-mail address). My apologies if from your mailbox > > perspective it is duplicate of the one I sent yesterday. > > > > GSAKMP issue 24 > > > > Section and relevant text passage: > > > > Section 4.2.1.2, the spec says: > > > > "The Policy Token and Key Download payloads are sent encrypted in the KEK > > generated by the Key Creation payload information using the mechanisms > > defined in the group announcment." > > > > Comment/issue description: > > > > However, the group announcement is done out of band and it is not defined > > within this specification. Yet here it directly impacts what algorithms > > and key lengths one would expect to encounter in the Key Download message. > > This seems to imply you can't connect to the group unless a candidate > > member is privy to some non-standard pre-arranged convention, which is > > overly restrictive and non-interoperable. > > > > Suggested issue resolution: > > > > I think that the "mechanisms defined in the group announcement" should > also be > > copied as a new set of fields in the Request To Join message. That way, > the GCKS > > can accept group members who did not hear the group announcement, or may > have heard an > > older version of the group announcement that specified a different KEK > algorithm, > > mode, and key length than a more recent version of that announcement. > > > > Further, the protocol spec should mandate at least one algorithm, mode, > and key > > length that both GCKS and group members are both required to implement for > the KEK. > > > > This seems to be a place where you would say something like: > > > > "...using the mechanisms defined in the group announcement, which are > > required to be identical to the set defined for IKEv2, or the IANA > > registry's current set of algorithms. This includes the same MUST > > implement requirements as IKEv2" > > > > or some words to that effect (wordsmithing TBD). > > > > > > _______________________________________________ > > 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 Fri Aug 29 13:04:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14700 for ; Fri, 29 Aug 2003 13:04:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EB70F53552; Fri, 29 Aug 2003 13:04: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 A988D53800 for ; Fri, 29 Aug 2003 13:02:01 -0400 (EDT) Received: (qmail 6268 invoked by uid 3269); 29 Aug 2003 17:02:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6265 invoked from network); 29 Aug 2003 17:02:01 -0000 Received: from gull.mail.pas.earthlink.net (207.217.120.84) by klesh.pair.com with SMTP; 29 Aug 2003 17:02:01 -0000 Received: from user-2ivekt8.dialup.mindspring.com ([165.247.83.168] helo=stealth) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19smdK-00022X-00; Fri, 29 Aug 2003 10:01:59 -0700 Message-ID: <005901c36e4f$4133ee60$9865fea9@stealth> From: "Andrea Colegrove" To: "George Gross" Cc: "George Gross" , References: Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 29 Aug 2003 13:01:55 -0400 Content-Transfer-Encoding: 7bit George, > > I am afraid that I cannot agree with the suggestion on the RTJ. > > > > The strength and choice of mechanisms for group keys must be consistent > > with every key download sent to each member. To vary this would destroy the > > integrity of the protection of group data. > > No, the GCKS always has the right to refuse membership if the asserted Key > Download KEK algorithm/mode/key length does not align with group policy. What does this accomplish? The RTJ itself has security requirements on it. A GCKS should not even attempt to process something that is not of sufficient caliber. So even before RTJ, the potential member must have some knowledge of the group. If we look at Tunnelled GSAKMP, we see add some negotiation capability before Key Download, but even so, the member still needs to know what the group is about: address, application, etc. This is done through web interfaces, SAP, etc. Whether the key download is not interpretable by the potential member or whether the GCKS NACKs the member is irrelevant from the perspective of the new member. The bottom line for the GCKS: The policy of a group is not negotiable, unless with each negotiation, you query the existing group membership to see if anyone wants to opt out. > > It is inconsistent to decide to > > download the information in algorithm SUPERSTRONG for one join and in DES > > for the next, because of what is supported by the potential member. > > Not having this mechanism in the RTJ will hardwire a particular group > policy decision into the GSAKMP protocol. By adding this information to > the RTJ, we are allowing hetrogenous group memberships as new versions of > the protocol and algorithms arrive in the field. It is an unreasonable > migration obstacle for the protocol to expect a flash cut of the > membership to newer versions. For example, if AES-128 is the norm for > version 1, and version 2 also supported AES-192, and local group policy > allowed it, there is no reason to deny membership for version 1 endpoints > using AES-128. > If a group's policy allowed it -- then yes. One of the nice things about flexible specification languages such as ASN.1 is that it allows flexibility of group policy to KeyDownloadMech (or whatever)::= CHOICE { aES128 [0] AES128, aES192 [1] AES192 } This does not hardwire it to a version of GSAKMP -- the announced mechanisms can be the suite defined as Suite 1, a set of algorithms independent of any suite, or a new Suite 2 defined independently. > > > > If the > > potential member cannot support SUPERSTRONG, then that member doesn't have > > the necessary mechanisms to support the group SA and thus should not be in > > the group. > > > Knowledge of the existence of a group and its "address" is obtained in > > some sort of group announcement. > > The "some sort of group announcement" is an example of unspecified > information that will cripple inter-operability. Every vendor who > implements GSAKMP is gonna roll their own "group announcement" mechanism? > Someone advertising a group will indicate what the group is about, where it is to be found (addresses, applications, etc.), what security management (and parameter choices), etc. Security management is only a part of the group application problem. See SIP, SAP, etc for more info here. > > It is not any more of an operational > > problem to obtain initial mechanism support requirements in this manner as > > well. > > As seen above, there are clearly issues about multiple versions and > multiple vendors deploying GSAKMP. These are real issues, and they have > the potential of making GSAKMP unusable in the field. Once again, there is a difference between a version of a protocol and the mechanisms that a particular implementation may choose to support. Yes, there needs to be a MUST implement set for interoperability testing (we have that in Suite 1), but support of different mechanisms does not mean different protocol versions. --- Andrea _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec