From msec-bounces@securemulticast.org Thu Nov 02 02:39:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAh-0000dm-H6 for msec-archive@lists.ietf.org; Thu, 02 Nov 2006 02:39:31 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfX4d-0004eX-It for msec-archive@lists.ietf.org; Thu, 02 Nov 2006 02:33:17 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 02D232D069; Thu, 2 Nov 2006 02:33:00 -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 70B462D071 for ; Thu, 2 Nov 2006 02:32:58 -0500 (EST) Received: (qmail 48040 invoked by uid 3269); 2 Nov 2006 07:32:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48037 invoked from network); 2 Nov 2006 07:32:57 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 2 Nov 2006 07:32:57 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 244FDE9D86 for ; Thu, 2 Nov 2006 02:32:58 -0500 (EST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mailwash15.pair.com (Postfix) with ESMTP id ECD3AE9D82 for ; Thu, 2 Nov 2006 02:32:57 -0500 (EST) Received: by wx-out-0506.google.com with SMTP id i26so55070wxd for ; Wed, 01 Nov 2006 23:32:56 -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=jZIy3z++ROipLKKITBMBUIU1w5AGZGzJXIoFrTE9yB3vKaHuHc3D3P3saI6YPTDUWZvYVphqQnGDFr1ljABa72GQ/m7OnhFrf+GyQPOv57MhNDzkmDIbJi7Hzi7O3KiRkkSP3BOA5JqAe2+H3j0mCQBp/+jO4ZnMLc/E1hkOcJE= Received: by 10.70.130.8 with SMTP id c8mr298994wxd.1162452776532; Wed, 01 Nov 2006 23:32:56 -0800 (PST) Received: by 10.70.18.20 with HTTP; Wed, 1 Nov 2006 23:32:56 -0800 (PST) Message-ID: Date: Thu, 2 Nov 2006 15:32:56 +0800 From: "CAO, ZHEN" To: liangjing In-Reply-To: <625017e00610311700w3be10b07idfb7841b12c550c5@mail.gmail.com> MIME-Version: 1.0 References: <625017e00610311700w3be10b07idfb7841b12c550c5@mail.gmail.com> 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="===============0260583664==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0260583664== Content-Type: multipart/alternative; boundary="----=_Part_924_30320503.1162452776491" ------=_Part_924_30320503.1162452776491 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jing, Thanks for your reply. You presented a theoretical analysis, but could you help to explain the security level comparison of ECC and XTR ,and in which circumstances we should use XTR instead of ECC? Thanks, Zhen On 11/1/06, liangjing wrote: > > 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_924_30320503.1162452776491 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Jing,
 
Thanks for your reply.  You presented a theoretical analysis, but could you help to explain the security level comparison of ECC and XTR ,and in which circumstances we should use XTR instead of ECC?

Thanks,
Zhen
On 11/1/06, liangjing <liangjingjing826@gmail.com> wrote:
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_924_30320503.1162452776491-- --===============0260583664== 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 --===============0260583664==-- From msec-bounces@ietf.org Thu Nov 02 10:20:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeMY-0004Xl-J6; Thu, 02 Nov 2006 10:20:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeMX-0004XV-Jd for msec@ietf.org; Thu, 02 Nov 2006 10:20:13 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfeMS-0003wK-Ue for msec@ietf.org; Thu, 02 Nov 2006 10:20:13 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id kA2FK74h007131; Thu, 2 Nov 2006 16:20:07 +0100 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 kA2FK7gC020391; Thu, 2 Nov 2006 16:20:07 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 16:20:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Nov 2006 16:18:51 +0100 Message-ID: In-Reply-To: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-msec-mikey-ecc-01.txt thread-index: Acb1E2y+AJId2YLYSxmPXm9oj/myGQJfVzkw From: "Fries, Steffen" To: "Eugene Chin" , X-OriginalArrivalTime: 02 Nov 2006 15:20:07.0009 (UTC) FILETIME=[60D80D10:01C6FE92] X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [MSEC] draft-ietf-msec-mikey-ecc-01.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="===============0259762146==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============0259762146== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FE92.609BA45E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FE92.609BA45E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Eugene, =20 I was just reading again over the mikey-ecc update. On question to the ECDSA addition. In the comments I sent to the former version of the draft, there was also ECGDSA included. The advantage of ECGDSA over ECDSA is that it does not require inverting the ephemeral key and thus may be interesting for devices with less computational power. Because of this we should maybe include it as well. What do you think?=20 =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 =09 =09 Section 3.3 - typo: server -> serve "Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..." =09 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) =09 The rename to MIKEY-ECMQV also affects section 4.1.2. =09 Thanks, Eugene.=20 =09 =09 ------_=_NextPart_001_01C6FE92.609BA45E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Eugene,
 
I was just reading again over the mikey-ecc = update. On=20 question to the ECDSA addition. In the comments I sent to the former = version of=20 the draft, there was also ECGDSA included. The advantage of ECGDSA = over=20 ECDSA is that it does not require inverting the ephemeral key and thus = may be=20 interesting for devices with less computational power. Because of this = we should=20 maybe include it as well. What do you think?
 
Regards
    Steffen
From: Eugene Chin=20 [mailto:eugene.chin@gmail.com]
Sent: Saturday, October 21, = 2006=20 3:14 PM
To: 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=20 draft now clearly identifies the 4 additional methods (1 added based = on=20 Steffen's comments):
- extending MIKEY-DHSIGN to use ECDSA
- = extending=20 MIKEY-DHSIGN 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_01C6FE92.609BA45E-- --===============0259762146== 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 --===============0259762146==-- From msec-bounces@ietf.org Thu Nov 02 10:20:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeMY-0004Xl-J6; Thu, 02 Nov 2006 10:20:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeMX-0004XV-Jd for msec@ietf.org; Thu, 02 Nov 2006 10:20:13 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfeMS-0003wK-Ue for msec@ietf.org; Thu, 02 Nov 2006 10:20:13 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id kA2FK74h007131; Thu, 2 Nov 2006 16:20:07 +0100 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 kA2FK7gC020391; Thu, 2 Nov 2006 16:20:07 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 16:20:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Nov 2006 16:18:51 +0100 Message-ID: In-Reply-To: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-msec-mikey-ecc-01.txt thread-index: Acb1E2y+AJId2YLYSxmPXm9oj/myGQJfVzkw From: "Fries, Steffen" To: "Eugene Chin" , X-OriginalArrivalTime: 02 Nov 2006 15:20:07.0009 (UTC) FILETIME=[60D80D10:01C6FE92] X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [MSEC] draft-ietf-msec-mikey-ecc-01.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="===============0259762146==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============0259762146== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FE92.609BA45E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FE92.609BA45E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Eugene, =20 I was just reading again over the mikey-ecc update. On question to the ECDSA addition. In the comments I sent to the former version of the draft, there was also ECGDSA included. The advantage of ECGDSA over ECDSA is that it does not require inverting the ephemeral key and thus may be interesting for devices with less computational power. Because of this we should maybe include it as well. What do you think?=20 =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 =09 =09 Section 3.3 - typo: server -> serve "Nevertheless, the established Diffie-Hellman-Secret may server as a pre-shared key..." =09 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) =09 The rename to MIKEY-ECMQV also affects section 4.1.2. =09 Thanks, Eugene.=20 =09 =09 ------_=_NextPart_001_01C6FE92.609BA45E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Eugene,
 
I was just reading again over the mikey-ecc = update. On=20 question to the ECDSA addition. In the comments I sent to the former = version of=20 the draft, there was also ECGDSA included. The advantage of ECGDSA = over=20 ECDSA is that it does not require inverting the ephemeral key and thus = may be=20 interesting for devices with less computational power. Because of this = we should=20 maybe include it as well. What do you think?
 
Regards
    Steffen
From: Eugene Chin=20 [mailto:eugene.chin@gmail.com]
Sent: Saturday, October 21, = 2006=20 3:14 PM
To: 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=20 draft now clearly identifies the 4 additional methods (1 added based = on=20 Steffen's comments):
- extending MIKEY-DHSIGN to use ECDSA
- = extending=20 MIKEY-DHSIGN 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_01C6FE92.609BA45E-- --===============0259762146== 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 --===============0259762146==-- From msec-bounces@ietf.org Fri Nov 03 01:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfsex-00045I-E7; Fri, 03 Nov 2006 01:36:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfsew-000457-A0 for msec@ietf.org; Fri, 03 Nov 2006 01:36:10 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfset-0001ZH-Ve for msec@ietf.org; Fri, 03 Nov 2006 01:36:10 -0500 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 kA36a61w001413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 2 Nov 2006 22:36:06 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-214.qualcomm.com [10.50.77.214]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA36a4rj027670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Nov 2006 22:36:05 -0800 (PST) Message-Id: <7.0.1.0.2.20061102223432.0690f760@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 02 Nov 2006 22:35:57 -0800 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [MSEC] Please send your presentations ASAP 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, I need two things actually: 1. From the presenters, please send your presentations ASAP. I need to upload them so people who might be participating remotely will have access to them. 2. I need a volunteer to take minutes. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Nov 03 01:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfsex-00045I-E7; Fri, 03 Nov 2006 01:36:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfsew-000457-A0 for msec@ietf.org; Fri, 03 Nov 2006 01:36:10 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfset-0001ZH-Ve for msec@ietf.org; Fri, 03 Nov 2006 01:36:10 -0500 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 kA36a61w001413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 2 Nov 2006 22:36:06 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-214.qualcomm.com [10.50.77.214]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA36a4rj027670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Nov 2006 22:36:05 -0800 (PST) Message-Id: <7.0.1.0.2.20061102223432.0690f760@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 02 Nov 2006 22:35:57 -0800 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [MSEC] Please send your presentations ASAP 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, I need two things actually: 1. From the presenters, please send your presentations ASAP. I need to upload them so people who might be participating remotely will have access to them. 2. I need a volunteer to take minutes. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Nov 03 07:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy2z-0004bb-Uh; Fri, 03 Nov 2006 07:21:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy2y-0004Z2-L3 for msec@ietf.org; Fri, 03 Nov 2006 07:21:20 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfy2l-0007rB-VS for msec@ietf.org; Fri, 03 Nov 2006 07:21:20 -0500 Received: by nf-out-0910.google.com with SMTP id n29so151925nfc for ; Fri, 03 Nov 2006 04:21:07 -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=P4gEd6UxWRubH67xvCgh3MHUUabZ5xDqnscC+M4HbvIe9yjo3oSP4GeWrEYGjG4lSIHWQxZIGgi1Z/k9bbma3FeRP4HXuM+/bZCj747NqtkN5qbKifRJPStIRHCAWRFqZpQj/eP2psG4gOF0LrIK8TBo8GWRvln+4GfihI+inZE= Received: by 10.82.152.16 with SMTP id z16mr102580bud.1162556466554; Fri, 03 Nov 2006 04:21:06 -0800 (PST) Received: by 10.82.148.6 with HTTP; Fri, 3 Nov 2006 04:21:06 -0800 (PST) Message-ID: <8ba53040611030421r74a4240ex86f432d81ed127b9@mail.gmail.com> Date: Fri, 3 Nov 2006 07:21:06 -0500 From: "Eugene Chin" To: "Fries, Steffen" In-Reply-To: MIME-Version: 1.0 References: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: msec@ietf.org Subject: [MSEC] Re: draft-ietf-msec-mikey-ecc-01.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="===============1344559271==" Errors-To: msec-bounces@ietf.org --===============1344559271== Content-Type: multipart/alternative; boundary="----=_Part_20308_7154352.1162556466527" ------=_Part_20308_7154352.1162556466527 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Steffen, In the comments I sent to the former version of the draft, there was > also ECGDSA included. > Oops, I appear to have missed this point from your previous comments. To be honest, I am not familiar with ECGDSA, and will get back to you. Thanks, Eugene. ------=_Part_20308_7154352.1162556466527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Steffen,

In the comments I sent to the former version of the draft, there was also ECGDSA included.

Oops, I appear to have missed this point from your previous comments.  To be honest, I am not familiar with ECGDSA, and will get back to you.

Thanks,
Eugene.
 


------=_Part_20308_7154352.1162556466527-- --===============1344559271== 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 --===============1344559271==-- From msec-bounces@ietf.org Fri Nov 03 07:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy2z-0004bb-Uh; Fri, 03 Nov 2006 07:21:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy2y-0004Z2-L3 for msec@ietf.org; Fri, 03 Nov 2006 07:21:20 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfy2l-0007rB-VS for msec@ietf.org; Fri, 03 Nov 2006 07:21:20 -0500 Received: by nf-out-0910.google.com with SMTP id n29so151925nfc for ; Fri, 03 Nov 2006 04:21:07 -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=P4gEd6UxWRubH67xvCgh3MHUUabZ5xDqnscC+M4HbvIe9yjo3oSP4GeWrEYGjG4lSIHWQxZIGgi1Z/k9bbma3FeRP4HXuM+/bZCj747NqtkN5qbKifRJPStIRHCAWRFqZpQj/eP2psG4gOF0LrIK8TBo8GWRvln+4GfihI+inZE= Received: by 10.82.152.16 with SMTP id z16mr102580bud.1162556466554; Fri, 03 Nov 2006 04:21:06 -0800 (PST) Received: by 10.82.148.6 with HTTP; Fri, 3 Nov 2006 04:21:06 -0800 (PST) Message-ID: <8ba53040611030421r74a4240ex86f432d81ed127b9@mail.gmail.com> Date: Fri, 3 Nov 2006 07:21:06 -0500 From: "Eugene Chin" To: "Fries, Steffen" In-Reply-To: MIME-Version: 1.0 References: <8ba53040610210614h6d5d3dbbk87a3cdb30512267e@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: msec@ietf.org Subject: [MSEC] Re: draft-ietf-msec-mikey-ecc-01.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="===============1344559271==" Errors-To: msec-bounces@ietf.org --===============1344559271== Content-Type: multipart/alternative; boundary="----=_Part_20308_7154352.1162556466527" ------=_Part_20308_7154352.1162556466527 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Steffen, In the comments I sent to the former version of the draft, there was > also ECGDSA included. > Oops, I appear to have missed this point from your previous comments. To be honest, I am not familiar with ECGDSA, and will get back to you. Thanks, Eugene. ------=_Part_20308_7154352.1162556466527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Steffen,

In the comments I sent to the former version of the draft, there was also ECGDSA included.

Oops, I appear to have missed this point from your previous comments.  To be honest, I am not familiar with ECGDSA, and will get back to you.

Thanks,
Eugene.
 


------=_Part_20308_7154352.1162556466527-- --===============1344559271== 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 --===============1344559271==-- From msec-bounces@ietf.org Fri Nov 03 07:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy5L-0005zj-KY; Fri, 03 Nov 2006 07:23:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy5J-0005z9-Dy for msec@ietf.org; Fri, 03 Nov 2006 07:23:45 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfy51-0008DN-AM for msec@ietf.org; Fri, 03 Nov 2006 07:23:45 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kA3CNPHN004162; Fri, 3 Nov 2006 13:23:25 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kA3CNMir009499; Fri, 3 Nov 2006 13:23:25 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 13:23:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Nov 2006 13:22:04 +0100 Message-ID: In-Reply-To: <8ba53040611030421r74a4240ex86f432d81ed127b9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-msec-mikey-ecc-01.txt thread-index: Acb/QosBJxu9o2fOSUSF9evpIqD7mgAAAk+A From: "Fries, Steffen" To: "Eugene Chin" X-OriginalArrivalTime: 03 Nov 2006 12:23:22.0839 (UTC) FILETIME=[DAADDE70:01C6FF42] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: msec@ietf.org Subject: [MSEC] RE: draft-ietf-msec-mikey-ecc-01.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="===============1494543944==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1494543944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FF42.DA5A53C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FF42.DA5A53C5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HI Eugene, =20 if you need further information on ECGDSA, just let me know. =20 Ciao Steffen ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com]=20 Sent: Friday, November 03, 2006 1:21 PM To: Fries, Steffen Cc: msec@ietf.org Subject: Re: draft-ietf-msec-mikey-ecc-01.txt =09 =09 Hi Steffen, =09 =09 =09 In the comments I sent to the former version of the draft, there was also ECGDSA included. Oops, I appear to have missed this point from your previous comments. To be honest, I am not familiar with ECGDSA, and will get back to you.=20 =09 Thanks, Eugene. =20 ------_=_NextPart_001_01C6FF42.DA5A53C5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
HI Eugene,
 
if you need further information on ECGDSA, just = let me=20 know.
 
Ciao
    Steffen

From: Eugene Chin=20 [mailto:eugene.chin@gmail.com]
Sent: Friday, November 03, = 2006 1:21=20 PM
To: Fries, Steffen
Cc: = msec@ietf.org
Subject:=20 Re: draft-ietf-msec-mikey-ecc-01.txt

Hi Steffen,

In the=20 comments I sent to the former version of the draft, there was=20 also ECGDSA included.

Oops, I appear to have missed this point from your previous=20 comments.  To be honest, I am not familiar with ECGDSA, and will = get back=20 to you.=20

Thanks,
Eugene.
 


------_=_NextPart_001_01C6FF42.DA5A53C5-- --===============1494543944== 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 --===============1494543944==-- From msec-bounces@ietf.org Fri Nov 03 07:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy5L-0005zj-KY; Fri, 03 Nov 2006 07:23:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfy5J-0005z9-Dy for msec@ietf.org; Fri, 03 Nov 2006 07:23:45 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfy51-0008DN-AM for msec@ietf.org; Fri, 03 Nov 2006 07:23:45 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kA3CNPHN004162; Fri, 3 Nov 2006 13:23:25 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kA3CNMir009499; Fri, 3 Nov 2006 13:23:25 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 13:23:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Nov 2006 13:22:04 +0100 Message-ID: In-Reply-To: <8ba53040611030421r74a4240ex86f432d81ed127b9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-msec-mikey-ecc-01.txt thread-index: Acb/QosBJxu9o2fOSUSF9evpIqD7mgAAAk+A From: "Fries, Steffen" To: "Eugene Chin" X-OriginalArrivalTime: 03 Nov 2006 12:23:22.0839 (UTC) FILETIME=[DAADDE70:01C6FF42] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: msec@ietf.org Subject: [MSEC] RE: draft-ietf-msec-mikey-ecc-01.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="===============1494543944==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1494543944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FF42.DA5A53C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FF42.DA5A53C5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HI Eugene, =20 if you need further information on ECGDSA, just let me know. =20 Ciao Steffen ________________________________ From: Eugene Chin [mailto:eugene.chin@gmail.com]=20 Sent: Friday, November 03, 2006 1:21 PM To: Fries, Steffen Cc: msec@ietf.org Subject: Re: draft-ietf-msec-mikey-ecc-01.txt =09 =09 Hi Steffen, =09 =09 =09 In the comments I sent to the former version of the draft, there was also ECGDSA included. Oops, I appear to have missed this point from your previous comments. To be honest, I am not familiar with ECGDSA, and will get back to you.=20 =09 Thanks, Eugene. =20 ------_=_NextPart_001_01C6FF42.DA5A53C5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
HI Eugene,
 
if you need further information on ECGDSA, just = let me=20 know.
 
Ciao
    Steffen

From: Eugene Chin=20 [mailto:eugene.chin@gmail.com]
Sent: Friday, November 03, = 2006 1:21=20 PM
To: Fries, Steffen
Cc: = msec@ietf.org
Subject:=20 Re: draft-ietf-msec-mikey-ecc-01.txt

Hi Steffen,

In the=20 comments I sent to the former version of the draft, there was=20 also ECGDSA included.

Oops, I appear to have missed this point from your previous=20 comments.  To be honest, I am not familiar with ECGDSA, and will = get back=20 to you.=20

Thanks,
Eugene.
 


------_=_NextPart_001_01C6FF42.DA5A53C5-- --===============1494543944== 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 --===============1494543944==-- From msec-bounces@securemulticast.org Fri Nov 03 11:00:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg1Si-0006Tv-At for msec-archive@lists.ietf.org; Fri, 03 Nov 2006 11:00:08 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg1Sf-00081O-0c for msec-archive@lists.ietf.org; Fri, 03 Nov 2006 11:00:08 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 412EB2CDDD; Fri, 3 Nov 2006 10:59:56 -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 B85E22CA2E for ; Fri, 3 Nov 2006 10:59:54 -0500 (EST) Received: (qmail 36800 invoked by uid 3269); 3 Nov 2006 15:59:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36797 invoked from network); 3 Nov 2006 15:59:54 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 3 Nov 2006 15:59:54 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 7BB5AE9D90 for ; Fri, 3 Nov 2006 10:59:54 -0500 (EST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mailwash15.pair.com (Postfix) with ESMTP id 425E2E9D7C for ; Fri, 3 Nov 2006 10:59:54 -0500 (EST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id kA3Fxnaq010659; Fri, 3 Nov 2006 16:59:50 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id kA3Fxnpd027634; Fri, 3 Nov 2006 16:59:49 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 16:59:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata Date: Fri, 3 Nov 2006 16:59:47 +0100 Message-ID: In-reply-to: <1ECE0EB50388174790F9694F77522CCF0DC994F0@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata Thread-Index: AcbyBV/5PjRRxM1rSUCitHEUG8AQTQKzKUdwAA4phoAAlWNRQA== From: "Euchner, Martin" To: "Francois Audet" , , "Euchner, Martin" X-OriginalArrivalTime: 03 Nov 2006 15:59:49.0148 (UTC) FILETIME=[171F5DC0:01C6FF61] 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: 08170828343bcf1325e4a0fb4584481c Francois, I can't help it, if 4 and a half years of draft available is not enough for you to catch errors. It also may have escaped your eyes that correction no. 15 is in fact an essential one that is worth recording on the errata, while items no 1 - 15 are rather editorial improvements/beautifications that may not have a high priority to get turned into an erratum. Martin Euchner. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 03 12:32:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg2uI-0004IO-5P for msec-archive@lists.ietf.org; Fri, 03 Nov 2006 12:32:42 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg2uF-00081U-T0 for msec-archive@lists.ietf.org; Fri, 03 Nov 2006 12:32:42 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0D1E22CE57; Fri, 3 Nov 2006 12:30:54 -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 1D32A2CD37 for ; Fri, 3 Nov 2006 12:30:38 -0500 (EST) Received: (qmail 62643 invoked by uid 3269); 3 Nov 2006 17:30:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62640 invoked from network); 3 Nov 2006 17:30:28 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 3 Nov 2006 17:30:28 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 14164E9D8C for ; Fri, 3 Nov 2006 12:30:23 -0500 (EST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by mailwash15.pair.com (Postfix) with ESMTP id DD3BDE9D13 for ; Fri, 3 Nov 2006 12:30:18 -0500 (EST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kA3HU2S26605; Fri, 3 Nov 2006 12:30:02 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata Date: Fri, 3 Nov 2006 11:30:01 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DD9E4EC@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/5PjRRxM1rSUCitHEUG8AQTQKzKUdwAA4phoAAlWNRQAADUydQ 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: 9466e0365fc95844abaf7c3f15a05c7d I guess it's not the time that counts, but the number of eyes that are activelly looking at it.=20 Disclaimer: I hadn't looked at it. > -----Original Message----- > From: Euchner, Martin [mailto:martin.euchner@siemens.com]=20 > Sent: Friday, November 03, 2006 8:00 AM > To: Audet, Francois (SC100:3055); msec@securemulticast.org;=20 > Euchner, Martin > Subject: RE: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata >=20 > Francois, >=20 > I can't help it, if 4 and a half years of draft available is=20 > not enough for you to catch errors. >=20 > It also may have escaped your eyes that correction no. 15 is=20 > in fact an essential one that is worth recording on the=20 > errata, while items no 1 - > 15 are rather editorial improvements/beautifications that may=20 > not have a high priority to get turned into an erratum. >=20 > Martin Euchner. >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 03 16:24:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg6WD-0000g6-0R for msec-archive@lists.ietf.org; Fri, 03 Nov 2006 16:24:05 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg6WB-0007ZC-L6 for msec-archive@lists.ietf.org; Fri, 03 Nov 2006 16:24:04 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 588052CB11; Fri, 3 Nov 2006 16:23:50 -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 E17D82CA70 for ; Fri, 3 Nov 2006 16:23:48 -0500 (EST) Received: (qmail 27713 invoked by uid 3269); 3 Nov 2006 21:23:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27710 invoked from network); 3 Nov 2006 21:23:48 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 3 Nov 2006 21:23:48 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 14F6AE9DBB for ; Fri, 3 Nov 2006 16:23:49 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mailwash15.pair.com (Postfix) with ESMTP id 34D60E9DAE for ; Fri, 3 Nov 2006 16:23:47 -0500 (EST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 03 Nov 2006 13:23:45 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAJCS0WrR7O6/2dsb2JhbAA X-IronPort-AV: i="4.09,386,1157353200"; d="scan'208"; a="1861948268:sNHT34834100" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA3LNix2006284; Fri, 3 Nov 2006 13:23:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA3LNiAo006484; Fri, 3 Nov 2006 13:23:44 -0800 (PST) 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); Fri, 3 Nov 2006 13:23:44 -0800 Received: from [192.168.0.10] ([10.21.113.217]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 13:23:43 -0800 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DD9E4EC@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DD9E4EC@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <771CED96-F5C2-4F8B-B654-C5C29FF3E8D4@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata Date: Fri, 3 Nov 2006 13:23:34 -0800 To: Francois Audet X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Nov 2006 21:23:43.0980 (UTC) FILETIME=[572F62C0:01C6FF8E] DKIM-Signature: a=rsa-sha1; q=dns; l=1201; t=1162589025; x=1163453025; 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]=20FW=3A=20proposed=20RFC=204650=20=22MIKEY=20DHHMAC=22=20 errata; X=v=3Dcisco.com=3B=20h=3Dakm9IudSDVmr3Ya+mf/E7gKB0y4=3D; b=Wl7EUOrq8arb6EYRhG6XiwHmpZc/VHBdFF4UnsajmWGXwgKZD1j5lU512lsy7aDRznlFZbus D3nAUkrf62dV2b9w3OlAwEFS489KF4zR90lT/kpWWZkYzY/5hKmCkwAE; Authentication-Results: sj-dkim-2.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: "Euchner, Martin" , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cathy Meadows discovered a problem with GDOI proof of possession about two years after RFC 3547 was published. Mark On Nov 3, 2006, at 9:30 AM, Francois Audet wrote: > I guess it's not the time that counts, but the number of eyes that > are activelly looking at it. > > Disclaimer: I hadn't looked at it. > >> -----Original Message----- >> From: Euchner, Martin [mailto:martin.euchner@siemens.com] >> Sent: Friday, November 03, 2006 8:00 AM >> To: Audet, Francois (SC100:3055); msec@securemulticast.org; >> Euchner, Martin >> Subject: RE: [MSEC] FW: proposed RFC 4650 "MIKEY DHHMAC" errata >> >> Francois, >> >> I can't help it, if 4 and a half years of draft available is >> not enough for you to catch errors. >> >> It also may have escaped your eyes that correction no. 15 is >> in fact an essential one that is worth recording on the >> errata, while items no 1 - >> 15 are rather editorial improvements/beautifications that may >> not have a high priority to get turned into an erratum. >> >> Martin Euchner. >> > _______________________________________________ > 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@ietf.org Mon Nov 06 03:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzeN-0002rA-S1; Mon, 06 Nov 2006 03:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzeM-0002r4-EW for msec@ietf.org; Mon, 06 Nov 2006 03:16:10 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgzeL-0002QW-47 for msec@ietf.org; Mon, 06 Nov 2006 03:16:10 -0500 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 kA68G7d3031940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Nov 2006 00:16:08 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-39.qualcomm.com [10.50.77.39]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA68G6mf023944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Nov 2006 00:16:06 -0800 (PST) Message-Id: <7.0.1.0.2.20061106000855.064e53d8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Nov 2006 00:15:57 -0800 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: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Presentations uploaded 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 received 3 presentations (MIKEY-ECC, MIKEY-XTR and GDOI-SRTP) and uploaded them to the IETF meeting materials page. If I missed any, please send me a note and I will find them in my mailbox. If you haven't sent your presentation yet, please do so ASAP. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Nov 06 03:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzeN-0002rA-S1; Mon, 06 Nov 2006 03:16:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzeM-0002r4-EW for msec@ietf.org; Mon, 06 Nov 2006 03:16:10 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgzeL-0002QW-47 for msec@ietf.org; Mon, 06 Nov 2006 03:16:10 -0500 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 kA68G7d3031940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Nov 2006 00:16:08 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-39.qualcomm.com [10.50.77.39]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA68G6mf023944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Nov 2006 00:16:06 -0800 (PST) Message-Id: <7.0.1.0.2.20061106000855.064e53d8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Nov 2006 00:15:57 -0800 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: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Presentations uploaded 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 received 3 presentations (MIKEY-ECC, MIKEY-XTR and GDOI-SRTP) and uploaded them to the IETF meeting materials page. If I missed any, please send me a note and I will find them in my mailbox. If you haven't sent your presentation yet, please do so ASAP. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Nov 06 03:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggzts-0006ir-0C; Mon, 06 Nov 2006 03:32:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggztr-0006il-DW for msec@ietf.org; Mon, 06 Nov 2006 03:32:11 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggztq-0004ch-2c for msec@ietf.org; Mon, 06 Nov 2006 03:32:11 -0500 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 kA68W8Bo021524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Nov 2006 00:32:09 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-39.qualcomm.com [10.50.77.39]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA68W7ST007602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Nov 2006 00:32:08 -0800 (PST) Message-Id: <7.0.1.0.2.20061106003054.0664b470@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Nov 2006 00:31:59 -0800 To: msec@ietf.org From: Lakshminath Dondeti Subject: Re: [MSEC] Presentations uploaded In-Reply-To: <7.0.1.0.2.20061106000855.064e53d8@qualcomm.com> References: <7.0.1.0.2.20061106000855.064e53d8@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 I found a fourth in my mailbox; sorry about that. "Sharing Keying Messages Among Group Members" has also been uploaded. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 Lakshminath At 12:15 AM 11/6/2006, Lakshminath Dondeti wrote: >Hi all, > >I received 3 presentations (MIKEY-ECC, MIKEY-XTR and GDOI-SRTP) and >uploaded them to the IETF meeting materials page. If I missed any, >please send me a note and I will find them in my mailbox. If you >haven't sent your presentation yet, please do so ASAP. > >thanks, >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 Mon Nov 06 03:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggzts-0006ir-0C; Mon, 06 Nov 2006 03:32:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggztr-0006il-DW for msec@ietf.org; Mon, 06 Nov 2006 03:32:11 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggztq-0004ch-2c for msec@ietf.org; Mon, 06 Nov 2006 03:32:11 -0500 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 kA68W8Bo021524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Nov 2006 00:32:09 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-39.qualcomm.com [10.50.77.39]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA68W7ST007602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Nov 2006 00:32:08 -0800 (PST) Message-Id: <7.0.1.0.2.20061106003054.0664b470@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Nov 2006 00:31:59 -0800 To: msec@ietf.org From: Lakshminath Dondeti Subject: Re: [MSEC] Presentations uploaded In-Reply-To: <7.0.1.0.2.20061106000855.064e53d8@qualcomm.com> References: <7.0.1.0.2.20061106000855.064e53d8@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 I found a fourth in my mailbox; sorry about that. "Sharing Keying Messages Among Group Members" has also been uploaded. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 Lakshminath At 12:15 AM 11/6/2006, Lakshminath Dondeti wrote: >Hi all, > >I received 3 presentations (MIKEY-ECC, MIKEY-XTR and GDOI-SRTP) and >uploaded them to the IETF meeting materials page. If I missed any, >please send me a note and I will find them in my mailbox. If you >haven't sent your presentation yet, please do so ASAP. > >thanks, >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@securemulticast.org Mon Nov 06 12:42:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8Tz-0008OA-5t for msec-archive@lists.ietf.org; Mon, 06 Nov 2006 12:42:03 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8To-0000YH-SD for msec-archive@lists.ietf.org; Mon, 06 Nov 2006 12:42:03 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 63EE82CEC4; Mon, 6 Nov 2006 12:41:37 -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 EF3B62CB89 for ; Mon, 6 Nov 2006 12:41:34 -0500 (EST) Received: (qmail 66398 invoked by uid 3269); 6 Nov 2006 17:41:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66267 invoked from network); 6 Nov 2006 17:41:31 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 6 Nov 2006 17:41:31 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 36571E9D9C for ; Mon, 6 Nov 2006 12:41:32 -0500 (EST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mailwash15.pair.com (Postfix) with ESMTP id B40C5E9D93 for ; Mon, 6 Nov 2006 12:41:31 -0500 (EST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 466F811AA for ; Mon, 6 Nov 2006 18:41:26 +0100 (CET) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:41:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Nov 2006 18:41:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments to mikey applicability draft Thread-Index: Acb+BtawS+Wihtk4Qr2uS6FFf8aqqgDd6SJw From: "Vesa Lehtovirta \(JO/LMF\)" To: X-OriginalArrivalTime: 06 Nov 2006 17:41:25.0947 (UTC) FILETIME=[C85650B0:01C701CA] X-Brightmail-Tracker: AAAAAA== Subject: [MSEC] Some comments to mikey applicability draft X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0081440239==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae This is a multi-part message in MIME format. --===============0081440239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C701CA.C81F3E85" This is a multi-part message in MIME format. ------_=_NextPart_001_01C701CA.C81F3E85 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Here are some comments to the MIKEY applicability draft. Unfortunately I have not been able to review all parts of the document with the same depth. =20 - In generel I see that this kind of document is very useful, also in the context of RTPSEC. =20 - The structure of the document seems good, but I would like to propose that section 3 could more clearly highlight/separate which modes of MIKEY are original from RFC 3830 and which are introduced later. =20 - The RCC draft mentioned in section 4.4 is not actually a MIKEY extension, but an extension to SRTP. It is true that it introduces some new parameters to be carried in MIKEY, but it is not a MIKEY extension in the same sense as the other extension mentioned in section 4, so it could probably even be left out or re-categorized .=20 - The scope of the document could be clarified somewhat. The abstract gives the impression that it is giving overview of MIKEY and extensions, but introduction says that it gives also insight to different use cases. These could be aligned and the introduction could probably also shortly discuss what kind of use scenarios are going to be analysed (especially the use cases described in section 5 could be mentioned).=20 - The section 7 on MIKEY related IANA registrations could be closer to section 10.=20 =20 - In introduction, the key distribution methods could include a reference to the applicable RFC or draft - In the paragraph just above 3.1 it is said:=20 " Neverheless in multimedia communication scenarios supporting forking Section 5.2, collisions may occur leading to so- called two-time pads, i.e., the same key is used for media streams to different destinations. "=20 Comment: It should be noted that two-time pads can also happen to streams going to the same destinations. Actually the risk is there if there is a possibility of collision of all parameters that are used for keystream calculation.=20 - In 6 on transport of MiKEY messages it could be added that MIKEY can also be transported over plain UDP and then the port number is 2269. =20 best regards, Vesa =20 ------_=_NextPart_001_01C701CA.C81F3E85 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Here are some=20 comments to the MIKEY applicability draft.  Unfortunately I have not been able to = review all=20 parts of the document with the same = depth.
 
- In generel = I see that=20 this kind of document is very useful, also in the context of=20 RTPSEC.  
- The = structure of=20 the document seems good, but I would like to propose that section 3 = could more=20 clearly highlight/separate which modes of MIKEY are = original from RFC=20 3830 and which are introduced later.  
- The = RCC draft=20 mentioned in section 4.4 is not actually a MIKEY extension, but an = extension to=20 SRTP. It is true that it introduces some new parameters to be carried in = MIKEY,=20 but it is not a MIKEY extension in the same sense as the other extension = mentioned in section 4, so it could probably even be left out or re-categorized .=20
- The = scope of the=20 document could be clarified somewhat. The abstract gives the impression = that it=20 is giving overview of MIKEY and extensions, but introduction says that = it gives=20 also insight to different use cases. These could  be aligned = and the=20 introduction could probably also shortly discuss what kind of use = scenarios are=20 going to be analysed (especially the use cases described in section = 5  could be mentioned). =
- The = section 7 on=20 MIKEY related IANA registrations could be closer to section 10.
 
- In introduction, the key=20 distribution methods could include a reference to the applicable RFC or=20 draft
-=20 In the paragraph just above 3.1 it is said:

 " Neverheless in multimedia = communication=20 scenarios

   = supporting=20 forking Section 5.2, collisions may occur leading to=20 so-

   = called two-time=20 pads, i.e., the same key is used for media streams=20 to

   = different=20 destinations. " <= /P>

Comment:=20 It should be noted that two-time pads can also happen to streams going = to the=20 same destinations. Actually the risk is there if there is a possibility = of=20 collision of all parameters that are used for keystream calculation.=20

- In 6 = on transport=20 of MiKEY messages it could be added that MIKEY can also be transported = over=20 plain UDP and then the port number is 2269.
 
best=20 regards,
  = Vesa
 
------_=_NextPart_001_01C701CA.C81F3E85-- --===============0081440239== 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 --===============0081440239==-- From msec-bounces@securemulticast.org Mon Nov 06 13:24:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh99N-000276-0U for msec-archive@lists.ietf.org; Mon, 06 Nov 2006 13:24:49 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh99G-00066e-MW for msec-archive@lists.ietf.org; Mon, 06 Nov 2006 13:24:48 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E7DBF2CD78; Mon, 6 Nov 2006 13:18:48 -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 711F62CD67 for ; Mon, 6 Nov 2006 13:18:42 -0500 (EST) Received: (qmail 78386 invoked by uid 3269); 6 Nov 2006 18:18:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78383 invoked from network); 6 Nov 2006 18:18:42 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 6 Nov 2006 18:18:42 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id D043DE9DAD for ; Mon, 6 Nov 2006 13:18:42 -0500 (EST) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by mailwash15.pair.com (Postfix) with ESMTP id 31B87E9D18 for ; Mon, 6 Nov 2006 13:18:42 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kA6IIeDY006858; Mon, 6 Nov 2006 19:18:40 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kA6IIcNs009818; Mon, 6 Nov 2006 19:18:39 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:18:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Some comments to mikey applicability draft Date: Mon, 6 Nov 2006 19:18:38 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Some comments to mikey applicability draft Thread-Index: Acb+BtawS+Wihtk4Qr2uS6FFf8aqqgDd6SJwABPSzBA= From: "Fries, Steffen" To: "Vesa Lehtovirta \(JO/LMF\)" , X-OriginalArrivalTime: 06 Nov 2006 18:18:38.0760 (UTC) FILETIME=[FB328A80:01C701CF] 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: , Content-Type: multipart/mixed; boundary="===============1244906532==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a This is a multi-part message in MIME format. --===============1244906532== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C701CF.FB05DEBE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C701CF.FB05DEBE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Vesa, =20 thanks for the commenst on the applicability draft. I'm preparing an updated version of the draft and will include your comments.=20 =20 Regarding RCC, well, its not rally an extension, but as it defines some new payloads, we thought for the sake of completness we state it as well. I will make a note regarding the MIKEY relation in out draft. =20 Regards Steffen ________________________________ From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa Lehtovirta (JO/LMF) Sent: Monday, November 06, 2006 6:42 PM To: msec@securemulticast.org Subject: [MSEC] Some comments to mikey applicability draft =09 =09 Hi, =20 Here are some comments to the MIKEY applicability draft. Unfortunately I have not been able to review all parts of the document with the same depth. =20 - In generel I see that this kind of document is very useful, also in the context of RTPSEC. =20 - The structure of the document seems good, but I would like to propose that section 3 could more clearly highlight/separate which modes of MIKEY are original from RFC 3830 and which are introduced later. =20 - The RCC draft mentioned in section 4.4 is not actually a MIKEY extension, but an extension to SRTP. It is true that it introduces some new parameters to be carried in MIKEY, but it is not a MIKEY extension in the same sense as the other extension mentioned in section 4, so it could probably even be left out or re-categorized .=20 - The scope of the document could be clarified somewhat. The abstract gives the impression that it is giving overview of MIKEY and extensions, but introduction says that it gives also insight to different use cases. These could be aligned and the introduction could probably also shortly discuss what kind of use scenarios are going to be analysed (especially the use cases described in section 5 could be mentioned).=20 - The section 7 on MIKEY related IANA registrations could be closer to section 10.=20 =20 - In introduction, the key distribution methods could include a reference to the applicable RFC or draft - In the paragraph just above 3.1 it is said:=20 " Neverheless in multimedia communication scenarios supporting forking Section 5.2, collisions may occur leading to so- called two-time pads, i.e., the same key is used for media streams to different destinations. "=20 Comment: It should be noted that two-time pads can also happen to streams going to the same destinations. Actually the risk is there if there is a possibility of collision of all parameters that are used for keystream calculation.=20 - In 6 on transport of MiKEY messages it could be added that MIKEY can also be transported over plain UDP and then the port number is 2269. =20 best regards, Vesa =20 ------_=_NextPart_001_01C701CF.FB05DEBE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Vesa,
 
thanks for the commenst on the applicability = draft. I'm=20 preparing an updated version of the draft and will include your = comments.=20
 
Regarding RCC, well, its not rally an = extension, but as it=20 defines some new payloads, we thought for the sake of completness we = state it as=20 well. I will make a note regarding the MIKEY relation in out=20 draft.
 
Regards
  Steffen

From: = msec-bounces@securemulticast.org=20 [mailto:msec-bounces@securemulticast.org] On Behalf Of Vesa = Lehtovirta=20 (JO/LMF)
Sent: Monday, November 06, 2006 6:42 = PM
To:=20 msec@securemulticast.org
Subject: [MSEC] Some comments to = mikey=20 applicability draft

Hi,
 
Here are=20 some comments to the MIKEY applicability draft.  Unfortunately I have not been able to = review=20 all parts of the document with the same=20 depth.
 
- In = generel I see=20 that this kind of document is very useful, also in the context of=20 RTPSEC.  
- = The structure of=20 the document seems good, but I would like to propose that section 3 = could more=20 clearly highlight/separate which modes of MIKEY are = original from=20 RFC 3830 and which are introduced later.  
- = The RCC draft=20 mentioned in section 4.4 is not actually a MIKEY extension, but an = extension=20 to SRTP. It is true that it introduces some new parameters to be = carried in=20 MIKEY, but it is not a MIKEY extension in the same sense as the other=20 extension mentioned in section 4, so it could probably even be left = out or re-categorized .=20
- = The scope of the=20 document could be clarified somewhat. The abstract gives the = impression that=20 it is giving overview of MIKEY and extensions, but introduction says = that it=20 gives also insight to different use cases. These could  be = aligned=20 and the introduction could probably also shortly discuss what kind of = use=20 scenarios are going to be analysed (especially the use cases described = in=20 section 5  could be=20 mentioned).
- = The section 7 on=20 MIKEY related IANA registrations could be closer to section 10. =
 
- In introduction, the key=20 distribution methods could include a reference to the applicable RFC = or=20 draft
-=20 In the paragraph just above 3.1 it is said:

 " Neverheless in multimedia = communication=20 scenarios

   = supporting=20 forking Section 5.2, collisions may occur leading to=20 so-

   = called two-time=20 pads, i.e., the same key is used for media streams=20 to

   = different=20 destinations. " <= /P>

Comment:=20 It should be noted that two-time pads can also happen to streams going = to the=20 same destinations. Actually the risk is there if there is a = possibility of=20 collision of all parameters that are used for keystream calculation.=20

- In = 6 on=20 transport of MiKEY messages it could be added that MIKEY can also be=20 transported over plain UDP and then the port number is=20 2269.
 
best = regards,
 =20 Vesa
 
------_=_NextPart_001_01C701CF.FB05DEBE-- --===============1244906532== 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 --===============1244906532==-- From msec-bounces@securemulticast.org Mon Nov 06 17:58:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQQ-0003ag-9R for msec-archive@lists.ietf.org; Mon, 06 Nov 2006 17:58:42 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDIL-0000YG-GI for msec-archive@lists.ietf.org; Mon, 06 Nov 2006 17:50:25 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D50972CFD3; Mon, 6 Nov 2006 17:50:04 -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 8E8DF2CFCD for ; Mon, 6 Nov 2006 17:50:03 -0500 (EST) Received: (qmail 62177 invoked by uid 3269); 6 Nov 2006 22:50:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62174 invoked from network); 6 Nov 2006 22:50:03 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 6 Nov 2006 22:50:03 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 75B64E9DA9 for ; Mon, 6 Nov 2006 17:50:03 -0500 (EST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mailwash15.pair.com (Postfix) with ESMTP id 488B1E9DA6 for ; Mon, 6 Nov 2006 17:50:03 -0500 (EST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2006 14:50:02 -0800 X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="755046076:sNHT51407978" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6Mo2Uv029773; Mon, 6 Nov 2006 14:50:02 -0800 Received: from [12.105.242.148] (sjc-vpn4-488.cisco.com [10.21.81.232]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6Mo0in023263; Mon, 6 Nov 2006 14:50:01 -0800 (PST) In-Reply-To: <17743.45851.948008.989306@fireball.kivinen.iki.fi> References: <17743.45851.948008.989306@fireball.kivinen.iki.fi> 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: Brian Weis Date: Mon, 6 Nov 2006 14:49:54 -0800 To: Tero Kivinen X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1752; t=1162853402; x=1163717402; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:Brian=20Weis=20 |Subject:Re=3A=20draft-ietf-msecipsec-extensions-04.txt; X=v=3Dcisco.com=3B=20h=3Dx3EjiXMg11IqAGHlwSF+73K8rR4=3D; b=en/GYgXy41YosrMutNK3kQFYVLOtXa/7HxBSew+BGpyqS8yiHg0MAoTbx0Ew+YWzsRTY6RwZ avFXXmAKjV1yQUKcR84WqAaFmjQTu7AP3pFaTwh1QCMtjQFJ5w0RIqul; Authentication-Results: sj-dkim-4.cisco.com; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: dignjatic@polycom.com, gmgross@identaware.com, msec-chairs@tools.ietf.org, msec@securemulticast.org Subject: [MSEC] Re: draft-ietf-msecipsec-extensions-04.txt 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: c1c65599517f9ac32519d043c37c5336 Hi Tero, Thanks for the correction on the IKEv2 reference ... we'll fix that in the next draft. I also believe that the notion of "comparable" in the final sentence intends to say that the GKM must have a facility that achieves the same result (which may be similar to IKEv1, IKEv2, or something else entirely). We'll clarify that as well. Thanks, Brian On Nov 6, 2006, at 2:11 PM, Tero Kivinen wrote: >> 6.3.3.6 UDP Checksum Dependency on Source IP Address > ... >> In a transport mode multicast application GSA, the UDP checksum >> operation requires the origin endpoint's IP address to complete >> successfully. In IKEv2, this information is exchanged between the >> endpoints by a NAT-OA payload (NAT original address). See also >> reference [RFC3947]. A comparable facility must exist in a GKM >> protocol payload that defines the multicast application GSA >> attributes for each Group Speaker. > > IKEv2 do not use NAT-OA payloads at all. NAT-OA payloads are only > used in the IKEv1. The RFC 4306 section 2.23 says: > > The original source and destination IP address required for the > transport mode TCP and UDP packet checksum fixup (see [Hutt05]) > are obtained from the Traffic Selectors associated with the > exchange. In the case of NAT traversal, the Traffic Selectors > MUST contain exactly one IP address, which is then used as the > original IP address. > > I.e. the original IP addresses for the cehcksum fixup are taken from > the traffic selectors. > -- > kivinen@safenet-inc.com -- 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@ietf.org Mon Nov 06 19:56:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFFX-0003q3-Ro; Mon, 06 Nov 2006 19:55:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFFW-0003pO-GI for msec@ietf.org; Mon, 06 Nov 2006 19:55:34 -0500 Received: from lvs00-fl-n08.ftl.affinity.com ([216.219.253.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFFV-0005oB-4b for msec@ietf.org; Mon, 06 Nov 2006 19:55:34 -0500 Received: ("??"@ams008.ftl.affinity.com) by ams008.ftl.affinity.com id S384161AbWKGAzc for ; Mon, 6 Nov 2006 19:55:32 -0500 From: gmgietf@identaware.com To: msec@ietf.org Date: Mon, 06 Nov 2006 19:55:32 -0500 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_25238_1162860932"; charset="iso-8859-1" Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: h.cruickshank@surrey.ac.uk Subject: [MSEC] I-D ACTION:draft-ietf-msec-ipsec-composite-group-00.txt (fwd) 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 MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_25238_1162860932 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, Although the multicast IPsec composite groups draft did not make the v00 ID cutoff date before San Diego, it is now available as an MSEC working group experimental track draft. This newest edition adds a security considerations section and the appendix has additional usage cases drawn from the IPDVB area. Your review and comments are welcomed; we would like to move to WGLC with the group's comments folded into the v01 edition... tia, George and Haitham ----------Forwarded message ---------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: msec@securemulticast.org Subject: I-D ACTION:draft-ietf-msec-ipsec-composite-group-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : Multicast IP Security Composite Cryptographic Groups Author(s) : G. Gross, H. Cruickshank Filename : draft-ietf-msec-ipsec-composite-group-00.txt Pages : 19 Date : 2006-11-6 The Multicast IP Security extension architecture [Weis] implicitly assumes a basic group endpoint population that shares homogeneous cryptographic capabilities and security policies. In practice, large- scale cryptographic groups may contain a heterogeneous endpoint population that can not be accommodated by that basic multicast IPsec architecture. For example, some endpoints may not have been upgraded to handle the successor algorithm for one that is being retired (e.g. SHA1 transition to SHA-ng). Group deployments that span multiple legal jurisdictions may have a different security policy in each jurisdiction (e.g. key strength). This document defines the "composite cryptographic group" IP security architecture capability. A composite cryptographic group allows multicast IPsec applications to transparently interact with the single logical group that is formed by the union of one or more basic cryptographic groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-composite-group-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-ietf-msec-ipsec-composite-group-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-ietf-msec-ipsec-composite-group-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. --=_0_25238_1162860932 Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-msec-ipsec-composite-group-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --=_0_25238_1162860932 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=_0_25238_1162860932 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 --=_0_25238_1162860932-- From msec-bounces@ietf.org Mon Nov 06 19:56:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFFX-0003q3-Ro; Mon, 06 Nov 2006 19:55:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFFW-0003pO-GI for msec@ietf.org; Mon, 06 Nov 2006 19:55:34 -0500 Received: from lvs00-fl-n08.ftl.affinity.com ([216.219.253.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFFV-0005oB-4b for msec@ietf.org; Mon, 06 Nov 2006 19:55:34 -0500 Received: ("??"@ams008.ftl.affinity.com) by ams008.ftl.affinity.com id S384161AbWKGAzc for ; Mon, 6 Nov 2006 19:55:32 -0500 From: gmgietf@identaware.com To: msec@ietf.org Date: Mon, 06 Nov 2006 19:55:32 -0500 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_25238_1162860932"; charset="iso-8859-1" Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: h.cruickshank@surrey.ac.uk Subject: [MSEC] I-D ACTION:draft-ietf-msec-ipsec-composite-group-00.txt (fwd) 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 MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_25238_1162860932 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, Although the multicast IPsec composite groups draft did not make the v00 ID cutoff date before San Diego, it is now available as an MSEC working group experimental track draft. This newest edition adds a security considerations section and the appendix has additional usage cases drawn from the IPDVB area. Your review and comments are welcomed; we would like to move to WGLC with the group's comments folded into the v01 edition... tia, George and Haitham ----------Forwarded message ---------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: msec@securemulticast.org Subject: I-D ACTION:draft-ietf-msec-ipsec-composite-group-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : Multicast IP Security Composite Cryptographic Groups Author(s) : G. Gross, H. Cruickshank Filename : draft-ietf-msec-ipsec-composite-group-00.txt Pages : 19 Date : 2006-11-6 The Multicast IP Security extension architecture [Weis] implicitly assumes a basic group endpoint population that shares homogeneous cryptographic capabilities and security policies. In practice, large- scale cryptographic groups may contain a heterogeneous endpoint population that can not be accommodated by that basic multicast IPsec architecture. For example, some endpoints may not have been upgraded to handle the successor algorithm for one that is being retired (e.g. SHA1 transition to SHA-ng). Group deployments that span multiple legal jurisdictions may have a different security policy in each jurisdiction (e.g. key strength). This document defines the "composite cryptographic group" IP security architecture capability. A composite cryptographic group allows multicast IPsec applications to transparently interact with the single logical group that is formed by the union of one or more basic cryptographic groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-composite-group-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-ietf-msec-ipsec-composite-group-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-ietf-msec-ipsec-composite-group-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. --=_0_25238_1162860932 Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-msec-ipsec-composite-group-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --=_0_25238_1162860932 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=_0_25238_1162860932 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 --=_0_25238_1162860932-- From msec-bounces@ietf.org Fri Nov 10 07:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiVsQ-0004E9-Bj; Fri, 10 Nov 2006 07:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiVsP-0004E4-6B for msec@ietf.org; Fri, 10 Nov 2006 07:52:57 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGyh-00013e-NM for msec@ietf.org; Thu, 09 Nov 2006 15:58:27 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiGjh-00015m-2M for msec@ietf.org; Thu, 09 Nov 2006 15:42:58 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA9KgreV006813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 9 Nov 2006 12:42:53 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-18.qualcomm.com [10.50.72.18]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA9KgqKK029699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Nov 2006 12:42:52 -0800 (PST) Message-Id: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 09 Nov 2006 12:42:43 -0800 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [MSEC] MSEC meeting summary for group review 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, Below is the meeting summary I am presenting, please send any revisions. +++++++ MSEC discussed several current deliverables and oddly enough for a group that is on its last leg, several new proposals. It appears that some of the proposals are extensions to existing protocols/RFCs, which are generally ok; we need to get them documented/published for interoperability purposes. There are however some proposals with new goals, e.g., OSPFv3 security, specifically, key management extensions to support OSPFv3. That is out of scope of our charter. That brings us to cross-area work that I reported here at SAAG before: RMT and IPDVB security requirements are two examples. So, if the OSPF WG wants MSEC to do some work, we can discuss it. I will start a conversation with the OSPF WG chairs and go from there. Another work item that has come up is how to do CTR mode in the multi-sender case. Our charter says "Initial efforts will focus on scalable solutions for groups with a single source and a very large number of recipients" but does not explicitly rule out the multi-sender case. Perhaps we can take up that item, although I am apprehensive about doing that work piece-meal. Folks are encouraged to finalize proposals for new work before the Prague meeting and finalize all work before the Chicago meeting. +++++++++ Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Nov 10 07:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiVsQ-0004E9-Bj; Fri, 10 Nov 2006 07:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiVsP-0004E4-6B for msec@ietf.org; Fri, 10 Nov 2006 07:52:57 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGyh-00013e-NM for msec@ietf.org; Thu, 09 Nov 2006 15:58:27 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiGjh-00015m-2M for msec@ietf.org; Thu, 09 Nov 2006 15:42:58 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA9KgreV006813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 9 Nov 2006 12:42:53 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-18.qualcomm.com [10.50.72.18]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA9KgqKK029699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Nov 2006 12:42:52 -0800 (PST) Message-Id: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 09 Nov 2006 12:42:43 -0800 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [MSEC] MSEC meeting summary for group review 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, Below is the meeting summary I am presenting, please send any revisions. +++++++ MSEC discussed several current deliverables and oddly enough for a group that is on its last leg, several new proposals. It appears that some of the proposals are extensions to existing protocols/RFCs, which are generally ok; we need to get them documented/published for interoperability purposes. There are however some proposals with new goals, e.g., OSPFv3 security, specifically, key management extensions to support OSPFv3. That is out of scope of our charter. That brings us to cross-area work that I reported here at SAAG before: RMT and IPDVB security requirements are two examples. So, if the OSPF WG wants MSEC to do some work, we can discuss it. I will start a conversation with the OSPF WG chairs and go from there. Another work item that has come up is how to do CTR mode in the multi-sender case. Our charter says "Initial efforts will focus on scalable solutions for groups with a single source and a very large number of recipients" but does not explicitly rule out the multi-sender case. Perhaps we can take up that item, although I am apprehensive about doing that work piece-meal. Folks are encouraged to finalize proposals for new work before the Prague meeting and finalize all work before the Chicago meeting. +++++++++ Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Nov 10 10:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYJg-0006wK-55; Fri, 10 Nov 2006 10:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYJf-0006sT-CO for msec@ietf.org; Fri, 10 Nov 2006 10:29:15 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYJe-0003vs-1Z for msec@ietf.org; Fri, 10 Nov 2006 10:29:15 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 07:29:13 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="477072:sNHT70859394" 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/8.12.11) with ESMTP id kAAFTD7H017617; Fri, 10 Nov 2006 07:29:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAAFTDin018809; Fri, 10 Nov 2006 07:29:13 -0800 (PST) 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); Fri, 10 Nov 2006 07:29:12 -0800 Received: from [192.168.0.14] ([10.21.83.193]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 07:29:12 -0800 In-Reply-To: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.com> References: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.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] MSEC meeting summary for group review Date: Fri, 10 Nov 2006 07:29:08 -0800 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 15:29:12.0533 (UTC) FILETIME=[F94E6850:01C704DC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1776; t=1163172553; x=1164036553; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MSEC]=20MSEC=20meeting=20summary=20for=20group=20rev iew |Sender:=20; bh=5bmUKuSUwhamaVkDov/bumweI9KDotahUxE6OJcRabA=; b=D+y+LtUwFCiES+RCdofe4auFDVWZm3pniIJLhcb/jxIjw91LZDFzIXrkZcDQpk+S0FUiAyVr 7QfsxgzhQqs+qIA/xwzR4B2V0xkgVsdo531cohDtmSqQAuq6Ho4n155Q; Authentication-Results: sj-dkim-3; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Lakshminath, I'd like to know if people think we make GDOI-SRTP a WG item. thanks, Mark On Nov 9, 2006, at 12:42 PM, Lakshminath Dondeti wrote: > Folks, > > Below is the meeting summary I am presenting, please send any > revisions. > > +++++++ > MSEC discussed several current deliverables and oddly enough for a > group that is on its last leg, several new proposals. It appears > that some of the proposals are extensions to existing protocols/ > RFCs, which are generally ok; we need to get them documented/ > published for interoperability purposes. There are however some > proposals with new goals, e.g., OSPFv3 security, specifically, key > management extensions to support OSPFv3. That is out of scope of > our charter. > > That brings us to cross-area work that I reported here at SAAG > before: RMT and IPDVB security requirements are two examples. So, > if the OSPF WG wants MSEC to do some work, we can discuss it. I > will start a conversation with the OSPF WG chairs and go from there. > > Another work item that has come up is how to do CTR mode in the > multi-sender case. Our charter says "Initial efforts will focus on > scalable solutions for groups with a single source and a very large > number of recipients" but does not explicitly rule out the multi- > sender case. Perhaps we can take up that item, although I am > apprehensive about doing that work piece-meal. > > Folks are encouraged to finalize proposals for new work before the > Prague meeting and finalize all work before the Chicago meeting. > +++++++++ > > 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 Fri Nov 10 10:29:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYJg-0006wK-55; Fri, 10 Nov 2006 10:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiYJf-0006sT-CO for msec@ietf.org; Fri, 10 Nov 2006 10:29:15 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiYJe-0003vs-1Z for msec@ietf.org; Fri, 10 Nov 2006 10:29:15 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2006 07:29:13 -0800 X-IronPort-AV: i="4.09,410,1157353200"; d="scan'208"; a="477072:sNHT70859394" 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/8.12.11) with ESMTP id kAAFTD7H017617; Fri, 10 Nov 2006 07:29:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAAFTDin018809; Fri, 10 Nov 2006 07:29:13 -0800 (PST) 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); Fri, 10 Nov 2006 07:29:12 -0800 Received: from [192.168.0.14] ([10.21.83.193]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 07:29:12 -0800 In-Reply-To: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.com> References: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.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] MSEC meeting summary for group review Date: Fri, 10 Nov 2006 07:29:08 -0800 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 10 Nov 2006 15:29:12.0533 (UTC) FILETIME=[F94E6850:01C704DC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1776; t=1163172553; x=1164036553; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MSEC]=20MSEC=20meeting=20summary=20for=20group=20rev iew |Sender:=20; bh=5bmUKuSUwhamaVkDov/bumweI9KDotahUxE6OJcRabA=; b=D+y+LtUwFCiES+RCdofe4auFDVWZm3pniIJLhcb/jxIjw91LZDFzIXrkZcDQpk+S0FUiAyVr 7QfsxgzhQqs+qIA/xwzR4B2V0xkgVsdo531cohDtmSqQAuq6Ho4n155Q; Authentication-Results: sj-dkim-3; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Lakshminath, I'd like to know if people think we make GDOI-SRTP a WG item. thanks, Mark On Nov 9, 2006, at 12:42 PM, Lakshminath Dondeti wrote: > Folks, > > Below is the meeting summary I am presenting, please send any > revisions. > > +++++++ > MSEC discussed several current deliverables and oddly enough for a > group that is on its last leg, several new proposals. It appears > that some of the proposals are extensions to existing protocols/ > RFCs, which are generally ok; we need to get them documented/ > published for interoperability purposes. There are however some > proposals with new goals, e.g., OSPFv3 security, specifically, key > management extensions to support OSPFv3. That is out of scope of > our charter. > > That brings us to cross-area work that I reported here at SAAG > before: RMT and IPDVB security requirements are two examples. So, > if the OSPF WG wants MSEC to do some work, we can discuss it. I > will start a conversation with the OSPF WG chairs and go from there. > > Another work item that has come up is how to do CTR mode in the > multi-sender case. Our charter says "Initial efforts will focus on > scalable solutions for groups with a single source and a very large > number of recipients" but does not explicitly rule out the multi- > sender case. Perhaps we can take up that item, although I am > apprehensive about doing that work piece-meal. > > Folks are encouraged to finalize proposals for new work before the > Prague meeting and finalize all work before the Chicago meeting. > +++++++++ > > 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 Fri Nov 10 13:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibOi-0000rN-3n; Fri, 10 Nov 2006 13:46:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibJE-0006bk-4E for msec@ietf.org; Fri, 10 Nov 2006 13:41:00 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gib6E-000491-1b for msec@ietf.org; Fri, 10 Nov 2006 13:27:35 -0500 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 <0J8J000XW25437@szxga01-in.huawei.com> for msec@ietf.org; Sat, 11 Nov 2006 02:31:53 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8J00751254XN@szxga01-in.huawei.com> for msec@ietf.org; Sat, 11 Nov 2006 02:31:52 +0800 (CST) Received: from jys3104091040d (dhcp66-12.ietf67.org [130.129.66.12]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8J00C8E307YH@szxml01-in.huawei.com>; Sat, 11 Nov 2006 02:50:42 +0800 (CST) Date: Sat, 11 Nov 2006 10:23:08 +0800 From: Liu Ya Subject: RE: [MSEC] MSEC meeting summary for group review In-reply-to: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.com> To: 'Lakshminath Dondeti' , msec@ietf.org Message-id: <01d501c70538$57e680e0$4e478182@jys3104091040d> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccEyBZz0a/4MoMHTkys8cETpb6BVAAY8z+g X-Spam-Score: 1.2 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 all, Existing MSEC protocols are not fully competent for group keying of some important scenarios such as OSPFv3, PIM-SM, etc. Extensions need to be made. In OSPFv3 scenario, for example, IP multicast is not always deployed. So, reliable rekeying can not always be achieved by RMT mechanisms. Routes may be shortly disconnected because of OSPFv3 routers' rebooting or other troubles. So it can not be assumed that an OSPFv3 can always receive the rekeying messages pushed by GCKS when some MSEC protocols is used in this scenario. There may be other new requirements to be proposed. I strongly propose the work of extending MSEC protocols as a working group item. Regards, Liu Ya On November 10, 2006 4:43 AM, Lakshminath wrote: > > Folks, > > Below is the meeting summary I am presenting, please send any > revisions. > > +++++++ > MSEC discussed several current deliverables and oddly enough > for a group that is on its last leg, several new proposals. > It appears that some of the proposals are extensions to > existing protocols/RFCs, which are generally ok; we need to > get them documented/published for interoperability purposes. > There are however some proposals with new goals, e.g., OSPFv3 > security, specifically, key management extensions to support > OSPFv3. That is out of scope of our charter. > > That brings us to cross-area work that I reported here at SAAG > before: RMT and IPDVB security requirements are two examples. > So, if the OSPF WG wants MSEC to do some work, we can > discuss it. I will start a conversation with the OSPF WG > chairs and go from there. > > Another work item that has come up is how to do CTR mode in > the multi-sender case. Our charter says "Initial efforts > will focus on scalable solutions for groups with a single > source and a very large number of recipients" but does not > explicitly rule out the multi-sender case. Perhaps we can > take up that item, although I am apprehensive about doing > that work piece-meal. > > Folks are encouraged to finalize proposals for new work > before the Prague meeting and finalize all work before the > Chicago meeting. > +++++++++ > > 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 Fri Nov 10 13:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibOi-0000rN-3n; Fri, 10 Nov 2006 13:46:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GibJE-0006bk-4E for msec@ietf.org; Fri, 10 Nov 2006 13:41:00 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gib6E-000491-1b for msec@ietf.org; Fri, 10 Nov 2006 13:27:35 -0500 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 <0J8J000XW25437@szxga01-in.huawei.com> for msec@ietf.org; Sat, 11 Nov 2006 02:31:53 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8J00751254XN@szxga01-in.huawei.com> for msec@ietf.org; Sat, 11 Nov 2006 02:31:52 +0800 (CST) Received: from jys3104091040d (dhcp66-12.ietf67.org [130.129.66.12]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8J00C8E307YH@szxml01-in.huawei.com>; Sat, 11 Nov 2006 02:50:42 +0800 (CST) Date: Sat, 11 Nov 2006 10:23:08 +0800 From: Liu Ya Subject: RE: [MSEC] MSEC meeting summary for group review In-reply-to: <7.0.1.0.2.20061109102811.0433b6f0@qualcomm.com> To: 'Lakshminath Dondeti' , msec@ietf.org Message-id: <01d501c70538$57e680e0$4e478182@jys3104091040d> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccEyBZz0a/4MoMHTkys8cETpb6BVAAY8z+g X-Spam-Score: 1.2 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 all, Existing MSEC protocols are not fully competent for group keying of some important scenarios such as OSPFv3, PIM-SM, etc. Extensions need to be made. In OSPFv3 scenario, for example, IP multicast is not always deployed. So, reliable rekeying can not always be achieved by RMT mechanisms. Routes may be shortly disconnected because of OSPFv3 routers' rebooting or other troubles. So it can not be assumed that an OSPFv3 can always receive the rekeying messages pushed by GCKS when some MSEC protocols is used in this scenario. There may be other new requirements to be proposed. I strongly propose the work of extending MSEC protocols as a working group item. Regards, Liu Ya On November 10, 2006 4:43 AM, Lakshminath wrote: > > Folks, > > Below is the meeting summary I am presenting, please send any > revisions. > > +++++++ > MSEC discussed several current deliverables and oddly enough > for a group that is on its last leg, several new proposals. > It appears that some of the proposals are extensions to > existing protocols/RFCs, which are generally ok; we need to > get them documented/published for interoperability purposes. > There are however some proposals with new goals, e.g., OSPFv3 > security, specifically, key management extensions to support > OSPFv3. That is out of scope of our charter. > > That brings us to cross-area work that I reported here at SAAG > before: RMT and IPDVB security requirements are two examples. > So, if the OSPF WG wants MSEC to do some work, we can > discuss it. I will start a conversation with the OSPF WG > chairs and go from there. > > Another work item that has come up is how to do CTR mode in > the multi-sender case. Our charter says "Initial efforts > will focus on scalable solutions for groups with a single > source and a very large number of recipients" but does not > explicitly rule out the multi-sender case. Perhaps we can > take up that item, although I am apprehensive about doing > that work piece-meal. > > Folks are encouraged to finalize proposals for new work > before the Prague meeting and finalize all work before the > Chicago meeting. > +++++++++ > > 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 Sun Nov 12 18:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOXD-0004sH-At; Sun, 12 Nov 2006 18:14:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOXC-0004sB-PP for msec@ietf.org; Sun, 12 Nov 2006 18:14:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjOXB-0002qo-Fd for msec@ietf.org; Sun, 12 Nov 2006 18:14:42 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kACNEbmN009633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Nov 2006 15:14:38 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-143.qualcomm.com [10.50.77.143]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kACNEaJW001706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 12 Nov 2006 15:14:37 -0800 (PST) Message-Id: <7.0.1.0.2.20061112151251.06d884e0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 12 Nov 2006 15:14:35 -0800 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: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] minutes 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 A few of you took minutes at the meeting, Mark, Steffen, Sheela, perhaps others too. I have received minutes from Sheela. Mark, Steffen, please send your copies of the minutes. Other minutes are appreciated as well. I was not on jabber. Was anyone active there? thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Nov 12 18:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOXD-0004sH-At; Sun, 12 Nov 2006 18:14:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjOXC-0004sB-PP for msec@ietf.org; Sun, 12 Nov 2006 18:14:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjOXB-0002qo-Fd for msec@ietf.org; Sun, 12 Nov 2006 18:14:42 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kACNEbmN009633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 12 Nov 2006 15:14:38 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-143.qualcomm.com [10.50.77.143]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kACNEaJW001706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 12 Nov 2006 15:14:37 -0800 (PST) Message-Id: <7.0.1.0.2.20061112151251.06d884e0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 12 Nov 2006 15:14:35 -0800 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: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] minutes 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 A few of you took minutes at the meeting, Mark, Steffen, Sheela, perhaps others too. I have received minutes from Sheela. Mark, Steffen, please send your copies of the minutes. Other minutes are appreciated as well. I was not on jabber. Was anyone active there? thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 13 23:40:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjq6M-0000yA-2o for msec-archive@lists.ietf.org; Mon, 13 Nov 2006 23:40:50 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjq6K-0005EG-Gx for msec-archive@lists.ietf.org; Mon, 13 Nov 2006 23:40:50 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2F84E2CA3F; Mon, 13 Nov 2006 23:40:42 -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 EBC592C920 for ; Mon, 13 Nov 2006 23:40:40 -0500 (EST) Received: (qmail 93820 invoked by uid 3269); 14 Nov 2006 04:40:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93817 invoked from network); 14 Nov 2006 04:40:40 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 14 Nov 2006 04:40:40 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 0D6F7E9D2C for ; Mon, 13 Nov 2006 23:40:41 -0500 (EST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mailwash15.pair.com (Postfix) with ESMTP id C2087E9D18 for ; Mon, 13 Nov 2006 23:40:39 -0500 (EST) 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 <0J8P00CQFE6FRD@szxga01-in.huawei.com> for msec@securemulticast.org; Tue, 14 Nov 2006 12:37:27 +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 <0J8P007KWE6DWU@szxga01-in.huawei.com> for msec@securemulticast.org; Tue, 14 Nov 2006 12:37:27 +0800 (CST) Received: from c61017 ([10.111.12.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8P008AVE69EK@szxml04-in.huawei.com> for msec@securemulticast.org; Tue, 14 Nov 2006 12:37:25 +0800 (CST) Date: Tue, 14 Nov 2006 12:37:21 +0800 From: chenxu To: msec@securemulticast.org Message-id: <000001c707a6$930b5ef0$600c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AccHppKgYGVLUgDeSa6Chhy3kI2eMw== Cc: mbaugher@cisco.com, thardjono@verisign.com Subject: [MSEC] Is ID payload missing in GROUPKEY-PUSH? 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="===============0342333349==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.7 (/) X-Scan-Signature: b644dab0a042898f2b3d8e7a5f3ac1e5 This is a multi-part message in MIME format. --===============0342333349== Content-type: multipart/alternative; boundary="Boundary_(ID_6ekvlCQtpUdnDG9lERJ74Q)" This is a multi-part message in MIME format. --Boundary_(ID_6ekvlCQtpUdnDG9lERJ74Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, everybody, Recently, I did some research on GDOI and one thing has confused me a bit. I noticed there is an ID payload in GROUPKEY-PULL, which is used to identify the group the member-initiator wishes to join. (RFC3547, Page 8). This payload is further described in Page 17. "The Identification Payload is used to identify a group identity ... ". However, I also noticed that there is no ID payload in GROUPKEY-PUSH message. When a member receives a GROUPKEY-PUSH message, he/she has no idea which group this message belongs to. Does this mean he/she must try to deal with all GROUPKEY-PUSH messages? Why not just include an ID payload in GROUPKEY-PUSH message after HDR and the SIG payload is a signature of a hash of the entire message including ID payload. E.g. <---- HDR*, ID, SEQ, SA, KD, [CERT,] SIG Best Regards, Xu Chen --Boundary_(ID_6ekvlCQtpUdnDG9lERJ74Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, everybody,

Recently, I did some research on GDOI and one thing has confused me a bit. I noticed there is an ID payload in GROUPKEY-PULL, which is used to identify the group the member-initiator wishes to join. (RFC3547, Page 8). This payload is further described in Page 17. “The Identification Payload is used to identify a group identity ……. ”.

 

However, I also noticed that there is no ID payload in GROUPKEY-PUSH message. When a member receives a GROUPKEY-PUSH message, he/she has no idea which group this message belongs to. Does this mean he/she must try to deal with all GROUPKEY-PUSH messages?

 

Why not just include an ID payload in GROUPKEY-PUSH message after HDR and the SIG payload is a signature of a hash of the entire message including ID payload.

E.g.  <---- HDR*, ID, SEQ, SA, KD, [CERT,] SIG

 

Best Regards,

Xu Chen

--Boundary_(ID_6ekvlCQtpUdnDG9lERJ74Q)-- --===============0342333349== 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 --===============0342333349==-- From msec-bounces@securemulticast.org Tue Nov 14 15:01:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4Tf-0006qX-JM for msec-archive@lists.ietf.org; Tue, 14 Nov 2006 15:01:51 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4Td-0002m5-Qf for msec-archive@lists.ietf.org; Tue, 14 Nov 2006 15:01:51 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 644A02B9CB; Tue, 14 Nov 2006 15:01:43 -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 A86B02CC56 for ; Tue, 14 Nov 2006 15:01:41 -0500 (EST) Received: (qmail 56915 invoked by uid 3269); 14 Nov 2006 20:01:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56912 invoked from network); 14 Nov 2006 20:01:41 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 14 Nov 2006 20:01:41 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 90800E9D8A for ; Tue, 14 Nov 2006 15:01:41 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mailwash15.pair.com (Postfix) with ESMTP id 8B14CE9D83 for ; Tue, 14 Nov 2006 15:01:37 -0500 (EST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2006 12:01:27 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAEK1P6w004707; Tue, 14 Nov 2006 12:01:25 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAEK1Pio003595; Tue, 14 Nov 2006 12:01:25 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 12:01:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Date: Tue, 14 Nov 2006 12:01:23 -0800 Message-ID: <6B9C4B97B82F924485E26968EB05A6EE025F5B99@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Thread-Index: AccHppKgYGVLUgDeSa6Chhy3kI2eMwAgNGww From: "Sheela Rowles \(srowles\)" To: "chenxu" , X-OriginalArrivalTime: 14 Nov 2006 20:01:25.0733 (UTC) FILETIME=[AA4DF150:01C70827] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17525; t=1163534486; x=1164398486; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=srowles@cisco.com; z=From:=20=22Sheela=20Rowles=20\(srowles\)=22=20 |Subject:=20RE=3A=20[MSEC]=20Is=20ID=20payload=20missing=20in=20GROUPKEY- PUSH? |Sender:=20; bh=6rWVrP3hJLTLCvqcAcDRHY/tz7hpS4CBfaVUJbuTlII=; b=ssSJAlZawjpvj+qFhSn4eTDbTUf6oMlHnhQZ7SZO1gBZD28JbBBEy/VEBBju9EBE7y3GilMp YOxcf+CAHxVUvbAZoHvoRU3buosIRTuoZJ7DTndTWkZHcvtbx6TGkMxh; Authentication-Results: sj-dkim-2; header.From=srowles@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Mark Baugher \(mbaugher\)" , thardjono@verisign.com 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="===============1074569707==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b This is a multi-part message in MIME format. --===============1074569707== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70827.A9EE5051" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70827.A9EE5051 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Xu Chen, You don't need the ID in the rekey messages since you can use the SPI to identify the information. During Registration, a KEK payload is sent to the Group Members with the SPI information. Then later during the rekey, the same SPI information is in the header, so the group member can identify the KEK information. Also, note from RFC 3547: Unlike ISAKMP or IKE, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Re- key SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI. Sheela ________________________________ From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of chenxu Sent: Monday, November 13, 2006 8:37 PM To: msec@securemulticast.org Cc: Mark Baugher (mbaugher); thardjono@verisign.com Subject: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Hi, everybody,=20 Recently, I did some research on GDOI and one thing has confused me a bit. I noticed there is an ID payload in GROUPKEY-PULL, which is used to identify the group the member-initiator wishes to join. (RFC3547, Page 8). This payload is further described in Page 17. "The Identification Payload is used to identify a group identity ....... ".=20 =20 However, I also noticed that there is no ID payload in GROUPKEY-PUSH message. When a member receives a GROUPKEY-PUSH message, he/she has no idea which group this message belongs to. Does this mean he/she must try to deal with all GROUPKEY-PUSH messages?=20 =20 Why not just include an ID payload in GROUPKEY-PUSH message after HDR and the SIG payload is a signature of a hash of the entire message including ID payload.=20 E.g. <---- HDR*, ID, SEQ, SA, KD, [CERT,] SIG =20 Best Regards, Xu Chen ------_=_NextPart_001_01C70827.A9EE5051 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Xu = Chen,

You don't need the ID in the rekey messages since you = can use=20 the  SPI to identify the = information.=20 During Registration, a KEK payload is sent to the Group Members with the = SPI=20 information.  Then later = during the=20 rekey, the same SPI information is in the header, = so the=20 group member can identify the KEK information.

Also, note from RFC=20 3547:

   = Unlike=20 ISAKMP or IKE, the cookie pair is completely determined by = the
  =20 GCKS.  The cookie pair in the GDOI ISAKMP header identifies the=20 Re-
   key SA to differentiate the secure groups managed by = a=20 GCKS.  Thus,
   GDOI uses the cookie fields as an=20 SPI.

Sheela


From: = msec-bounces@securemulticast.org=20 [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 chenxu
Sent: Monday, November 13, 2006 8:37 = PM
To:=20 msec@securemulticast.org
Cc: Mark Baugher (mbaugher);=20 thardjono@verisign.com
Subject: [MSEC] Is ID payload missing = in=20 GROUPKEY-PUSH?

Hi, = everybody,=20

Recently, I did=20 some research on GDOI and one thing has confused me a bit. I noticed = there is an=20 ID payload in GROUPKEY-PULL, which is used to identify the group the=20 member-initiator wishes to join. (RFC3547, Page 8). This payload is = further=20 described in Page 17. “The Identification Payload is used to = identify a group=20 identity ……. ”.

 

However, = I also=20 noticed that there is no ID payload in GROUPKEY-PUSH message. When a = member=20 receives a GROUPKEY-PUSH message, he/she has no idea which group this = message=20 belongs to. Does this mean he/she must try to deal with all = GROUPKEY-PUSH=20 messages?

 

Why not = just=20 include an ID payload in GROUPKEY-PUSH message after HDR and the SIG = payload is=20 a signature of a hash of the entire message including ID payload.=20

E.g.=20  <---- HDR*, ID, SEQ, SA, KD, [CERT,] = SIG

 

Best=20 Regards,

Xu=20 Chen

------_=_NextPart_001_01C70827.A9EE5051-- --===============1074569707== 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 --===============1074569707==-- From msec-bounces@securemulticast.org Fri Nov 24 21:23:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnnCx-0001AB-AQ for msec-archive@lists.ietf.org; Fri, 24 Nov 2006 21:23:59 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnnCv-0007PI-W5 for msec-archive@lists.ietf.org; Fri, 24 Nov 2006 21:23:59 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 5C4142C4BE; Fri, 24 Nov 2006 21:23:47 -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 B2F132BF7C for ; Fri, 24 Nov 2006 21:23:45 -0500 (EST) Received: (qmail 17189 invoked by uid 3269); 25 Nov 2006 02:23:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17186 invoked from network); 25 Nov 2006 02:23:40 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 25 Nov 2006 02:23:39 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id F3AD0E9D2D for ; Fri, 24 Nov 2006 21:23:39 -0500 (EST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mailwash15.pair.com (Postfix) with ESMTP id 78DE4E9D82 for ; Fri, 24 Nov 2006 21:23:32 -0500 (EST) 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 <0J9900KCCLAX9E@szxga01-in.huawei.com> for msec@securemulticast.org; Sat, 25 Nov 2006 10:23:21 +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 <0J99002FYLAWTB@szxga01-in.huawei.com> for msec@securemulticast.org; Sat, 25 Nov 2006 10:23:21 +0800 (CST) Received: from c61017 ([10.111.12.53]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J99005SJLATZE@szxml04-in.huawei.com> for msec@securemulticast.org; Sat, 25 Nov 2006 10:23:20 +0800 (CST) Date: Sat, 25 Nov 2006 10:23:17 +0800 From: Xu Chen In-reply-to: <6B9C4B97B82F924485E26968EB05A6EE025F5B99@xmb-sjc-224.amer.cisco.com> To: "'Sheela Rowles (srowles)'" Message-id: <000c01c71038$ab0a4b20$350c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AccHppKgYGVLUgDeSa6Chhy3kI2eMwAgNGwwAeD9eLA= Cc: mbaugher@cisco.com, msec@securemulticast.org Subject: Re: [MSEC] Is ID payload missing in GROUPKEY-PUSH? X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.5 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 hi Sheela, Many thanks for answering my question. Another question just confused me. According to RFC3547 section 3.3, "If the policy in the SA payload is acceptable...., the initiator continues the protocol." However, what will happen, if the SA payload is not acceptable(such as an unsupported SIG_ALGORITHM)? IKE has a SA negotiation in Quick Mode and the responder may choose prefered SA proposal. Also, it is more reasonable for a group member to follow group SA policy than to negotiate it. However, if the second message of GROUPKEY-PULL(with group SA payload) is lost , GDOI GCKS may not be able to distinguish this situation with unacceptable group SA policy . Best Regards, Xu Chen ________________________________ From: Sheela Rowles (srowles) [mailto:srowles@cisco.com] Sent: Wednesday, November 15, 2006 4:01 AM To: chenxu; msec@securemulticast.org Cc: Mark Baugher (mbaugher); thardjono@verisign.com Subject: RE: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Xu Chen, You don't need the ID in the rekey messages since you can use the SPI to identify the information. During Registration, a KEK payload is sent to the Group Members with the SPI information. Then later during the rekey, the same SPI information is in the header, so the group member can identify the KEK information. Also, note from RFC 3547: Unlike ISAKMP or IKE, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Re- key SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI. Sheela ________________________________ From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of chenxu Sent: Monday, November 13, 2006 8:37 PM To: msec@securemulticast.org Cc: Mark Baugher (mbaugher); thardjono@verisign.com Subject: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Hi, everybody, Recently, I did some research on GDOI and one thing has confused me a bit. I noticed there is an ID payload in GROUPKEY-PULL, which is used to identify the group the member-initiator wishes to join. (RFC3547, Page 8). This payload is further described in Page 17. "The Identification Payload is used to identify a group identity ... ". However, I also noticed that there is no ID payload in GROUPKEY-PUSH message. When a member receives a GROUPKEY-PUSH message, he/she has no idea which group this message belongs to. Does this mean he/she must try to deal with all GROUPKEY-PUSH messages? Why not just include an ID payload in GROUPKEY-PUSH message after HDR and the SIG payload is a signature of a hash of the entire message including ID payload. E.g. <---- HDR*, ID, SEQ, SA, KD, [CERT,] SIG Best Regards, Xu Chen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 27 13:27:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolCJ-0001p9-72 for msec-archive@lists.ietf.org; Mon, 27 Nov 2006 13:27:19 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GolCH-0005vx-O6 for msec-archive@lists.ietf.org; Mon, 27 Nov 2006 13:27:19 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0B2302CF09; Mon, 27 Nov 2006 13:27:09 -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 271322CF0A for ; Mon, 27 Nov 2006 13:26:20 -0500 (EST) Received: (qmail 91452 invoked by uid 3269); 27 Nov 2006 18:26:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91445 invoked from network); 27 Nov 2006 18:26:19 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 27 Nov 2006 18:26:19 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id B6C7CE9DA7 for ; Mon, 27 Nov 2006 13:26:19 -0500 (EST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mailwash15.pair.com (Postfix) with ESMTP id 51777E9D9E for ; Mon, 27 Nov 2006 13:26:19 -0500 (EST) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2006 10:26:18 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kARIQIq1026881; Mon, 27 Nov 2006 10:26:18 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kARIQ4dW004812; Mon, 27 Nov 2006 10:26:13 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 10:25:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Nov 2006 10:25:58 -0800 Message-ID: <6B9C4B97B82F924485E26968EB05A6EE026DA4B0@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Thread-Index: AccHppKgYGVLUgDeSa6Chhy3kI2eMwAgNGwwAeD9eLAAqTr4MA== From: "Sheela Rowles \(srowles\)" To: "Xu Chen" X-OriginalArrivalTime: 27 Nov 2006 18:25:59.0521 (UTC) FILETIME=[7C961510:01C71251] Authentication-Results: sj-dkim-6; header.From=srowles@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Cc: "Mark Baugher \(mbaugher\)" , msec@securemulticast.org Subject: Re: [MSEC] Is ID payload missing in GROUPKEY-PUSH? X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 My interpretation of that statement, "If the policy in the SA payload is acceptable..., the initiator continues the protocol." is that if the policy is not acceptable the initiator will not continue the protocol. I'm not sure I understand your comparison to QM since as you mention SA negotiation is with QM not with GDOI. If the GCKS does not receive the 3rd message from the initiator, it should not send the KD payload regardless of the circumstances. Sheela -----Original Message----- From: Xu Chen [mailto:chenxu0128@huawei.com] Sent: Friday, November 24, 2006 6:23 PM To: Sheela Rowles (srowles) Cc: Mark Baugher (mbaugher); msec@securemulticast.org Subject: RE: [MSEC] Is ID payload missing in GROUPKEY-PUSH? hi Sheela, Many thanks for answering my question. Another question just confused me. According to RFC3547 section 3.3, "If the policy in the SA payload is acceptable...., the initiator continues the protocol." However, what will happen, if the SA payload is not acceptable(such as an unsupported SIG_ALGORITHM)? IKE has a SA negotiation in Quick Mode and the responder may choose prefered SA proposal. Also, it is more reasonable for a group member to follow group SA policy than to negotiate it. However, if the second message of GROUPKEY-PULL(with group SA payload) is lost , GDOI GCKS may not be able to distinguish this situation with unacceptable group SA policy . Best Regards, Xu Chen ________________________________ From: Sheela Rowles (srowles) [mailto:srowles@cisco.com] Sent: Wednesday, November 15, 2006 4:01 AM To: chenxu; msec@securemulticast.org Cc: Mark Baugher (mbaugher); thardjono@verisign.com Subject: RE: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Xu Chen, You don't need the ID in the rekey messages since you can use the SPI to identify the information. During Registration, a KEK payload is sent to the Group Members with the SPI information. Then later during the rekey, the same SPI information is in the header, so the group member can identify the KEK information. Also, note from RFC 3547: Unlike ISAKMP or IKE, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Re- key SA to differentiate the secure groups managed by a GCKS. Thus, GDOI uses the cookie fields as an SPI. Sheela ________________________________ From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of chenxu Sent: Monday, November 13, 2006 8:37 PM To: msec@securemulticast.org Cc: Mark Baugher (mbaugher); thardjono@verisign.com Subject: [MSEC] Is ID payload missing in GROUPKEY-PUSH? Hi, everybody, Recently, I did some research on GDOI and one thing has confused me a bit. I noticed there is an ID payload in GROUPKEY-PULL, which is used to identify the group the member-initiator wishes to join. (RFC3547, Page 8). This payload is further described in Page 17. "The Identification Payload is used to identify a group identity ... ". However, I also noticed that there is no ID payload in GROUPKEY-PUSH message. When a member receives a GROUPKEY-PUSH message, he/she has no idea which group this message belongs to. Does this mean he/she must try to deal with all GROUPKEY-PUSH messages? Why not just include an ID payload in GROUPKEY-PUSH message after HDR and the SIG payload is a signature of a hash of the entire message including ID payload. E.g. <---- HDR*, ID, SEQ, SA, KD, [CERT,] SIG Best Regards, Xu Chen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec