From msec-bounces@ietf.org Fri Oct 13 02:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGhS-0007T0-Kq; Fri, 13 Oct 2006 02:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGhS-0007Sv-4B for msec@ietf.org; Fri, 13 Oct 2006 02:39:18 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYGhQ-00081Y-Gl for msec@ietf.org; Fri, 13 Oct 2006 02:39:18 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J72001QGAI64T@szxga01-in.huawei.com> for msec@ietf.org; Fri, 13 Oct 2006 14:39:42 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7200B0KAI6VI@szxga01-in.huawei.com> for msec@ietf.org; Fri, 13 Oct 2006 14:39:42 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J720076RAKM87@szxml03-in.huawei.com> for msec@ietf.org; Fri, 13 Oct 2006 14:41:11 +0800 (CST) Date: Fri, 13 Oct 2006 14:35:15 +0800 From: Liu Ya To: msec@ietf.org Message-id: <023a01c6ee91$be5cf6f0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [MSEC] Is GSAKMP compatible with IPsec architecture defined in RFC4301? X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, I have a question about GSAKMP. In the MSEC architecture defined in RFC4301 and draft-ietf-msec-ipsec-extensions-01, ESP/AH can be used for data security protocols. GDOI and GKDP serve group keying. Can GSAKMP be used here for group keying? I find no GSAKMP payloads that can deliver SPI (Security Parameters Index) information from GC/KS to group members. Please tell me whether the combination of MSEC_Architecture+ESP/AH+GSAKMP is feasible? Thanks, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Oct 13 02:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGhS-0007T0-Kq; Fri, 13 Oct 2006 02:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYGhS-0007Sv-4B for msec@ietf.org; Fri, 13 Oct 2006 02:39:18 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYGhQ-00081Y-Gl for msec@ietf.org; Fri, 13 Oct 2006 02:39:18 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J72001QGAI64T@szxga01-in.huawei.com> for msec@ietf.org; Fri, 13 Oct 2006 14:39:42 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7200B0KAI6VI@szxga01-in.huawei.com> for msec@ietf.org; Fri, 13 Oct 2006 14:39:42 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J720076RAKM87@szxml03-in.huawei.com> for msec@ietf.org; Fri, 13 Oct 2006 14:41:11 +0800 (CST) Date: Fri, 13 Oct 2006 14:35:15 +0800 From: Liu Ya To: msec@ietf.org Message-id: <023a01c6ee91$be5cf6f0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [MSEC] Is GSAKMP compatible with IPsec architecture defined in RFC4301? X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, I have a question about GSAKMP. In the MSEC architecture defined in RFC4301 and draft-ietf-msec-ipsec-extensions-01, ESP/AH can be used for data security protocols. GDOI and GKDP serve group keying. Can GSAKMP be used here for group keying? I find no GSAKMP payloads that can deliver SPI (Security Parameters Index) information from GC/KS to group members. Please tell me whether the combination of MSEC_Architecture+ESP/AH+GSAKMP is feasible? Thanks, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Oct 13 22:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYxC-0006gI-Sx; Fri, 13 Oct 2006 22:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYxC-0006gD-8l for msec@ietf.org; Fri, 13 Oct 2006 22:08:46 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYYxA-0005ug-EV for msec@ietf.org; Fri, 13 Oct 2006 22:08:46 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J73002FESSFDN@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:12:16 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7300F3CSSFVD@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:12:15 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J73007C5SUVCI@szxml03-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:13:45 +0800 (CST) Date: Sat, 14 Oct 2006 10:07:47 +0800 From: Liu Ya Subject: Re: [MSEC] Is GSAKMP compatible with IPsec architecture defined in RFC4301? To: George Gross Message-id: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi George, Thanks for your answer. > Transitioning the above extensions from private implementations into the > IETF is an area for future standardization. Of course, that activity will > depend on industry interest. I am developing a group keying solution for OSPFv3, a complementarity to RFC4552. That solution is actually an IPsec group key management one. It can also be extended to other scenarios, such as PIM-SM-v2. As for keying protocol, GSAKMP is suitable for such cases for its rich features. That may be considered as a requirement to the standardization you mentioned. Best regards, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Oct 13 22:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYxC-0006gI-Sx; Fri, 13 Oct 2006 22:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYYxC-0006gD-8l for msec@ietf.org; Fri, 13 Oct 2006 22:08:46 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYYxA-0005ug-EV for msec@ietf.org; Fri, 13 Oct 2006 22:08:46 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J73002FESSFDN@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:12:16 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7300F3CSSFVD@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:12:15 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J73007C5SUVCI@szxml03-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:13:45 +0800 (CST) Date: Sat, 14 Oct 2006 10:07:47 +0800 From: Liu Ya Subject: Re: [MSEC] Is GSAKMP compatible with IPsec architecture defined in RFC4301? To: George Gross Message-id: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi George, Thanks for your answer. > Transitioning the above extensions from private implementations into the > IETF is an area for future standardization. Of course, that activity will > depend on industry interest. I am developing a group keying solution for OSPFv3, a complementarity to RFC4552. That solution is actually an IPsec group key management one. It can also be extended to other scenarios, such as PIM-SM-v2. As for keying protocol, GSAKMP is suitable for such cases for its rich features. That may be considered as a requirement to the standardization you mentioned. Best regards, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Oct 13 22:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYZEI-0001vb-BG; Fri, 13 Oct 2006 22:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYZEH-0001uL-Is for msec@ietf.org; Fri, 13 Oct 2006 22:26:25 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYZEE-0001sU-UQ for msec@ietf.org; Fri, 13 Oct 2006 22:26:25 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J73002K6TLTDN@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:29:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J73009GOTLTIZ@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:29:53 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J73004HOU0M41@szxml04-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:38:47 +0800 (CST) Date: Sat, 14 Oct 2006 10:25:25 +0800 From: Liu Ya To: msec@ietf.org Message-id: <032501c6ef38$02009f00$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/mixed; boundary="Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [MSEC] I-D ACTION:draft-liu-gdoi-extensions-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, I'm developing a automated group keying solution for OSPFv3. GDOI is used for keying protocol. According to the characteristics of OSPFv3 groups (long-term and stable group membership, trust entities between members), two extensions are defined in draft-liu-gdoi-extensions-00.txt to increase the Protocol's availability. Any comments on the draft would be appreciated. Thanks and regards, Liu Ya ----- Original Message ----- From: To: Sent: Saturday, October 14, 2006 3:50 AM Subject: I-D ACTION:draft-liu-gdoi-extensions-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : GDOI Extensions > Author(s) : Y. Liu, X. Chen > Filename : draft-liu-gdoi-extensions-00.txt > Pages : 13 > Date : 2006-10-13 > > The GDOI Protocol [RFC3547] specifies a standard mechanism of group > SA management. Two extensions are described in this document to > increase the Protocol's availability. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-liu-gdoi-extensions-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-liu-gdoi-extensions-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-type: application/octet-stream; name=ATT00696.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00696.dat Content-Type: text/plain Content-ID: <2006-10-13115229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liu-gdoi-extensions-00.txt --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-type: text/plain; name=draft-liu-gdoi-extensions-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-liu-gdoi-extensions-00.txt Content-Type: text/plain Content-ID: <2006-10-13115229.I-D@ietf.org> --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g)-- From msec-bounces@ietf.org Fri Oct 13 22:26:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYZEI-0001vb-BG; Fri, 13 Oct 2006 22:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYZEH-0001uL-Is for msec@ietf.org; Fri, 13 Oct 2006 22:26:25 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYZEE-0001sU-UQ for msec@ietf.org; Fri, 13 Oct 2006 22:26:25 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J73002K6TLTDN@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:29:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J73009GOTLTIZ@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:29:53 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J73004HOU0M41@szxml04-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 10:38:47 +0800 (CST) Date: Sat, 14 Oct 2006 10:25:25 +0800 From: Liu Ya To: msec@ietf.org Message-id: <032501c6ef38$02009f00$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/mixed; boundary="Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [MSEC] I-D ACTION:draft-liu-gdoi-extensions-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, I'm developing a automated group keying solution for OSPFv3. GDOI is used for keying protocol. According to the characteristics of OSPFv3 groups (long-term and stable group membership, trust entities between members), two extensions are defined in draft-liu-gdoi-extensions-00.txt to increase the Protocol's availability. Any comments on the draft would be appreciated. Thanks and regards, Liu Ya ----- Original Message ----- From: To: Sent: Saturday, October 14, 2006 3:50 AM Subject: I-D ACTION:draft-liu-gdoi-extensions-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : GDOI Extensions > Author(s) : Y. Liu, X. Chen > Filename : draft-liu-gdoi-extensions-00.txt > Pages : 13 > Date : 2006-10-13 > > The GDOI Protocol [RFC3547] specifies a standard mechanism of group > SA management. Two extensions are described in this document to > increase the Protocol's availability. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-liu-gdoi-extensions-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-liu-gdoi-extensions-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-type: application/octet-stream; name=ATT00696.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00696.dat Content-Type: text/plain Content-ID: <2006-10-13115229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liu-gdoi-extensions-00.txt --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-type: text/plain; name=draft-liu-gdoi-extensions-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-liu-gdoi-extensions-00.txt Content-Type: text/plain Content-ID: <2006-10-13115229.I-D@ietf.org> --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --Boundary_(ID_L0CQE1WhvaPc0Izax0vh6g)-- From msec-bounces@ietf.org Fri Oct 13 23:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYaPK-0001Ej-AP; Fri, 13 Oct 2006 23:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYaPJ-0001Dp-Gn for msec@ietf.org; Fri, 13 Oct 2006 23:41:53 -0400 Received: from lvs00-fl-n02.ftl.affinity.com ([216.219.253.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYaPI-0002tz-7K for msec@ietf.org; Fri, 13 Oct 2006 23:41:53 -0400 Received: ("??"@ams002.ftl.affinity.com) by ams002.ftl.affinity.com id S364558AbWJNDlY for ; Fri, 13 Oct 2006 23:41:24 -0400 References: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> In-Reply-To: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> From: gmgietf@identaware.com To: Liu Ya Date: Fri, 13 Oct 2006 23:41:24 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: msec@ietf.org, George Gross Subject: [MSEC] OSPFv3 security, was Re: Is GSAKMP compatible with IPsec architecture defined in RFC4301? X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Liu, I can see how applying MSEC IPsec to OSPF security would be a good fit for its trust model. GSAKMP has a rich feature set, and in particular its concept of autonomous distributed operations with sub-groups could map easily onto OSPF areas. In another e-mail that you sent to MSEC, you proposed a set of GDOI extensions that apparently handle the reliability and reachability issues found in a group of OSPF routers. Your Internet Draft seems to have some unstated OSPF requirements about why these GDOI extensions are needed. I would welcome hearing from you some more background about why you suggest that GDOI needs reliability mechanisms. In group key management protocols developed so far, reliability mechanisms are largely delegated to a separate protocol layer. br, George Liu Ya writes: > Hi George, > > Thanks for your answer. > >> Transitioning the above extensions from private implementations into the >> IETF is an area for future standardization. Of course, that activity will >> depend on industry interest. > > I am developing a group keying solution for OSPFv3, a complementarity to RFC4552. That solution is actually an IPsec group key management one. It can also be extended to other scenarios, such as PIM-SM-v2. As for keying protocol, GSAKMP is suitable for such cases for its rich features. That may be considered as a requirement to the standardization you mentioned. > > Best regards, > Liu Ya > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Oct 13 23:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYaPK-0001Ej-AP; Fri, 13 Oct 2006 23:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYaPJ-0001Dp-Gn for msec@ietf.org; Fri, 13 Oct 2006 23:41:53 -0400 Received: from lvs00-fl-n02.ftl.affinity.com ([216.219.253.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYaPI-0002tz-7K for msec@ietf.org; Fri, 13 Oct 2006 23:41:53 -0400 Received: ("??"@ams002.ftl.affinity.com) by ams002.ftl.affinity.com id S364558AbWJNDlY for ; Fri, 13 Oct 2006 23:41:24 -0400 References: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> In-Reply-To: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> From: gmgietf@identaware.com To: Liu Ya Date: Fri, 13 Oct 2006 23:41:24 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: msec@ietf.org, George Gross Subject: [MSEC] OSPFv3 security, was Re: Is GSAKMP compatible with IPsec architecture defined in RFC4301? X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Liu, I can see how applying MSEC IPsec to OSPF security would be a good fit for its trust model. GSAKMP has a rich feature set, and in particular its concept of autonomous distributed operations with sub-groups could map easily onto OSPF areas. In another e-mail that you sent to MSEC, you proposed a set of GDOI extensions that apparently handle the reliability and reachability issues found in a group of OSPF routers. Your Internet Draft seems to have some unstated OSPF requirements about why these GDOI extensions are needed. I would welcome hearing from you some more background about why you suggest that GDOI needs reliability mechanisms. In group key management protocols developed so far, reliability mechanisms are largely delegated to a separate protocol layer. br, George Liu Ya writes: > Hi George, > > Thanks for your answer. > >> Transitioning the above extensions from private implementations into the >> IETF is an area for future standardization. Of course, that activity will >> depend on industry interest. > > I am developing a group keying solution for OSPFv3, a complementarity to RFC4552. That solution is actually an IPsec group key management one. It can also be extended to other scenarios, such as PIM-SM-v2. As for keying protocol, GSAKMP is suitable for such cases for its rich features. That may be considered as a requirement to the standardization you mentioned. > > Best regards, > Liu Ya > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Oct 14 03:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdg3-0000BX-S8; Sat, 14 Oct 2006 03:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdg1-00006F-PU for msec@ietf.org; Sat, 14 Oct 2006 03:11:21 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYdXh-0006Fw-2l for msec@ietf.org; Sat, 14 Oct 2006 03:02:47 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7400L5G6ESVJ@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 15:06:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J740052D6ESXU@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 15:06:28 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J74005L16TKUF@szxml04-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 15:15:22 +0800 (CST) Date: Sat, 14 Oct 2006 15:01:58 +0800 From: Liu Ya To: gmgietf@identaware.com Message-id: <039d01c6ef5e$a49350c0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: msec@ietf.org Subject: [MSEC] Re: OSPFv3 security, was Re: Is GSAKMP compatible with IPsec architecture defined in RFC4301? X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi George, Thanks for your commenting quickly. My answer is inline. > Hi Liu, > > I can see how applying MSEC IPsec to OSPF security would be a good fit for > its trust model. GSAKMP has a rich feature set, and in particular its > concept of autonomous distributed operations with sub-groups could map > easily onto OSPF areas. GSAKMP would be more fit than GDOI. But extensions must be defined before GSAKMP can be used here. > In another e-mail that you sent to MSEC, you proposed a set of GDOI > extensions that apparently handle the reliability and reachability issues > found in a group of OSPF routers. Your Internet Draft seems to have some > unstated OSPF requirements about why these GDOI extensions are needed. I > would welcome hearing from you some more background about why you suggest > that GDOI needs reliability mechanisms. In group key management protocols > developed so far, reliability mechanisms are largely delegated to a separate > protocol layer. For existing reliable rekeying methods, e.g., reliable multicast protocol, FEC encoding scheme, etc., high efficiency can be achieved when they are implemented with IP multicast. But IP multicast service is not always available in some scenarios like OSPFv3 groups. And unicast is not fit for those methods. A multicast-undependent way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to fulfil that requirement. For simplicity, it is not achieved in a separate reliable protocol layer. Best regards, Liu Ya > br, > George > > Liu Ya writes: > >> Hi George, >> >> Thanks for your answer. >> >>> Transitioning the above extensions from private implementations into the >>> IETF is an area for future standardization. Of course, that activity will >>> depend on industry interest. >> >> I am developing a group keying solution for OSPFv3, a complementarity to RFC4552. That solution is actually an IPsec group key management one. It can also be extended to other scenarios, such as PIM-SM-v2. As for keying protocol, GSAKMP is suitable for such cases for its rich features. That may be considered as a requirement to the standardization you mentioned. >> >> Best regards, >> Liu Ya >> >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www1.ietf.org/mailman/listinfo/msec > > > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Oct 14 03:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdg3-0000BX-S8; Sat, 14 Oct 2006 03:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdg1-00006F-PU for msec@ietf.org; Sat, 14 Oct 2006 03:11:21 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYdXh-0006Fw-2l for msec@ietf.org; Sat, 14 Oct 2006 03:02:47 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7400L5G6ESVJ@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 15:06:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J740052D6ESXU@szxga01-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 15:06:28 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J74005L16TKUF@szxml04-in.huawei.com> for msec@ietf.org; Sat, 14 Oct 2006 15:15:22 +0800 (CST) Date: Sat, 14 Oct 2006 15:01:58 +0800 From: Liu Ya To: gmgietf@identaware.com Message-id: <039d01c6ef5e$a49350c0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <029601c6ef35$8b5645f0$480c6f0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: msec@ietf.org Subject: [MSEC] Re: OSPFv3 security, was Re: Is GSAKMP compatible with IPsec architecture defined in RFC4301? X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi George, Thanks for your commenting quickly. My answer is inline. > Hi Liu, > > I can see how applying MSEC IPsec to OSPF security would be a good fit for > its trust model. GSAKMP has a rich feature set, and in particular its > concept of autonomous distributed operations with sub-groups could map > easily onto OSPF areas. GSAKMP would be more fit than GDOI. But extensions must be defined before GSAKMP can be used here. > In another e-mail that you sent to MSEC, you proposed a set of GDOI > extensions that apparently handle the reliability and reachability issues > found in a group of OSPF routers. Your Internet Draft seems to have some > unstated OSPF requirements about why these GDOI extensions are needed. I > would welcome hearing from you some more background about why you suggest > that GDOI needs reliability mechanisms. In group key management protocols > developed so far, reliability mechanisms are largely delegated to a separate > protocol layer. For existing reliable rekeying methods, e.g., reliable multicast protocol, FEC encoding scheme, etc., high efficiency can be achieved when they are implemented with IP multicast. But IP multicast service is not always available in some scenarios like OSPFv3 groups. And unicast is not fit for those methods. A multicast-undependent way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to fulfil that requirement. For simplicity, it is not achieved in a separate reliable protocol layer. Best regards, Liu Ya > br, > George > > Liu Ya writes: > >> Hi George, >> >> Thanks for your answer. >> >>> Transitioning the above extensions from private implementations into the >>> IETF is an area for future standardization. Of course, that activity will >>> depend on industry interest. >> >> I am developing a group keying solution for OSPFv3, a complementarity to RFC4552. That solution is actually an IPsec group key management one. It can also be extended to other scenarios, such as PIM-SM-v2. As for keying protocol, GSAKMP is suitable for such cases for its rich features. That may be considered as a requirement to the standardization you mentioned. >> >> Best regards, >> Liu Ya >> >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www1.ietf.org/mailman/listinfo/msec > > > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Oct 16 02:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMBu-0000Bm-Ak; Mon, 16 Oct 2006 02:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMBs-00008P-V6 for msec@ietf.org; Mon, 16 Oct 2006 02:43:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZMBq-0006iH-L9 for msec@ietf.org; Mon, 16 Oct 2006 02:43:12 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9G6h8WK025778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Oct 2006 23:43:09 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-230.qualcomm.com [10.50.64.230]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9G6guqC013255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Oct 2006 23:43:03 -0700 (PDT) Message-Id: <7.0.1.0.2.20061015233610.04889558@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 15 Oct 2006 23:42:49 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [MSEC] Call for agenda items X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, We have 2 hours in San Diego. Let's discuss any pending items so we can complete the MSEC work. I suggest that we start mailing list discussions on any controversial items ASAP. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Oct 16 02:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMBu-0000Bm-Ak; Mon, 16 Oct 2006 02:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMBs-00008P-V6 for msec@ietf.org; Mon, 16 Oct 2006 02:43:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZMBq-0006iH-L9 for msec@ietf.org; Mon, 16 Oct 2006 02:43:12 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9G6h8WK025778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Oct 2006 23:43:09 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-230.qualcomm.com [10.50.64.230]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9G6guqC013255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Oct 2006 23:43:03 -0700 (PDT) Message-Id: <7.0.1.0.2.20061015233610.04889558@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 15 Oct 2006 23:42:49 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [MSEC] Call for agenda items X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, We have 2 hours in San Diego. Let's discuss any pending items so we can complete the MSEC work. I suggest that we start mailing list discussions on any controversial items ASAP. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Oct 16 08:37:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRi0-0002RD-Vd; Mon, 16 Oct 2006 08:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRhx-0002QK-8U for msec@ietf.org; Mon, 16 Oct 2006 08:36:41 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZRhu-0006A9-Vc for msec@ietf.org; Mon, 16 Oct 2006 08:36:41 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J78007OOBDMM5@szxga03-in.huawei.com> for msec@ietf.org; Mon, 16 Oct 2006 20:44:11 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7800NEIBDM1D@szxga03-in.huawei.com> for msec@ietf.org; Mon, 16 Oct 2006 20:44:10 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J780010PBGRYE@szxml04-in.huawei.com> for msec@ietf.org; Mon, 16 Oct 2006 20:46:07 +0800 (CST) Date: Mon, 16 Oct 2006 20:32:37 +0800 From: Liu Ya To: msec@ietf.org Message-id: <0a6301c6f11f$2a571c70$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbxHyoND8uJO27kSPK1Z56Sk+ibVA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, Following are some case clarifications on NEIGHBORSHIP-NOTIFY and GROUPKEY-SHARE exchanges defined in http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. For a GDOI group, a member may be shortly offline with GCKS for some reasons, such as rebooting, network route flapping, etc. During that interval, the GCKS might either create and push new rekeying messages, or do nothing. When the unlucky member is online again, it does not know what happened. For assurance, it should contact the GCKS to see whether the group SAs (including data security SA and Re-key SA) have been updated. If yes, it must initiate another two-party exchange with the GCKS to download the latest SAs. In some environments (e.g. OSPF router groups), it is usual that group members happen to be offline shortly. If the group size is large, the GCKS would have to expend much computation power and network bandwidth to deal with members' requests. For some GDOI groups like an OSPF router group, a trust and stable group membership exists. That characteristic can be utilized to alleviate GCKS's workload: Firstly, group neighborship is established. Then, whenever a group member is not sure whether its local SAs are in synchronization with GCKS, it first contacts its neighbors, not GCKS. By this method, the requests from members to GCKS decrease greatly. The neighborship can be either manually configured on group members side, or centrally managed at GCKS. If the second method is used, the neighborship is notified to the involved members using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY-SHARE, is used by group members to contact its neighbors for latest group SAs. How to establish the group neighborship is out of the doc's scope, determined by particular group policy. Any comments and questions would be appreciated. Thanks, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Oct 16 08:37:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRi0-0002RD-Vd; Mon, 16 Oct 2006 08:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRhx-0002QK-8U for msec@ietf.org; Mon, 16 Oct 2006 08:36:41 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZRhu-0006A9-Vc for msec@ietf.org; Mon, 16 Oct 2006 08:36:41 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J78007OOBDMM5@szxga03-in.huawei.com> for msec@ietf.org; Mon, 16 Oct 2006 20:44:11 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7800NEIBDM1D@szxga03-in.huawei.com> for msec@ietf.org; Mon, 16 Oct 2006 20:44:10 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J780010PBGRYE@szxml04-in.huawei.com> for msec@ietf.org; Mon, 16 Oct 2006 20:46:07 +0800 (CST) Date: Mon, 16 Oct 2006 20:32:37 +0800 From: Liu Ya To: msec@ietf.org Message-id: <0a6301c6f11f$2a571c70$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbxHyoND8uJO27kSPK1Z56Sk+ibVA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, Following are some case clarifications on NEIGHBORSHIP-NOTIFY and GROUPKEY-SHARE exchanges defined in http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. For a GDOI group, a member may be shortly offline with GCKS for some reasons, such as rebooting, network route flapping, etc. During that interval, the GCKS might either create and push new rekeying messages, or do nothing. When the unlucky member is online again, it does not know what happened. For assurance, it should contact the GCKS to see whether the group SAs (including data security SA and Re-key SA) have been updated. If yes, it must initiate another two-party exchange with the GCKS to download the latest SAs. In some environments (e.g. OSPF router groups), it is usual that group members happen to be offline shortly. If the group size is large, the GCKS would have to expend much computation power and network bandwidth to deal with members' requests. For some GDOI groups like an OSPF router group, a trust and stable group membership exists. That characteristic can be utilized to alleviate GCKS's workload: Firstly, group neighborship is established. Then, whenever a group member is not sure whether its local SAs are in synchronization with GCKS, it first contacts its neighbors, not GCKS. By this method, the requests from members to GCKS decrease greatly. The neighborship can be either manually configured on group members side, or centrally managed at GCKS. If the second method is used, the neighborship is notified to the involved members using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY-SHARE, is used by group members to contact its neighbors for latest group SAs. How to establish the group neighborship is out of the doc's scope, determined by particular group policy. Any comments and questions would be appreciated. Thanks, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Oct 16 14:43:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXR0-00044e-7Q; Mon, 16 Oct 2006 14:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXQy-00044X-Bc for msec@ietf.org; Mon, 16 Oct 2006 14:43:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXQv-0000On-SB for msec@ietf.org; Mon, 16 Oct 2006 14:43:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2006 11:43:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GIhTKW013440; Mon, 16 Oct 2006 11:43:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9GIhTAq005477; Mon, 16 Oct 2006 11:43:29 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:43:29 -0700 Received: from [192.168.0.11] ([10.21.122.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:43:28 -0700 In-Reply-To: <0a6301c6f11f$2a571c70$480c6f0a@china.huawei.com> References: <0a6301c6f11f$2a571c70$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt Date: Mon, 16 Oct 2006 11:43:26 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Oct 2006 18:43:28.0879 (UTC) FILETIME=[F8B3E7F0:01C6F152] DKIM-Signature: a=rsa-sha1; q=dns; l=3982; t=1161024209; x=1161888209; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20in=20draft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DRjCgPOmcJKlVyXjjqiaE3lw1v50=3D; b=TTTsMdvSwUDhX0VCA5HsBZ7qXG3NjrK+nwXCLpzI/oD4EA0UJKtreXYp0vezLI5+YJHhP9Qg /EY0DgcxPx2dzh/hKm/Ka047QBmbEQ/2nGDL/LNIksSTxN2e5eEyDYBs; Authentication-Results: sj-dkim-1.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Dear Liu Ya, On Oct 16, 2006, at 5:32 AM, Liu Ya wrote: > Hi all, > > Following are some case clarifications on NEIGHBORSHIP-NOTIFY and > GROUPKEY-SHARE exchanges defined in > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. I have questions about whether the current definitions (i.e. RFC 3547) don't meet your requirements. For example, do we really need a "unicast-groupkey-push" given that the current groupkey-push can be either sent either multicast or unicast? > > For a GDOI group, a member may be shortly offline with GCKS for some > reasons, such as rebooting, network route flapping, etc. During that > interval, the GCKS might either create and push new rekeying > messages, or do > nothing. When the unlucky member is online again, it does not know > what > happened. For assurance, it should contact the GCKS to see whether > the group > SAs (including data security SA and Re-key SA) have been updated. > If yes, it > must initiate another two-party exchange with the GCKS to download the > latest SAs. In some environments (e.g. OSPF router groups), it is > usual that > group members happen to be offline shortly. If the group size is > large, the > GCKS would have to expend much computation power and network > bandwidth to > deal with members' requests. Why use a centralized GCKS? I can think of cases where a central GCKS is appropriate, but maybe the OSPF router groups application is not one of those cases. In this case, I would go to a distributed GCKS model where each GDOI member runs its own GCKS (e.g. to manage the decryption keys for data that it sends and to forward other senders' decryption keys that happen to be in the cache). > > For some GDOI groups like an OSPF router group, a trust and stable > group > membership exists. That characteristic can be utilized to alleviate > GCKS's > workload: Firstly, group neighborship is established. Then, > whenever a group > member is not sure whether its local SAs are in synchronization > with GCKS, > it first contacts its neighbors, not GCKS. Why not contact the neighbor's GCKS to get the update from its cache? > By this method, the requests from > members to GCKS decrease greatly. The requests to a central GCKS would decrease greatly. What is increasing are requests made to other group members. Properly considered, each group member can and should runs a GCKS and this is what gets contacted. By this method, the requests from one member to abother's GCKS increases as requests to a central GCKS are reduced. > The neighborship can be either manually > configured on group members side, or centrally managed at GCKS. If the > second method is used, the neighborship is notified to the involved > members > using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY- > SHARE, is > used by group members to contact its neighbors for latest group > SAs. How to > establish the group neighborship is out of the doc's scope, > determined by > particular group policy. I think I understand your goal here. And I think that you need to apply RFC 3547 such that each group member has a GCKS, which can act as a server to a GCKS client or as a client to a GCKS server. I do think that you will need to describe how this would work for OSPF, but this maybe could be done as an Informational RFC, which is a very fast way to publish a standard - provided that the RFC Editor and the IESG agree with using RFC 3547 and your enhancements for OSPF router groups. Personally, I really don't know enough to say one way or the other. > > Any comments and questions would be appreciated. I hope my comments are helpful. cheers, Mark > > Thanks, > Liu Ya > > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Oct 16 14:43:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXR0-00044e-7Q; Mon, 16 Oct 2006 14:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXQy-00044X-Bc for msec@ietf.org; Mon, 16 Oct 2006 14:43:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXQv-0000On-SB for msec@ietf.org; Mon, 16 Oct 2006 14:43:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2006 11:43:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GIhTKW013440; Mon, 16 Oct 2006 11:43:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9GIhTAq005477; Mon, 16 Oct 2006 11:43:29 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:43:29 -0700 Received: from [192.168.0.11] ([10.21.122.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:43:28 -0700 In-Reply-To: <0a6301c6f11f$2a571c70$480c6f0a@china.huawei.com> References: <0a6301c6f11f$2a571c70$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt Date: Mon, 16 Oct 2006 11:43:26 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Oct 2006 18:43:28.0879 (UTC) FILETIME=[F8B3E7F0:01C6F152] DKIM-Signature: a=rsa-sha1; q=dns; l=3982; t=1161024209; x=1161888209; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20in=20draft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DRjCgPOmcJKlVyXjjqiaE3lw1v50=3D; b=TTTsMdvSwUDhX0VCA5HsBZ7qXG3NjrK+nwXCLpzI/oD4EA0UJKtreXYp0vezLI5+YJHhP9Qg /EY0DgcxPx2dzh/hKm/Ka047QBmbEQ/2nGDL/LNIksSTxN2e5eEyDYBs; Authentication-Results: sj-dkim-1.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Dear Liu Ya, On Oct 16, 2006, at 5:32 AM, Liu Ya wrote: > Hi all, > > Following are some case clarifications on NEIGHBORSHIP-NOTIFY and > GROUPKEY-SHARE exchanges defined in > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. I have questions about whether the current definitions (i.e. RFC 3547) don't meet your requirements. For example, do we really need a "unicast-groupkey-push" given that the current groupkey-push can be either sent either multicast or unicast? > > For a GDOI group, a member may be shortly offline with GCKS for some > reasons, such as rebooting, network route flapping, etc. During that > interval, the GCKS might either create and push new rekeying > messages, or do > nothing. When the unlucky member is online again, it does not know > what > happened. For assurance, it should contact the GCKS to see whether > the group > SAs (including data security SA and Re-key SA) have been updated. > If yes, it > must initiate another two-party exchange with the GCKS to download the > latest SAs. In some environments (e.g. OSPF router groups), it is > usual that > group members happen to be offline shortly. If the group size is > large, the > GCKS would have to expend much computation power and network > bandwidth to > deal with members' requests. Why use a centralized GCKS? I can think of cases where a central GCKS is appropriate, but maybe the OSPF router groups application is not one of those cases. In this case, I would go to a distributed GCKS model where each GDOI member runs its own GCKS (e.g. to manage the decryption keys for data that it sends and to forward other senders' decryption keys that happen to be in the cache). > > For some GDOI groups like an OSPF router group, a trust and stable > group > membership exists. That characteristic can be utilized to alleviate > GCKS's > workload: Firstly, group neighborship is established. Then, > whenever a group > member is not sure whether its local SAs are in synchronization > with GCKS, > it first contacts its neighbors, not GCKS. Why not contact the neighbor's GCKS to get the update from its cache? > By this method, the requests from > members to GCKS decrease greatly. The requests to a central GCKS would decrease greatly. What is increasing are requests made to other group members. Properly considered, each group member can and should runs a GCKS and this is what gets contacted. By this method, the requests from one member to abother's GCKS increases as requests to a central GCKS are reduced. > The neighborship can be either manually > configured on group members side, or centrally managed at GCKS. If the > second method is used, the neighborship is notified to the involved > members > using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY- > SHARE, is > used by group members to contact its neighbors for latest group > SAs. How to > establish the group neighborship is out of the doc's scope, > determined by > particular group policy. I think I understand your goal here. And I think that you need to apply RFC 3547 such that each group member has a GCKS, which can act as a server to a GCKS client or as a client to a GCKS server. I do think that you will need to describe how this would work for OSPF, but this maybe could be done as an Informational RFC, which is a very fast way to publish a standard - provided that the RFC Editor and the IESG agree with using RFC 3547 and your enhancements for OSPF router groups. Personally, I really don't know enough to say one way or the other. > > Any comments and questions would be appreciated. I hope my comments are helpful. cheers, Mark > > Thanks, > Liu Ya > > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 01:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZh6q-0001u0-60; Tue, 17 Oct 2006 01:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZh6o-0001lr-Np for msec@ietf.org; Tue, 17 Oct 2006 01:03:22 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZh6n-0001YG-5s for msec@ietf.org; Tue, 17 Oct 2006 01:03:22 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900A84LA1LK@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 13:15:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900JO0LA0C5@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 13:15:37 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7900974KZX93@szxml04-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 13:09:36 +0800 (CST) Date: Tue, 17 Oct 2006 12:56:07 +0800 From: Liu Ya Subject: RE: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt In-reply-to: To: 'Mark Baugher' , msec@ietf.org Message-id: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbxUv9UmuOfYGVCS8yyBR6gvHoloQANeY+Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, My answer is inline. > > Following are some case clarifications on NEIGHBORSHIP-NOTIFY and > > GROUPKEY-SHARE exchanges defined in > > > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. > > I have questions about whether the current definitions (i.e. RFC > 3547) don't meet your requirements. For example, do we > really need a > "unicast-groupkey-push" given that the current groupkey-push can be > either sent either multicast or unicast? The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably deliver keying messages over unicast channel. It is different from unicast GROUPKEY-PUSH, which must be used with additional reliable transport technology (e.g. FEC encoding) to achieve reliable rekeying. I explained the requirement of UNICAST-GROUPKEY-PUSH in another e-mail to George as follows: For existing reliable rekeying methods, e.g., reliable multicast protocol, FEC encoding scheme, etc., high efficiency can be achieved when they are implemented over IP multicast. But IP multicast service is not always available. And unicast is not fit for above methods. A multicast-undependent way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to fulfil that requirement. > > > > For a GDOI group, a member may be shortly offline with GCKS for some > > reasons, such as rebooting, network route flapping, etc. During that > > interval, the GCKS might either create and push new rekeying > > messages, or do > > nothing. When the unlucky member is online again, it does not know > > what > > happened. For assurance, it should contact the GCKS to see whether > > the group > > SAs (including data security SA and Re-key SA) have been updated. > > If yes, it > > must initiate another two-party exchange with the GCKS to > download the > > latest SAs. In some environments (e.g. OSPF router groups), it is > > usual that > > group members happen to be offline shortly. If the group size is > > large, the > > GCKS would have to expend much computation power and network > > bandwidth to > > deal with members' requests. > > Why use a centralized GCKS? I can think of cases where a central > GCKS is appropriate, but maybe the OSPF router groups application is > not one of those cases. In this case, I would go to a distributed > GCKS model where each GDOI member runs its own GCKS (e.g. to manage > the decryption keys for data that it sends and to forward other > senders' decryption keys that happen to be in the cache). Distributed GCKS is fine. It is necessary for large GDOI groups, e.g. large-scale OSPF ASes with thousands of routers. I imagine two deployment models as fowllows: +----------+ | GCKS | +----------+ ^ | OOB communication mechanism V +---------------------+-------------------+ | | | V V V +-------------+ +------------+ +------------+ | Delegate | | Delegate| | Delegate| +-------------+ +------------+ +------------+ | V GROUPKEY-PULL or GROUPKEY-PUSH +---------------------+-------------------+ | | | V V V +------------+ +------------+ +------------+ | Member | | Member | | Member | +------------+ +------------+ +------------+ or OOB communication mechanism +---------------------+-------------------+ | | | V V V +-------------+ +------------+ +------------+ | S-GCKS | | M-GCKS| | S-GCKS | +-------------+ +------------+ +------------+ | V GROUPKEY-PULL or GROUPKEY-PUSH +---------------------+-------------------+ | | | V V V +------------+ +------------+ +------------+ | Member | | Member | | Member | +------------+ +------------+ +------------+ Here the prefix 'M-' indicates master, and 'S-' indicates subordinate. In both forms above, the group root key must be managed centrally. And some out-of-band mechanisms must be defined to transport that key, and other information, between GCKSes, or between GCKS and Delegates. Obviously, the system is complicated in above models. And side effects (e.g. larger rekeying delay) exist. For large groups, distributed control model would be the only standby choice. While for cases of medium scale groups, one centralized GCKS would be enough for group keying purpose if measures are taken to reduce GCKS's workload. Sharing keying messages between group members is just an examplle of that measure. It is deployed as follows: +----------+ | GCKS | +----------+ ^ | GROUPKEY-PULL or GROUPKEY-PUSH V +------------------------------------------------------+ | | V V +------------+ +------------+ | Member | <----GROUPKEY-SHARE----> | Member | +------------+ +------------+ This technique can also be used in distributed control model to reduce delegate workload, thus decreasing the number of delegates. > > > > For some GDOI groups like an OSPF router group, a trust and stable > > group > > membership exists. That characteristic can be utilized to > alleviate > > GCKS's > > workload: Firstly, group neighborship is established. Then, > > whenever a group > > member is not sure whether its local SAs are in synchronization > > with GCKS, > > it first contacts its neighbors, not GCKS. > > Why not contact the neighbor's GCKS to get the update from its cache? > > > By this method, the requests from > > members to GCKS decrease greatly. > > The requests to a central GCKS would decrease greatly. What is > increasing are requests made to other group members. Properly > considered, each group member can and should runs a GCKS and this is > what gets contacted. By this method, the requests from one > member to > abother's GCKS increases as requests to a central GCKS are reduced. > The performance bottleneck of group keying is in GCKS, not group members. The GROUPKEY-SHARE exchange alliviates GCKS workload by apportioning it to group members. KEKs and TEK are still centrally managed on GCKS. Keying messages also originate from GCKS. What a group member needs to do is to cache the rekeying messages and send them to requesters. It does not play the real GCKS role. > > The neighborship can be either manually > > configured on group members side, or centrally managed at > GCKS. If the > > second method is used, the neighborship is notified to the > involved > > members > > using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY- > > SHARE, is > > used by group members to contact its neighbors for latest group > > SAs. How to > > establish the group neighborship is out of the doc's scope, > > determined by > > particular group policy. > > I think I understand your goal here. And I think that you need to > apply RFC 3547 such that each group member has a GCKS, which can act > as a server to a GCKS client or as a client to a GCKS server. I do > think that you will need to describe how this would work for OSPF, > but this maybe could be done as an Informational RFC, which > is a very > fast way to publish a standard - provided that the RFC Editor > and the > IESG agree with using RFC 3547 and your enhancements for OSPF router > groups. Personally, I really don't know enough to say one > way or the > other. > > > > Any comments and questions would be appreciated. > > I hope my comments are helpful. Certainly, your comments are helpful to me. Best regards, Liu Ya > > cheers, Mark > > > > Thanks, > > Liu Ya > > > > > > > > _______________________________________________ > > MSEC mailing list > > MSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 01:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZh6q-0001u0-60; Tue, 17 Oct 2006 01:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZh6o-0001lr-Np for msec@ietf.org; Tue, 17 Oct 2006 01:03:22 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZh6n-0001YG-5s for msec@ietf.org; Tue, 17 Oct 2006 01:03:22 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900A84LA1LK@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 13:15:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900JO0LA0C5@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 13:15:37 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7900974KZX93@szxml04-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 13:09:36 +0800 (CST) Date: Tue, 17 Oct 2006 12:56:07 +0800 From: Liu Ya Subject: RE: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt In-reply-to: To: 'Mark Baugher' , msec@ietf.org Message-id: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbxUv9UmuOfYGVCS8yyBR6gvHoloQANeY+Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, My answer is inline. > > Following are some case clarifications on NEIGHBORSHIP-NOTIFY and > > GROUPKEY-SHARE exchanges defined in > > > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. > > I have questions about whether the current definitions (i.e. RFC > 3547) don't meet your requirements. For example, do we > really need a > "unicast-groupkey-push" given that the current groupkey-push can be > either sent either multicast or unicast? The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably deliver keying messages over unicast channel. It is different from unicast GROUPKEY-PUSH, which must be used with additional reliable transport technology (e.g. FEC encoding) to achieve reliable rekeying. I explained the requirement of UNICAST-GROUPKEY-PUSH in another e-mail to George as follows: For existing reliable rekeying methods, e.g., reliable multicast protocol, FEC encoding scheme, etc., high efficiency can be achieved when they are implemented over IP multicast. But IP multicast service is not always available. And unicast is not fit for above methods. A multicast-undependent way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to fulfil that requirement. > > > > For a GDOI group, a member may be shortly offline with GCKS for some > > reasons, such as rebooting, network route flapping, etc. During that > > interval, the GCKS might either create and push new rekeying > > messages, or do > > nothing. When the unlucky member is online again, it does not know > > what > > happened. For assurance, it should contact the GCKS to see whether > > the group > > SAs (including data security SA and Re-key SA) have been updated. > > If yes, it > > must initiate another two-party exchange with the GCKS to > download the > > latest SAs. In some environments (e.g. OSPF router groups), it is > > usual that > > group members happen to be offline shortly. If the group size is > > large, the > > GCKS would have to expend much computation power and network > > bandwidth to > > deal with members' requests. > > Why use a centralized GCKS? I can think of cases where a central > GCKS is appropriate, but maybe the OSPF router groups application is > not one of those cases. In this case, I would go to a distributed > GCKS model where each GDOI member runs its own GCKS (e.g. to manage > the decryption keys for data that it sends and to forward other > senders' decryption keys that happen to be in the cache). Distributed GCKS is fine. It is necessary for large GDOI groups, e.g. large-scale OSPF ASes with thousands of routers. I imagine two deployment models as fowllows: +----------+ | GCKS | +----------+ ^ | OOB communication mechanism V +---------------------+-------------------+ | | | V V V +-------------+ +------------+ +------------+ | Delegate | | Delegate| | Delegate| +-------------+ +------------+ +------------+ | V GROUPKEY-PULL or GROUPKEY-PUSH +---------------------+-------------------+ | | | V V V +------------+ +------------+ +------------+ | Member | | Member | | Member | +------------+ +------------+ +------------+ or OOB communication mechanism +---------------------+-------------------+ | | | V V V +-------------+ +------------+ +------------+ | S-GCKS | | M-GCKS| | S-GCKS | +-------------+ +------------+ +------------+ | V GROUPKEY-PULL or GROUPKEY-PUSH +---------------------+-------------------+ | | | V V V +------------+ +------------+ +------------+ | Member | | Member | | Member | +------------+ +------------+ +------------+ Here the prefix 'M-' indicates master, and 'S-' indicates subordinate. In both forms above, the group root key must be managed centrally. And some out-of-band mechanisms must be defined to transport that key, and other information, between GCKSes, or between GCKS and Delegates. Obviously, the system is complicated in above models. And side effects (e.g. larger rekeying delay) exist. For large groups, distributed control model would be the only standby choice. While for cases of medium scale groups, one centralized GCKS would be enough for group keying purpose if measures are taken to reduce GCKS's workload. Sharing keying messages between group members is just an examplle of that measure. It is deployed as follows: +----------+ | GCKS | +----------+ ^ | GROUPKEY-PULL or GROUPKEY-PUSH V +------------------------------------------------------+ | | V V +------------+ +------------+ | Member | <----GROUPKEY-SHARE----> | Member | +------------+ +------------+ This technique can also be used in distributed control model to reduce delegate workload, thus decreasing the number of delegates. > > > > For some GDOI groups like an OSPF router group, a trust and stable > > group > > membership exists. That characteristic can be utilized to > alleviate > > GCKS's > > workload: Firstly, group neighborship is established. Then, > > whenever a group > > member is not sure whether its local SAs are in synchronization > > with GCKS, > > it first contacts its neighbors, not GCKS. > > Why not contact the neighbor's GCKS to get the update from its cache? > > > By this method, the requests from > > members to GCKS decrease greatly. > > The requests to a central GCKS would decrease greatly. What is > increasing are requests made to other group members. Properly > considered, each group member can and should runs a GCKS and this is > what gets contacted. By this method, the requests from one > member to > abother's GCKS increases as requests to a central GCKS are reduced. > The performance bottleneck of group keying is in GCKS, not group members. The GROUPKEY-SHARE exchange alliviates GCKS workload by apportioning it to group members. KEKs and TEK are still centrally managed on GCKS. Keying messages also originate from GCKS. What a group member needs to do is to cache the rekeying messages and send them to requesters. It does not play the real GCKS role. > > The neighborship can be either manually > > configured on group members side, or centrally managed at > GCKS. If the > > second method is used, the neighborship is notified to the > involved > > members > > using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY- > > SHARE, is > > used by group members to contact its neighbors for latest group > > SAs. How to > > establish the group neighborship is out of the doc's scope, > > determined by > > particular group policy. > > I think I understand your goal here. And I think that you need to > apply RFC 3547 such that each group member has a GCKS, which can act > as a server to a GCKS client or as a client to a GCKS server. I do > think that you will need to describe how this would work for OSPF, > but this maybe could be done as an Informational RFC, which > is a very > fast way to publish a standard - provided that the RFC Editor > and the > IESG agree with using RFC 3547 and your enhancements for OSPF router > groups. Personally, I really don't know enough to say one > way or the > other. > > > > Any comments and questions would be appreciated. > > I hope my comments are helpful. Certainly, your comments are helpful to me. Best regards, Liu Ya > > cheers, Mark > > > > Thanks, > > Liu Ya > > > > > > > > _______________________________________________ > > MSEC mailing list > > MSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 04:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZk0G-0001md-J5; Tue, 17 Oct 2006 04:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZk0E-0001hk-T3 for msec@ietf.org; Tue, 17 Oct 2006 04:08:46 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZk0C-0002aT-BH for msec@ietf.org; Tue, 17 Oct 2006 04:08:46 -0400 Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k9H88552014038; Tue, 17 Oct 2006 10:08:05 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k9H885pD027618; Tue, 17 Oct 2006 10:08:06 +0200 (MEST) Message-ID: <45348F65.7020404@inrialpes.fr> Date: Tue, 17 Oct 2006 10:08:05 +0200 From: Vincent Roca User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Liu Ya Subject: Re: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt References: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> In-Reply-To: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 17 Oct 2006 10:08:06 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hello Liu, >> I have questions about whether the current definitions (i.e. RFC >> 3547) don't meet your requirements. For example, do we >> really need a >> "unicast-groupkey-push" given that the current groupkey-push can be >> either sent either multicast or unicast? >> > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably deliver > keying messages over unicast channel. It is different from unicast > GROUPKEY-PUSH, which must be used with additional reliable transport > technology (e.g. FEC encoding) to achieve reliable rekeying. I explained > the requirement of UNICAST-GROUPKEY-PUSH in another e-mail to George as > follows: > > For existing reliable rekeying methods, e.g., reliable multicast protocol, > FEC encoding scheme, etc., high efficiency can be achieved when they are > implemented over IP multicast. But IP multicast service is not always > available. And unicast is not fit for above methods. A multicast-undependent > way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to > fulfil that requirement. > Just one small remark: reliable multicast protocols (either NORM or ALC) and the associated FEC encoding schemes (usually embedded in the above protocols) are not limited to multicast-enabled networks. Using ALC or NORM for point-to-point communications (or any flavor of application-level multicast based on underlying unicast transmissions) is fine as well. For instance, with ALC you can have a periodic delivery of the content to the single receiver with a very limited additional complexity. And if it turns there are many receivers, you won't have to change the specifications. Yet I admit that using NORM for point-to-point communications would add a significant complexity for a very small benefit (if any!). That's perhaps what you meant? Having said that, there are perhaps other features (that I don't know) in your target use case that make the above protocols undesirable. Cheers, Vincent _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 04:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZk0G-0001md-J5; Tue, 17 Oct 2006 04:08:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZk0E-0001hk-T3 for msec@ietf.org; Tue, 17 Oct 2006 04:08:46 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZk0C-0002aT-BH for msec@ietf.org; Tue, 17 Oct 2006 04:08:46 -0400 Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k9H88552014038; Tue, 17 Oct 2006 10:08:05 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k9H885pD027618; Tue, 17 Oct 2006 10:08:06 +0200 (MEST) Message-ID: <45348F65.7020404@inrialpes.fr> Date: Tue, 17 Oct 2006 10:08:05 +0200 From: Vincent Roca User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Liu Ya Subject: Re: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt References: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> In-Reply-To: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 17 Oct 2006 10:08:06 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hello Liu, >> I have questions about whether the current definitions (i.e. RFC >> 3547) don't meet your requirements. For example, do we >> really need a >> "unicast-groupkey-push" given that the current groupkey-push can be >> either sent either multicast or unicast? >> > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably deliver > keying messages over unicast channel. It is different from unicast > GROUPKEY-PUSH, which must be used with additional reliable transport > technology (e.g. FEC encoding) to achieve reliable rekeying. I explained > the requirement of UNICAST-GROUPKEY-PUSH in another e-mail to George as > follows: > > For existing reliable rekeying methods, e.g., reliable multicast protocol, > FEC encoding scheme, etc., high efficiency can be achieved when they are > implemented over IP multicast. But IP multicast service is not always > available. And unicast is not fit for above methods. A multicast-undependent > way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to > fulfil that requirement. > Just one small remark: reliable multicast protocols (either NORM or ALC) and the associated FEC encoding schemes (usually embedded in the above protocols) are not limited to multicast-enabled networks. Using ALC or NORM for point-to-point communications (or any flavor of application-level multicast based on underlying unicast transmissions) is fine as well. For instance, with ALC you can have a periodic delivery of the content to the single receiver with a very limited additional complexity. And if it turns there are many receivers, you won't have to change the specifications. Yet I admit that using NORM for point-to-point communications would add a significant complexity for a very small benefit (if any!). That's perhaps what you meant? Having said that, there are perhaps other features (that I don't know) in your target use case that make the above protocols undesirable. Cheers, Vincent _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 05:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZktN-0006nr-JB; Tue, 17 Oct 2006 05:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZktL-0006nB-TP for msec@ietf.org; Tue, 17 Oct 2006 05:05:43 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZktK-0006fb-20 for msec@ietf.org; Tue, 17 Oct 2006 05:05:43 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900DSZWPVRA@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 17:22:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900MK3WPUFG@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 17:22:43 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7900AH4W3K7Q@szxml03-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 17:09:23 +0800 (CST) Date: Tue, 17 Oct 2006 17:03:14 +0800 From: Liu Ya Subject: RE: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt In-reply-to: <45348F65.7020404@inrialpes.fr> To: 'Vincent Roca' , msec@ietf.org Message-id: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbxw2tvtpRxFHy7QI2/FL+QbErsKAAB5vew X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Vincent, There is difference in our understanding of "unavailability of IP multicast service". Yes, higher level multicast services (e.g. IP multicast and application-level multicast) are not limmited to lower level multicast-enabled networks. But they are unnecessarily deployed. GDOI runs on top of UDP. Availability of IP multicast service is the pre-condition of running reliable multicast protocols such as NORTM and ALC. However, IP multicast is seldom deployed in real networks. Regards, Liu Ya > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Tuesday, October 17, 2006 4:08 PM > To: Liu Ya > Cc: 'Mark Baugher'; msec@ietf.org > Subject: Re: [MSEC] Case clarifications on group neighborship > defined indraft-liu-gdoi-extensions-00.txt > > Hello Liu, > > >> I have questions about whether the current definitions (i.e. RFC > >> 3547) don't meet your requirements. For example, do we > >> really need a > >> "unicast-groupkey-push" given that the current > groupkey-push can be > >> either sent either multicast or unicast? > >> > > > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to > reliably deliver > > keying messages over unicast channel. It is different from unicast > > GROUPKEY-PUSH, which must be used with additional reliable transport > > technology (e.g. FEC encoding) to achieve reliable > rekeying. I explained > > the requirement of UNICAST-GROUPKEY-PUSH in another e-mail > to George as > > follows: > > > > For existing reliable rekeying methods, e.g., reliable > multicast protocol, > > FEC encoding scheme, etc., high efficiency can be achieved > when they are > > implemented over IP multicast. But IP multicast service is > not always > > available. And unicast is not fit for above methods. A > multicast-undependent > > way of reliable rekeying is needed. The > UNICAST-GROUPKEY-PUSH exchange is to > > fulfil that requirement. > > > > Just one small remark: reliable multicast protocols (either > NORM or ALC) and > the associated FEC encoding schemes (usually embedded in the above > protocols) > are not limited to multicast-enabled networks. Using ALC or NORM for > point-to-point communications (or any flavor of application-level > multicast based > on underlying unicast transmissions) is fine as well. For > instance, with > ALC you > can have a periodic delivery of the content to the single > receiver with > a very limited > additional complexity. And if it turns there are many receivers, you > won't have > to change the specifications. > Yet I admit that using NORM for point-to-point communications > would add > a significant complexity for a very small benefit (if any!). That's > perhaps what > you meant? > Having said that, there are perhaps other features (that I > don't know) > in your target > use case that make the above protocols undesirable. > > Cheers, > > Vincent > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 05:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZktN-0006nr-JB; Tue, 17 Oct 2006 05:05:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZktL-0006nB-TP for msec@ietf.org; Tue, 17 Oct 2006 05:05:43 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZktK-0006fb-20 for msec@ietf.org; Tue, 17 Oct 2006 05:05:43 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900DSZWPVRA@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 17:22:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7900MK3WPUFG@szxga02-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 17:22:43 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7900AH4W3K7Q@szxml03-in.huawei.com> for msec@ietf.org; Tue, 17 Oct 2006 17:09:23 +0800 (CST) Date: Tue, 17 Oct 2006 17:03:14 +0800 From: Liu Ya Subject: RE: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt In-reply-to: <45348F65.7020404@inrialpes.fr> To: 'Vincent Roca' , msec@ietf.org Message-id: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbxw2tvtpRxFHy7QI2/FL+QbErsKAAB5vew X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Vincent, There is difference in our understanding of "unavailability of IP multicast service". Yes, higher level multicast services (e.g. IP multicast and application-level multicast) are not limmited to lower level multicast-enabled networks. But they are unnecessarily deployed. GDOI runs on top of UDP. Availability of IP multicast service is the pre-condition of running reliable multicast protocols such as NORTM and ALC. However, IP multicast is seldom deployed in real networks. Regards, Liu Ya > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Tuesday, October 17, 2006 4:08 PM > To: Liu Ya > Cc: 'Mark Baugher'; msec@ietf.org > Subject: Re: [MSEC] Case clarifications on group neighborship > defined indraft-liu-gdoi-extensions-00.txt > > Hello Liu, > > >> I have questions about whether the current definitions (i.e. RFC > >> 3547) don't meet your requirements. For example, do we > >> really need a > >> "unicast-groupkey-push" given that the current > groupkey-push can be > >> either sent either multicast or unicast? > >> > > > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to > reliably deliver > > keying messages over unicast channel. It is different from unicast > > GROUPKEY-PUSH, which must be used with additional reliable transport > > technology (e.g. FEC encoding) to achieve reliable > rekeying. I explained > > the requirement of UNICAST-GROUPKEY-PUSH in another e-mail > to George as > > follows: > > > > For existing reliable rekeying methods, e.g., reliable > multicast protocol, > > FEC encoding scheme, etc., high efficiency can be achieved > when they are > > implemented over IP multicast. But IP multicast service is > not always > > available. And unicast is not fit for above methods. A > multicast-undependent > > way of reliable rekeying is needed. The > UNICAST-GROUPKEY-PUSH exchange is to > > fulfil that requirement. > > > > Just one small remark: reliable multicast protocols (either > NORM or ALC) and > the associated FEC encoding schemes (usually embedded in the above > protocols) > are not limited to multicast-enabled networks. Using ALC or NORM for > point-to-point communications (or any flavor of application-level > multicast based > on underlying unicast transmissions) is fine as well. For > instance, with > ALC you > can have a periodic delivery of the content to the single > receiver with > a very limited > additional complexity. And if it turns there are many receivers, you > won't have > to change the specifications. > Yet I admit that using NORM for point-to-point communications > would add > a significant complexity for a very small benefit (if any!). That's > perhaps what > you meant? > Having said that, there are perhaps other features (that I > don't know) > in your target > use case that make the above protocols undesirable. > > Cheers, > > Vincent > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 05:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlTm-0008Fp-Bn; Tue, 17 Oct 2006 05:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlTl-0008Fk-Iv for msec@ietf.org; Tue, 17 Oct 2006 05:43:21 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlTk-0005qz-4n for msec@ietf.org; Tue, 17 Oct 2006 05:43:21 -0400 Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k9H9gvc9000671; Tue, 17 Oct 2006 11:42:57 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k9H9gv57005434; Tue, 17 Oct 2006 11:42:58 +0200 (MEST) Message-ID: <4534A5A1.9070708@inrialpes.fr> Date: Tue, 17 Oct 2006 11:42:57 +0200 From: Vincent Roca User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Liu Ya Subject: Re: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt References: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> In-Reply-To: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 17 Oct 2006 11:42:57 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hello Liu, > There is difference in our understanding of "unavailability of IP multicast > service". Yes, higher level multicast services (e.g. IP multicast and > application-level multicast) are not limmited to lower level > multicast-enabled networks. But they are unnecessarily deployed. GDOI runs > on top of UDP. Availability of IP multicast service is the pre-condition of > running reliable multicast protocols such as NORTM and ALC. However, IP > multicast is seldom deployed in real networks. > As a FLUTE/ALC and NORM developper (http://planete-bcast.inrialpes.fr), I can promise you that our implementation (and the same is true for that of Univ. of Tempere) supports both unicast or multicast services (whether they are emulated at application level or rely on native multicast routing). Specifying a unicast destination address is not a problem at all. Having purely unidirectional physical networks is not a problem either with ALC (but is an issue with NORM). What I mean is that we have a lot of flexibility here, and that's the reason why ALC is used in many different use cases, from Internet communications (with/without multicast routing), satellite based networks, and DVB-H (and similar) broadcasting networks. But I don't know the GDOI use case, and cannot answer if in that particular use case, it makes sense or not to use one of the reliable multicast protocols in all situations, in particular when there's a single destination. Hope it clarifies my previous email. Cheers, Vincent _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 05:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlTm-0008Fp-Bn; Tue, 17 Oct 2006 05:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlTl-0008Fk-Iv for msec@ietf.org; Tue, 17 Oct 2006 05:43:21 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlTk-0005qz-4n for msec@ietf.org; Tue, 17 Oct 2006 05:43:21 -0400 Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k9H9gvc9000671; Tue, 17 Oct 2006 11:42:57 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k9H9gv57005434; Tue, 17 Oct 2006 11:42:58 +0200 (MEST) Message-ID: <4534A5A1.9070708@inrialpes.fr> Date: Tue, 17 Oct 2006 11:42:57 +0200 From: Vincent Roca User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Liu Ya Subject: Re: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt References: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> In-Reply-To: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 17 Oct 2006 11:42:57 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hello Liu, > There is difference in our understanding of "unavailability of IP multicast > service". Yes, higher level multicast services (e.g. IP multicast and > application-level multicast) are not limmited to lower level > multicast-enabled networks. But they are unnecessarily deployed. GDOI runs > on top of UDP. Availability of IP multicast service is the pre-condition of > running reliable multicast protocols such as NORTM and ALC. However, IP > multicast is seldom deployed in real networks. > As a FLUTE/ALC and NORM developper (http://planete-bcast.inrialpes.fr), I can promise you that our implementation (and the same is true for that of Univ. of Tempere) supports both unicast or multicast services (whether they are emulated at application level or rely on native multicast routing). Specifying a unicast destination address is not a problem at all. Having purely unidirectional physical networks is not a problem either with ALC (but is an issue with NORM). What I mean is that we have a lot of flexibility here, and that's the reason why ALC is used in many different use cases, from Internet communications (with/without multicast routing), satellite based networks, and DVB-H (and similar) broadcasting networks. But I don't know the GDOI use case, and cannot answer if in that particular use case, it makes sense or not to use one of the reliable multicast protocols in all situations, in particular when there's a single destination. Hope it clarifies my previous email. Cheers, Vincent _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 06:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmFk-0000TY-0N; Tue, 17 Oct 2006 06:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmFi-0000Rv-R4 for msec@ietf.org; Tue, 17 Oct 2006 06:32:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZm76-0004eJ-7r for msec@ietf.org; Tue, 17 Oct 2006 06:24:01 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HANweE006296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Oct 2006 03:23:59 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-114.qualcomm.com [10.50.64.114]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HANp2X017483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Oct 2006 03:23:56 -0700 (PDT) Message-Id: <7.0.1.0.2.20061017032206.0491a958@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 17 Oct 2006 03:23:45 -0700 To: msec@ietf.org From: Lakshminath Dondeti Subject: Re: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE In-Reply-To: <7.0.1.0.2.20060921094125.07886cc0@qualcomm.com> References: <7.0.1.0.2.20060921094125.07886cc0@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, We have finished the LC with no comments. That is not a good thing. I will solicit some reviews privately. Meanwhile, I encourage everyone to read the document and send a review to the list. thanks, Lakshminath At 09:51 AM 9/21/2006, Lakshminath Dondeti wrote: >Folks, > >Steffen and Dragan inform me that the draft "On the applicability of >various MIKEY modes and extensions" >(draft-ietf-msec-mikey-applicability-02.txt) is now complete and >requested a WGLC. > >Please review and send comments to the MSEC list before Oct 6, 2006 >AOE. We would like to know whether the document is ready or not >ready, whether there are any gaps that you would like to see covered. > >Thank you. > >Lakshminath > > >_______________________________________________ >MSEC mailing list >MSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 06:33:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmFk-0000TY-0N; Tue, 17 Oct 2006 06:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmFi-0000Rv-R4 for msec@ietf.org; Tue, 17 Oct 2006 06:32:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZm76-0004eJ-7r for msec@ietf.org; Tue, 17 Oct 2006 06:24:01 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HANweE006296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Oct 2006 03:23:59 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-114.qualcomm.com [10.50.64.114]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HANp2X017483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Oct 2006 03:23:56 -0700 (PDT) Message-Id: <7.0.1.0.2.20061017032206.0491a958@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 17 Oct 2006 03:23:45 -0700 To: msec@ietf.org From: Lakshminath Dondeti Subject: Re: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE In-Reply-To: <7.0.1.0.2.20060921094125.07886cc0@qualcomm.com> References: <7.0.1.0.2.20060921094125.07886cc0@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, We have finished the LC with no comments. That is not a good thing. I will solicit some reviews privately. Meanwhile, I encourage everyone to read the document and send a review to the list. thanks, Lakshminath At 09:51 AM 9/21/2006, Lakshminath Dondeti wrote: >Folks, > >Steffen and Dragan inform me that the draft "On the applicability of >various MIKEY modes and extensions" >(draft-ietf-msec-mikey-applicability-02.txt) is now complete and >requested a WGLC. > >Please review and send comments to the MSEC list before Oct 6, 2006 >AOE. We would like to know whether the document is ready or not >ready, whether there are any gaps that you would like to see covered. > >Thank you. > >Lakshminath > > >_______________________________________________ >MSEC mailing list >MSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 10:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUb-00006B-M6; Tue, 17 Oct 2006 10:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUa-0008W3-9d for msec@ietf.org; Tue, 17 Oct 2006 10:00:28 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpNG-0002Ld-48 for msec@ietf.org; Tue, 17 Oct 2006 09:52:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2006 06:52:54 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HDqroG004834; Tue, 17 Oct 2006 06:52:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HDqrW4011385; Tue, 17 Oct 2006 06:52:53 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 06:52:52 -0700 Received: from [192.168.0.10] ([10.21.121.137]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 06:52:52 -0700 In-Reply-To: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> References: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt Date: Tue, 17 Oct 2006 06:52:48 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Oct 2006 13:52:52.0692 (UTC) FILETIME=[8A56A940:01C6F1F3] DKIM-Signature: a=rsa-sha1; q=dns; l=3486; t=1161093173; x=1161957173; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20indraft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DfjE1nsnNyysTJxV1fAeadSBmjGM=3D; b=HrPqwjGi96UZ8FrCpgyOULpB5nn9XJFRg2AZ1PSNkrW9eQZ2MqKJbEUNo3tbXwe0TNZStJ88 m0fccWfSHireOW9KiairaURpnltLEw8Y5aoDSkbqGXLMgloDp4DG6kDo; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Liu Ya, On Oct 17, 2006, at 2:03 AM, Liu Ya wrote: > Hi Vincent, > > There is difference in our understanding of "unavailability of IP > multicast > service". Yes, higher level multicast services (e.g. IP multicast and > application-level multicast) are not limmited to lower level > multicast-enabled networks. But they are unnecessarily deployed. > GDOI runs > on top of UDP. GDOI could also run on TCP if one were to define this behavior. Please bear in mind that RFC 3547 is based on RFC 2408, ISAKMP, which is designed to run over a sockets interface, not just UDP. cheers, Mark > Availability of IP multicast service is the pre-condition of > running reliable multicast protocols such as NORTM and ALC. > However, IP > multicast is seldom deployed in real networks. > > Regards, > Liu Ya > >> -----Original Message----- >> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >> Sent: Tuesday, October 17, 2006 4:08 PM >> To: Liu Ya >> Cc: 'Mark Baugher'; msec@ietf.org >> Subject: Re: [MSEC] Case clarifications on group neighborship >> defined indraft-liu-gdoi-extensions-00.txt >> >> Hello Liu, >> >>>> I have questions about whether the current definitions (i.e. RFC >>>> 3547) don't meet your requirements. For example, do we >>>> really need a >>>> "unicast-groupkey-push" given that the current >> groupkey-push can be >>>> either sent either multicast or unicast? >>>> >>> >>> The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to >> reliably deliver >>> keying messages over unicast channel. It is different from unicast >>> GROUPKEY-PUSH, which must be used with additional reliable transport >>> technology (e.g. FEC encoding) to achieve reliable >> rekeying. I explained >>> the requirement of UNICAST-GROUPKEY-PUSH in another e-mail >> to George as >>> follows: >>> >>> For existing reliable rekeying methods, e.g., reliable >> multicast protocol, >>> FEC encoding scheme, etc., high efficiency can be achieved >> when they are >>> implemented over IP multicast. But IP multicast service is >> not always >>> available. And unicast is not fit for above methods. A >> multicast-undependent >>> way of reliable rekeying is needed. The >> UNICAST-GROUPKEY-PUSH exchange is to >>> fulfil that requirement. >>> >> >> Just one small remark: reliable multicast protocols (either >> NORM or ALC) and >> the associated FEC encoding schemes (usually embedded in the above >> protocols) >> are not limited to multicast-enabled networks. Using ALC or NORM for >> point-to-point communications (or any flavor of application-level >> multicast based >> on underlying unicast transmissions) is fine as well. For >> instance, with >> ALC you >> can have a periodic delivery of the content to the single >> receiver with >> a very limited >> additional complexity. And if it turns there are many receivers, you >> won't have >> to change the specifications. >> Yet I admit that using NORM for point-to-point communications >> would add >> a significant complexity for a very small benefit (if any!). That's >> perhaps what >> you meant? >> Having said that, there are perhaps other features (that I >> don't know) >> in your target >> use case that make the above protocols undesirable. >> >> Cheers, >> >> Vincent >> > > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 10:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUb-00006B-M6; Tue, 17 Oct 2006 10:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUa-0008W3-9d for msec@ietf.org; Tue, 17 Oct 2006 10:00:28 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpNG-0002Ld-48 for msec@ietf.org; Tue, 17 Oct 2006 09:52:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2006 06:52:54 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HDqroG004834; Tue, 17 Oct 2006 06:52:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HDqrW4011385; Tue, 17 Oct 2006 06:52:53 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 06:52:52 -0700 Received: from [192.168.0.10] ([10.21.121.137]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 06:52:52 -0700 In-Reply-To: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> References: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt Date: Tue, 17 Oct 2006 06:52:48 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Oct 2006 13:52:52.0692 (UTC) FILETIME=[8A56A940:01C6F1F3] DKIM-Signature: a=rsa-sha1; q=dns; l=3486; t=1161093173; x=1161957173; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20indraft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DfjE1nsnNyysTJxV1fAeadSBmjGM=3D; b=HrPqwjGi96UZ8FrCpgyOULpB5nn9XJFRg2AZ1PSNkrW9eQZ2MqKJbEUNo3tbXwe0TNZStJ88 m0fccWfSHireOW9KiairaURpnltLEw8Y5aoDSkbqGXLMgloDp4DG6kDo; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Liu Ya, On Oct 17, 2006, at 2:03 AM, Liu Ya wrote: > Hi Vincent, > > There is difference in our understanding of "unavailability of IP > multicast > service". Yes, higher level multicast services (e.g. IP multicast and > application-level multicast) are not limmited to lower level > multicast-enabled networks. But they are unnecessarily deployed. > GDOI runs > on top of UDP. GDOI could also run on TCP if one were to define this behavior. Please bear in mind that RFC 3547 is based on RFC 2408, ISAKMP, which is designed to run over a sockets interface, not just UDP. cheers, Mark > Availability of IP multicast service is the pre-condition of > running reliable multicast protocols such as NORTM and ALC. > However, IP > multicast is seldom deployed in real networks. > > Regards, > Liu Ya > >> -----Original Message----- >> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >> Sent: Tuesday, October 17, 2006 4:08 PM >> To: Liu Ya >> Cc: 'Mark Baugher'; msec@ietf.org >> Subject: Re: [MSEC] Case clarifications on group neighborship >> defined indraft-liu-gdoi-extensions-00.txt >> >> Hello Liu, >> >>>> I have questions about whether the current definitions (i.e. RFC >>>> 3547) don't meet your requirements. For example, do we >>>> really need a >>>> "unicast-groupkey-push" given that the current >> groupkey-push can be >>>> either sent either multicast or unicast? >>>> >>> >>> The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to >> reliably deliver >>> keying messages over unicast channel. It is different from unicast >>> GROUPKEY-PUSH, which must be used with additional reliable transport >>> technology (e.g. FEC encoding) to achieve reliable >> rekeying. I explained >>> the requirement of UNICAST-GROUPKEY-PUSH in another e-mail >> to George as >>> follows: >>> >>> For existing reliable rekeying methods, e.g., reliable >> multicast protocol, >>> FEC encoding scheme, etc., high efficiency can be achieved >> when they are >>> implemented over IP multicast. But IP multicast service is >> not always >>> available. And unicast is not fit for above methods. A >> multicast-undependent >>> way of reliable rekeying is needed. The >> UNICAST-GROUPKEY-PUSH exchange is to >>> fulfil that requirement. >>> >> >> Just one small remark: reliable multicast protocols (either >> NORM or ALC) and >> the associated FEC encoding schemes (usually embedded in the above >> protocols) >> are not limited to multicast-enabled networks. Using ALC or NORM for >> point-to-point communications (or any flavor of application-level >> multicast based >> on underlying unicast transmissions) is fine as well. For >> instance, with >> ALC you >> can have a periodic delivery of the content to the single >> receiver with >> a very limited >> additional complexity. And if it turns there are many receivers, you >> won't have >> to change the specifications. >> Yet I admit that using NORM for point-to-point communications >> would add >> a significant complexity for a very small benefit (if any!). That's >> perhaps what >> you meant? >> Having said that, there are perhaps other features (that I >> don't know) >> in your target >> use case that make the above protocols undesirable. >> >> Cheers, >> >> Vincent >> > > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 13:16:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsXr-0005n1-Hq; Tue, 17 Oct 2006 13:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWe-0005Ny-I6 for msec@ietf.org; Tue, 17 Oct 2006 13:14:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsL4-0007sy-QF for msec@ietf.org; Tue, 17 Oct 2006 13:02:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 10:02:50 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HH2oxx028170; Tue, 17 Oct 2006 10:02:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HH2nW4000803; Tue, 17 Oct 2006 10:02:49 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 10:02:49 -0700 Received: from [192.168.0.10] ([10.21.121.137]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:02:49 -0700 In-Reply-To: <4534A5A1.9070708@inrialpes.fr> References: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> <4534A5A1.9070708@inrialpes.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7374A418-7083-42DA-8296-1A0B5F9BE9B3@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt Date: Tue, 17 Oct 2006 10:02:45 -0700 To: Vincent Roca X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Oct 2006 17:02:49.0489 (UTC) FILETIME=[135BE010:01C6F20E] DKIM-Signature: a=rsa-sha1; q=dns; l=2378; t=1161104570; x=1161968570; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20indraft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DfjE1nsnNyysTJxV1fAeadSBmjGM=3D; b=XqdZ89Y+K1DvMaaQRKG0SDPe4LrzIOOp5PJ3kWZA3JS5mnt8tJXGdNMlUqbUCH6OOLkbAbLx lcAkY3Ynt9dcssG4J/mLk5o0reS4HuZT2udNcI3lGL2/kR92qoOkP4AR; Authentication-Results: sj-dkim-1.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Vincent, On Oct 17, 2006, at 2:42 AM, Vincent Roca wrote: > Hello Liu, > >> There is difference in our understanding of "unavailability of IP >> multicast >> service". Yes, higher level multicast services (e.g. IP multicast and >> application-level multicast) are not limmited to lower level >> multicast-enabled networks. But they are unnecessarily deployed. >> GDOI runs >> on top of UDP. Availability of IP multicast service is the pre- >> condition of >> running reliable multicast protocols such as NORTM and ALC. >> However, IP >> multicast is seldom deployed in real networks. > As a FLUTE/ALC and NORM developper (http://planete- > bcast.inrialpes.fr), I can > promise you that our implementation (and the same is true for that > of Univ. of > Tempere) supports both unicast or multicast services (whether they > are emulated > at application level or rely on native multicast routing). > Specifying a unicast destination > address is not a problem at all. Having purely unidirectional > physical networks > is not a problem either with ALC (but is an issue with NORM). What > I mean is > that we have a lot of flexibility here, and that's the reason why > ALC is used in > many different use cases, from Internet communications (with/ > without multicast > routing), satellite based networks, and DVB-H (and similar) > broadcasting networks. > > But I don't know the GDOI use case, and cannot answer if in that > particular use case, > it makes sense or not to use one of the reliable multicast > protocols in all situations, > in particular when there's a single destination. First, we have the problem of securing reliable multicast protocols and what to use for key establishment. As far back as 1998, we wanted to support security for reliable multicast protocols. By "we" I mean IRTF SMuG. GDOI can do that. For this reason, we often don't have the luxury of using a reliable multicast service, but opt to build the mechanisms into the protocol that we need. In Liu Ya's case, I think he just needs to use TCP as a transport protocol. Cheers, Mark > > Hope it clarifies my previous email. > > Cheers, > > Vincent > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 13:16:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsXr-0005n1-Hq; Tue, 17 Oct 2006 13:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWe-0005Ny-I6 for msec@ietf.org; Tue, 17 Oct 2006 13:14:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsL4-0007sy-QF for msec@ietf.org; Tue, 17 Oct 2006 13:02:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 10:02:50 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HH2oxx028170; Tue, 17 Oct 2006 10:02:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HH2nW4000803; Tue, 17 Oct 2006 10:02:49 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 10:02:49 -0700 Received: from [192.168.0.10] ([10.21.121.137]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:02:49 -0700 In-Reply-To: <4534A5A1.9070708@inrialpes.fr> References: <0c7d01c6f1cb$145333d0$480c6f0a@china.huawei.com> <4534A5A1.9070708@inrialpes.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7374A418-7083-42DA-8296-1A0B5F9BE9B3@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined indraft-liu-gdoi-extensions-00.txt Date: Tue, 17 Oct 2006 10:02:45 -0700 To: Vincent Roca X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Oct 2006 17:02:49.0489 (UTC) FILETIME=[135BE010:01C6F20E] DKIM-Signature: a=rsa-sha1; q=dns; l=2378; t=1161104570; x=1161968570; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20indraft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DfjE1nsnNyysTJxV1fAeadSBmjGM=3D; b=XqdZ89Y+K1DvMaaQRKG0SDPe4LrzIOOp5PJ3kWZA3JS5mnt8tJXGdNMlUqbUCH6OOLkbAbLx lcAkY3Ynt9dcssG4J/mLk5o0reS4HuZT2udNcI3lGL2/kR92qoOkP4AR; Authentication-Results: sj-dkim-1.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Vincent, On Oct 17, 2006, at 2:42 AM, Vincent Roca wrote: > Hello Liu, > >> There is difference in our understanding of "unavailability of IP >> multicast >> service". Yes, higher level multicast services (e.g. IP multicast and >> application-level multicast) are not limmited to lower level >> multicast-enabled networks. But they are unnecessarily deployed. >> GDOI runs >> on top of UDP. Availability of IP multicast service is the pre- >> condition of >> running reliable multicast protocols such as NORTM and ALC. >> However, IP >> multicast is seldom deployed in real networks. > As a FLUTE/ALC and NORM developper (http://planete- > bcast.inrialpes.fr), I can > promise you that our implementation (and the same is true for that > of Univ. of > Tempere) supports both unicast or multicast services (whether they > are emulated > at application level or rely on native multicast routing). > Specifying a unicast destination > address is not a problem at all. Having purely unidirectional > physical networks > is not a problem either with ALC (but is an issue with NORM). What > I mean is > that we have a lot of flexibility here, and that's the reason why > ALC is used in > many different use cases, from Internet communications (with/ > without multicast > routing), satellite based networks, and DVB-H (and similar) > broadcasting networks. > > But I don't know the GDOI use case, and cannot answer if in that > particular use case, > it makes sense or not to use one of the reliable multicast > protocols in all situations, > in particular when there's a single destination. First, we have the problem of securing reliable multicast protocols and what to use for key establishment. As far back as 1998, we wanted to support security for reliable multicast protocols. By "we" I mean IRTF SMuG. GDOI can do that. For this reason, we often don't have the luxury of using a reliable multicast service, but opt to build the mechanisms into the protocol that we need. In Liu Ya's case, I think he just needs to use TCP as a transport protocol. Cheers, Mark > > Hope it clarifies my previous email. > > Cheers, > > Vincent > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 17:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwV9-0000Nu-NV; Tue, 17 Oct 2006 17:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwV8-0000Mg-8J for msec@ietf.org; Tue, 17 Oct 2006 17:29:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpc7-0004Ko-HC for msec@ietf.org; Tue, 17 Oct 2006 10:08:18 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 07:08:15 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HE8F1n018829; Tue, 17 Oct 2006 07:08:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9HE8Ein000226; Tue, 17 Oct 2006 07:08:14 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 07:08:14 -0700 Received: from [192.168.0.10] ([10.21.121.137]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 07:08:14 -0700 In-Reply-To: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> References: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt Date: Tue, 17 Oct 2006 07:08:10 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Oct 2006 14:08:14.0391 (UTC) FILETIME=[AFB6C470:01C6F1F5] DKIM-Signature: a=rsa-sha1; q=dns; l=10700; t=1161094095; x=1161958095; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20in=20draft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DRjCgPOmcJKlVyXjjqiaE3lw1v50=3D; b=gR/o9o+7dhOQotcTH/uzTmRa0oONUrblhkkKyagRekfNXi3YbmAp9Zi2q0lH4INIgzk+KIHX 7/PIhobxpIF5YGVF9X9hhj1dUq4xNxdDaxmF7jgkXSv5Ao90yknoR5za; Authentication-Results: sj-dkim-3.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Liu Ya, On Oct 16, 2006, at 9:56 PM, Liu Ya wrote: > Hi Mark, > > My answer is inline. > >>> Following are some case clarifications on NEIGHBORSHIP-NOTIFY and >>> GROUPKEY-SHARE exchanges defined in >>> >> http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. >> >> I have questions about whether the current definitions (i.e. RFC >> 3547) don't meet your requirements. For example, do we >> really need a >> "unicast-groupkey-push" given that the current groupkey-push can be >> either sent either multicast or unicast? > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably > deliver > keying messages over unicast channel. Why not signal that you're using TCP and not UDP for the groupkey- push rather than invent new protocols? > It is different from unicast > GROUPKEY-PUSH, which must be used with additional reliable transport > technology (e.g. FEC encoding) to achieve reliable rekeying. I > explained > the requirement of UNICAST-GROUPKEY-PUSH in another e-mail to > George as > follows: > > For existing reliable rekeying methods, e.g., reliable multicast > protocol, > FEC encoding scheme, etc., high efficiency can be achieved when > they are > implemented over IP multicast. But IP multicast service is not always > available. I don't see what this has to do with the issue of reliable vs unreliable messaging. We can run either UDP or TCP to a unicast address regardless of the availability of multicast routing and access services. > And unicast is not fit for above methods. A multicast-undependent > way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH > exchange is to > fulfil that requirement. I believe that you are equating unicast with reliable and not multicast. But unicast and gdoi messaging can be run over a reliable end-to-end protocol such as UDP. I don't see why we need to have a new elements of procedure like unicast-groupkey-push. > >>> >>> For a GDOI group, a member may be shortly offline with GCKS for some >>> reasons, such as rebooting, network route flapping, etc. During that >>> interval, the GCKS might either create and push new rekeying >>> messages, or do >>> nothing. When the unlucky member is online again, it does not know >>> what >>> happened. For assurance, it should contact the GCKS to see whether >>> the group >>> SAs (including data security SA and Re-key SA) have been updated. >>> If yes, it >>> must initiate another two-party exchange with the GCKS to >> download the >>> latest SAs. In some environments (e.g. OSPF router groups), it is >>> usual that >>> group members happen to be offline shortly. If the group size is >>> large, the >>> GCKS would have to expend much computation power and network >>> bandwidth to >>> deal with members' requests. >> >> Why use a centralized GCKS? I can think of cases where a central >> GCKS is appropriate, but maybe the OSPF router groups application is >> not one of those cases. In this case, I would go to a distributed >> GCKS model where each GDOI member runs its own GCKS (e.g. to manage >> the decryption keys for data that it sends and to forward other >> senders' decryption keys that happen to be in the cache). > > Distributed GCKS is fine. It is necessary for large GDOI groups, e.g. > large-scale OSPF ASes with thousands of routers. I imagine two > deployment > models as fowllows: Sorry, I'm having trouble reading this diagram. > > +----------+ > | GCKS | > +----------+ > ^ > | OOB communication mechanism > V > +---------------------+-------------------+ > | | | > V V V > +-------------+ +------------+ +------------+ > | Delegate | | Delegate| | Delegate| > +-------------+ +------------+ +------------+ > | > V GROUPKEY-PULL or GROUPKEY-PUSH > +---------------------+-------------------+ > | | | > V V V > +------------+ +------------+ +------------+ > | Member | | Member | | Member | > +------------+ +------------+ +------------+ > > or > > OOB communication mechanism > +---------------------+-------------------+ > | | | > V V V > +-------------+ +------------+ +------------+ > | S-GCKS | | M-GCKS| | S-GCKS | > +-------------+ +------------+ +------------+ > | > V GROUPKEY-PULL or GROUPKEY-PUSH > +---------------------+-------------------+ > | | | > V V V > +------------+ +------------+ +------------+ > | Member | | Member | | Member | > +------------+ +------------+ +------------+ > > Here the prefix 'M-' indicates master, and 'S-' indicates > subordinate. In How about a third category 'P-' indicates a peer, i.e. the gcks operates entirely symmetrically with necessarily having a hierarchical relationship at all. > both forms above, the group root key must be managed centrally. And > some > out-of-band mechanisms must be defined to transport that key, and > other > information, between GCKSes, or between GCKS and Delegates. Why out of band? > Obviously, the > system is complicated in above models. And side effects (e.g. larger > rekeying delay) exist. For large groups, distributed control model > would be > the only standby choice. While for cases of medium scale groups, one > centralized GCKS would be enough for group keying purpose if > measures are > taken to reduce GCKS's workload. Sharing keying messages between group > members is just an examplle of that measure. It is deployed as > follows: > > +----------+ > | GCKS | > +----------+ > ^ > | GROUPKEY-PULL or GROUPKEY-PUSH > V > +------------------------------------------------------+ > | > | > V > V > +------------+ > +------------+ > | Member | <----GROUPKEY-SHARE----> | Member | > +------------+ > +------------+ > > This technique can also be used in distributed control model to reduce > delegate workload, thus decreasing the number of delegates. The model that I have in my head is very much like other client/ server messaging protocol where each entity is both a client and a server. I think that there is not necessarily any need to add new protocol procedures to gain the scalability - and relilability - that you're seeking. > >>> >>> For some GDOI groups like an OSPF router group, a trust and stable >>> group >>> membership exists. That characteristic can be utilized to >> alleviate >>> GCKS's >>> workload: Firstly, group neighborship is established. Then, >>> whenever a group >>> member is not sure whether its local SAs are in synchronization >>> with GCKS, >>> it first contacts its neighbors, not GCKS. >> >> Why not contact the neighbor's GCKS to get the update from its cache? >> >>> By this method, the requests from >>> members to GCKS decrease greatly. >> >> The requests to a central GCKS would decrease greatly. What is >> increasing are requests made to other group members. Properly >> considered, each group member can and should runs a GCKS and this is >> what gets contacted. By this method, the requests from one >> member to >> abother's GCKS increases as requests to a central GCKS are reduced. >> > > The performance bottleneck of group keying is in GCKS, not group > members. Then run the GCKS from each group member. > The GROUPKEY-SHARE exchange alliviates GCKS workload by > apportioning it to > group members. I don't see why we need a new protocol operation to accomplish this. > KEKs and TEK are still centrally managed on GCKS. Keying > messages also originate from GCKS. What a group member needs to do > is to > cache the rekeying messages and send them to requesters. It does > not play > the real GCKS role. If a and b are members of secure group g, then either a or b or both may be authorized to hand out keys for g. You're problem is not a lack of protocol operations, just policy. > >>> The neighborship can be either manually >>> configured on group members side, or centrally managed at >> GCKS. If the >>> second method is used, the neighborship is notified to the >> involved >>> members >>> using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY- >>> SHARE, is >>> used by group members to contact its neighbors for latest group >>> SAs. How to >>> establish the group neighborship is out of the doc's scope, >>> determined by >>> particular group policy. >> >> I think I understand your goal here. And I think that you need to >> apply RFC 3547 such that each group member has a GCKS, which can act >> as a server to a GCKS client or as a client to a GCKS server. I do >> think that you will need to describe how this would work for OSPF, >> but this maybe could be done as an Informational RFC, which >> is a very >> fast way to publish a standard - provided that the RFC Editor >> and the >> IESG agree with using RFC 3547 and your enhancements for OSPF router >> groups. Personally, I really don't know enough to say one >> way or the >> other. >>> >>> Any comments and questions would be appreciated. >> >> I hope my comments are helpful. > > Certainly, your comments are helpful to me. Great. Cheers, Mark > > Best regards, > Liu Ya > >> >> cheers, Mark >>> >>> Thanks, >>> Liu Ya >>> >>> >>> >>> _______________________________________________ >>> MSEC mailing list >>> MSEC@ietf.org >>> https://www1.ietf.org/mailman/listinfo/msec >> _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 17:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwV9-0000Nu-NV; Tue, 17 Oct 2006 17:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwV8-0000Mg-8J for msec@ietf.org; Tue, 17 Oct 2006 17:29:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpc7-0004Ko-HC for msec@ietf.org; Tue, 17 Oct 2006 10:08:18 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 07:08:15 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HE8F1n018829; Tue, 17 Oct 2006 07:08:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9HE8Ein000226; Tue, 17 Oct 2006 07:08:14 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 07:08:14 -0700 Received: from [192.168.0.10] ([10.21.121.137]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 07:08:14 -0700 In-Reply-To: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> References: <0c7b01c6f1a8$8ea6e5a0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt Date: Tue, 17 Oct 2006 07:08:10 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Oct 2006 14:08:14.0391 (UTC) FILETIME=[AFB6C470:01C6F1F5] DKIM-Signature: a=rsa-sha1; q=dns; l=10700; t=1161094095; x=1161958095; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Case=20clarifications=20on=20group=20neighborship=20def ined=20in=20draft-liu-gdoi-extensions-00.txt; X=v=3Dcisco.com=3B=20h=3DRjCgPOmcJKlVyXjjqiaE3lw1v50=3D; b=gR/o9o+7dhOQotcTH/uzTmRa0oONUrblhkkKyagRekfNXi3YbmAp9Zi2q0lH4INIgzk+KIHX 7/PIhobxpIF5YGVF9X9hhj1dUq4xNxdDaxmF7jgkXSv5Ao90yknoR5za; Authentication-Results: sj-dkim-3.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Liu Ya, On Oct 16, 2006, at 9:56 PM, Liu Ya wrote: > Hi Mark, > > My answer is inline. > >>> Following are some case clarifications on NEIGHBORSHIP-NOTIFY and >>> GROUPKEY-SHARE exchanges defined in >>> >> http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. >> >> I have questions about whether the current definitions (i.e. RFC >> 3547) don't meet your requirements. For example, do we >> really need a >> "unicast-groupkey-push" given that the current groupkey-push can be >> either sent either multicast or unicast? > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably > deliver > keying messages over unicast channel. Why not signal that you're using TCP and not UDP for the groupkey- push rather than invent new protocols? > It is different from unicast > GROUPKEY-PUSH, which must be used with additional reliable transport > technology (e.g. FEC encoding) to achieve reliable rekeying. I > explained > the requirement of UNICAST-GROUPKEY-PUSH in another e-mail to > George as > follows: > > For existing reliable rekeying methods, e.g., reliable multicast > protocol, > FEC encoding scheme, etc., high efficiency can be achieved when > they are > implemented over IP multicast. But IP multicast service is not always > available. I don't see what this has to do with the issue of reliable vs unreliable messaging. We can run either UDP or TCP to a unicast address regardless of the availability of multicast routing and access services. > And unicast is not fit for above methods. A multicast-undependent > way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH > exchange is to > fulfil that requirement. I believe that you are equating unicast with reliable and not multicast. But unicast and gdoi messaging can be run over a reliable end-to-end protocol such as UDP. I don't see why we need to have a new elements of procedure like unicast-groupkey-push. > >>> >>> For a GDOI group, a member may be shortly offline with GCKS for some >>> reasons, such as rebooting, network route flapping, etc. During that >>> interval, the GCKS might either create and push new rekeying >>> messages, or do >>> nothing. When the unlucky member is online again, it does not know >>> what >>> happened. For assurance, it should contact the GCKS to see whether >>> the group >>> SAs (including data security SA and Re-key SA) have been updated. >>> If yes, it >>> must initiate another two-party exchange with the GCKS to >> download the >>> latest SAs. In some environments (e.g. OSPF router groups), it is >>> usual that >>> group members happen to be offline shortly. If the group size is >>> large, the >>> GCKS would have to expend much computation power and network >>> bandwidth to >>> deal with members' requests. >> >> Why use a centralized GCKS? I can think of cases where a central >> GCKS is appropriate, but maybe the OSPF router groups application is >> not one of those cases. In this case, I would go to a distributed >> GCKS model where each GDOI member runs its own GCKS (e.g. to manage >> the decryption keys for data that it sends and to forward other >> senders' decryption keys that happen to be in the cache). > > Distributed GCKS is fine. It is necessary for large GDOI groups, e.g. > large-scale OSPF ASes with thousands of routers. I imagine two > deployment > models as fowllows: Sorry, I'm having trouble reading this diagram. > > +----------+ > | GCKS | > +----------+ > ^ > | OOB communication mechanism > V > +---------------------+-------------------+ > | | | > V V V > +-------------+ +------------+ +------------+ > | Delegate | | Delegate| | Delegate| > +-------------+ +------------+ +------------+ > | > V GROUPKEY-PULL or GROUPKEY-PUSH > +---------------------+-------------------+ > | | | > V V V > +------------+ +------------+ +------------+ > | Member | | Member | | Member | > +------------+ +------------+ +------------+ > > or > > OOB communication mechanism > +---------------------+-------------------+ > | | | > V V V > +-------------+ +------------+ +------------+ > | S-GCKS | | M-GCKS| | S-GCKS | > +-------------+ +------------+ +------------+ > | > V GROUPKEY-PULL or GROUPKEY-PUSH > +---------------------+-------------------+ > | | | > V V V > +------------+ +------------+ +------------+ > | Member | | Member | | Member | > +------------+ +------------+ +------------+ > > Here the prefix 'M-' indicates master, and 'S-' indicates > subordinate. In How about a third category 'P-' indicates a peer, i.e. the gcks operates entirely symmetrically with necessarily having a hierarchical relationship at all. > both forms above, the group root key must be managed centrally. And > some > out-of-band mechanisms must be defined to transport that key, and > other > information, between GCKSes, or between GCKS and Delegates. Why out of band? > Obviously, the > system is complicated in above models. And side effects (e.g. larger > rekeying delay) exist. For large groups, distributed control model > would be > the only standby choice. While for cases of medium scale groups, one > centralized GCKS would be enough for group keying purpose if > measures are > taken to reduce GCKS's workload. Sharing keying messages between group > members is just an examplle of that measure. It is deployed as > follows: > > +----------+ > | GCKS | > +----------+ > ^ > | GROUPKEY-PULL or GROUPKEY-PUSH > V > +------------------------------------------------------+ > | > | > V > V > +------------+ > +------------+ > | Member | <----GROUPKEY-SHARE----> | Member | > +------------+ > +------------+ > > This technique can also be used in distributed control model to reduce > delegate workload, thus decreasing the number of delegates. The model that I have in my head is very much like other client/ server messaging protocol where each entity is both a client and a server. I think that there is not necessarily any need to add new protocol procedures to gain the scalability - and relilability - that you're seeking. > >>> >>> For some GDOI groups like an OSPF router group, a trust and stable >>> group >>> membership exists. That characteristic can be utilized to >> alleviate >>> GCKS's >>> workload: Firstly, group neighborship is established. Then, >>> whenever a group >>> member is not sure whether its local SAs are in synchronization >>> with GCKS, >>> it first contacts its neighbors, not GCKS. >> >> Why not contact the neighbor's GCKS to get the update from its cache? >> >>> By this method, the requests from >>> members to GCKS decrease greatly. >> >> The requests to a central GCKS would decrease greatly. What is >> increasing are requests made to other group members. Properly >> considered, each group member can and should runs a GCKS and this is >> what gets contacted. By this method, the requests from one >> member to >> abother's GCKS increases as requests to a central GCKS are reduced. >> > > The performance bottleneck of group keying is in GCKS, not group > members. Then run the GCKS from each group member. > The GROUPKEY-SHARE exchange alliviates GCKS workload by > apportioning it to > group members. I don't see why we need a new protocol operation to accomplish this. > KEKs and TEK are still centrally managed on GCKS. Keying > messages also originate from GCKS. What a group member needs to do > is to > cache the rekeying messages and send them to requesters. It does > not play > the real GCKS role. If a and b are members of secure group g, then either a or b or both may be authorized to hand out keys for g. You're problem is not a lack of protocol operations, just policy. > >>> The neighborship can be either manually >>> configured on group members side, or centrally managed at >> GCKS. If the >>> second method is used, the neighborship is notified to the >> involved >>> members >>> using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY- >>> SHARE, is >>> used by group members to contact its neighbors for latest group >>> SAs. How to >>> establish the group neighborship is out of the doc's scope, >>> determined by >>> particular group policy. >> >> I think I understand your goal here. And I think that you need to >> apply RFC 3547 such that each group member has a GCKS, which can act >> as a server to a GCKS client or as a client to a GCKS server. I do >> think that you will need to describe how this would work for OSPF, >> but this maybe could be done as an Informational RFC, which >> is a very >> fast way to publish a standard - provided that the RFC Editor >> and the >> IESG agree with using RFC 3547 and your enhancements for OSPF router >> groups. Personally, I really don't know enough to say one >> way or the >> other. >>> >>> Any comments and questions would be appreciated. >> >> I hope my comments are helpful. > > Certainly, your comments are helpful to me. Great. Cheers, Mark > > Best regards, > Liu Ya > >> >> cheers, Mark >>> >>> Thanks, >>> Liu Ya >>> >>> >>> >>> _______________________________________________ >>> MSEC mailing list >>> MSEC@ietf.org >>> https://www1.ietf.org/mailman/listinfo/msec >> _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 17 19:46:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZyeB-0000dG-BR for msec-archive@lists.ietf.org; Tue, 17 Oct 2006 19:46:59 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZybM-0008W9-0r for msec-archive@lists.ietf.org; Tue, 17 Oct 2006 19:44:05 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8CD9C2CDEF; Tue, 17 Oct 2006 19:43:53 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BE4B42CD8A for ; Tue, 17 Oct 2006 19:43:51 -0400 (EDT) Received: (qmail 28548 invoked by uid 3269); 17 Oct 2006 23:43:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28545 invoked from network); 17 Oct 2006 23:43:51 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 17 Oct 2006 23:43:51 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id B6C5DE9D7C for ; Tue, 17 Oct 2006 19:43:51 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mailwash15.pair.com (Postfix) with ESMTP id 8CDFCE9D7B for ; Tue, 17 Oct 2006 19:43:51 -0400 (EDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2006 16:43:51 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HNhoRp012859 for ; Tue, 17 Oct 2006 16:43:50 -0700 Received: from [10.32.176.34] ([10.32.176.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9HNhibF029674 for ; Tue, 17 Oct 2006 16:43:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: msec From: Brian Weis Date: Tue, 17 Oct 2006 16:43:38 -0700 X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1463; t=1161128630; x=1161992630; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:Brian=20Weis=20 |Subject:Using=20Counter=20Modes=20with=20ESP=20and=20AH=20to=20Protect=20Group=2 0Traffic; X=v=3Dcisco.com=3B=20h=3D1B5kIXxaCiWRSyK3dCwoRHSSOOU=3D; b=YSljBEaQmljxr4xUvnalYlNto50+mDq/LZKla97gv++uVI7g2N9xCZBUbfIsm1bfQQrGXZcB w+5qD4n0QuX9e+FrdkWjpie4DS/KKwddDqo2h7LsjJMA5aSN9jD1HYVL; Authentication-Results: sj-dkim-5.cisco.com; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com verified; ); Subject: [MSEC] Using Counter Modes with ESP and AH to Protect Group Traffic X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Greetings, This is a call for comments on a new individual submission that is relevant to this working group. Counter-based modes of AES are becoming more popular because of their efficiency. However, these modes cannot currently be safely used with multi-sender IPsec SAs. This draft describes a method whereby these modes can safely be used in the presence of an automated group key management system. We'd like to make this a WG draft, if the chairs agree that it fits within the WG charter. Any comments pro or con that action are appreciated. Thanks, Brian > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Using Counter Modes with Encapsulating Security Payload > (ESP) and Authentication Header (AH) to Protect Group Traffic > Author(s) : D. McGrew, B. Weis > Filename : draft-weis-esp-group-counter-cipher-00.txt > Pages : 13 > Date : 2006-10-16 > > This memo describes the use of Advanced Encryption Standard (AES) > counter modes when applied to the Encapsulating Security Payload > (ESP) and Authentication Header (AH) in multiple-sender group > applications. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-weis-esp-group-counter- > cipher-00.txt > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 17 21:41:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0R2-0002yC-D5 for msec-archive@lists.ietf.org; Tue, 17 Oct 2006 21:41:32 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga0R1-00022z-5B for msec-archive@lists.ietf.org; Tue, 17 Oct 2006 21:41:32 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BABF52CACA; Tue, 17 Oct 2006 21:41:20 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4D1DE2CAAF for ; Tue, 17 Oct 2006 21:41:20 -0400 (EDT) Received: (qmail 74491 invoked by uid 3269); 18 Oct 2006 01:41:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74487 invoked from network); 18 Oct 2006 01:41:20 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 18 Oct 2006 01:41:20 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 17FADE9D4D for ; Tue, 17 Oct 2006 21:41:20 -0400 (EDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mailwash15.pair.com (Postfix) with ESMTP id C890AE9D24 for ; Tue, 17 Oct 2006 21:41:19 -0400 (EDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7B00ALY68852@szxga01-in.huawei.com> for msec@securemulticast.org; Wed, 18 Oct 2006 09:45:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7B00ED8687MB@szxga01-in.huawei.com> for msec@securemulticast.org; Wed, 18 Oct 2006 09:45:44 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7B00HEJ6MXH6@szxml04-in.huawei.com> for msec@securemulticast.org; Wed, 18 Oct 2006 09:54:36 +0800 (CST) Date: Wed, 18 Oct 2006 09:41:07 +0800 From: Miao Fuyou To: 'msec' Message-id: <01ed01c6f256$7b44e620$5c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbyVnrbzwXTDFg7Q4unKUWMlrz7Ig== Subject: [MSEC] delivery issue of msec mailing list X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f hi, It seems the mailing list does not work well. I got only 2 mails from this mailing list since my subscription, actually there should be a lot of posts recently. I believe my mail server does not block mails. And there is only one mail in archive on October, I reckon archiver suffers the same issue, too. Have you encounter the same issue? (If you are in same situation to me, it is highly possibel that you could not get this message:-)) Miao _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 23:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2Iv-0006YC-Sh; Tue, 17 Oct 2006 23:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2Iu-0006Xz-HN for msec@ietf.org; Tue, 17 Oct 2006 23:41:16 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2Iq-00008U-OS for msec@ietf.org; Tue, 17 Oct 2006 23:41:16 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7B001Y5BNUEJ@szxga03-in.huawei.com> for msec@ietf.org; Wed, 18 Oct 2006 11:43:06 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7B008D0BNTRC@szxga03-in.huawei.com> for msec@ietf.org; Wed, 18 Oct 2006 11:43:06 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7B007IEBEQ6D@szxml03-in.huawei.com> for msec@ietf.org; Wed, 18 Oct 2006 11:37:41 +0800 (CST) Date: Wed, 18 Oct 2006 11:31:31 +0800 From: Liu Ya Subject: RE: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt In-reply-to: To: 'Mark Baugher' , msec@ietf.org Message-id: <0e3901c6f265$e7885c90$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbx9bc6/a/7CGuiQw2l1LNy4hpLkAAYZd5Q X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, > On October 17, 2006 10:08 PM, Mark wrote: > > hi Liu Ya, > > On Oct 16, 2006, at 9:56 PM, Liu Ya wrote: > > > Hi Mark, > > > > My answer is inline. > > > >>> Following are some case clarifications on NEIGHBORSHIP-NOTIFY and > >>> GROUPKEY-SHARE exchanges defined in > >>> > >> > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. > >> > >> I have questions about whether the current definitions (i.e. RFC > >> 3547) don't meet your requirements. For example, do we > >> really need a > >> "unicast-groupkey-push" given that the current groupkey-push can be > >> either sent either multicast or unicast? > > > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably > > deliver > > keying messages over unicast channel. > > Why not signal that you're using TCP and not UDP for the groupkey- > push rather than invent new protocols? > It is the first time that I know TCP can be used for GDOI. RFC3547 doesn't say that at all. I'll consider GDOI over TCP. And UNICAST-GROUPKEY-PUSH may be deleted from my draft in future. Let's stop talking about that exchange any more. > >>> > >>> For a GDOI group, a member may be shortly offline with > GCKS for some > >>> reasons, such as rebooting, network route flapping, etc. > During that > >>> interval, the GCKS might either create and push new rekeying > >>> messages, or do > >>> nothing. When the unlucky member is online again, it does not know > >>> what > >>> happened. For assurance, it should contact the GCKS to see whether > >>> the group > >>> SAs (including data security SA and Re-key SA) have been updated. > >>> If yes, it > >>> must initiate another two-party exchange with the GCKS to > >> download the > >>> latest SAs. In some environments (e.g. OSPF router groups), it is > >>> usual that > >>> group members happen to be offline shortly. If the group size is > >>> large, the > >>> GCKS would have to expend much computation power and network > >>> bandwidth to > >>> deal with members' requests. > >> > >> Why use a centralized GCKS? I can think of cases where a central > >> GCKS is appropriate, but maybe the OSPF router groups > application is > >> not one of those cases. In this case, I would go to a distributed > >> GCKS model where each GDOI member runs its own GCKS (e.g. to manage > >> the decryption keys for data that it sends and to forward other > >> senders' decryption keys that happen to be in the cache). > > > > Distributed GCKS is fine. It is necessary for large GDOI > groups, e.g. > > large-scale OSPF ASes with thousands of routers. I imagine two > > deployment > > models as fowllows: > > Sorry, I'm having trouble reading this diagram. The diagrams is to show the hierarchy of GDOI groups when distributed GCKS is used. > > > > > +----------+ > > | GCKS | > > +----------+ > > ^ > > | OOB communication mechanism > > V > > +---------------------+-------------------+ > > | | | > > V V V > > +-------------+ +------------+ +------------+ > > | Delegate | | Delegate| | Delegate| > > +-------------+ +------------+ +------------+ > > | > > V GROUPKEY-PULL or > GROUPKEY-PUSH > > +---------------------+-------------------+ > > | | | > > V V V > > +------------+ +------------+ +------------+ > > | Member | | Member | | Member | > > +------------+ +------------+ +------------+ > > > > or > > > > OOB communication mechanism > > +---------------------+-------------------+ > > | | | > > V V V > > +-------------+ +------------+ +------------+ > > | S-GCKS | | M-GCKS| | S-GCKS | > > +-------------+ +------------+ +------------+ > > | > > V GROUPKEY-PULL or > GROUPKEY-PUSH > > +---------------------+-------------------+ > > | | | > > V V V > > +------------+ +------------+ +------------+ > > | Member | | Member | | Member | > > +------------+ +------------+ +------------+ > > > > Here the prefix 'M-' indicates master, and 'S-' indicates > > subordinate. In > > How about a third category 'P-' indicates a peer, i.e. the gcks > operates entirely symmetrically with necessarily having a > hierarchical relationship at all. > > > both forms above, the group root key must be managed > centrally. And > > some > > out-of-band mechanisms must be defined to transport that key, and > > other > > information, between GCKSes, or between GCKS and Delegates. > > Why out of band? Those mechanisms are not defined in RFC3547. I think they should be defined by particular GDOI implementations. So, they are thought out of band. > > > Obviously, the > > system is complicated in above models. And side effects (e.g. larger > > rekeying delay) exist. For large groups, distributed control model > > would be > > the only standby choice. While for cases of medium scale groups, one > > centralized GCKS would be enough for group keying purpose if > > measures are > > taken to reduce GCKS's workload. Sharing keying messages > between group > > members is just an examplle of that measure. It is deployed as > > follows: > > > > +----------+ > > | GCKS | > > +----------+ > > ^ > > | GROUPKEY-PULL or > GROUPKEY-PUSH > > V > > +------------------------------------------------------+ > > | > > | > > V > > V > > +------------+ > > +------------+ > > | Member | <----GROUPKEY-SHARE----> | Member | > > +------------+ > > +------------+ > > > > This technique can also be used in distributed control > model to reduce > > delegate workload, thus decreasing the number of delegates. > > The model that I have in my head is very much like other client/ > server messaging protocol where each entity is both a client and a > server. I think that there is not necessarily any need to add new > protocol procedures to gain the scalability - and > relilability - that > you're seeking. The name of P2P messaging may be more appropriate than client/server. In fact, that idea came from BitTorrent, a well-known P2P software. It is to make one GCKS serve more group members. I don't know why you think it is not needed for GDOI. > > > > >>> > >>> For some GDOI groups like an OSPF router group, a trust and stable > >>> group > >>> membership exists. That characteristic can be utilized to > >> alleviate > >>> GCKS's > >>> workload: Firstly, group neighborship is established. Then, > >>> whenever a group > >>> member is not sure whether its local SAs are in synchronization > >>> with GCKS, > >>> it first contacts its neighbors, not GCKS. > >> > >> Why not contact the neighbor's GCKS to get the update from > its cache? > >> > >>> By this method, the requests from > >>> members to GCKS decrease greatly. > >> > >> The requests to a central GCKS would decrease greatly. What is > >> increasing are requests made to other group members. Properly > >> considered, each group member can and should runs a GCKS > and this is > >> what gets contacted. By this method, the requests from one > >> member to > >> abother's GCKS increases as requests to a central GCKS are reduced. > >> > > > > The performance bottleneck of group keying is in GCKS, not group > > members. > > Then run the GCKS from each group member. No GCKS exists in a GROUPKEY-SHARE exchange. Only rekeying messages, not group key, is shared. A group member needn't provide keying service for its neighbors. Maybe the GROUPKEYINGMESSAGE-SHARE name is more comprehensive than GROUPKEY-SHARE. > > > The GROUPKEY-SHARE exchange alliviates GCKS workload by > > apportioning it to > > group members. > > I don't see why we need a new protocol operation to accomplish this. > > > KEKs and TEK are still centrally managed on GCKS. Keying > > messages also originate from GCKS. What a group member needs to do > > is to > > cache the rekeying messages and send them to requesters. It does > > not play > > the real GCKS role. > > If a and b are members of secure group g, then either a or b or both > may be authorized to hand out keys for g. You're problem is not a > lack of protocol operations, just policy. GROUPKEY-SHARE does not work in that way as you said. Only the centralized GCKS is authorized to hand out keys for the group. Neither a nor b is authorized to do that work. Only after a and b are assigned into one neighboring sub-group, they are able to share rekeying messages, not keys, each other. If they belong to different neighboring sub-groups, sharing messages between them is not authorized. Moreover, GROUPKEY-SHARE is flexible. It can be selectively depoyed int a GDOI group both partly and globally. Regards, Liu Ya > > > > >>> The neighborship can be either manually > >>> configured on group members side, or centrally managed at > >> GCKS. If the > >>> second method is used, the neighborship is notified to the > >> involved > >>> members > >>> using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, > GROUPKEY- > >>> SHARE, is > >>> used by group members to contact its neighbors for latest group > >>> SAs. How to > >>> establish the group neighborship is out of the doc's scope, > >>> determined by > >>> particular group policy. > >> > >> I think I understand your goal here. And I think that you need to > >> apply RFC 3547 such that each group member has a GCKS, > which can act > >> as a server to a GCKS client or as a client to a GCKS server. I do > >> think that you will need to describe how this would work for OSPF, > >> but this maybe could be done as an Informational RFC, which > >> is a very > >> fast way to publish a standard - provided that the RFC Editor > >> and the > >> IESG agree with using RFC 3547 and your enhancements for > OSPF router > >> groups. Personally, I really don't know enough to say one > >> way or the > >> other. > >>> > >>> Any comments and questions would be appreciated. > >> > >> I hope my comments are helpful. > > > > Certainly, your comments are helpful to me. > > Great. > > Cheers, Mark > > > > Best regards, > > Liu Ya > > > >> > >> cheers, Mark > >>> > >>> Thanks, > >>> Liu Ya > >>> > >>> > >>> > >>> _______________________________________________ > >>> MSEC mailing list > >>> MSEC@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/msec > >> > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Oct 17 23:41:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2Iv-0006YC-Sh; Tue, 17 Oct 2006 23:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga2Iu-0006Xz-HN for msec@ietf.org; Tue, 17 Oct 2006 23:41:16 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga2Iq-00008U-OS for msec@ietf.org; Tue, 17 Oct 2006 23:41:16 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7B001Y5BNUEJ@szxga03-in.huawei.com> for msec@ietf.org; Wed, 18 Oct 2006 11:43:06 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7B008D0BNTRC@szxga03-in.huawei.com> for msec@ietf.org; Wed, 18 Oct 2006 11:43:06 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7B007IEBEQ6D@szxml03-in.huawei.com> for msec@ietf.org; Wed, 18 Oct 2006 11:37:41 +0800 (CST) Date: Wed, 18 Oct 2006 11:31:31 +0800 From: Liu Ya Subject: RE: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt In-reply-to: To: 'Mark Baugher' , msec@ietf.org Message-id: <0e3901c6f265$e7885c90$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbx9bc6/a/7CGuiQw2l1LNy4hpLkAAYZd5Q X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, > On October 17, 2006 10:08 PM, Mark wrote: > > hi Liu Ya, > > On Oct 16, 2006, at 9:56 PM, Liu Ya wrote: > > > Hi Mark, > > > > My answer is inline. > > > >>> Following are some case clarifications on NEIGHBORSHIP-NOTIFY and > >>> GROUPKEY-SHARE exchanges defined in > >>> > >> > http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. > >> > >> I have questions about whether the current definitions (i.e. RFC > >> 3547) don't meet your requirements. For example, do we > >> really need a > >> "unicast-groupkey-push" given that the current groupkey-push can be > >> either sent either multicast or unicast? > > > > The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably > > deliver > > keying messages over unicast channel. > > Why not signal that you're using TCP and not UDP for the groupkey- > push rather than invent new protocols? > It is the first time that I know TCP can be used for GDOI. RFC3547 doesn't say that at all. I'll consider GDOI over TCP. And UNICAST-GROUPKEY-PUSH may be deleted from my draft in future. Let's stop talking about that exchange any more. > >>> > >>> For a GDOI group, a member may be shortly offline with > GCKS for some > >>> reasons, such as rebooting, network route flapping, etc. > During that > >>> interval, the GCKS might either create and push new rekeying > >>> messages, or do > >>> nothing. When the unlucky member is online again, it does not know > >>> what > >>> happened. For assurance, it should contact the GCKS to see whether > >>> the group > >>> SAs (including data security SA and Re-key SA) have been updated. > >>> If yes, it > >>> must initiate another two-party exchange with the GCKS to > >> download the > >>> latest SAs. In some environments (e.g. OSPF router groups), it is > >>> usual that > >>> group members happen to be offline shortly. If the group size is > >>> large, the > >>> GCKS would have to expend much computation power and network > >>> bandwidth to > >>> deal with members' requests. > >> > >> Why use a centralized GCKS? I can think of cases where a central > >> GCKS is appropriate, but maybe the OSPF router groups > application is > >> not one of those cases. In this case, I would go to a distributed > >> GCKS model where each GDOI member runs its own GCKS (e.g. to manage > >> the decryption keys for data that it sends and to forward other > >> senders' decryption keys that happen to be in the cache). > > > > Distributed GCKS is fine. It is necessary for large GDOI > groups, e.g. > > large-scale OSPF ASes with thousands of routers. I imagine two > > deployment > > models as fowllows: > > Sorry, I'm having trouble reading this diagram. The diagrams is to show the hierarchy of GDOI groups when distributed GCKS is used. > > > > > +----------+ > > | GCKS | > > +----------+ > > ^ > > | OOB communication mechanism > > V > > +---------------------+-------------------+ > > | | | > > V V V > > +-------------+ +------------+ +------------+ > > | Delegate | | Delegate| | Delegate| > > +-------------+ +------------+ +------------+ > > | > > V GROUPKEY-PULL or > GROUPKEY-PUSH > > +---------------------+-------------------+ > > | | | > > V V V > > +------------+ +------------+ +------------+ > > | Member | | Member | | Member | > > +------------+ +------------+ +------------+ > > > > or > > > > OOB communication mechanism > > +---------------------+-------------------+ > > | | | > > V V V > > +-------------+ +------------+ +------------+ > > | S-GCKS | | M-GCKS| | S-GCKS | > > +-------------+ +------------+ +------------+ > > | > > V GROUPKEY-PULL or > GROUPKEY-PUSH > > +---------------------+-------------------+ > > | | | > > V V V > > +------------+ +------------+ +------------+ > > | Member | | Member | | Member | > > +------------+ +------------+ +------------+ > > > > Here the prefix 'M-' indicates master, and 'S-' indicates > > subordinate. In > > How about a third category 'P-' indicates a peer, i.e. the gcks > operates entirely symmetrically with necessarily having a > hierarchical relationship at all. > > > both forms above, the group root key must be managed > centrally. And > > some > > out-of-band mechanisms must be defined to transport that key, and > > other > > information, between GCKSes, or between GCKS and Delegates. > > Why out of band? Those mechanisms are not defined in RFC3547. I think they should be defined by particular GDOI implementations. So, they are thought out of band. > > > Obviously, the > > system is complicated in above models. And side effects (e.g. larger > > rekeying delay) exist. For large groups, distributed control model > > would be > > the only standby choice. While for cases of medium scale groups, one > > centralized GCKS would be enough for group keying purpose if > > measures are > > taken to reduce GCKS's workload. Sharing keying messages > between group > > members is just an examplle of that measure. It is deployed as > > follows: > > > > +----------+ > > | GCKS | > > +----------+ > > ^ > > | GROUPKEY-PULL or > GROUPKEY-PUSH > > V > > +------------------------------------------------------+ > > | > > | > > V > > V > > +------------+ > > +------------+ > > | Member | <----GROUPKEY-SHARE----> | Member | > > +------------+ > > +------------+ > > > > This technique can also be used in distributed control > model to reduce > > delegate workload, thus decreasing the number of delegates. > > The model that I have in my head is very much like other client/ > server messaging protocol where each entity is both a client and a > server. I think that there is not necessarily any need to add new > protocol procedures to gain the scalability - and > relilability - that > you're seeking. The name of P2P messaging may be more appropriate than client/server. In fact, that idea came from BitTorrent, a well-known P2P software. It is to make one GCKS serve more group members. I don't know why you think it is not needed for GDOI. > > > > >>> > >>> For some GDOI groups like an OSPF router group, a trust and stable > >>> group > >>> membership exists. That characteristic can be utilized to > >> alleviate > >>> GCKS's > >>> workload: Firstly, group neighborship is established. Then, > >>> whenever a group > >>> member is not sure whether its local SAs are in synchronization > >>> with GCKS, > >>> it first contacts its neighbors, not GCKS. > >> > >> Why not contact the neighbor's GCKS to get the update from > its cache? > >> > >>> By this method, the requests from > >>> members to GCKS decrease greatly. > >> > >> The requests to a central GCKS would decrease greatly. What is > >> increasing are requests made to other group members. Properly > >> considered, each group member can and should runs a GCKS > and this is > >> what gets contacted. By this method, the requests from one > >> member to > >> abother's GCKS increases as requests to a central GCKS are reduced. > >> > > > > The performance bottleneck of group keying is in GCKS, not group > > members. > > Then run the GCKS from each group member. No GCKS exists in a GROUPKEY-SHARE exchange. Only rekeying messages, not group key, is shared. A group member needn't provide keying service for its neighbors. Maybe the GROUPKEYINGMESSAGE-SHARE name is more comprehensive than GROUPKEY-SHARE. > > > The GROUPKEY-SHARE exchange alliviates GCKS workload by > > apportioning it to > > group members. > > I don't see why we need a new protocol operation to accomplish this. > > > KEKs and TEK are still centrally managed on GCKS. Keying > > messages also originate from GCKS. What a group member needs to do > > is to > > cache the rekeying messages and send them to requesters. It does > > not play > > the real GCKS role. > > If a and b are members of secure group g, then either a or b or both > may be authorized to hand out keys for g. You're problem is not a > lack of protocol operations, just policy. GROUPKEY-SHARE does not work in that way as you said. Only the centralized GCKS is authorized to hand out keys for the group. Neither a nor b is authorized to do that work. Only after a and b are assigned into one neighboring sub-group, they are able to share rekeying messages, not keys, each other. If they belong to different neighboring sub-groups, sharing messages between them is not authorized. Moreover, GROUPKEY-SHARE is flexible. It can be selectively depoyed int a GDOI group both partly and globally. Regards, Liu Ya > > > > >>> The neighborship can be either manually > >>> configured on group members side, or centrally managed at > >> GCKS. If the > >>> second method is used, the neighborship is notified to the > >> involved > >>> members > >>> using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, > GROUPKEY- > >>> SHARE, is > >>> used by group members to contact its neighbors for latest group > >>> SAs. How to > >>> establish the group neighborship is out of the doc's scope, > >>> determined by > >>> particular group policy. > >> > >> I think I understand your goal here. And I think that you need to > >> apply RFC 3547 such that each group member has a GCKS, > which can act > >> as a server to a GCKS client or as a client to a GCKS server. I do > >> think that you will need to describe how this would work for OSPF, > >> but this maybe could be done as an Informational RFC, which > >> is a very > >> fast way to publish a standard - provided that the RFC Editor > >> and the > >> IESG agree with using RFC 3547 and your enhancements for > OSPF router > >> groups. Personally, I really don't know enough to say one > >> way or the > >> other. > >>> > >>> Any comments and questions would be appreciated. > >> > >> I hope my comments are helpful. > > > > Certainly, your comments are helpful to me. > > Great. > > Cheers, Mark > > > > Best regards, > > Liu Ya > > > >> > >> cheers, Mark > >>> > >>> Thanks, > >>> Liu Ya > >>> > >>> > >>> > >>> _______________________________________________ > >>> MSEC mailing list > >>> MSEC@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/msec > >> > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Oct 18 07:30:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga9dS-0000P4-IR for msec-archive@lists.ietf.org; Wed, 18 Oct 2006 07:30:58 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga9dR-0005Db-6m for msec-archive@lists.ietf.org; Wed, 18 Oct 2006 07:30:58 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DB3402CB4F; Wed, 18 Oct 2006 07:30:46 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 07B622CB15 for ; Wed, 18 Oct 2006 07:30:46 -0400 (EDT) Received: (qmail 83285 invoked by uid 3269); 18 Oct 2006 11:30:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83282 invoked from network); 18 Oct 2006 11:30:46 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 18 Oct 2006 11:30:46 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id EF9E8E9D96 for ; Wed, 18 Oct 2006 07:30:45 -0400 (EDT) Received: from perseverance.services.encs.concordia.ca (perseverance-96.encs.concordia.ca [132.205.96.94]) by mailwash15.pair.com (Postfix) with ESMTP id DDC8AE9D93 for ; Wed, 18 Oct 2006 07:30:45 -0400 (EDT) Received: from [127.0.0.1] (root@fir.cs.concordia.ca [132.205.45.147]) by perseverance.services.encs.concordia.ca (8.13.7/8.13.7) with ESMTP id k9IBUTYu005013 for ; Wed, 18 Oct 2006 07:30:45 -0400 Message-ID: <45361015.8090809@cse.concordia.ca> Date: Wed, 18 Oct 2006 07:29:25 -0400 From: William Atwood User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.43 on perseverance.encs.concordia.ca at 2006/10/18 07:30:45 EDT Subject: [MSEC] Questions about draft-ietf-pim-sm-linklocal X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Since one of the most useful responses to draft-atwood-pim-sm-linklocal came from an MSEC group member who does not subscribe to the pim mailing list, I obtained permission to cross-post the message below to the MSEC mailing list. Any comments from the MSEC list members will be most appreciated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - As requested after the PIM WG meeting at IETF-66, we have issued draft-ietf-pim-sm-linklocal-00, which considers the problem of securing the link-local (router-to-router) messages in PIM-SM. Our original proposal (in draft-atwood-pim-sm-linklocal-01) was 1) to use the IPsec Authentication Header (AH) to provide authentication, and 2) to use Security Association (SA) selection based on source address to permit enabling replay protection. In preparing this new draft, we have freely borrowed ideas (and text) from RFC 4552 (Authentication/Confidentiality for OSPFv3). (Thanks to Bill Fenner for this pointer.) We have four questions that we specifically want to ask the Working Group members: 1) Is there an operational need for confidentiality as well as authentication? If so, we will adopt appropriate text from RFC 4552 and recommend the use of ESP in addition to AH. 2) One reply to the posting of draft-atwood-pim-sm-linklocal strongly suggested the use of automated group key management for a community of PIM-SM routers. The arguments were convincing to us. Does anyone have any observations on the utility of this? Should it be mandatory (MUST), or recommended (SHOULD), or optional (MAY)? 3) RFC 4601 states: "IPsec [8] allows (but does not require) there to be different Security Policy Databases (SPD) for each router interface. If available, it may be desirable to configure the Security Policy Database at a PIM router such that all incoming and outgoing Join/Prune, Assert, and Hello packets use a different SA for each incoming and outgoing interface." The solution that we propose uses the source address as a selector, and thus avoids the necessity of multiple SPDs. For this reason, we did _not_ adopt the text from RFC 4552 that requires the ability to choose a specific SPD based on the interface. Does anyone see any disadvantages to this decision? (NOTE: OSFPv3 speakers (RFC 4552) cannot rely on the limited number (and distance) of peers that we will have with PIM-SM link-local messages.) 4) Is it preferable to continue to use ALL_PIM_ROUTERS (with the proposed new semantics for secured messages), or to define a new SSM address to be used for exchanging the secured messages? Of course, comments on any part of the document will be most welcome. Bill Atwood Salekul Islam -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.Concordia.ca 1455 de Maisonneuve Blvd. West http: //www.cse.Concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@ietf.org Thu Oct 19 09:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYE9-0007JW-2t; Thu, 19 Oct 2006 09:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPq7-0008Jb-VI for msec@ietf.org; Fri, 13 Oct 2006 12:24:51 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GYPq3-0006C7-Kb for msec@ietf.org; Fri, 13 Oct 2006 12:24:51 -0400 Received: (qmail 91769 invoked by uid 0); 13 Oct 2006 12:24:47 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 13 Oct 2006 12:24:47 -0400 Received: (qmail 85344 invoked from network); 13 Oct 2006 12:24:46 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 13 Oct 2006 12:24:46 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k9DCRR008909; Fri, 13 Oct 2006 08:27:27 -0400 Date: Fri, 13 Oct 2006 08:27:27 -0400 (EDT) From: George Gross To: Liu Ya Subject: Re: [MSEC] Is GSAKMP compatible with IPsec architecture defined in RFC4301? In-Reply-To: <023a01c6ee91$be5cf6f0$480c6f0a@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Thu, 19 Oct 2006 09:46:28 -0400 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Liu, On Fri, 13 Oct 2006, Liu Ya wrote: > Hi all, > > I have a question about GSAKMP. In the MSEC architecture defined in > RFC4301 and draft-ietf-msec-ipsec-extensions-01, ESP/AH can be used > for data security protocols. GDOI and GKDP serve group keying. Can > GSAKMP be used here for group keying? Yes, GSAKMP can handle that type of group keying. Of course, RFC4534 and RFC4535 only define an extensible framework from which one derives application-specific instances. IPsec is an example of such an extension. > I find no GSAKMP payloads that > can deliver SPI (Security Parameters Index) information from GC/KS to > group members. Please tell me whether the combination of > MSEC_Architecture+ESP/AH+GSAKMP is feasible? Extending GSAKMP to do IPsec group key management involves several extensions: 1) An IPsec group security policy information model. The Group Owner uses this information model to encode a given group's IPsec security policies in the policy token. This policy includes IPsec PAD, SPD, and SAD descriptors for attributes such as the encryption transform, authentication transform, SPI, key identifiers, group speaker authorization, etc. The policy token is distributed to the group membership in a Policy Token payload, either via a Re-Key Event message multicast or at registration time within a Key Download message. 2) Group keying material for the IPsec SA is distributed in the Key Download payload. For each IPsec SA, there would be a separate key for the encryption transform, group authentication transform, and optionally a digital signature public key. The key identifiers would refer to IPsec SA descriptors within the policy token. 3) Developing a profile on the many options and features within the base GSAKMP protocol. Transitioning the above extensions from private implementations into the IETF is an area for future standardization. Of course, that activity will depend on industry interest. hth, George > > Thanks, > Liu Ya > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Oct 19 09:47:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYE9-0007JW-2t; Thu, 19 Oct 2006 09:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPq7-0008Jb-VI for msec@ietf.org; Fri, 13 Oct 2006 12:24:51 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GYPq3-0006C7-Kb for msec@ietf.org; Fri, 13 Oct 2006 12:24:51 -0400 Received: (qmail 91769 invoked by uid 0); 13 Oct 2006 12:24:47 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 13 Oct 2006 12:24:47 -0400 Received: (qmail 85344 invoked from network); 13 Oct 2006 12:24:46 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 13 Oct 2006 12:24:46 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k9DCRR008909; Fri, 13 Oct 2006 08:27:27 -0400 Date: Fri, 13 Oct 2006 08:27:27 -0400 (EDT) From: George Gross To: Liu Ya Subject: Re: [MSEC] Is GSAKMP compatible with IPsec architecture defined in RFC4301? In-Reply-To: <023a01c6ee91$be5cf6f0$480c6f0a@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Thu, 19 Oct 2006 09:46:28 -0400 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Liu, On Fri, 13 Oct 2006, Liu Ya wrote: > Hi all, > > I have a question about GSAKMP. In the MSEC architecture defined in > RFC4301 and draft-ietf-msec-ipsec-extensions-01, ESP/AH can be used > for data security protocols. GDOI and GKDP serve group keying. Can > GSAKMP be used here for group keying? Yes, GSAKMP can handle that type of group keying. Of course, RFC4534 and RFC4535 only define an extensible framework from which one derives application-specific instances. IPsec is an example of such an extension. > I find no GSAKMP payloads that > can deliver SPI (Security Parameters Index) information from GC/KS to > group members. Please tell me whether the combination of > MSEC_Architecture+ESP/AH+GSAKMP is feasible? Extending GSAKMP to do IPsec group key management involves several extensions: 1) An IPsec group security policy information model. The Group Owner uses this information model to encode a given group's IPsec security policies in the policy token. This policy includes IPsec PAD, SPD, and SAD descriptors for attributes such as the encryption transform, authentication transform, SPI, key identifiers, group speaker authorization, etc. The policy token is distributed to the group membership in a Policy Token payload, either via a Re-Key Event message multicast or at registration time within a Key Download message. 2) Group keying material for the IPsec SA is distributed in the Key Download payload. For each IPsec SA, there would be a separate key for the encryption transform, group authentication transform, and optionally a digital signature public key. The key identifiers would refer to IPsec SA descriptors within the policy token. 3) Developing a profile on the many options and features within the base GSAKMP protocol. Transitioning the above extensions from private implementations into the IETF is an area for future standardization. Of course, that activity will depend on industry interest. hth, George > > Thanks, > Liu Ya > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Oct 20 18:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb38T-0007va-Lo; Fri, 20 Oct 2006 18:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb38R-0007uw-L7; Fri, 20 Oct 2006 18:46:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb38J-00070f-J8; Fri, 20 Oct 2006 18:46:39 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2006 15:46:31 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KMkUS8012924; Fri, 20 Oct 2006 15:46:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9KMkYW4026384; Fri, 20 Oct 2006 15:46:34 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:46:30 -0700 Received: from [192.168.0.10] ([10.21.120.205]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:46:29 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) References: Message-Id: <02BEDDF0-D414-4160-A75D-E7FF1022A3D7@cisco.com> From: Mark Baugher Date: Fri, 20 Oct 2006 15:46:30 -0700 To: msec@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Oct 2006 22:46:29.0946 (UTC) FILETIME=[955929A0:01C6F499] DKIM-Signature: a=rsa-sha1; q=dns; l=19123; t=1161384390; x=1162248390; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Fwd=3A=20I-D=20ACTION=3Adraft-baugher-msec-gdoi-srtp-00.txt=20; X=v=3Dcisco.com=3B=20h=3Dh2u+w4Gf7TU6SulC4S/yYyc/8E8=3D; b=RN4e9DLkZKDuVzqGtc9PD9jwU6gyS4XAJyu18aRHBxcJ9VFo34hryXxOOBcK97WNKSfDEILd G3O3tZKH9lBmiTcU2JVoYxjUumG6SNANXqzmi7qqbxWMJ4am/tBDx5K/; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Subject: [MSEC] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1025369167==" Errors-To: msec-bounces@ietf.org --===============1025369167== Content-Type: multipart/alternative; boundary=Apple-Mail-12-541080016 --Apple-Mail-12-541080016 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi We wish to call you attention to this recent contribution on signaling SRTP crypto contexts using ISAKMP GDOI. Please direct your comments about this I-D to msec. Thanks, Mark Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 16, 2006 12:50:01 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : GDOI Key Establishment for the SRTP Data Security Protocol > Author(s) : M. Baugher, A. Rueegsegger > Filename : draft-baugher-msec-gdoi-srtp-00.txt > Pages : 19 > Date : 2006-10-16 > > The Secure Real-time Transport Protocol (SRTP) secures unicast and > multicast media streams. Multicast receivers of an SRTP stream > therefore share an SRTP master key for multicast message > authentication and decryption. This document describes how to > establish a shared, "group key" for an SRTP session using RFC 3547, > the Group Domain of Interpretation (GDOI) and RFC 2408, the > Internet > Security Association and Key Management Protocol. This document > extends GDOI for SRTP group key establishment. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi- > srtp-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-baugher-msec-gdoi-srtp-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-10-16121241.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-12-541080016 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi
=A0 We wish to call you = attention to this recent contribution on signaling SRTP crypto contexts = using=A0ISAKMP GDOI.=A0 Please direct your comments about this I-D to = msec.

Thanks, = Mark

Begin forwarded message:

Date: October 16, 2006 12:50:01 PM = PDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : GDOI Key Establishment for the = SRTP Data Security Protocol
= Author(s) = : M. Baugher, A. Rueegsegger
= Filename = : draft-baugher-msec-gdoi-srtp-00.txt
Pages : 19
Date : = 2006-10-16

=

=A0=A0 The Secure Real-time = Transport Protocol (SRTP) secures unicast and
=A0=A0 = multicast media streams.=A0 = Multicast receivers of an SRTP stream
=A0=A0 = therefore share an SRTP master key for multicast = message
=A0=A0 authentication and = decryption.=A0 This = document describes how to
=A0=A0 establish a shared, "group = key" for an SRTP session using RFC 3547,
=A0=A0 the Group Domain of = Interpretation (GDOI) and RFC 2408, the Internet
=A0=A0 = Security Association and Key Management Protocol.=A0 This document
=A0=A0 = extends GDOI for SRTP group key establishment.



A URL for this Internet-Draft = is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-baugher-msec-gdoi-srtp-00.txt".

A list of = Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

I-D-Announce mailing list
=

= --Apple-Mail-12-541080016-- --===============1025369167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1025369167==-- From msec-bounces@ietf.org Fri Oct 20 18:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb38T-0007va-Lo; Fri, 20 Oct 2006 18:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb38R-0007uw-L7; Fri, 20 Oct 2006 18:46:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb38J-00070f-J8; Fri, 20 Oct 2006 18:46:39 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2006 15:46:31 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KMkUS8012924; Fri, 20 Oct 2006 15:46:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9KMkYW4026384; Fri, 20 Oct 2006 15:46:34 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:46:30 -0700 Received: from [192.168.0.10] ([10.21.120.205]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:46:29 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) References: Message-Id: <02BEDDF0-D414-4160-A75D-E7FF1022A3D7@cisco.com> From: Mark Baugher Date: Fri, 20 Oct 2006 15:46:30 -0700 To: msec@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Oct 2006 22:46:29.0946 (UTC) FILETIME=[955929A0:01C6F499] DKIM-Signature: a=rsa-sha1; q=dns; l=19123; t=1161384390; x=1162248390; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Fwd=3A=20I-D=20ACTION=3Adraft-baugher-msec-gdoi-srtp-00.txt=20; X=v=3Dcisco.com=3B=20h=3Dh2u+w4Gf7TU6SulC4S/yYyc/8E8=3D; b=RN4e9DLkZKDuVzqGtc9PD9jwU6gyS4XAJyu18aRHBxcJ9VFo34hryXxOOBcK97WNKSfDEILd G3O3tZKH9lBmiTcU2JVoYxjUumG6SNANXqzmi7qqbxWMJ4am/tBDx5K/; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Subject: [MSEC] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1025369167==" Errors-To: msec-bounces@ietf.org --===============1025369167== Content-Type: multipart/alternative; boundary=Apple-Mail-12-541080016 --Apple-Mail-12-541080016 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi We wish to call you attention to this recent contribution on signaling SRTP crypto contexts using ISAKMP GDOI. Please direct your comments about this I-D to msec. Thanks, Mark Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 16, 2006 12:50:01 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : GDOI Key Establishment for the SRTP Data Security Protocol > Author(s) : M. Baugher, A. Rueegsegger > Filename : draft-baugher-msec-gdoi-srtp-00.txt > Pages : 19 > Date : 2006-10-16 > > The Secure Real-time Transport Protocol (SRTP) secures unicast and > multicast media streams. Multicast receivers of an SRTP stream > therefore share an SRTP master key for multicast message > authentication and decryption. This document describes how to > establish a shared, "group key" for an SRTP session using RFC 3547, > the Group Domain of Interpretation (GDOI) and RFC 2408, the > Internet > Security Association and Key Management Protocol. This document > extends GDOI for SRTP group key establishment. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi- > srtp-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-baugher-msec-gdoi-srtp-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-10-16121241.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-12-541080016 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi
=A0 We wish to call you = attention to this recent contribution on signaling SRTP crypto contexts = using=A0ISAKMP GDOI.=A0 Please direct your comments about this I-D to = msec.

Thanks, = Mark

Begin forwarded message:

Date: October 16, 2006 12:50:01 PM = PDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : GDOI Key Establishment for the = SRTP Data Security Protocol
= Author(s) = : M. Baugher, A. Rueegsegger
= Filename = : draft-baugher-msec-gdoi-srtp-00.txt
Pages : 19
Date : = 2006-10-16

=

=A0=A0 The Secure Real-time = Transport Protocol (SRTP) secures unicast and
=A0=A0 = multicast media streams.=A0 = Multicast receivers of an SRTP stream
=A0=A0 = therefore share an SRTP master key for multicast = message
=A0=A0 authentication and = decryption.=A0 This = document describes how to
=A0=A0 establish a shared, "group = key" for an SRTP session using RFC 3547,
=A0=A0 the Group Domain of = Interpretation (GDOI) and RFC 2408, the Internet
=A0=A0 = Security Association and Key Management Protocol.=A0 This document
=A0=A0 = extends GDOI for SRTP group key establishment.



A URL for this Internet-Draft = is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-baugher-msec-gdoi-srtp-00.txt".

A list of = Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

I-D-Announce mailing list
=

= --Apple-Mail-12-541080016-- --===============1025369167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1025369167==-- From msec-bounces@ietf.org Sat Oct 21 09:14:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbGg5-0001ON-Vy; Sat, 21 Oct 2006 09:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbGg4-0001OI-HX for msec@ietf.org; Sat, 21 Oct 2006 09:14:16 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbGg1-0003sN-32 for msec@ietf.org; Sat, 21 Oct 2006 09:14:16 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1838759nfc for ; Sat, 21 Oct 2006 06:14:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=DZe62NZE9gjNcTD+Wtp9U3tVG2O2+bO+GenIMZRQhaPjb7jd1oAgbzu01673eSGV4Rt7tCItaquwiSkAxXvcLtIYbzRnEIBfMije2SPnMAsni78qGocP2R/Qr2V8swwjeBHezhJ97NshDXK73oukDuNo/kBVjinUocwf79u5iIs= Received: by 10.82.106.14 with SMTP id e14mr907854buc; Sat, 21 Oct 2006 06:14:11 -0700 (PDT) Received: by 10.82.148.6 with HTTP; Sat, 21 Oct 2006 06:14:11 -0700 (PDT) Message-ID: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> Date: Sat, 21 Oct 2006 09:14:11 -0400 From: "Eugene Chin" To: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE In-Reply-To: <7.0.1.0.2.20061017032206.0491a958@qualcomm.com> MIME-Version: 1.0 References: <7.0.1.0.2.20060921094125.07886cc0@qualcomm.com> <7.0.1.0.2.20061017032206.0491a958@qualcomm.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1277075771==" Errors-To: msec-bounces@ietf.org --===============1277075771== Content-Type: multipart/alternative; boundary="----=_Part_108019_18172414.1161436451644" ------=_Part_108019_18172414.1161436451644 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Section 3.3 - typo: server -> serve "Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..." Section 4.1 - I've submitted an update to ietf-msec-mikey-ecc. Where I think it was previously confusing, the draft now clearly identifies the 4 additional methods (1 added based on Steffen's comments): - extending MIKEY-DHSIGN to use ECDSA - extending MIKEY-DHSIGN to use ECDH - MIKEY-ECIES - MIKEY-ECMQV (renamed from MIKEY-MQV) The rename to MIKEY-ECMQV also affects section 4.1.2. Thanks, Eugene. ------=_Part_108019_18172414.1161436451644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Section 3.3 - typo: server -> serve
"Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..."

Section 4.1 -
I've submitted an update to ietf-msec-mikey-ecc.  Where I think it was previously confusing, the draft now clearly identifies the 4 additional methods (1 added based on Steffen's comments):
- extending MIKEY-DHSIGN to use ECDSA
- extending MIKEY-DHSIGN to use ECDH
- MIKEY-ECIES
- MIKEY-ECMQV (renamed from MIKEY-MQV)

The rename to MIKEY-ECMQV also affects section 4.1.2.

Thanks,
Eugene.

------=_Part_108019_18172414.1161436451644-- --===============1277075771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1277075771==-- From msec-bounces@ietf.org Sat Oct 21 09:14:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbGg5-0001ON-Vy; Sat, 21 Oct 2006 09:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbGg4-0001OI-HX for msec@ietf.org; Sat, 21 Oct 2006 09:14:16 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbGg1-0003sN-32 for msec@ietf.org; Sat, 21 Oct 2006 09:14:16 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1838759nfc for ; Sat, 21 Oct 2006 06:14:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=DZe62NZE9gjNcTD+Wtp9U3tVG2O2+bO+GenIMZRQhaPjb7jd1oAgbzu01673eSGV4Rt7tCItaquwiSkAxXvcLtIYbzRnEIBfMije2SPnMAsni78qGocP2R/Qr2V8swwjeBHezhJ97NshDXK73oukDuNo/kBVjinUocwf79u5iIs= Received: by 10.82.106.14 with SMTP id e14mr907854buc; Sat, 21 Oct 2006 06:14:11 -0700 (PDT) Received: by 10.82.148.6 with HTTP; Sat, 21 Oct 2006 06:14:11 -0700 (PDT) Message-ID: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> Date: Sat, 21 Oct 2006 09:14:11 -0400 From: "Eugene Chin" To: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE In-Reply-To: <7.0.1.0.2.20061017032206.0491a958@qualcomm.com> MIME-Version: 1.0 References: <7.0.1.0.2.20060921094125.07886cc0@qualcomm.com> <7.0.1.0.2.20061017032206.0491a958@qualcomm.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1277075771==" Errors-To: msec-bounces@ietf.org --===============1277075771== Content-Type: multipart/alternative; boundary="----=_Part_108019_18172414.1161436451644" ------=_Part_108019_18172414.1161436451644 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Section 3.3 - typo: server -> serve "Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..." Section 4.1 - I've submitted an update to ietf-msec-mikey-ecc. Where I think it was previously confusing, the draft now clearly identifies the 4 additional methods (1 added based on Steffen's comments): - extending MIKEY-DHSIGN to use ECDSA - extending MIKEY-DHSIGN to use ECDH - MIKEY-ECIES - MIKEY-ECMQV (renamed from MIKEY-MQV) The rename to MIKEY-ECMQV also affects section 4.1.2. Thanks, Eugene. ------=_Part_108019_18172414.1161436451644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Section 3.3 - typo: server -> serve
"Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..."

Section 4.1 -
I've submitted an update to ietf-msec-mikey-ecc.  Where I think it was previously confusing, the draft now clearly identifies the 4 additional methods (1 added based on Steffen's comments):
- extending MIKEY-DHSIGN to use ECDSA
- extending MIKEY-DHSIGN to use ECDH
- MIKEY-ECIES
- MIKEY-ECMQV (renamed from MIKEY-MQV)

The rename to MIKEY-ECMQV also affects section 4.1.2.

Thanks,
Eugene.

------=_Part_108019_18172414.1161436451644-- --===============1277075771== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1277075771==-- From msec-bounces@ietf.org Sun Oct 22 23:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbq3m-0008Jf-CK; Sun, 22 Oct 2006 23:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbq3k-0008B9-U3 for msec@ietf.org; Sun, 22 Oct 2006 23:01:04 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbq3e-0004Lr-2N for msec@ietf.org; Sun, 22 Oct 2006 23:01:04 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7K005NAIWQMF@szxga01-in.huawei.com> for msec@ietf.org; Mon, 23 Oct 2006 10:58:02 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7K009VMIWQPR@szxga01-in.huawei.com> for msec@ietf.org; Mon, 23 Oct 2006 10:58:02 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7K00KAAJBHJ5@szxml04-in.huawei.com> for msec@ietf.org; Mon, 23 Oct 2006 11:06:56 +0800 (CST) Date: Mon, 23 Oct 2006 10:53:18 +0800 From: Liu Ya Subject: RE: [MSEC] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt In-reply-to: <02BEDDF0-D414-4160-A75D-E7FF1022A3D7@cisco.com> To: 'Mark Baugher' Message-id: <039701c6f64e$6540b7e0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acb0mlcYFA3ZwNtHQka0Q9+KGjRlxQBrEk9g X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, I have a question. What are the expected useage scenarios for GDOI + SRTP? I notice that in draft-wing-media-security-requirements-00.txt posted last week, the "shared key conferencing" requirement has been voted out-of-scope. It seems that the target RTPsec scenarions for GDOI usage do not exist any more.=20 Regards, Liu Ya=20 >=20 > hi > ?We wish to call you attention to this recent contribution on=20 > signaling SRTP crypto contexts using=A0ISAKMP GDOI.?Please=20 > direct your comments about this I-D to msec. >=20 > Thanks, Mark >=20 >=20 > Begin forwarded message: >=20 >=20 > From: Internet-Drafts@ietf.org > Date: October 16, 2006 12:50:01 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt?/SPAN> > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts?/SPAN> > directories. >=20 >=20 > Title : GDOI Key Establishment for the SRTP Data=20 > Security Protocol > Author(s) : M. Baugher, A. Rueegsegger > Filename : draft-baugher-msec-gdoi-srtp-00.txt > Pages : 19 > Date : 2006-10-16 >=20 > =09 > =09 >=20 > =A0=A0 The Secure Real-time Transport Protocol (SRTP)=20 > secures unicast and > =A0=A0 multicast media streams.?Multicast receivers of an SRTP stream > =A0=A0 therefore share an SRTP master key for multicast message > =A0=A0 authentication and decryption.?This document describes how to > =A0=A0 establish a shared, "group key" for an SRTP session=20 > using RFC 3547, > =A0=A0 the Group Domain of Interpretation (GDOI) and RFC=20 > 2408, the Internet > =A0=A0 Security Association and Key Management=20 > Protocol.?This document > =A0=A0 extends GDOI for SRTP group key establishment. >=20 >=20 >=20 > A URL for this Internet-Draft is: > =09 > http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi-sr > tp-00.txt >=20 > To remove yourself from the I-D Announcement list, send=20 > a message to?/SPAN> > i-d-announce-request@ietf.org with the word unsubscribe=20 > in the body of?/SPAN> > the message.?/SPAN> > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce?/SPAN> > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP.=20 > Login with the?/SPAN> > username "anonymous" and a password of your e-mail=20 > address. After?/SPAN> > logging in, type "cd internet-drafts" and then?/SPAN> > "get draft-baugher-msec-gdoi-srtp-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html?/SPAN> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt". >=20 > =09 > =09 >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility.?To use this > feature, insert the command "ENCODING mime" before the "FILE" > command.?To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader.?Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII=20 > version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-10-16121241.I-D@ietf.org> >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 >=20 >=20 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Oct 22 23:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbq3m-0008Jf-CK; Sun, 22 Oct 2006 23:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbq3k-0008B9-U3 for msec@ietf.org; Sun, 22 Oct 2006 23:01:04 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbq3e-0004Lr-2N for msec@ietf.org; Sun, 22 Oct 2006 23:01:04 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7K005NAIWQMF@szxga01-in.huawei.com> for msec@ietf.org; Mon, 23 Oct 2006 10:58:02 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7K009VMIWQPR@szxga01-in.huawei.com> for msec@ietf.org; Mon, 23 Oct 2006 10:58:02 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7K00KAAJBHJ5@szxml04-in.huawei.com> for msec@ietf.org; Mon, 23 Oct 2006 11:06:56 +0800 (CST) Date: Mon, 23 Oct 2006 10:53:18 +0800 From: Liu Ya Subject: RE: [MSEC] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt In-reply-to: <02BEDDF0-D414-4160-A75D-E7FF1022A3D7@cisco.com> To: 'Mark Baugher' Message-id: <039701c6f64e$6540b7e0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acb0mlcYFA3ZwNtHQka0Q9+KGjRlxQBrEk9g X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, I have a question. What are the expected useage scenarios for GDOI + SRTP? I notice that in draft-wing-media-security-requirements-00.txt posted last week, the "shared key conferencing" requirement has been voted out-of-scope. It seems that the target RTPsec scenarions for GDOI usage do not exist any more.=20 Regards, Liu Ya=20 >=20 > hi > ?We wish to call you attention to this recent contribution on=20 > signaling SRTP crypto contexts using=A0ISAKMP GDOI.?Please=20 > direct your comments about this I-D to msec. >=20 > Thanks, Mark >=20 >=20 > Begin forwarded message: >=20 >=20 > From: Internet-Drafts@ietf.org > Date: October 16, 2006 12:50:01 PM PDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt?/SPAN> > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts?/SPAN> > directories. >=20 >=20 > Title : GDOI Key Establishment for the SRTP Data=20 > Security Protocol > Author(s) : M. Baugher, A. Rueegsegger > Filename : draft-baugher-msec-gdoi-srtp-00.txt > Pages : 19 > Date : 2006-10-16 >=20 > =09 > =09 >=20 > =A0=A0 The Secure Real-time Transport Protocol (SRTP)=20 > secures unicast and > =A0=A0 multicast media streams.?Multicast receivers of an SRTP stream > =A0=A0 therefore share an SRTP master key for multicast message > =A0=A0 authentication and decryption.?This document describes how to > =A0=A0 establish a shared, "group key" for an SRTP session=20 > using RFC 3547, > =A0=A0 the Group Domain of Interpretation (GDOI) and RFC=20 > 2408, the Internet > =A0=A0 Security Association and Key Management=20 > Protocol.?This document > =A0=A0 extends GDOI for SRTP group key establishment. >=20 >=20 >=20 > A URL for this Internet-Draft is: > =09 > http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi-sr > tp-00.txt >=20 > To remove yourself from the I-D Announcement list, send=20 > a message to?/SPAN> > i-d-announce-request@ietf.org with the word unsubscribe=20 > in the body of?/SPAN> > the message.?/SPAN> > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce?/SPAN> > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP.=20 > Login with the?/SPAN> > username "anonymous" and a password of your e-mail=20 > address. After?/SPAN> > logging in, type "cd internet-drafts" and then?/SPAN> > "get draft-baugher-msec-gdoi-srtp-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html?/SPAN> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt". >=20 > =09 > =09 >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility.?To use this > feature, insert the command "ENCODING mime" before the "FILE" > command.?To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader.?Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII=20 > version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-10-16121241.I-D@ietf.org> >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 >=20 >=20 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Oct 22 23:17:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbqJK-0000FM-5j for msec-archive@lists.ietf.org; Sun, 22 Oct 2006 23:17:10 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbqJI-0006Gb-RR for msec-archive@lists.ietf.org; Sun, 22 Oct 2006 23:17:10 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B79522BAAC; Sun, 22 Oct 2006 23:16:30 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 074A42B957 for ; Sun, 22 Oct 2006 23:16:30 -0400 (EDT) Received: (qmail 4555 invoked by uid 3269); 23 Oct 2006 03:16:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4552 invoked from network); 23 Oct 2006 03:16:30 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 23 Oct 2006 03:16:30 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id E6956E9D84 for ; Sun, 22 Oct 2006 23:16:29 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mailwash15.pair.com (Postfix) with ESMTP id CBFA3E9D60 for ; Sun, 22 Oct 2006 23:16:29 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id t32so36032pyc for ; Sun, 22 Oct 2006 20:16:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=HP/3PwvFVn5Ft/gAYI+nTnEjN1qZri9jLNqy9EYMoaUUdyS7oFBkvmyp6edNEKNTdViBr9O1eRoYo6GgUnYW2yKxvLzCNJDvAsb1oKIeELiCfOk93UoDKUJxqf5Ok2ZarLTe87GbvEN3t/ARDRqAll+1wIzey+Xe2m2SIbrFync= Received: by 10.65.38.7 with SMTP id q7mr4552905qbj; Sun, 22 Oct 2006 20:16:29 -0700 (PDT) Received: by 10.65.185.14 with HTTP; Sun, 22 Oct 2006 20:16:29 -0700 (PDT) Message-ID: <625017e00610222016s3b6bdfc9icfd485e525b88642@mail.gmail.com> Date: Mon, 23 Oct 2006 11:16:29 +0800 From: liangjing To: msec@securemulticast.org MIME-Version: 1.0 Subject: [MSEC] Using XTR algorithm for MIKEY X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0953449921==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a --===============0953449921== Content-Type: multipart/alternative; boundary="----=_Part_84213_20984102.1161573389388" ------=_Part_84213_20984102.1161573389388 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all the following are our draft submitted. We will appreciate if you could review and comment on it. Many thanks -Jing A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : XTR algorithm for MIKEY Author(s) : J. Liang, et al. Filename : draft-liang-msec-mikey-xtr-00.txt Pages : 14 Date : 2006-10-17 This document proposes extensions to the encryption and digital signature methods described for use in MIKEY, employing a new method of public cryptographic algorithm called Efficient and Compact Subgroup Trace Representation (XTR stands for ECSTR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liang-msec-mikey-xtr-00.txt ------=_Part_84213_20984102.1161573389388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all

the following are our draft submitted.
We will appreciate if you could review and comment on it.

Many thanks

-Jing

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


       Title           : XTR algorithm for MIKEY
       Author(s)       : J. Liang, et al.
       Filename        : draft-liang-msec-mikey-xtr-00.txt
       Pages           : 14
       Date            : 2006-10-17

  This document proposes extensions to the encryption and digital
  signature methods described for use in MIKEY, employing a new method
  of public cryptographic algorithm called Efficient and Compact
  Subgroup Trace Representation (XTR stands for ECSTR).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-liang-msec-mikey-xtr-00.txt


------=_Part_84213_20984102.1161573389388-- --===============0953449921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0953449921==-- From msec-bounces@ietf.org Mon Oct 23 02:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtTV-00073p-7S; Mon, 23 Oct 2006 02:39:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtTT-00073Z-2E for msec@ietf.org; Mon, 23 Oct 2006 02:39:51 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbtTO-0004oc-G9 for msec@ietf.org; Mon, 23 Oct 2006 02:39:51 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k9N6djE5030217; Mon, 23 Oct 2006 08:39:45 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k9N6dbco024912; Mon, 23 Oct 2006 08:39:44 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 08:39:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE Date: Mon, 23 Oct 2006 08:38:34 +0200 Message-ID: In-Reply-To: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE Thread-Index: Acb1E2y+AJId2YLYSxmPXm9oj/myGQBWkasA From: "Fries, Steffen" To: "Eugene Chin" , X-OriginalArrivalTime: 23 Oct 2006 06:39:40.0765 (UTC) FILETIME=[046BD8D0:01C6F66E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0690105202==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============0690105202== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F66D.FA110F0E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F66D.FA110F0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eugene, =20 thanks for the comments, we will include it in the next version. I will also check, if we need to update the call flows with the updated ECC methods. =20 Regards Steffen ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com]=20 Sent: Saturday, October 21, 2006 3:14 PM To: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02,ending Oct 6, 2006 AOE Section 3.3 - typo: server -> serve "Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..." Section 4.1 - I've submitted an update to ietf-msec-mikey-ecc. Where I think it was previously confusing, the draft now clearly identifies the 4 additional methods (1 added based on Steffen's comments):=20 - extending MIKEY-DHSIGN to use ECDSA - extending MIKEY-DHSIGN to use ECDH - MIKEY-ECIES - MIKEY-ECMQV (renamed from MIKEY-MQV) The rename to MIKEY-ECMQV also affects section 4.1.2. Thanks, Eugene.=20 ------_=_NextPart_001_01C6F66D.FA110F0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Eugene,
 
thanks for the comments, we will include it in = the next=20 version. I will also check, if we need to update the call flows with the = updated=20 ECC methods.
 
Regards
    Steffen

From: Eugene Chin = [mailto:eugene.chin@gmail.com]=20
Sent: Saturday, October 21, 2006 3:14 PM
To:=20 msec@ietf.org
Subject: Re: [MSEC] WGLC on=20 draft-ietf-msec-mikey-applicability-02,ending Oct 6, 2006=20 AOE

Section 3.3 - typo: server -> serve
"Nevertheless, the=20 established Diffie-Hellman-Secret may server as a pre-shared=20 key..."

Section 4.1 -
I've submitted an update to=20 ietf-msec-mikey-ecc.  Where I think it was previously confusing, = the draft=20 now clearly identifies the 4 additional methods (1 added based on = Steffen's=20 comments):
- extending MIKEY-DHSIGN to use ECDSA
- extending = MIKEY-DHSIGN=20 to use ECDH
- MIKEY-ECIES
- MIKEY-ECMQV (renamed from=20 MIKEY-MQV)

The rename to MIKEY-ECMQV also affects section=20 4.1.2.

Thanks,
Eugene.

------_=_NextPart_001_01C6F66D.FA110F0E-- --===============0690105202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============0690105202==-- From msec-bounces@ietf.org Mon Oct 23 02:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtTV-00073p-7S; Mon, 23 Oct 2006 02:39:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtTT-00073Z-2E for msec@ietf.org; Mon, 23 Oct 2006 02:39:51 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbtTO-0004oc-G9 for msec@ietf.org; Mon, 23 Oct 2006 02:39:51 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k9N6djE5030217; Mon, 23 Oct 2006 08:39:45 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k9N6dbco024912; Mon, 23 Oct 2006 08:39:44 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 08:39:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE Date: Mon, 23 Oct 2006 08:38:34 +0200 Message-ID: In-Reply-To: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02, ending Oct 6, 2006 AOE Thread-Index: Acb1E2y+AJId2YLYSxmPXm9oj/myGQBWkasA From: "Fries, Steffen" To: "Eugene Chin" , X-OriginalArrivalTime: 23 Oct 2006 06:39:40.0765 (UTC) FILETIME=[046BD8D0:01C6F66E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0690105202==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============0690105202== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F66D.FA110F0E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F66D.FA110F0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eugene, =20 thanks for the comments, we will include it in the next version. I will also check, if we need to update the call flows with the updated ECC methods. =20 Regards Steffen ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com]=20 Sent: Saturday, October 21, 2006 3:14 PM To: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-mikey-applicability-02,ending Oct 6, 2006 AOE Section 3.3 - typo: server -> serve "Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..." Section 4.1 - I've submitted an update to ietf-msec-mikey-ecc. Where I think it was previously confusing, the draft now clearly identifies the 4 additional methods (1 added based on Steffen's comments):=20 - extending MIKEY-DHSIGN to use ECDSA - extending MIKEY-DHSIGN to use ECDH - MIKEY-ECIES - MIKEY-ECMQV (renamed from MIKEY-MQV) The rename to MIKEY-ECMQV also affects section 4.1.2. Thanks, Eugene.=20 ------_=_NextPart_001_01C6F66D.FA110F0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Eugene,
 
thanks for the comments, we will include it in = the next=20 version. I will also check, if we need to update the call flows with the = updated=20 ECC methods.
 
Regards
    Steffen

From: Eugene Chin = [mailto:eugene.chin@gmail.com]=20
Sent: Saturday, October 21, 2006 3:14 PM
To:=20 msec@ietf.org
Subject: Re: [MSEC] WGLC on=20 draft-ietf-msec-mikey-applicability-02,ending Oct 6, 2006=20 AOE

Section 3.3 - typo: server -> serve
"Nevertheless, the=20 established Diffie-Hellman-Secret may server as a pre-shared=20 key..."

Section 4.1 -
I've submitted an update to=20 ietf-msec-mikey-ecc.  Where I think it was previously confusing, = the draft=20 now clearly identifies the 4 additional methods (1 added based on = Steffen's=20 comments):
- extending MIKEY-DHSIGN to use ECDSA
- extending = MIKEY-DHSIGN=20 to use ECDH
- MIKEY-ECIES
- MIKEY-ECMQV (renamed from=20 MIKEY-MQV)

The rename to MIKEY-ECMQV also affects section=20 4.1.2.

Thanks,
Eugene.

------_=_NextPart_001_01C6F66D.FA110F0E-- --===============0690105202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============0690105202==-- From msec-bounces@ietf.org Mon Oct 23 11:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Qs-0005jT-5M; Mon, 23 Oct 2006 11:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Qq-0005jN-Pn for msec@ietf.org; Mon, 23 Oct 2006 11:09:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1Qk-0003sG-6p for msec@ietf.org; Mon, 23 Oct 2006 11:09:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2006 08:09:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NF9XTj020136; Mon, 23 Oct 2006 08:09:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NF9Xin024312; Mon, 23 Oct 2006 08:09:33 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 08:09:33 -0700 Received: from [192.168.0.10] ([10.21.152.173]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 08:09:32 -0700 In-Reply-To: <039701c6f64e$6540b7e0$480c6f0a@china.huawei.com> References: <039701c6f64e$6540b7e0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=GBK; delsp=yes; format=flowed Message-Id: <07EE6337-268C-4795-A1E0-20779BECD511@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt Date: Mon, 23 Oct 2006 08:09:31 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Oct 2006 15:09:32.0885 (UTC) FILETIME=[3EBEE850:01C6F6B5] DKIM-Signature: a=rsa-sha1; q=dns; l=4308; t=1161616173; x=1162480173; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Fwd=3A=20I-D=20ACTION=3Adraft-baugher-msec-gdoi-srtp-00 .txt; X=v=3Dcisco.com=3B=20h=3DNnzC1vdv34lOIOAZf1dAy4RQ68Q=3D; b=JGVofq0RlWUYKyKEQ3VYJtK8gVbVgjvWhBPo513wPxI03ZYVoec6h36MimQlt6riIZaKjn0e BEJnRmAigz01Z5kxkWGP1z+9ZsyE6glFVVMkeZbxa4hIRxdjXyXgDRgj; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Liu Ya, On Oct 22, 2006, at 7:53 PM, Liu Ya wrote: > Hi Mark, > > I have a question. What are the expected useage scenarios for GDOI + > SRTP? Broadcast, multicast, and conferencing are the applications that come =20= to my mind. If there is group keying for the application, then GDOI =20 is one way to manage those keys. > I notice that in draft-wing-media-security-requirements-00.txt > posted last week, the "shared key conferencing" requirement has been > voted out-of-scope. It seems that the target RTPsec scenarions for > GDOI usage do not exist any more. Personally, I see RTPsec as trying to solve problems with SIP =20 signaling of SRTP. Mark > > Regards, > Liu Ya > >> >> hi >> ?We wish to call you attention to this recent contribution on >> signaling SRTP crypto contexts using=A0ISAKMP GDOI.?Please >> direct your comments about this I-D to msec. >> >> Thanks, Mark >> >> >> Begin forwarded message: >> >> >> From: Internet-Drafts@ietf.org >> Date: October 16, 2006 12:50:01 PM PDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt?/SPAN> >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts?/SPAN> >> directories. >> >> >> Title : GDOI Key Establishment for the SRTP Data >> Security Protocol >> Author(s) : M. Baugher, A. Rueegsegger >> Filename : draft-baugher-msec-gdoi-srtp-00.txt >> Pages : 19 >> Date : 2006-10-16 >> >> =09 >> =09 >> >> =A0=A0 The Secure Real-time Transport Protocol (SRTP) >> secures unicast and >> =A0=A0 multicast media streams.?Multicast receivers of an SRTP > stream >> =A0=A0 therefore share an SRTP master key for multicast message >> =A0=A0 authentication and decryption.?This document describes = how > to >> =A0=A0 establish a shared, "group key" for an SRTP session >> using RFC 3547, >> =A0=A0 the Group Domain of Interpretation (GDOI) and RFC >> 2408, the Internet >> =A0=A0 Security Association and Key Management >> Protocol.?This document >> =A0=A0 extends GDOI for SRTP group key establishment. >> >> >> >> A URL for this Internet-Draft is: >> =09 >> http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi-sr >> tp-00.txt >> >> To remove yourself from the I-D Announcement list, send >> a message to?/SPAN> >> i-d-announce-request@ietf.org with the word unsubscribe >> in the body of?/SPAN> >> the message.?/SPAN> >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce?/SPAN> >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. >> Login with the?/SPAN> >> username "anonymous" and a password of your e-mail >> address. After?/SPAN> >> logging in, type "cd internet-drafts" and then?/SPAN> >> "get draft-baugher-msec-gdoi-srtp-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html?/SPAN> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt". >> >> =09 >> =09 >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility.?To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command.?To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader.?Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been > split >> up into multiple messages), so check your local documentation > on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail > reader >> implementation to automatically retrieve the ASCII >> version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-10-16121241.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >> _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Oct 23 11:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Qs-0005jT-5M; Mon, 23 Oct 2006 11:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Qq-0005jN-Pn for msec@ietf.org; Mon, 23 Oct 2006 11:09:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1Qk-0003sG-6p for msec@ietf.org; Mon, 23 Oct 2006 11:09:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2006 08:09:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NF9XTj020136; Mon, 23 Oct 2006 08:09:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NF9Xin024312; Mon, 23 Oct 2006 08:09:33 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 08:09:33 -0700 Received: from [192.168.0.10] ([10.21.152.173]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 08:09:32 -0700 In-Reply-To: <039701c6f64e$6540b7e0$480c6f0a@china.huawei.com> References: <039701c6f64e$6540b7e0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=GBK; delsp=yes; format=flowed Message-Id: <07EE6337-268C-4795-A1E0-20779BECD511@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] Fwd: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt Date: Mon, 23 Oct 2006 08:09:31 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Oct 2006 15:09:32.0885 (UTC) FILETIME=[3EBEE850:01C6F6B5] DKIM-Signature: a=rsa-sha1; q=dns; l=4308; t=1161616173; x=1162480173; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[MSEC]=20Fwd=3A=20I-D=20ACTION=3Adraft-baugher-msec-gdoi-srtp-00 .txt; X=v=3Dcisco.com=3B=20h=3DNnzC1vdv34lOIOAZf1dAy4RQ68Q=3D; b=JGVofq0RlWUYKyKEQ3VYJtK8gVbVgjvWhBPo513wPxI03ZYVoec6h36MimQlt6riIZaKjn0e BEJnRmAigz01Z5kxkWGP1z+9ZsyE6glFVVMkeZbxa4hIRxdjXyXgDRgj; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Liu Ya, On Oct 22, 2006, at 7:53 PM, Liu Ya wrote: > Hi Mark, > > I have a question. What are the expected useage scenarios for GDOI + > SRTP? Broadcast, multicast, and conferencing are the applications that come =20= to my mind. If there is group keying for the application, then GDOI =20 is one way to manage those keys. > I notice that in draft-wing-media-security-requirements-00.txt > posted last week, the "shared key conferencing" requirement has been > voted out-of-scope. It seems that the target RTPsec scenarions for > GDOI usage do not exist any more. Personally, I see RTPsec as trying to solve problems with SIP =20 signaling of SRTP. Mark > > Regards, > Liu Ya > >> >> hi >> ?We wish to call you attention to this recent contribution on >> signaling SRTP crypto contexts using=A0ISAKMP GDOI.?Please >> direct your comments about this I-D to msec. >> >> Thanks, Mark >> >> >> Begin forwarded message: >> >> >> From: Internet-Drafts@ietf.org >> Date: October 16, 2006 12:50:01 PM PDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-baugher-msec-gdoi-srtp-00.txt?/SPAN> >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts?/SPAN> >> directories. >> >> >> Title : GDOI Key Establishment for the SRTP Data >> Security Protocol >> Author(s) : M. Baugher, A. Rueegsegger >> Filename : draft-baugher-msec-gdoi-srtp-00.txt >> Pages : 19 >> Date : 2006-10-16 >> >> =09 >> =09 >> >> =A0=A0 The Secure Real-time Transport Protocol (SRTP) >> secures unicast and >> =A0=A0 multicast media streams.?Multicast receivers of an SRTP > stream >> =A0=A0 therefore share an SRTP master key for multicast message >> =A0=A0 authentication and decryption.?This document describes = how > to >> =A0=A0 establish a shared, "group key" for an SRTP session >> using RFC 3547, >> =A0=A0 the Group Domain of Interpretation (GDOI) and RFC >> 2408, the Internet >> =A0=A0 Security Association and Key Management >> Protocol.?This document >> =A0=A0 extends GDOI for SRTP group key establishment. >> >> >> >> A URL for this Internet-Draft is: >> =09 >> http://www.ietf.org/internet-drafts/draft-baugher-msec-gdoi-sr >> tp-00.txt >> >> To remove yourself from the I-D Announcement list, send >> a message to?/SPAN> >> i-d-announce-request@ietf.org with the word unsubscribe >> in the body of?/SPAN> >> the message.?/SPAN> >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce?/SPAN> >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. >> Login with the?/SPAN> >> username "anonymous" and a password of your e-mail >> address. After?/SPAN> >> logging in, type "cd internet-drafts" and then?/SPAN> >> "get draft-baugher-msec-gdoi-srtp-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html?/SPAN> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-baugher-msec-gdoi-srtp-00.txt". >> >> =09 >> =09 >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility.?To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command.?To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader.?Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been > split >> up into multiple messages), so check your local documentation > on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail > reader >> implementation to automatically retrieve the ASCII >> version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-10-16121241.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >> _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Oct 25 04:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GceO2-00052l-Hd; Wed, 25 Oct 2006 04:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GceO0-00052g-IP for msec@ietf.org; Wed, 25 Oct 2006 04:45:20 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GceNy-00024v-LL for msec@ietf.org; Wed, 25 Oct 2006 04:45:20 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7O0054YOSZGA@szxga03-in.huawei.com> for msec@ietf.org; Wed, 25 Oct 2006 16:55:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7O005CAOSZ20@szxga03-in.huawei.com> for msec@ietf.org; Wed, 25 Oct 2006 16:55:47 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7O00IMGOW4QQ@szxml04-in.huawei.com> for msec@ietf.org; Wed, 25 Oct 2006 16:57:44 +0800 (CST) Date: Wed, 25 Oct 2006 16:43:59 +0800 From: Liu Ya In-reply-to: <02BEDDF0-D414-4160-A75D-E7FF1022A3D7@cisco.com> To: 'Mark Baugher' Message-id: <07b401c6f811$ba31dbc0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acb0mlcYFA3ZwNtHQka0Q9+KGjRlxQCgQe2Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: msec@ietf.org Subject: [MSEC] Some comments on draft-baugher-msec-gdoi-srtp-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, Some comments are proposed below. 1, In paragraph 2 of section 2, the doc writes: "... Using this protocol extension, the GDOI Group Controller/Key Server (GCKS) provides the cryptographic keys, policies and other attributes to SRTP (via the API to a GDOI Member). ..." There are different meanings in above sentence. Such an understanding might be gotten that those parameters are directly provided from GCKS to SRTP via the API. In fact, two steps are needed for that purpose. Firstly, parameters are transported from GCKS to GDOI Member through GDOI signalling channel, then provided to SRTP via the API between SRTP and GDOI Member. 2, Two figures are given in the beginning of section 2. The first one, Figure 2.0-1, is explicitly explained as a logical diagram. While no clear text is given to the second one, which is interpreted in paragraph 3 of section 2. After reading paragraph 3, I get a strong apprehension that Fig. 2.0-2 is a physical diagram. However, the same illustrating method are used for the two figures. It is better to emphasize the physical entities of SRTP source and SRTP receiver in Fig. 2.0-2, such as, in my suggestion, illustrating the left two logical entities into a physical sender, the right two logical ones into a physical receiver. 3, The case of multiple SSRCs within one RTP session is considered in both RTP [RFC3550] and SRTP [RFC3711]. When GDOI is used in such case, it is possible that multiple SSRCs need to be transported from GCKS to SRTP receivers. However, only one SSRC field space is assgined in SA-TEK, which is defined in section 2.2. 4, When interpreting the SA-TEK's MKI Leghth field in section 2.2, page 9, the word 'indicator' is used improperly. MKI is the abbreviation for Master Key Identifier, not Master Key Indicator [RFC3771]. And in section 3.2.1 of RFC3711, a special parameter called MKI indicator is defined for SRTP cryptographic context, indicating whether an MKI is present in SRTP packets. To distinguish MKI and MKI indicator, it's better to avoid using the word 'indicator' here. Regards, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Oct 25 04:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GceO2-00052l-Hd; Wed, 25 Oct 2006 04:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GceO0-00052g-IP for msec@ietf.org; Wed, 25 Oct 2006 04:45:20 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GceNy-00024v-LL for msec@ietf.org; Wed, 25 Oct 2006 04:45:20 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7O0054YOSZGA@szxga03-in.huawei.com> for msec@ietf.org; Wed, 25 Oct 2006 16:55:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7O005CAOSZ20@szxga03-in.huawei.com> for msec@ietf.org; Wed, 25 Oct 2006 16:55:47 +0800 (CST) Received: from l52008 ([10.111.12.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7O00IMGOW4QQ@szxml04-in.huawei.com> for msec@ietf.org; Wed, 25 Oct 2006 16:57:44 +0800 (CST) Date: Wed, 25 Oct 2006 16:43:59 +0800 From: Liu Ya In-reply-to: <02BEDDF0-D414-4160-A75D-E7FF1022A3D7@cisco.com> To: 'Mark Baugher' Message-id: <07b401c6f811$ba31dbc0$480c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acb0mlcYFA3ZwNtHQka0Q9+KGjRlxQCgQe2Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: msec@ietf.org Subject: [MSEC] Some comments on draft-baugher-msec-gdoi-srtp-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mark, Some comments are proposed below. 1, In paragraph 2 of section 2, the doc writes: "... Using this protocol extension, the GDOI Group Controller/Key Server (GCKS) provides the cryptographic keys, policies and other attributes to SRTP (via the API to a GDOI Member). ..." There are different meanings in above sentence. Such an understanding might be gotten that those parameters are directly provided from GCKS to SRTP via the API. In fact, two steps are needed for that purpose. Firstly, parameters are transported from GCKS to GDOI Member through GDOI signalling channel, then provided to SRTP via the API between SRTP and GDOI Member. 2, Two figures are given in the beginning of section 2. The first one, Figure 2.0-1, is explicitly explained as a logical diagram. While no clear text is given to the second one, which is interpreted in paragraph 3 of section 2. After reading paragraph 3, I get a strong apprehension that Fig. 2.0-2 is a physical diagram. However, the same illustrating method are used for the two figures. It is better to emphasize the physical entities of SRTP source and SRTP receiver in Fig. 2.0-2, such as, in my suggestion, illustrating the left two logical entities into a physical sender, the right two logical ones into a physical receiver. 3, The case of multiple SSRCs within one RTP session is considered in both RTP [RFC3550] and SRTP [RFC3711]. When GDOI is used in such case, it is possible that multiple SSRCs need to be transported from GCKS to SRTP receivers. However, only one SSRC field space is assgined in SA-TEK, which is defined in section 2.2. 4, When interpreting the SA-TEK's MKI Leghth field in section 2.2, page 9, the word 'indicator' is used improperly. MKI is the abbreviation for Master Key Identifier, not Master Key Indicator [RFC3771]. And in section 3.2.1 of RFC3711, a special parameter called MKI indicator is defined for SRTP cryptographic context, indicating whether an MKI is present in SRTP packets. To distinguish MKI and MKI indicator, it's better to avoid using the word 'indicator' here. Regards, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Oct 25 23:48:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcwEI-0005Yl-C4 for msec-archive@lists.ietf.org; Wed, 25 Oct 2006 23:48:30 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcwEH-0001ll-2D for msec-archive@lists.ietf.org; Wed, 25 Oct 2006 23:48:30 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6ED252C9BB; Wed, 25 Oct 2006 23:48:18 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 999612CBB4 for ; Wed, 25 Oct 2006 23:48:15 -0400 (EDT) Received: (qmail 7942 invoked by uid 3269); 26 Oct 2006 03:48:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7938 invoked from network); 26 Oct 2006 03:48:15 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 26 Oct 2006 03:48:15 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 95E35E9D2B for ; Wed, 25 Oct 2006 23:48:15 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by mailwash15.pair.com (Postfix) with ESMTP id 74001E9D29 for ; Wed, 25 Oct 2006 23:48:15 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id i11so290398nzh for ; Wed, 25 Oct 2006 20:48:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=Vnq9gN47j4qHvBKSvaZIsG0Apt0zIvLbn3h1lp4Ema8ntl421Wh+YzpTqyD5qYttBhsqQ4tpxf6A/tea1NmuguaFj9XNoMEWPNsFE+NngDyVg8Rzn6ROq7XieZM88D2pbVBY0ABZNPHkXUTilyM/mg1KFdDjKTT5BqFUZpdUHT8= Received: by 10.65.97.18 with SMTP id z18mr2210740qbl; Wed, 25 Oct 2006 20:48:14 -0700 (PDT) Received: by 10.65.185.14 with HTTP; Wed, 25 Oct 2006 20:48:14 -0700 (PDT) Message-ID: <625017e00610252048i1b8e2361y53ee33c6cbefb2ea@mail.gmail.com> Date: Thu, 26 Oct 2006 11:48:14 +0800 From: liangjing To: mblaser@certicom.com, dbrown@certicom.com, ldondeti@qualcomm.com MIME-Version: 1.0 Cc: msec@securemulticast.org Subject: [MSEC] Comments on draft-ietf-msec-mikey-ecc-01 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0439934061==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 --===============0439934061== Content-Type: multipart/alternative; boundary="----=_Part_21086_20006500.1161834494658" ------=_Part_21086_20006500.1161834494658 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, After reading your draft, I still have a question about the ECDH use in MIKEY. As you have stated in your draft that to use ECDH and ECDSA signature algorithm, this extension to MIKEY-DHSIGN may be combined with the extension described in Section 2 , but my question is as you have used the signature algorithm to generate the SIGi and SIGr, why not use this algorithm to generate the TGK as well. One side of the communication party can choice a random number as the TGK , and after encrypting it with the other side's public key, both of them will get the TGK key quickly than using ECDH to generate the key material of encr_key and auth_key and generate the TGK from these keys. Best Regards Jing ------=_Part_21086_20006500.1161834494658 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
After reading your draft, I still have a question about the ECDH use in MIKEY.
As you have stated in your draft that to use ECDH and ECDSA signature algorithm, this extension to MIKEY-DHSIGN may be combined with the extension described in Section 2 , but my question is as you have used the signature algorithm to generate the SIGi and SIGr, why not use this algorithm to generate the TGK as well. One side of the communication party can choice a random number as the TGK , and after encrypting it with the other side's public key, both of them will get the TGK key quickly than using ECDH to generate the key material of encr_key and auth_key and generate the TGK from these keys.
 
Best Regards
Jing
------=_Part_21086_20006500.1161834494658-- --===============0439934061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0439934061==-- From msec-bounces@securemulticast.org Thu Oct 26 07:16:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd3Du-0002EC-CU for msec-archive@lists.ietf.org; Thu, 26 Oct 2006 07:16:34 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd3Dl-0000iZ-O3 for msec-archive@lists.ietf.org; Thu, 26 Oct 2006 07:16:34 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2C1502C1B8; Thu, 26 Oct 2006 07:16:15 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 720622B8B4 for ; Thu, 26 Oct 2006 07:16:14 -0400 (EDT) Received: (qmail 41957 invoked by uid 3269); 26 Oct 2006 11:16:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41954 invoked from network); 26 Oct 2006 11:16:14 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 26 Oct 2006 11:16:14 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 5DD20E9D2A for ; Thu, 26 Oct 2006 07:16:14 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mailwash15.pair.com (Postfix) with ESMTP id 00797E9D1F for ; Thu, 26 Oct 2006 07:16:13 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id q29so1072472nfc for ; Thu, 26 Oct 2006 04:16:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FMUFC//qPY0Nl0sQK7gxuDkXrpHuIKsGyJxk0zMVVqE5D3Bb3F0mBpse+utocXjLYM30ANjWDD9GcIfGaBzk06PbGWZOEaIETCpjlL4tRmUvlAIY/pRl5fWjn2z6YMWJW/KjE65Baxne7Ous9M0FNQYouZ8Eqn2RIwYxBCByUPE= Received: by 10.82.129.8 with SMTP id b8mr398757bud; Thu, 26 Oct 2006 04:16:12 -0700 (PDT) Received: by 10.82.148.6 with HTTP; Thu, 26 Oct 2006 04:16:12 -0700 (PDT) Message-ID: <8ba53040610260416s6d33c8a1mb871b0f436d8a5e@mail.gmail.com> Date: Thu, 26 Oct 2006 07:16:12 -0400 From: "Eugene Chin" To: liangjing Subject: Re: [MSEC] Comments on draft-ietf-msec-mikey-ecc-01 In-Reply-To: <625017e00610252048i1b8e2361y53ee33c6cbefb2ea@mail.gmail.com> MIME-Version: 1.0 References: <625017e00610252048i1b8e2361y53ee33c6cbefb2ea@mail.gmail.com> Cc: dbrown@certicom.com, echin@certicom.com, msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1302720588==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 --===============1302720588== Content-Type: multipart/alternative; boundary="----=_Part_34880_6658386.1161861372611" ------=_Part_34880_6658386.1161861372611 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > and after encrypting it with the other side's public key, both of them > will get the TGK key quickly > Hi Jing, Thank you for the review. What you have described is actually MIKEY-ECIES. To encrypt it with the public key, we use the ECIES algorithm. This is parallel to the MIKEY-RSA case where we encrypt it using the envelope key. Except with ECIES, the way the algorithm is, the envelope key is not required. I hope that answers your question. Thanks, Eugene. ------=_Part_34880_6658386.1161861372611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
and after encrypting it with the other side's public key, both of them will get the TGK key quickly

Hi Jing,

Thank you for the review.

What you have described is actually MIKEY-ECIES.  To encrypt it with the public key, we use the ECIES algorithm.  This is parallel to the MIKEY-RSA case where we encrypt it using the envelope key.  Except with ECIES, the way the algorithm is, the envelope key is not required.  I hope that answers your question.

Thanks,
Eugene.
------=_Part_34880_6658386.1161861372611-- --===============1302720588== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1302720588==-- From desiliconization@transmediahome.com Thu Oct 26 09:07:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4xD-00053r-To for msec-archive@ietf.org; Thu, 26 Oct 2006 09:07:27 -0400 Received: from [81.215.44.240] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gd4x9-00055f-2w for msec-archive@ietf.org; Thu, 26 Oct 2006 09:07:27 -0400 Message-ID: <000001c6f8fe$d70d6a00$0100007f@localhost> From: "XP Software" To: Subject: New software uploaded by Mildred on Oct 26 16:50:00 MSK 2006 Date: Thu, 26 Oct 2006 16:06:56 +0300 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.150 X-Spam-Score: 1.8 (+) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Mildred has uploaded some new software for you! View your available uploaded software from Mildred @ www. allnewoem .net hostname - print/set hostname .berkeley.edu CS.BERKELEY.EDU such systems. device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector in Japan (it is called 2?0SX here in U.S.). whether Jordan looks like a toon ferret or not, whether or not SUP gets the information it needs to run from a configuration file You will notice that near the end of the default kernel configuration initially in PC clone computers by vendors who used "clean" BIOS from a kernel that crashes during booting. modem is able to ask the sending modem to resend a block of data that the matching return statement is reached by The boot message identifier for this drive is "ARCHIVE VIPER 2525 Comments to the above script: process. You will need to know, at the minimum, your service determine the true cause(s) of the interrupt. any new interrupts will be generated. You configure LPD by editing the file /etc/printcap. The LPD spooling Splitting of the console driver into abstraction layers, both to effect, things like ``delete line 23'', ``add these two lines after conversion filters for your favorite file formats (besides plain ASCII Working from older sources unfortunately means that your changes may can be, and how large the printer queues can get. www.freebsd. Indent the output by number columns; if you omit number, indent there are periods of time when the sources are literally un- 10.3.9. * Other Why can't it find it? Have I got a dud CDROM? hackersFreeBSD>. Someone will very likely get back in touch with nel and most likely not do anything at all since the crash dump and set command bytesize 8 terminal special file /dev/tty0?, if it exists. For backup purposes, I'd have to give the higher recommendation to the 5 deny lqr for that host, directly to it over the ethernet interface, ed0. There 300 MB and go up to 7 GB. Hardware compression, available with most work well with FreeBSD. Like other UNIX-like operating systems, # cd /dev You may wish to not include them for simplicity. two can communicate (unless you have an internal modem, which does port[,port[,port[...]]] swap device (e.g. an MS Windows swap file). Optional. Tape Media This drive is identical to the Quantum DLT2000. The drive firmware just run it through CTM to keep your sources up to date. FreeBSD 2.1.1. like to be such a mirror, please contact the FreeBSD project $%&'()*+,-./01234567 # $Id: porting.sgml,v 1.2.4.5 1996/06/19 20:28:08 jkh Exp $ zpintr 10.3.4. * Parallel ports 600: or by editing /etc/make.conf, but this doesn't always seem to get job. If users want to spend time searching for their printouts, they :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ not have the name of the package at the beginning, as in: 5. Set the password for root and toor (and any other accounts that port skeleton, let's get a whole sub-directory, for example all the ===> Building for bash-1.14.5 controller snd0 hostname myclient.mydomain filesystems for each client. If anyone has any suggestions on how to again, with the new df capability for the printer bamboo while still maintaining interactive response to other users. this line should always be 127.0.0.1. The second line maps the name 18.2.5.4.5. PATCHFILES It won't prevent Mathematica from running in any way and you can directory, a directory where print jobs reside until they are printed, packets coming through this interface. Interface unit numbers can be # Simply copies stdin to stdout. Ignores all filter arguments. they really are enabled. An easy way to do this is to run quota -v. We have also taken the comments and suggestions of many of our users usually goes out on the second try. frequently have a hidden buffer consisting of several hundred bytes. 10.4.1.5. Thanks to... Processor emulation environments for execution of foreign binaries. netmask are The final line (destination subnet 224) deals with MultiCasting, which # format the floppy user interface (GUI) for the cost of a common VGA card and monitor From kgdb do: option in the Options menu before installation can proceed. I successfully installed FreeBSD onto a ESDI disk controlled by a Enter secret password: in your kernel's config file. It is included in the GENERIC kernel, way'' works in practice by combining a set of simple but very flexible PostScript Printers'' tells how to do this. Host restrictions debugging gated's activity; you can certainly turn off the tracing will be running both FreeBSD and NT or OS/2. In such a scenario, I Printerleaf files (files from the Interleaf desktop publishing only certain hosts can gain access to the servers, and often they can Password:ADEN BED WOLF HAW HOT STUN gateway address for your local network. So (using the same example), files are correctly deleted. Then do a `pkg_add .tgz' and system's console - if it lights up, that should mean that FreeBSD has FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source . ipfw add accept from any to sup.FreeBSD 871 we generally, in fact, give them write access to the project's CVS o Finally, use whatever works. If you are inside the United States, you may also uncomment the software (in the ports collection) allows you to access DOS buy but are sometimes unwilling to pay the price required to get the The tape does not contain an Identifier Block (block number 0). All % used, and the user is authenticated if the hash of the user-provided tion. pseudo-device sl number called the "Start Bit" is added to the beginning of each word that is administrative one; it does not mean the person concerned is an example command) most SCSI CDROM drives I've seen have been of pretty solid ===> Patching for bash-1.14.5 Parallel port Note: If your SoundBlaster is on a different IRQ (such as probably never affect the operation of a properly written driver) the FreeBSD slice) is used. In this way, the bad144 replacement signals on the pins that the DTE device transmits on, and vice versa. that unused 386 or 486 PC sitting in the corner into an advanced get garbage, try pressing about once per second. If you still /etc/master.passwd would look something like this (except it would be next-generation development. Around the time that 2.2-RELEASE is From msec-bounces@securemulticast.org Thu Oct 26 22:37:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdHav-0000Fc-Oa for msec-archive@lists.ietf.org; Thu, 26 Oct 2006 22:37:17 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdHaf-0005dN-W6 for msec-archive@lists.ietf.org; Thu, 26 Oct 2006 22:37:04 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 999942CCE8; Thu, 26 Oct 2006 22:36:51 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 03C7D2CD3C for ; Thu, 26 Oct 2006 22:36:50 -0400 (EDT) Received: (qmail 77293 invoked by uid 3269); 27 Oct 2006 02:36:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77134 invoked from network); 27 Oct 2006 02:35:38 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 27 Oct 2006 02:35:38 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 7CCE6E9D94 for ; Thu, 26 Oct 2006 22:35:38 -0400 (EDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mailwash15.pair.com (Postfix) with ESMTP id 5B0AAE9D93 for ; Thu, 26 Oct 2006 22:35:38 -0400 (EDT) Received: by nz-out-0102.google.com with SMTP id i11so547702nzh for ; Thu, 26 Oct 2006 19:35:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=Kf9WSVjM1CW6377BVHz6JFR/jB37d3YaUoG9R9sKK6p2RyYC6AMOSUFZg2rCKxDW/IDdikiuAdfBFhi0u9L8yMd2NLzlayheQAWzQG1zel3Uxz7zgkDNYH8JxZbU/NjDiFkMlm42db/kPTn9slVJI5/weNZ4LJ6N83dWiJeGn0c= Received: by 10.64.180.4 with SMTP id c4mr4273150qbf; Thu, 26 Oct 2006 19:35:37 -0700 (PDT) Received: by 10.64.148.15 with HTTP; Thu, 26 Oct 2006 19:35:36 -0700 (PDT) Message-ID: <625017e00610261935r36d59784v49eb278502bc652a@mail.gmail.com> Date: Fri, 27 Oct 2006 10:35:37 +0800 From: liangjing To: eugene.chin@gmail.com MIME-Version: 1.0 Cc: dbrown@certicom.com, echin@certicom.com, msec@securemulticast.org Subject: [MSEC] comments on using ECC algorithm on MIKEY X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2069150966==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============2069150966== Content-Type: multipart/alternative; boundary="----=_Part_35015_24270038.1161916537043" ------=_Part_35015_24270038.1161916537043 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Eugene ** Thank you for your reply explaining the various use of ECC algorithm. Working with elliptic curves requires the generation of curve parameters, which involves a complex procedure known as 'point counting'. Your draft proposed the ECC groups given are among the fifteen groups that NIST recommends in FIPS 186-2[FIPS-186-2]. I have a doubt that as the group parameters below are open to public , how could it be secure if using large distributed computers to compute the value of the operation i * P, and then figure out the secret value i based on the KEi (i * P) and P which are public value in the message exchage. i = r = KEi = KEr = Z = And as I wrote a draft[draft-liang-msec-mikey-xtr-00] based on the Diffie-Hellman key agreement protocol and RFC3830, but using the XTR algorithm instead of ECC algorithm. In cryptography, XTR is an algorithm for public-key encryption. XTR stands for 'ECSTR', which is an abbreviation for Efficient and Compact Subgroup Trace Representation. It is a novel method that makes use of traces to represent and calculate powers of elements of a subgroup of a finite field. It is based on the primitive underlying the very first public key cryptosystem, the Diffie-Hellman key agreement protocol. >From a security point of view, XTR is a traditional discrete logarithm system: For its security it relies on the difficulty of solving discrete logarithm related problems in the multiplicative group of a finite field. Some advantages of XTR are its fast key generation (much faster than RSA), small key sizes (much smaller than RSA, comparable with ECC for current security settings), and speed (overall comparable with ECC for current security settings). I wonder if this algorithm is suitable if you have any comment please let me know. Best Regards Jing ------=_Part_35015_24270038.1161916537043 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Eugene
Thank you for your reply explaining the various use of ECC algorithm.
 
Working with elliptic curves requires the generation of curve parameters, which involves a complex procedure known as 'point counting'.
 
Your draft proposed the ECC groups given are among the fifteen groups that NIST recommends in FIPS 186-2[FIPS-186-2].

I have a doubt that as the group parameters below are open to public , how could it be secure if using large distributed computers to compute the value of the operation i * P, and then figure out the secret value i based on the KEi (i * P) and P which are public value in the message exchage.
i = <initiator secret value>
r = <responder secret value>
KEi = <initiator key exchange payload>
KEr = <responder key exchange payload>
Z = <raw shared secret>
 
And as I wrote a draft[draft-liang-msec-mikey-xtr-00] based on the Diffie-Hellman key agreement protocol and RFC3830, but using the XTR algorithm instead of ECC algorithm.

In cryptography, XTR is an algorithm for public-key encryption. XTR stands for 'ECSTR', which is an abbreviation for Efficient and Compact Subgroup Trace Representation.

It is a novel method that makes use of traces to represent and calculate powers of elements of a subgroup of a finite field. It is based on the primitive underlying the very first public key cryptosystem, the Diffie-Hellman key agreement protocol.

From a security point of view, XTR is a traditional discrete logarithm system: For its security it relies on the difficulty of solving discrete logarithm related problems in the multiplicative group of a finite field. Some advantages of XTR are its fast key generation (much faster than RSA), small key sizes (much smaller than RSA, comparable with ECC for current security settings), and speed (overall comparable with ECC for current security settings).
I wonder if this algorithm is suitable if you have any comment please let me know.
 
Best Regards
Jing
 
------=_Part_35015_24270038.1161916537043-- --===============2069150966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============2069150966==-- From msec-bounces@ietf.org Fri Oct 27 19:23:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb2K-0003nK-Ti; Fri, 27 Oct 2006 19:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxO-0007dV-Mm for msec@ietf.org; Fri, 27 Oct 2006 19:17:46 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdair-0000Cp-BT for msec@ietf.org; Fri, 27 Oct 2006 19:02:46 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9RN2hX3016607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Oct 2006 16:02:44 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-47.qualcomm.com [10.50.65.47]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9RN2fml025693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Oct 2006 16:02:43 -0700 (PDT) Message-Id: <7.0.1.0.2.20061027155914.041a1830@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 27 Oct 2006 16:02:35 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [MSEC] MSEC Agenda at IETF-67 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, The first version of the MSEC agenda has been uploaded. Please let me know if I left out anything. I am generally assuming about 10 minutes for presentation and discussion. If anyone needs more time, please let me know. http://www3.ietf.org/proceedings/06nov/agenda/msec.txt Also, please volunteer to take minutes at the meeting. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Oct 27 19:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb2K-0003nK-Ti; Fri, 27 Oct 2006 19:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxO-0007dV-Mm for msec@ietf.org; Fri, 27 Oct 2006 19:17:46 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdair-0000Cp-BT for msec@ietf.org; Fri, 27 Oct 2006 19:02:46 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9RN2hX3016607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Oct 2006 16:02:44 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-47.qualcomm.com [10.50.65.47]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9RN2fml025693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Oct 2006 16:02:43 -0700 (PDT) Message-Id: <7.0.1.0.2.20061027155914.041a1830@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 27 Oct 2006 16:02:35 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [MSEC] MSEC Agenda at IETF-67 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, The first version of the MSEC agenda has been uploaded. Please let me know if I left out anything. I am generally assuming about 10 minutes for presentation and discussion. If anyone needs more time, please let me know. http://www3.ietf.org/proceedings/06nov/agenda/msec.txt Also, please volunteer to take minutes at the meeting. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Oct 28 14:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdsT2-0007qE-Dh; Sat, 28 Oct 2006 13:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdsSx-0007pa-D9 for msec@ietf.org; Sat, 28 Oct 2006 13:59:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdsSw-0002M6-17 for msec@ietf.org; Sat, 28 Oct 2006 13:59:31 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2006 10:59:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9SHxTMY009833; Sat, 28 Oct 2006 10:59:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9SHxSAo013030; Sat, 28 Oct 2006 10:59:28 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 10:59:28 -0700 Received: from [192.168.0.10] ([10.21.147.3]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 10:59:27 -0700 In-Reply-To: <07b401c6f811$ba31dbc0$480c6f0a@china.huawei.com> References: <07b401c6f811$ba31dbc0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E97D706-AE26-42F1-BC1B-0CDFBD29AD22@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Sat, 28 Oct 2006 10:59:23 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Oct 2006 17:59:27.0973 (UTC) FILETIME=[CF8EA150:01C6FABA] DKIM-Signature: a=rsa-sha1; q=dns; l=3269; t=1162058369; x=1162922369; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20Some=20comments=20on=20draft-baugher-msec-gdoi-srtp-00.txt; X=v=3Dcisco.com=3B=20h=3D8b+qqwi/myn66vcMJudkyeo7nho=3D; b=L3HK19slRcRgU7PEFVXeZgUsnPPDkld6pT7SqLsRrjAZlgEsja2JXN9t1aszfvsMPVewB4lA jHh+rmsignpFU6bgMBo0hqDZ0l3z2bukBGAormsHOnfXvKMBrF+uP++1; Authentication-Results: sj-dkim-4.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: msec@ietf.org, =?ISO-8859-1?Q?Adrian-Ken_R=FCegsegger?= Subject: [MSEC] Re: Some comments on draft-baugher-msec-gdoi-srtp-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Liu Ya Thanks for your comments. See inline, below... On Oct 25, 2006, at 1:43 AM, Liu Ya wrote: > Hi Mark, > > Some comments are proposed below. > > 1, In paragraph 2 of section 2, the doc writes: > "... Using this protocol extension, the GDOI Group Controller/Key > Server (GCKS) provides the cryptographic keys, policies and other > attributes to SRTP (via the API to a GDOI Member). ..." > > There are different meanings in above sentence. Such an understanding > might be gotten that those parameters are directly provided from GCKS > to SRTP via the API. In fact, two steps are needed for that purpose. > Firstly, parameters are transported from GCKS to GDOI Member through > GDOI signalling channel, then provided to SRTP via the API between > SRTP and GDOI Member. That's what we intended. Please propose new text if what we wrote is not clear enough. > > 2, Two figures are given in the beginning of section 2. The first one, > Figure 2.0-1, is explicitly explained as a logical diagram. While no > clear text is given to the second one, which is interpreted in > paragraph 3 of section 2. After reading paragraph 3, I get a strong > apprehension that Fig. 2.0-2 is a physical diagram. However, the same > illustrating method are used for the two figures. It is better to > emphasize the physical entities of SRTP source and SRTP receiver in > Fig. 2.0-2, such as, in my suggestion, illustrating the left two > logical entities into a physical sender, the right two logical ones > into a physical receiver. That's our intention and that's why we introduced Fig. 2.0-2 as being a "physical realization". We rely on an assumption that an API operates between two entities on the same computer. I think drawing a box around them as you suggest in a subsequent note to this list adds clarity and we should include that in the next revision. > > 3, The case of multiple SSRCs within one RTP session is considered in > both RTP [RFC3550] and SRTP [RFC3711]. When GDOI is used in such case, > it is possible that multiple SSRCs need to be transported from GCKS to > SRTP receivers. However, only one SSRC field space is assgined in > SA-TEK, which is defined in section 2.2. The SA-TEK is going to be changed substantially in the next draft. I personally did the diagram. Brian and Adrian suggested some improvements, but we ran out of time before the submission deadline. Adrian revised the text and you'll see that in the next revision of this I-D. I do expect that we will have one SA-TEK for each session from a given source. It is also possible to have one SA-TEK and one from other sources to a given session. > > 4, When interpreting the SA-TEK's MKI Leghth field in section 2.2, > page 9, the word 'indicator' is used improperly. MKI is the > abbreviation for Master Key Identifier, not Master Key Indicator > [RFC3771]. And in section 3.2.1 of RFC3711, a special parameter called > MKI indicator is defined for SRTP cryptographic context, indicating > whether an MKI is present in SRTP packets. To distinguish MKI and MKI > indicator, it's better to avoid using the word 'indicator' here. Agreed. Thanks, Mark > > > Regards, > Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Oct 28 14:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdsT2-0007qE-Dh; Sat, 28 Oct 2006 13:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdsSx-0007pa-D9 for msec@ietf.org; Sat, 28 Oct 2006 13:59:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdsSw-0002M6-17 for msec@ietf.org; Sat, 28 Oct 2006 13:59:31 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2006 10:59:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9SHxTMY009833; Sat, 28 Oct 2006 10:59:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9SHxSAo013030; Sat, 28 Oct 2006 10:59:28 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 10:59:28 -0700 Received: from [192.168.0.10] ([10.21.147.3]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 10:59:27 -0700 In-Reply-To: <07b401c6f811$ba31dbc0$480c6f0a@china.huawei.com> References: <07b401c6f811$ba31dbc0$480c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E97D706-AE26-42F1-BC1B-0CDFBD29AD22@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Sat, 28 Oct 2006 10:59:23 -0700 To: Liu Ya X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Oct 2006 17:59:27.0973 (UTC) FILETIME=[CF8EA150:01C6FABA] DKIM-Signature: a=rsa-sha1; q=dns; l=3269; t=1162058369; x=1162922369; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20Some=20comments=20on=20draft-baugher-msec-gdoi-srtp-00.txt; X=v=3Dcisco.com=3B=20h=3D8b+qqwi/myn66vcMJudkyeo7nho=3D; b=L3HK19slRcRgU7PEFVXeZgUsnPPDkld6pT7SqLsRrjAZlgEsja2JXN9t1aszfvsMPVewB4lA jHh+rmsignpFU6bgMBo0hqDZ0l3z2bukBGAormsHOnfXvKMBrF+uP++1; Authentication-Results: sj-dkim-4.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: msec@ietf.org, =?ISO-8859-1?Q?Adrian-Ken_R=FCegsegger?= Subject: [MSEC] Re: Some comments on draft-baugher-msec-gdoi-srtp-00.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org hi Liu Ya Thanks for your comments. See inline, below... On Oct 25, 2006, at 1:43 AM, Liu Ya wrote: > Hi Mark, > > Some comments are proposed below. > > 1, In paragraph 2 of section 2, the doc writes: > "... Using this protocol extension, the GDOI Group Controller/Key > Server (GCKS) provides the cryptographic keys, policies and other > attributes to SRTP (via the API to a GDOI Member). ..." > > There are different meanings in above sentence. Such an understanding > might be gotten that those parameters are directly provided from GCKS > to SRTP via the API. In fact, two steps are needed for that purpose. > Firstly, parameters are transported from GCKS to GDOI Member through > GDOI signalling channel, then provided to SRTP via the API between > SRTP and GDOI Member. That's what we intended. Please propose new text if what we wrote is not clear enough. > > 2, Two figures are given in the beginning of section 2. The first one, > Figure 2.0-1, is explicitly explained as a logical diagram. While no > clear text is given to the second one, which is interpreted in > paragraph 3 of section 2. After reading paragraph 3, I get a strong > apprehension that Fig. 2.0-2 is a physical diagram. However, the same > illustrating method are used for the two figures. It is better to > emphasize the physical entities of SRTP source and SRTP receiver in > Fig. 2.0-2, such as, in my suggestion, illustrating the left two > logical entities into a physical sender, the right two logical ones > into a physical receiver. That's our intention and that's why we introduced Fig. 2.0-2 as being a "physical realization". We rely on an assumption that an API operates between two entities on the same computer. I think drawing a box around them as you suggest in a subsequent note to this list adds clarity and we should include that in the next revision. > > 3, The case of multiple SSRCs within one RTP session is considered in > both RTP [RFC3550] and SRTP [RFC3711]. When GDOI is used in such case, > it is possible that multiple SSRCs need to be transported from GCKS to > SRTP receivers. However, only one SSRC field space is assgined in > SA-TEK, which is defined in section 2.2. The SA-TEK is going to be changed substantially in the next draft. I personally did the diagram. Brian and Adrian suggested some improvements, but we ran out of time before the submission deadline. Adrian revised the text and you'll see that in the next revision of this I-D. I do expect that we will have one SA-TEK for each session from a given source. It is also possible to have one SA-TEK and one from other sources to a given session. > > 4, When interpreting the SA-TEK's MKI Leghth field in section 2.2, > page 9, the word 'indicator' is used improperly. MKI is the > abbreviation for Master Key Identifier, not Master Key Indicator > [RFC3771]. And in section 3.2.1 of RFC3711, a special parameter called > MKI indicator is defined for SRTP cryptographic context, indicating > whether an MKI is present in SRTP packets. To distinguish MKI and MKI > indicator, it's better to avoid using the word 'indicator' here. Agreed. Thanks, Mark > > > Regards, > Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 31 04:55:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeqLf-0008AK-Qv for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 04:55:59 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeqLe-0006TV-89 for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 04:55:59 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E3FE42C8F1; Tue, 31 Oct 2006 04:55:49 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7E57F2C8C8 for ; Tue, 31 Oct 2006 04:55:48 -0500 (EST) Received: (qmail 99166 invoked by uid 3269); 31 Oct 2006 09:55:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99163 invoked from network); 31 Oct 2006 09:55:48 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 31 Oct 2006 09:55:48 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id C0DF0E9D4F for ; Tue, 31 Oct 2006 04:55:48 -0500 (EST) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mailwash15.pair.com (Postfix) with ESMTP id 52675E9D4D for ; Tue, 31 Oct 2006 04:55:48 -0500 (EST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k9V9tk4U023727; Tue, 31 Oct 2006 10:55:46 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k9V9tkMc002907; Tue, 31 Oct 2006 10:55:46 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:55:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Oct 2006 10:55:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: proposed RFC 4650 "MIKEY DHHMAC" errata thread-index: AcbyBV/5PjRRxM1rSUCitHEUG8AQTQKzKUdw From: "Euchner, Martin" To: , "Euchner, Martin" , X-OriginalArrivalTime: 31 Oct 2006 09:55:46.0024 (UTC) FILETIME=[BC5DE680:01C6FCD2] Cc: Subject: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Dear MIKEY experts, Please find below a proposed errata for recently published RFC 4650 = "MIKEY DHHMAC". I've reviewed the proposal and I consider all the proposed = corrections/improvements correct. Can we have a mailing list discussion and agreement within MSEC, if the = proposed errata is acceptable? With kind regards Martin Euchner. -----Original Message----- From: Martin Euchner [mailto:martin_euchner@hotmail.com]=20 Sent: Dienstag, 17. Oktober 2006 17:55 To: Euchner, Martin Subject: FW: RFC 4650 errata From: Alfred H=CEnes To: rfc-editor@rfc-editor.org, martin_euchner@hotmail.com Subject: RFC 4650 errata Date: Fri, 13 Oct 2006 16:19:07 +0200 (MESZ) Hello, reading the recently published RFC 4650 (MIKEY DHHMAC), I found a couple of textual flaws that might be noted as RFC errata. The items below are presented in textual order of occurrence. Only items (14) and (15) below are considered serious. (1) word omission In Section 1, the first text line on page 2 says: There is work done in IETF to develop key management schemes. [..] It should say: | There is work done in the IETF to develop key management schemes. [..] (2) typo In Section 1, the last indented paragraph on page 4 says: However, the Diffie-Hellman key agreement protocol is known for its subtle security strengths in that it is able to provide full perfect forward secrecy (PFS) and further have to both parties actively involved in session key generation. This special security property (despite the somewhat higher computational costs) makes Diffie-Hellman techniques attractive in practice. It should say: However, the Diffie-Hellman key agreement protocol is known for its subtle security strengths in that it is able to provide full | perfect forward secrecy (PFS) and further have both parties actively involved in session key generation. This special security property (despite the somewhat higher computational costs) makes Diffie-Hellman techniques attractive in practice. (3) typo (line folding problem?) The second paragraph of Section 2, on page 7, says: DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, pre- shared master secrets are assumed to be available among the entities in such an environment. It should say: DHHMAC is applicable in a peer-to-peer group where no access to a public-key infrastructure can be assumed to be available. Rather, | pre-shared master secrets are assumed to be available among the entities in such an environment. (4) typo In Section 2.1, the last paragraph on page 7 says: a) SIP [13] and SDP, where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP offer/answer see RFC 3264 [27]) handshake, as described in [4]; It should say: a) SIP [13] and SDP, where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP | offer/answer (see RFC 3264 [27]) handshake, as described in [4]; or perhaps even better: a) SIP [13] and SDP, where the encoded MIKEY messages are encapsulated and transported in SDP containers of the SDP | offer/answer handshake (see RFC 3264 [27]), as described in [4]; (5) message syntax notation Figure 1 in Section 3, on page 8, says: Initiator Responder I_message =3D HDR, T, RAND, [IDi], IDr, {SP}, DHi, KEMAC -----------------------> R_message =3D HDR, T, [IDr], IDi, DHr, DHi, KEMAC <---------------------- To avoid optional empty protocol elements, it should perhaps better say: Initiator Responder | I_message =3D HDR, T, RAND, [IDi,] IDr, {SP}, DHi, KEMAC -----------------------> R_message =3D HDR, T, | [IDr,] IDi, DHr, DHi, KEMAC <---------------------- (5') Similar corrections would be suitable in Section 3.1 for Figure 2, on page 10. (6) missing comma, causing possible mis-interpretation The last sentence of Section 3, at the bottom of page 9, says: [...]. The HMAC SHALL be computed over the entire message, excluding the MAC field using auth_key; see also section 4.2. It should say: [...]. The HMAC SHALL be | computed over the entire message, excluding the MAC field, using auth_key; see also section 4.2. or perhaps even better and clearer: [...]. The HMAC SHALL be | computed (using auth_key) over the entire message excluding the MAC | field; see also section 4.2. (7) extraneous (duplicate) word In Section 4.1, the last sentence on page 11, says: Other defined next payload values defined in [2] SHALL not be = applied to DHHMAC. It should say: | Other next payload values defined in [2] SHALL not be applied to DHHMAC. (8) missing comma, causing possible mis-interpretation [similar to item (6) above] The last sentence of the second paragraph of Section 4.2, on page 12, says: [...]. The HMAC is then calculated over the entire MIKEY message, excluding the MAC field using auth_key as described in [2] section 5.2, and then stored within the MAC field. It should say: [...]. The HMAC is then calculated over the entire MIKEY | message, excluding the MAC field, using auth_key as described in [2] section 5.2, and then stored within the MAC field. or perhaps even better and clearer: | [...]. The HMAC is then calculated using auth_key, over the | entire MIKEY message, excluding the MAC field, as described in [2] section 5.2, and then stored within the MAC field. (9) missing article The last paragraph on page 13, i.e. the 2nd bullet in Section 5.2, says: * Eavesdropping of other, transmitted keying information: DHHMAC protocol does not explicitly transmit the TGK at all. [...] It should say: | * Eavesdropping of other, transmitted keying information: The DHHMAC protocol does not explicitly transmit the TGK at all. [...] (10) missing "/" The 3rd paragraph on page 14, i.e. the 4th bullet in Section 5.2, says: * Man-in-the-middle attacks: Such attacks threaten the security of exchanged, non-authenticated messages. Man-in-the-middle attacks usually come with masquerade and or loss of message integrity (see below). [...] It should say: * Man-in-the-middle attacks: Such attacks threaten the security of exchanged, non-authenticated messages. Man-in-the-middle attacks | usually come with masquerade and/or loss of message integrity (see below). [...] (11) missing comma (potential for mis-interpretation) The second paragraph on page 15 (within Section 5.2) says: * Identity protection: Like MIKEY, identity protection is not a = major design requirement for MIKEY-DHHMAC, either; see [2]. No security protocol is known so far that is able to provide the objectives of DHHMAC as stated in section 5.3, including identity protection within just a single roundtrip. [...] It should say: * Identity protection: Like MIKEY, identity protection is not a = major design requirement for MIKEY-DHHMAC, either; see [2]. No security protocol is known so far that is able to provide the objectives of | DHHMAC as stated in section 5.3, including identity protection, within just a single roundtrip. [...] (12) extraneous word The 3rd paragraph on page 18 (within Section 5.3) says: If a very high security level is desired for long-term secrecy of the negotiated Diffie-Hellman shared secret, longer hash values = may be deployed, such as SHA256, SHA384, or SHA512 provide, possibly = in | conjunction with stronger Diffie-Hellman groups. This is left as for further study. It should say: | [...]. This is left for further study. (13) extraneous words (left over from changing the sentence?) The last lines on page 18 (within Section 5.3) say: Public-key infrastructures may not always be available in certain environments, nor may they be deemed adequate for real-time multimedia applications when additional steps are taken for certificate validation and certificate revocation methods with additional roundtrips into account. The RFC should say: Public-key infrastructures may not always be available in certain environments, nor may they be deemed adequate for real-time multimedia applications when additional steps are taken for certificate validation and certificate revocation methods with additional roundtrips. (14) outdated Informative Reference Once more: This RFC as well references the now-outdated RFC 1750. All new RFCs should refer to BCP 106, RFC 4086, instead of RFC 1750! Item [8] in Section 8.2, at the bottom of page 22 of RFC 4650, should be replaced by the proper RFC-style citation for RFC 4086. (15) typo -- results in wrong Endpoint identifier specified The 3rd paragraph of Appendix A, on page 25, says: To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the = caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A | routing gatekeeper (GK) would forward this message to endpoint B; in case of a non-routing gatekeeper, endpoint B sends the SETUP = directly to endpoint A. [...] It should say: To establish a call, it is assumed that endpoint B has obtained permission from the gatekeeper (not shown). Endpoint B as the = caller builds the MIKEY-DHHMAC I_message (see section 3) and sends the I_message encapsulated within the H.323-SETUP to endpoint A. A | routing gatekeeper (GK) would forward this message to endpoint A; in case of a non-routing gatekeeper, endpoint B sends the SETUP = directly to endpoint A. [...] Best regards, Alfred H=CEnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 31 11:37:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewbw-0005uU-6q for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 11:37:12 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gewbs-0002EP-6n for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 11:37:12 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id CD9062CB96; Tue, 31 Oct 2006 11:36:59 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BA0B72CBD6 for ; Tue, 31 Oct 2006 11:36:58 -0500 (EST) Received: (qmail 7040 invoked by uid 3269); 31 Oct 2006 16:36:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7037 invoked from network); 31 Oct 2006 16:36:58 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 31 Oct 2006 16:36:58 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id C518AE9D81 for ; Tue, 31 Oct 2006 11:36:58 -0500 (EST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by mailwash15.pair.com (Postfix) with ESMTP id 81DD3E9DA6 for ; Tue, 31 Oct 2006 11:36:58 -0500 (EST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9VGarQ16719; Tue, 31 Oct 2006 11:36:54 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata Date: Tue, 31 Oct 2006 10:36:51 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC994F0@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata Thread-Index: AcbyBV/5PjRRxM1rSUCitHEUG8AQTQKzKUdwAA4phoA= From: "Francois Audet" To: "Euchner, Martin" , Cc: X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Thanks. I can't help to think that if it had some many glitches, maybe we issued the RFC too fast.=20 > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of Euchner, Martin > Sent: Tuesday, October 31, 2006 1:56 AM > To: msec@securemulticast.org; Euchner, Martin; ah@tr-sys.de > Subject: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata >=20 > Dear MIKEY experts, >=20 > Please find below a proposed errata for recently published=20 > RFC 4650 "MIKEY DHHMAC". >=20 > I've reviewed the proposal and I consider all the proposed=20 > corrections/improvements correct. >=20 > Can we have a mailing list discussion and agreement within=20 > MSEC, if the proposed errata is acceptable? >=20 > With kind regards >=20 > Martin Euchner. >=20 >=20 > -----Original Message----- > From: Martin Euchner [mailto:martin_euchner@hotmail.com] > Sent: Dienstag, 17. Oktober 2006 17:55 > To: Euchner, Martin > Subject: FW: RFC 4650 errata >=20 >=20 > From: Alfred H=CEnes > To: rfc-editor@rfc-editor.org, martin_euchner@hotmail.com > Subject: RFC 4650 errata > Date: Fri, 13 Oct 2006 16:19:07 +0200 (MESZ) >=20 > Hello, > reading the recently published RFC 4650 (MIKEY DHHMAC), I found > a couple of textual flaws that might be noted as RFC errata. >=20 > The items below are presented in textual order of occurrence. > Only items (14) and (15) below are considered serious. >=20 >=20 > (1) word omission >=20 > In Section 1, the first text line on page 2 says: >=20 > There is work done in IETF to develop key management=20 > schemes. [..] >=20 > It should say: >=20 > | There is work done in the IETF to develop key management schemes. > [..] >=20 >=20 > (2) typo >=20 > In Section 1, the last indented paragraph on page 4 says: >=20 > However, the Diffie-Hellman key agreement protocol is known for > its subtle security strengths in that it is able to=20 > provide full > perfect forward secrecy (PFS) and further have to both parties > actively involved in session key generation. This special > security property (despite the somewhat higher computational > costs) makes Diffie-Hellman techniques attractive in practice. >=20 > It should say: >=20 > However, the Diffie-Hellman key agreement protocol is known for > its subtle security strengths in that it is able to=20 > provide full > | perfect forward secrecy (PFS) and further have both parties > actively involved in session key generation. This special > security property (despite the somewhat higher computational > costs) makes Diffie-Hellman techniques attractive in practice. >=20 >=20 > (3) typo (line folding problem?) >=20 > The second paragraph of Section 2, on page 7, says: >=20 > DHHMAC is applicable in a peer-to-peer group where no access to a > public-key infrastructure can be assumed to be available. Rather, > pre- shared master secrets are assumed to be available among the > entities in such an environment. >=20 > It should say: >=20 > DHHMAC is applicable in a peer-to-peer group where no access to a > public-key infrastructure can be assumed to be available. Rather, > | pre-shared master secrets are assumed to be available among the > entities in such an environment. >=20 >=20 > (4) typo >=20 > In Section 2.1, the last paragraph on page 7 says: >=20 > a) SIP [13] and SDP, where the encoded MIKEY messages are > encapsulated and transported in SDP containers of the SDP > offer/answer see RFC 3264 [27]) handshake, as described in [4]; >=20 > It should say: >=20 > a) SIP [13] and SDP, where the encoded MIKEY messages are > encapsulated and transported in SDP containers of the SDP > | offer/answer (see RFC 3264 [27]) handshake, as described in [4]; >=20 > or perhaps even better: >=20 > a) SIP [13] and SDP, where the encoded MIKEY messages are > encapsulated and transported in SDP containers of the SDP > | offer/answer handshake (see RFC 3264 [27]), as described in [4]; >=20 >=20 > (5) message syntax notation >=20 > Figure 1 in Section 3, on page 8, says: >=20 > Initiator Responder >=20 > I_message =3D HDR, T, RAND, [IDi], IDr, > {SP}, DHi, KEMAC > -----------------------> R_message =3D HDR, T, > [IDr], IDi, DHr, > DHi, KEMAC > <---------------------- >=20 > To avoid optional empty protocol elements, > it should perhaps better say: >=20 > Initiator Responder >=20 > | I_message =3D HDR, T, RAND, [IDi,] IDr, > {SP}, DHi, KEMAC > -----------------------> R_message =3D HDR, T, > | [IDr,] IDi, DHr, > DHi, KEMAC > <---------------------- >=20 > (5') >=20 > Similar corrections would be suitable in Section 3.1 for Figure 2, > on page 10. >=20 >=20 > (6) missing comma, causing possible mis-interpretation >=20 > The last sentence of Section 3, at the bottom of page 9, says: >=20 > [...]. The HMAC SHALL be > computed over the entire message, excluding the MAC field using > auth_key; see also section 4.2. >=20 > It should say: >=20 > [...]. The HMAC SHALL be > | computed over the entire message, excluding the MAC field, using > auth_key; see also section 4.2. >=20 > or perhaps even better and clearer: >=20 > [...]. The HMAC SHALL be > | computed (using auth_key) over the entire message excluding the MAC > | field; see also section 4.2. >=20 >=20 > (7) extraneous (duplicate) word >=20 > In Section 4.1, the last sentence on page 11, says: >=20 > Other defined next payload values defined in [2] SHALL=20 > not be applied > to DHHMAC. >=20 > It should say: >=20 > | Other next payload values defined in [2] SHALL not be applied to > DHHMAC. >=20 > (8) missing comma, causing possible mis-interpretation > [similar to item (6) above] >=20 > The last sentence of the second paragraph of Section 4.2, > on page 12, says: >=20 > [...]. The HMAC is then calculated over the entire MIKEY > message, excluding the MAC field using auth_key as=20 > described in [2] > section 5.2, and then stored within the MAC field. >=20 > It should say: >=20 > [...]. The HMAC is then calculated over the entire MIKEY > | message, excluding the MAC field, using auth_key as=20 > described in [2] > section 5.2, and then stored within the MAC field. >=20 > or perhaps even better and clearer: >=20 > | [...]. The HMAC is then calculated using auth_key, over the > | entire MIKEY message, excluding the MAC field, as described in [2] > section 5.2, and then stored within the MAC field. >=20 >=20 > (9) missing article >=20 > The last paragraph on page 13, i.e. the 2nd bullet in Section=20 > 5.2, says: >=20 > * Eavesdropping of other, transmitted keying information: DHHMAC > protocol does not explicitly transmit the TGK at all. [...] >=20 > It should say: >=20 > | * Eavesdropping of other, transmitted keying information:=20 > The DHHMAC > protocol does not explicitly transmit the TGK at all. [...] >=20 >=20 > (10) missing "/" >=20 > The 3rd paragraph on page 14, i.e. the 4th bullet in Section=20 > 5.2, says: >=20 > * Man-in-the-middle attacks: Such attacks threaten the security of > exchanged, non-authenticated messages. =20 > Man-in-the-middle attacks > usually come with masquerade and or loss of message=20 > integrity (see > below). [...] >=20 > It should say: >=20 > * Man-in-the-middle attacks: Such attacks threaten the security of > exchanged, non-authenticated messages. =20 > Man-in-the-middle attacks > | usually come with masquerade and/or loss of message=20 > integrity (see > below). [...] >=20 >=20 > (11) missing comma (potential for mis-interpretation) >=20 > The second paragraph on page 15 (within Section 5.2) says: >=20 > * Identity protection: Like MIKEY, identity protection is=20 > not a major > design requirement for MIKEY-DHHMAC, either; see [2]. =20 > No security > protocol is known so far that is able to provide the=20 > objectives of > DHHMAC as stated in section 5.3, including identity protection > within just a single roundtrip. [...] >=20 > It should say: >=20 > * Identity protection: Like MIKEY, identity protection is=20 > not a major > design requirement for MIKEY-DHHMAC, either; see [2]. =20 > No security > protocol is known so far that is able to provide the=20 > objectives of > | DHHMAC as stated in section 5.3, including identity protection, > within just a single roundtrip. [...] >=20 >=20 > (12) extraneous word >=20 > The 3rd paragraph on page 18 (within Section 5.3) says: >=20 > If a very high security level is desired for long-term=20 > secrecy of > the negotiated Diffie-Hellman shared secret, longer=20 > hash values may > be deployed, such as SHA256, SHA384, or SHA512 provide,=20 > possibly in > | conjunction with stronger Diffie-Hellman groups. This is left as > for further study. >=20 > It should say: >=20 > | [...]. This=20 > is left for > further study. >=20 >=20 > (13) extraneous words (left over from changing the sentence?) >=20 > The last lines on page 18 (within Section 5.3) say: >=20 > Public-key infrastructures may not always be available=20 > in certain > environments, nor may they be deemed adequate for real-time > multimedia applications when additional steps are taken for > certificate validation and certificate revocation methods with > additional roundtrips into account. >=20 > The RFC should say: >=20 > Public-key infrastructures may not always be available=20 > in certain > environments, nor may they be deemed adequate for real-time > multimedia applications when additional steps are taken for > certificate validation and certificate revocation methods with > additional roundtrips. >=20 >=20 > (14) outdated Informative Reference >=20 > Once more: This RFC as well references the now-outdated RFC 1750. > All new RFCs should refer to BCP 106, RFC 4086, instead of RFC 1750! >=20 > Item [8] in Section 8.2, at the bottom of page 22 of RFC 4650, > should be replaced by the proper RFC-style citation for RFC 4086. >=20 >=20 > (15) typo -- results in wrong Endpoint identifier specified >=20 > The 3rd paragraph of Appendix A, on page 25, says: >=20 > To establish a call, it is assumed that endpoint B has obtained > permission from the gatekeeper (not shown). Endpoint B=20 > as the caller > builds the MIKEY-DHHMAC I_message (see section 3) and sends the > I_message encapsulated within the H.323-SETUP to endpoint A. A > | routing gatekeeper (GK) would forward this message to=20 > endpoint B; in > case of a non-routing gatekeeper, endpoint B sends the=20 > SETUP directly > to endpoint A. [...] >=20 > It should say: >=20 > To establish a call, it is assumed that endpoint B has obtained > permission from the gatekeeper (not shown). Endpoint B=20 > as the caller > builds the MIKEY-DHHMAC I_message (see section 3) and sends the > I_message encapsulated within the H.323-SETUP to endpoint A. A > | routing gatekeeper (GK) would forward this message to=20 > endpoint A; in > case of a non-routing gatekeeper, endpoint B sends the=20 > SETUP directly > to endpoint A. [...] >=20 >=20 > Best regards, > Alfred H=CEnes. >=20 > -- >=20 > +------------------------+------------------------------------ > --------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math.,=20 > Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18=20 > | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de =20 > | > +------------------------+------------------------------------ > --------+ >=20 >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 31 11:54:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewsZ-0007an-La for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 11:54:24 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewsW-0005QU-0c for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 11:54:23 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C8CF02C81C; Tue, 31 Oct 2006 11:54:19 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6BF722C42E for ; Tue, 31 Oct 2006 11:54:18 -0500 (EST) Received: (qmail 12186 invoked by uid 3269); 31 Oct 2006 16:54:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12183 invoked from network); 31 Oct 2006 16:54:18 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 31 Oct 2006 16:54:18 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 632ADE9D96 for ; Tue, 31 Oct 2006 11:54:18 -0500 (EST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by mailwash15.pair.com (Postfix) with ESMTP id E092BE9D90 for ; Tue, 31 Oct 2006 11:54:17 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9VGsAtm026519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 31 Oct 2006 08:54:10 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-193.qualcomm.com [10.50.77.193]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9VGs6Sc008676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Oct 2006 08:54:07 -0800 (PST) Message-Id: <7.0.1.0.2.20061031085216.07ac38b8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 31 Oct 2006 08:53:59 -0800 To: "Francois Audet" , "Euchner, Martin" , From: Lakshminath Dondeti Subject: RE: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC994F0@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF0DC994F0@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Nearly all of these are editorial and IMO don't quite need to be done, I= think. At 08:36 AM 10/31/2006, Francois Audet wrote: >Thanks. > >I can't help to think that if it had some many glitches, maybe we >issued the RFC too fast. > > > -----Original Message----- > > From: msec-bounces@securemulticast.org > > [mailto:msec-bounces@securemulticast.org] On Behalf Of Euchner, Martin > > Sent: Tuesday, October 31, 2006 1:56 AM > > To: msec@securemulticast.org; Euchner, Martin; ah@tr-sys.de > > Subject: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata > > > > Dear MIKEY experts, > > > > Please find below a proposed errata for recently published > > RFC 4650 "MIKEY DHHMAC". > > > > I've reviewed the proposal and I consider all the proposed > > corrections/improvements correct. > > > > Can we have a mailing list discussion and agreement within > > MSEC, if the proposed errata is acceptable? > > > > With kind regards > > > > Martin Euchner. > > > > > > -----Original Message----- > > From: Martin Euchner [mailto:martin_euchner@hotmail.com] > > Sent: Dienstag, 17. Oktober 2006 17:55 > > To: Euchner, Martin > > Subject: FW: RFC 4650 errata > > > > > > From: Alfred H=CEnes > > To: rfc-editor@rfc-editor.org, martin_euchner@hotmail.com > > Subject: RFC 4650 errata > > Date: Fri, 13 Oct 2006 16:19:07 +0200 (MESZ) > > > > Hello, > > reading the recently published RFC 4650 (MIKEY DHHMAC), I found > > a couple of textual flaws that might be noted as RFC errata. > > > > The items below are presented in textual order of occurrence. > > Only items (14) and (15) below are considered serious. > > > > > > (1) word omission > > > > In Section 1, the first text line on page 2 says: > > > > There is work done in IETF to develop key management > > schemes. [..] > > > > It should say: > > > > | There is work done in the IETF to develop key management schemes. > > [..] > > > > > > (2) typo > > > > In Section 1, the last indented paragraph on page 4 says: > > > > However, the Diffie-Hellman key agreement protocol is known for > > its subtle security strengths in that it is able to > > provide full > > perfect forward secrecy (PFS) and further have to both parties > > actively involved in session key generation. This special > > security property (despite the somewhat higher computational > > costs) makes Diffie-Hellman techniques attractive in practice. > > > > It should say: > > > > However, the Diffie-Hellman key agreement protocol is known for > > its subtle security strengths in that it is able to > > provide full > > | perfect forward secrecy (PFS) and further have both parties > > actively involved in session key generation. This special > > security property (despite the somewhat higher computational > > costs) makes Diffie-Hellman techniques attractive in practice. > > > > > > (3) typo (line folding problem?) > > > > The second paragraph of Section 2, on page 7, says: > > > > DHHMAC is applicable in a peer-to-peer group where no access to a > > public-key infrastructure can be assumed to be available. Rather, > > pre- shared master secrets are assumed to be available among the > > entities in such an environment. > > > > It should say: > > > > DHHMAC is applicable in a peer-to-peer group where no access to a > > public-key infrastructure can be assumed to be available. Rather, > > | pre-shared master secrets are assumed to be available among the > > entities in such an environment. > > > > > > (4) typo > > > > In Section 2.1, the last paragraph on page 7 says: > > > > a) SIP [13] and SDP, where the encoded MIKEY messages are > > encapsulated and transported in SDP containers of the SDP > > offer/answer see RFC 3264 [27]) handshake, as described in [4]; > > > > It should say: > > > > a) SIP [13] and SDP, where the encoded MIKEY messages are > > encapsulated and transported in SDP containers of the SDP > > | offer/answer (see RFC 3264 [27]) handshake, as described in [4]; > > > > or perhaps even better: > > > > a) SIP [13] and SDP, where the encoded MIKEY messages are > > encapsulated and transported in SDP containers of the SDP > > | offer/answer handshake (see RFC 3264 [27]), as described in [4]; > > > > > > (5) message syntax notation > > > > Figure 1 in Section 3, on page 8, says: > > > > Initiator Responder > > > > I_message =3D HDR, T, RAND, [IDi], IDr, > > {SP}, DHi, KEMAC > > -----------------------> R_message =3D HDR, T, > > [IDr], IDi, DHr, > > DHi, KEMAC > > <---------------------- > > > > To avoid optional empty protocol elements, > > it should perhaps better say: > > > > Initiator Responder > > > > | I_message =3D HDR, T, RAND, [IDi,] IDr, > > {SP}, DHi, KEMAC > > -----------------------> R_message =3D HDR, T, > > | [IDr,] IDi, DHr, > > DHi, KEMAC > > <---------------------- > > > > (5') > > > > Similar corrections would be suitable in Section 3.1 for Figure 2, > > on page 10. > > > > > > (6) missing comma, causing possible mis-interpretation > > > > The last sentence of Section 3, at the bottom of page 9, says: > > > > [...]. The HMAC SHALL be > > computed over the entire message, excluding the MAC field using > > auth_key; see also section 4.2. > > > > It should say: > > > > [...]. The HMAC SHALL be > > | computed over the entire message, excluding the MAC field, using > > auth_key; see also section 4.2. > > > > or perhaps even better and clearer: > > > > [...]. The HMAC SHALL be > > | computed (using auth_key) over the entire message excluding the MAC > > | field; see also section 4.2. > > > > > > (7) extraneous (duplicate) word > > > > In Section 4.1, the last sentence on page 11, says: > > > > Other defined next payload values defined in [2] SHALL > > not be applied > > to DHHMAC. > > > > It should say: > > > > | Other next payload values defined in [2] SHALL not be applied to > > DHHMAC. > > > > (8) missing comma, causing possible mis-interpretation > > [similar to item (6) above] > > > > The last sentence of the second paragraph of Section 4.2, > > on page 12, says: > > > > [...]. The HMAC is then calculated over the entire MIKEY > > message, excluding the MAC field using auth_key as > > described in [2] > > section 5.2, and then stored within the MAC field. > > > > It should say: > > > > [...]. The HMAC is then calculated over the entire MIKEY > > | message, excluding the MAC field, using auth_key as > > described in [2] > > section 5.2, and then stored within the MAC field. > > > > or perhaps even better and clearer: > > > > | [...]. The HMAC is then calculated using auth_key, over the > > | entire MIKEY message, excluding the MAC field, as described in [2] > > section 5.2, and then stored within the MAC field. > > > > > > (9) missing article > > > > The last paragraph on page 13, i.e. the 2nd bullet in Section > > 5.2, says: > > > > * Eavesdropping of other, transmitted keying information: DHHMAC > > protocol does not explicitly transmit the TGK at all. [...] > > > > It should say: > > > > | * Eavesdropping of other, transmitted keying information: > > The DHHMAC > > protocol does not explicitly transmit the TGK at all. [...] > > > > > > (10) missing "/" > > > > The 3rd paragraph on page 14, i.e. the 4th bullet in Section > > 5.2, says: > > > > * Man-in-the-middle attacks: Such attacks threaten the security of > > exchanged, non-authenticated messages. > > Man-in-the-middle attacks > > usually come with masquerade and or loss of message > > integrity (see > > below). [...] > > > > It should say: > > > > * Man-in-the-middle attacks: Such attacks threaten the security of > > exchanged, non-authenticated messages. > > Man-in-the-middle attacks > > | usually come with masquerade and/or loss of message > > integrity (see > > below). [...] > > > > > > (11) missing comma (potential for mis-interpretation) > > > > The second paragraph on page 15 (within Section 5.2) says: > > > > * Identity protection: Like MIKEY, identity protection is > > not a major > > design requirement for MIKEY-DHHMAC, either; see [2]. > > No security > > protocol is known so far that is able to provide the > > objectives of > > DHHMAC as stated in section 5.3, including identity protection > > within just a single roundtrip. [...] > > > > It should say: > > > > * Identity protection: Like MIKEY, identity protection is > > not a major > > design requirement for MIKEY-DHHMAC, either; see [2]. > > No security > > protocol is known so far that is able to provide the > > objectives of > > | DHHMAC as stated in section 5.3, including identity protection, > > within just a single roundtrip. [...] > > > > > > (12) extraneous word > > > > The 3rd paragraph on page 18 (within Section 5.3) says: > > > > If a very high security level is desired for long-term > > secrecy of > > the negotiated Diffie-Hellman shared secret, longer > > hash values may > > be deployed, such as SHA256, SHA384, or SHA512 provide, > > possibly in > > | conjunction with stronger Diffie-Hellman groups. This is left as > > for further study. > > > > It should say: > > > > | [...]. This > > is left for > > further study. > > > > > > (13) extraneous words (left over from changing the sentence?) > > > > The last lines on page 18 (within Section 5.3) say: > > > > Public-key infrastructures may not always be available > > in certain > > environments, nor may they be deemed adequate for real-time > > multimedia applications when additional steps are taken for > > certificate validation and certificate revocation methods with > > additional roundtrips into account. > > > > The RFC should say: > > > > Public-key infrastructures may not always be available > > in certain > > environments, nor may they be deemed adequate for real-time > > multimedia applications when additional steps are taken for > > certificate validation and certificate revocation methods with > > additional roundtrips. > > > > > > (14) outdated Informative Reference > > > > Once more: This RFC as well references the now-outdated RFC 1750. > > All new RFCs should refer to BCP 106, RFC 4086, instead of RFC 1750! > > > > Item [8] in Section 8.2, at the bottom of page 22 of RFC 4650, > > should be replaced by the proper RFC-style citation for RFC 4086. > > > > > > (15) typo -- results in wrong Endpoint identifier specified > > > > The 3rd paragraph of Appendix A, on page 25, says: > > > > To establish a call, it is assumed that endpoint B has obtained > > permission from the gatekeeper (not shown). Endpoint B > > as the caller > > builds the MIKEY-DHHMAC I_message (see section 3) and sends the > > I_message encapsulated within the H.323-SETUP to endpoint A. A > > | routing gatekeeper (GK) would forward this message to > > endpoint B; in > > case of a non-routing gatekeeper, endpoint B sends the > > SETUP directly > > to endpoint A. [...] > > > > It should say: > > > > To establish a call, it is assumed that endpoint B has obtained > > permission from the gatekeeper (not shown). Endpoint B > > as the caller > > builds the MIKEY-DHHMAC I_message (see section 3) and sends the > > I_message encapsulated within the H.323-SETUP to endpoint A. A > > | routing gatekeeper (GK) would forward this message to > > endpoint A; in > > case of a non-routing gatekeeper, endpoint B sends the > > SETUP directly > > to endpoint A. [...] > > > > > > Best regards, > > Alfred H=CEnes. > > > > -- > > > > +------------------------+------------------------------------ > > --------+ > > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., > > Dipl.-Phys. | > > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 > > | > > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de > > | > > +------------------------+------------------------------------ > > --------+ > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Oct 31 19:48:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf4HR-0002IY-DH for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 19:48:33 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf4HQ-0003d4-4M for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 19:48:33 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B900E2BEDD; Tue, 31 Oct 2006 19:48:12 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 2DC842BEDD for ; Tue, 31 Oct 2006 19:48:04 -0500 (EST) Received: (qmail 64590 invoked by uid 3269); 1 Nov 2006 00:48:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64587 invoked from network); 1 Nov 2006 00:48:04 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 1 Nov 2006 00:48:04 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 2BF1DE9D1A for ; Tue, 31 Oct 2006 19:48:04 -0500 (EST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mailwash15.pair.com (Postfix) with ESMTP id 18AE1E9D13 for ; Tue, 31 Oct 2006 19:48:04 -0500 (EST) Received: by wx-out-0506.google.com with SMTP id i26so2040294wxd for ; Tue, 31 Oct 2006 16:48:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=pjeDiQa02sZFMTkBNfvj+t7V17/g9/k6+7cPPqBEaq1Mytn8I/FiPL/aE/bcWMWO2RlNo0p6Ts5b603Kg8Ce8d3VNGc4dhkLYwHnQmi8CJzodHuNYagW9hMoDmpUmiep0uzVSrrsAr9emyBsDlLd/aDB0hrTgq64lB7TxBRG9XA= Received: by 10.70.50.18 with SMTP id x18mr8331436wxx; Tue, 31 Oct 2006 16:48:02 -0800 (PST) Received: by 10.70.18.20 with HTTP; Tue, 31 Oct 2006 16:48:02 -0800 (PST) Message-ID: Date: Wed, 1 Nov 2006 08:48:02 +0800 From: "CAO, ZHEN" To: liangjing MIME-Version: 1.0 Cc: msec@securemulticast.org Subject: [MSEC] comments on draft-liang-msec-mikey-xtr-00 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0250904825==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============0250904825== Content-Type: multipart/alternative; boundary="----=_Part_11882_27167733.1162342082640" ------=_Part_11882_27167733.1162342082640 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jing, I have read your draft. You state that XTR has less communication overhead, and significant computation advantages, which leads to a conclusion that XTR could be suitable for the wireless and smart device. Could you help to explain why XTR is better than other algorithms such as RSA or ECC? Many thanks, Zhen ------=_Part_11882_27167733.1162342082640 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi Jing,
 
I have read your draft. You state that XTR has less communication overhead, and significant computation advantages, which leads to a conclusion that XTR could be suitable for the wireless and smart device. Could you help to explain why XTR is better than other algorithms such as RSA or ECC?
 
Many thanks,
Zhen

------=_Part_11882_27167733.1162342082640-- --===============0250904825== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0250904825==-- From msec-bounces@securemulticast.org Tue Oct 31 20:00:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf4TQ-0005Vx-Qy for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 20:00:57 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf4TP-0005ew-E5 for msec-archive@lists.ietf.org; Tue, 31 Oct 2006 20:00:56 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 383FC2C7D8; Tue, 31 Oct 2006 20:00:55 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 1F5BD2B805 for ; Tue, 31 Oct 2006 20:00:54 -0500 (EST) Received: (qmail 67306 invoked by uid 3269); 1 Nov 2006 01:00:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67183 invoked from network); 1 Nov 2006 01:00:02 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 1 Nov 2006 01:00:02 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id D5D4AE9D13 for ; Tue, 31 Oct 2006 20:00:02 -0500 (EST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mailwash15.pair.com (Postfix) with ESMTP id AA6D0E9DB6 for ; Tue, 31 Oct 2006 20:00:02 -0500 (EST) Received: by wx-out-0506.google.com with SMTP id i26so2042803wxd for ; Tue, 31 Oct 2006 17:00:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fl0TM/R/xkX78l0vd0E2YCcuhiw5XEQqZlxp6D+Tjk/N6kkem1oa4bK1iTyTzlbuapAmfOJoxjHzCxWjg9SadIfpUyb84QFucBAfTvGgthQidrjjtjjlKAKk5I9rkZDgGDxyqOlHlcOnCFgr6vR0wqU2DssqiPLyfpDTxmV7xVg= Received: by 10.65.219.13 with SMTP id w13mr7959531qbq; Tue, 31 Oct 2006 17:00:01 -0800 (PST) Received: by 10.64.148.15 with HTTP; Tue, 31 Oct 2006 17:00:01 -0800 (PST) Message-ID: <625017e00610311700w3be10b07idfb7841b12c550c5@mail.gmail.com> Date: Wed, 1 Nov 2006 09:00:01 +0800 From: liangjing To: "CAO, ZHEN" In-Reply-To: MIME-Version: 1.0 References: Cc: msec@securemulticast.org Subject: [MSEC] Re: comments on draft-liang-msec-mikey-xtr-00 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0153029884==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 --===============0153029884== Content-Type: multipart/alternative; boundary="----=_Part_10556_13941810.1162342801811" ------=_Part_10556_13941810.1162342801811 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, In arithmetic theory, XTR uses the trace over GF(p2) to represent an element g of the order p2-p+1 subgroup GF(p6) to achieve a factor 3 computation size reduction and thus faster calculations. The reason that XTR uses this specific subgroup g is not just that it provides full GF(p6) security, but also very efficient representation, at a small cost.Forexample, if one is willing to give up the distinction between elements and their conjugates over GF(p2), then not only elements of the XTR super group can be represented using an element of GF(p6) as opposed to GF(p6). But also calculations take place in GF(p2) instead of GF(p6) and can thus be performed much faster than usual. The paper "the XTR public key system", has proposed the XTR algorithm in theory. Best Regards -Jing 2006/11/1, CAO, ZHEN : > > Hi Jing, > > I have read your draft. You state that XTR has less communication > overhead, and significant computation advantages, which leads to a > conclusion that XTR could be suitable for the wireless and smart device. > Could you help to explain why XTR is better than other algorithms such as > RSA or ECC? > > Many thanks, > Zhen > ------=_Part_10556_13941810.1162342801811 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
  In arithmetic theory, XTR uses the trace over GF(p2) to represent an element g of the order p2-p+1 subgroup GF(p6) to achieve a factor 3 computation size reduction and thus faster calculations.
  The reason that XTR uses this specific subgroup g is not just that it provides full GF(p6)
security, but also very efficient representation, at a small cost.For example, if one is
willing to give up the distinction between elements and their conjugates over GF(p2), then
not only elements of the XTR super group can be represented using an element of GF(p6)
as opposed to GF(p6). But also calculations take place in GF(p2) instead of GF(p6) and
can thus be performed much faster than usual.
  The paper "the XTR public key system", has proposed the XTR algorithm in theory.
 
Best Regards
-Jing
 
2006/11/1, CAO, ZHEN <caozhenpku@gmail.com>:

Hi Jing,
 
I have read your draft. You state that XTR has less communication overhead, and significant computation advantages, which leads to a conclusion that XTR could be suitable for the wireless and smart device. Could you help to explain why XTR is better than other algorithms such as RSA or ECC?
 
Many thanks,
Zhen


------=_Part_10556_13941810.1162342801811-- --===============0153029884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0153029884==--