From msec-admin@securemulticast.org Tue Apr 1 05:14:14 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02904 for ; Tue, 1 Apr 2003 05:14:13 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 185CE5381D; Tue, 1 Apr 2003 05:16:09 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7BEE95381C for ; Tue, 1 Apr 2003 05:15:52 -0500 (EST) Received: (qmail 45345 invoked by uid 3269); 1 Apr 2003 10:15:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45341 invoked from network); 1 Apr 2003 10:15:52 -0000 Received: from netmedia.kjist.ac.kr (203.237.53.16) by klesh.pair.com with SMTP; 1 Apr 2003 10:15:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Message-ID: <0ECD92AD3DC97C4686C7C172D347FA1A1D67E0@nml.netmedia.kjist.ac.kr> Thread-Topic: Questions: Relation among GSAKMP, GDOI and other Documents thread-index: AcL4N41m86J0u16uR2mnKfDXoqlcIQ== From: "Deuk-Whee Kwak" To: Subject: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents 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, 1 Apr 2003 19:15:01 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02904 How are you? I have been studying on the multicast key management protocols such as GSAKMP, GDOI, and MIKEY In the document MIKEY, the authors say that MIKEY can be used as a registration protocol in the GKMArch. But considered GSAKMP, I think I can also use GSAKMP for a registration protocol. Is it possible? If so, what are the merits and demerits of MIKEY and GSAKMP. If not, why? And what is the relation between GSAKMP and GDOI. If GSAKMP can be used as a registration protocol, what are the main purposes of GDOI? Is this used for re-key protocol? It is also confusing me that there are too many key management-related documents such as GKMP architecture (RFC 2094), GKMP specification (RFC 2093), Scalable Multicast Key Distribution (RFC 1949) and so on Are there any documents or papers that explain their relation among them? Best regards, D. W. Kwak _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 10:00:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15957 for ; Tue, 1 Apr 2003 10:00:09 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DECAD53881; Tue, 1 Apr 2003 10:02:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2D89053753 for ; Tue, 1 Apr 2003 10:00:14 -0500 (EST) Received: (qmail 82105 invoked by uid 3269); 1 Apr 2003 15:00:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82102 invoked from network); 1 Apr 2003 15:00:13 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 1 Apr 2003 15:00:13 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31F05P24731; Tue, 1 Apr 2003 10:00:06 -0500 (EST) 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 HB8AN24S; Tue, 1 Apr 2003 10:00:04 -0500 Received: from nortelnetworks.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 HBX3CGR0; Tue, 1 Apr 2003 10:00:04 -0500 Message-ID: <3E89AA10.4040904@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Deuk-Whee Kwak Cc: msec@securemulticast.org Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents References: <0ECD92AD3DC97C4686C7C172D347FA1A1D67E0@nml.netmedia.kjist.ac.kr> Content-Type: text/plain; charset=x-windows-949 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, 01 Apr 2003 10:02:40 -0500 Content-Transfer-Encoding: 7bit Hi, Yes, indeed it is confusing. If you look for "Standards Track" documents only, your field will narrow down a bit. But you will still have a few (GDOI, GSAKMP, and MIKEY) remaining to choose from. So, I invite the individual I-D authors to send their thoughts on how their protocols differ from others. In fact, I have requested some of the authors to send an email to GKMarch authors along these lines, so we can document the applicability of the three Group Key Management Protocols that are on Standards Track in MSEC. Please send your thoughts to the list. Many thanks. best regards, Lakshminath Deuk-Whee Kwak wrote: > How are you? > I have been studying on the multicast key management protocols such as GSAKMP, GDOI, and MIKEY > In the document MIKEY, the authors say that MIKEY can be used as a registration protocol in the GKMArch. > But considered GSAKMP, I think I can also use GSAKMP for a registration protocol. > Is it possible? If so, what are the merits and demerits of MIKEY and GSAKMP. If not, why? > > And what is the relation between GSAKMP and GDOI. If GSAKMP can be used as a registration protocol, what are the main purposes of GDOI? Is this used for re-key protocol? > It is also confusing me that there are too many key management-related documents such as GKMP architecture (RFC 2094), GKMP specification (RFC 2093), Scalable Multicast Key Distribution (RFC 1949) and so on > Are there any documents or papers that explain their relation among them? > > Best regards, > D. W. Kwak > > > _______________________________________________ > 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 Apr 1 10:23:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19704 for ; Tue, 1 Apr 2003 10:23:20 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A20B953889; Tue, 1 Apr 2003 10:22:43 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2F59A535A0 for ; Tue, 1 Apr 2003 10:21:45 -0500 (EST) Received: (qmail 86661 invoked by uid 3269); 1 Apr 2003 15:21:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86658 invoked from network); 1 Apr 2003 15:21:45 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 1 Apr 2003 15:21:45 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31FLUP27229; Tue, 1 Apr 2003 10:21:31 -0500 (EST) 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 HB8AN292; Tue, 1 Apr 2003 10:21:29 -0500 Received: from nortelnetworks.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 HBX3CGT4; Tue, 1 Apr 2003 10:21:29 -0500 Message-ID: <3E89AF19.2060201@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Deuk-Whee Kwak Cc: msec@securemulticast.org Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents References: <0ECD92AD3DC97C4686C7C172D347FA1A1D67E0@nml.netmedia.kjist.ac.kr> Content-Type: text/plain; charset=x-windows-949 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, 01 Apr 2003 10:24:09 -0500 Content-Transfer-Encoding: 7bit Hi Kwak, I will try to answer some of your questions: Deuk-Whee Kwak wrote: > How are you? > I have been studying on the multicast key management protocols such as GSAKMP, GDOI, and MIKEY > In the document MIKEY, the authors say that MIKEY can be used as a registration protocol in the GKMArch. > But considered GSAKMP, I think I can also use GSAKMP for a registration protocol. > Is it possible? If so, what are the merits and demerits of MIKEY and GSAKMP. If not, why? > > And what is the relation between GSAKMP and GDOI. If GSAKMP can be used as a registration protocol, what are the main purposes of GDOI? Is this used for re-key protocol? > It is also confusing me that there are too many key management-related documents such as GKMP architecture (RFC 2094), GKMP specification (RFC 2093), Scalable Multicast Key Distribution (RFC 1949) and so on > Are there any documents or papers that explain their relation among them? > GSAKMP and GDOI are both complete group key management protocols. Both have the Registration Protocol and the Rekey protocol, and are independent of each other. If you look at the old GSAKMP docs (pre-lite), you will notice that GSAKMP was using a secure tunnel, which could be established using say SSL, to protect group key establishment. GDOI is similar to IKEv1, and comes with all its advantages and of course, the ISAKMP baggage :-). That was one of the main differences. However, GSAKMP-lite or the new GSAKMP does not use a secure tunnel and relies on a DH exchange with signatures. It also relies on an announcement protocol so the GCKS can announce the security mechanisms used by the group beforehand; this reduces the number of round trips. There is a Policy Token payload which differentiates it from the other two protocols. regards, Lakshminath > Best regards, > D. W. Kwak > > > _______________________________________________ > 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 Apr 1 11:28:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26680 for ; Tue, 1 Apr 2003 11:28:15 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8868F537E2; Tue, 1 Apr 2003 11:30:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C4446535A0 for ; Tue, 1 Apr 2003 11:29:09 -0500 (EST) Received: (qmail 98181 invoked by uid 3269); 1 Apr 2003 16:29:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98178 invoked from network); 1 Apr 2003 16:29:09 -0000 Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (193.180.251.47) by klesh.pair.com with SMTP; 1 Apr 2003 16:29:09 -0000 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h31GSkrs009703; Tue, 1 Apr 2003 18:28:46 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2A4KR1ZZ>; Tue, 1 Apr 2003 18:28:46 +0200 Message-ID: <1F55F6582266314A85A55F6241509B670575B2ED@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (EAB)" To: "'Lakshminath Dondeti'" , Deuk-Whee Kwak Cc: msec@securemulticast.org Subject: RE: [MSEC] Questions: Relation among GSAKMP, GDOI and other Docum ents MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: Tue, 1 Apr 2003 18:29:14 +0200 Hi, To begin with, as Lakshminath hinted, today there exist three group key management protocols (in MSEC), but their purpose differs. In fact, it is very hard to create one single protocol that addresses everything from small-scale interactive groups up to large scale multicast groups (that's the basic reason why there exist a few different protocols today). So basically, the main difference between the protocols comes from the scenarios they address and the requirements these scenarios put on them. As Lakshminath also pointed out, the GKMArch will be updated to more clearly clarify the relations between the different protocols (or rather, clearly identify the basic scenarios the different protocols address). I have tried to quickly summarize what I believe is the main characteristics of MIKEY that are different to the other protocols. The main scenarios, which MIKEY has been designed for, comprise conversational multimedia applications, and an environment of heterogeneous nature. One of the main requirements is to reduce the overall latency for the call setup (hence the key management should preferable not introduce extra roundtrips). With this kind of scenario in mind (and the requirements it put), MIKEY was designed so that it could be carried by any session control protocol (e.g. SIP and RTSP), if needed, in order to avoid any extra roundtrips for the security setup. This gave MIKEY the specific property of being a one-roundtrip protocol. Some other characteristics of MIKEY is of course that: it focuses mainly on small- scale interactive groups, and it provides an option to use "pre-shared" keys for the key transport. Best Regards, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 12:32:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02188 for ; Tue, 1 Apr 2003 12:32:32 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3E2FF5381C; Tue, 1 Apr 2003 12:34:28 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E6CF75381C for ; Tue, 1 Apr 2003 12:32:47 -0500 (EST) Received: (qmail 9434 invoked by uid 3269); 1 Apr 2003 17:32:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9429 invoked from network); 1 Apr 2003 17:32:47 -0000 Received: from syd-msg-core-1.cisco.com (64.104.193.198) by klesh.pair.com with SMTP; 1 Apr 2003 17:32:47 -0000 Received: from cisco.com (localhost [127.0.0.1]) by syd-msg-core-1.cisco.com (8.12.2/8.12.6) with SMTP id h31HWeBM010318 for ; Wed, 2 Apr 2003 03:32:41 +1000 (EST) Message-ID: <3E89CD3A.B6FBEFCE@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] TLS vs. multicast 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, 01 Apr 2003 09:32:42 -0800 Content-Transfer-Encoding: 7bit The MSEC Architecture draft has the following statement in section 3.1 "Multicast Data". I've taken out of context for clarity: "... multicast encryption and group authentication are fairly standard and similar to encrypting and authenticating point-to-point communication .... Consequently, off-the-shelf solutions (e.g., taken from IPSec [RFC2406], TLS [RFC2246]) may be sufficient for encryption." I've been told that TLS is inherently unicast, I suppose because of it usually being dependent upon TCP. Is that statement strictly true? If so, then I will strike the reference to TLS from this section, since it is specifically discussing multicast data. Thanks, Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 13:36:46 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07248 for ; Tue, 1 Apr 2003 13:36:45 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8488B53717; Tue, 1 Apr 2003 13:38:38 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9142A53717 for ; Tue, 1 Apr 2003 13:36:18 -0500 (EST) Received: (qmail 20127 invoked by uid 3269); 1 Apr 2003 18:36:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20124 invoked from network); 1 Apr 2003 18:36:16 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 1 Apr 2003 18:36:16 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M5.sparta.com (8.12.8/8.12.5) with ESMTP id h31Ia67m018985; Tue, 1 Apr 2003 12:36:07 -0600 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 h31Ia4Nl030163; Tue, 1 Apr 2003 12:36:05 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA28745; Tue, 1 Apr 2003 13:36:02 -0500 (EST) Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Content-Type: multipart/alternative; boundary=Apple-Mail-18-48011258 Mime-Version: 1.0 (Apple Message framework v551) Cc: Deuk-Whee Kwak , msec@securemulticast.org To: Lakshminath Dondeti From: Hugh Harney In-Reply-To: <3E89AF19.2060201@nortelnetworks.com> Message-Id: X-Mailer: Apple Mail (2.551) 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, 1 Apr 2003 13:36:11 -0500 --Apple-Mail-18-48011258 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, Let me take a shot. GDOI GDOI offers key distribution from a single source to a group. It assumes that the joining members know the identity of the authorized GC/KS. It is a centralized key dissemination architecture. This works well when there is a single well know data source. GDOI contains in it the policy information necessary to set up the IPSec SPD and SAD. GSAKMP (there is only one draft going forward to standards track at this time) GSAKMP provides policy distribution and enforcement. It allows the key dissemination process to be distributed to ensure scalability, via the secure establishment of subordinate GC/KSs. GSAKMP requires that the Group Owner create a policy token that describes the desired security policy for the group. This token is signed by the owner, and all security policy decisions are based on that verifiable token. GSAKMP assumes the members "know" the default GSAKMP group join mechanisms. If any other security suites are defined, they will have to be announced to the group. This allows GSAKMP to support other algorithm types beyond the default. This optional announcement portion of GSAKMP is the only reliance on announcements. GSAKMP itself is self contained. The process GSAKMP uses to bring someone into a group is as follows. GSAKMP assumes the members know nothing except the point of trust, the ID of the Group Owner. The joining member sends a request to join to the GC/KS. The GC/KS reviews the RTJ with respect to the access control security policy as defined in the policy token. If the potential member meets the access control criteria, the GC/KS creates a message that will download key. The joining member reviews the policy token (sent to the member as part of the download message) to determine if the GC/KS is authorized to distribute key for this group. If everything goes well the group member retrieves the key and ACKs the GC/KS The difference between GDOI and GSAKMP lies in the enforcement of security policy and the establishment of subordinate GC/KSs. MIKEY MIKEY was developed for mmusic. I have not looked at it in sufficient detail to offer an opinion. --Apple-Mail-18-48011258 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Let me take a shot. GDOI GDOI offers key distribution from a single source to a group. It assumes that the joining members know the identity of the authorized GC/KS. It is a centralized key dissemination architecture. This works well when there is a single well know data source. GDOI contains in it the policy information necessary to set up the IPSec SPD and SAD. GSAKMP (there is only one draft going forward to standards track at this time) GSAKMP provides policy distribution and enforcement. It allows the key dissemination process to be distributed to ensure scalability, via the secure establishment of subordinate GC/KSs. GSAKMP requires that the Group Owner create a policy token that describes the desired security policy for the group. This token is signed by the owner, and all security policy decisions are based on that verifiable token. GSAKMP assumes the members "know" the default GSAKMP group join mechanisms. If any other security suites are defined, they will have to be announced to the group. This allows GSAKMP to support other algorithm types beyond the default. This optional announcement portion of GSAKMP is the only reliance on announcements. GSAKMP itself is self contained. The process GSAKMP uses to bring someone into a group is as follows. GSAKMP assumes the members know nothing except the point of trust, the ID of the Group Owner. The joining member sends a request to join to the GC/KS. The GC/KS reviews the RTJ with respect to the access control security policy as defined in the policy token. If the potential member meets the access control criteria, the GC/KS creates a message that will download key. The joining member reviews the policy token (sent to the member as part of the download message) to determine if the GC/KS is authorized to distribute key for this group. If everything goes well the group member retrieves the key and ACKs the GC/KS The difference between GDOI and GSAKMP lies in the enforcement of security policy and the establishment of subordinate GC/KSs. MIKEY MIKEY was developed for mmusic. I have not looked at it in sufficient detail to offer an opinion. --Apple-Mail-18-48011258-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 13:48:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07753 for ; Tue, 1 Apr 2003 13:48:09 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 79C765356D; Tue, 1 Apr 2003 13:50:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 439255353E for ; Tue, 1 Apr 2003 13:48:13 -0500 (EST) Received: (qmail 21969 invoked by uid 3269); 1 Apr 2003 18:48:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21966 invoked from network); 1 Apr 2003 18:48:13 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 1 Apr 2003 18:48:13 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31Im0V15349; Tue, 1 Apr 2003 13:48:00 -0500 (EST) 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 HB8ANLSF; Tue, 1 Apr 2003 13:48:00 -0500 Received: from nortelnetworks.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 HBX3CG05; Tue, 1 Apr 2003 13:48:00 -0500 Message-ID: <3E89DF7D.8020401@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugh Harney Cc: Deuk-Whee Kwak , msec@securemulticast.org Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents References: 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: Tue, 01 Apr 2003 13:50:37 -0500 Content-Transfer-Encoding: 7bit Thanks for the summary Hugh! I have a few questions for further clarification. What is the secure data transport protocol for GSAKMP? AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. Let us say for argument sake, we incorporate a) Policy Token into GDOI and b) whatever comes out of the new MSEC charter for distributed operation into GDOI, would we still need GDOI and GSAKMP? Or, is there a reason that functionality cannot be added to GDOI (post RFC)? At that point the only disadvantage of GDOI (IMO) is that is has too many messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). regards, Lakshminath Hugh Harney wrote: > Hi, > > > Let me take a shot. > > > GDOI > > > GDOI offers key distribution from a single source to a group. It assumes > that the joining members know the identity of the authorized GC/KS. It > is a centralized key dissemination architecture. This works well when > there is a single well know data source. > > > GDOI contains in it the policy information necessary to set up the IPSec > SPD and SAD. > > > GSAKMP (there is only one draft going forward to standards track at this > time) > > > GSAKMP provides policy distribution and enforcement. It allows the key > dissemination process to be distributed to ensure scalability, via the > secure establishment of subordinate GC/KSs. GSAKMP requires that the > Group Owner create a policy token that describes the desired security > policy for the group. This token is signed by the owner, and all > security policy decisions are based on that verifiable token. > > > GSAKMP assumes the members "know" the default GSAKMP group join > mechanisms. If any other security suites are defined, they will have to > be announced to the group. This allows GSAKMP to support other algorithm > types beyond the default. This optional announcement portion of GSAKMP > is the only reliance on announcements. GSAKMP itself is self contained. > > > The process GSAKMP uses to bring someone into a group is as follows. > GSAKMP assumes the members know nothing except the point of trust, the > ID of the Group Owner. The joining member sends a request to join to the > GC/KS. The GC/KS reviews the RTJ with respect to the access control > security policy as defined in the policy token. If the potential member > meets the access control criteria, the GC/KS creates a message that will > download key. The joining member reviews the policy token (sent to the > member as part of the download message) to determine if the GC/KS is > authorized to distribute key for this group. If everything goes well the > group member retrieves the key and ACKs the GC/KS > > > The difference between GDOI and GSAKMP lies in the enforcement of > security policy and the establishment of subordinate GC/KSs. > > > MIKEY > > > MIKEY was developed for mmusic. I have not looked at it in sufficient > detail to offer an opinion. > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 14:33:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09689 for ; Tue, 1 Apr 2003 14:33:34 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1089353877; Tue, 1 Apr 2003 14:34:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6DB5853875 for ; Tue, 1 Apr 2003 14:32:32 -0500 (EST) Received: (qmail 29754 invoked by uid 3269); 1 Apr 2003 19:32:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29751 invoked from network); 1 Apr 2003 19:32:32 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by klesh.pair.com with SMTP; 1 Apr 2003 19:32:32 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31JWJ4c025276; Tue, 1 Apr 2003 11:32:20 -0800 (PST) Received: from cscoamera13263.mbaugher.com (sjc-vpn4-649.cisco.com [10.21.82.137]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACV01706; Tue, 1 Apr 2003 11:32:18 -0800 (PST) Message-Id: <5.1.1.5.2.20030401113147.06263078@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Cc: Deuk-Whee Kwak , msec@securemulticast.org In-Reply-To: <3E89AF19.2060201@nortelnetworks.com> References: <0ECD92AD3DC97C4686C7C172D347FA1A1D67E0@nml.netmedia.kjist.ac.kr> 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, 01 Apr 2003 11:32:15 -0800 Hi Lakshminath Thanks for the good summary of GSAKMP and GDOI. Mark At 10:24 AM 4/1/2003 -0500, Lakshminath Dondeti wrote: >Hi Kwak, > >I will try to answer some of your questions: > >Deuk-Whee Kwak wrote: > > How are you? > > I have been studying on the multicast key management protocols such as > GSAKMP, GDOI, and MIKEY > > In the document MIKEY, the authors say that MIKEY can be used as a > registration protocol in the GKMArch. > > But considered GSAKMP, I think I can also use GSAKMP for a registration > protocol. > > Is it possible? If so, what are the merits and demerits of MIKEY and > GSAKMP. If not, why? > > > > And what is the relation between GSAKMP and GDOI. If GSAKMP can be used > as a registration protocol, what are the main purposes of GDOI? Is this > used for re-key protocol? > > It is also confusing me that there are too many key management-related > documents such as GKMP architecture (RFC 2094), GKMP specification (RFC > 2093), Scalable Multicast Key Distribution (RFC 1949) and so on > > Are there any documents or papers that explain their relation among them? > > > >GSAKMP and GDOI are both complete group key management protocols. Both >have the Registration Protocol and the Rekey protocol, and are >independent of each other. > >If you look at the old GSAKMP docs (pre-lite), you will notice that >GSAKMP was using a secure tunnel, which could be established using say >SSL, to protect group key establishment. GDOI is similar to IKEv1, and >comes with all its advantages and of course, the ISAKMP baggage :-). >That was one of the main differences. > >However, GSAKMP-lite or the new GSAKMP does not use a secure tunnel and >relies on a DH exchange with signatures. It also relies on an >announcement protocol so the GCKS can announce the security mechanisms >used by the group beforehand; this reduces the number of round trips. >There is a Policy Token payload which differentiates it from the other >two protocols. > >regards, >Lakshminath > > > > Best regards, > > D. W. Kwak > > > > > > _______________________________________________ > > 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 Apr 1 14:38:19 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10001 for ; Tue, 1 Apr 2003 14:38:18 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EFAF05361C; Tue, 1 Apr 2003 14:40:15 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id ECED053583 for ; Tue, 1 Apr 2003 14:38:17 -0500 (EST) Received: (qmail 30633 invoked by uid 3269); 1 Apr 2003 19:38:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 30630 invoked from network); 1 Apr 2003 19:38:17 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by klesh.pair.com with SMTP; 1 Apr 2003 19:38:17 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31JcF4c008285; Tue, 1 Apr 2003 11:38:15 -0800 (PST) Received: from cscoamera13263.mbaugher.com (sjc-vpn4-649.cisco.com [10.21.82.137]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACV02592; Tue, 1 Apr 2003 11:38:14 -0800 (PST) Message-Id: <5.1.1.5.2.20030401113345.0628e158@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Brian Weis From: Mark Baugher Subject: Re: [MSEC] TLS vs. multicast Cc: msec@securemulticast.org In-Reply-To: <3E89CD3A.B6FBEFCE@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, 01 Apr 2003 11:38:10 -0800 Brian, At 09:32 AM 4/1/2003 -0800, Brian Weis wrote: >The MSEC Architecture draft has the following statement in section 3.1 >"Multicast Data". I've taken out of context for clarity: > > "... multicast encryption and group authentication are fairly > standard and similar to encrypting and authenticating point-to-point > communication .... Consequently, off-the-shelf solutions (e.g., taken > from IPSec [RFC2406], TLS [RFC2246]) may be sufficient for > encryption." Did this come from the original SMuG framework draft? >I've been told that TLS is inherently unicast, I suppose because of it >usually being dependent upon TCP. Is that statement strictly true? Yep, ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt says it runs on a reliable protocol, e.g. TCP in section 1 >If >so, then I will strike the reference to TLS from this section, since it >is specifically discussing multicast data. I still cannot figure out why TLS is in that paragraph, but TLS seems to be wrong in the limited context cited above. thanks, Mark >Thanks, >Brian > >-- >Brian Weis >Strategic Cryptographic Development, ITD, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 15:24:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13436 for ; Tue, 1 Apr 2003 15:24:50 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4D48F53862; Tue, 1 Apr 2003 15:26:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BA3B05366C for ; Tue, 1 Apr 2003 15:25:22 -0500 (EST) Received: (qmail 41218 invoked by uid 3269); 1 Apr 2003 20:25:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41215 invoked from network); 1 Apr 2003 20:25:22 -0000 Received: from lithium.nac.net (64.21.52.83) by klesh.pair.com with SMTP; 1 Apr 2003 20:25:22 -0000 Received: (qmail 60037 invoked from network); 1 Apr 2003 20:25:21 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.173) by mail.nac.net with SMTP; 1 Apr 2003 20:25:21 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h31IaqX23093; Tue, 1 Apr 2003 13:36:52 -0500 From: George Gross To: Lakshminath Dondeti Cc: Hugh Harney , Deuk-Whee Kwak , Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents In-Reply-To: <3E89DF7D.8020401@nortelnetworks.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, 1 Apr 2003 13:36:52 -0500 (EST) Hi, while rev'ing the arch doc's text that contrasts GDOI vs. GSAKMP, I would suggest that mention be made of how GDOI leverages the phase 1 ISAKMP/IKE-v2 security association to secure the GDOI exchanges. The advantage is that the use of ISAKMP/IKE can fit within an Enterprise's existing VPN authentication policies. For example, the ISAKMP/IKE-v2 exchanges may include the EAP authentication of the operator (e.g. an Enterprise remote access scenario). That said, I did have a question about the GDOI GROUPKEY-PULL exchange. See below... br, George On Tue, 1 Apr 2003, Lakshminath Dondeti wrote: > Thanks for the summary Hugh! I have a few questions for further > clarification. What is the secure data transport protocol for GSAKMP? > AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. > > Let us say for argument sake, we incorporate a) Policy Token into GDOI > and b) whatever comes out of the new MSEC charter for distributed > operation into GDOI, would we still need GDOI and GSAKMP? Or, is there > a reason that functionality cannot be added to GDOI (post RFC)? At that > point the only disadvantage of GDOI (IMO) is that is has too many > messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). The GDOI GROUPKEY-PUSH exchange goes through the expense of proving the liveness of the initiator and responder to protect against replay attacks. This incurs an extra message roundtrip exchange and perhaps a D-H computation. I could see the logic of doing this if the ISAKMP phase 1 SA was "stale", i.e. it had not been just created, but it seems as if this GDOI phase 2 exchange could be optimized (skipped?) if you had just finished proving the initiator and respondor's liveness during the phase 1 SA setup. or would that open a vulnerability? As it stands now, to setup a group member join using GDOI, I count: a. 4 ISAKMP/IKE-v2 messages (2 round trips) b. assume 4 messages for the EAP exchange c. 4 messages for the GDOI GROUPKEY-PULL d. N messages for the GDOI GROUPKEY-PUSH, where "N" depends on how many datagram it takes to express the rekey (which I infer may be more than one if using LKH) so the total is 12 + N, right? > regards, > Lakshminath > > Hugh Harney wrote: > > Hi, > > > > > > Let me take a shot. > > > > > > GDOI > > > > > > GDOI offers key distribution from a single source to a group. It assumes > > that the joining members know the identity of the authorized GC/KS. It > > is a centralized key dissemination architecture. This works well when > > there is a single well know data source. > > > > > > GDOI contains in it the policy information necessary to set up the IPSec > > SPD and SAD. > > > > > > GSAKMP (there is only one draft going forward to standards track at this > > time) > > > > > > GSAKMP provides policy distribution and enforcement. It allows the key > > dissemination process to be distributed to ensure scalability, via the > > secure establishment of subordinate GC/KSs. GSAKMP requires that the > > Group Owner create a policy token that describes the desired security > > policy for the group. This token is signed by the owner, and all > > security policy decisions are based on that verifiable token. > > > > > > GSAKMP assumes the members "know" the default GSAKMP group join > > mechanisms. If any other security suites are defined, they will have to > > be announced to the group. This allows GSAKMP to support other algorithm > > types beyond the default. This optional announcement portion of GSAKMP > > is the only reliance on announcements. GSAKMP itself is self contained. > > > > > > The process GSAKMP uses to bring someone into a group is as follows. > > GSAKMP assumes the members know nothing except the point of trust, the > > ID of the Group Owner. The joining member sends a request to join to the > > GC/KS. The GC/KS reviews the RTJ with respect to the access control > > security policy as defined in the policy token. If the potential member > > meets the access control criteria, the GC/KS creates a message that will > > download key. The joining member reviews the policy token (sent to the > > member as part of the download message) to determine if the GC/KS is > > authorized to distribute key for this group. If everything goes well the > > group member retrieves the key and ACKs the GC/KS > > > > > > The difference between GDOI and GSAKMP lies in the enforcement of > > security policy and the establishment of subordinate GC/KSs. > > > > > > MIKEY > > > > > > MIKEY was developed for mmusic. I have not looked at it in sufficient > > detail to offer an opinion. > > > > > > _______________________________________________ > 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 Apr 1 15:36:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14047 for ; Tue, 1 Apr 2003 15:36:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 87A1B5386E; Tue, 1 Apr 2003 15:38:29 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3CE155375E for ; Tue, 1 Apr 2003 15:36:59 -0500 (EST) Received: (qmail 43743 invoked by uid 3269); 1 Apr 2003 20:36:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43740 invoked from network); 1 Apr 2003 20:36:58 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 1 Apr 2003 20:36:58 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M5.sparta.com (8.12.8/8.12.5) with ESMTP id h31Kan7m024711; Tue, 1 Apr 2003 14:36:49 -0600 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 h31KamNl002941; Tue, 1 Apr 2003 14:36:49 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA00781; Tue, 1 Apr 2003 15:36:47 -0500 (EST) Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Deuk-Whee Kwak , msec@securemulticast.org To: Lakshminath Dondeti From: Hugh Harney In-Reply-To: <3E89DF7D.8020401@nortelnetworks.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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, 1 Apr 2003 15:36:56 -0500 Content-Transfer-Encoding: 7bit Lakshminath, GSAKMP provides secure cryptographic groups. It can hand this group key off to any secure data delivery protocol. The MSEC charter states IPSec, so the GSAKMP policy token provides all the policy for IPSec. I would note that GSAKMP could support any group secure data protocol. The policy token is written to be generic enough to provide the policy for any data deliver protocol, also. I also wrote the GSAKMP protocol to allow other protocols to use it - GDOI or MIKEY or any other. So if GDOI wanted to use the policy token it's pretty much ready to roll. The only other difference between GSAKMP and GDOI is the concept GSAKMP has of subordinate GC/KSs. Hugh On Tuesday, Apr 1, 2003, at 13:50 US/Eastern, Lakshminath Dondeti wrote: > Thanks for the summary Hugh! I have a few questions for further > clarification. What is the secure data transport protocol for GSAKMP? > AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. > > Let us say for argument sake, we incorporate a) Policy Token into GDOI > and b) whatever comes out of the new MSEC charter for distributed > operation into GDOI, would we still need GDOI and GSAKMP? Or, is > there a reason that functionality cannot be added to GDOI (post RFC)? > At that point the only disadvantage of GDOI (IMO) is that is has too > many messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). > > regards, > Lakshminath > > Hugh Harney wrote: >> Hi, >> Let me take a shot. >> GDOI >> GDOI offers key distribution from a single source to a group. It >> assumes that the joining members know the identity of the authorized >> GC/KS. It is a centralized key dissemination architecture. This works >> well when there is a single well know data source. >> GDOI contains in it the policy information necessary to set up the >> IPSec SPD and SAD. >> GSAKMP (there is only one draft going forward to standards track at >> this time) >> GSAKMP provides policy distribution and enforcement. It allows the >> key dissemination process to be distributed to ensure scalability, >> via the secure establishment of subordinate GC/KSs. GSAKMP requires >> that the Group Owner create a policy token that describes the desired >> security policy for the group. This token is signed by the owner, and >> all security policy decisions are based on that verifiable token. >> GSAKMP assumes the members "know" the default GSAKMP group join >> mechanisms. If any other security suites are defined, they will have >> to be announced to the group. This allows GSAKMP to support other >> algorithm types beyond the default. This optional announcement >> portion of GSAKMP is the only reliance on announcements. GSAKMP >> itself is self contained. >> The process GSAKMP uses to bring someone into a group is as follows. >> GSAKMP assumes the members know nothing except the point of trust, >> the ID of the Group Owner. The joining member sends a request to join >> to the GC/KS. The GC/KS reviews the RTJ with respect to the access >> control security policy as defined in the policy token. If the >> potential member meets the access control criteria, the GC/KS creates >> a message that will download key. The joining member reviews the >> policy token (sent to the member as part of the download message) to >> determine if the GC/KS is authorized to distribute key for this >> group. If everything goes well the group member retrieves the key and >> ACKs the GC/KS >> The difference between GDOI and GSAKMP lies in the enforcement of >> security policy and the establishment of subordinate GC/KSs. >> MIKEY >> MIKEY was developed for mmusic. I have not looked at it in sufficient >> detail to offer an opinion. > > > > _______________________________________________ > 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 Apr 1 15:52:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14592 for ; Tue, 1 Apr 2003 15:52:41 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D76945387B; Tue, 1 Apr 2003 15:54:37 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 754C353872 for ; Tue, 1 Apr 2003 15:53:06 -0500 (EST) Received: (qmail 46975 invoked by uid 3269); 1 Apr 2003 20:53:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46972 invoked from network); 1 Apr 2003 20:53:06 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by klesh.pair.com with SMTP; 1 Apr 2003 20:53:06 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31KqcOV019162; Tue, 1 Apr 2003 12:52:39 -0800 (PST) Received: from cscoamera13263.mbaugher.com (sjc-vpn4-649.cisco.com [10.21.82.137]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACV11377; Tue, 1 Apr 2003 12:52:37 -0800 (PST) Message-Id: <5.1.1.5.2.20030401124708.04965078@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Cc: Lakshminath Dondeti , Hugh Harney , Deuk-Whee Kwak , In-Reply-To: References: <3E89DF7D.8020401@nortelnetworks.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, 01 Apr 2003 12:52:34 -0800 George, You're right: GDOI has a lot of messages in in it's GROUPKEY-PULL, but no more than IKE v1. The GROUPKEY-PUSH messages are optional an unneeded for the initial establishment of the group key, which is done by the pull. I noticed that you estimate the message cost based on IKE v2. If we defined an GDOI child SA exchange, then I expect we could reduce the message overhead of GDOI considerably. Mark At 01:36 PM 4/1/2003 -0500, George Gross wrote: >Hi, > while rev'ing the arch doc's text that contrasts GDOI vs. GSAKMP, >I would suggest that mention be made of how GDOI leverages the phase 1 >ISAKMP/IKE-v2 security association to secure the GDOI exchanges. The >advantage is that the use of ISAKMP/IKE can fit within an Enterprise's >existing VPN authentication policies. For example, the ISAKMP/IKE-v2 >exchanges may include the EAP authentication of the operator (e.g. an >Enterprise remote access scenario). > > That said, I did have a question about the GDOI GROUPKEY-PULL >exchange. See below... > >br, > George > >On Tue, 1 Apr 2003, Lakshminath Dondeti wrote: > > > Thanks for the summary Hugh! I have a few questions for further > > clarification. What is the secure data transport protocol for GSAKMP? > > AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. > > > > Let us say for argument sake, we incorporate a) Policy Token into GDOI > > and b) whatever comes out of the new MSEC charter for distributed > > operation into GDOI, would we still need GDOI and GSAKMP? Or, is there > > a reason that functionality cannot be added to GDOI (post RFC)? At that > > point the only disadvantage of GDOI (IMO) is that is has too many > > messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). > >The GDOI GROUPKEY-PUSH exchange goes through the expense of proving the >liveness of the initiator and responder to protect against replay attacks. >This incurs an extra message roundtrip exchange and perhaps a D-H >computation. I could see the logic of doing this if the ISAKMP phase 1 SA >was "stale", i.e. it had not been just created, but it seems as if this >GDOI phase 2 exchange could be optimized (skipped?) if you had just >finished proving the initiator and respondor's liveness during the phase 1 >SA setup. or would that open a vulnerability? > >As it stands now, to setup a group member join using GDOI, I count: > >a. 4 ISAKMP/IKE-v2 messages (2 round trips) > >b. assume 4 messages for the EAP exchange > >c. 4 messages for the GDOI GROUPKEY-PULL > >d. N messages for the GDOI GROUPKEY-PUSH, where "N" depends on how many >datagram it takes to express the rekey (which I infer may be more than one >if using LKH) > >so the total is 12 + N, right? > > > regards, > > Lakshminath > > > > Hugh Harney wrote: > > > Hi, > > > > > > > > > Let me take a shot. > > > > > > > > > GDOI > > > > > > > > > GDOI offers key distribution from a single source to a group. It assumes > > > that the joining members know the identity of the authorized GC/KS. It > > > is a centralized key dissemination architecture. This works well when > > > there is a single well know data source. > > > > > > > > > GDOI contains in it the policy information necessary to set up the IPSec > > > SPD and SAD. > > > > > > > > > GSAKMP (there is only one draft going forward to standards track at this > > > time) > > > > > > > > > GSAKMP provides policy distribution and enforcement. It allows the key > > > dissemination process to be distributed to ensure scalability, via the > > > secure establishment of subordinate GC/KSs. GSAKMP requires that the > > > Group Owner create a policy token that describes the desired security > > > policy for the group. This token is signed by the owner, and all > > > security policy decisions are based on that verifiable token. > > > > > > > > > GSAKMP assumes the members "know" the default GSAKMP group join > > > mechanisms. If any other security suites are defined, they will have to > > > be announced to the group. This allows GSAKMP to support other algorithm > > > types beyond the default. This optional announcement portion of GSAKMP > > > is the only reliance on announcements. GSAKMP itself is self contained. > > > > > > > > > The process GSAKMP uses to bring someone into a group is as follows. > > > GSAKMP assumes the members know nothing except the point of trust, the > > > ID of the Group Owner. The joining member sends a request to join to the > > > GC/KS. The GC/KS reviews the RTJ with respect to the access control > > > security policy as defined in the policy token. If the potential member > > > meets the access control criteria, the GC/KS creates a message that will > > > download key. The joining member reviews the policy token (sent to the > > > member as part of the download message) to determine if the GC/KS is > > > authorized to distribute key for this group. If everything goes well the > > > group member retrieves the key and ACKs the GC/KS > > > > > > > > > The difference between GDOI and GSAKMP lies in the enforcement of > > > security policy and the establishment of subordinate GC/KSs. > > > > > > > > > MIKEY > > > > > > > > > MIKEY was developed for mmusic. I have not looked at it in sufficient > > > detail to offer an opinion. > > > > > > > > > > > _______________________________________________ > > 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 Apr 1 16:15:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15440 for ; Tue, 1 Apr 2003 16:15:51 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2427153894; Tue, 1 Apr 2003 16:16:08 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 687F853887 for ; Tue, 1 Apr 2003 16:15:31 -0500 (EST) Received: (qmail 52034 invoked by uid 3269); 1 Apr 2003 21:15:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52031 invoked from network); 1 Apr 2003 21:15:31 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 1 Apr 2003 21:15:31 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31LFRP09657; Tue, 1 Apr 2003 16:15:28 -0500 (EST) 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 HB8ANNLY; Tue, 1 Apr 2003 16:15:26 -0500 Received: from nortelnetworks.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 HBX3CHF3; Tue, 1 Apr 2003 16:15:26 -0500 Message-ID: <3E8A020A.7010702@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Cc: msec@securemulticast.org Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents References: 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: Tue, 01 Apr 2003 16:18:02 -0500 Content-Transfer-Encoding: 7bit George Gross wrote: > Hi, > while rev'ing the arch doc's text that contrasts GDOI vs. GSAKMP, > I would suggest that mention be made of how GDOI leverages the phase 1 > ISAKMP/IKE-v2 security association to secure the GDOI exchanges. The > advantage is that the use of ISAKMP/IKE can fit within an Enterprise's > existing VPN authentication policies. For example, the ISAKMP/IKE-v2 > exchanges may include the EAP authentication of the operator (e.g. an > Enterprise remote access scenario). George, I am not sure about the interaction between GDOI and IKEv2. I agree with the other stuff about EAP etc. Indeed that was the intention behind using ISAKMP/IKEv1 for GDOI design, i.e., we don't have to reinvent NAT traversal, EAP etc. > > That said, I did have a question about the GDOI GROUPKEY-PULL > exchange. See below... > > br, > George > > On Tue, 1 Apr 2003, Lakshminath Dondeti wrote: > > >>Thanks for the summary Hugh! I have a few questions for further >>clarification. What is the secure data transport protocol for GSAKMP? >>AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. >> >>Let us say for argument sake, we incorporate a) Policy Token into GDOI >>and b) whatever comes out of the new MSEC charter for distributed >>operation into GDOI, would we still need GDOI and GSAKMP? Or, is there >>a reason that functionality cannot be added to GDOI (post RFC)? At that >>point the only disadvantage of GDOI (IMO) is that is has too many >>messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). > > > The GDOI GROUPKEY-PUSH exchange goes through the expense of proving the > liveness of the initiator and responder to protect against replay attacks. > This incurs an extra message roundtrip exchange and perhaps a D-H > computation. I could see the logic of doing this if the ISAKMP phase 1 SA > was "stale", i.e. it had not been just created, but it seems as if this > GDOI phase 2 exchange could be optimized (skipped?) if you had just > finished proving the initiator and respondor's liveness during the phase 1 > SA setup. or would that open a vulnerability? > > As it stands now, to setup a group member join using GDOI, I count: > > a. 4 ISAKMP/IKE-v2 messages (2 round trips) I would say 6/3, depending on main/aggressive modes of IKEv1. > > b. assume 4 messages for the EAP exchange > > c. 4 messages for the GDOI GROUPKEY-PULL > > d. N messages for the GDOI GROUPKEY-PUSH, where "N" depends on how many > datagram it takes to express the rekey (which I infer may be more than one > if using LKH) If it is immediate rekeying using LKH, the rekey message might not be very large (see my presentation at the SLC meeting, available at www.securemulticast.org, I think). Thus N may not necessarily be large. > > so the total is 12 + N, right? As Mark suggested in his message, and going even further, a redesign of GDOI along the lines of IKEv2 would reduce the number of messages considerably. regards, Lakshminath > > >>regards, >>Lakshminath >> >>Hugh Harney wrote: >> >>>Hi, >>> >>> >>>Let me take a shot. >>> >>> >>>GDOI >>> >>> >>>GDOI offers key distribution from a single source to a group. It assumes >>>that the joining members know the identity of the authorized GC/KS. It >>>is a centralized key dissemination architecture. This works well when >>>there is a single well know data source. >>> >>> >>>GDOI contains in it the policy information necessary to set up the IPSec >>>SPD and SAD. >>> >>> >>>GSAKMP (there is only one draft going forward to standards track at this >>>time) >>> >>> >>>GSAKMP provides policy distribution and enforcement. It allows the key >>>dissemination process to be distributed to ensure scalability, via the >>>secure establishment of subordinate GC/KSs. GSAKMP requires that the >>>Group Owner create a policy token that describes the desired security >>>policy for the group. This token is signed by the owner, and all >>>security policy decisions are based on that verifiable token. >>> >>> >>>GSAKMP assumes the members "know" the default GSAKMP group join >>>mechanisms. If any other security suites are defined, they will have to >>>be announced to the group. This allows GSAKMP to support other algorithm >>>types beyond the default. This optional announcement portion of GSAKMP >>>is the only reliance on announcements. GSAKMP itself is self contained. >>> >>> >>>The process GSAKMP uses to bring someone into a group is as follows. >>>GSAKMP assumes the members know nothing except the point of trust, the >>>ID of the Group Owner. The joining member sends a request to join to the >>>GC/KS. The GC/KS reviews the RTJ with respect to the access control >>>security policy as defined in the policy token. If the potential member >>>meets the access control criteria, the GC/KS creates a message that will >>>download key. The joining member reviews the policy token (sent to the >>>member as part of the download message) to determine if the GC/KS is >>>authorized to distribute key for this group. If everything goes well the >>>group member retrieves the key and ACKs the GC/KS >>> >>> >>>The difference between GDOI and GSAKMP lies in the enforcement of >>>security policy and the establishment of subordinate GC/KSs. >>> >>> >>>MIKEY >>> >>> >>>MIKEY was developed for mmusic. I have not looked at it in sufficient >>>detail to offer an opinion. >>> >> >> >> >>_______________________________________________ >>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 Apr 1 16:31:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16030 for ; Tue, 1 Apr 2003 16:31:06 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0DFEB536B8; Tue, 1 Apr 2003 16:32:33 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 14A135363E for ; Tue, 1 Apr 2003 16:31:32 -0500 (EST) Received: (qmail 55377 invoked by uid 3269); 1 Apr 2003 21:31:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55372 invoked from network); 1 Apr 2003 21:31:30 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 1 Apr 2003 21:31:30 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31LVIV28496; Tue, 1 Apr 2003 16:31:18 -0500 (EST) 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 HB8ANNR1; Tue, 1 Apr 2003 16:31:17 -0500 Received: from nortelnetworks.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 HBX3CHGP; Tue, 1 Apr 2003 16:31:17 -0500 Message-ID: <3E8A05C2.7060000@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugh Harney Cc: msec@securemulticast.org Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents References: 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: Tue, 01 Apr 2003 16:33:54 -0500 Content-Transfer-Encoding: 7bit Hugh Harney wrote: > Lakshminath, > > GSAKMP provides secure cryptographic groups. It can hand this group key > off to any secure data delivery protocol. The MSEC charter states IPSec, > so the GSAKMP policy token provides all the policy for IPSec. I would > note that GSAKMP could support any group secure data protocol. The > policy token is written to be generic enough to provide the policy for > any data deliver protocol, also. Hugh, Thanks for the explanation. Yes, I recall having this discussion at the meeting now. My understanding at the time was that we would need a shim to translate the Policy Token into an SAD entry. Do you agree? regards, Lakshminath > > I also wrote the GSAKMP protocol to allow other protocols to use it - > GDOI or MIKEY or any other. So if GDOI wanted to use the policy token > it's pretty much ready to roll. > > The only other difference between GSAKMP and GDOI is the concept GSAKMP > has of subordinate GC/KSs. > > > Hugh > > On Tuesday, Apr 1, 2003, at 13:50 US/Eastern, Lakshminath Dondeti wrote: > >> Thanks for the summary Hugh! I have a few questions for further >> clarification. What is the secure data transport protocol for GSAKMP? >> AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. >> >> Let us say for argument sake, we incorporate a) Policy Token into GDOI >> and b) whatever comes out of the new MSEC charter for distributed >> operation into GDOI, would we still need GDOI and GSAKMP? Or, is >> there a reason that functionality cannot be added to GDOI (post RFC)? >> At that point the only disadvantage of GDOI (IMO) is that is has too >> many messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). >> >> regards, >> Lakshminath >> >> Hugh Harney wrote: >> >>> Hi, >>> Let me take a shot. >>> GDOI >>> GDOI offers key distribution from a single source to a group. It >>> assumes that the joining members know the identity of the authorized >>> GC/KS. It is a centralized key dissemination architecture. This works >>> well when there is a single well know data source. >>> GDOI contains in it the policy information necessary to set up the >>> IPSec SPD and SAD. >>> GSAKMP (there is only one draft going forward to standards track at >>> this time) >>> GSAKMP provides policy distribution and enforcement. It allows the >>> key dissemination process to be distributed to ensure scalability, >>> via the secure establishment of subordinate GC/KSs. GSAKMP requires >>> that the Group Owner create a policy token that describes the desired >>> security policy for the group. This token is signed by the owner, and >>> all security policy decisions are based on that verifiable token. >>> GSAKMP assumes the members "know" the default GSAKMP group join >>> mechanisms. If any other security suites are defined, they will have >>> to be announced to the group. This allows GSAKMP to support other >>> algorithm types beyond the default. This optional announcement >>> portion of GSAKMP is the only reliance on announcements. GSAKMP >>> itself is self contained. >>> The process GSAKMP uses to bring someone into a group is as follows. >>> GSAKMP assumes the members know nothing except the point of trust, >>> the ID of the Group Owner. The joining member sends a request to join >>> to the GC/KS. The GC/KS reviews the RTJ with respect to the access >>> control security policy as defined in the policy token. If the >>> potential member meets the access control criteria, the GC/KS creates >>> a message that will download key. The joining member reviews the >>> policy token (sent to the member as part of the download message) to >>> determine if the GC/KS is authorized to distribute key for this >>> group. If everything goes well the group member retrieves the key and >>> ACKs the GC/KS >>> The difference between GDOI and GSAKMP lies in the enforcement of >>> security policy and the establishment of subordinate GC/KSs. >>> MIKEY >>> MIKEY was developed for mmusic. I have not looked at it in sufficient >>> detail to offer an opinion. >> >> >> >> >> _______________________________________________ >> 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 Apr 1 16:36:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16467 for ; Tue, 1 Apr 2003 16:36:33 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9801C5374F; Tue, 1 Apr 2003 16:38:27 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0B1755374F for ; Tue, 1 Apr 2003 16:36:58 -0500 (EST) Received: (qmail 56456 invoked by uid 3269); 1 Apr 2003 21:36:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56453 invoked from network); 1 Apr 2003 21:36:57 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 1 Apr 2003 21:36:57 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31LalP11838; Tue, 1 Apr 2003 16:36:48 -0500 (EST) 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 HB8ANNTB; Tue, 1 Apr 2003 16:36:47 -0500 Received: from nortelnetworks.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 HBX3CHGW; Tue, 1 Apr 2003 16:36:46 -0500 Message-ID: <3E8A070B.1030204@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ran Canetti , thardjono@verisign.com Cc: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] new charter of MSEC 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, 01 Apr 2003 16:39:23 -0500 Content-Transfer-Encoding: 7bit Ran and Thomas, I see that there is no timeline or I-D corresponding to the new charter item, i.e., distributed architectures. Would text on this topic from the GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) I-Ds be a starting point for this? Thanks. regards, Lakshminath "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 mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 18:50:26 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22064 for ; Tue, 1 Apr 2003 18:50:26 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 49A31535A8; Tue, 1 Apr 2003 18:52:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 133FB53549 for ; Tue, 1 Apr 2003 18:51:21 -0500 (EST) Received: (qmail 77666 invoked by uid 3269); 1 Apr 2003 23:51:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77663 invoked from network); 1 Apr 2003 23:51:21 -0000 Received: from lithium.nac.net (64.21.52.83) by klesh.pair.com with SMTP; 1 Apr 2003 23:51:21 -0000 Received: (qmail 23231 invoked from network); 1 Apr 2003 23:50:08 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.173) by mail.nac.net with SMTP; 1 Apr 2003 23:50:08 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h31M1bX23384; Tue, 1 Apr 2003 17:01:37 -0500 From: George Gross To: Mark Baugher Cc: Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents In-Reply-To: <5.1.1.5.2.20030401124708.04965078@agora.rdrop.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, 1 Apr 2003 17:01:37 -0500 (EST) Hi Mark, comments inline below... br, George On Tue, 1 Apr 2003, Mark Baugher wrote: > George, > You're right: GDOI has a lot of messages in in it's GROUPKEY-PULL, but > no more than IKE v1. The GROUPKEY-PUSH messages are optional an unneeded > for the initial establishment of the group key, which is done by the pull. > > I noticed that you estimate the message cost based on IKE v2. If we > defined an GDOI child SA exchange, then I expect we could reduce the > message overhead of GDOI considerably. I think that defining a GDOI child SA exchange would be good thing. It would reduce latency for the most frequent case (join to an existing group) from 8 + N to 6 + N messages, assuming there wasn't an EAP exchange, and that you could skip the GDOI liveness test exchange. so would GDOI signal one of two exchange sequences to allow this optimization? > > Mark > At 01:36 PM 4/1/2003 -0500, George Gross wrote: > >Hi, > > while rev'ing the arch doc's text that contrasts GDOI vs. GSAKMP, > >I would suggest that mention be made of how GDOI leverages the phase 1 > >ISAKMP/IKE-v2 security association to secure the GDOI exchanges. The > >advantage is that the use of ISAKMP/IKE can fit within an Enterprise's > >existing VPN authentication policies. For example, the ISAKMP/IKE-v2 > >exchanges may include the EAP authentication of the operator (e.g. an > >Enterprise remote access scenario). > > > > That said, I did have a question about the GDOI GROUPKEY-PULL > >exchange. See below... > > > >br, > > George > > > >On Tue, 1 Apr 2003, Lakshminath Dondeti wrote: > > > > > Thanks for the summary Hugh! I have a few questions for further > > > clarification. What is the secure data transport protocol for GSAKMP? > > > AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. > > > > > > Let us say for argument sake, we incorporate a) Policy Token into GDOI > > > and b) whatever comes out of the new MSEC charter for distributed > > > operation into GDOI, would we still need GDOI and GSAKMP? Or, is there > > > a reason that functionality cannot be added to GDOI (post RFC)? At that > > > point the only disadvantage of GDOI (IMO) is that is has too many > > > messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). > > > >The GDOI GROUPKEY-PUSH exchange goes through the expense of proving the > >liveness of the initiator and responder to protect against replay attacks. > >This incurs an extra message roundtrip exchange and perhaps a D-H > >computation. I could see the logic of doing this if the ISAKMP phase 1 SA > >was "stale", i.e. it had not been just created, but it seems as if this > >GDOI phase 2 exchange could be optimized (skipped?) if you had just > >finished proving the initiator and respondor's liveness during the phase 1 > >SA setup. or would that open a vulnerability? > > > >As it stands now, to setup a group member join using GDOI, I count: > > > >a. 4 ISAKMP/IKE-v2 messages (2 round trips) > > > >b. assume 4 messages for the EAP exchange > > > >c. 4 messages for the GDOI GROUPKEY-PULL > > > >d. N messages for the GDOI GROUPKEY-PUSH, where "N" depends on how many > >datagram it takes to express the rekey (which I infer may be more than one > >if using LKH) > > > >so the total is 12 + N, right? > > > > > regards, > > > Lakshminath > > > > > > Hugh Harney wrote: > > > > Hi, > > > > > > > > > > > > Let me take a shot. > > > > > > > > > > > > GDOI > > > > > > > > > > > > GDOI offers key distribution from a single source to a group. It assumes > > > > that the joining members know the identity of the authorized GC/KS. It > > > > is a centralized key dissemination architecture. This works well when > > > > there is a single well know data source. > > > > > > > > > > > > GDOI contains in it the policy information necessary to set up the IPSec > > > > SPD and SAD. > > > > > > > > > > > > GSAKMP (there is only one draft going forward to standards track at this > > > > time) > > > > > > > > > > > > GSAKMP provides policy distribution and enforcement. It allows the key > > > > dissemination process to be distributed to ensure scalability, via the > > > > secure establishment of subordinate GC/KSs. GSAKMP requires that the > > > > Group Owner create a policy token that describes the desired security > > > > policy for the group. This token is signed by the owner, and all > > > > security policy decisions are based on that verifiable token. > > > > > > > > > > > > GSAKMP assumes the members "know" the default GSAKMP group join > > > > mechanisms. If any other security suites are defined, they will have to > > > > be announced to the group. This allows GSAKMP to support other algorithm > > > > types beyond the default. This optional announcement portion of GSAKMP > > > > is the only reliance on announcements. GSAKMP itself is self contained. > > > > > > > > > > > > The process GSAKMP uses to bring someone into a group is as follows. > > > > GSAKMP assumes the members know nothing except the point of trust, the > > > > ID of the Group Owner. The joining member sends a request to join to the > > > > GC/KS. The GC/KS reviews the RTJ with respect to the access control > > > > security policy as defined in the policy token. If the potential member > > > > meets the access control criteria, the GC/KS creates a message that will > > > > download key. The joining member reviews the policy token (sent to the > > > > member as part of the download message) to determine if the GC/KS is > > > > authorized to distribute key for this group. If everything goes well the > > > > group member retrieves the key and ACKs the GC/KS > > > > > > > > > > > > The difference between GDOI and GSAKMP lies in the enforcement of > > > > security policy and the establishment of subordinate GC/KSs. > > > > > > > > > > > > MIKEY > > > > > > > > > > > > MIKEY was developed for mmusic. I have not looked at it in sufficient > > > > detail to offer an opinion. > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Apr 1 19:54:55 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23645 for ; Tue, 1 Apr 2003 19:54:55 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 32E39538BD; Tue, 1 Apr 2003 19:56:15 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8F11253654 for ; Tue, 1 Apr 2003 19:54:06 -0500 (EST) Received: (qmail 86835 invoked by uid 3269); 2 Apr 2003 00:54:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86832 invoked from network); 2 Apr 2003 00:54:06 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 2 Apr 2003 00:54:06 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h320s25M015154; Tue, 1 Apr 2003 16:54:03 -0800 (PST) Received: from cscoamera13263.mbaugher.com (sjc-vpn1-40.cisco.com [10.21.96.40]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACV39299; Tue, 1 Apr 2003 16:54:01 -0800 (PST) Message-Id: <5.1.1.5.2.20030401165155.04a83958@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Cc: In-Reply-To: References: <5.1.1.5.2.20030401124708.04965078@agora.rdrop.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, 01 Apr 2003 16:53:59 -0800 George, At 05:01 PM 4/1/2003 -0500, George Gross wrote: >Hi Mark, > > comments inline below... > >br, > George > >On Tue, 1 Apr 2003, Mark Baugher wrote: > > > George, > > You're right: GDOI has a lot of messages in in it's GROUPKEY-PULL, but > > no more than IKE v1. The GROUPKEY-PUSH messages are optional an unneeded > > for the initial establishment of the group key, which is done by the pull. > > > > I noticed that you estimate the message cost based on IKE v2. If we > > defined an GDOI child SA exchange, then I expect we could reduce the > > message overhead of GDOI considerably. > >I think that defining a GDOI child SA exchange would be good thing. It >would reduce latency for the most frequent case (join to an existing >group) from 8 + N to 6 + N messages, assuming there wasn't an EAP >exchange, and that you could skip the GDOI liveness test exchange. Why do you add N? We don't require any pushes. >so would GDOI signal one of two exchange sequences to allow this >optimization? I don't know how IKE does it. I'd look at that first. Mark > > > > Mark > > At 01:36 PM 4/1/2003 -0500, George Gross wrote: > > >Hi, > > > while rev'ing the arch doc's text that contrasts GDOI vs. GSAKMP, > > >I would suggest that mention be made of how GDOI leverages the phase 1 > > >ISAKMP/IKE-v2 security association to secure the GDOI exchanges. The > > >advantage is that the use of ISAKMP/IKE can fit within an Enterprise's > > >existing VPN authentication policies. For example, the ISAKMP/IKE-v2 > > >exchanges may include the EAP authentication of the operator (e.g. an > > >Enterprise remote access scenario). > > > > > > That said, I did have a question about the GDOI GROUPKEY-PULL > > >exchange. See below... > > > > > >br, > > > George > > > > > >On Tue, 1 Apr 2003, Lakshminath Dondeti wrote: > > > > > > > Thanks for the summary Hugh! I have a few questions for further > > > > clarification. What is the secure data transport protocol for GSAKMP? > > > > AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY. > > > > > > > > Let us say for argument sake, we incorporate a) Policy Token into GDOI > > > > and b) whatever comes out of the new MSEC charter for distributed > > > > operation into GDOI, would we still need GDOI and GSAKMP? Or, is there > > > > a reason that functionality cannot be added to GDOI (post RFC)? At > that > > > > point the only disadvantage of GDOI (IMO) is that is has too many > > > > messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ). > > > > > >The GDOI GROUPKEY-PUSH exchange goes through the expense of proving the > > >liveness of the initiator and responder to protect against replay attacks. > > >This incurs an extra message roundtrip exchange and perhaps a D-H > > >computation. I could see the logic of doing this if the ISAKMP phase 1 SA > > >was "stale", i.e. it had not been just created, but it seems as if this > > >GDOI phase 2 exchange could be optimized (skipped?) if you had just > > >finished proving the initiator and respondor's liveness during the phase 1 > > >SA setup. or would that open a vulnerability? > > > > > >As it stands now, to setup a group member join using GDOI, I count: > > > > > >a. 4 ISAKMP/IKE-v2 messages (2 round trips) > > > > > >b. assume 4 messages for the EAP exchange > > > > > >c. 4 messages for the GDOI GROUPKEY-PULL > > > > > >d. N messages for the GDOI GROUPKEY-PUSH, where "N" depends on how many > > >datagram it takes to express the rekey (which I infer may be more than one > > >if using LKH) > > > > > >so the total is 12 + N, right? > > > > > > > regards, > > > > Lakshminath > > > > > > > > Hugh Harney wrote: > > > > > Hi, > > > > > > > > > > > > > > > Let me take a shot. > > > > > > > > > > > > > > > GDOI > > > > > > > > > > > > > > > GDOI offers key distribution from a single source to a group. It > assumes > > > > > that the joining members know the identity of the authorized > GC/KS. It > > > > > is a centralized key dissemination architecture. This works well when > > > > > there is a single well know data source. > > > > > > > > > > > > > > > GDOI contains in it the policy information necessary to set up > the IPSec > > > > > SPD and SAD. > > > > > > > > > > > > > > > GSAKMP (there is only one draft going forward to standards track > at this > > > > > time) > > > > > > > > > > > > > > > GSAKMP provides policy distribution and enforcement. It allows > the key > > > > > dissemination process to be distributed to ensure scalability, > via the > > > > > secure establishment of subordinate GC/KSs. GSAKMP requires that the > > > > > Group Owner create a policy token that describes the desired security > > > > > policy for the group. This token is signed by the owner, and all > > > > > security policy decisions are based on that verifiable token. > > > > > > > > > > > > > > > GSAKMP assumes the members "know" the default GSAKMP group join > > > > > mechanisms. If any other security suites are defined, they will > have to > > > > > be announced to the group. This allows GSAKMP to support other > algorithm > > > > > types beyond the default. This optional announcement portion of > GSAKMP > > > > > is the only reliance on announcements. GSAKMP itself is self > contained. > > > > > > > > > > > > > > > The process GSAKMP uses to bring someone into a group is as follows. > > > > > GSAKMP assumes the members know nothing except the point of > trust, the > > > > > ID of the Group Owner. The joining member sends a request to join > to the > > > > > GC/KS. The GC/KS reviews the RTJ with respect to the access control > > > > > security policy as defined in the policy token. If the potential > member > > > > > meets the access control criteria, the GC/KS creates a message > that will > > > > > download key. The joining member reviews the policy token (sent > to the > > > > > member as part of the download message) to determine if the GC/KS is > > > > > authorized to distribute key for this group. If everything goes > well the > > > > > group member retrieves the key and ACKs the GC/KS > > > > > > > > > > > > > > > The difference between GDOI and GSAKMP lies in the enforcement of > > > > > security policy and the establishment of subordinate GC/KSs. > > > > > > > > > > > > > > > MIKEY > > > > > > > > > > > > > > > MIKEY was developed for mmusic. I have not looked at it in sufficient > > > > > detail to offer an opinion. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Apr 1 20:56:16 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25100 for ; Tue, 1 Apr 2003 20:56:15 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7BF0B537E2; Tue, 1 Apr 2003 20:58:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 33DEB5391C for ; Tue, 1 Apr 2003 20:56:38 -0500 (EST) Received: (qmail 95460 invoked by uid 3269); 2 Apr 2003 01:56:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95457 invoked from network); 2 Apr 2003 01:56:37 -0000 Received: from lithium.nac.net (64.21.52.83) by klesh.pair.com with SMTP; 2 Apr 2003 01:56:37 -0000 Received: (qmail 64935 invoked from network); 2 Apr 2003 01:53:06 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.173) by mail.nac.net with SMTP; 2 Apr 2003 01:53:06 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h3204Xb23495; Tue, 1 Apr 2003 19:04:33 -0500 From: George Gross To: Mark Baugher Cc: Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents In-Reply-To: <5.1.1.5.2.20030401165155.04a83958@agora.rdrop.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, 1 Apr 2003 19:04:33 -0500 (EST) Hi Mark, maybe I misunderstood the conditions that can trigger GROUPKEY-PUSH, see my question below... br, george On Tue, 1 Apr 2003, Mark Baugher wrote: > >I think that defining a GDOI child SA exchange would be good thing. It > >would reduce latency for the most frequent case (join to an existing > >group) from 8 + N to 6 + N messages, assuming there wasn't an EAP > >exchange, and that you could skip the GDOI liveness test exchange. > > Why do you add N? We don't require any pushes. hmmm... when you add a new member to the group, don't you have to re-key to assure backward and forward secrecy? I was assuming you do not unicast the new group key to every registration SA, instead you GROUPKEY-PUSH multicast the new group key. at least that's how I interpreted the draft... _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 1 21:50:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26339 for ; Tue, 1 Apr 2003 21:50:12 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DB30353888; Tue, 1 Apr 2003 21:52:10 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 11F29535A3 for ; Tue, 1 Apr 2003 21:51:06 -0500 (EST) Received: (qmail 10842 invoked by uid 3269); 2 Apr 2003 02:51:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10839 invoked from network); 2 Apr 2003 02:51:05 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by klesh.pair.com with SMTP; 2 Apr 2003 02:51:05 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h322p1OX014720; Tue, 1 Apr 2003 18:51:03 -0800 (PST) Received: from cscoamera13263.mbaugher.com (sjc-vpn1-683.cisco.com [10.21.98.171]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACV49936; Tue, 1 Apr 2003 18:51:00 -0800 (PST) Message-Id: <5.1.1.5.2.20030401184938.04a8d290@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Cc: In-Reply-To: References: <5.1.1.5.2.20030401165155.04a83958@agora.rdrop.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, 01 Apr 2003 18:50:59 -0800 George, At 07:04 PM 4/1/2003 -0500, George Gross wrote: >Hi Mark, > > maybe I misunderstood the conditions that can trigger >GROUPKEY-PUSH, see my question below... > >br, > george > >On Tue, 1 Apr 2003, Mark Baugher wrote: > > > > > >I think that defining a GDOI child SA exchange would be good thing. It > > >would reduce latency for the most frequent case (join to an existing > > >group) from 8 + N to 6 + N messages, assuming there wasn't an EAP > > >exchange, and that you could skip the GDOI liveness test exchange. > > > > Why do you add N? We don't require any pushes. > >hmmm... when you add a new member to the group, don't you have to re-key >to assure backward and forward secrecy? I was assuming you do not unicast >the new group key to every registration SA, instead you GROUPKEY-PUSH >multicast the new group key. at least that's how I interpreted the >draft... This is true when forward and/or backward secrecy is required. I agree. Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Apr 2 12:33:12 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20120 for ; Wed, 2 Apr 2003 12:33:11 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4D07C53839; Wed, 2 Apr 2003 12:34:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3280053750 for ; Wed, 2 Apr 2003 12:32:50 -0500 (EST) Received: (qmail 66509 invoked by uid 3269); 2 Apr 2003 17:32:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66505 invoked from network); 2 Apr 2003 17:32:49 -0000 Received: from syd-msg-core-1.cisco.com (64.104.193.198) by klesh.pair.com with SMTP; 2 Apr 2003 17:32:49 -0000 Received: from cisco.com (localhost [127.0.0.1]) by syd-msg-core-1.cisco.com (8.12.2/8.12.6) with SMTP id h32HWYv5020903; Thu, 3 Apr 2003 03:32:36 +1000 (EST) Message-ID: <3E8B1EB4.94DD2283@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: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] TLS vs. multicast References: <5.1.1.5.2.20030401113345.0628e158@agora.rdrop.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 02 Apr 2003 09:32:36 -0800 Content-Transfer-Encoding: 7bit Hi Mark, Mark Baugher wrote: > > Brian, > > At 09:32 AM 4/1/2003 -0800, Brian Weis wrote: > >The MSEC Architecture draft has the following statement in section 3.1 > >"Multicast Data". I've taken out of context for clarity: > > > > "... multicast encryption and group authentication are fairly > > standard and similar to encrypting and authenticating point-to-point > > communication .... Consequently, off-the-shelf solutions (e.g., taken > > from IPSec [RFC2406], TLS [RFC2246]) may be sufficient for > > encryption." > > Did this come from the original SMuG framework draft? Yes. > >I've been told that TLS is inherently unicast, I suppose because of it > >usually being dependent upon TCP. Is that statement strictly true? > > Yep, ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt says it runs on a > reliable protocol, e.g. TCP in section 1 > > >If > >so, then I will strike the reference to TLS from this section, since it > >is specifically discussing multicast data. > > I still cannot figure out why TLS is in that paragraph, but TLS seems to be > wrong in the limited context cited above. Thanks ... I'll remove the reference. Brian > thanks, Mark > > >Thanks, > >Brian > > > >-- > >Brian Weis > >Strategic Cryptographic Development, ITD, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Apr 3 12:32:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02529 for ; Thu, 3 Apr 2003 12:32:38 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4270353A01; Thu, 3 Apr 2003 12:30:21 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7EF6F539FF for ; Thu, 3 Apr 2003 12:29:05 -0500 (EST) Received: (qmail 26125 invoked by uid 3269); 3 Apr 2003 17:29:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26118 invoked from network); 3 Apr 2003 17:29:05 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 3 Apr 2003 17:29:05 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M5.sparta.com (8.12.8/8.12.5) with ESMTP id h33HQ37m025143; Thu, 3 Apr 2003 11:26:03 -0600 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 h33HQ2Nl022717; Thu, 3 Apr 2003 11:26:02 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA06398; Thu, 3 Apr 2003 12:25:59 -0500 (EST) Subject: Re: [MSEC] new charter of MSEC Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ran Canetti , thardjono@verisign.com, msec@securemulticast.org To: Lakshminath Dondeti From: Hugh Harney In-Reply-To: <3E8A070B.1030204@nortelnetworks.com> Message-Id: <5D4226B8-65F9-11D7-B0AC-000393DAD548@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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, 3 Apr 2003 12:26:11 -0500 Content-Transfer-Encoding: 7bit Lakshminath, Well GSAKMP does support distributed architectures. The GKMP architecture RFC discusses this also RFC 2093 Hugh On Tuesday, Apr 1, 2003, at 16:39 US/Eastern, Lakshminath Dondeti wrote: > Ran and Thomas, > > I see that there is no timeline or I-D corresponding to the new > charter item, i.e., distributed architectures. Would text on this > topic from the GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) > I-Ds be a starting point for this? > > Thanks. > > regards, > Lakshminath > > "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 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 Thu Apr 3 12:32:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02532 for ; Thu, 3 Apr 2003 12:32:39 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 46448539B2; Thu, 3 Apr 2003 12:28:27 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 93F1D539F7 for ; Thu, 3 Apr 2003 12:27:30 -0500 (EST) Received: (qmail 25876 invoked by uid 3269); 3 Apr 2003 17:27:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25873 invoked from network); 3 Apr 2003 17:27:29 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 3 Apr 2003 17:27:29 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M5.sparta.com (8.12.8/8.12.5) with ESMTP id h33HOT7m025059; Thu, 3 Apr 2003 11:24:29 -0600 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 h33HOSNl022658; Thu, 3 Apr 2003 11:24:28 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA06385; Thu, 3 Apr 2003 12:24:26 -0500 (EST) Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: msec@securemulticast.org To: Lakshminath Dondeti From: Hugh Harney In-Reply-To: <3E8A05C2.7060000@nortelnetworks.com> Message-Id: <25C0BBA6-65F9-11D7-B0AC-000393DAD548@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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, 3 Apr 2003 12:24:38 -0500 Content-Transfer-Encoding: 7bit Lakshminath, > Hugh Harney wrote: >> Lakshminath, >> GSAKMP provides secure cryptographic groups. It can hand this group >> key off to any secure data delivery protocol. The MSEC charter states >> IPSec, so the GSAKMP policy token provides all the policy for IPSec. >> I would note that GSAKMP could support any group secure data >> protocol. The policy token is written to be generic enough to provide >> the policy for any data deliver protocol, also. > > Hugh, > > Thanks for the explanation. Yes, I recall having this discussion at > the meeting now. My understanding at the time was that we would need > a shim to translate the Policy Token into an SAD entry. Do you agree? Well, most the the shim exists in the form on PF_Key _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Apr 3 15:34:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12563 for ; Thu, 3 Apr 2003 15:34:43 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C6A3153992; Thu, 3 Apr 2003 15:26:25 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 779D453985 for ; Thu, 3 Apr 2003 15:25:10 -0500 (EST) Received: (qmail 58420 invoked by uid 3269); 3 Apr 2003 20:25:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58413 invoked from network); 3 Apr 2003 20:25:09 -0000 Received: from smtp014.mail.yahoo.com (216.136.173.58) by klesh.pair.com with SMTP; 3 Apr 2003 20:25:09 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Apr 2003 20:25:08 -0000 Message-Id: <5.0.0.25.2.20030403151033.0306f230@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Lakshminath Dondeti , Ran Canetti From: Thomas Hardjono Subject: Re: [MSEC] new charter of MSEC Cc: msec@securemulticast.org In-Reply-To: <3E8A070B.1030204@nortelnetworks.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, 03 Apr 2003 15:25:06 -0500 I think the intention was to open-up the working group to ideas/protocols regarding how to manage multiple GCKSs. I think the Policy-Token work from GSAKMP is definitely a starting point. Perhaps a reasonable target would be to have a separate draft that would provide applicability of the token (or some authorization method) for all of the key management protocols. Also, though the token provides authorization, there is still the open questions of how one GCKS communicates securely with other GCKSs. For example, do we use point-to-point or a separate group (e.g. like the All-KDs-group) for GCKSs only. Perhaps this maybe a protocol-specific question. I think there is a lot within GSAKMP that can be "unearthed", since there has been a lot of thinking behind GSAKMP that hasn't made it into the text of the GSAKMP-drafts. thomas ------ At 4/1/2003||04:39 PM, Lakshminath Dondeti wrote: >Ran and Thomas, > >I see that there is no timeline or I-D corresponding to the new charter >item, i.e., distributed architectures. Would text on this topic from the >GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) I-Ds be a starting >point for this? > >Thanks. > >regards, >Lakshminath > >"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 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 Apr 3 15:44:18 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12839 for ; Thu, 3 Apr 2003 15:44:17 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A5F153569; Thu, 3 Apr 2003 15:46:09 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 44ECA537E7 for ; Thu, 3 Apr 2003 15:45:26 -0500 (EST) Received: (qmail 62661 invoked by uid 3269); 3 Apr 2003 20:45:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62658 invoked from network); 3 Apr 2003 20:45:25 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 3 Apr 2003 20:45:25 -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 h33Kj0V04807; Thu, 3 Apr 2003 15:45:00 -0500 (EST) 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 HB8AN020; Thu, 3 Apr 2003 15:44:59 -0500 Received: from nortelnetworks.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 HBX3CJ32; Thu, 3 Apr 2003 15:44:59 -0500 Message-ID: <3E8C9DE7.4000003@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Hardjono , Hugh Harney Cc: Ran Canetti , msec@securemulticast.org Subject: Re: [MSEC] new charter of MSEC References: <5.0.0.25.2.20030403151033.0306f230@pop.mail.yahoo.com> 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: Thu, 03 Apr 2003 15:47:35 -0500 Content-Transfer-Encoding: 7bit I am still trying to put GSAKMP's policy token and the subordinate GCKS functionalities in context with respect to the other protocols, viz., GDOI and MIKEY. As Hugh noted, the policy token can be used by the other protocols. How about the subordinate GCKS functionality? What are the dependencies in making that to work in GDOI, say? If we can extract those pieces into a document, that would be a great starting point for some of the new charter items (the many-to-many piece still remains). If that can be done, it is conceivable to write a GDOIbis (or call it GDOI-GSAKMP or GKDP or whatever) spec, that is lightweight (say, based on IKEv2), supports (optional?) policy token, and optional distributed operation. While that may be a long way away, would we still need both GSAKMP and GDOI then? regards, Lakshminath PS: This may be a replay of some old discussions, but this time around we will include a summary of the discussion in the GKMarch I-D. Thomas Hardjono wrote: > > I think the intention was to open-up the working group to > ideas/protocols regarding how to manage multiple GCKSs. > > I think the Policy-Token work from GSAKMP is definitely a starting > point. Perhaps a reasonable target would be to have a separate draft > that would provide applicability of the token (or some authorization > method) for all of the key management protocols. > > Also, though the token provides authorization, there is still the open > questions of how one GCKS communicates securely with other GCKSs. For > example, do we use point-to-point or a separate group (e.g. like the > All-KDs-group) for GCKSs only. Perhaps this maybe a protocol-specific > question. > > I think there is a lot within GSAKMP that can be "unearthed", since > there has been a lot of thinking behind GSAKMP that hasn't made it into > the text of the GSAKMP-drafts. > > thomas > ------ > > > > At 4/1/2003||04:39 PM, Lakshminath Dondeti wrote: > >> Ran and Thomas, >> >> I see that there is no timeline or I-D corresponding to the new >> charter item, i.e., distributed architectures. Would text on this >> topic from the GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) >> I-Ds be a starting point for this? >> >> Thanks. >> >> regards, >> Lakshminath >> >> "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 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 Apr 3 16:04:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13704 for ; Thu, 3 Apr 2003 16:04:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9E9CA5398E; Thu, 3 Apr 2003 16:05:18 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8434753575 for ; Thu, 3 Apr 2003 16:03:46 -0500 (EST) Received: (qmail 66188 invoked by uid 3269); 3 Apr 2003 21:03:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66185 invoked from network); 3 Apr 2003 21:03:46 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 3 Apr 2003 21:03:46 -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 h33L3UV10901; Thu, 3 Apr 2003 16:03:31 -0500 (EST) 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 HB8AN0QT; Thu, 3 Apr 2003 16:03:30 -0500 Received: from nortelnetworks.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 HBX3CJPF; Thu, 3 Apr 2003 16:03:30 -0500 Message-ID: <3E8CA23D.30602@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Hardjono Cc: Ran Canetti , msec@securemulticast.org Subject: Re: [MSEC] new charter of MSEC References: <5.0.0.25.2.20030403151033.0306f230@pop.mail.yahoo.com> 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: Thu, 03 Apr 2003 16:06:05 -0500 Content-Transfer-Encoding: 7bit Thomas Hardjono wrote: > > I think the intention was to open-up the working group to > ideas/protocols regarding how to manage multiple GCKSs. Along these lines, would it be fair to separate the following two models of multiple GCKSs in addressing this topic; a) multiple GCKSs for scalability and availability of the GCKS services b) hierarchical subgrouping and designation of a root GCKS and different levels of subordinated GCKSs. The first probably is simpler compared to the second model. regards, Lakshminath > > I think the Policy-Token work from GSAKMP is definitely a starting > point. Perhaps a reasonable target would be to have a separate draft > that would provide applicability of the token (or some authorization > method) for all of the key management protocols. > > Also, though the token provides authorization, there is still the open > questions of how one GCKS communicates securely with other GCKSs. For > example, do we use point-to-point or a separate group (e.g. like the > All-KDs-group) for GCKSs only. Perhaps this maybe a protocol-specific > question. > > I think there is a lot within GSAKMP that can be "unearthed", since > there has been a lot of thinking behind GSAKMP that hasn't made it into > the text of the GSAKMP-drafts. > > thomas > ------ > > > > At 4/1/2003||04:39 PM, Lakshminath Dondeti wrote: > >> Ran and Thomas, >> >> I see that there is no timeline or I-D corresponding to the new >> charter item, i.e., distributed architectures. Would text on this >> topic from the GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) >> I-Ds be a starting point for this? >> >> Thanks. >> >> regards, >> Lakshminath >> >> "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 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 Apr 3 17:58:12 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18038 for ; Thu, 3 Apr 2003 17:58:12 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 78C6353558; Thu, 3 Apr 2003 18:00:09 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 48E3353557 for ; Thu, 3 Apr 2003 17:59:52 -0500 (EST) Received: (qmail 86584 invoked by uid 3269); 3 Apr 2003 22:59:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86580 invoked from network); 3 Apr 2003 22:59:52 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by klesh.pair.com with SMTP; 3 Apr 2003 22:59:52 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h33Mxh8O026357; Thu, 3 Apr 2003 14:59:44 -0800 (PST) Received: from cscoamera13263.mbaugher.com (sjc-vpn4-93.cisco.com [10.21.80.93]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACX35062; Thu, 3 Apr 2003 14:59:42 -0800 (PST) Message-Id: <5.1.1.5.2.20030403145738.08dc20a8@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] new charter of MSEC Cc: Thomas Hardjono , Hugh Harney , Ran Canetti , msec@securemulticast.org In-Reply-To: <3E8C9DE7.4000003@nortelnetworks.com> References: <5.0.0.25.2.20030403151033.0306f230@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: Thu, 03 Apr 2003 14:59:40 -0800 At 03:47 PM 4/3/2003 -0500, Lakshminath Dondeti wrote: >I am still trying to put GSAKMP's policy token and the subordinate GCKS >functionalities in context with respect to the other protocols, viz., GDOI >and MIKEY. As Hugh noted, the policy token can be used by the other protocols. > >How about the subordinate GCKS functionality? What are the dependencies >in making that to work in GDOI, say? If we can extract those pieces into >a document, that would be a great starting point for some of the new >charter items (the many-to-many piece still remains). > >If that can be done, it is conceivable to write a GDOIbis (or call it >GDOI-GSAKMP or GKDP or whatever) spec, that is lightweight (say, based on >IKEv2), supports (optional?) policy token, and optional distributed >operation. While that may be a long way away, would we still need both >GSAKMP and GDOI then? I expect both will be around. I think that we will want a GDOIbis that is optimized to use IKEv2 child SA functionality. We can consider distributed GDOI GCKS mechanisms at that time as well. cheers, Mark >regards, >Lakshminath > >PS: This may be a replay of some old discussions, but this time around we >will include a summary of the discussion in the GKMarch I-D. > >Thomas Hardjono wrote: >>I think the intention was to open-up the working group to ideas/protocols >>regarding how to manage multiple GCKSs. >>I think the Policy-Token work from GSAKMP is definitely a starting >>point. Perhaps a reasonable target would be to have a separate draft >>that would provide applicability of the token (or some authorization >>method) for all of the key management protocols. >>Also, though the token provides authorization, there is still the open >>questions of how one GCKS communicates securely with other GCKSs. For >>example, do we use point-to-point or a separate group (e.g. like the >>All-KDs-group) for GCKSs only. Perhaps this maybe a protocol-specific >>question. >>I think there is a lot within GSAKMP that can be "unearthed", since there >>has been a lot of thinking behind GSAKMP that hasn't made it into the >>text of the GSAKMP-drafts. >>thomas >>------ >> >>At 4/1/2003||04:39 PM, Lakshminath Dondeti wrote: >> >>>Ran and Thomas, >>> >>>I see that there is no timeline or I-D corresponding to the new charter >>>item, i.e., distributed architectures. Would text on this topic from >>>the GSAKMP-Experimental or GSAKMP-Standards_Track ( :-) ) I-Ds be a >>>starting point for this? >>> >>>Thanks. >>> >>>regards, >>>Lakshminath >>> >>>"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 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 Sun Apr 6 15:30:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04586 for ; Sun, 6 Apr 2003 15:30:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DF08253577; Sun, 6 Apr 2003 15:32: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 29F385356D for ; Sun, 6 Apr 2003 15:31:54 -0400 (EDT) Received: (qmail 85792 invoked by uid 3269); 6 Apr 2003 19:31:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85787 invoked from network); 6 Apr 2003 19:31:53 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 6 Apr 2003 19:31:53 -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 h36JVnQ185050; Sun, 6 Apr 2003 15:31:49 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h36JVnl93246; Sun, 6 Apr 2003 15:31:49 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id PAA28236; Sun, 6 Apr 2003 15:31:48 -0400 From: Ran Canetti Message-Id: <200304061931.PAA28236@ornavella.watson.ibm.com> To: gmgross@nac.net, ldondeti@nortelnetworks.com Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Cc: msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 6 Apr 2003 15:31:48 -0400 A belated remark on this thread: As the GDOI document says, there is nothing in GDOI that ties it exclusively to IKEv1. Indeed, once IKEv2 is stable, it should be quite straightforward to write a "GDOIv2" document which describes how GDOI can make use of IKEv2. Potentially, the GDOI phase 2 can be piggybacked on the last two messagges of phase 1 (as is done in IKEv2); this would reduce the round complexity of "GDOIv2" to the round complexity of IKEv2, which is 4/6 messages, depending on whether dos protection is on. Hopefully we can find a volunteer with enough energy to write this up. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Apr 6 20:14:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10140 for ; Sun, 6 Apr 2003 20:14:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CEECA535E3; Sun, 6 Apr 2003 20:15: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 C78C3535E3 for ; Sun, 6 Apr 2003 20:13:51 -0400 (EDT) Received: (qmail 21124 invoked by uid 3269); 7 Apr 2003 00:13:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21121 invoked from network); 7 Apr 2003 00:13:51 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 7 Apr 2003 00:13:51 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h370DhY17667; Sun, 6 Apr 2003 19:13:44 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2J0VQZ2X; Sun, 6 Apr 2003 17:13:44 -0700 Received: from nortelnetworks.com (acart40u.ca.nortel.com [47.129.49.131]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2J0P05LZ; Sun, 6 Apr 2003 20:13:41 -0400 Message-ID: <3E90C36E.1070900@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ran Canetti Cc: gmgross@nac.net, msec@securemulticast.org Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents References: <200304061931.PAA28236@ornavella.watson.ibm.com> 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: Sun, 06 Apr 2003 20:16:46 -0400 Content-Transfer-Encoding: 7bit I agree with you Ran. I also think that we should follow IKEv2's model and piggyback the GDOI Child SAs (Rekey and Data Security SAs) on to the last two messages of an IKEv2 exchange. And, I am sure we can find a volunteer to write GDOIv2 :-). regards, Lakshminath Ran Canetti wrote: > A belated remark on this thread: As the GDOI document says, there is nothing > in GDOI that ties it exclusively to IKEv1. Indeed, once IKEv2 is stable, > it should be quite straightforward to write a "GDOIv2" document which describes > how GDOI can make use of IKEv2. Potentially, the GDOI phase 2 can be piggybacked > on the last two messagges of phase 1 (as is done in IKEv2); this would > reduce the round complexity of "GDOIv2" to the round complexity of IKEv2, > which is 4/6 messages, depending on whether dos protection is on. > > Hopefully we can find a volunteer with enough energy to write this up. > > Ran > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Apr 6 22:56:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12517 for ; Sun, 6 Apr 2003 22:56:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CBF8F53574; Sun, 6 Apr 2003 22: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 D8B1C53565 for ; Sun, 6 Apr 2003 22:56:12 -0400 (EDT) Received: (qmail 45091 invoked by uid 3269); 7 Apr 2003 02:56:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45088 invoked from network); 7 Apr 2003 02:56:12 -0000 Received: from oe42.law11.hotmail.com (HELO hotmail.com) (64.4.16.100) by klesh.pair.com with SMTP; 7 Apr 2003 02:56:12 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 6 Apr 2003 19:56:12 -0700 Received: from 172.159.63.213 by oe42.law11.hotmail.com with DAV; Mon, 07 Apr 2003 02:56:11 +0000 X-Originating-IP: [172.159.63.213] X-Originating-Email: [isalekul@hotmail.com] From: "Salekul Islam" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C2FC90.2750EBA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 07 Apr 2003 02:56:12.0092 (UTC) FILETIME=[3F4877C0:01C2FCB1] Subject: [MSEC] Question Related to PIM-SM Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 6 Apr 2003 22:59:18 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C2FC90.2750EBA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I need some clarification related to PIM-SM security. In PIM-SM we have = link-local messages that are sent to ALL_PIM_ROUTERS. In security = section of PIM-SM spec it is receommended that one SA should be used to = protect all the link-local messages. In that spec nothing is mentioned = about how to protect multicast data. As far my understanding we need = another SA among the sender(s) and receiver(s) to protect mulicast data. = When a sender sends data to multicast group it will use the later SA and = only the receivers will be able to decrypt the data (not the = intermediate routers). Intermediate routers will only bypass these data = packets. Is my understanding clear? Or I am missing some points? I asked the same quetion to PIM WG but they have referred me to ask it = here. I am expecting someone's response. Salekul=20 ------=_NextPart_000_001F_01C2FC90.2750EBA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I need some clarification related to PIM-SM security. In = PIM-SM=20 we have link-local messages that are sent to ALL_PIM_ROUTERS. In = security=20 section of PIM-SM spec it is receommended that one SA should be used to = protect=20 all the link-local messages. In that spec nothing is mentioned = about how to=20 protect multicast data. As far my understanding we need another SA among = the=20 sender(s) and receiver(s) to protect mulicast data. When a sender = sends=20 data to multicast group it will use the later SA and only the = receivers=20 will be able to decrypt the data (not the intermediate routers). = Intermediate=20 routers will only bypass these data packets. Is my understanding clear? = Or I am=20 missing some points?
 
I asked the same quetion to PIM WG but they have referred me to ask = it=20 here. I am expecting someone's response.
 
Salekul 
------=_NextPart_000_001F_01C2FC90.2750EBA0-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 7 08:41:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18601 for ; Mon, 7 Apr 2003 08:41:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BF78053600; Mon, 7 Apr 2003 08:43: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 DA1BA53552 for ; Mon, 7 Apr 2003 08:26:01 -0400 (EDT) Received: (qmail 51875 invoked by uid 3269); 7 Apr 2003 12:26:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51872 invoked from network); 7 Apr 2003 12:26:01 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 7 Apr 2003 12:26:01 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M5.sparta.com (8.12.8/8.12.5) with ESMTP id h37CQ17m014980; Mon, 7 Apr 2003 07:26:01 -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 h37CQ0Nl022621; Mon, 7 Apr 2003 07:26:00 -0500 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id IAA23426; Mon, 7 Apr 2003 08:25:58 -0400 (EDT) Subject: Re: [MSEC] Comments on GSAKMP lite Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: msec@securemulticast.org To: Ran Canetti From: Hugh Harney In-Reply-To: <200303210332.WAA35190@ornavella.watson.ibm.com> Message-Id: <15B54229-68F4-11D7-B840-000393DAD548@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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, 7 Apr 2003 08:25:57 -0400 Content-Transfer-Encoding: 7bit Ran, I've been thinking about our discussions at the IETF for a week or two. You made two suggestions - use cookies a la IKEv2 to prevent some DOS attacks and replace the signature on the GSAKMP ACK message with a signed MAC. I believe that cookies must be added to the GSAKMP spec and that will happen. However, I've been thinking about changing the authentication on the ACK message from a signature to a keyed MAC as you suggested. We would get some efficiencies in protocol processing, however we would be loosing the non-reputation characteristic of the signed ACK. I think the signed ACK would give a subordinate GC/KS a non-reputable proof of key delivery that could be handed off to the master GC/KS. In a group scenario this would help manage the group. A GC/KS could store this signed ACK as proof of authorization to charge or to verify that an Sub GC/KS is acting properly. I believe the non-reputability property is only important in a group scenario. In peer SAs both sides have direct proof of the connection and SA creation. In peer SAs it makes perfect sense to switch to a keyed MAC for processing efficiencies. I don't think the same thing can be said in the Group paradigm. Thanks Hugh On Thursday, Mar 20, 2003, at 22:32 US/Eastern, Ran Canetti wrote: > > Folks, > > I enclose a summary of a discussion I had with Hugh and Andrea in SFO > where I raised some issues regarding the GSAKMP-lite document. In > general, > I felt that the protocol is good (modulo the points below) and the > document > is well written. However, the points below seem to require addressing. > > Best, > > Ran > > > > * One editorial point was the lack of a "Security considerations" > section. > Beyond being a formal requirement, such a section is a great place to > discuss many security issues relating to GSAKMP. (some examples can be > extracted from the remarks below.) > > * DOS resilience: In the current protocol, the first message (coming > from > the joining member) contains a Diffie-Hellman exponent. the GCKS needs > to compute the DH secret before sending the response message. This > requires > a modular exponentiation - which is a costly operation. Thus, a naive > implementation of a GCKS is highly susceptible to DOS attack that > floods > the GCKS with bogus DH exponents and causes the GCKS to do a costly > exponentiation in response to each one. Andrea pointed out that if the > GCKS > has a list of "acceptable group members" then the GCKS could > reject bogus join requests without doing the exponentiation. > But such lists are not always available, and furthermore verifying > that a > join request really comes from an acceptable member involves verifying > certificates, which is costly by itself. > > Therefore I think it would be a very good idea to add an anti-DOS > mechanism > to the protocol. One such mechanism, that is currently used in IKEv2, > is to > add a optional cookie exchange between message 1 and 2. the exchange > will be > turned on by the GCKS whenever it feels it is under DOS attack. > > * Currently the third message (the ACK message sent by the member) is > digitally signed by the member. Instead of signing, it is enough to > MAC this > message using a key derived from the agreed DH key. This will save an > unnecessary and costly signature generation and verification. > (Derivation of an additional MAC key is easy - just extend the > derivation > of the encryption key (used in message 2) to derive also a MAC key.) > > * Recall the attack that Cathy Meadows found against a prior version of > GDOI: It was possible to use a signature generated by the GCKS in the > registration protocol to spoof a rekey message (and vice versa). The > solution in GDOI was to add reserved values to the signed texts that > make it clear in which context a signature is generated. > A similar mechanism should be done explicitly in GSAKMP, to avoid > similar > attacks. Apparently there are currently such values in the GSAKMP > message > headers; but these should be made explicit and it should be made sure > that > the values are actually signed. > > * Another concern was to add the identity of the GCKS to the signed > text > in the join request. This may mitigate the damage caused by a rogoue > GCKS in > a distributed architecture. Hugh pointed out that there may be > interoperabiltiy advantages in NOT doing that. I'm interested to hear > what > other people have to say about this traddeoff. In any case, the issue > should > probably be discussed in the security considerations section. > > * Regarding the order of encyption and signature in the key download > message: It wasnt clear to me whther the intention was first to > encrypt the > polcy token and key download payloads, and then sign the ciphertexts > (along > with the other fields to be signed), or alternatively to encrypt the > signature. I strongly vote for the first method - since the second > method > does not guarantee the secrecy of the data. (See for instance the > attack > in [K01].) > > * The current draft specifies "minimum fields to be included un der the > signature" in the three messages. For sake of unambiguity, it would be > better to specify these fields deterministically - without allowing > for potentially additional signed fields. > > * Some additional work needs to be done in order to make GSAKMP > compatible > with TESLA. The main issue is to augment GSAKMP so that it will be > possible to > piggyback a time synchronization exchange on the GSAKMP messages. I > will not > get into more details here; this should probably be done in cooperation > with the authors of the TESLA drafts. > > * I think it will be a very good idea to discuss in the security > considerations > section why the protocol may be secure. This is especially in place > since > the current version is doing things from scratch, and does not use > off-the-shelf (and hopefully analyzed) key exchange protocols. > > Here is my 2c towars this goal. The basic exchange in the registration > protocol > can be regarded as a variant of the ISO 9798-3 protocol, which is > sketched > below. The policy token and the group keys are then encrypted using a > key > derived from the agreed DH secret. The ISO 9798-3 protocol was > analyzed in > [CK01]. > > The ISO 9798-3 protocol: > > A->B: A,N_a,g^a > B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,B,A) > A->B: SIG_a(N_a,N_b,g^a,g^b,A,B) > > A salient point about this protocol is that each party signs, in > addition to the nonces and the two public DH exponents, also the > identity of the peer. (If the peer's identity is not signed then > the protocol is completely broken.) In the context of GSAKMP the > identity of "B" is the group ID. > > [Note though that this relates only to a small part of the GSAKMP > protocol. > Full analysis should include the entire protocol, including the rekey > messages and group evolution over time.] > > > > [CK01] Canetti and Krawczyk, "Analysis of Key-Exchange Protocols > and Their Use for Building Secure Channels", Eurocrypt 01. > Available at http://eprint.iacr.org/2001/040. > > > [K01] H. Krawczyk, "On the order of encryption and > authentication, or > how secure is SSL", Crypto 01. > > > > > > _______________________________________________ > 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 Mon Apr 7 12:16:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25189 for ; Mon, 7 Apr 2003 12:16:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 99F505364F; Mon, 7 Apr 2003 12:18: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 5ED0D5363E for ; Mon, 7 Apr 2003 12:16:02 -0400 (EDT) Received: (qmail 88359 invoked by uid 3269); 7 Apr 2003 16:16:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88356 invoked from network); 7 Apr 2003 16:16:02 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by klesh.pair.com with SMTP; 7 Apr 2003 16:16:02 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h37GFwph002486; Mon, 7 Apr 2003 09:15:58 -0700 (PDT) Received: from cscoamera13263.mbaugher.com (rtp-vpn2-375.cisco.com [10.82.241.119]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACZ40591; Mon, 7 Apr 2003 09:15:56 -0700 (PDT) Message-Id: <5.1.1.5.2.20030407091116.04e7d240@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: "Salekul Islam" From: Mark Baugher Subject: Re: [MSEC] Question Related to PIM-SM 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: Mon, 07 Apr 2003 09:15:50 -0700 Salekul, At 10:59 PM 4/6/2003 -0400, Salekul Islam wrote: >Hi, > >I need some clarification related to PIM-SM security. In PIM-SM we have >link-local messages that are sent to ALL_PIM_ROUTERS. In security section >of PIM-SM spec it is receommended that one SA should be used to protect >all the link-local messages. In that spec nothing is mentioned about how >to protect multicast data. By "multicast data" do you mean the user data that are routed through PIM? >As far my understanding we need another SA among the sender(s) and >receiver(s) to protect mulicast data. Yes, but I would not call this PIM security unless the senders and receivers are PIM routers and the data are PIM messages. >When a sender sends data to multicast group it will use the later SA and >only the receivers will be able to decrypt the data (not the intermediate >routers). Intermediate routers will only bypass these data packets. Is my >understanding clear? Or I am missing some points? I think so. The protection of user's multicast data is quite separate from the protection of multicast routing messages. The two have no dependence on each other. > >I asked the same quetion to PIM WG but they have referred me to ask it >here. I am expecting someone's response. I hope my comments are relevant. Mark > >Salekul > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 7 12:18:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25283 for ; Mon, 7 Apr 2003 12:18:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2EBDD5364F; Mon, 7 Apr 2003 12:20: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 BE287536FB for ; Mon, 7 Apr 2003 12:18:21 -0400 (EDT) Received: (qmail 88756 invoked by uid 3269); 7 Apr 2003 16:18:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88753 invoked from network); 7 Apr 2003 16:18:21 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by klesh.pair.com with SMTP; 7 Apr 2003 16:18:21 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h37GIEmr016900; Mon, 7 Apr 2003 09:18:14 -0700 (PDT) Received: from cscoamera13263.mbaugher.com (rtp-vpn2-375.cisco.com [10.82.241.119]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACZ40787; Mon, 7 Apr 2003 09:18:12 -0700 (PDT) Message-Id: <5.1.1.5.2.20030407091716.0513add8@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents Cc: msec@securemulticast.org In-Reply-To: <3E90C36E.1070900@nortelnetworks.com> References: <200304061931.PAA28236@ornavella.watson.ibm.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, 07 Apr 2003 09:18:06 -0700 hi, At 08:16 PM 4/6/2003 -0400, Lakshminath Dondeti wrote: >I agree with you Ran. I also think that we should follow IKEv2's model >and piggyback the GDOI Child SAs (Rekey and Data Security SAs) on to the >last two messages of an IKEv2 exchange. And, I am sure we can find a >volunteer to write GDOIv2 :-). well, the volunteer(s) will need to have an IKEv2 implementation and be able to extend it with GDOIv2. cheers, Mark >regards, >Lakshminath > >Ran Canetti wrote: >>A belated remark on this thread: As the GDOI document says, there is >>nothing in GDOI that ties it exclusively to IKEv1. Indeed, once IKEv2 is >>stable, >>it should be quite straightforward to write a "GDOIv2" document which >>describes how GDOI can make use of IKEv2. Potentially, the GDOI phase 2 >>can be piggybacked >>on the last two messagges of phase 1 (as is done in IKEv2); this would >>reduce the round complexity of "GDOIv2" to the round complexity of IKEv2, >>which is 4/6 messages, depending on whether dos protection is on. >>Hopefully we can find a volunteer with enough energy to write this up. >>Ran > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 7 13:16:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27953 for ; Mon, 7 Apr 2003 13:16:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 69E3253725; Mon, 7 Apr 2003 13:18:34 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7542053665 for ; Mon, 7 Apr 2003 13:16:23 -0400 (EDT) Received: (qmail 99127 invoked by uid 3269); 7 Apr 2003 17:16:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99124 invoked from network); 7 Apr 2003 17:16:23 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 7 Apr 2003 17:16:23 -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 h37HG8P24867; Mon, 7 Apr 2003 10:16:08 -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 2J0VRZ0S; Mon, 7 Apr 2003 10:15:22 -0700 Received: from nortelnetworks.com (acart32b.ca.nortel.com [47.129.60.116]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2J0P050X; Mon, 7 Apr 2003 13:15:19 -0400 Message-ID: <3E91B2E5.9050700@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents References: <200304061931.PAA28236@ornavella.watson.ibm.com> <5.1.1.5.2.20030407091716.0513add8@agora.rdrop.com> 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, 07 Apr 2003 13:18:29 -0400 Content-Transfer-Encoding: 7bit Agreed :-)! Lakshminath Mark Baugher wrote: > hi, > > At 08:16 PM 4/6/2003 -0400, Lakshminath Dondeti wrote: > >> I agree with you Ran. I also think that we should follow IKEv2's >> model and piggyback the GDOI Child SAs (Rekey and Data Security SAs) >> on to the last two messages of an IKEv2 exchange. And, I am sure we >> can find a volunteer to write GDOIv2 :-). > > > well, the volunteer(s) will need to have an IKEv2 implementation and be > able to extend it with GDOIv2. > > cheers, Mark > > >> regards, >> Lakshminath >> >> Ran Canetti wrote: >> >>> A belated remark on this thread: As the GDOI document says, there is >>> nothing in GDOI that ties it exclusively to IKEv1. Indeed, once IKEv2 >>> is stable, >>> it should be quite straightforward to write a "GDOIv2" document which >>> describes how GDOI can make use of IKEv2. Potentially, the GDOI phase >>> 2 can be piggybacked >>> on the last two messagges of phase 1 (as is done in IKEv2); this would >>> reduce the round complexity of "GDOIv2" to the round complexity of >>> IKEv2, >>> which is 4/6 messages, depending on whether dos protection is on. >>> Hopefully we can find a volunteer with enough energy to write this up. >>> Ran >> >> >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Apr 7 14:54:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00740 for ; Mon, 7 Apr 2003 14:54:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CAE82536C0; Mon, 7 Apr 2003 14:56: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 73795536A9 for ; Mon, 7 Apr 2003 14:54:24 -0400 (EDT) Received: (qmail 15125 invoked by uid 3269); 7 Apr 2003 18:54:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15122 invoked from network); 7 Apr 2003 18:54:24 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 7 Apr 2003 18:54:24 -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 h37Is6Q24408; Mon, 7 Apr 2003 14:54:06 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h37Is5l45534; Mon, 7 Apr 2003 14:54:06 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id OAA38868; Mon, 7 Apr 2003 14:54:04 -0400 From: Ran Canetti Message-Id: <200304071854.OAA38868@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, hh@sparta.com Subject: Re: [MSEC] Comments on GSAKMP lite Cc: msec@securemulticast.org 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, 7 Apr 2003 14:54:04 -0400 Hugh, > From hh@sparta.com Mon Apr 7 08:27:32 2003 > > Ran, > > I've been thinking about our discussions at the IETF for a week or two. > You made two suggestions - use cookies a la IKEv2 to prevent some DOS > attacks and replace the signature on the GSAKMP ACK message with a > signed MAC. > > I believe that cookies must be added to the GSAKMP spec and that will > happen. Great! > However, I've been thinking about changing the authentication on the > ACK message from a signature to a keyed MAC as you suggested. We would > get some efficiencies in protocol processing, however we would be > loosing the non-reputation characteristic of the signed ACK. > > I think the signed ACK would give a subordinate GC/KS a non-reputable > proof of key delivery that could be handed off to the master GC/KS. In > a group scenario this would help manage the group. A GC/KS could store > this signed ACK as proof of authorization to charge or to verify that > an Sub GC/KS is acting properly. > > I believe the non-reputability property is only important in a group > scenario. In peer SAs both sides have direct proof of the connection > and SA creation. In peer SAs it makes perfect sense to switch to a > keyed MAC for processing efficiencies. I don't think the same thing can > be said in the Group paradigm. oops... i just re-read the draft and my remarks, and my suggestion to remove the signature in message 3 is wrong. the signature must be there for the core security of the exchange. The initiator must sign the responder's DH exponent and/or nonce, othewise some attacks may be possible. So in the current design the 3rd message must be signed. Ran > > Thanks > > Hugh > BTW, as a side, I'd like to remark that there is still something unsatisfying in the fact that the same signature (in message 3) is used both for the core security of the exchange and for billing/logging purposes. first, the two signatures could have different security requirements or certificates. furthermore, it would be nice to have a protocol that uses only a single member-generated signature whenever the billing-signature is not needed. Here is a potential (and very sketchy) design that separates the two signatures. There are either 4 or 5 messages here, depending on whether the member signature on the key-download is needed. Note however that the KS is not required to make any on-line exponentiation until message 3 is received. This means that the cookie mechanism could be piggybacked on messages 2,3 withut additional round trips. (It is true that the KS has to generate g^y, which requires exponentiation. but: (a) this can be done in advance, off-line, (b) the KS can use the same g^y form multiple exchanges within a given time period. in this case the per-session freshness is guaranteed by a separate Nonce.) member -> KS : g^x, ID, Cert KS -> member : g^y, Nonce memver -> KS : sig_member(g^x,g^y,KS,Nonce,member-ID) KS -> member : sig_KS(g^x,g^y,KS,member-ID,e=ENC(key download info)) member -> KS : sig_member(KS,member-ID,e) /* this signature is optional */ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 8 13:30:11 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23095 for ; Tue, 8 Apr 2003 13:30:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 44DF0536DF; Tue, 8 Apr 2003 13:32:13 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 560FD536DF for ; Tue, 8 Apr 2003 13:30:22 -0400 (EDT) Received: (qmail 61670 invoked by uid 3269); 8 Apr 2003 17:30:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61665 invoked from network); 8 Apr 2003 17:30:21 -0000 Received: from pigeon.verisign.com (65.205.251.71) by klesh.pair.com with SMTP; 8 Apr 2003 17:30:21 -0000 Received: from vhqpostal-gw1.verisign.com (signio.com [65.205.251.55]) by pigeon.verisign.com (8.12.9/) with ESMTP id h38HRcIJ015769; Tue, 8 Apr 2003 10:27:38 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.35.33.15]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id G937NFF8; Tue, 8 Apr 2003 10:30:14 -0700 Message-Id: <5.0.0.25.2.20030408132340.02270db8@vhqpostal3.verisign.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: "Salekul Islam" , From: Thomas Hardjono Subject: Re: [MSEC] Question Related to PIM-SM 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: Tue, 08 Apr 2003 13:30:11 -0400 Hi Salekul, Let me try have a go at answering your questions. At 4/6/2003||10:59 PM, Salekul Islam wrote: >Hi, > >I need some clarification related to PIM-SM security. In PIM-SM we have >link-local messages that are sent to ALL_PIM_ROUTERS. In security section >of PIM-SM spec it is receommended that one SA should be used to protect >all the link-local messages. In that spec nothing is mentioned about how >to protect multicast data. That's correct. The PIM-SM spec is more concerned about router-to-router behavior (including their security), as opposed to the data (and its security) being forwarded. >As far my understanding we need another SA among the sender(s) and >receiver(s) to protect mulicast data. When a sender sends data to >multicast group it will use the later SA and only the receivers will be >able to decrypt the data (not the intermediate routers). Intermediate >routers will only bypass these data packets. Is my understanding clear? Or >I am missing some points? Yes, that is also correct. Thus, two different instances of the Group SA (GSA) is needed. One is for the "data" plane, where the members are the Receivers (e.g. people), and another for the routing plane where the members are the PIM-routers. > >I asked the same quetion to PIM WG but they have referred me to ask it >here. I am expecting someone's response. > >Salekul > Hope this helps. cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 8 14:26:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25070 for ; Tue, 8 Apr 2003 14:26:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9AF0F53840; Tue, 8 Apr 2003 14:27:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CF3195380E for ; Tue, 8 Apr 2003 13:52:29 -0400 (EDT) Received: (qmail 64904 invoked by uid 3269); 8 Apr 2003 17:52:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64901 invoked from network); 8 Apr 2003 17:52:29 -0000 Received: from heron.mail.pas.earthlink.net (207.217.120.189) by klesh.pair.com with SMTP; 8 Apr 2003 17:52:29 -0000 Received: from user-vcauo1q.dsl.mindspring.com ([216.175.96.58] helo=SGOSWAMIPCL) by heron.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 192xGm-0002Bi-00 for msec@securemulticast.org; Tue, 08 Apr 2003 10:52:28 -0700 From: "Subrata Goswami" To: Message-ID: <00d801c2fdf7$89e52340$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E91B2E5.9050700@nortelnetworks.com> Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b8c5814d95a742dc6cf39083a5449b2a1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Subject: [MSEC] Questions on draft-ietf-msec-ipsec-multicast-issues-01.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, 8 Apr 2003 10:51:52 -0700 Content-Transfer-Encoding: 7bit Q1. In Section 1.0, should the first sentences of choices A and B need to be swapped ? Q2. Authentication and Integrity. The difference from unicast arises primarily because SA's can be shared, hence authentication and integrity needs to performed separately. Disallowing SA sharing would eliminate this problem. Q3. Anti-reply protection: It seems to me that the sequence number is source dependant, so adding the source address bits to sequence counter bits should uniquely identify the particular sequence (even when SA's are shared). Q4. Scant resource devices. Here the argument is that these devices may not have enough resources to store multiple source specific SA's. An alternative would be to allow only one source to multicast to these devices. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 8 16:53:23 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01689 for ; Tue, 8 Apr 2003 16:53:22 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A2A205384B; Tue, 8 Apr 2003 16:54:36 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D0C9F53848 for ; Tue, 8 Apr 2003 16:53:36 -0400 (EDT) Received: (qmail 99814 invoked by uid 3269); 8 Apr 2003 20:53:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99809 invoked from network); 8 Apr 2003 20:53:36 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 8 Apr 2003 20:53:36 -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 h38KrSQ232872; Tue, 8 Apr 2003 16:53:28 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h38KrSl94458; Tue, 8 Apr 2003 16:53:28 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id QAA36904; Tue, 8 Apr 2003 16:53:27 -0400 From: Ran Canetti Message-Id: <200304082053.QAA36904@ornavella.watson.ibm.com> To: bew@cisco.com, thardjono@verisign.com, thardjono@yahoo.com Cc: msec@securemulticast.org Subject: [MSEC] Comments on MSEC architecture draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 8 Apr 2003 16:53:27 -0400 Here are some remarks on the MSEC architecture draft (http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-00.txt). In all, the draft looks good, but there are several issues that seem to require addressing. I encourage people to give this document a thorough reading, it is an important one. Ran * The document does not address MIKEY and how it is incorporated into the MSEC architecture. True, MIKEY is a belated addition to the working group, and it works a bit differently than GDOI and GSAKMP. Still, we should fit it in the current framework (or alternatively decide that it doesnt fit). One option would be to use MIKEY as a registration protocol; but then: (a) MIKEY should be able to generate a GSA in the same way that GDOI and GSAKMP do. (b) There should probably be a rekey (or, "PUSH") protocol associated with MIKEY. However, this option does not cover the use of MIKEY for small groups with single sender, potentially without a GCKS at all. Do we wantto includethis option within the MSEC architecture or do we want to leave it out for now? Any thoughts/suggestions? * The framework should probably mention explicitly that in some scenarios a member may need to establish additional secure unicast connection with the GCKS, on top of the registration protocol. These may be to "resynch" in case of running out of synch regarding group keys, or to "de-register" in case this is relevant. * Regarding the registration SA: It should probably be discussed whether the Reg SA should be long-lived (ie, should exist throughout the lifetime of the group) or short-lived (ie, should exist only as long as the registration protocol is alive). The long-lived case is less scalable since the GCKS needs to maintain an SA for each member. (This can be somewhat less of a problem for distributed designs). If short-lived SA is used then it should be said that a new SA is set-up for each "resynch" or "de-register" connection with the GCKS. * Regarding the data SA: The recent advancements regarding structure of the data SA in conjunction with IPSEC should probably be reflected in this document. Full details can be refered to the MESP document (which will probably change its name to the data security architecture document), but at least the principles (including the fact that we are using the ESP format with the ESP protocol number) are definitely part of the general architecture. Also, currently the document says nothing on how the data is actually protected, it is not even mentioned in which layer of the communication the protection takes place. It should probably be said that we use IP layer protection, and more specifically that the transforms we use are compatible with ESP and AH. (In fact, do we want to use AH at all in the context of MSEC, or does ESP answer all our needs?) * Section 5 (security services) is probably more appropriate for a requirements document, but in lack of such (at least so far), it should probably stay. * The reference [CP99] should probably be changed to [CCPRRS] Canetti R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P., Saha D., "An architecture for secure IP multicast", NDSS 2000. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Apr 11 19:28:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04931 for ; Fri, 11 Apr 2003 19:28:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4CDD653681; Fri, 11 Apr 2003 19:30: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 C8F615356D for ; Fri, 11 Apr 2003 19:29:19 -0400 (EDT) Received: (qmail 74878 invoked by uid 3269); 11 Apr 2003 23:29:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74875 invoked from network); 11 Apr 2003 23:29:19 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 11 Apr 2003 23:29:19 -0000 Received: from cisco.com ([128.107.176.91]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3BNTFGO024827; Fri, 11 Apr 2003 16:29:16 -0700 (PDT) Message-ID: <3E96E10C.DD9CBDFA@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: Ran Canetti Cc: thardjono@verisign.com, thardjono@yahoo.com, msec@securemulticast.org References: <200304082053.QAA36904@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: Comments on MSEC architecture draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 11 Apr 2003 08:36:44 -0700 Content-Transfer-Encoding: 7bit Ran, Thanks very much for your comments. Please see remarks inline below. Ran Canetti wrote: > > Here are some remarks on the MSEC architecture draft > (http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-00.txt). > In all, the draft looks good, but there are several issues that seem to > require addressing. > > I encourage people to give this document a thorough reading, it is an > important one. > > Ran > > * The document does not address MIKEY and how it is incorporated into the > MSEC architecture. True, MIKEY is a belated addition to the working group, > and it works a bit differently than GDOI and GSAKMP. Still, we should > fit it in the current framework (or alternatively decide that it doesnt fit). > > One option would be to use MIKEY as a registration protocol; but > then: (a) MIKEY should be able to generate a GSA in the same way that GDOI > and GSAKMP do. (b) There should probably be a rekey (or, "PUSH") protocol > associated with MIKEY. Regarding (a), both MIKEY and GKMARCH state that MIKEY fits into the architecture as a registration protocol, so it clearly does fit into the MSEC architecture. A description of how and why it fits as a registration protocol protocol probably belongs in the GKMARCH document rather than the MSEC Arch document. Regarding (b), the GKMARCH does point out that a re-key protocol is optional for a GKM system. That has been MSEC's intent. However, the MSEC Arch draft appears to be missing that discussion so I'll add it. > However, this option does not cover the use of MIKEY for small groups with > single sender, potentially without a GCKS at all. Do we wantto includethis > option within the MSEC architecture or do we want to leave it out for now? > Any thoughts/suggestions? One can consider the sender as acting as a GCKS to his receivers. I think that fits the architecture. It would be a good idea to mention that the role of a GCKS can be played by a group member (e.g., sender). > * The framework should probably mention explicitly that in some scenarios > a member may need to establish additional secure unicast connection with > the GCKS, on top of the registration protocol. These may be to "resynch" > in case of running out of synch regarding group keys, or to "de-register" > in case this is relevant. OK, I'll add those concepts. > * Regarding the registration SA: It should probably be discussed whether the > Reg SA should be long-lived (ie, should exist throughout the lifetime of the > group) or short-lived (ie, should exist only as long as the registration > protocol is alive). > The long-lived case is less scalable since the GCKS needs to maintain an SA > for each member. (This can be somewhat less of a problem for distributed > designs). If short-lived SA is used then it should be said that a new SA is > set-up for each "resynch" or "de-register" connection with the GCKS. OK, will do. > * Regarding the data SA: The recent advancements regarding structure of the > data SA in conjunction with IPSEC should probably be reflected in this > document. Full details can be refered to the MESP document (which will > probably change its name to the data security architecture document), > but at least the principles (including the fact that we are using the > ESP format with the ESP protocol number) are definitely part of the general > architecture. Shouldn't the MSEC architecture be agnostic as to what types of data security SAs are used? I can imagine SRTP SAs for example, or other data security protocols which are not related to IPsec at all. (For that matter, I wonder if the data security arch document should also not be so closely tied to IPsec. Maybe there does need to be a separate document there.) > Also, currently the document says nothing on how the data is actually protected, > it is not even mentioned in which layer of the communication the protection > takes place. It should probably be said that we use IP layer protection, > and more specifically that the transforms we use are compatible with ESP and > AH. (In fact, do we want to use AH at all in the context of MSEC, or does > ESP answer all our needs?) But from an overall architecture perspective a data security SA could be at any layer of the protocol, can't it? For example, I've run into scenarios where the old SMuG concept of AMESP would have been useful. I'd rather we left it that way in the architecture. > * Section 5 (security services) is probably more appropriate for a > requirements document, but in lack of such (at least so far), it should > probably stay. > > * The reference [CP99] should probably be changed to > > [CCPRRS] Canetti R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P., > Saha D., "An architecture for secure IP multicast", NDSS 2000. OK, will do. Thanks, Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Apr 12 01:17:28 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10596 for ; Sat, 12 Apr 2003 01:17:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BE5F6538D9; Sat, 12 Apr 2003 01:19: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 03E7E53575 for ; Fri, 11 Apr 2003 23:27:46 -0400 (EDT) Received: (qmail 7948 invoked by uid 3269); 12 Apr 2003 03:27:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7945 invoked from network); 12 Apr 2003 03:27:46 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 12 Apr 2003 03:27: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 h3C3RkQ185156 for ; Fri, 11 Apr 2003 23:27:46 -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.4) with ESMTP id h3C3Rj761368 for ; Fri, 11 Apr 2003 23:27:45 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id XAA25958 for msec@securemulticast.org; Fri, 11 Apr 2003 23:27:45 -0400 From: Ran Canetti Message-Id: <200304120327.XAA25958@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] Minutes of SFO meeting 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, 11 Apr 2003 23:27:45 -0400 Below are the minutes of the SFO meeting, as scribed by Mark Baugher. (Thanks Mark!) Any comments? We hould submit them to the IETF proceedings on Monday. (Sorry for the last minute notice.) Thanks, Thomas and Ran PS. The slides of the presentations are available from the IETF site, at http://www.ietf.org/proceedings/03mar/index.html. MSEC WG Meeting, 56th IETF, 17 March 2003 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Recharter, Thomas: A new charter was posted to the msec list for discussion. Thomas showed the current MSEC I-Ds list. GDOI & MIKEY are in Last Call. Recharter to extend msec life to 2004 to finish work and develop new focus on distributed architectures and many:many multicast. Mar 03 Last Call on GKMARCH with several more following. New focus areas are not on the list or Proposed I- Ds, but Ran thinks that these problems should be issues for each of the present drafts rather than separate drafts. 2. TESLA Update, Adrian: Brief description of TESLA stream, outline of current drafts, and future works on broadcast authentication. Problem is to prevent receiver from impersonating sender in a secure group. Sender precomputes N+1 keys, 0..N, where Kn = HMAC(Kn-1, 1), K0 = K. K is installed securely prior to the session start. The sender creats a chain from the installed key(0) to key(N-1) where key(N-1) is the first key to be revealed in a TESLA packet during the session. The receiver can always verify that a key(n-k) is part of the chain by computing key(n-j), j=k..n, and compute key(N-1) or some intermediate key that the receiver has received and cached. The TESLA I-Ds is draft-ietf- msec-tesla-intro-01 that adds immediate authentication and concurrent TESLA instances (to handle receivers over networks with a wide range of packet delays. draft-ietf-msec-tesla-spec-00 is current technical draft that gives a bootstrapping procedures (e.g. time synchronization), format, operation with ESP, etc. B.Whillock has done a reference implementation that is available on the web. Looking for a second implementation. Also need to integrate with ESP/MESP. 3. IPSEC Multicast Issues, Brian: Ran, Mark, Thomas and Brian wrote an I-D to document the multicast issues in AH/ESP while they are being revised by S.Kent. The issues are (1) SPI allocation and SA lookup using 3-tuple without using source address, (2) Anti-replay protection for multi-sender SAs (part of new charter of msec), and (3) ICV name. Overall, this was a productive exchange IPSEC and MSEC with good collaboration with S.Kent. 4. MESP, Mark: Made MESP into a transform framework for ESP rather than a separate protocol. The framework is based on group secrecy, internal authentication and external authentication where external authentication protects internal. Need to resolve making ENC, INT, EXT processing order to be mandatory. 5. Feedback messages, Lakshminath: Feedback is needed for GSA synchronization, NAKs, and de-registration. Most GKM systems keep a unique key per member; suggest we use that unique key for feedback from each group member. SA lookup could probably use the SPI. Proposed feedback message resembles the groupkey push message in GDOI. Hugh pointed out that the unique key is usually a KEK and said that the use of a KEK for a TEK could be problematic. Replay protection may use the SEQ# and this may work for NAKs and de-registration but not for out of sync feedback messages. Question: is this something the group should do? The answer is yes. 6. Group key management, Lakshminath: Do one RFC for LKH, OFT, and OFC as well as treating key tree management. The latter uses binary or natural number encoding, the goal is to manage the splitting and shrinking in an efficient manner. Zhang et. al. scheme keeps rekey messages small and limits number of messages for maintaining tree. Two Options. First, standardize key tree encoding and try to get a key tree encoding for all interesting trees. Second, GCKS may advertise a standardized scheme and use it - tradeoffs footprint, communication cost, etc. 7. GSAKMP, Hugh: GSAKMP Light done in Sep 2001 that was shorter and simpler. Since GSAKMP Light is favored, we decided to focus just on GSAKMP Light and make it GSAKMP. Old GSAKMP considered for Informational RFCs; Russ favors Experimental over Informational; if it catches on, then an Experimental track protocol can go standards track, Informational cannot. 8. Policy Token, Hugh: New spec has GSAKMP Roles and Policy token. GSAKMP creates set of roles (GO, GCKS, Sub GCKS,and GM). Policy token wraps policy and sent from GO to GCKS who then distributes it to subordinates of group members (GM). GSAKMP protocol incorporates policy-token dissemination. Policy uses Identification, Authorizations, Access Control, Mechanisms, and Signature. Each was explained. 9. DHHMAC for Mikey, Martin: intended for proposed standard, identity protection clarified, aligned with MIKEY v6, and editorial improvements. Document is ready for WG last call? But a -02 version will be submitted prior to last call. Ran said that this probably should not go ahead of MIKEY. Thomas will submit in two weeks. Also, there may be some need for EC for MIKEY. 10. SDP Security Descriptions, Mark: After a brief overview of SDP, Mark described two configurations for which SDP Security Descriptions apply; one is an end-to-end RTSP running in TLS; the other is a hop-by-hop SIP running over some collection of TLS connections. He briefly described the SDP status, syntax, parameters and next steps. In the discussion, Russ went thumbs down on the hop-by-hop SIP security descriptions as offering no security. Mark and Dan Wing wrote the draft-ietf-mmusic-sdescriptions-00.txt and will be updating it to draft-ietf-mmusic-sdescriptions-01.txt in the Spring. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Apr 12 10:48:03 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29131 for ; Sat, 12 Apr 2003 10:48:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 388135371E; Sat, 12 Apr 2003 10:50: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 097A7536DC for ; Sat, 12 Apr 2003 10:48:44 -0400 (EDT) Received: (qmail 20282 invoked by uid 3269); 12 Apr 2003 14:48:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20279 invoked from network); 12 Apr 2003 14:48:44 -0000 Received: from smtp014.mail.yahoo.com (216.136.173.58) by klesh.pair.com with SMTP; 12 Apr 2003 14:48:44 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 Apr 2003 14:48:43 -0000 Message-Id: <5.0.0.25.2.20030412104716.03e6ae40@vhqpostal3.verisign.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Subject: Slides on MSEC website -- Re: [MSEC] Minutes of SFO meeting In-Reply-To: <200304120327.XAA25958@ornavella.watson.ibm.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, 12 Apr 2003 10:48:41 -0400 All the slides and the minutes are also on the MSEC website. http://www.securemulticast.org/msec-meetings.htm thomas ------ At 4/11/2003||11:27 PM, Ran Canetti wrote: >Below are the minutes of the SFO meeting, as scribed by Mark Baugher. >(Thanks Mark!) Any comments? We hould submit them to the IETF >proceedings on Monday. (Sorry for the last minute notice.) > >Thanks, > >Thomas and Ran > >PS. The slides of the presentations are available from the IETF site, >at http://www.ietf.org/proceedings/03mar/index.html. > > > >MSEC WG Meeting, 56th IETF, 17 March 2003 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >1. Recharter, Thomas: A new charter was posted to the msec list for >discussion. >Thomas showed the current MSEC I-Ds list. GDOI & MIKEY are in Last Call. >Recharter to extend msec life to 2004 to finish work and develop new focus on >distributed architectures and many:many multicast. Mar 03 Last Call on >GKMARCH >with several more following. New focus areas are not on the list or >Proposed I- >Ds, but Ran thinks that these problems should be issues for each of the >present >drafts rather than separate drafts. > >2. TESLA Update, Adrian: Brief description of TESLA stream, outline of >current >drafts, and future works on broadcast authentication. Problem is to prevent >receiver from impersonating sender in a secure group. Sender precomputes N+1 >keys, 0..N, where Kn = HMAC(Kn-1, 1), K0 = K. K is installed securely >prior to >the session start. The sender creats a chain from the installed key(0) to >key(N-1) where key(N-1) is the first key to be revealed in a TESLA packet >during >the session. The receiver can always verify that a key(n-k) is part of the >chain by computing key(n-j), j=k..n, and compute key(N-1) or some >intermediate >key that the receiver has received and cached. The TESLA I-Ds is draft-ietf- >msec-tesla-intro-01 that adds immediate authentication and concurrent TESLA >instances (to handle receivers over networks with a wide range of packet >delays. >draft-ietf-msec-tesla-spec-00 is current technical draft that gives a >bootstrapping procedures (e.g. time synchronization), format, operation with >ESP, etc. B.Whillock has done a reference implementation that is >available on >the web. Looking for a second implementation. Also need to integrate with >ESP/MESP. > >3. IPSEC Multicast Issues, Brian: Ran, Mark, Thomas and Brian wrote an I-D to >document the multicast issues in AH/ESP while they are being revised by >S.Kent. >The issues are (1) SPI allocation and SA lookup using 3-tuple without using >source address, (2) Anti-replay protection for multi-sender SAs (part of new >charter of msec), and (3) ICV name. Overall, this was a productive exchange >IPSEC and MSEC with good collaboration with S.Kent. > >4. MESP, Mark: Made MESP into a transform framework for ESP rather than a >separate protocol. The framework is based on group secrecy, internal >authentication and external authentication where external authentication >protects internal. Need to resolve making ENC, INT, EXT processing order >to be >mandatory. > >5. Feedback messages, Lakshminath: Feedback is needed for GSA >synchronization, >NAKs, and de-registration. Most GKM systems keep a unique key per member; >suggest we use that unique key for feedback from each group member. SA >lookup >could probably use the SPI. Proposed feedback message resembles the groupkey >push message in GDOI. Hugh pointed out that the unique key is usually a >KEK and >said that the use of a KEK for a TEK could be problematic. Replay protection >may use the SEQ# and this may work for NAKs and de-registration but not >for out >of sync feedback messages. Question: is this something the group should >do? >The answer is yes. > >6. Group key management, Lakshminath: Do one RFC for LKH, OFT, and OFC as >well >as treating key tree management. The latter uses binary or natural number >encoding, the goal is to manage the splitting and shrinking in an efficient >manner. Zhang et. al. scheme keeps rekey messages small and limits number of >messages for maintaining tree. Two Options. First, standardize key tree >encoding and try to get a key tree encoding for all interesting >trees. Second, >GCKS may advertise a standardized scheme and use it - tradeoffs footprint, >communication cost, etc. > >7. GSAKMP, Hugh: GSAKMP Light done in Sep 2001 that was shorter and simpler. >Since GSAKMP Light is favored, we decided to focus just on GSAKMP Light >and make >it GSAKMP. Old GSAKMP considered for Informational RFCs; Russ favors >Experimental over Informational; if it catches on, then an Experimental track >protocol can go standards track, Informational cannot. > >8. Policy Token, Hugh: New spec has GSAKMP Roles and Policy token. GSAKMP >creates set of roles (GO, GCKS, Sub GCKS,and GM). Policy token wraps >policy and >sent from GO to GCKS who then distributes it to subordinates of group members >(GM). GSAKMP protocol incorporates policy-token dissemination. Policy uses >Identification, Authorizations, Access Control, Mechanisms, and >Signature. Each >was explained. > >9. DHHMAC for Mikey, Martin: intended for proposed standard, identity >protection clarified, aligned with MIKEY v6, and editorial improvements. >Document is ready for WG last call? But a -02 version will be submitted >prior >to last call. Ran said that this probably should not go ahead of >MIKEY. Thomas >will submit in two weeks. Also, there may be some need for EC for MIKEY. > >10. SDP Security Descriptions, Mark: After a brief overview of SDP, Mark >described two configurations for which SDP Security Descriptions apply; >one is >an end-to-end RTSP running in TLS; the other is a hop-by-hop SIP running over >some collection of TLS connections. He briefly described the SDP status, >syntax, parameters and next steps. In the discussion, Russ went thumbs >down on >the hop-by-hop SIP security descriptions as offering no security. Mark >and Dan >Wing wrote the draft-ietf-mmusic-sdescriptions-00.txt and will be updating >it to >draft-ietf-mmusic-sdescriptions-01.txt in the Spring. > > > > >_______________________________________________ >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 Apr 14 00:13:38 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11883 for ; Mon, 14 Apr 2003 00:13:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 238F753886; Mon, 14 Apr 2003 00:15: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 D445F535A2 for ; Mon, 14 Apr 2003 00:12:03 -0400 (EDT) Received: (qmail 21895 invoked by uid 3269); 14 Apr 2003 04:12:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21888 invoked from network); 14 Apr 2003 04:12:03 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 14 Apr 2003 04:12:03 -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 h3E4BuQ177172; Mon, 14 Apr 2003 00:11:56 -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.4) with ESMTP id h3E4Bt792750; Mon, 14 Apr 2003 00:11:56 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id AAA29478; Mon, 14 Apr 2003 00:11:55 -0400 From: Ran Canetti Message-Id: <200304140411.AAA29478@ornavella.watson.ibm.com> To: bew@cisco.com, canetti@watson.ibm.com Cc: msec@securemulticast.org, thardjono@verisign.com, thardjono@yahoo.com Subject: [MSEC] Re: Comments on MSEC architecture draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 14 Apr 2003 00:11:55 -0400 Brian, See remarks inline. > From bew@cisco.com Fri Apr 11 19:30:04 2003 > > Ran, > > Thanks very much for your comments. Please see remarks inline below. > > Ran Canetti wrote: > > > > Here are some remarks on the MSEC architecture draft > > (http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-00.txt). > > In all, the draft looks good, but there are several issues that seem to > > require addressing. > > > > I encourage people to give this document a thorough reading, it is an > > important one. > > > > Ran > > > > * The document does not address MIKEY and how it is incorporated into the > > MSEC architecture. True, MIKEY is a belated addition to the working group, > > and it works a bit differently than GDOI and GSAKMP. Still, we should > > fit it in the current framework (or alternatively decide that it doesnt fit). > > > > One option would be to use MIKEY as a registration protocol; but > > then: (a) MIKEY should be able to generate a GSA in the same way that GDOI > > and GSAKMP do. (b) There should probably be a rekey (or, "PUSH") protocol > > associated with MIKEY. > > Regarding (a), both MIKEY and GKMARCH state that MIKEY fits into the > architecture as a registration protocol, so it clearly does fit into the > MSEC architecture. A description of how and why it fits as a > registration protocol protocol probably belongs in the GKMARCH document > rather than the MSEC Arch document. > > Regarding (b), the GKMARCH does point out that a re-key protocol is > optional for a GKM system. That has been MSEC's intent. However, the > MSEC Arch draft appears to be missing that discussion so I'll add it. ok. > > > However, this option does not cover the use of MIKEY for small groups with > > single sender, potentially without a GCKS at all. Do we wantto includethis > > option within the MSEC architecture or do we want to leave it out for now? > > Any thoughts/suggestions? > > One can consider the sender as acting as a GCKS to his receivers. I > think that fits the architecture. It would be a good idea to mention > that the role of a GCKS can be played by a group member (e.g., sender). I think its a bit more than that: With 1-to-many using MIKEY there is no real "registration protocol" - the key exchange is initiated by the sender and consists of a single message from the sender to the recipient(s). Do we want to accept this way of setting up a 1-to-many session, say with small number of recipients? (I dont see any reason not to, does anybody else see any?) > > > * The framework should probably mention explicitly that in some scenarios > > a member may need to establish additional secure unicast connection with > > the GCKS, on top of the registration protocol. These may be to "resynch" > > in case of running out of synch regarding group keys, or to "de-register" > > in case this is relevant. > > OK, I'll add those concepts. > > > * Regarding the registration SA: It should probably be discussed whether the > > Reg SA should be long-lived (ie, should exist throughout the lifetime of the > > group) or short-lived (ie, should exist only as long as the registration > > protocol is alive). > > The long-lived case is less scalable since the GCKS needs to maintain an SA > > for each member. (This can be somewhat less of a problem for distributed > > designs). If short-lived SA is used then it should be said that a new SA is > > set-up for each "resynch" or "de-register" connection with the GCKS. > > OK, will do. > > > * Regarding the data SA: The recent advancements regarding structure of the > > data SA in conjunction with IPSEC should probably be reflected in this > > document. Full details can be refered to the MESP document (which will > > probably change its name to the data security architecture document), > > but at least the principles (including the fact that we are using the > > ESP format with the ESP protocol number) are definitely part of the general > > architecture. > > Shouldn't the MSEC architecture be agnostic as to what types of data > security SAs are used? I can imagine SRTP SAs for example, or other data > security protocols which are not related to IPsec at all. > > (For that matter, I wonder if the data security arch document should > also not be so closely tied to IPsec. Maybe there does need to be a > separate document there.) I very much agree that in principle there is no reason to do exclusively ipsec. But the architecture should represent reality. And in reality we're only doing IPSEC (for now at least). So, I'd think the arch should say that we currently use IPSEC, and that in the future it may be possible to have an an SRTP-based data transmission for MSEC. (And if anybody is interested making the future into present then they's most welcome to!) > > > Also, currently the document says nothing on how the data is actually protected, > > it is not even mentioned in which layer of the communication the protection > > takes place. It should probably be said that we use IP layer protection, > > and more specifically that the transforms we use are compatible with ESP and > > AH. (In fact, do we want to use AH at all in the context of MSEC, or does > > ESP answer all our needs?) > > But from an overall architecture perspective a data security SA could be > at any layer of the protocol, can't it? For example, I've run into > scenarios where the old SMuG concept of AMESP would have been useful. > I'd rather we left it that way in the architecture. Again, you're right that in principle it can be in either layer, and it was appropriate for the SMuG draft to be more generic, being an IRTF draft. But I think that the current arch should reflect what is actually being done, and that's IPSEC. Best, Ran > > > * Section 5 (security services) is probably more appropriate for a > > requirements document, but in lack of such (at least so far), it should > > probably stay. > > > > * The reference [CP99] should probably be changed to > > > > [CCPRRS] Canetti R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P., > > Saha D., "An architecture for secure IP multicast", NDSS 2000. > > OK, will do. > > Thanks, > Brian > > -- > Brian Weis > Strategic Cryptographic Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 22 16:06:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23889 for ; Tue, 22 Apr 2003 16:06:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 00758535CE; Tue, 22 Apr 2003 16:08:46 -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 4BC09535CE for ; Tue, 22 Apr 2003 16:06:13 -0400 (EDT) Received: (qmail 96851 invoked by uid 3269); 22 Apr 2003 20:06:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96848 invoked from network); 22 Apr 2003 20:06:13 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 22 Apr 2003 20:06:13 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3MK5wdL028431; Tue, 22 Apr 2003 13:06:10 -0700 (PDT) Received: from cscoamera13263.mbaugher.com (rtp-vpn2-710.cisco.com [10.82.242.198]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADL53552; Tue, 22 Apr 2003 13:05:56 -0700 (PDT) Message-Id: <5.1.1.5.2.20030422130042.02c4ecf0@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Ran Canetti From: Mark Baugher Subject: Re: [MSEC] Comments on MSEC architecture draft Cc: Brian Weis , thardjono@verisign.com, thardjono@yahoo.com, msec@securemulticast.org In-Reply-To: <200304082053.QAA36904@ornavella.watson.ibm.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, 22 Apr 2003 13:05:54 -0700 At 04:53 PM 4/8/2003 -0400, Ran Canetti wrote: >Here are some remarks on the MSEC architecture draft >(http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-00.txt). >In all, the draft looks good, but there are several issues that seem to >require addressing. > >I encourage people to give this document a thorough reading, it is an >important one. > > >Ran > > > >* The document does not address MIKEY and how it is incorporated into the >MSEC architecture. True, MIKEY is a belated addition to the working group, >and it works a bit differently than GDOI and GSAKMP. Still, we should >fit it in the current framework (or alternatively decide that it doesnt fit). > >One option would be to use MIKEY as a registration protocol; When we admitted MIKEY as a work item to msec, we said that it was a registration protocol, but there is another dimension to this question: Will group security be used in IP telephony? Most of us in business use conference calls almost as much as point-to-point calls. Do we expect that an ad-hoc or "meet me" conference to use group keys? Will we continue to have middle boxes such as multipoint control units when we add security? I think this is worthy of some consideration. Mark >but >then: (a) MIKEY should be able to generate a GSA in the same way that GDOI >and GSAKMP do. (b) There should probably be a rekey (or, "PUSH") protocol >associated with MIKEY. > >However, this option does not cover the use of MIKEY for small groups with >single sender, potentially without a GCKS at all. Do we wantto includethis >option within the MSEC architecture or do we want to leave it out for now? >Any thoughts/suggestions? > >* The framework should probably mention explicitly that in some scenarios >a member may need to establish additional secure unicast connection with >the GCKS, on top of the registration protocol. These may be to "resynch" >in case of running out of synch regarding group keys, or to "de-register" >in case this is relevant. > >* Regarding the registration SA: It should probably be discussed whether the >Reg SA should be long-lived (ie, should exist throughout the lifetime of the >group) or short-lived (ie, should exist only as long as the registration >protocol is alive). >The long-lived case is less scalable since the GCKS needs to maintain an SA >for each member. (This can be somewhat less of a problem for distributed >designs). If short-lived SA is used then it should be said that a new SA is >set-up for each "resynch" or "de-register" connection with the GCKS. > >* Regarding the data SA: The recent advancements regarding structure of the >data SA in conjunction with IPSEC should probably be reflected in this >document. Full details can be refered to the MESP document (which will >probably change its name to the data security architecture document), >but at least the principles (including the fact that we are using the >ESP format with the ESP protocol number) are definitely part of the general >architecture. > >Also, currently the document says nothing on how the data is actually >protected, >it is not even mentioned in which layer of the communication the protection >takes place. It should probably be said that we use IP layer protection, >and more specifically that the transforms we use are compatible with ESP and >AH. (In fact, do we want to use AH at all in the context of MSEC, or does >ESP answer all our needs?) > >* Section 5 (security services) is probably more appropriate for a >requirements document, but in lack of such (at least so far), it should >probably stay. > >* The reference [CP99] should probably be changed to > > [CCPRRS] Canetti R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P., > Saha D., "An architecture for secure IP multicast", NDSS 2000. > > > > > > >_______________________________________________ >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 Apr 22 16:19:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24641 for ; Tue, 22 Apr 2003 16:19:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 12C6B535CE; Tue, 22 Apr 2003 16:21: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 6D6015371D for ; Tue, 22 Apr 2003 16:19:47 -0400 (EDT) Received: (qmail 1676 invoked by uid 3269); 22 Apr 2003 20:19:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1673 invoked from network); 22 Apr 2003 20:19:47 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 22 Apr 2003 20:19:47 -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 h3MKJkT26234 for ; Tue, 22 Apr 2003 16:19:46 -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.4) with ESMTP id h3MKJjr61820 for ; Tue, 22 Apr 2003 16:19:45 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id QAA40594 for msec@securemulticast.org; Tue, 22 Apr 2003 16:19:45 -0400 From: Ran Canetti Message-Id: <200304222019.QAA40594@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] Data Security Architecture document 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, 22 Apr 2003 16:19:45 -0400 Folks, As we know, the MSEC charter calls for a document describing the architecture of the MSEC data security transforms. There is a proposal to base much of this draft on the current mesp draft (draft-ietf-msec-mesp-01.txt), and to discontinue the mesp draft. The proposed structure of the data security transforms architecture (d-star) darft is roughly as follows: 1. A general part describing the required functionalities of data security transforms (confidentiality, source authentication, group authentication). 2. A part summarizing the information included in the data SA generated by the key management protocols. 3. A part describing how to do data protection in the IP layer. This will be based mostly on the current MESP draft (and will be compatible with IPSEC's ESP). A question here: Does anyone see a need to discuss also a "Multicast AH" (or MAH), analogously to MESP? 4. A part describing how to do data protection in the application layer, based on SRTP. (This is a new section that did not appear before.) What do people say? If there are no objections then the hope is that a first draft will be out within a month or so. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 22 17:29:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27538 for ; Tue, 22 Apr 2003 17:29:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 124285370D; Tue, 22 Apr 2003 17:31: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 8150D535AF for ; Tue, 22 Apr 2003 17:29:52 -0400 (EDT) Received: (qmail 15745 invoked by uid 3269); 22 Apr 2003 21:29:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15742 invoked from network); 22 Apr 2003 21:29:52 -0000 Received: from lithium.nac.net (64.21.52.83) by klesh.pair.com with SMTP; 22 Apr 2003 21:29:52 -0000 Received: (qmail 45346 invoked from network); 22 Apr 2003 21:26:27 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.172) by mail.nac.net with SMTP; 22 Apr 2003 21:26:27 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h3MJYYQ01414; Tue, 22 Apr 2003 15:34:34 -0400 From: George Gross To: Ran Canetti Cc: Subject: Re: [MSEC] Data Security Architecture document In-Reply-To: <200304222019.QAA40594@ornavella.watson.ibm.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, 22 Apr 2003 15:34:34 -0400 (EDT) Hi Ran, On Tue, 22 Apr 2003, Ran Canetti wrote: > A question here: Does anyone see a need to discuss also a "Multicast AH" > (or MAH), analogously to MESP? > hmmm... yes, I can think of an application domain that might have a need for this capability. There are two scenarios that come to mind: 1) the local legal jurisdiction does not allow encryption or it requires source authentication when using encryption, and/or at the same time the protection of the IP header integrity is a requirement, 2) you are transporting a payload that does not contain secrets (i.e. no encryption needed) but you want to assure the IP header is source authenticated.... perhaps IPv6 SEND could fit this profile? or a VoIP teleconference that requires non-repudiation evidence. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Apr 22 19:20:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01230 for ; Tue, 22 Apr 2003 19:20:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B4B5E5387C; Tue, 22 Apr 2003 19:21: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 7BF4C5370D for ; Tue, 22 Apr 2003 17:35:33 -0400 (EDT) Received: (qmail 16576 invoked by uid 3269); 22 Apr 2003 21:35:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16573 invoked from network); 22 Apr 2003 21:35:33 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 22 Apr 2003 21:35:33 -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 h3MLZNg17754; Tue, 22 Apr 2003 17:35:23 -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 J1YLRZW6; Tue, 22 Apr 2003 17:35:22 -0400 Received: from nortelnetworks.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 2RDTQSN2; Tue, 22 Apr 2003 17:35:22 -0400 Message-ID: <3EA5B63D.8090900@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Cc: Ran Canetti , msec@securemulticast.org Subject: Re: [MSEC] Data Security Architecture document References: 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: Tue, 22 Apr 2003 17:38:05 -0400 Content-Transfer-Encoding: 7bit Wouldn't ESP with null encryption work in those cases? That said, how about preserving header integrity protection offered by AH in some form? cheers, Lakshminath George Gross wrote: > Hi Ran, > > On Tue, 22 Apr 2003, Ran Canetti wrote: > > >>A question here: Does anyone see a need to discuss also a "Multicast AH" >>(or MAH), analogously to MESP? >> > > hmmm... yes, I can think of an application domain that might have a need > for this capability. > > There are two scenarios that come to mind: > > 1) the local legal jurisdiction does not allow encryption or it requires > source authentication when using encryption, and/or at the same time the > protection of the IP header integrity is a requirement, > > 2) you are transporting a payload that does not contain secrets (i.e. no > encryption needed) but you want to assure the IP header is source > authenticated.... perhaps IPv6 SEND could fit this profile? or a VoIP > teleconference that requires non-repudiation evidence. > > 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 Tue Apr 22 19:23:08 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01273 for ; Tue, 22 Apr 2003 19:23:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E5260538A7; Tue, 22 Apr 2003 19:22: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 82F5E535FC for ; Tue, 22 Apr 2003 17:41:05 -0400 (EDT) Received: (qmail 17254 invoked by uid 3269); 22 Apr 2003 21:41:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17251 invoked from network); 22 Apr 2003 21:41:05 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 22 Apr 2003 21:41:05 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MLf1f16891; Tue, 22 Apr 2003 17:41:01 -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 J1YLRZX6; Tue, 22 Apr 2003 17:41:00 -0400 Received: from nortelnetworks.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 2RDTQSNS; Tue, 22 Apr 2003 17:41:00 -0400 Message-ID: <3EA5B795.1060402@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Cc: Ran Canetti , msec@securemulticast.org Subject: Re: [MSEC] Data Security Architecture document References: 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: Tue, 22 Apr 2003 17:43:49 -0400 Content-Transfer-Encoding: 7bit I missed the non-repudiation bit in my reply. We discussed it at the Atlanta meeting and decided (as with IPsec transforms) against providing non-repudiation at network layer. regards, Lakshminath George Gross wrote: > Hi Ran, > > On Tue, 22 Apr 2003, Ran Canetti wrote: > > >>A question here: Does anyone see a need to discuss also a "Multicast AH" >>(or MAH), analogously to MESP? >> > > hmmm... yes, I can think of an application domain that might have a need > for this capability. > > There are two scenarios that come to mind: > > 1) the local legal jurisdiction does not allow encryption or it requires > source authentication when using encryption, and/or at the same time the > protection of the IP header integrity is a requirement, > > 2) you are transporting a payload that does not contain secrets (i.e. no > encryption needed) but you want to assure the IP header is source > authenticated.... perhaps IPv6 SEND could fit this profile? or a VoIP > teleconference that requires non-repudiation evidence. > > 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 Tue Apr 22 19:29:54 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01371 for ; Tue, 22 Apr 2003 19:29:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4FD5B537E7; Tue, 22 Apr 2003 19:32: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 84A4C53803 for ; Tue, 22 Apr 2003 19:30:25 -0400 (EDT) Received: (qmail 32398 invoked by uid 3269); 22 Apr 2003 23:30:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32395 invoked from network); 22 Apr 2003 23:30:25 -0000 Received: from lithium.nac.net (64.21.52.83) by klesh.pair.com with SMTP; 22 Apr 2003 23:30:25 -0000 Received: (qmail 96857 invoked from network); 22 Apr 2003 22:57:28 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.172) by mail.nac.net with SMTP; 22 Apr 2003 22:57:28 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h3ML5Tn01504; Tue, 22 Apr 2003 17:05:29 -0400 From: George Gross To: Lakshminath Dondeti Cc: Ran Canetti , Subject: Re: [MSEC] Data Security Architecture document In-Reply-To: <3EA5B795.1060402@nortelnetworks.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, 22 Apr 2003 17:05:29 -0400 (EDT) Hi Lakshminath, well, working groups achieve their rough consensus on the mailing list ;o) since I was not at Atlanta, what was the basis of the decision on the "against providing non-repudiation at network layer..."? From what I can tell, we agree that having IP header integrity protection is a requirement, so don't we get source authentication and non-repudiation for essentially free? br, George On Tue, 22 Apr 2003, Lakshminath Dondeti wrote: > I missed the non-repudiation bit in my reply. We discussed it at the > Atlanta meeting and decided (as with IPsec transforms) against providing > non-repudiation at network layer. > > regards, > Lakshminath > > George Gross wrote: > > Hi Ran, > > > > On Tue, 22 Apr 2003, Ran Canetti wrote: > > > > > >>A question here: Does anyone see a need to discuss also a "Multicast AH" > >>(or MAH), analogously to MESP? > >> > > > > hmmm... yes, I can think of an application domain that might have a need > > for this capability. > > > > There are two scenarios that come to mind: > > > > 1) the local legal jurisdiction does not allow encryption or it requires > > source authentication when using encryption, and/or at the same time the > > protection of the IP header integrity is a requirement, > > > > 2) you are transporting a payload that does not contain secrets (i.e. no > > encryption needed) but you want to assure the IP header is source > > authenticated.... perhaps IPv6 SEND could fit this profile? or a VoIP > > teleconference that requires non-repudiation evidence. > > > > 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 Tue Apr 22 20:02:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02168 for ; Tue, 22 Apr 2003 20:02:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 52D4553823; Tue, 22 Apr 2003 20:04: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 4D13B535F2 for ; Tue, 22 Apr 2003 20:03:15 -0400 (EDT) Received: (qmail 36899 invoked by uid 3269); 23 Apr 2003 00:03:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36896 invoked from network); 23 Apr 2003 00:03:15 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by klesh.pair.com with SMTP; 23 Apr 2003 00:03:15 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3N035n2022141; Tue, 22 Apr 2003 17:03:06 -0700 (PDT) Received: from cscoamera13263.mbaugher.com (rtp-vpn2-710.cisco.com [10.82.242.198]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADL79712; Tue, 22 Apr 2003 17:02:53 -0700 (PDT) Message-Id: <5.1.1.5.2.20030422170212.02ed7aa8@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] Data Security Architecture document Cc: George Gross , Ran Canetti , msec@securemulticast.org In-Reply-To: <3EA5B63D.8090900@nortelnetworks.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: Tue, 22 Apr 2003 17:02:51 -0700 At 05:38 PM 4/22/2003 -0400, Lakshminath Dondeti wrote: >Wouldn't ESP with null encryption work in those cases? > >That said, how about preserving header integrity protection offered by AH >in some form? I think we need AH for this purpose Mark >cheers, >Lakshminath > >George Gross wrote: >>Hi Ran, >>On Tue, 22 Apr 2003, Ran Canetti wrote: >> >> >>>A question here: Does anyone see a need to discuss also a "Multicast AH" >>>(or MAH), analogously to MESP? >>hmmm... yes, I can think of an application domain that might have a need >>for this capability. >>There are two scenarios that come to mind: >>1) the local legal jurisdiction does not allow encryption or it requires >>source authentication when using encryption, and/or at the same time the >>protection of the IP header integrity is a requirement, >>2) you are transporting a payload that does not contain secrets (i.e. no >>encryption needed) but you want to assure the IP header is source >>authenticated.... perhaps IPv6 SEND could fit this profile? or a VoIP >>teleconference that requires non-repudiation evidence. >>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 Wed Apr 23 13:12:11 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26682 for ; Wed, 23 Apr 2003 13:12:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DCCE853613; Wed, 23 Apr 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 8170C5353A for ; Wed, 23 Apr 2003 13:12:53 -0400 (EDT) Received: (qmail 22174 invoked by uid 3269); 23 Apr 2003 17:12:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22170 invoked from network); 23 Apr 2003 17:12:53 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by klesh.pair.com with SMTP; 23 Apr 2003 17:12:53 -0000 Received: from cisco.com (stealth-10-34-255-61.cisco.com [10.34.255.61]) by sj-core-2.cisco.com (8.12.6/8.12.6) with SMTP id h3NHCmID006017; Wed, 23 Apr 2003 10:12:49 -0700 (PDT) Message-ID: <3EA65AFC.FFF3DB7F@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: Ran Canetti Cc: msec@securemulticast.org, thardjono@verisign.com, thardjono@yahoo.com Subject: Re: [MSEC] Re: Comments on MSEC architecture draft References: <200304140411.AAA29478@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 23 Apr 2003 02:21:00 -0700 Content-Transfer-Encoding: 7bit Hi Ran, Ran Canetti wrote: > > > However, this option does not cover the use of MIKEY for small groups with > > > single sender, potentially without a GCKS at all. Do we wantto includethis > > > option within the MSEC architecture or do we want to leave it out for now? > > > Any thoughts/suggestions? > > > > One can consider the sender as acting as a GCKS to his receivers. I > > think that fits the architecture. It would be a good idea to mention > > that the role of a GCKS can be played by a group member (e.g., sender). > > I think its a bit more than that: With 1-to-many using MIKEY there is no > real "registration protocol" - the key exchange is initiated by the sender > and consists of a single message from the sender to the recipient(s). > Do we want to accept this way of setting up a 1-to-many session, > say with small number of recipients? (I dont see any reason not to, does > anybody else see any?) I agree that we should accept this way of setting up a 1-to-many session. But I would argue that a single message does take the role of a registration protocol. This deserves some discussion in the GKMARCH document which, as I understand it, is meant to expand upon the key management architecture points in the MSEC Arch document. > > Shouldn't the MSEC architecture be agnostic as to what types of data > > security SAs are used? I can imagine SRTP SAs for example, or other data > > security protocols which are not related to IPsec at all. > > > > (For that matter, I wonder if the data security arch document should > > also not be so closely tied to IPsec. Maybe there does need to be a > > separate document there.) > > I very much agree that in principle there is no reason to do exclusively > ipsec. But the architecture should represent reality. And in reality > we're only doing IPSEC (for now at least). So, I'd think the arch should say > that we currently use IPSEC, and that in the future it may be possible to > have an an SRTP-based data transmission for MSEC. > (And if anybody is interested making the future into present then they's > most welcome to!) > > > > > > Also, currently the document says nothing on how the data is actually protected, > > > it is not even mentioned in which layer of the communication the protection > > > takes place. It should probably be said that we use IP layer protection, > > > and more specifically that the transforms we use are compatible with ESP and > > > AH. (In fact, do we want to use AH at all in the context of MSEC, or does > > > ESP answer all our needs?) > > > > But from an overall architecture perspective a data security SA could be > > at any layer of the protocol, can't it? For example, I've run into > > scenarios where the old SMuG concept of AMESP would have been useful. > > I'd rather we left it that way in the architecture. > > Again, you're right that in principle it can be in either layer, and it was > appropriate for the SMuG draft to be more generic, being an IRTF draft. > But I think that the current arch should reflect what is actually being done, > and that's IPSEC. Well, this is an interesting question. I think we are coming from different directions with respect to the purpose of the MSEC Architecture document. Let me try to explain for what purpose I thought it was intended. I'm anxious to hear other people's thoughts on the subject. Here's the question: should our Architecture documents be constrained to current working group items, or are Architecture documents supposed to consider the overall architecture that we are working with? The MSEC charter does not restrict us to any particular protocols, nor does it restrict us to a particular layer in the network stack. Also, It has seemed to me that one of MSEC's valuable contributions has been to carry forward and further the unpublished architectural work done in SMuG. Since the SMuG work remains unpublished, but remains the base of all of our work, we have an obligation to publish it. Indeed that work needs to be brought up to date to encompass newer work, but that's a matter of expanding the architecture rather than restricting it! One could contrast the MSEC Architecture document with RFC 2401. RFC 2401 very specifically defines one method of securing IP packets, so it must be very restrictive. But there isn't exactly one method of securing group traffic. In some sense, the MSEC Arch document is at a higher level than RFC 2401, and it does in fact point to IPsec as one way of securing group traffic. The other point I want to make is that we have in our charter a second layer of architecture documents which further define data transform arch, group key mgmt arch, and policy arch. Those indeed should talk about protocols as examples, and discuss the protocols in more detail. But there's no reason the high level MSEC Architecture document should be so restrictive. To play devils advocate, if on the other hand the the MSEC Architecture document just was concerned with IPsec, then the MSEC Architecture document wouldn't be necessary, because RFC 2401 already encompasses how to encrypt multicast packets and talks about the possible future of group key management. In summary, I strongly feel that the MSEC Arch document needs to describe the general concepts of how to secure group traffic. One of the main contributions that MSEC can make is to publish general principles around how to secure multicast, as well as defining protocols (e.g., MESP) which fit into that architecture. As I said above, I'm anxious to hear other opinions. Thanks, Brian > Best, > > Ran > -- 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 Apr 23 14:17:54 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28805 for ; Wed, 23 Apr 2003 14:17:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 07A8553623; Wed, 23 Apr 2003 14:20: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 BBBF1537E7 for ; Wed, 23 Apr 2003 14:18:42 -0400 (EDT) Received: (qmail 34168 invoked by uid 3269); 23 Apr 2003 18:18:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34165 invoked from network); 23 Apr 2003 18:18:42 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 23 Apr 2003 18:18:42 -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 h3NIIFT55064; Wed, 23 Apr 2003 14:18:15 -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.4) with ESMTP id h3NIIFr63330; Wed, 23 Apr 2003 14:18:15 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) with ESMTP id OAA40932; Wed, 23 Apr 2003 14:18:15 -0400 From: canetti To: Brian Weis Cc: msec@securemulticast.org, thardjono@verisign.com, thardjono@yahoo.com Subject: Re: [MSEC] Re: Comments on MSEC architecture draft In-Reply-To: <3EA65AFC.FFF3DB7F@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, 23 Apr 2003 14:18:14 -0400 (EDT) Brian, just a quick reply: On Wed, 23 Apr 2003, Brian Weis wrote: ... > Hi Ran, > > Ran Canetti wrote: > > > > > However, this option does not cover the use of MIKEY for small groups with > > > > single sender, potentially without a GCKS at all. Do we wantto includethis > > > > option within the MSEC architecture or do we want to leave it out for now? > > > > Any thoughts/suggestions? > > > > > > One can consider the sender as acting as a GCKS to his receivers. I > > > think that fits the architecture. It would be a good idea to mention > > > that the role of a GCKS can be played by a group member (e.g., sender). > > > > I think its a bit more than that: With 1-to-many using MIKEY there is no > > real "registration protocol" - the key exchange is initiated by the sender > > and consists of a single message from the sender to the recipient(s). > > Do we want to accept this way of setting up a 1-to-many session, > > say with small number of recipients? (I dont see any reason not to, does > > anybody else see any?) > > I agree that we should accept this way of setting up a 1-to-many > session. But I would argue that a single message does take the role of a > registration protocol. This deserves some discussion in the GKMARCH > document which, as I understand it, is meant to expand upon the key > management architecture points in the MSEC Arch document. It definitely should be mentioned and elaborated in GKMARCH. I also think it is central/important enough to be mentioned in the general architecture document (albeit more tersely, ofcourse). Wouldn't you say? > > > > Shouldn't the MSEC architecture be agnostic as to what types of data > > > security SAs are used? I can imagine SRTP SAs for example, or other data > > > security protocols which are not related to IPsec at all. > > > > > > (For that matter, I wonder if the data security arch document should > > > also not be so closely tied to IPsec. Maybe there does need to be a > > > separate document there.) > > > > I very much agree that in principle there is no reason to do exclusively > > ipsec. But the architecture should represent reality. And in reality > > we're only doing IPSEC (for now at least). So, I'd think the arch should say > > that we currently use IPSEC, and that in the future it may be possible to > > have an an SRTP-based data transmission for MSEC. > > (And if anybody is interested making the future into present then they's > > most welcome to!) > > > > > > > > > Also, currently the document says nothing on how the data is actually protected, > > > > it is not even mentioned in which layer of the communication the protection > > > > takes place. It should probably be said that we use IP layer protection, > > > > and more specifically that the transforms we use are compatible with ESP and > > > > AH. (In fact, do we want to use AH at all in the context of MSEC, or does > > > > ESP answer all our needs?) > > > > > > But from an overall architecture perspective a data security SA could be > > > at any layer of the protocol, can't it? For example, I've run into > > > scenarios where the old SMuG concept of AMESP would have been useful. > > > I'd rather we left it that way in the architecture. > > > > Again, you're right that in principle it can be in either layer, and it was > > appropriate for the SMuG draft to be more generic, being an IRTF draft. > > But I think that the current arch should reflect what is actually being done, > > and that's IPSEC. > > Well, this is an interesting question. I think we are coming from > different directions with respect to the purpose of the MSEC > Architecture document. Let me try to explain for what purpose I thought > it was intended. I'm anxious to hear other people's thoughts on the > subject. > > Here's the question: should our Architecture documents be constrained to > current working group items, or are Architecture documents supposed to > consider the overall architecture that we are working with? > > The MSEC charter does not restrict us to any particular protocols, nor > does it restrict us to a particular layer in the network stack. > > Also, It has seemed to me that one of MSEC's valuable contributions has > been to carry forward and further the unpublished architectural work > done in SMuG. Since the SMuG work remains unpublished, but remains the > base of all of our work, we have an obligation to publish it. Indeed > that work needs to be brought up to date to encompass newer work, but > that's a matter of expanding the architecture rather than restricting > it! > > One could contrast the MSEC Architecture document with RFC 2401. RFC > 2401 very specifically defines one method of securing IP packets, so it > must be very restrictive. But there isn't exactly one method of securing > group traffic. In some sense, the MSEC Arch document is at a higher > level than RFC 2401, and it does in fact point to IPsec as one way of > securing group traffic. > > The other point I want to make is that we have in our charter a second > layer of architecture documents which further define data transform > arch, group key mgmt arch, and policy arch. Those indeed should talk > about protocols as examples, and discuss the protocols in more detail. > But there's no reason the high level MSEC Architecture document should > be so restrictive. > > To play devils advocate, if on the other hand the the MSEC Architecture > document just was concerned with IPsec, then the MSEC Architecture > document wouldn't be necessary, because RFC 2401 already encompasses how > to encrypt multicast packets and talks about the possible future of > group key management. > > In summary, I strongly feel that the MSEC Arch document needs to > describe the general concepts of how to secure group traffic. One of the > main contributions that MSEC can make is to publish general principles > around how to secure multicast, as well as defining protocols (e.g., > MESP) which fit into that architecture. > > As I said above, I'm anxious to hear other opinions. Brian, I didnt mean to say that the architecture document should not mention several options of what can be done. It definitely should. But it should also say what is actually being done. no? BTW, hopefully, the upcoming d-star (data security transforms architecture) draft will include a non-ipsec method, so we will not be restricted to ipsec exclusively. Ran > > Thanks, > Brian > > > Best, > > > > Ran > > > > -- > 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 Wed Apr 23 14: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 OAA00435 for ; Wed, 23 Apr 2003 14:52:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id ED9E45367C; Wed, 23 Apr 2003 14:54: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 8712753663 for ; Wed, 23 Apr 2003 14:53:19 -0400 (EDT) Received: (qmail 40785 invoked by uid 3269); 23 Apr 2003 18:53:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40782 invoked from network); 23 Apr 2003 18:53:19 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 23 Apr 2003 18:53:19 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NIrER00764; Wed, 23 Apr 2003 13:53:14 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2R1B0YYN; Wed, 23 Apr 2003 11:53:14 -0700 Received: from nortelnetworks.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 2RDTQT26; Wed, 23 Apr 2003 14:53:11 -0400 Message-ID: <3EA6E1BE.9090508@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Cc: Ran Canetti , msec@securemulticast.org Subject: Re: [MSEC] Data Security Architecture document References: 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: Wed, 23 Apr 2003 14:55:58 -0400 Content-Transfer-Encoding: 7bit Please see inline: George Gross wrote: > Hi Lakshminath, > > well, working groups achieve their rough consensus on the mailing > list ;o) since I was not at Atlanta, what was the basis of the decision on > the "against providing non-repudiation at network layer..."? > Yes, you are right about the procedure for consensus. But there was some discussion on the topic late last year. I am not sure whether that qualifies as consensus. http://www.pairlist.net/pipermail/msec/2002-November/000584.html The question is whether always-on non-repudiation without regard to various applications' requirements is a good feature. For many, including me, the answer is no. For example, it may be required for Business related VoIP conferences, but may be undesirable for personal calls. The new MESP draft authenticates encrypted text and therefore does not support non-repudiation as a feature (not even as an option, as I recall ;-)). Is AMESP still alive? regards, Lakshminath > From what I can tell, we agree that having IP header integrity > protection is a requirement, so don't we get source authentication and > non-repudiation for essentially free? > > br, > George > > On Tue, 22 Apr 2003, Lakshminath Dondeti wrote: > > >>I missed the non-repudiation bit in my reply. We discussed it at the >>Atlanta meeting and decided (as with IPsec transforms) against providing >>non-repudiation at network layer. >> >>regards, >>Lakshminath >> >>George Gross wrote: >> >>>Hi Ran, >>> >>>On Tue, 22 Apr 2003, Ran Canetti wrote: >>> >>> >>>>A question here: Does anyone see a need to discuss also a "Multicast AH" >>>>(or MAH), analogously to MESP? >>>> >>> >>>hmmm... yes, I can think of an application domain that might have a need >>>for this capability. >>> >>>There are two scenarios that come to mind: >>> >>>1) the local legal jurisdiction does not allow encryption or it requires >>>source authentication when using encryption, and/or at the same time the >>>protection of the IP header integrity is a requirement, >>> >>>2) you are transporting a payload that does not contain secrets (i.e. no >>>encryption needed) but you want to assure the IP header is source >>>authenticated.... perhaps IPv6 SEND could fit this profile? or a VoIP >>>teleconference that requires non-repudiation evidence. >>> >>>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 Apr 24 06:42:22 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10523 for ; Thu, 24 Apr 2003 06:42:22 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3CD0E5370D; Thu, 24 Apr 2003 06:44: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 634025369A for ; Thu, 24 Apr 2003 06:43:15 -0400 (EDT) Received: (qmail 15745 invoked by uid 3269); 24 Apr 2003 10:43:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15742 invoked from network); 24 Apr 2003 10:43:15 -0000 Received: from klovstad.no (HELO anton.klovstad.no) (217.13.22.153) by klesh.pair.com with SMTP; 24 Apr 2003 10:43:15 -0000 Received: from aaberg (laptop-dhcp-101 [192.168.16.101]) by anton.klovstad.no (8.12.2/8.12.2/Debian -7) with SMTP id h3OAhDqv013038 for ; Thu, 24 Apr 2003 12:43:14 +0200 Reply-To: From: =?iso-8859-1?Q?Magnus_Kl=F8vstad?= To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Subject: [MSEC] Scalability issues in MSEC proposals 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, 24 Apr 2003 12:43:13 +0200 Content-Transfer-Encoding: 7bit Hi, I am writing a paper for my master degree (University of Oslo, Norway) related to secure multicast scalability in large multicast groups with a single source. I have so far reviewed MSEC documentation on group management in the following protocols GSAKMP light, MIKEY and GDOI. As a part of the paper I will use modelling and simulation in Javasim (http://www.javasim.org) to simulate different scenarios and get a better view on scalability issues. I will therefore be grateful for all kind of documentation and links related to scalability. In particular documentation and implementation (not necessarily Javasim) related to group managment,key-distribution and re-keying. Best regards Magnus Klovstad magnusk@ifi.uio.no _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Apr 25 21:53:25 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29310 for ; Fri, 25 Apr 2003 21:53:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 58399539AF; Fri, 25 Apr 2003 21:55: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 EBD53535B6 for ; Fri, 25 Apr 2003 16:55:40 -0400 (EDT) Received: (qmail 67242 invoked by uid 3269); 25 Apr 2003 20:55:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67237 invoked from network); 25 Apr 2003 20:55:40 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by klesh.pair.com with SMTP; 25 Apr 2003 20:55:40 -0000 Received: from cisco.com ([128.107.176.189]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3PKtc08022570; Fri, 25 Apr 2003 13:55:38 -0700 (PDT) Message-ID: <3EA9A0C9.40EAE0AC@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: Mark Baugher Cc: thardjono@yahoo.com, msec@securemulticast.org References: <5.1.1.5.2.20030422184425.0de8cdc8@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: comments on draft-ietf-msec-arch-00.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, 25 Apr 2003 13:55:37 -0700 Content-Transfer-Encoding: 7bit Hi Mark, Thank you for your careful review. Please see replies inline. Mark Baugher wrote: > > Brian, Thomas > Here are my comments on > http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-00.txt. Pardon my > delay in getting to this. > > Mark > > 1. Document purpose and goals > o p.1 Abstract says it describes the protocols of the msec group. I > think it should be the overview and rationale of the msec architecture. OK. > o We should remove msec wg references in the Abstract, Section 1.1, > 5.2.2, 7 and any other places where it appears. I believe that the IETF > does not publish documents that reference working groups as a rule. Good point. > [snip] In any > case, I think we want to describe our architecture and contrast it with > alternatives in the Introduction. That's a good idea. > o We should remove the "work plan" aspects of this document, which is a > legacy of the smug work where this document laid out what we were going to > do. Now, we need to describe something closer to a finished product, the > msec architecture. > - the Abstract talks about "what must be addressed" Good catch. > - 2.1 first sentence talks about a "proposed" framework and later has > phrases like "attempts to incorporate" and "tries to express" which sounds > more like an approach or proposal than a finished architecture (or set of > protocols that perform a complete function). OK. > - ditto on 3.0, which uses the phrase "begins to address" and 3.3 > says that multicast policy "will extend" the work done in the IPsec policy > work and things that "need to be explored." OK. > - ditto on 5.2.1, which mentions "functional building blocks" and > 5.2.5 that speculates on what the work "must take into account." OK. > - 7.0 has similar issues My preference would be to get rid of section 7 completely. Comments? > o the WG needs to noodle a bit on what this document is. It currently > has a document roadmap, are we going to keep it and update the documents > that it contains? My preference would be to drop it completely from this document. Perhaps a separate document akin to RFC 2411 would make sense to publish just before MSEC disbands. Any document roapmap published before that time would be incomplete. > 2. The unfinished architecture > o 1.3 does not reference any policy documents and this is a gating > factor to how far we can go in describing the msec architecture when this > work is missing I think section 1.3 does not belong in this document. References to these documents should be made in the relevant sections later in the document. Whether or not there are policy documents to cite (your complaint) should be dealt with later policy sections. > o It's dicey to assume much about msec policy without having work > underway on a policy I-D; if the GSAKMP Token is to serve as the basis of > policy then we should reference that, but this is a work item that is neeed > for the msec architecture to be complete. right now, its vague when it > comes to policy There has been *some* work done one a policy arch I-D, but it hasn't been completed yet. :-( I'm not sure where the GSAKMP Token fits into the picture. > o 2.2.2 uses the phrase "allowed to" rather than "authorized to" and > this is a place where we should discuss the authorization issues, much of > which is sprinkled through the GSAKMP documents. OK. > o I think we are at risk in publishing this document before we resolve > our policy problem in msec since those who work on it may need to change > the approach in ways that are not anticipated in the document This whole document is built around the Reference Framework (figure 1). This is so high level, I have trouble understanding how the policy work would deviate from this high level. > 3. Definitions > o I'm not sure exactly what is meant by "influence of policies" in > 2.2.2. "policy translation" is not defined in 3.3, nor is the term > "mechanism." I'll reword these things. > o "distributed" is not defined in terms of security in 2.2.1 or > 2.2.4. There are issues with authorization (e.g. delegation certs) and new > protocols (e.g. among GCKS's and Policy Servers) and hard-to-solve > problems, such as policy. OK. > o 4.2 talks about the registration SA as being "crucial" and "protect > other elements of the GSA (this is vague), but I think that the other two > SAs can be established without the registration protocol per se. Consider > a smart card approach among others. I think this section should be saying that there must be a registration process in order to setup the other two SAs. Whether or not that's a "registration protocol" or "installing a smart card" matters not. I'll reword this. > o Section 5 incorrectly includes confidentiality and authentication > between member and GCKS in the data plane services > > 4. Editorial comments > o 1.0 "...which have been developed which..." > o 2.1, the 1st three paragraphs could be condensed into several > sentences I think > o 3.0 uses the phrase "emanating from the reference framework," which > sounds stilted > o 3.0 uses "refreshment" where key management might be more appropriate > o The bullets are funky in 3.2 and throughout most of the document > o 3.3, the last sentence might better serve as the topic of the entire > section > o 4.1 appears twice > o 4.1(2), first paragraph is redundant or belongs in sections 2 and 3 > or should somehow refer back to section 2 and 3 > o "pairwise" might be a better word than "unicast" in most places > o p 13 "dta" should be "data" > o the normative terms "may" and "must" appear in section 5.2.1 and in > other places of the document that are non-normative > o 5.2.3 is missing a comma after "paramount" > o 5.2.6 should have references for PDP and PEP Thanks, Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec