From ipsec-bounces@ietf.org Tue Aug 02 04:35:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsFc-0007ay-PL; Tue, 02 Aug 2005 04:35:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsFa-0007Zo-V6 for ipsec@megatron.ietf.org; Tue, 02 Aug 2005 04:35:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29768 for ; Tue, 2 Aug 2005 04:35:48 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzsm1-0002SF-El for ipsec@ietf.org; Tue, 02 Aug 2005 05:09:22 -0400 Received: from [86.255.6.94] (wired-6-94.ietf63.ietf.org [86.255.6.94]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j728Zd7D036270 for ; Tue, 2 Aug 2005 01:35:40 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 2 Aug 2005 10:32:00 +0200 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ipsec] Last Call: 'The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hoffman-rfc3664bis-03.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 02 08:32:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvwF-0007QD-DM; Tue, 02 Aug 2005 08:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvwC-0007OZ-Vj for ipsec@megatron.ietf.org; Tue, 02 Aug 2005 08:32:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15499 for ; Tue, 2 Aug 2005 08:32:03 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzwSf-0005WG-L2 for ipsec@ietf.org; Tue, 02 Aug 2005 09:05:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j72CPmSX019039; Tue, 2 Aug 2005 15:25:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 15:31:51 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 15:31:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] REKEY_SA Notify clarification wanted Date: Tue, 2 Aug 2005 15:31:50 +0300 Message-ID: Thread-Topic: [Ipsec] REKEY_SA Notify clarification wanted Thread-Index: AcWV6fxZln7QrUxOSZ+F33fIe6AT3ABYKTAA To: , X-OriginalArrivalTime: 02 Aug 2005 12:31:50.0983 (UTC) FILETIME=[285CFD70:01C5975E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Fukumoto Atsushi writes: > > draft-ietf-ipsec-ikev2-17.txt says: > > in section 1.3: > > If this CREATE_CHILD_SA exchange is rekeying an existing=20 > > SA other than the IKE_SA, the leading N payload of type=20 > > REKEY_SA MUST identify the SA being rekeyed. If this=20 > > CREATE_CHILD_SA exchange is not rekeying an existing SA,=20 > > the N payload MUST be omitted. > >=20 > > and in section 3.10.1: > > REKEY_SA 16393 > >=20 > > This notification MUST be included in a CREATE_CHILD_SA > > exchange if the purpose of the exchange is to replace > > an existing ESP or AH SA. The SPI field identifies=20 > > the SA being rekeyed. There is no data. > >=20 > > These are the only mentions of REKEY_SA, and I found it hard to > > figure out what to do when rekeying IKE SA. The above > > descriptions strongly suggests (to me) that the REKEY_SA is not > > used in IKE SA rekeying. >=20 > When you are rekeying IKE SA you do not include N(REKEY_SA) at > all. It is only included when you are rekeying ESP or AH SA (as the > section 3.10.1 and 1.3 say). I think the text could be interpreted both ways. Since it says "REKEY_SA is not included when you're not rekeying an existing SA", that could imply that it is included when you are rekeying. But it's not really needed, since the fact you're rekeying the=20 IKE_SA is anyway obvious from the SA payload. Is there any information how existing implementations have interpreted this? (e.g. from the Santa Clara bakeoff?) (The one implementation I know of did not send REKEY_SA in this case.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 02 09:52:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxCL-0004dZ-6Z; Tue, 02 Aug 2005 09:52:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxCJ-0004bo-4b for ipsec@megatron.ietf.org; Tue, 02 Aug 2005 09:52:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19942 for ; Tue, 2 Aug 2005 09:52:45 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzxim-0000Zz-Mk for ipsec@ietf.org; Tue, 02 Aug 2005 10:26:22 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j72Dqevp022588 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 2 Aug 2005 16:52:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j72DqekS022585; Tue, 2 Aug 2005 16:52:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17135.31400.76405.863677@fireball.kivinen.iki.fi> Date: Tue, 2 Aug 2005 16:52:40 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] REKEY_SA Notify clarification wanted In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > > > If this CREATE_CHILD_SA exchange is rekeying an existing > > > SA other than the IKE_SA, the leading N payload of type > I think the text could be interpreted both ways. Since it says If it says "rekeying an existing SA other than the IKE_SA", I do not know how it can be interpreted to include also rekeying IKE_SA? > "REKEY_SA is not included when you're not rekeying an existing SA", > that could imply that it is included when you are rekeying. But the text who said to add it had "other than the IKE_SA". > But it's not really needed, since the fact you're rekeying the > IKE_SA is anyway obvious from the SA payload. > > Is there any information how existing implementations have > interpreted this? (e.g. from the Santa Clara bakeoff?) I do not remember anybody using REKEY_SA on IKE_SA rekeys in the bakeoff, but I might be wrong... > (The one implementation I know of did not send REKEY_SA in this case.) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 03 00:11:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0AbA-0003vx-9K; Wed, 03 Aug 2005 00:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ab7-0003vs-LV for ipsec@megatron.ietf.org; Wed, 03 Aug 2005 00:11:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05863 for ; Wed, 3 Aug 2005 00:11:14 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0B7c-000168-JN for ipsec@ietf.org; Wed, 03 Aug 2005 00:45:00 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j734B3rr002521 for ; Wed, 3 Aug 2005 13:11:03 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j734B3HW009621 for ; Wed, 3 Aug 2005 13:11:03 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id PAA09615 ; Wed, 3 Aug 2005 13:11:03 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j734B2sf011708 for ; Wed, 3 Aug 2005 13:11:03 +0900 (JST) Received: by toshiba.co.jp id j734B22Y003295; Wed, 3 Aug 2005 13:11:02 +0900 (JST) To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] REKEY_SA Notify clarification wanted In-reply-to: Pasi.Eronen's message of "Tue, 02 Aug 2005 15:31:50 +0300." Date: Wed, 03 Aug 2005 13:11:01 +0900 From: Fukumoto Atsushi Message-Id: <200508030411.j734B22Y003295@toshiba.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > Is there any information how existing implementations have > interpreted this? (e.g. from the Santa Clara bakeoff?) I had no problem of interpreting the IKEv2 draft that way. The only reason I was confused is due to the clarification draft appendix A.5 which has N(REKEY) for rekeying IKE_SA, since I considered the clarification draft is supposed to be clarifying the protocol. This appendix was included from draft-03, dated June 1 2005, so the implementation prior to that should have had no influence from this. FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 05 18:36:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Ang-0007eh-Hr; Fri, 05 Aug 2005 18:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Anf-0007ec-B1 for ipsec@megatron.ietf.org; Fri, 05 Aug 2005 18:36:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08250 for ; Fri, 5 Aug 2005 18:36:19 -0400 (EDT) Received: from smtp109.sbc.mail.mud.yahoo.com ([68.142.198.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E1BKm-0005Md-TY for ipsec@ietf.org; Fri, 05 Aug 2005 19:10:40 -0400 Received: (qmail 8484 invoked from network); 5 Aug 2005 22:36:06 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.169.162.158 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 5 Aug 2005 22:36:05 -0000 Message-ID: <004801c59a0e$120cb710$6501a8c0@adithya> From: "Mohan Parthasarathy" To: Date: Fri, 5 Aug 2005 15:36:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 4.6 (++++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Ipsec] REKEY_SA with new SA offer.. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I could not find it anywhere in the IKEv2 draft whether this is disallowed or not. When either side wants to send a REKEY message, can it offer a different set of proposals/transforms from what it offered in the SA payload previously (could be first time or last rekey time) ? Similarly, can the responder choose a different one from what it offered before ? For example, when i set up the ESP SA for the first time i offered AES with SHA-1 and when i rekey i offer ENCR_NULL and SHA-1 ? I don't see why this would be an issue. -mohan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 06 12:04:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1RAH-0007U8-0K; Sat, 06 Aug 2005 12:04:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1RAE-0007Tv-TL for ipsec@megatron.ietf.org; Sat, 06 Aug 2005 12:04:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29070 for ; Sat, 6 Aug 2005 12:04:44 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1RhW-00020d-3y for ipsec@ietf.org; Sat, 06 Aug 2005 12:39:13 -0400 Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j76G4g1d025856; Sat, 6 Aug 2005 09:04:42 -0700 (PDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j76G4ef8024324; Sat, 6 Aug 2005 09:04:40 -0700 (PDT) Subject: Re: [Ipsec] REKEY_SA with new SA offer.. From: Bill Sommerfeld To: Mohan Parthasarathy In-Reply-To: <004801c59a0e$120cb710$6501a8c0@adithya> References: <004801c59a0e$120cb710$6501a8c0@adithya> Content-Type: text/plain Message-Id: <1123344277.5951.19.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Sat, 06 Aug 2005 18:04:39 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sat, 2005-08-06 at 00:36, Mohan Parthasarathy wrote: > For example, > when i set up the ESP SA for the first time i offered AES with SHA-1 and when i rekey i offer > ENCR_NULL and SHA-1 ? I don't see why this would be an issue. changing a real algorithm to ENCR_NULL on a rekey really ought to be an error. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 06 14:41:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1TbS-0005Pb-FC; Sat, 06 Aug 2005 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1TbQ-0005PW-Jx for ipsec@megatron.ietf.org; Sat, 06 Aug 2005 14:41:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05174 for ; Sat, 6 Aug 2005 14:40:59 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1U8l-0005Sk-9I for ipsec@ietf.org; Sat, 06 Aug 2005 15:15:28 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Aug 2005 11:40:50 -0700 X-IronPort-AV: i="3.95,172,1120460400"; d="scan'208"; a="203265083:sNHT29102044" 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 j76IeLZN012054; Sat, 6 Aug 2005 11:40:48 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 11:40:30 -0700 Received: from sfluhrerhpc ([10.32.244.83]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 6 Aug 2005 11:40:29 -0700 From: "Scott Fluhrer" To: "'Bill Sommerfeld'" , "'Mohan Parthasarathy'" Subject: RE: [Ipsec] REKEY_SA with new SA offer.. Date: Sat, 6 Aug 2005 11:40:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWaoSfqJcl9YN7cRLyACD5rq+G5agAFMixQ In-Reply-To: <1123344277.5951.19.camel@unknown.hamachi.org> Message-ID: X-OriginalArrivalTime: 06 Aug 2005 18:40:29.0662 (UTC) FILETIME=[51C68FE0:01C59AB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Bill Sommerfeld > Sent: Saturday, August 06, 2005 9:05 AM > To: Mohan Parthasarathy > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] REKEY_SA with new SA offer.. > > On Sat, 2005-08-06 at 00:36, Mohan Parthasarathy wrote: > > For example, > > when i set up the ESP SA for the first time i offered AES > with SHA-1 > > and when i rekey i offer ENCR_NULL and SHA-1 ? I don't see > why this would be an issue. > > changing a real algorithm to ENCR_NULL on a rekey really > ought to be an error. Not necessarily. What if we rekeyed because our security policy changed (that is, the administrator deliberately changed our policy on what transforms should be used)? -- scott _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 08 14:39:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CXC-000797-E3; Mon, 08 Aug 2005 14:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CXA-00076j-C9 for ipsec@megatron.ietf.org; Mon, 08 Aug 2005 14:39:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08272 for ; Mon, 8 Aug 2005 14:39:34 -0400 (EDT) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2D4u-0008HN-8w for ipsec@ietf.org; Mon, 08 Aug 2005 15:14:29 -0400 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 08 Aug 2005 11:39:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,89,1122879600"; d="scan'208"; a="471231212:sNHT22930060" Received: from gluon.jnpr.net ([172.24.15.23]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 11:39:25 -0700 Received: from ghuang-lnx.netscreen.com ([10.150.65.191]) by gluon.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 11:39:25 -0700 Subject: RE: [Ipsec] REKEY_SA with new SA offer.. From: Geoffrey Huang To: Scott Fluhrer In-Reply-To: References: Content-Type: text/plain Date: Mon, 08 Aug 2005 11:39:24 -0700 Message-Id: <1123526365.5015.2.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2005 18:39:25.0270 (UTC) FILETIME=[80389F60:01C59C48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: 'Mohan Parthasarathy' , ipsec@ietf.org, 'Bill Sommerfeld' X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sat, 2005-08-06 at 11:40 -0700, Scott Fluhrer wrote: > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of Bill Sommerfeld > > Sent: Saturday, August 06, 2005 9:05 AM > > To: Mohan Parthasarathy > > Cc: ipsec@ietf.org > > Subject: Re: [Ipsec] REKEY_SA with new SA offer.. > > > > On Sat, 2005-08-06 at 00:36, Mohan Parthasarathy wrote: > > > For example, > > > when i set up the ESP SA for the first time i offered AES > > with SHA-1 > > > and when i rekey i offer ENCR_NULL and SHA-1 ? I don't see > > why this would be an issue. > > > > changing a real algorithm to ENCR_NULL on a rekey really > > ought to be an error. > > Not necessarily. What if we rekeyed because our security policy changed > (that is, the administrator deliberately changed our policy on what > transforms should be used)? > I tend to agree. The text of the previous e-mail said changing an algorithm "to ENCR_NULL" ought to be an error, suggesting special- casing. I.e., the text of the e-mail suggests changing from ENCR_NULL to AES wouldn't be an error. I disagree that one would be allowed but not the other. In any case, I think the administrator should be allowed to do as the administrator pleases. Otherwise, what would be the point of re-sending the SA payload? -g _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 08 17:34:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FFy-0002T3-Rh; Mon, 08 Aug 2005 17:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FFw-0002Qh-Jq for ipsec@megatron.ietf.org; Mon, 08 Aug 2005 17:34:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26076 for ; Mon, 8 Aug 2005 17:33:58 -0400 (EDT) Received: from web80604.mail.yahoo.com ([66.218.79.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2Fnf-0007YT-LE for ipsec@ietf.org; Mon, 08 Aug 2005 18:08:55 -0400 Received: (qmail 61778 invoked by uid 60001); 8 Aug 2005 21:33:45 -0000 Message-ID: <20050808213345.61776.qmail@web80604.mail.yahoo.com> Received: from [206.132.194.2] by web80604.mail.yahoo.com via HTTP; Mon, 08 Aug 2005 14:33:45 PDT Date: Mon, 8 Aug 2005 14:33:45 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [Ipsec] REKEY_SA with new SA offer.. To: Bill Sommerfeld In-Reply-To: <1123344277.5951.19.camel@unknown.hamachi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --- Bill Sommerfeld wrote: > On Sat, 2005-08-06 at 00:36, Mohan Parthasarathy > wrote: > > For example, > > when i set up the ESP SA for the first time i > offered AES with SHA-1 and when i rekey i offer > > ENCR_NULL and SHA-1 ? I don't see why this would > be an issue. > > changing a real algorithm to ENCR_NULL on a rekey > really ought to be an > error. > Hmm.. Why ? It is a matter of policy. If the peer is willing to accept such policy, why is it an error ? IKEv2 itself cannot say much about it i guess as it is a matter of policy. Checking to see if i am not missing anything in the draft.. -mohan > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 16 05:46:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4y1d-0006PJ-CT; Tue, 16 Aug 2005 05:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4y1c-0006PA-0N for ipsec@megatron.ietf.org; Tue, 16 Aug 2005 05:46:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29903 for ; Tue, 16 Aug 2005 05:46:25 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E4yav-0003qz-C1 for ipsec@ietf.org; Tue, 16 Aug 2005 06:22:57 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 16 Aug 2005 10:42:05 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 10:42:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Aug 2005 10:42:04 +0100 Message-ID: Thread-Topic: Multicast - IPsec in Tunnel mode Thread-Index: AcWiN/XfuwgQcsplQfaFo5tWWyzkqQADpouQ From: "H.Cruickshank" To: ipsec X-OriginalArrivalTime: 16 Aug 2005 09:42:04.0829 (UTC) FILETIME=[C2B9BCD0:01C5A246] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [Ipsec] FW: Multicast - IPsec in Tunnel mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1602423683==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1602423683== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A246.C2D163AB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A246.C2D163AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Cruickshank HS Dr (CCSR)=20 Sent: 16 August 2005 08:56 To: 'ipsec@lists.tislabs.com'; msec@securemulticast.org Subject: Multicast - IPsec in Tunnel mode Hi, =20 I wonder if somebody can help me to understand how does IPsec (tunnel mode) work with multicast: =20 Scenario 1: ----------- There is an IP multicast session in the clear. Part of the multicast distribution paths are controlled by security gateways, where they MUST use IPsec in tunnel-mode between them. Let us assume that there are 4 security gateways: How does IPsec (tunnel mode) work here. =20 =20 =20 Scenario 2: ----------- Same as scenario 1, except that the original IP multicast session is secure (e.g. IPsec in transport mode between sender and receivers) . So how does the security gateways use IPsec in tunnel-mode now. =20 Many thanks. Haitham =20 ------_=_NextPart_001_01C5A246.C2D163AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: Cruickshank HS Dr = (CCSR)=20
Sent: 16 August 2005 08:56
To: = 'ipsec@lists.tislabs.com';=20 msec@securemulticast.org
Subject: Multicast - IPsec in Tunnel=20 mode

Hi,
 
I wonder if somebody can help me to understand = how  does IPsec (tunnel mode) = work with=20 multicast:
 
Scenario=20 1:
-----------
There is an = IP multicast=20 session in the clear.  Part of the multicast distribution paths are = controlled by security gateways, where they MUST use IPsec = in=20 tunnel-mode between them.  Let us assume that there are 4 security=20 gateways: How does = IPsec (tunnel=20 mode) work=20 here.   
 
 
Scenario=20 2:
-----------
Same as = scenario 1,=20 except that the original IP multicast session is secure (e.g. IPsec in = transport mode=20 between sender and receivers) .  So how does the security gateways = use=20 IPsec in tunnel-mode now.
 
Many=20 thanks.
Haitham
 
=00 ------_=_NextPart_001_01C5A246.C2D163AB-- --===============1602423683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1602423683==-- From ipsec-bounces@ietf.org Tue Aug 16 09:17:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51Jt-0003pF-6R; Tue, 16 Aug 2005 09:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51Jq-0003mE-8G for ipsec@megatron.ietf.org; Tue, 16 Aug 2005 09:17:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09819 for ; Tue, 16 Aug 2005 09:17:27 -0400 (EDT) Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E51sv-0000gR-Cz for ipsec@ietf.org; Tue, 16 Aug 2005 09:53:48 -0400 Received: (qmail 75669 invoked from network); 16 Aug 2005 13:17:10 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 16 Aug 2005 13:17:10 -0000 Received: (qmail 60717 invoked from network); 16 Aug 2005 09:17:10 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 16 Aug 2005 09:17:10 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j7G9tgL16664; Tue, 16 Aug 2005 05:55:42 -0400 Date: Tue, 16 Aug 2005 05:55:42 -0400 (EDT) From: George Gross To: "H.Cruickshank" Subject: Re: [Ipsec] FW: Multicast - IPsec in Tunnel mode In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.7 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Haitham, You can find a discussion of IPsec tunnel mode, and many other aspects of IPsec secure multicast in the draft: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensions-00.txt wrt/ your two questions, the above draft defines an optional flag for use in combination with the Populate From Packet (PFP) mode SPD entries that enhances IPsec tunnel mode for secure multicast. Plz refer to the draft section 3 for the details.... hth, George On Tue, 16 Aug 2005, H.Cruickshank wrote: > > -----Original Message----- > From: Cruickshank HS Dr (CCSR) > Sent: 16 August 2005 08:56 > To: 'ipsec@lists.tislabs.com'; msec@securemulticast.org > Subject: Multicast - IPsec in Tunnel mode > > > Hi, > > I wonder if somebody can help me to understand how does IPsec (tunnel > mode) work with multicast: > > Scenario 1: > ----------- > There is an IP multicast session in the clear. Part of the multicast > distribution paths are controlled by security gateways, where they MUST > use IPsec in tunnel-mode between them. Let us assume that there are 4 > security gateways: How does IPsec (tunnel mode) work here. > > > Scenario 2: > ----------- > Same as scenario 1, except that the original IP multicast session is > secure (e.g. IPsec in transport mode between sender and receivers) . So > how does the security gateways use IPsec in tunnel-mode now. > > Many thanks. > Haitham > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 16 09:56:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51w2-0002WP-6H; Tue, 16 Aug 2005 09:56:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51w0-0002WK-1N for ipsec@megatron.ietf.org; Tue, 16 Aug 2005 09:56:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12019 for ; Tue, 16 Aug 2005 09:56:53 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E52VI-0001l2-Mp for ipsec@ietf.org; Tue, 16 Aug 2005 10:33:28 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 16 Aug 2005 14:55:57 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 14:55:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] FW: Multicast - IPsec in Tunnel mode Date: Tue, 16 Aug 2005 14:55:52 +0100 Message-ID: Thread-Topic: [Ipsec] FW: Multicast - IPsec in Tunnel mode Thread-Index: AcWiZj8HvGQwFn2rQHWPXQLciCOKDAAA0O6Q From: "H.Cruickshank" To: gmgross X-OriginalArrivalTime: 16 Aug 2005 13:55:55.0073 (UTC) FILETIME=[38A88B10:01C5A26A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi George, Many thanks for your reply. I am aware of the msec draft on multicast extension (draft-ietf-msec-ipsec-extensions-00.txt). However my question was about the current IPsec (standard) and how does the tunnel mode work with multicast. Haitham -- Dr. Haitham S. Cruickshank=20 Lecturer Communications Centre for Communication Systems Research (CCSR)=20 School of Electronics, Computing and Mathematics=20 University of Surrey, Guildford, Surrey GU2 7XH, UK=20 Tel: +44 1483 686007 (indirect 689844)=20 Fax: +44 1483 686011=20 e-mail: H.Cruickshank@surrey.ac.uk=20 http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/=20 -----Original Message----- From: George Gross [mailto:gmgross@nac.net]=20 Sent: 16 August 2005 10:56 To: Cruickshank HS Dr (CCSR) Cc: ipsec Subject: Re: [Ipsec] FW: Multicast - IPsec in Tunnel mode Hi Haitham, You can find a discussion of IPsec tunnel mode, and many other aspects of IPsec secure multicast in the draft: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensions-00. txt wrt/ your two questions, the above draft defines an optional flag for use in combination with the Populate From Packet (PFP) mode SPD entries that enhances IPsec tunnel mode for secure multicast. Plz refer to the draft section 3 for the details.... hth, George On Tue, 16 Aug 2005, H.Cruickshank wrote: > > -----Original Message----- > From: Cruickshank HS Dr (CCSR) > Sent: 16 August 2005 08:56 > To: 'ipsec@lists.tislabs.com'; msec@securemulticast.org > Subject: Multicast - IPsec in Tunnel mode > > > Hi, > > I wonder if somebody can help me to understand how does IPsec (tunnel > mode) work with multicast: > > Scenario 1: > ----------- > There is an IP multicast session in the clear. Part of the multicast=20 > distribution paths are controlled by security gateways, where they=20 > MUST use IPsec in tunnel-mode between them. Let us assume that there=20 > are 4 security gateways: How does IPsec (tunnel mode) work here. > > > Scenario 2: > ----------- > Same as scenario 1, except that the original IP multicast session is=20 > secure (e.g. IPsec in transport mode between sender and receivers) . =20 > So how does the security gateways use IPsec in tunnel-mode now. > > Many thanks. > Haitham > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 16 10:49:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52kP-0003nu-Ad; Tue, 16 Aug 2005 10:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52kM-0003nm-T0 for ipsec@megatron.ietf.org; Tue, 16 Aug 2005 10:48:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16054 for ; Tue, 16 Aug 2005 10:48:56 -0400 (EDT) Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E53Jg-0003D8-Tc for ipsec@ietf.org; Tue, 16 Aug 2005 11:25:31 -0400 Received: (qmail 8147 invoked from network); 16 Aug 2005 14:48:54 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 16 Aug 2005 14:48:54 -0000 Received: (qmail 19165 invoked from network); 16 Aug 2005 10:48:54 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 16 Aug 2005 10:48:54 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j7GBRRv16756; Tue, 16 Aug 2005 07:27:27 -0400 Date: Tue, 16 Aug 2005 07:27:27 -0400 (EDT) From: George Gross To: "H.Cruickshank" Subject: RE: [Ipsec] FW: Multicast - IPsec in Tunnel mode In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.7 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: ipsec , gmgross X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Haitham, inline below.... On Tue, 16 Aug 2005, H.Cruickshank wrote: > Hi George, > > Many thanks for your reply. I am aware of the msec draft on multicast > extension (draft-ietf-msec-ipsec-extensions-00.txt). However my > question was about the current IPsec (standard) and how does the tunnel > mode work with multicast. I can understand your confusion, perhaps I can clarify the relationship between the draft-ietf-msec-ipsec-extensions-00.txt and other IPsec documents. In the original RFC2401, the definition of secure multicast processing was not altogether as well understood as compared to what is known now. Consequently, folks in MSEC worked with Steve Kent to formulate a more mature secure multicast definition for inclusion in RFC2401-bis. I don't know off hand if any document explicitly says this, but the intent is that the use of secure multicast with RFC2401 implementations is deprecated. In RFC2401-bis, support for secure multicast is optional. For those RFC2401-bis compliant IPsec implementations that choose to support secure multicast, the msec-ipsec-extensions draft adds additional mandatory requirements beyond those stated in RFC2401-bis. These requirements mostly concern tunnel mode SAs. RFC2401-bis and its companions are currently in the RFC editor's queue. The msec-ipsec-extensions draft is standards track work item within the MSEC working group. does that help clarify the IPsec document relationships? br, George > > Haitham > > -- > > Dr. Haitham S. Cruickshank > > Lecturer > > Communications Centre for Communication Systems Research (CCSR) > > School of Electronics, Computing and Mathematics > > University of Surrey, Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > > Fax: +44 1483 686011 > > e-mail: H.Cruickshank@surrey.ac.uk > > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > -----Original Message----- > From: George Gross [mailto:gmgross@nac.net] > Sent: 16 August 2005 10:56 > To: Cruickshank HS Dr (CCSR) > Cc: ipsec > Subject: Re: [Ipsec] FW: Multicast - IPsec in Tunnel mode > > > Hi Haitham, > > You can find a discussion of IPsec tunnel mode, and many other aspects > of IPsec secure multicast in the draft: > > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-extensions-00. > txt > > wrt/ your two questions, the above draft defines an optional flag for > use in combination with the Populate From Packet (PFP) mode SPD entries > that enhances IPsec tunnel mode for secure multicast. Plz refer to the > draft section 3 for the details.... > > hth, > George > > On Tue, 16 Aug 2005, H.Cruickshank wrote: > > > > > -----Original Message----- > > From: Cruickshank HS Dr (CCSR) > > Sent: 16 August 2005 08:56 > > To: 'ipsec@lists.tislabs.com'; msec@securemulticast.org > > Subject: Multicast - IPsec in Tunnel mode > > > > > > Hi, > > > > I wonder if somebody can help me to understand how does IPsec (tunnel > > mode) work with multicast: > > > > Scenario 1: > > ----------- > > There is an IP multicast session in the clear. Part of the multicast > > distribution paths are controlled by security gateways, where they > > MUST use IPsec in tunnel-mode between them. Let us assume that there > > are 4 security gateways: How does IPsec (tunnel mode) work here. > > > > > > Scenario 2: > > ----------- > > Same as scenario 1, except that the original IP multicast session is > > secure (e.g. IPsec in transport mode between sender and receivers) . > > So how does the security gateways use IPsec in tunnel-mode now. > > > > Many thanks. > > Haitham > > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Aug 19 06:47:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64Pc-00026k-Iw; Fri, 19 Aug 2005 06:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64Pa-00026e-SL for ipsec@megatron.ietf.org; Fri, 19 Aug 2005 06:47:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25413 for ; Fri, 19 Aug 2005 06:47:43 -0400 (EDT) From: atul@codito.com Received: from [203.197.88.2] (helo=marvin.codito.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E64zW-0004uX-6t for ipsec@ietf.org; Fri, 19 Aug 2005 07:24:55 -0400 Received: from webmail.codito.com (localhost [127.0.0.1]) by marvin.codito.net (8.13.4/8.13.4/Debian-3) with ESMTP id j7JAlXce013742 for ; Fri, 19 Aug 2005 16:17:34 +0530 Received: from 220.225.32.98 (SquirrelMail authenticated user atul) by webmail.codito.com with HTTP; Fri, 19 Aug 2005 16:17:34 +0530 (IST) Message-ID: <33296.220.225.32.98.1124448454.squirrel@webmail.codito.com> Date: Fri, 19 Aug 2005 16:17:34 +0530 (IST) Subject: [ipsec] PMTU handling in IPSec for IPv4 in 2.6 kernel To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.86.1/1034/Fri Aug 19 01:37:58 2005 on marvin.codito.net X-Virus-Status: Clean X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 8bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hii ... Can anyone plz help me a lil in figuring out where the MTU discovery n handling is done in linux kernel 2.6 for ICMP erooro handling in IPSEC... thnx.. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 22 09:37:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CUm-0002fc-Nl; Mon, 22 Aug 2005 09:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CUk-0002fX-R9 for ipsec@megatron.ietf.org; Mon, 22 Aug 2005 09:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15710 for ; Mon, 22 Aug 2005 09:37:45 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7D5H-00015V-JA for ipsec@ietf.org; Mon, 22 Aug 2005 10:15:34 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j7MDbU9N017349 for ; Mon, 22 Aug 2005 08:37:30 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Aug 2005 08:37:30 -0500 Message-ID: From: "James Comen (NC/TNT)" To: "'ipsec@ietf.org'" Date: Mon, 22 Aug 2005 08:37:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ipsec] Status of IKEv2 draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1753144985==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1753144985== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A71E.A1A91652" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5A71E.A1A91652 Content-Type: text/plain; charset="iso-8859-1" Hello, I've been looking through the IPsec archives and have not been able to determine the status of the IKEv2 draft. Draft 17 was to have expired in March of 2005. I saw IKEv2 discussions following March 2005 but no plans for a subsequent IKEv2 draft. Are there plans/timetable for an upcoming IKEv2 draft/RFC? Thanks ------_=_NextPart_001_01C5A71E.A1A91652 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status of IKEv2 draft

Hello,
I've been looking through the IPsec = archives and have not been able to determine the status of the IKEv2 = draft.
Draft 17 was to have expired in March = of 2005.  I saw IKEv2 discussions following March 2005 but no = plans for a subsequent IKEv2 draft. 

Are there plans/timetable for an = upcoming IKEv2 draft/RFC?
Thanks

------_=_NextPart_001_01C5A71E.A1A91652-- --===============1753144985== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1753144985==-- From ipsec-bounces@ietf.org Mon Aug 22 10:53:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DfZ-0007z5-HN; Mon, 22 Aug 2005 10:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DfX-0007yw-1R for ipsec@megatron.ietf.org; Mon, 22 Aug 2005 10:52:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20693 for ; Mon, 22 Aug 2005 10:52:56 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EG6-0003IP-GE for ipsec@ietf.org; Mon, 22 Aug 2005 11:30:47 -0400 Received: by machshav.com (Postfix, from userid 512) id 71663FB27C; Mon, 22 Aug 2005 10:52:48 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E5453FB249; Mon, 22 Aug 2005 10:52:47 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id B1DF93BFF2F; Mon, 22 Aug 2005 10:52:46 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "James Comen (NC/TNT)" Subject: Re: [Ipsec] Status of IKEv2 draft In-Reply-To: Your message of "Mon, 22 Aug 2005 08:37:25 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Aug 2005 10:52:46 -0400 Message-Id: <20050822145246.B1DF93BFF2F@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "'ipsec@ietf.org'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In message >Hello, >I've been looking through the IPsec archives and have not been able to determi >ne the status of the IKEv2 draft. >Draft 17 was to have expired in March of 2005. I saw IKEv2 discussions follow >ing March 2005 but no plans for a subsequent IKEv2 draft. >Are there plans/timetable for an upcoming IKEv2 draft/RFC? https://datatracker.ietf.org/public/pidtracker.cgi says that that draft is in the RFC Editor Queue. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 22 11:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EYq-0002pA-F9; Mon, 22 Aug 2005 11:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EYo-0002p2-Ub for ipsec@megatron.ietf.org; Mon, 22 Aug 2005 11:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23762 for ; Mon, 22 Aug 2005 11:50:04 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7F9N-00054N-LE for ipsec@ietf.org; Mon, 22 Aug 2005 12:27:56 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MFnkHe012924; Mon, 22 Aug 2005 08:49:46 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 22 Aug 2005 08:49:43 -0700 To: "James Comen (NC/TNT)" , "'ipsec@ietf.org'" From: Paul Hoffman Subject: Re: [Ipsec] Status of IKEv2 draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org It is languishing in the RFC Editor's queue, patiently waiting for publication. See . --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 22 12:11:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EtW-0006UR-Kd; Mon, 22 Aug 2005 12:11:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EtU-0006UH-KW for ipsec@megatron.ietf.org; Mon, 22 Aug 2005 12:11:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24834 for ; Mon, 22 Aug 2005 12:11:25 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7FU2-0005gy-I0 for ipsec@ietf.org; Mon, 22 Aug 2005 12:49:17 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7MGBL2B001143; Mon, 22 Aug 2005 09:11:21 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j7MGBKUj027677; Mon, 22 Aug 2005 12:11:20 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j7MGBJUs025165; Mon, 22 Aug 2005 12:11:20 -0400 (EDT) Subject: Re: [Ipsec] Status of IKEv2 draft From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1124727079.24824.59.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 22 Aug 2005 12:11:19 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "'ipsec@ietf.org'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, 2005-08-22 at 11:49, Paul Hoffman wrote: > It is languishing in the RFC Editor's queue, patiently waiting for > publication. See > . The RFC editor publication latency (from when the last normative reference is approved to when the rfc pops out) looks like it's around 7 months at present. ikev2 depends on 2401bis; 2401bis was approved in mid-April. So maybe if we're lucky we'll have an ikev2 rfc in november? - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 23 02:11:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7S06-0002UL-S0; Tue, 23 Aug 2005 02:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7S05-0002UB-7U for ipsec@megatron.ietf.org; Tue, 23 Aug 2005 02:11:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12770 for ; Tue, 23 Aug 2005 02:11:07 -0400 (EDT) Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7S07-0000Z7-8g for ipsec@ietf.org; Tue, 23 Aug 2005 02:11:12 -0400 Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.193]) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j7N6ArG18171 for ; Tue, 23 Aug 2005 15:10:53 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j7N6Ark08198 for ipsec@ietf.org; Tue, 23 Aug 2005 15:10:53 +0900 (JST) Received: from ncos.nec.co.jp (mailgate2.ncos.nec.co.jp [10.40.15.12]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with SMTP id j7N6Arn28221 for ; Tue, 23 Aug 2005 15:10:53 +0900 (JST) Received: (qmail 11671 invoked by uid 0); 23 Aug 2005 15:10:45 +0900 Received: from unknown (HELO platini.ntes.ipv6.nec.co.jp) (10.43.90.28) by 172.16.255.129 with SMTP; 23 Aug 2005 15:10:45 +0900 Received: from bn4p0048.bn4.bbn.ncos.nec.co.jp ([IPv6:5ffe:26:2591:1:203:47ff:feb1:ba04]) (authenticated user=inoue mech=LOGIN) by platini.ntes.ipv6.nec.co.jp (8.13.4/8.13.1) with ESMTP id j7N6AiW5025030 for ; Tue, 23 Aug 2005 15:10:45 +0900 (JST) (envelope-from inoue@ntes.ipv6.nec.co.jp) Date: Tue, 23 Aug 2005 15:10:44 +0900 From: Satoshi Inoue To: ipsec@ietf.org Message-Id: <20050823151044.1265b582.inoue@ntes.ipv6.nec.co.jp> X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Ipsec] EAP_ONLY_AUTHENTICATION; is it still valid? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, While I was trying to figure out how to do EAP w/o CERT, I found description on EAP_ONLY_AUTHENTICATION notification payload in draft-eronen-ipsec-ikev2-eap-auth-03.txt. Is this notify (or I-D I may say) still a valid type in terms of IKEv2 standard track? Relating to this topic, I'm a bit confused with the sequence below; IKEv2 w/ EAP sequence (just copied from IKEv2-17). Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr } If CERT is not used with EAP, how do we derive the AUTH payload in message 4? Thanks, Satoshi Inoue _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 23 04:33:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UEI-0003ga-Em; Tue, 23 Aug 2005 04:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UEH-0003gK-0B for ipsec@megatron.ietf.org; Tue, 23 Aug 2005 04:33:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21320 for ; Tue, 23 Aug 2005 04:33:55 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7UEJ-0004h2-Pi for ipsec@ietf.org; Tue, 23 Aug 2005 04:34:02 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j7N8XZs4009152; Tue, 23 Aug 2005 10:33:35 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j7N8XZjh016588; Tue, 23 Aug 2005 10:33:35 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Aug 2005 10:33:34 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: AW: [Ipsec] EAP_ONLY_AUTHENTICATION; is it still valid? Date: Tue, 23 Aug 2005 10:33:33 +0200 Message-ID: Thread-Topic: [Ipsec] EAP_ONLY_AUTHENTICATION; is it still valid? Thread-Index: AcWnqehR8Hns14laR5Gich/3lwRaNAACKGPg From: "Tschofenig, Hannes" To: "Satoshi Inoue" , X-OriginalArrivalTime: 23 Aug 2005 08:33:34.0508 (UTC) FILETIME=[59ACC6C0:01C5A7BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi satoshi,=20 thanks for our feedback. please find a few comments below:=20 > Hi all, >=20 > While I was trying to figure out how to do EAP w/o CERT, I found > description on EAP_ONLY_AUTHENTICATION notification payload in > draft-eronen-ipsec-ikev2-eap-auth-03.txt. Is this notify (or I-D I > may say) still a valid type in terms of IKEv2 standard track? what do you mean by valid?=20 where do you see a problem?=20 >=20 > Relating to this topic, I'm a bit confused with the sequence below; > IKEv2 w/ EAP sequence (just copied from IKEv2-17). >=20 > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> >=20 > <-- HDR, SAr1, KEr, Nr, [CERTREQ] >=20 > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> >=20 > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP } >=20 > HDR, SK {EAP} --> >=20 > <-- HDR, SK {EAP (success)} >=20 > HDR, SK {AUTH} --> >=20 > <-- HDR, SK {AUTH, SAr2, TSi, TSr } >=20 > If CERT is not used with EAP, how do we derive the AUTH payload in > message 4? with ikev2 the responder uses pk-based authentication to the initiator. if the cert payload is not included in message 4 then the initiator is assumed to know the certificate (based on the identity of the responder).=20 with draft-eronen-ipsec-ikev2-eap-auth-03.txt the auth payload of message 4 is delayed to a later message (see section 3 of draft-eronen-ipsec-ikev2-eap-auth-03.txt).=20 ciao hannes >=20 > Thanks, > Satoshi Inoue >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 23 06:53:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WP3-0005EP-95; Tue, 23 Aug 2005 06:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WP0-0005EK-U1 for ipsec@megatron.ietf.org; Tue, 23 Aug 2005 06:53:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25909 for ; Tue, 23 Aug 2005 06:53:08 -0400 (EDT) Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7WP5-0008KT-LN for ipsec@ietf.org; Tue, 23 Aug 2005 06:53:17 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.192]) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j7NAquG01078 for ; Tue, 23 Aug 2005 19:52:56 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j7NAqux01222 for ipsec@ietf.org; Tue, 23 Aug 2005 19:52:56 +0900 (JST) Received: from ncos.nec.co.jp (mailgate2.ncos.nec.co.jp [10.40.15.12]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with SMTP id j7NAqu602234 for ; Tue, 23 Aug 2005 19:52:56 +0900 (JST) Received: (qmail 13085 invoked by uid 0); 23 Aug 2005 19:52:46 +0900 Received: from unknown (HELO platini.ntes.ipv6.nec.co.jp) (10.43.90.28) by 172.16.255.129 with SMTP; 23 Aug 2005 19:52:46 +0900 Received: from bn4p0048.bn4.bbn.ncos.nec.co.jp ([IPv6:5ffe:26:2591:1:203:47ff:feb1:ba04]) (authenticated user=inoue mech=LOGIN) by platini.ntes.ipv6.nec.co.jp (8.13.4/8.13.1) with ESMTP id j7NAqkMd038481; Tue, 23 Aug 2005 19:52:46 +0900 (JST) (envelope-from inoue@ntes.ipv6.nec.co.jp) Date: Tue, 23 Aug 2005 19:52:46 +0900 From: Satoshi Inoue To: "Tschofenig, Hannes" Subject: Re: AW: [Ipsec] EAP_ONLY_AUTHENTICATION; is it still valid? Message-Id: <20050823195246.7cb23123.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Hannes, Thanks for your response. On Tue, 23 Aug 2005 10:33:33 +0200 "Tschofenig, Hannes" wrote: > what do you mean by valid? I wanted to know whether it's gonna be a proposed standard or not. Or at least, whether it's well confirmed/clarified by the list. The value for this notify type is not assigned yet, that's another worry for me. > with ikev2 the responder uses pk-based authentication to the initiator. > if the cert payload is not included in message 4 then the initiator is > assumed to know the certificate (based on the identity of the > responder). Okay. Let me focus on EAP w/o using certificates. If EAP_ONLY_AUTHENTICATION is considered as a proposed standard (or well confirmed/clarified), shouldn't the message 4 of AUTH payload be optional in IKEv2-17 too? Another thing, isn't it possible to include this notify payload in IKEv2-17, or at least, in clarification document? I do not want to see too many separated RFC/I-Ds for IKEv2, like it was in IKEv1. > with draft-eronen-ipsec-ikev2-eap-auth-03.txt the auth payload of > message 4 is delayed to a later message (see section 3 of > draft-eronen-ipsec-ikev2-eap-auth-03.txt). AUTH payload of message 4 is omitted, not delayed. AUTH payload of message 7 and 8 is derived from EAP generated key, right? Thanks, Satoshi Inoue _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 23 13:28:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cZI-0001H2-3d; Tue, 23 Aug 2005 13:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cZE-0001Gh-P2 for ipsec@megatron.ietf.org; Tue, 23 Aug 2005 13:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16895 for ; Tue, 23 Aug 2005 13:28:00 -0400 (EDT) From: atul@codito.com Received: from [203.197.88.2] (helo=marvin.codito.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7cZC-0003Oe-2S for ipsec@ietf.org; Tue, 23 Aug 2005 13:28:13 -0400 Received: from webmail.codito.com (localhost [127.0.0.1]) by marvin.codito.net (8.13.4/8.13.4/Debian-3) with ESMTP id j7NHSQ1a016756 for ; Tue, 23 Aug 2005 22:58:28 +0530 Received: from 220.225.32.98 (SquirrelMail authenticated user atul) by webmail.codito.com with HTTP; Tue, 23 Aug 2005 22:58:28 +0530 (IST) Message-ID: <33639.220.225.32.98.1124818108.squirrel@webmail.codito.com> Date: Tue, 23 Aug 2005 22:58:28 +0530 (IST) Subject: [Ipsec]Issue on PF_KEY vs. Netlink interface] To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.86.1/1036/Tue Aug 23 19:25:28 2005 on marvin.codito.net X-Virus-Status: Clean X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 8bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I'm learning native IPsec in Linux kernel 2.6. and use IPsec-Tools as my user-space tools. In net/key/af_key.c, there are something about PF_KEY as follows: static struct xfrm_mgr pfkeyv2_mgr = { .id = "pfkeyv2", .notify = pfkey_send_notify, .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, }; static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *xp, int dir) In net/xfrm/xfrm_user.c, there are also something about Netlink as follows: static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, .acquire = xfrm_send_acquire, .compile_policy = xfrm_compile_policy, .notify_policy = xfrm_send_policy_notify, }; static int xfrm_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) Then, when kernel send a message to racoon for setting up a SA, What interface(i.e. PF_KEY or Netlink) indeed is used to send such a message? (i.e. Does it use pfkey_send_acquire() or xfrm_send_acquire()? ) .. if both r used can u tell me the situation where one or the othere is used.. And, What is the relationship between PF_KEY and Netlink in Linux kernel, when we use IPsec? plzz help me i m stuck at a place where i dont know anyone who can help me.. Thank you. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 24 06:00:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7s3S-0008Dd-1n; Wed, 24 Aug 2005 06:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7s3Q-0008DT-7i for ipsec@megatron.ietf.org; Wed, 24 Aug 2005 06:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10591 for ; Wed, 24 Aug 2005 06:00:18 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7s3h-000209-6t for ipsec@ietf.org; Wed, 24 Aug 2005 06:00:39 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j7OA08YG003928; Wed, 24 Aug 2005 12:00:08 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j7OA07uD012301; Wed, 24 Aug 2005 12:00:07 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Aug 2005 12:00:04 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: AW: AW: [Ipsec] EAP_ONLY_AUTHENTICATION; is it still valid? Date: Wed, 24 Aug 2005 12:00:03 +0200 Message-ID: Thread-Topic: AW: [Ipsec] EAP_ONLY_AUTHENTICATION; is it still valid? Thread-Index: AcWn0Nc2luERCfZ6SWyPk1xPyWOC8QAwIDgQ From: "Tschofenig, Hannes" To: "Satoshi Inoue" X-OriginalArrivalTime: 24 Aug 2005 10:00:04.0221 (UTC) FILETIME=[9965E2D0:01C5A892] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi satoshi,=20 > Hi Hannes, >=20 > Thanks for your response. >=20 > On Tue, 23 Aug 2005 10:33:33 +0200 > "Tschofenig, Hannes" wrote: >=20 > > what do you mean by valid?=20 >=20 > I wanted to know whether it's gonna be a proposed standard or not. we, the authors, would like to see this work moving forward. we have also received positive feedback about this work for this work.=20 > Or at least, whether it's well confirmed/clarified by the list. since the ipsec working group does not exist anymore it will not be a working group item.=20 > The > value for this notify type is not assigned yet, that's another > worry for me. sure. that would happen as part of the iana registration.=20 >=20 > > with ikev2 the responder uses pk-based authentication to=20 > the initiator. > > if the cert payload is not included in message 4 then the=20 > initiator is > > assumed to know the certificate (based on the identity of the > > responder).=20 >=20 > Okay. Let me focus on EAP w/o using certificates. If > EAP_ONLY_AUTHENTICATION is considered as a proposed standard (or > well confirmed/clarified), shouldn't the message 4 of AUTH payload > be optional in IKEv2-17 too? it does not need to be. if the responder supports this extension then the corresponding functionality will be triggered.=20 >=20 > Another thing, isn't it possible to include this notify payload in > IKEv2-17, or at least, in clarification document? ikev2: no.=20 clarifications document: i don't think that this was the idea of the clarifications document. > I do not want to > see too many separated RFC/I-Ds for IKEv2, like it was in IKEv1. i see.=20 >=20 > > with draft-eronen-ipsec-ikev2-eap-auth-03.txt the auth payload of > > message 4 is delayed to a later message (see section 3 of > > draft-eronen-ipsec-ikev2-eap-auth-03.txt).=20 >=20 > AUTH payload of message 4 is omitted, not delayed. well, the auth payload sent by the responder to the initiator is sent in a later message exchange after the eap authentication was completed.=20 > AUTH payload of > message 7 and 8 is derived from EAP generated key, right? yes, see the following paragraph in section 3: =20 " Both the initiator and responder MUST verify that the EAP method actually used provided mutual authentication and established a shared secret key. The AUTH payloads sent after EAP Success MUST use the EAP-generated key, and MUST NOT use SK_pi or SK_pr. " ciao hannes >=20 > Thanks, > Satoshi Inoue >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 30 08:28:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5Dw-0000SX-EM; Tue, 30 Aug 2005 08:28:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5Du-0000SP-HD for ipsec@megatron.ietf.org; Tue, 30 Aug 2005 08:28:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09443 for ; Tue, 30 Aug 2005 08:28:15 -0400 (EDT) Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA5FP-00084g-PG for ipsec@ietf.org; Tue, 30 Aug 2005 08:29:53 -0400 Received: from asbmail4.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with ESMTP id j7UCQFs7011991 for ; Tue, 30 Aug 2005 20:26:16 +0800 Received: from asbmail1.sbell.com.cn ([172.24.208.61]) by asbmail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Aug 2005 20:27:56 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Aug 2005 20:27:56 +0800 Message-ID: <60BBB1231E9EA443BD400F30A47C0A70010B5934@asbmail1.sbell.com.cn> Thread-Topic: ipsec test specification Thread-Index: AcWtXj9aA3Ofv2W2Q0C+EOA+dtB0qw== From: "FCG Yang JianBin" To: X-OriginalArrivalTime: 30 Aug 2005 12:27:56.0377 (UTC) FILETIME=[4017F490:01C5AD5E] X-imss-version: 2.031 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ipsec] ipsec test specification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2047490746==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============2047490746== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AD5E.40110E27" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AD5E.40110E27 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello: Is there any ipsec test specification or ipsec interopration test = standard or draft? who can tell me where i can get them?=20 Thanks a lot! Best Regard Yang Jianbin ------_=_NextPart_001_01C5AD5E.40110E27 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable ipsec test specification

Hello:

Is there any ipsec test specification or ipsec = interopration test standard or draft?
who can tell me where i can get them?
Thanks a lot!

Best Regard
Yang Jianbin


------_=_NextPart_001_01C5AD5E.40110E27-- --===============2047490746== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============2047490746==-- From ipsec-bounces@ietf.org Tue Aug 30 12:32:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA91v-0001bI-CI; Tue, 30 Aug 2005 12:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA91t-0001bD-FT for ipsec@megatron.ietf.org; Tue, 30 Aug 2005 12:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21984 for ; Tue, 30 Aug 2005 12:32:06 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EA93S-0005pn-CP for ipsec@ietf.org; Tue, 30 Aug 2005 12:33:47 -0400 Received: (qmail 28624 invoked by uid 0); 30 Aug 2005 16:32:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.157.37) by woodstock.binhost.com with SMTP; 30 Aug 2005 16:32:02 -0000 Message-Id: <6.2.1.2.2.20050830123055.063c4b10@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 30 Aug 2005 12:32:03 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] draft-mcgrew-aes-gmac-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org David McGrew and John Viega have requested publication of an IPsec ESP cipher specification that uses AES GMAC. The specification can be found at: http://www.ietf.org/internet-drafts/draft-mcgrew-aes-gmac-esp-00.txt Please let me know about any concerns that you might have with this specification in the next two weeks. Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 30 14:08:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAXX-0005v3-8x; Tue, 30 Aug 2005 14:08:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAXV-0005ut-HQ for ipsec@megatron.ietf.org; Tue, 30 Aug 2005 14:08:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27623 for ; Tue, 30 Aug 2005 14:08:51 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAAZ5-0000JX-16 for ipsec@ietf.org; Tue, 30 Aug 2005 14:10:32 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UI8fub097646; Tue, 30 Aug 2005 11:08:42 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <60BBB1231E9EA443BD400F30A47C0A70010B5934@asbmail1.sbell.com.cn> References: <60BBB1231E9EA443BD400F30A47C0A70010B5934@asbmail1.sbell.com.cn> Date: Tue, 30 Aug 2005 11:08:36 -0700 To: "FCG Yang JianBin" , From: Paul Hoffman Subject: Re: [Ipsec] ipsec test specification Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:27 PM +0800 8/30/05, FCG Yang JianBin wrote: >Is there any ipsec test specification or ipsec interopration test >standard or draft? There are none currently in the IETF. Organizations such as the VPN Consortium and ICSA Labs do interoperability testing for their members. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 31 06:52:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAQCh-0006bb-K3; Wed, 31 Aug 2005 06:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAQCf-0006aa-Jt for ipsec@megatron.ietf.org; Wed, 31 Aug 2005 06:52:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12952 for ; Wed, 31 Aug 2005 06:52:22 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAQEM-0001T3-0K for ipsec@ietf.org; Wed, 31 Aug 2005 06:54:13 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j7VApN6W009834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2005 13:51:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j7VApN3T011226; Wed, 31 Aug 2005 13:51:23 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17173.35755.659859.549651@fireball.kivinen.iki.fi> Date: Wed, 31 Aug 2005 13:51:23 +0300 From: Tero Kivinen To: Russ Housley Subject: [Ipsec] draft-mcgrew-aes-gmac-esp-00 In-Reply-To: <6.2.1.2.2.20050830123055.063c4b10@mail.binhost.com> References: <6.2.1.2.2.20050830123055.063c4b10@mail.binhost.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 16 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Russ Housley writes: > David McGrew and John Viega have requested publication of an IPsec ESP > cipher specification that uses AES GMAC. The specification can be found at: > > http://www.ietf.org/internet-drafts/draft-mcgrew-aes-gmac-esp-00.txt > > Please let me know about any concerns that you might have with this > specification in the next two weeks. I have one question relating to the test vectors. The draft says "Appendix B of [GCM] provides test vectors that will assist implementers with AES-GMAC.", but if I read the GCM (http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf) document correctly the appendix B does not have any single test case where the additional data data would have some data and where the actual plaintext to cipher zero. Also should we have test vectors in this document and not to refer some article. The test vectors in the GCM document is more or less for testing the cipher itself, they are not really very good test vectors for the GMAC-ESP. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 31 10:46:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EATrS-0002yI-Kf; Wed, 31 Aug 2005 10:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EATrQ-0002yD-8R for ipsec@megatron.ietf.org; Wed, 31 Aug 2005 10:46:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25030 for ; Wed, 31 Aug 2005 10:46:41 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EATt7-0007tE-2i for ipsec@ietf.org; Wed, 31 Aug 2005 10:48:34 -0400 Received: (qmail 7539 invoked by uid 0); 31 Aug 2005 14:46:26 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.39.220) by woodstock.binhost.com with SMTP; 31 Aug 2005 14:46:26 -0000 Message-Id: <6.2.1.2.2.20050831101101.055fd360@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 31 Aug 2005 10:11:25 -0400 To: Tero Kivinen From: Russ Housley Subject: Re: [Ipsec] draft-mcgrew-aes-gmac-esp-00 In-Reply-To: <17173.35755.659859.549651@fireball.kivinen.iki.fi> References: <6.2.1.2.2.20050830123055.063c4b10@mail.binhost.com> <17173.35755.659859.549651@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Good catch. I have requested that the authors include test vectors. Russ At 06:51 AM 8/31/2005, Tero Kivinen wrote: >Russ Housley writes: > > David McGrew and John Viega have requested publication of an IPsec ESP > > cipher specification that uses AES GMAC. The specification can be > found at: > > > > http://www.ietf.org/internet-drafts/draft-mcgrew-aes-gmac-esp-00.txt > > > > Please let me know about any concerns that you might have with this > > specification in the next two weeks. > >I have one question relating to the test vectors. The draft says >"Appendix B of [GCM] provides test vectors that will assist >implementers with AES-GMAC.", but if I read the GCM >(http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf) >document correctly the appendix B does not have any single test case >where the additional data data would have some data and where the >actual plaintext to cipher zero. > >Also should we have test vectors in this document and not to refer >some article. The test vectors in the GCM document is more or less for >testing the cipher itself, they are not really very good test vectors >for the GMAC-ESP. >-- >kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec