From ipsec-bounces@ietf.org Sun Jan 01 03:05:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsyDP-0001Le-Ew; Sun, 01 Jan 2006 03:05:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsyDM-0001LZ-Cj for ipsec@megatron.ietf.org; Sun, 01 Jan 2006 03:05:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01141 for ; Sun, 1 Jan 2006 03:04:03 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsyIA-0000NX-FC for ipsec@ietf.org; Sun, 01 Jan 2006 03:10:16 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k0184qAF000840; Sun, 1 Jan 2006 10:04:53 +0200 (IST) Message-Id: <200601010804.k0184qAF000840@michael.checkpoint.com> From: "Yoav Nir" To: "'Wade'" , , Subject: RE: [Ipsec] is there any idea on ipsec HA? Date: Sun, 1 Jan 2006 10:04:52 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcYNX9HTOR/mLfqiQf6+ncZcnY2OTgBSeCVw In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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 If you're doing HA, you can have a single IKE SA, but a separate IPsec SA for each security gateway. If you're using IKEv1, this will work with some but not all of the peers. If you're using IKEv2, then allowing two parallel SAs is required. Even if this is not allowed, when the failover happens, you can quickly (using Quick Mode or Create-Child-SA) create an IPsec SA and traffic will continue as before. You don't need to backup every packet or synchronize the replay counter for every packet. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Wade Sent: Friday, December 30, 2005 6:33 PM To: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net Subject: [Ipsec] is there any idea on ipsec HA? hello, The Ipsec high availability is one of requirement of people. Usually we use two security gateways, one acting as a master and another acting as a standby SG. I got a question on the packet sequence number, should the master SG send every packet to standby SG? The sequence number is used by anti-reply, if we don't bakeup it, when the master SG is halt for some reason the remote peer won't accept the packet which received from the backup SG because the packet SN won't pass the anti-reply checking mechanism. But to backup every packet is impossible, it's take too much throughput.. If we don't want to disable the anti-replay, is there any advice to solve this problem? Thanks Huide _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 01 15:52:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtABa-0005lZ-UC; Sun, 01 Jan 2006 15:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtABY-0005lJ-P8 for ipsec@megatron.ietf.org; Sun, 01 Jan 2006 15:52:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12296 for ; Sun, 1 Jan 2006 15:50:59 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtAGT-0007fp-Ud for ipsec@ietf.org; Sun, 01 Jan 2006 15:57:19 -0500 Received: by machshav.com (Postfix, from userid 512) id 8B7B3FB291; Sun, 1 Jan 2006 15:52:03 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B571FFB24A; Sun, 1 Jan 2006 15:51:58 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 866253C01D0; Sun, 1 Jan 2006 15:51:50 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: (Your message of "Thu, 29 Dec 2005 13:41:59 PST.") Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Jan 2006 15:51:50 -0500 Message-Id: <20060101205150.866253C01D0@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IPsec WG 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 , Paul Hoffman writes: >Greetings again. Some VPNC members have complained about having to >jump back and forth between the IKEv2 Clarifications document with >the IKEv2 RFC. At the same time, they also have said that they don't >like the SHOULDs in IKEv2 that have nothing to do with >interoperability. > >To that end, I have created a new document, for IKEv2.1. The first >draft is at >. >Its main purpose is to fix the above two problems, but it can also be >a springboard for needed core features that are not clarifications. >The version number is 2.1 because some of the normative requirements >(SHOULD and MUST) have changed. So far, there are no bits-on-the-wire >changes, although it is believable that some will be introduced (such >as new notifications) before the document is done. > >Of course, I am open to comments and suggestions on improving the >document. Given that we are starting to see IKEv2 implementations in >the market, it would be good to close this document within a few >months so that new implementers can go straight to version 2.1. > If we're going to reopen IKEv2, I think we should add hash and signature algorithm negotiation at the same time. --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 Jan 02 02:48:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKQk-0001NC-FY; Mon, 02 Jan 2006 02:48:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKQh-0001L3-QJ for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 02:48:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28630 for ; Mon, 2 Jan 2006 02:47:18 -0500 (EST) 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 1EtKVj-0006vi-CE for ipsec@ietf.org; Mon, 02 Jan 2006 02:53:43 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k027m4Gw008312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2006 09:48:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k027m3U8028022; Mon, 2 Jan 2006 09:48:03 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17336.55987.375237.679663@fireball.acr.fi> Date: Mon, 2 Jan 2006 09:48:03 +0200 From: Tero Kivinen To: "Yoav Nir" Subject: RE: [Ipsec] is there any idea on ipsec HA? In-Reply-To: <200601010804.k0184qAF000840@michael.checkpoint.com> References: <200601010804.k0184qAF000840@michael.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 9 min X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net 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 Yoav Nir writes: > If you're doing HA, you can have a single IKE SA, but a separate IPsec SA > for each security gateway. If you're using IKEv1, this will work with some > but not all of the peers. If you're using IKEv2, then allowing two parallel > SAs is required. > > Even if this is not allowed, when the failover happens, you can quickly > (using Quick Mode or Create-Child-SA) create an IPsec SA and traffic will > continue as before. You don't need to backup every packet or synchronize the > replay counter for every packet. For IKEv2 you need to synchronize all IKEv2 exchange data for every IKEv2 SA packet, as if the peer doing the negotiation crashes in the middle of the exchange, then the backup host needs to be able to complete that exchange. On the other hand IKE SA exchanges are much less frequent than IPsec packets, thus synchronizing those shouldn't be problem. There is also all kind of tricks you can do to make the syncronizing less frequent. If you are really doing HA system (i.e. no load balancing) then the easiest way is to make sure that backup node actually will see all same packets that the main system sees (i.e. it can keep up to date window for received packets), and for outgoing packets you simply need to skip far enough forward to make sure you do not reuse any sequence numbers already used by the main node (i.e. if you transmit last outgoing sequence number every 0.1 seconds from main node to backup node, and the link speed is 100 MBit/s, there can be at maximum 20000 packets sent out by the main node during that 0.1 second time, thus if you skip forward for example 1 000 000 that should make sure you do not reuse previous sequence numbers (provided you noticed the crash of main node in less than 50 seconds time). If you want to do load balancing, i.e. both nodes process packets all the time, and your normal load is high enough that you cannot process full stream of packets on one node, then you have to use much more complicated tricks (and most likely you need to have fast enough communications between the nodes to keep the reply window information in sync). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 02 02:51:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKTj-0003sF-TL; Mon, 02 Jan 2006 02:51:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKTh-0003pS-Jl for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 02:51:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29107 for ; Mon, 2 Jan 2006 02:50:25 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKYi-00073r-7I for ipsec@ietf.org; Mon, 02 Jan 2006 02:56:49 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k027pBAF026686 for ; Mon, 2 Jan 2006 09:51:11 +0200 (IST) Message-Id: <200601020751.k027pBAF026686@michael.checkpoint.com> From: "Yoav Nir" To: "'IPsec WG'" Subject: RE: [Ipsec] First draft of IKEv2.1 Date: Mon, 2 Jan 2006 09:51:10 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcYPFY4i5SMMCKrNSJuQzdRxkBfSFAAWShCw In-Reply-To: <20060101205150.866253C01D0@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit 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 And Re-Auth, and multiple EAP, and EAP-only authentication, and IKE over TCP (or SCTP) and lots of other stuff some people want. If we're reopening IKEv2, we need a new working group, and all issues can be re-opened. If it's just the clarifications, they can be published in a separate Best-Current-Practice RFC without any need for changing bits-on-the wire. Steven M. Bellovin said: > If we're going to reopen IKEv2, I think we should add hash and signature > algorithm negotiation at the same time. > > --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 Jan 02 03:53:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtLRD-00021X-Ka; Mon, 02 Jan 2006 03:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtLR6-0001t1-I1 for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 03:53:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04058 for ; Mon, 2 Jan 2006 03:51:47 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtLW7-0000J7-9M for ipsec@ietf.org; Mon, 02 Jan 2006 03:58:13 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4A17F898C6; Mon, 2 Jan 2006 10:52:44 +0200 (EET) Message-ID: <43B8E9FC.6060106@kolumbus.fi> Date: Mon, 02 Jan 2006 10:53:16 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir Subject: Re: [Ipsec] First draft of IKEv2.1 References: <200601020751.k027pBAF026686@michael.checkpoint.com> In-Reply-To: <200601020751.k027pBAF026686@michael.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: 'IPsec WG' 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 Yoav Nir wrote: >And Re-Auth, and multiple EAP, and EAP-only authentication, and IKE over TCP >(or SCTP) and lots of other stuff some people want. > >If we're reopening IKEv2, we need a new working group, and all issues can be >re-opened. > Indeed. But I have three comments; 1) Doing a new revision should not normally mean that "all" issues can be re-opened. Hopefully this is not the open season to redesign IKEv2 to suit whatever preferences some of us may have had. Sure, we can do clarifications, bug fixes, and also extensions. But lets not re-open all issues. 2) I'm getting increasingly convinced that it would be better to issue a clarifications RFC soon, and leave all new functionality to new documents. Not sure where Steven's hash negotiation belongs. You could reasonably call it a bug fix, too :-) 3) If there are new features I'd recommend getting a new WG and having a public discussion about the set of extensions we want. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 02 04:02:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtLaF-0008OE-3Q; Mon, 02 Jan 2006 04:02:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtLaA-0008Nn-Sq for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 04:02:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04835 for ; Mon, 2 Jan 2006 04:01:09 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtLfC-0000jd-9m for ipsec@ietf.org; Mon, 02 Jan 2006 04:07:35 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k02921AF014369; Mon, 2 Jan 2006 11:02:01 +0200 (IST) Message-Id: <200601020902.k02921AF014369@michael.checkpoint.com> From: "Yoav Nir" To: "'Jari Arkko'" Subject: RE: [Ipsec] First draft of IKEv2.1 Date: Mon, 2 Jan 2006 11:02:01 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcYPeeq3H/hq6N3CQfCkt+hu8rGEsQAALWjA In-Reply-To: <43B8E9FC.6060106@kolumbus.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: 'IPsec WG' 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 Jari Arkko wrote: > Indeed. But I have three comments; > > 1) Doing a new revision should not normally mean that > "all" issues can be re-opened. Hopefully this is not the > open season to redesign IKEv2 to suit whatever preferences > some of us may have had. Sure, we can do clarifications, > bug fixes, and also extensions. But lets not re-open all > issues. > > 2) I'm getting increasingly convinced that it would be better > to issue a clarifications RFC soon, and leave all new > functionality to new documents. Not sure where Steven's > hash negotiation belongs. You could reasonably call it > a bug fix, too :-) > > 3) If there are new features I'd recommend getting a new > WG and having a public discussion about the set of > extensions we want. > True. I think a new WG working on version 2.1 or 2.5 or 3.0 is inevitable, but in true IETF form, such a group will probably take 3-4 years to produce an RFC. If we're doing a new version, everything will have to be discussed again. The clarification document (or BCP) can be done and in the RFC Editor's queue in a couple of months, and not change any bits on the wire. That's the way I think we should go. Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 02 04:34:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtM52-0006Ys-3x; Mon, 02 Jan 2006 04:34:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtM50-0006Yk-5X for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 04:34:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06436 for ; Mon, 2 Jan 2006 04:33:01 -0500 (EST) 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 1EtMA2-0001Qm-5J for ipsec@ietf.org; Mon, 02 Jan 2006 04:39:27 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k029XufG003220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2006 11:33:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k029Xucu028814; Mon, 2 Jan 2006 11:33:56 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17336.62340.163143.648447@fireball.acr.fi> Date: Mon, 2 Jan 2006 11:33:56 +0200 From: Tero Kivinen To: "Yoav Nir" Subject: RE: [Ipsec] First draft of IKEv2.1 In-Reply-To: <200601020751.k027pBAF026686@michael.checkpoint.com> References: <20060101205150.866253C01D0@berkshire.machshav.com> <200601020751.k027pBAF026686@michael.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: 'IPsec WG' 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 Yoav Nir writes: > And Re-Auth, and multiple EAP, and EAP-only authentication, and IKE over TCP > (or SCTP) and lots of other stuff some people want. I am not sure we want to put all that to the IKEv2 base document. I think it might be better to have separate documents for those. > If we're reopening IKEv2, we need a new working group, and all issues can be > re-opened. If it's just the clarifications, they can be published in a > separate Best-Current-Practice RFC without any need for changing bits-on-the > wire. Actually if it is just clarifications, with no bits-on-the wire changes then we can probably just do the changes and aim for the next step on the standarization (i.e. issue new rfc that will be on the draft standard status instead of proposed standard). The old IKEv1 RFCs (rfc 2407-2409) are now obsoleted by the RFC 4306, so it would be good if we could start its way towards to full standard. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 02 05:30:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtMx6-0002Zs-Pc; Mon, 02 Jan 2006 05:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtMx3-0002Zf-MT for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 05:30:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11438 for ; Mon, 2 Jan 2006 05:28:52 -0500 (EST) 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 1EtN27-000335-6k for ipsec@ietf.org; Mon, 02 Jan 2006 05:35:19 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k02AT4kh013664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2006 12:29:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k02AT3tk014169; Mon, 2 Jan 2006 12:29:03 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17337.111.244474.161415@fireball.acr.fi> Date: Mon, 2 Jan 2006 12:29:03 +0200 From: Tero Kivinen To: "Steven M. Bellovin" Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: <20060101205150.866253C01D0@berkshire.machshav.com> References: <20060101205150.866253C01D0@berkshire.machshav.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 24 min X-Total-Time: 27 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: IPsec WG 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 Steven M. Bellovin writes: > If we're going to reopen IKEv2, I think we should add hash and signature > algorithm negotiation at the same time. What do you mean by hash algorithm negotiation? As far I as I know we do have that already in the IKEv2. We can negotiate PRFs and Integrity hash algorithms separately. We do use fixed hash-algorithms in few cases, but there is no real need for cryptographic hash-function for those cases (hash and URL, NAT-T etc). The only place where we do not negotiate hash functions is the case of certificates, i.e. the signature algorithm used when signing data is coming from the certificate (i.e. SHA-1 for the DSS, and most likely same signature algorithm than what was used to sign certificate for the RSA certificates). So what we might want to do we might want to explicitly say that the signature algorithm used for the RSA digitial signatures should be same than what was used to sign that certificate. How to negotiate signature algorithms used for certificate chains is more general problem than IKEv2 problem, and I am not sure what would be the best way to do that. We could for example fix this completely by using different CAs, i.e. we would have multiple overlapping hierarchies, where each public key is signed with multiple hash-algorithms using different top level CA certificates having different public keys. This way when the client sends out list of CAs it supports it would also express which hash-algorithms it supports (it supports the hash algorithm used by the top level CAs it lists, as otherwise he would not be able to verify those certificates from that hierarchy). I also think it is ok to expect that if the certificate chain validation supports certain signature algorithms the IKEv2 AUTH payload supports the same algorithms too, i.e. the IKEv2 and certificate library uses same signature verification routine. This does not say that the IKEv2 module supports same hash algorithm for example for the integrity algorith or for prf. Signature verification is more closely tied to the certificate validation than to the integrity verification or prf, thus it is safe to assume that all signature algorithm verifications use same set of algorithms. Anyways I think all this certificate chain problem is not really IKEv2 problem, but more generic PKIX problem, that needs to be fixed there first, and then we can fix it in IKEv2 based on the guidelines specified there. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 02 09:17:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtQUz-0001oF-OP; Mon, 02 Jan 2006 09:17:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtQUw-0001lo-JU for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 09:17:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03051 for ; Mon, 2 Jan 2006 09:16:05 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtQa1-0001Pl-7E for ipsec@ietf.org; Mon, 02 Jan 2006 09:22:34 -0500 Received: by machshav.com (Postfix, from userid 512) id 9ABBAFB28B; Mon, 2 Jan 2006 09:17:09 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E2D2DFB283; Mon, 2 Jan 2006 09:17:08 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 66F0A3C01E4; Mon, 2 Jan 2006 09:17:07 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Tero Kivinen Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: (Your message of "Mon, 02 Jan 2006 12:29:03 +0200.") <17337.111.244474.161415@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Jan 2006 09:17:07 -0500 Message-Id: <20060102141707.66F0A3C01E4@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IPsec WG 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 <17337.111.244474.161415@fireball.acr.fi>, Tero Kivinen writes: >Steven M. Bellovin writes: >> If we're going to reopen IKEv2, I think we should add hash and signature >> algorithm negotiation at the same time. > >What do you mean by hash algorithm negotiation? As far I as I know we >do have that already in the IKEv2. We can negotiate PRFs and Integrity >hash algorithms separately. We do use fixed hash-algorithms in few >cases, but there is no real need for cryptographic hash-function for >those cases (hash and URL, NAT-T etc). > >The only place where we do not negotiate hash functions is the case of >certificates, i.e. the signature algorithm used when signing data is >coming from the certificate (i.e. SHA-1 for the DSS, and most likely >same signature algorithm than what was used to sign certificate for >the RSA certificates). > I'm referring to the concerns raised in the paper by myself and ekr, on how to negotiate use of newer hash functions and signature algorithms for certificates. Briefly, the SAi1 and SAr1 messages need to contain optional payloads indicating what hash functions and signature algorithms are accepted. --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 Jan 02 10:02:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRCY-00077G-6x; Mon, 02 Jan 2006 10:02:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRCU-00074F-EI for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 10:02:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07664 for ; Mon, 2 Jan 2006 10:01:05 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtRHa-0002nY-5g for ipsec@ietf.org; Mon, 02 Jan 2006 10:07:34 -0500 Received: by zproxy.gmail.com with SMTP id o37so2983975nzf for ; Mon, 02 Jan 2006 07:02:14 -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=YwMA/Ma/nN84UYSrrQJsDukqaYVIYh8248Q5V0NYKLhcvI3ekNrGOXhnSKt7rM+sVu+KZ/rDc1kA37N1/B3weVA2ceRbY3Yv0ygjMrRj+YtWD3J9YEYb3erPg5cx8OWzwPMdwsTBUqDKtjUe6JL/r/2IcTzNZQJ6ge/EQzfvLnQ= Received: by 10.65.105.9 with SMTP id h9mr201847qbm; Mon, 02 Jan 2006 07:02:14 -0800 (PST) Received: by 10.64.220.6 with HTTP; Mon, 2 Jan 2006 07:02:14 -0800 (PST) Message-ID: Date: Mon, 2 Jan 2006 23:02:14 +0800 From: Huide Yin To: Yoav Nir Subject: Re: [Ipsec] is there any idea on ipsec HA? In-Reply-To: <200601010804.k0184qAF000840@michael.checkpoint.com> MIME-Version: 1.0 References: <200601010804.k0184qAF000840@michael.checkpoint.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net 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="===============0183648265==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0183648265== Content-Type: multipart/alternative; boundary="----=_Part_13482_33401743.1136214134458" ------=_Part_13482_33401743.1136214134458 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 1/1/06, Yoav Nir wrote: > > If you're doing HA, you can have a single IKE SA, but a separate IPsec SA > for each security gateway. If you're using IKEv1, this will work with > some > but not all of the peers. If you're using IKEv2, then allowing two > parallel > SAs is required. > > Even if this is not allowed, when the failover happens, you can quickly > (using Quick Mode or Create-Child-SA) create an IPsec SA and traffic will > continue as before. You don't need to backup every packet or synchronize > the > replay counter for every packet. Here, does you mean only backup the phase I SA is enough? so .. when the master SG broken down, we still need to re-negotiating the phase II SA = , that will take some time, at least we need the 3 message each side for quic= k mode exchange, and we should notify the remote peer to delete the old one of the Phase II and initiating the exchange, all of the must take some time... If the traffic is busy, this will cause many packets in the ipsec tunnel be droped... And for the "load share" the phase II SA is necessary, right? The 2 phases SA should be backed up, and may be the 32 packets anti-reply window can be used. Here is an idea on the SN processing, but I'm not sure it's feasibility: We can send the backup info only when the anti-reply checking reach the edge of window, that means we will send 1 backup info every 32 packets have been processed by Ipsec. So if the master halt, the backup SG can increase the SN counter and continue the packet forwarding... Huide ________________________________ > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Wade > Sent: Friday, December 30, 2005 6:33 PM > To: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net > Subject: [Ipsec] is there any idea on ipsec HA? > > > hello, > > The Ipsec high availability is one of requirement of people. Usually > we > use two security gateways, one acting as a master and another acting as a > standby SG. > I got a question on the packet sequence number, should the master SG > send every packet to standby SG? The sequence number is used by > anti-reply, > if we don't bakeup it, when the master SG is halt for some reason the > remote > peer won't accept the packet which received from the backup SG because th= e > packet SN won't pass the anti-reply checking mechanism. But to backup > every > packet is impossible, it's take too much throughput.. > > If we don't want to disable the anti-replay, is there any advice to > solve this problem? > > > Thanks > > Huide > > ------=_Part_13482_33401743.1136214134458 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

On 1/1/06, Y= oav Nir <ynir@checkpoint.com<= /a>> wrote: =20
If you're doing HA, you can have= a single IKE SA, but a separate IPsec SA
for each security gateway.&nbs= p; If you're using IKEv1, this will work with some=20
but not all of the peers. If you're using IKEv2, then allowing two para= llel
SAs is required.

Even if this is not allowed, when the failo= ver happens, you can quickly
(using Quick Mode or Create-Child-SA) creat= e an IPsec SA and traffic will=20
continue as before. You don't need to backup every packet or synchroniz= e the
replay counter for every packet.
 
    Here, does you mean only backup the phase I SA is e= nough?  so .. when the master SG broken down, we still need to re-nego= tiating the phase II SA , that will take some time, at least we need t= he 3 message each side for quick mode exchange,  and we should notify = the remote peer to delete the old one of the Phase II and initiating the ex= change, all of the must take some time... If the traffic is busy, this will= cause many packets in the ipsec tunnel be droped...=20
 
   And for the "load share" the phase II SA is nec= essary, right? The 2 phases SA should be backed up, and may be the 32 packe= ts anti-reply window can be used.
 
   Here is an idea on the SN processing, but I'm n= ot sure it's feasibility: We can send the backup info only&n= bsp;when the anti-reply checking reach the edge of window, that means = we will send 1 backup info every 32 packets have been processed by Ipsec.&n= bsp; So if the master halt, the backup SG can increase the SN counter = and continue the packet forwarding...=20
 
 
Huide
  
 

________________________________=

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
Wade
Sent: Friday, Decembe= r 30, 2005 6:33 PM
To: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net
Subject: [Ipsec] is there an= y idea on ipsec HA?


hello,

    The Ip= sec high availability is one of requirement of people. Usually we
use tw= o security gateways, one acting as a master and another acting as a=20
standby SG.
    I got a question on the packet s= equence number,  should the master SG
send every packet to sta= ndby SG? The sequence number is used by anti-reply,
if we don't bakeup i= t, when the master SG is halt for some reason the remote=20
peer won't accept the packet which received from the backup SG because = the
packet SN won't pass the anti-reply checking mechanism. But to backu= p every
packet is impossible, it's take too much throughput..

    If we don't want to disable the anti-replay, &= nbsp;is there any advice to
solve this problem?


Thanks
Huide


------=_Part_13482_33401743.1136214134458-- --===============0183648265== 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 --===============0183648265==-- From ipsec-bounces@ietf.org Mon Jan 02 10:36:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRjI-0007TE-8r; Mon, 02 Jan 2006 10:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRjF-0007NU-Gz for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 10:36:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11819 for ; Mon, 2 Jan 2006 10:34:56 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtRoL-0003wS-9d for ipsec@ietf.org; Mon, 02 Jan 2006 10:41:25 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k02FZuh1051437; Mon, 2 Jan 2006 07:35:57 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200601020751.k027pBAF026686@michael.checkpoint.com> References: <200601020751.k027pBAF026686@michael.checkpoint.com> Date: Mon, 2 Jan 2006 07:35:16 -0800 To: "Yoav Nir" , "'IPsec WG'" From: Paul Hoffman Subject: RE: [Ipsec] First draft of IKEv2.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 9:51 AM +0200 1/2/06, Yoav Nir wrote: >And Re-Auth, and multiple EAP, and EAP-only authentication, and IKE over TCP >(or SCTP) and lots of other stuff some people want. Serious question for the whole list, not just Yoav: why should those be in the base IKEvSomthing spec? Why should they not be extensions? Which are needed for a minimal useful IKE, and which are good for more capable IKEs? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 02 11:04:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSAa-0005ui-Rs; Mon, 02 Jan 2006 11:04:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSAY-0005uX-7t for ipsec@megatron.ietf.org; Mon, 02 Jan 2006 11:04:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14805 for ; Mon, 2 Jan 2006 11:03:08 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtSFe-0004sB-RQ for ipsec@ietf.org; Mon, 02 Jan 2006 11:09:39 -0500 Received: by zproxy.gmail.com with SMTP id 12so2534185nzp for ; Mon, 02 Jan 2006 08:04:21 -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=Ytnck/cD3ci2aR+MJYOL9TqRhGdU5VOONeYiK/aJR2LvQawR7/siak5X2i7x+fSLUQTwyH3K1gEpC4CdrR6FZLgpM69QLJmeGjm+t1F8+F9GRb6Oiq4Cyl/nlnBjTSXDWMn4CXTc6DP2wRf1+ImHoxcY68u9kX2nGM82uECRQTw= Received: by 10.65.96.13 with SMTP id y13mr206736qbl; Mon, 02 Jan 2006 08:04:21 -0800 (PST) Received: by 10.64.220.6 with HTTP; Mon, 2 Jan 2006 08:04:20 -0800 (PST) Message-ID: Date: Tue, 3 Jan 2006 00:04:20 +0800 From: Huide Yin To: Tero Kivinen Subject: Re: [Ipsec] is there any idea on ipsec HA? In-Reply-To: <17336.55987.375237.679663@fireball.acr.fi> MIME-Version: 1.0 References: <200601010804.k0184qAF000840@michael.checkpoint.com> <17336.55987.375237.679663@fireball.acr.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, Yoav Nir 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="===============2042793111==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2042793111== Content-Type: multipart/alternative; boundary="----=_Part_14394_21622770.1136217860994" ------=_Part_14394_21622770.1136217860994 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 1/2/06, Tero Kivinen wrote: > > For IKEv2 you need to synchronize all IKEv2 exchange data for every > IKEv2 SA packet, as if the peer doing the negotiation crashes in the > middle of the exchange, then the backup host needs to be able to > complete that exchange. > > On the other hand IKE SA exchanges are much less frequent than IPsec > packets, thus synchronizing those shouldn't be problem. > > There is also all kind of tricks you can do to make the syncronizing > less frequent. If you are really doing HA system (i.e. no load > balancing) then the easiest way is to make sure that backup node > actually will see all same packets that the main system sees (i.e. it > can keep up to date window for received packets), and for outgoing > packets you simply need to skip far enough forward to make sure you do > not reuse any sequence numbers already used by the main node (i.e. if > you transmit last outgoing sequence number every 0.1 seconds from main > node to backup node, and the link speed is 100 MBit/s, there can be at > maximum 20000 packets sent out by the main node during that 0.1 second > time, thus if you skip forward for example 1 000 000 that should make > sure you do not reuse previous sequence numbers (provided you noticed > the crash of main node in less than 50 seconds time). Is there any problem about this method? I think it can solve the packet's sequence number problem between master & standby SGs, but we must assume the maximum link speed between remote peer and HA group, right? ------=_Part_14394_21622770.1136217860994 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
On 1/2/06, T= ero Kivinen <kivinen@iki.fi>= ; wrote:

For IKEv2 you need to synchr= onize all IKEv2 exchange data for every
IKEv2 SA packet, as if the peer = doing the negotiation crashes in the
middle of the exchange, then the backup host needs to be able to
com= plete that exchange.

On the other hand IKE SA exchanges are much les= s frequent than IPsec
packets, thus synchronizing those shouldn't be pro= blem.

There is also all kind of tricks you can do to make the syncronizin= g
less frequent. If you are really doing HA system (i.e. no load
bala= ncing) then the easiest way is to make sure that backup node
actually wi= ll see all same packets that the main system sees ( i.e. it
can keep up to date window for received packets), and for outgoi= ng
packets you simply need to skip far enough forward to make sure you d= o
not reuse any sequence numbers already used by the main node (i.e. if
you transmit last outgoing sequence number every 0.1 seconds from main<= br>node to backup node, and the link speed is 100 MBit/s, there can be atmaximum 20000 packets sent out by the main node during that 0.1 second
time, thus if you skip forward for example 1 000 000 that should makesure you do not reuse previous sequence numbers (provided you noticed
= the crash of main node in less than 50 seconds time).
 
   Is there any problem about this method?  I think it = can solve the packet's sequence number problem between master & standby= SGs, but we must assume the maximum link speed  b= etween remote peer and HA group, right?
 

------=_Part_14394_21622770.1136217860994-- --===============2042793111== 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 --===============2042793111==-- From ipsec-bounces@ietf.org Tue Jan 03 04:38:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eticq-000583-Fo; Tue, 03 Jan 2006 04:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etick-00057k-Pv for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 04:38:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27787 for ; Tue, 3 Jan 2006 04:37:21 -0500 (EST) 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 1Etii0-0003rS-CB for ipsec@ietf.org; Tue, 03 Jan 2006 04:44:00 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k039biPf002960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 11:37:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k039bhoe005541; Tue, 3 Jan 2006 11:37:43 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17338.17895.476855.348810@fireball.acr.fi> Date: Tue, 3 Jan 2006 11:37:43 +0200 From: Tero Kivinen To: "Steven M. Bellovin" Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: <20060102141707.66F0A3C01E4@berkshire.machshav.com> References: <17337.111.244474.161415@fireball.acr.fi> <20060102141707.66F0A3C01E4@berkshire.machshav.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: IPsec WG 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 Steven M. Bellovin writes: > I'm referring to the concerns raised in the paper by myself and ekr, on > how to negotiate use of newer hash functions and signature algorithms > for certificates. Ok, so it is more of PKIX problem than IPsec problem. I always wondered why you listed IPsec as problematic in your paper, as for example with pre shared key or with EAP there is no hash problems in the IKEv2. The problem only occurs when using certificates. > Briefly, the SAi1 and SAr1 messages need to contain > optional payloads indicating what hash functions and signature > algorithms are accepted. I am not sure that is correct way to fix it. We do not need to select on hash function for the both directions, which happens if we put them to SA payloads. We need to announce to the other end what hash functions we accept and the other end will need to use one of those when selecting hash function for the RSA key signature. The problem is that regardless what we do if the other end does not have certificate signed with the supported hash function, we cannot get interoperability. On the other hand if the other hand has certificates signed with multiple hash functions they can use the certificate authority payload to select CAs with suitable hash functions. I do not think we want to modify SA payload because of this PKIX problem. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 04:46:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtikS-0007yL-BU; Tue, 03 Jan 2006 04:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtikP-0007vD-OR for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 04:46:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28540 for ; Tue, 3 Jan 2006 04:45:16 -0500 (EST) 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 1Etipf-000488-Im for ipsec@ietf.org; Tue, 03 Jan 2006 04:51:56 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k039kJAM025340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 11:46:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k039kH2U002224; Tue, 3 Jan 2006 11:46:17 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17338.18409.925566.130017@fireball.acr.fi> Date: Tue, 3 Jan 2006 11:46:17 +0200 From: Tero Kivinen To: Paul Hoffman Subject: RE: [Ipsec] First draft of IKEv2.1 In-Reply-To: References: <200601020751.k027pBAF026686@michael.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: 'IPsec WG' , Yoav Nir 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 Paul Hoffman writes: > At 9:51 AM +0200 1/2/06, Yoav Nir wrote: > >And Re-Auth, and multiple EAP, and EAP-only authentication, and IKE over TCP > >(or SCTP) and lots of other stuff some people want. > > Serious question for the whole list, not just Yoav: why should those > be in the base IKEvSomthing spec? Why should they not be extensions? I think at least Re-Auth, multiple EAP and EAP-only should all be extensions, not part of base IKEvX spec. IKE over TCP or SCTP is different, as I do not think we want those at all. The very simple IKE over TCP, where we simply say you use TCP stream to send IKE packets, and we do not try to recover from lost TCP streams is not really useful. On the other hand if we start to do complicated recovery / retranmission processing for the TCP over IKE, then we can ask what is the benefits for using TCP instead of UDP at all. > Which are needed for a minimal useful IKE, and which are good for > more capable IKEs? I think the base IKEv2 now already has the minimal useful set of features, and I do think that all extensions to it should be mostly done as extensions, not as part of base spec. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 04:58:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etivg-0006TV-K1; Tue, 03 Jan 2006 04:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etive-0006TQ-On for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 04:58:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29664 for ; Tue, 3 Jan 2006 04:56:53 -0500 (EST) 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 1Etj0u-0004Y8-M8 for ipsec@ietf.org; Tue, 03 Jan 2006 05:03:33 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k039vn0N006689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 11:57:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k039vmua026877; Tue, 3 Jan 2006 11:57:48 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17338.19100.880242.493719@fireball.acr.fi> Date: Tue, 3 Jan 2006 11:57:48 +0200 From: Tero Kivinen To: Huide Yin Subject: Re: [Ipsec] is there any idea on ipsec HA? In-Reply-To: References: <200601010804.k0184qAF000840@michael.checkpoint.com> <17336.55987.375237.679663@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, Yoav Nir 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 Huide Yin writes: > Is there any problem about this method? There are all kind of implementation problems with all of these methods, and you need to think of those and solve them when making implementation. I haven't really implemented full HA setup myself, so I cannot say if there is more problems that I missed with that approach, but I do know that some people have used that kind of method to implement HA setups. > I think it can solve the packet's sequence number problem between > master & standby SGs, but we must assume the maximum link speed > between remote peer and HA group, right? The actual amount of packets you jump forward does not really matter, so you can increment the outbound sequence number with large enough number when you notice the failure of the master node. I mean, you could also simply set it to 0xf0000000 or so, and immediately start rekey, and hope that the 0x0fffffff packets is enough for you to be able to finish the rekey (the actual values could depend on your setup). In that case you of course need to make sure that the sequence number never normally gets up to that big, i.e. start rekey normally when sequence number is around 0xe0000000 or so. There is also other kind of tricks you can do depending on your setup. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 10:02:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etng1-0002WT-Mw; Tue, 03 Jan 2006 10:02:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etnfz-0002WJ-LM for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 10:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03010 for ; Tue, 3 Jan 2006 10:01:02 -0500 (EST) Received: from smarthost167.mail.easynet.fr ([212.180.1.167] helo=caine.easynet.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtnlD-0005rR-3f for ipsec@ietf.org; Tue, 03 Jan 2006 10:07:44 -0500 Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by caine.easynet.fr with esmtp (Exim 4.50) id 1Etnfm-00003O-3z; Tue, 03 Jan 2006 16:02:02 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 5A5823F17; Tue, 3 Jan 2006 16:01:59 +0100 (CET) Date: Tue, 3 Jan 2006 16:01:59 +0100 From: VANHULLEBUS Yvan To: Wade Message-ID: <20060103150159.GA16969@zen.inc> References: <20051230195054.GA15632@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051230195054.GA15632@uk.tiscali.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net Subject: [Ipsec] Re: [Ipsec-tools-devel] is there any idea on ipsec HA? 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 (for moderators: once again, with my *good* address for ipsec@ietf. Sorry if the mail appears twice on some lists...) Looks this mail didn't reach ipsec@ietf mailing list (I'm not using the same mail adress for my subscriptions to both lists...), sending it again with the "good" email for this list (for "who moderates ipsec-tools-devel: discard this mail, already sent to the list...). On Fri, Dec 30, 2005 at 07:50:54PM +0000, Brian Candler wrote: [IPSec HA] > ipsec-tools is a package which negotiates keys and installs a SA - it does > not actually perform any ESP packet processing - so I'm not sure why you're > asking on the ipsec-tools-devel list. IPSec HA is a process which involves all layers, including racoon, if you want *real* and working HA. Let's guess you use a Linux / BSD kernel with racoon, and implement an IPSec SA tool to synchronize both kernels. When the active gate hangs up, negociated tunnels will continue to work.... But if you have NAT-T tunnels, you won't have anymore keepalives (done by racoon). If your peer have DPD enabled, you won't be able anymore to decrypt it's DPD requests (protected by the IKE SA), so your peer will quickly consider you're dead. And if you don't have DPD, and if your peers wand to negociate a new IPSec SA, it will probably try to negociate it through an existing IKE SA, which does NOT exists for you ! There are other problems (generated policies, etc...), which are more or less complex to solve. > If you want to have instant failover between a master and slave gateway, > then yes you will need to synchronise state between them. The two solutions > I'm aware of are OpenBSD (sasyncd/pfsync) and Cisco IOS (State > Synchronisation Protocol, SSP) Such solutions to synchronize IPSec SAs (I did not have a closer look on those solutions, I just *believe* they "just" synchronize IPSec SAs) are "instant failover", but will generate problems I just explained, at least for racoon + Linux / BSD solutions. > > If we don't want to disable the anti-replay, is there any advice > > to solve this problem? > > Since you didn't describe what sort of gateways you have, then no-one is > going to be able to advise you whether the feature you want is available for > them or not. A *perfect* IPSec HA solution does NOT depends on the gateways type, usage, peers, etc.... It just depends on the gate on which you wants to have HA, and as this was posted on ipsec-tools ML, I believe the answer is "ipsec-tools with Linux/BSD stack". Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 10:20:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtnxG-0006gt-DZ; Tue, 03 Jan 2006 10:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtnxD-0006ez-JN for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 10:20:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04969 for ; Tue, 3 Jan 2006 10:18:49 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eto2V-0006PB-ED for ipsec@ietf.org; Tue, 03 Jan 2006 10:25:32 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k03FJhIE010659; Tue, 3 Jan 2006 10:19:44 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 3 Jan 2006 10:18:07 -0500 To: Wade From: Stephen Kent Subject: Re: [Ipsec] is there any idea on ipsec HA? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net 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 12:33 AM +0800 12/31/05, Wade wrote: >hello, > > The Ipsec high availability is one of requirement of people. >Usually we use two security gateways, one acting as a master and >another acting as a standby SG. > I got a question on the packet sequence number, should the >master SG send every packet to standby SG? The sequence number is >used by anti-reply, if we don't bakeup it, when the master SG is >halt for some reason the remote peer won't accept the packet which >received from the backup SG because the packet SN won't pass the >anti-reply checking mechanism. But to backup every packet is >impossible, it's take too much throughput.. > > If we don't want to disable the anti-replay, is there any >advice to solve this problem? > > >Thanks > >Huide To mirror an SA on two devices requires sharing a lot of state, including keys. In general, making provisions to share the SA keys may create vulnerabilities. Only if you can avoid such vulnerabilities does it make sense to pursue the sort of tricks Tero suggests. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 10:32:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eto9c-0001Qq-4Y; Tue, 03 Jan 2006 10:32:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eto9Z-0001QG-TM for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 10:32:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06282 for ; Tue, 3 Jan 2006 10:31:36 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtoEr-0006no-PU for ipsec@ietf.org; Tue, 03 Jan 2006 10:38:19 -0500 Received: by machshav.com (Postfix, from userid 512) id 61E48FB284; Tue, 3 Jan 2006 10:32:41 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 657A4FB27C; Tue, 3 Jan 2006 10:32:40 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 363003C016A; Tue, 3 Jan 2006 10:32:39 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Tero Kivinen Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: (Your message of "Tue, 03 Jan 2006 11:37:43 +0200.") <17338.17895.476855.348810@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jan 2006 10:32:39 -0500 Message-Id: <20060103153239.363003C016A@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IPsec WG 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 <17338.17895.476855.348810@fireball.acr.fi>, Tero Kivinen writes: >Steven M. Bellovin writes: >> I'm referring to the concerns raised in the paper by myself and ekr, on >> how to negotiate use of newer hash functions and signature algorithms >> for certificates. > >Ok, so it is more of PKIX problem than IPsec problem. I always >wondered why you listed IPsec as problematic in your paper, as for >example with pre shared key or with EAP there is no hash problems in >the IKEv2. > >The problem only occurs when using certificates. > >> Briefly, the SAi1 and SAr1 messages need to contain >> optional payloads indicating what hash functions and signature >> algorithms are accepted. > >I am not sure that is correct way to fix it. We do not need to select >on hash function for the both directions, which happens if we put them >to SA payloads. We need to announce to the other end what hash >functions we accept and the other end will need to use one of those >when selecting hash function for the RSA key signature. > >The problem is that regardless what we do if the other end does not >have certificate signed with the supported hash function, we cannot >get interoperability. On the other hand if the other hand has >certificates signed with multiple hash functions they can use the >certificate authority payload to select CAs with suitable hash >functions. > >I do not think we want to modify SA payload because of this PKIX >problem. >-- No, it is not a PKIX problem, it is an IKE problem when certificates are used. Your note is dancing around the problem; I'll put it in concrete terms. Suppose that either the initiator or the responder has RSA-MD5, RSA-SHA256, and ECC-SHA256 certificates. Which should be used? I agree, of course, that PKIX needs to define those certificate types if they're not already defined; that's quite different than saying what can be used in any given protocol. For that matter, I'm not at all convinced that EAP and shared secret are safe. Clearly, today's collision attacks don't cause problems. Would a sufficiently powerful preimage attack be a threat? That's much less clear. --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 Tue Jan 03 11:19:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etot7-0006Si-UB; Tue, 03 Jan 2006 11:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etot5-0006S6-Aj for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 11:19:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16892 for ; Tue, 3 Jan 2006 11:18:37 -0500 (EST) 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 1EtoyO-0000iz-DX for ipsec@ietf.org; Tue, 03 Jan 2006 11:25:20 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03GJ1jh006748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 18:19:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03GJ1UN008110; Tue, 3 Jan 2006 18:19:01 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17338.41973.141018.260606@fireball.acr.fi> Date: Tue, 3 Jan 2006 18:19:01 +0200 From: Tero Kivinen To: "Steven M. Bellovin" Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: <20060103153239.363003C016A@berkshire.machshav.com> References: <17338.17895.476855.348810@fireball.acr.fi> <20060103153239.363003C016A@berkshire.machshav.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: IPsec WG 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 Steven M. Bellovin writes: > No, it is not a PKIX problem, it is an IKE problem when certificates > are used. There is no way of knowing whether the other end can parse your chain, as he might have different set of certificates and certificate roots that you have. I.e. even when you have certificate chain from CA1 through Intermediate CA2 to end certificate CERT1, that does not mean that other end has the exact same chain. He could have same CA1, but could have newer intermediate CA2, which uses different hash algorithm, and then another end entity certificate CERT2 for the exact same private and public key for of the node. Even when host A can verify that path does not have any unsupported hash algorithms, that might not be true for the other end. There is nothing IPsec or IKE can really do there, unless it defines that chains are not used, or if they are used, they must be transmitted completely inside the IKE. > Your note is dancing around the problem; I'll put it in > concrete terms. Suppose that either the initiator or the responder has > RSA-MD5, RSA-SHA256, and ECC-SHA256 certificates. Which should be used? If the other end has sent out certificate request for the top level CA, and that top level CA has a hash-algorithm statement saying that this CA hierarchy is supporting RSA-SHA1, RSA-SHA256 or RSA-SHA512 certificates (there is no such extension yet), then he would be selecting RSA-SHA256. Currently there is no such thing to tell in the PKIX certificates. > I agree, of course, that PKIX needs to define those certificate types > if they're not already defined; that's quite different than saying what > can be used in any given protocol. I think there is signature algorithms already there, but that still does not mean that we can say anything about the intermediate certificates the other end might see during the validation process. Or the signature algorithms used for the CRLs etc. > For that matter, I'm not at all convinced that EAP and shared secret > are safe. Clearly, today's collision attacks don't cause problems. > Would a sufficiently powerful preimage attack be a threat? That's much > less clear. If HMAC is not safe, then I think we have much bigger problems than what we have with IKEv2. And we do already have AES128_XCBC as prf and integrity algorithm defined for the IKEv2, thus I do not think there is problem with EAP and HMAC or AES128_XCBC use in there. Hmm.. actually just noticed that the EAP and shared keys are not allowed in IKEv2: ---------------------------------------------------------------------- 2.16. Extensible Authentication Protocol Methods ... For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. ---------------------------------------------------------------------- That is one MUST that quite a few implementors in the last interop didn't follow. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 11:41:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpE7-00032p-7j; Tue, 03 Jan 2006 11:41:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpE5-00032k-Qm for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 11:41:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20759 for ; Tue, 3 Jan 2006 11:40:19 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtpJO-0001lR-6O for ipsec@ietf.org; Tue, 03 Jan 2006 11:47:03 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k03GfPBo023144 for ; Tue, 3 Jan 2006 08:41:26 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060103153239.363003C016A@berkshire.machshav.com> <17338.17895.476855.348810@fireball.acr.fi> References: <20060103153239.363003C016A@berkshire.machshav.com> <17337.111.244474.161415@fireball.acr.fi> <20060102141707.66F0A3C01E4@berkshire.machshav.com> <17338.17895.476855.348810@fireball.acr.fi> Date: Tue, 3 Jan 2006 08:38:49 -0800 To: IPsec WG From: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 11:37 AM +0200 1/3/06, Tero Kivinen wrote: >The problem is that regardless what we do if the other end does not >have certificate signed with the supported hash function, we cannot >get interoperability. Yes. >On the other hand if the other hand has >certificates signed with multiple hash functions they can use the >certificate authority payload to select CAs with suitable hash >functions. No. It is explicitly allowed that a trust anchor can sign its own key with one algorithm, but issue certificates that are signed with different algorithms. At 10:32 AM -0500 1/3/06, Steven M. Bellovin wrote: >Suppose that either the initiator or the responder has >RSA-MD5, RSA-SHA256, and ECC-SHA256 certificates. Which should be used? Simple: any of the ones that chain to any of the trust anchors given in the CERTREQ payload that was received, as long as the side receiving the certificate can validate it. It is the latter part that we don't have today. A simple extension (not part of the IKEv2 core) that would solve this: a vendor ID that says which certificate types beyond the required ones you can interpret. You add this to the message that has the CERTREQ in it. There is no need to make this a *negotiated* item, simply an announcement. Adding it to the negotiation will reduce interoperability (because we now have a new negotiated item), and will not get the two parties any further than a simple announcement. Do folks agree with this thought? If so, I can whip up a short Internet Draft on the extension. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 11:55:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpRZ-0005MQ-KK; Tue, 03 Jan 2006 11:55:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpRX-0005M6-6g for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 11:55:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22574 for ; Tue, 3 Jan 2006 11:54:12 -0500 (EST) 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 1EtpWq-0002DP-CF for ipsec@ietf.org; Tue, 03 Jan 2006 12:00:56 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03GtDKW002795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 18:55:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03GtDVQ028224; Tue, 3 Jan 2006 18:55:13 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17338.44145.112526.318162@fireball.acr.fi> Date: Tue, 3 Jan 2006 18:55:13 +0200 From: Tero Kivinen To: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: References: <20060103153239.363003C016A@berkshire.machshav.com> <17337.111.244474.161415@fireball.acr.fi> <20060102141707.66F0A3C01E4@berkshire.machshav.com> <17338.17895.476855.348810@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IPsec WG 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 Paul Hoffman writes: > A simple extension (not part of the IKEv2 core) that would solve > this: a vendor ID that says which certificate types beyond the > required ones you can interpret. You add this to the message that has > the CERTREQ in it. You do assume that both ends do see exactly same set of certificates in their hierarchies. I.e. what happens if the host A has certificate hierarchy using intermediate CA signed with SHA1, and that is acceptable to B. But when B goes and fetches that intermediate certificate from the LDAP repository there is already new version of it that is now signed with the SHA-256, as the signer of that CA decided to start reissuing intermediate CA certificates with stronger hash. Now B cannot validate the path, but A do think he should be able to validate the path. A might not refetch the intermediate CA for long time (years) as the old one is not revoced and it has long lifetime. > There is no need to make this a *negotiated* item, simply an > announcement. Adding it to the negotiation will reduce > interoperability (because we now have a new negotiated item), and > will not get the two parties any further than a simple announcement. True. > Do folks agree with this thought? If so, I can whip up a short > Internet Draft on the extension. If you make that kind of draft, use status notification instead of vendor ID. We are already using status notifications for this kind of announcements (IPcomp, transport/tunnel etc). In any case it does not solve the problem, as we cannot solve it without restricting what CAs can do. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 11:57:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpTv-00067C-AV; Tue, 03 Jan 2006 11:57:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtpTu-000677-1C for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 11:57:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22944 for ; Tue, 3 Jan 2006 11:56:39 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtpZC-0002JQ-Iy for ipsec@ietf.org; Tue, 03 Jan 2006 12:03:23 -0500 Received: by machshav.com (Postfix, from userid 512) id 25C0DFB282; Tue, 3 Jan 2006 11:57:47 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3637EFB24F; Tue, 3 Jan 2006 11:57:46 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 0E6AD3C016A; Tue, 3 Jan 2006 11:57:45 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: (Your message of "Tue, 03 Jan 2006 08:38:49 PST.") Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jan 2006 11:57:45 -0500 Message-Id: <20060103165745.0E6AD3C016A@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IPsec WG 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 , Paul Hoffman writes: > >At 10:32 AM -0500 1/3/06, Steven M. Bellovin wrote: >>Suppose that either the initiator or the responder has >>RSA-MD5, RSA-SHA256, and ECC-SHA256 certificates. Which should be used? > >Simple: any of the ones that chain to any of the trust anchors given >in the CERTREQ payload that was received, as long as the side >receiving the certificate can validate it. It is the latter part that >we don't have today. > >A simple extension (not part of the IKEv2 core) that would solve >this: a vendor ID that says which certificate types beyond the >required ones you can interpret. You add this to the message that has >the CERTREQ in it. > >There is no need to make this a *negotiated* item, simply an >announcement. Adding it to the negotiation will reduce >interoperability (because we now have a new negotiated item), and >will not get the two parties any further than a simple announcement. I agree that it's an announcement and not a negotiation. > >Do folks agree with this thought? If so, I can whip up a short >Internet Draft on the extension. > I very much disagree with using vendor IDs -- that's a hack that doesn't scale very well. Let's be explicit about what we're announcing. --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 Tue Jan 03 12:15:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etpl3-000222-2J; Tue, 03 Jan 2006 12:15:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etpl1-00021s-NG for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 12:15:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25206 for ; Tue, 3 Jan 2006 12:14:21 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtpqL-0002yZ-HB for ipsec@ietf.org; Tue, 03 Jan 2006 12:21:05 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k03HFTmK025773; Tue, 3 Jan 2006 09:15:29 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17338.44145.112526.318162@fireball.acr.fi> References: <20060103153239.363003C016A@berkshire.machshav.com> <17337.111.244474.161415@fireball.acr.fi> <20060102141707.66F0A3C01E4@berkshire.machshav.com> <17338.17895.476855.348810@fireball.acr.fi> <17338.44145.112526.318162@fireball.acr.fi> Date: Tue, 3 Jan 2006 09:15:30 -0800 To: Tero Kivinen From: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IPsec WG 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 6:55 PM +0200 1/3/06, Tero Kivinen wrote: >Paul Hoffman writes: >> A simple extension (not part of the IKEv2 core) that would solve >> this: a vendor ID that says which certificate types beyond the >> required ones you can interpret. You add this to the message that has >> the CERTREQ in it. > >You do assume that both ends do see exactly same set of certificates >in their hierarchies. I.e. what happens if the host A has certificate >hierarchy using intermediate CA signed with SHA1, and that is >acceptable to B. But when B goes and fetches that intermediate >certificate from the LDAP repository there is already new version of >it that is now signed with the SHA-256, as the signer of that CA >decided to start reissuing intermediate CA certificates with stronger >hash. Now B cannot validate the path, but A do think he should be able >to validate the path. A might not refetch the intermediate CA for long >time (years) as the old one is not revoced and it has long lifetime. All true, but not relevant here. Restricting chains or eliminating chains for PKI4IPSEC, not IKEv2. >If you make that kind of draft, use status notification instead of >vendor ID. We are already using status notifications for this kind of >announcements (IPcomp, transport/tunnel etc). Gaaah, of course. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 12:37:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etq6F-0006bp-23; Tue, 03 Jan 2006 12:37:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etq6D-0006ay-5E for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 12:37:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28114 for ; Tue, 3 Jan 2006 12:36:14 -0500 (EST) 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 1EtqBU-0003pH-3U for ipsec@ietf.org; Tue, 03 Jan 2006 12:42:59 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03HbIo6026131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 19:37:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03HbIua023934; Tue, 3 Jan 2006 19:37:18 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17338.46670.67223.305523@fireball.acr.fi> Date: Tue, 3 Jan 2006 19:37:18 +0200 From: Tero Kivinen To: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: References: <20060103153239.363003C016A@berkshire.machshav.com> <17337.111.244474.161415@fireball.acr.fi> <20060102141707.66F0A3C01E4@berkshire.machshav.com> <17338.17895.476855.348810@fireball.acr.fi> <17338.44145.112526.318162@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: IPsec WG 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 Paul Hoffman writes: > All true, but not relevant here. Restricting chains or eliminating > chains for PKI4IPSEC, not IKEv2. So shouldn't the whole problem then belong to the PKI4IPSEC group? I mean what does it help if we do partial solution which does not solve the problem itself, but simply moves it a bit to the one direction. Of course if you plan to say that PKI4IPSEC will be saying: CA MUST use exactly one signature algorithm for all intermediate certificates, CRLs, and end entity certificates inside its hierarchy, then this notification will fix the problem. Before we see that in the PKI4IPSEC we do not know whether the notification will fix the problem or simply make it less frequent. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 13:29:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtquQ-0000Cy-ND; Tue, 03 Jan 2006 13:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtquP-0000Bq-Bs for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 13:29:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07586 for ; Tue, 3 Jan 2006 13:28:06 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etqzh-0005x9-Q8 for ipsec@ietf.org; Tue, 03 Jan 2006 13:34:52 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k03ITCZ4032530; Tue, 3 Jan 2006 10:29:12 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17338.46670.67223.305523@fireball.acr.fi> References: <20060103153239.363003C016A@berkshire.machshav.com> <17337.111.244474.161415@fireball.acr.fi> <20060102141707.66F0A3C01E4@berkshire.machshav.com> <17338.17895.476855.348810@fireball.acr.fi> <17338.44145.112526.318162@fireball.acr.fi> <17338.46670.67223.305523@fireball.acr.fi> Date: Tue, 3 Jan 2006 10:29:14 -0800 To: Tero Kivinen From: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IPsec WG 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 7:37 PM +0200 1/3/06, Tero Kivinen wrote: >Paul Hoffman writes: >> All true, but not relevant here. Restricting chains or eliminating >> chains for PKI4IPSEC, not IKEv2. > >So shouldn't the whole problem then belong to the PKI4IPSEC group? No. > I >mean what does it help if we do partial solution which does not solve >the problem itself, but simply moves it a bit to the one direction. The proposal (notify the other end which signature algorithms you can valdiate) solves the problem for everyone who does not use chains. This is probably at least 90% of the users of certificates in IPsec. >Of course if you plan to say that PKI4IPSEC will be saying: CA MUST >use exactly one signature algorithm for all intermediate certificates, >CRLs, and end entity certificates inside its hierarchy, then this >notification will fix the problem. Yes, and if the CA doesn't have chains, this notification fixes the problem. And if the CA has chains that only use the algorithms used in the notification, this fixes the problem. The only problem not fixed is a CA who allows multiple algorithms in the chain that the user cannot resolve. That is no different with or without the notification. >Before we see that in the PKI4IPSEC we do not know whether the >notification will fix the problem or simply make it less frequent. Two things: - The main document for PKI4IPSEC is now in WG last call there. If you are concerned with what it says, this is a very good time to read it and comment. - Less frequent is good. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 13:36:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etr0s-0001Bz-75; Tue, 03 Jan 2006 13:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etr0r-0001Bt-6b for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 13:36:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08628 for ; Tue, 3 Jan 2006 13:34:46 -0500 (EST) 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 1Etr69-0006CG-4b for ipsec@ietf.org; Tue, 03 Jan 2006 13:41:32 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k03IZpWb000892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2006 20:35:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k03IZpH7005819; Tue, 3 Jan 2006 20:35:51 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17338.50183.24940.941649@fireball.acr.fi> Date: Tue, 3 Jan 2006 20:35:51 +0200 From: Tero Kivinen To: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 In-Reply-To: References: <20060103153239.363003C016A@berkshire.machshav.com> <17337.111.244474.161415@fireball.acr.fi> <20060102141707.66F0A3C01E4@berkshire.machshav.com> <17338.17895.476855.348810@fireball.acr.fi> <17338.44145.112526.318162@fireball.acr.fi> <17338.46670.67223.305523@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: IPsec WG 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 Paul Hoffman writes: > The proposal (notify the other end which signature algorithms you can > valdiate) solves the problem for everyone who does not use chains. > This is probably at least 90% of the users of certificates in IPsec. It does not solve the problem if CRLs are used, as they can again use different algorithm, especially if the other end uses OCSP or something else and the other end CRLs. Actually if we limit ourselves to hierarchy where we have CA cert, end entity cert and the CRL all signed with same hash algorith, then we do not need to anything for IKEv2. The negotiation happens automatically by selecting the right CA. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 13:47:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrCH-0004DQ-Md; Tue, 03 Jan 2006 13:47:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrCF-0004DH-Pi for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 13:47:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10726 for ; Tue, 3 Jan 2006 13:46:32 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtrHW-0006hR-S4 for ipsec@ietf.org; Tue, 03 Jan 2006 13:53:18 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k03Ih0IG023679; Tue, 3 Jan 2006 13:43:01 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <17338.41973.141018.260606@fireball.acr.fi> References: <17338.17895.476855.348810@fireball.acr.fi> <20060103153239.363003C016A@berkshire.machshav.com> <17338.41973.141018.260606@fireball.acr.fi> Date: Tue, 3 Jan 2006 13:34:43 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: [Ipsec] First draft of IKEv2.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IPsec WG , "Steven M. Bellovin" 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 A CA might support more than one hash and/or signature algorithm. Although this is rare today, it may be more common as CAs transition to new hash algorithms in the future. The primary problem is discovering which certs have been issued by a CA under more than one algorithm, i.e., to detect when there is a choice. This has generally been viewed as a directory search problem, rather than a problem to be addressed via an extension. We do have an exception to this general rule: a new I-D in the S/MIME WG: smime-certcapa-05.txt. This extension defines a way for a cert to advertise the (S/MIME) crypto capabilities for an S/MIME recipient. So, one could argue that an analogous extension in a CA cert could be used to advertise the cert/CRL algorithm capabilities of a CA, as a hint to request certs or CRLs using other algorithms, either from a peer or from a directory. If one adopted this approach, then the solution might be viewed as a PKIX issue rather than an IPsec issue. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 03 16:22:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EttcA-0001Hz-4x; Tue, 03 Jan 2006 16:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ettc8-0001Gb-9A for ipsec@megatron.ietf.org; Tue, 03 Jan 2006 16:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11199 for ; Tue, 3 Jan 2006 16:21:24 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtthQ-0007TT-9w for ipsec@ietf.org; Tue, 03 Jan 2006 16:28:08 -0500 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k03LMXuf011375 for ; Tue, 3 Jan 2006 14:22:33 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k03LMW30003763 for ; Tue, 3 Jan 2006 14:22:33 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k03LMWT1002900; Tue, 3 Jan 2006 15:22:32 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k03LMVk8002899; Tue, 3 Jan 2006 15:22:31 -0600 (CST) Date: Tue, 3 Jan 2006 15:22:31 -0600 From: Nicolas Williams To: Tero Kivinen Subject: Re: [Ipsec] First draft of IKEv2.1 Message-ID: <20060103212230.GN18698@binky.Central.Sun.COM> Mail-Followup-To: Tero Kivinen , "Steven M. Bellovin" , IPsec WG References: <17338.17895.476855.348810@fireball.acr.fi> <20060103153239.363003C016A@berkshire.machshav.com> <17338.41973.141018.260606@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17338.41973.141018.260606@fireball.acr.fi> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IPsec WG , "Steven M. Bellovin" 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 Tue, Jan 03, 2006 at 06:19:01PM +0200, Tero Kivinen wrote: > Steven M. Bellovin writes: > > No, it is not a PKIX problem, it is an IKE problem when certificates > > are used. > > There is no way of knowing whether the other end can parse your chain, > as he might have different set of certificates and certificate roots > that you have. I.e. even when you have certificate chain from CA1 > through Intermediate CA2 to end certificate CERT1, that does not mean > that other end has the exact same chain. He could have same CA1, but > could have newer intermediate CA2, which uses different hash > algorithm, and then another end entity certificate CERT2 for the exact > same private and public key for of the node. > > Even when host A can verify that path does not have any unsupported > hash algorithms, that might not be true for the other end. There is > nothing IPsec or IKE can really do there, unless it defines that > chains are not used, or if they are used, they must be transmitted > completely inside the IKE. So, the cert paths are not the real issue here. The real issue is having the ability to migrate from one algorithm to another, where "migrate" != "flag day." Eventually one would like to end the migration by dropping support for legacy algorithms, which means no longer "interoperating" with peers that were not updated in a timely fashion. I think you're right though that the SA payloads are the wrong place to fix the problem since the SA payload "is used to negotiate attributes of a security association" whereas what we want is to negotiate selection of certs used to authenticate the peers in IKEv2. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 04 04:25:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu4tR-0002iQ-7q; Wed, 04 Jan 2006 04:25:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu4tP-0002gN-1x; Wed, 04 Jan 2006 04:25:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02127; Wed, 4 Jan 2006 04:24:01 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu4yq-0007lK-6F; Wed, 04 Jan 2006 04:30:53 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k049KsRX008573; Wed, 4 Jan 2006 11:20:58 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 11:25:10 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jan 2006 11:25:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jan 2006 11:25:10 +0200 Message-ID: Thread-Topic: Last call comments about "Repeated Authentication in IKEv2" Thread-Index: AcYREMKT4WFgsDPjSAWeFuAytOPDDg== To: X-OriginalArrivalTime: 04 Jan 2006 09:25:09.0453 (UTC) FILETIME=[C1C267D0:01C61110] X-Spam-Score: 0.4 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: [Ipsec] Last call comments about "Repeated Authentication in IKEv2" 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 1) Overall: Being able to reauthenticate the client (either periodically or by some other trigger) is a common requirement in remote access deployments. It's a good idea to have one documented way to do this, instead of each vendor inventing its own proprietary payloads. Thus, I think this document is a very useful extension to IKEv2, and deserves to be published. 2) The document could be more precise about in describing what messages can contain the AUTH_LIFETIME notification. The intent was clearly "in the last IKE_AUTH response or in any INFORMATIONAL request", but this is not exactly the same as saying "in a separate Informational exchange" (which might be interpreted as including both the request and response messages) or "MAY be sent by the original Responder at any time". 3) Section 2: "It is recommended that an INITIAL-CONTACT notification be included in the AUTH exchange."=20 This is probably not correct. RFC4306 says that "This notification MUST NOT be sent by an entity that may be replicated (e.g., a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time)." Even if the corporate IT department has decided not to allow this, the initiator probably does not know this, so it should not include the notification.=20 Furthermore, the INITIAL_CONTACT notification is not really needed=20 for anything in this case, since the client has not crashed, and it still has all the information it needs to properly close=20 the old IKE_SA (once the new one has been established). 4) Section 7 (IANA Considerations): The text should say that the number needs to be assigned from the "Status Types" range (and not the "Error Types" part) 5) Typos etc. Section 2: the Informational response should be "HDR, SK{}"=20 Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/ Section 6, should explicitly say that both references are normative Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 04 05:03:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu5Ur-0002Lj-Cz; Wed, 04 Jan 2006 05:03:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu5Up-0002LV-Bv; Wed, 04 Jan 2006 05:03:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07000; Wed, 4 Jan 2006 05:02:40 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu5aG-0000tN-5z; Wed, 04 Jan 2006 05:09:33 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k04A3XY9024169; Wed, 4 Jan 2006 12:03:33 +0200 (IST) Message-Id: <200601041003.k04A3XY9024169@michael.checkpoint.com> From: "Yoav Nir" To: , Subject: RE: [Ipsec] Last call comments about "Repeated Authentication in IKEv2" Date: Wed, 4 Jan 2006 12:03:33 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYREMKT4WFgsDPjSAWeFuAytOPDDgABDrew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Comments inline > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Pasi.Eronen@nokia.com > > 1) Overall: Being able to reauthenticate the client (either > periodically or by some other trigger) is a common requirement in > remote access deployments. It's a good idea to have one documented > way to do this, instead of each vendor inventing its own proprietary > payloads. Thus, I think this document is a very useful extension to > IKEv2, and deserves to be published. > > 2) The document could be more precise about in describing what > messages can contain the AUTH_LIFETIME notification. The intent was > clearly "in the last IKE_AUTH response or in any INFORMATIONAL > request", but this is not exactly the same as saying "in a separate > Informational exchange" (which might be interpreted as including > both the request and response messages) or "MAY be sent by the > original Responder at any time". You're right about the former, but I think the latter needs to stay. It refers to the timing of sending the message. > 3) Section 2: "It is recommended that an INITIAL-CONTACT > notification be included in the AUTH exchange." > > This is probably not correct. RFC4306 says that "This notification > MUST NOT be sent by an entity that may be replicated (e.g., a > roaming user's credentials where the user is allowed to connect to > the corporate firewall from two remote systems at the same time)." > > Even if the corporate IT department has decided not to allow this, > the initiator probably does not know this, so it should not include > the notification. > > Furthermore, the INITIAL_CONTACT notification is not really needed > for anything in this case, since the client has not crashed, > and it still has all the information it needs to properly close > the old IKE_SA (once the new one has been established). I thought INITIAL_CONTACT would be a shorter way to achieve the same goal, but I forgot about the replication problem. I agree. This line must go. > 4) Section 7 (IANA Considerations): The text should say that the > number needs to be assigned from the "Status Types" range (and not > the "Error Types" part) Well, if and when this is published, This would change to a specific, allocated number. I did write this in the IANA application. > 5) Typos etc. > Section 2: the Informational response should be "HDR, SK{}" > Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/ > Section 6, should explicitly say that both references are normative Agreed. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 08 23:04:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvoGw-000528-Fh; Sun, 08 Jan 2006 23:04:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvoGu-00051u-L9 for ipsec@megatron.ietf.org; Sun, 08 Jan 2006 23:04:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11921 for ; Sun, 8 Jan 2006 23:03:21 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvoNJ-0006c0-JM for ipsec@ietf.org; Sun, 08 Jan 2006 23:11:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 8 Jan 2006 20:04:29 -0800 Message-ID: Thread-Topic: Discrepency RFC4301 and RFC4305 Thread-Index: AcYU0pafy2RJZlLbTiOhqW5X9ySukA== From: "Vishwas Manral" To: "IPsec" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Subject: [Ipsec] Discrepency RFC4301 and RFC4305 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="===============1486554665==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1486554665== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C614D1.CA0C5D20" This is a multi-part message in MIME format. ------_=_NextPart_001_01C614D1.CA0C5D20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 I had brought out the issue more then a year back that: =20 RFC4301 states - confidentiality-only (MAY be supported) - integrity only (MUST be supported) - confidentiality and integrity (MUST be supported) =20 However RFC4305 states that NULL authentication support is a MUST. =20 I had brought out the issue with the draft which became RFC4305. Stephen Kent had supported the change and stated=20 "since we changed the requirements for encryption-only support in this round of document revisions, I think a SHOULD here is correct." http://130.230.52.14/list-archive/ipsec/msg05576.html =20 however Donald Eastlake had stated @@@ I think draft-ietf-ipsec-esp-v3-09 should be changed. http://130.230.52.14/list-archive/ipsec/msg05578.html =20 The issue never got resolved and we now have this discrepancy in the RFC's. Should I send an errata for RFC4305 regarding the same? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C614D1.CA0C5D20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

I had brought out the issue more then a year back = that:

 

RFC4301 = states

            - confidentiality-only (MAY be supported)

            - integrity only (MUST be supported)

            - confidentiality and integrity (MUST be = supported)

 

However RFC4305 states that NULL authentication = support is a MUST.

 

I had brought out the issue with the draft which = became RFC4305. Stephen Kent had supported the change and stated =

“since we changed the requirements for encryption-only = support in this round of document revisions, I think a SHOULD here is = correct.”

http://130= .230.52.14/list-archive/ipsec/msg05576.html<= /p>

 

however Donald Eastlake had = stated

@@@ I think draft-ietf-ipsec-esp-v3-09 should be = changed.

http://130= .230.52.14/list-archive/ipsec/msg05578.html<= /p>

 

The issue never got resolved and we now have this discrepancy in the RFC’s. Should I send an errata for RFC4305 = regarding the same?

 

Thanks,

Vishwas

 

------_=_NextPart_001_01C614D1.CA0C5D20-- --===============1486554665== 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 --===============1486554665==-- From ipsec-bounces@ietf.org Mon Jan 09 09:22:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evxuj-0000xE-70; Mon, 09 Jan 2006 09:22:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evxuh-0000x9-8d for ipsec@megatron.ietf.org; Mon, 09 Jan 2006 09:22:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17786 for ; Mon, 9 Jan 2006 09:21:05 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evy1B-0006CA-Tp for ipsec@ietf.org; Mon, 09 Jan 2006 09:29:07 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k09EMCpq065740; Mon, 9 Jan 2006 06:22:13 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 9 Jan 2006 06:22:18 -0800 To: "Vishwas Manral" , "IPsec" From: Paul Hoffman Subject: Re: [Ipsec] Discrepency RFC4301 and RFC4305 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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:04 PM -0800 1/8/06, Vishwas Manral wrote: >The issue never got resolved and we now have this discrepancy in the >RFC's. Should I send an errata for RFC4305 regarding the same? Unfortunately, it is not errata, it is a desired spec change that we missed. You might bring it to the RFC Editor as a spec note, certainly including the two references, and see if they will list it on the errata page. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 09 10:56:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzNn-0003Ez-U3; Mon, 09 Jan 2006 10:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzNl-0003En-No for ipsec@megatron.ietf.org; Mon, 09 Jan 2006 10:56:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24738 for ; Mon, 9 Jan 2006 10:55:11 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzUI-0000sg-BY for ipsec@ietf.org; Mon, 09 Jan 2006 11:03:14 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k09FuHIC017460; Mon, 9 Jan 2006 10:56:17 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 9 Jan 2006 10:45:57 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: Re: [Ipsec] Discrepency RFC4301 and RFC4305 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.7 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: IPsec , russ housley 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="===============0831800075==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0831800075== Content-Type: multipart/alternative; boundary="============_-1075300317==_ma============" --============_-1075300317==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:04 PM -0800 1/8/06, Vishwas Manral wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C614D1.CA0C5D20" > >Hi, > >I had brought out the issue more then a year back that: > >RFC4301 states > - confidentiality-only (MAY be supported) > - integrity only (MUST be supported) > - confidentiality and integrity (MUST be supported) > >However RFC4305 states that NULL authentication support is a MUST. > >I had brought out the issue with the draft which became RFC4305. >Stephen Kent had supported the change and stated >"since we changed the requirements for encryption-only support in >this round of document revisions, I think a SHOULD here is correct." >http://130.230.52.14/list-archive/ipsec/msg05576.html > >however Donald Eastlake had stated >@@@ I think draft-ietf-ipsec-esp-v3-09 should be changed. >http://130.230.52.14/list-archive/ipsec/msg05578.html > >The issue never got resolved and we now have this discrepancy in the >RFC's. Should I send an errata for RFC4305 regarding the same? > >Thanks, >Vishwas Whoops. Sorry that this one fell through the cracks in the intervening year after you noted the discrepancy. I still think a SHOULD is appropriate for ESP, given the changes in the architecture document. Since this is a significant change (from a MUST to a SHOULD), it cannot be an errata, as Paul noted. I'll ask Russ how he would like to handle this. Steve --============_-1075300317==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Discrepency RFC4301 and RFC4305
At 8:04 PM -0800 1/8/06, Vishwas Manral wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
  boundary="----_=_NextPart_001_01C614D1.CA0C5D20"
Hi,
 
I had brought out the issue more then a year back that:
 
RFC4301 states
            - confidentiality-only (MAY be supported)
            - integrity only (MUST be supported)
            - confidentiality and integrity (MUST be supported)
 
However RFC4305 states that NULL authentication support is a MUST.
 
I had brought out the issue with the draft which became RFC4305. Stephen Kent had supported the change and stated
"since we changed the requirements for encryption-only support in this round of document revisions, I think a SHOULD here is correct."
http://130.230.52.14/list-archive/ipsec/msg05576.html
 
however Donald Eastlake had stated
@@@ I think draft-ietf-ipsec-esp-v3-09 should be changed.
http://130.230.52.14/list-archive/ipsec/msg05578.html
 
The issue never got resolved and we now have this discrepancy in the RFC's. Should I send an errata for RFC4305 regarding the same?
 
Thanks,
Vishwas

Whoops.  Sorry that this one fell through the cracks in the intervening year after you noted the discrepancy.

I still think a SHOULD is appropriate for ESP, given the changes in the architecture document. Since this is a significant change (from a MUST to a SHOULD), it cannot be an errata, as Paul noted. I'll ask Russ how he would like to handle this.

Steve
--============_-1075300317==_ma============-- --===============0831800075== 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 --===============0831800075==-- From ipsec-bounces@ietf.org Fri Jan 13 00:52:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExHrB-0003I6-9J; Fri, 13 Jan 2006 00:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExHr9-0003E7-Bg for ipsec@megatron.ietf.org; Fri, 13 Jan 2006 00:52:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02898 for ; Fri, 13 Jan 2006 00:50:50 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExHyP-0004Vd-3U for ipsec@ietf.org; Fri, 13 Jan 2006 00:59:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2006 21:51:56 -0800 Message-ID: Thread-Topic: Errata RFC4305 Thread-Index: AcYX9I0QikhfGvpWTh2ME/9wF2lMlQAAAZ1AAAAJetA= From: "Vishwas Manral" To: "Russ Housley" X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: IPsec , Stephen Kent Subject: [Ipsec] Errata RFC4305 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 Russ/ Stephen, After the private discussion, I have compiled changes for RFC4305. The changes are all related to the old point I had raised, on the list (except point 3 where I have added a note).=20 I will forward them to the errata page if the changes look good to the list. 1. Section 3.1.1 states Requirement Authentication Algorithm (notes) ----------- ------------------------ MUST HMAC-SHA1-96 [RFC2404] MUST NULL (1) SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (2) Should be=20 Requirement Authentication Algorithm (notes) ----------- ------------------------ MUST HMAC-SHA1-96 [RFC2404] SHOULD+ AES-XCBC-MAC-96 [RFC3566] SHOULD NULL (1) MAY HMAC-MD5-96 [RFC2403] (2) 2. Section 3.1.1 states Notes: (1) Since ESP encryption and authentication are optional, support for the two "NULL" algorithms is required to maintain consistency with the way these services are negotiated. Note that while authentication and encryption can each be "NULL", they MUST NOT both be "NULL". Should be Notes: (1) Since ESP encryption is optional, support for the "NULL" algorithm is required to maintain consistency with the way=20 services are negotiated. Note that while authentication=20 and encryption can each be "NULL", they MUST NOT both be=20 "NULL". 3. Section 3.2 states Requirement Algorithm (notes) ----------- --------- MUST HMAC-SHA1-96 [RFC2404]=20 SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (1) Note: (1) Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC. Should be Requirement Algorithm (notes) ----------- --------- MUST HMAC-SHA1-96 [RFC2404] (1) SHOULD+ AES-XCBC-MAC-96 [RFC3566] MAY HMAC-MD5-96 [RFC2403] (2) Note: (1) Collisions attacks are now known in SHA-1; however, these should=20 not affect the use of SHA-1 with HMAC. (2) Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC. 4. Section 6. The implementation requirements are compared below: Old Old New Req. RFC(s) Requirement Algorithm (notes) --- ------ ----------- --------- MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1) MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403] MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404] Should be The implementation requirements are compared below: Old Old New Req. RFC(s) Requirement Algorithm (notes) --- ------ ----------- --------- MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1) MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403] MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404] MUST 2406 SHOULD NULL Authentication MUST 2406 MUST NULL Encryption =20 Thanks, Vishwas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 13 04:35:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExLKz-0004ZA-BY; Fri, 13 Jan 2006 04:35:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExLKw-0004Z4-SH for ipsec@megatron.ietf.org; Fri, 13 Jan 2006 04:35:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16082 for ; Fri, 13 Jan 2006 04:33:48 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExLSB-0002jO-Th for ipsec@ietf.org; Fri, 13 Jan 2006 04:42:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2006 01:34:46 -0800 Message-ID: Thread-Topic: RFC4302 and Routing Type 2 header Thread-Index: AcYYJWiMdn07/J1pTWec7KpgGlEQDw== From: "Vishwas Manral" To: "IPsec" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] RFC4302 and Routing Type 2 header 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 Stephen, I think we missed out the mention of how we need to treat Routing Type 2 header and Mobility header for ICV computations in the AH RFC4302. I agree, the way to use it sounds obvious though. I think for data packets we can have AH with MIPv6 packets. Thanks, Vishwas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 13 10:10:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExQZa-0000Nz-9R; Fri, 13 Jan 2006 10:10:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExQZY-0000Lv-CV for ipsec@megatron.ietf.org; Fri, 13 Jan 2006 10:10:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11998 for ; Fri, 13 Jan 2006 10:09:13 -0500 (EST) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExQgr-00072k-FR for ipsec@ietf.org; Fri, 13 Jan 2006 10:18:10 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k0DFAKpE018749 for ; Fri, 13 Jan 2006 10:10:20 -0500 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k0DFAKih018744; Fri, 13 Jan 2006 10:10:20 -0500 Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 10:10:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17351.49881.925848.930352@gargle.gargle.HOWL> Date: Fri, 13 Jan 2006 10:10:17 -0500 From: Paul Koning To: Vishwas@sinett.com Subject: Re: [Ipsec] Errata RFC4305 References: X-Mailer: VM 7.17 under 21.5 (beta23) "daikon" XEmacs Lucid X-OriginalArrivalTime: 13 Jan 2006 15:10:19.0957 (UTC) FILETIME=[77E64650:01C61853] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, housley@vigilsec.com, kent@bbn.com 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 Russ/ Stephen, > After the private discussion, I have compiled changes for RFC4305. The > changes are all related to the old point I had raised, on the list > (except point 3 where I have added a note). > > I will forward them to the errata page if the changes look good to the > list. > > 1. Section 3.1.1 states > > Requirement Authentication Algorithm (notes) > ----------- ------------------------ >... > MUST NULL (1) >... > Should be > > Requirement Authentication Algorithm (notes) > ----------- ------------------------ >.. > SHOULD NULL (1) That still seems to conflict with RFC 4303, which says MAY and not SHOULD. In my opinion, MAY is the correct choice. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 15 10:27:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9mr-0005sq-Sy; Sun, 15 Jan 2006 10:27:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9mp-0005s9-Oz for ipsec@megatron.ietf.org; Sun, 15 Jan 2006 10:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07909 for ; Sun, 15 Jan 2006 10:25:55 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey3h6-0003g6-FW for ipsec@ietf.org; Sun, 15 Jan 2006 03:57:03 -0500 Received: from [213.54.82.223] (helo=212.227.126.177) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Ey3ZD46hd-000585; Sun, 15 Jan 2006 09:48:52 +0100 From: Thomas Otto To: ipsec@ietf.org Date: Sun, 15 Jan 2006 09:49:03 +0100 User-Agent: KMail/1.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601150949.03425.t.otto@sharevolution.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:3105fcefe481186a11ed9e9de1ccc56f X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Ipsec] RFC 4306 - Pseudorandom function 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, IKEv2 (RFC 4306) does not explicitely give an algorithm for prf, only for its iterated version. prf+ (K,S) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) Is a single iteration prf(K,S) or prf(K,S | 0x01) ? Thomas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 18 07:07:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzC6H-0007Jr-SK; Wed, 18 Jan 2006 07:07:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzC6G-0007Jm-R8 for ipsec@megatron.ietf.org; Wed, 18 Jan 2006 07:07:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03303 for ; Wed, 18 Jan 2006 07:06:15 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzCEZ-0006F4-Oy for ipsec@ietf.org; Wed, 18 Jan 2006 07:16:17 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EzC68-0004Cj-0D for ipsec@ietf.org; Wed, 18 Jan 2006 07:07:32 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0IC2lil027606; Wed, 18 Jan 2006 14:02:50 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 14:07:29 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 14:07:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] IKEv2: invalid SPI in DELETE payload Date: Wed, 18 Jan 2006 14:07:30 +0200 Message-ID: In-Reply-To: <17321.7090.645389.376171@fireball.acr.fi> Thread-Topic: [Ipsec] IKEv2: invalid SPI in DELETE payload Thread-Index: AcYGDm0pOEgLhsEnQ6iOmp2iWc9cVgWF7atw To: X-OriginalArrivalTime: 18 Jan 2006 12:07:29.0669 (UTC) FILETIME=[C129EB50:01C61C27] X-Spam-Score: 0.4 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 =20 Tero Kivinen wrote: > The problem is that if responder's policy changes then he might want > to delete SA even when there has not been any traffic over that SA > (which would indicate that the other end managed to create the SA). I finally managed to write something for the clarifications document about this issue. Here's some analysis: X.X Deleting a non-existent SPI The specification does not describe what happens when a Delete payload containing an unrecognized SPI is received. Normally, this situation does not happen, since the state should be synchronized. However, there is at least one one rare situation where this can actually happen. Consider a situation where host A creates a CHILD_SA pair, but soon thereafter host B decides to delete it (possible because its policy changed): Host A Host B -------- -------- send req1: SA(..,SPIa,..),.. --> --> recv req1 (lost) <-- send resp1: SA(..,SPIb,..),.. <-- send req2: D(SPIb) recv req2 At this point, host A has not yet received message resp1 (and is retransmitting message req1), so it does not recognize SPIb in message req2. What should host A do? =20 One option would be to reply with an empty Informational response. However, this same reply would also be sent if host A has received resp1, but has already sent a new request to delete the SA that was just created. This would lead to a situation where the peers are no longer in sync about which SAs exist between them. However, host B would eventually notice that the other half of the CHILD_SA pair has not been deleted. Section 1.4 describes this case and notes that "a node SHOULD regard half-closed connections as anomalous and audit their existence should they persist", and continues that "if connection state becomes sufficiently messed up, a node MAY close the IKE_SA". Another solution that has been proposed is to reply with an INVALID_SPI notification which contains SPIb. This would explicitly tell host B that the SA was not deleted, so host B could try deleting it again later. However, this usage is not part of the IKEv2 specification, and would not be in line with normal use of the INVALID_SPI notification where the data field contains the SPI the recipient of the notification would put in outbound=20 packets. Currently, this document recommends (to be determined) =20 (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/Jan 2006.) To me, it looks like the former approach would be sufficient (it's not very serious if this kind of "half-closed SA" exists for some time), and better in line with what the spec currently says. Any comments? Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 18 07:19:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzCHe-0002b6-1m; Wed, 18 Jan 2006 07:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzCHb-0002ZI-OH for ipsec@megatron.ietf.org; Wed, 18 Jan 2006 07:19:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04441 for ; Wed, 18 Jan 2006 07:17:58 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzCPv-0006if-Lj for ipsec@ietf.org; Wed, 18 Jan 2006 07:28:00 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k0ICIwaw025727 for ; Wed, 18 Jan 2006 14:18:58 +0200 (IST) Message-Id: <200601181218.k0ICIwaw025727@michael.checkpoint.com> From: "Yoav Nir" To: Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload Date: Wed, 18 Jan 2006 14:18:58 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYGDm0pOEgLhsEnQ6iOmp2iWc9cVgWF7atwAADFAbA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit 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 wrote: > > Tero Kivinen wrote: > > > The problem is that if responder's policy changes then he might want > > to delete SA even when there has not been any traffic over that SA > > (which would indicate that the other end managed to create the SA). > > I finally managed to write something for the clarifications document > about this issue. Here's some analysis: > > X.X Deleting a non-existent SPI > > The specification does not describe what happens when a Delete > payload containing an unrecognized SPI is received. Normally, this > situation does not happen, since the state should be synchronized. > However, there is at least one one rare situation where this can > actually happen. > > Consider a situation where host A creates a CHILD_SA pair, but soon > > thereafter host B decides to delete it (possible because its policy > changed): > > Host A Host B > -------- -------- > send req1: SA(..,SPIa,..),.. --> > --> recv req1 > (lost) <-- send resp1: SA(..,SPIb,..),.. > > <-- send req2: D(SPIb) > recv req2 > > At this point, host A has not yet received message resp1 (and is > retransmitting message req1), so it does not recognize SPIb in > message req2. What should host A do? > > One option would be to reply with an empty Informational response. > However, this same reply would also be sent if host A has received > resp1, but has already sent a new request to delete the SA that was > just created. This would lead to a situation where the peers are no > longer in sync about which SAs exist between them. However, host B > would eventually notice that the other half of the CHILD_SA pair > has not been deleted. Section 1.4 describes this case and notes > that "a node SHOULD regard half-closed connections as anomalous and > audit their existence should they persist", and continues that "if > connection state becomes sufficiently messed up, a node MAY close > the IKE_SA". > > Another solution that has been proposed is to reply with an > INVALID_SPI notification which contains SPIb. This would explicitly > tell host B that the SA was not deleted, so host B could try > deleting it again later. However, this usage is not part of the > IKEv2 specification, and would not be in line with normal use > of the INVALID_SPI notification where the data field contains > the SPI the recipient of the notification would put in outbound > packets. > > Currently, this document recommends (to be determined) > > (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec > 2005/Jan 2006.) > > To me, it looks like the former approach would be sufficient (it's not > very serious if this kind of "half-closed SA" exists for some time), > and better in line with what the spec currently says. Any comments? > > Best regards, > Pasi Agree. INVALID_SPI is not expected in response to a DELETE. Besides, the initiator wanted this SPI to no longer exist. It doesn't exist. Mission accomplished. Receiving this empty response is enough of an indication that the states are our of sync that the initiator can silently delete (and log) the other half of the SA. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 18 07:47:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzCiQ-00016F-8O; Wed, 18 Jan 2006 07:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzCiO-00015H-TB for ipsec@megatron.ietf.org; Wed, 18 Jan 2006 07:47:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07611 for ; Wed, 18 Jan 2006 07:45:39 -0500 (EST) Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzCqg-0007wn-Sz for ipsec@ietf.org; Wed, 18 Jan 2006 07:55:41 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 6DC171FAC1D; Wed, 18 Jan 2006 13:46:52 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20007-01-2; Wed, 18 Jan 2006 13:46:51 +0100 (CET) Received: from mail.dif.um.es (dif.um.es [155.54.204.60]) by mail.um.es (Postfix) with ESMTP id C51781FAC16; Wed, 18 Jan 2006 13:46:51 +0100 (CET) Received: from diffie (unknown [155.54.210.175]) by mail.dif.um.es (Postfix) with ESMTP id EAC1C1054029; Wed, 18 Jan 2006 13:46:24 +0100 (CET) Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload From: Alejandro Perez Mendez To: Yoav Nir In-Reply-To: <200601181218.k0ICIwaw025727@michael.checkpoint.com> References: <200601181218.k0ICIwaw025727@michael.checkpoint.com> Content-Type: text/plain; charset=utf-8 Date: Wed, 18 Jan 2006 13:46:52 +0100 Message-Id: <1137588413.14553.10.camel@diffie> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 El mi=C3=A9, 18-01-2006 a las 14:18 +0200, Yoav Nir escribi=C3=B3: > Pasi.Eronen@nokia.com wrote: >=20 > > =20 > > Tero Kivinen wrote: > >=20 > > > The problem is that if responder's policy changes then he might wan= t > > > to delete SA even when there has not been any traffic over that SA > > > (which would indicate that the other end managed to create the SA). > >=20 > > I finally managed to write something for the clarifications document > > about this issue. Here's some analysis: > >=20 > > X.X Deleting a non-existent SPI > >=20 > > The specification does not describe what happens when a Delete > > payload containing an unrecognized SPI is received. Normally, this > > situation does not happen, since the state should be synchronized. > > However, there is at least one one rare situation where this can > > actually happen. > >=20 > > Consider a situation where host A creates a CHILD_SA pair, but soo= n > >=20 > > thereafter host B decides to delete it (possible because its polic= y > > changed): > >=20 > > Host A Host B > > -------- -------- > > send req1: SA(..,SPIa,..),.. --> > > --> recv req1 > > (lost) <-- send resp1: SA(..,SPIb,..),.. > >=20 > > <-- send req2: D(SPIb) > > recv req2 > >=20 > > At this point, host A has not yet received message resp1 (and is > > retransmitting message req1), so it does not recognize SPIb in > > message req2. What should host A do? > > =20 > > One option would be to reply with an empty Informational response. > > However, this same reply would also be sent if host A has received > > resp1, but has already sent a new request to delete the SA that wa= s > > just created. This would lead to a situation where the peers are n= o > > longer in sync about which SAs exist between them. However, host = B > > would eventually notice that the other half of the CHILD_SA pair > > has not been deleted. Section 1.4 describes this case and notes > > that "a node SHOULD regard half-closed connections as anomalous an= d > > audit their existence should they persist", and continues that "if > > connection state becomes sufficiently messed up, a node MAY close > > the IKE_SA". > >=20 > > Another solution that has been proposed is to reply with an > > INVALID_SPI notification which contains SPIb. This would explicitl= y > > tell host B that the SA was not deleted, so host B could try > > deleting it again later. However, this usage is not part of the > > IKEv2 specification, and would not be in line with normal use > > of the INVALID_SPI notification where the data field contains > > the SPI the recipient of the notification would put in outbound=20 > > packets. > >=20 > > Currently, this document recommends (to be determined) > > =20 > > (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec > > 2005/Jan 2006.) > >=20 > > To me, it looks like the former approach would be sufficient (it's no= t > > very serious if this kind of "half-closed SA" exists for some time), > > and better in line with what the spec currently says. Any comments? > >=20 > > Best regards, > > Pasi >=20 > Agree. INVALID_SPI is not expected in response to a DELETE. Besides, th= e > initiator wanted this SPI to no longer exist. It doesn't exist. Mission > accomplished. Receiving this empty response is enough of an indication = that > the states are our of sync that the initiator can silently delete (and = log) > the other half of the SA. And what happen when the responder receives a CREATE_CHILD_SA request including a REKEY_SA payload that contains an unknown SPI? Should the responder send INVALID_SPI in this case? Should the responder ignore such request? Host A Host B -------- -------- send req1: SA(..,SPIa,..),.. --> --> recv req1 (lost) <-- send resp1: SA(..,SPIb,..),.. <-- send req2: REKEY_SA(SPIb) recv req2 Regards! -- OpenIKEv2 develop team http://openikev2.sf.net Alejandro Perez Mendez Pedro J. Fernandez Ruiz >=20 >=20 > _______________________________________________ > 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 Wed Jan 18 08:30:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzDOh-00066p-KL; Wed, 18 Jan 2006 08:30:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzDOg-00066k-5y for ipsec@megatron.ietf.org; Wed, 18 Jan 2006 08:30:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12510 for ; Wed, 18 Jan 2006 08:29:19 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzDWx-0001W7-Kp for ipsec@ietf.org; Wed, 18 Jan 2006 08:39:23 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k0IDUMaw017627; Wed, 18 Jan 2006 15:30:22 +0200 (IST) Message-Id: <200601181330.k0IDUMaw017627@michael.checkpoint.com> From: "Yoav Nir" To: Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload Date: Wed, 18 Jan 2006 15:30:22 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYGDm0pOEgLhsEnQ6iOmp2iWc9cVgWF7atwAACerCAAAHu1MAACESAQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Host A requested that SPIb be deleted, and B acknowledged. That should be enough for A to conclude that host B no longer has its half of the SA. It can safely set a timer (for say, 10 seconds) and then silently delete the other half of the SA. I don't think in the real world SAs are so numerous that complying with the section 1.4 requirement is any problem. > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Wednesday, January 18, 2006 2:30 PM > To: ynir@checkpoint.com > Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload > > Yoav Nir wrote: > > > Agree. INVALID_SPI is not expected in response to a DELETE. > > Besides, the initiator wanted this SPI to no longer exist. It > > doesn't exist. Mission accomplished. Receiving this empty response > > is enough of an indication that the states are our of sync that the > > initiator can silently delete (and log) the other half of the SA. > > Well, host A still thinks both halves of the SA exist, and thus host B > cannot completely forget the situation. In addition to perhaps logging > the situation, Section 1.4 requires that host B must not re-use the > same SPIs for some other SA (at least with the same peer). > > Best regards, > Pasi > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 18 08:31:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzDP3-00069e-C3; Wed, 18 Jan 2006 08:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzDP2-00069Z-3w for ipsec@megatron.ietf.org; Wed, 18 Jan 2006 08:31:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12533 for ; Wed, 18 Jan 2006 08:29:42 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzDXK-0001X2-Qi for ipsec@ietf.org; Wed, 18 Jan 2006 08:39:45 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0IDUtSa006685; Wed, 18 Jan 2006 15:30:56 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 15:30:42 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 15:30:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] IKEv2: invalid SPI in DELETE payload Date: Wed, 18 Jan 2006 15:30:42 +0200 Message-ID: In-Reply-To: <1137588413.14553.10.camel@diffie> Thread-Topic: [Ipsec] IKEv2: invalid SPI in DELETE payload Thread-Index: AcYcLtypHnxfm4KHSuWboQJaQ+/n0gAApNaw To: X-OriginalArrivalTime: 18 Jan 2006 13:30:42.0529 (UTC) FILETIME=[6123E510:01C61C33] X-Spam-Score: 0.4 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > And what happen when the responder receives a CREATE_CHILD_SA request > including a REKEY_SA payload that contains an unknown SPI? Should the > responder send INVALID_SPI in this case? Should the responder ignore > such request? The same situation (host receives a rekeying request with an unknown SPI) can also happen if both peers start rekeying at the same time.=20 This case is discussed in the clarifications draft Section 5.12; currently it recommends replying with NO_PROPOSAL_CHOSEN. I'm not sure if this is the best possible approach, but it seemed reasonable when that text was written... (But the presumably the "host A creates an SA, host B immediately starts rekeying it" case should be quite rare.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 18 11:08:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFrm-0006i5-Th; Wed, 18 Jan 2006 11:08:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFrl-0006hx-UD for ipsec@megatron.ietf.org; Wed, 18 Jan 2006 11:08:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29656 for ; Wed, 18 Jan 2006 11:07:31 -0500 (EST) Received: from 84-121-24-204.onocable.ono.com ([84.121.24.204] helo=localhost.localdomain) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzG08-00080E-Cj for ipsec@ietf.org; Wed, 18 Jan 2006 11:17:36 -0500 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 53C038E26C; Wed, 18 Jan 2006 17:08:48 +0100 (CET) Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload From: Alejandro Perez Mendez To: Pasi.Eronen@nokia.com In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Wed, 18 Jan 2006 17:08:47 +0100 Message-Id: <1137600527.22324.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.5.4 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 El mi=C3=A9, 18--2006 a las 15:30 +0200, Pasi.Eronen@nokia.com escribi=C3= =B3:=20 > > And what happen when the responder receives a CREATE_CHILD_SA request > > including a REKEY_SA payload that contains an unknown SPI? Should the > > responder send INVALID_SPI in this case? Should the responder ignore > > such request? >=20 > The same situation (host receives a rekeying request with an > unknown SPI) can also happen if both peers start rekeying at > the same time.=20 >=20 > This case is discussed in the clarifications draft Section 5.12; > currently it recommends replying with NO_PROPOSAL_CHOSEN. > I'm not sure if this is the best possible approach, but it > seemed reasonable when that text was written... It's good for me. I had not read entirely this section before. >=20 > (But the presumably the "host A creates an SA, host B immediately > starts rekeying it" case should be quite rare.) One may want to rekey in intervals of 1 or 2 seconds and retransmition time may be superior. It is a rare case, but it is not impossible. Regards -- OpenIKEv2 develop team http://openikev2.sf.net =20 Alejandro Perez Mendez Pedro J. Fernandez Ruiz _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 23 08:22:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F11eW-0004h6-Ho; Mon, 23 Jan 2006 08:22:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F11eT-0004gp-3r for ipsec@megatron.ietf.org; Mon, 23 Jan 2006 08:22:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16959 for ; Mon, 23 Jan 2006 08:21:02 -0500 (EST) 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 1F11nn-0005OP-Pq for ipsec@ietf.org; Mon, 23 Jan 2006 08:32:13 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k0NDMFGe002475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2006 15:22:15 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k0NDMDQJ018145; Mon, 23 Jan 2006 15:22:13 +0200 (EET) X-Authentication-Warning: fireball.acr.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: <17364.55429.535916.153864@fireball.acr.fi> Date: Mon, 23 Jan 2006 15:22:13 +0200 From: Tero Kivinen To: "Yoav Nir" Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload In-Reply-To: <200601181330.k0IDUMaw017627@michael.checkpoint.com> References: <200601181330.k0IDUMaw017627@michael.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 14 min X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com 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 Yoav Nir writes: > Host A requested that SPIb be deleted, and B acknowledged. That should be Actually it was host B requested SPIb to be deleted, and host A which received that request didn't know anything about the SPIb at that point. If host A replies with ack, then host B will delete the SPIb (his inbound SA), but will keep the outbound SA as it was not deleted by the reply DELETE as normally would. Host B does not have any way to clean up the state after that, except to delete the IKE SA and recreate all SAs. Host A will create the SPIb as outbound SPI after he gets retransmissions of the packets, and host A thinks he has SA that is up and working, but B does not accept any data to it, but drops those packets. The host B will then start sending INVALID_SPI when host A sends him packets using SPIb, so host A can detect the situation and delete send delete to SPIa. After that host B is happy as he has deleted the both SPIs, but he will reply with empty ack again, as he does not have the SPIb anymore, thus host A still will have half closed SA. This does require quite a lot of special code just to do detect those situations and recover from them. If the host A sends any kind of error message back to the delete indicating that the delete could not be performed, then no special code is needed, as they both stay in sync all the time. It does not have have to be INVALID_SPI, it could even be some other error notify, but as the SPI is invalid for the host A INVALID_SPI matches quite well to that. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 27 11:10:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WAt-00079y-QM; Fri, 27 Jan 2006 11:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WAr-00079D-LB for ipsec@megatron.ietf.org; Fri, 27 Jan 2006 11:10:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22524 for ; Fri, 27 Jan 2006 11:08:36 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2WL1-0004em-A8 for ipsec@ietf.org; Fri, 27 Jan 2006 11:20:41 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0RGA0dX073517 for ; Fri, 27 Jan 2006 08:10:01 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 27 Jan 2006 08:09:52 -0800 To: IPsec WG From: rfc-editor@rfc-editor.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Ipsec] RFC 4359 on The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) 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 A new Request for Comments is now available in online RFC libraries. RFC 4359 Title: The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) Author(s): B. Weis Status: Standards Track Date: January 2006 Mailbox: bew@cisco.com Pages: 12 Characters: 26989 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-msec-ipsec-signatures-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4359.txt This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. This document is a product of the Multicast Security Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 30 16:47:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3gs2-000801-Jw; Mon, 30 Jan 2006 16:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3gs0-0007zS-H4 for ipsec@megatron.ietf.org; Mon, 30 Jan 2006 16:47:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10617 for ; Mon, 30 Jan 2006 16:45:57 -0500 (EST) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3h2m-00072I-ER for ipsec@ietf.org; Mon, 30 Jan 2006 16:58:45 -0500 Received: from elwamui-karabash.atl.sa.earthlink.net ([209.86.224.37]) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F3grq-0006Hc-00 for ipsec@ietf.org; Mon, 30 Jan 2006 16:47:22 -0500 Message-ID: <12803499.1138657642162.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Mon, 30 Jan 2006 13:47:22 -0800 (GMT-08:00) From: "Scott G. Kelly" To: ipsec list Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14104_6497228.1138657642155" X-Mailer: EarthLink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Ipsec] Fw: I-D ACTION:draft-kelly-saag-des-implications-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Scott G. Kelly" List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ------=_Part_14104_6497228.1138657642155 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Some time ago, Russ Housley asked if someone would write a note for implementers regarding the security implications of using DES. This request derived from a recommendation in http://www.ietf.org/internet-drafts/draft-ietf-newtrk-decruft-experiment-03.txt. Anyway, here's the first cut at the draft. I intend to add an appendix explaining why 3DES is still okay, and someone suggested that maybe DESX should be discussed as well. If you have suggestions or comments, I'm all ears... -----Forwarded Message----- >From: Internet-Drafts@ietf.org >Sent: Jan 30, 2006 12:50 PM >To: i-d-announce@ietf.org >Subject: I-D ACTION:draft-kelly-saag-des-implications-00.txt > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : draft-kelly-saag-des-implications > Author(s) : S. Kelly > Filename : draft-kelly-saag-des-implications-00.txt > Pages : 24 > Date : 2006-1-30 > > The Data Encryption Standard [DES] is susceptible to brute force > attacks which are well within the reach of a modestly financed > adversary. As a result, DES has been deprecated, and replaced by the > Advanced Encryption Standard [AES]. Nonetheless, many applications > continue to rely on DES for security, and designers and implementers > continue to provide support for it in new applications. While this > is not always inappropriate, it frequently is. This note discusses > DES security implications, so that designers and implementers can > make judicious decisions regarding its use. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kelly-saag-des-implications-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-kelly-saag-des-implications-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-kelly-saag-des-implications-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. ------=_Part_14104_6497228.1138657642155 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-30120813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kelly-saag-des-implications-00.txt ------=_Part_14104_6497228.1138657642155 Content-Type: Message/External-body; name="draft-kelly-saag-des-implications-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-30120813.I-D@ietf.org> ------=_Part_14104_6497228.1138657642155 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_Part_14104_6497228.1138657642155 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 ------=_Part_14104_6497228.1138657642155-- From ipsec-bounces@ietf.org Mon Jan 30 17:39:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3hgc-0002hr-L7; Mon, 30 Jan 2006 17:39:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3hgb-0002ge-9O for ipsec@megatron.ietf.org; Mon, 30 Jan 2006 17:39:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20354 for ; Mon, 30 Jan 2006 17:38:03 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3hrF-0002KT-SP for ipsec@ietf.org; Mon, 30 Jan 2006 17:50:51 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0UMdS1i026383; Mon, 30 Jan 2006 14:39:29 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <12803499.1138657642162.JavaMail.root@elwamui-karabash.atl.sa.earthlink.ne t> References: <12803499.1138657642162.JavaMail.root@elwamui-karabash.atl.sa.earthlink.ne t> Date: Mon, 30 Jan 2006 14:39:28 -0800 To: "Scott G. Kelly" , ipsec list From: Paul Hoffman Subject: Re: [Ipsec] Fw: I-D ACTION:draft-kelly-saag-des-implications-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 1:47 PM -0800 1/30/06, Scott G. Kelly wrote: >Some time ago, Russ Housley asked if someone would write a note for >implementers regarding the security implications of using DES. This >request derived from a recommendation in > >http://www.ietf.org/internet-drafts/draft-ietf-newtrk-decruft-experiment-03.txt. > >Anyway, here's the first cut at the draft. I intend to add an >appendix explaining why 3DES is still okay, and someone suggested >that maybe DESX should be discussed as well. If you have >suggestions or comments, I'm all ears... Apropos to this mailing list: maybe a bit more about user interfaces that have multiple choices for algorithms but that have "DES" as the default choice in drop-down menus being a Really Bad (and Unnecessary) Thing. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec