From owner-ipsec@lists.tislabs.com Thu Mar 1 06:35:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA23707; Thu, 1 Mar 2001 06:35:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28026 Thu, 1 Mar 2001 07:30:36 -0500 (EST) Message-Id: <200103010317.TAA06305@domus.ebay.sun.com> Date: Wed, 28 Feb 2001 19:17:30 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: Internet Draft for explicit security labels in IPv6. To: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9jHUCWwDSMzmNjSZbSM0eQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating within the premises of a trusted infrastructure. IPv6 only has the implicit labeling by having different IPsec SAs convey different labels. We think there is a need to have explicit labels in IPv6, whether or not IPsec is used. Please see draft-belgaied-ipv6-lsopt-00.txt http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt Regards, Kais. From owner-ipsec@lists.tislabs.com Thu Mar 1 10:44:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13230; Thu, 1 Mar 2001 10:44:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28826 Thu, 1 Mar 2001 12:06:26 -0500 (EST) From: "Joseph D. Harwood" To: "Kais Belgaied" , , Subject: RE: Internet Draft for explicit security labels in IPv6. Date: Thu, 1 Mar 2001 09:11:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C0A22F.8DBCD7E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200103010317.TAA06305@domus.ebay.sun.com> X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C0A22F.8DBCD7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This sounds like it mandates the use of AH, is that correct? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied > Sent: Wednesday, February 28, 2001 7:18 PM > To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > Subject: Internet Draft for explicit security labels in IPv6. > > > Greetings, > > IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating > within the premises of a trusted infrastructure. > IPv6 only has the implicit labeling by having different IPsec SAs convey > different labels. > We think there is a need to have explicit labels in IPv6, whether or not > IPsec is used. > > Please see draft-belgaied-ipv6-lsopt-00.txt > > http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt > > > Regards, > Kais. > > > ------=_NextPart_000_0016_01C0A22F.8DBCD7E0 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0016_01C0A22F.8DBCD7E0-- From owner-ipsec@lists.tislabs.com Thu Mar 1 12:37:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA20466; Thu, 1 Mar 2001 12:37:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29382 Thu, 1 Mar 2001 14:05:24 -0500 (EST) Message-Id: <200103011857.KAA10956@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 10:57:59 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: RE: Internet Draft for explicit security labels in IPv6. To: kais@domus.ebay.sun.com, ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QBDv7AE1DqT5f59x+U7jjA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It mandates a guarantee that the label on the IPv6 is authentic before trusting it. In a link-local scope, where the label is proposed to be carried in the destination header, ESP is mandatory and sufficient. On a wider scope, AH is necessary. Kais. > >This sounds like it mandates the use of AH, is that correct? > >Best Regards, >Joseph D. Harwood >jharwood@vesta-corp.com >www.vesta-corp.com > >> -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied >> Sent: Wednesday, February 28, 2001 7:18 PM >> To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com >> Subject: Internet Draft for explicit security labels in IPv6. >> >> >> Greetings, >> >> IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating >> within the premises of a trusted infrastructure. >> IPv6 only has the implicit labeling by having different IPsec SAs convey >> different labels. >> We think there is a need to have explicit labels in IPv6, whether or not >> IPsec is used. >> >> Please see draft-belgaied-ipv6-lsopt-00.txt >> >> http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt >> >> >> Regards, >> Kais. >> >> >> From owner-ipsec@lists.tislabs.com Thu Mar 1 12:42:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA20564; Thu, 1 Mar 2001 12:42:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29452 Thu, 1 Mar 2001 14:23:58 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Kais Belgaied Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 14:27:24 -0500 Message-Id: <20010301192729.3FF2F35C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200103011857.KAA10956@domus.ebay.sun.com>, Kais Belgaied writes: >It mandates a guarantee that the label on the IPv6 is authentic before trustin >g >it. In a link-local scope, where the label is proposed to be carried in the >destination header, ESP is mandatory and sufficient. >On a wider scope, AH is necessary. Or it could be bound to the certificate and recreated at the far end. > >Kais. > > > >This sounds like it mandates the use of AH, is that correct? > > > >Best Regards, > >Joseph D. Harwood > >jharwood@vesta-corp.com > >www.vesta-corp.com > > > >> -----Original Message----- > >> From: owner-ipsec@lists.tislabs.com > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied > >> Sent: Wednesday, February 28, 2001 7:18 PM > >> To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > >> Subject: Internet Draft for explicit security labels in IPv6. > >> > >> > >> Greetings, > >> > >> IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating > >> within the premises of a trusted infrastructure. > >> IPv6 only has the implicit labeling by having different IPsec SAs convey > >> different labels. > >> We think there is a need to have explicit labels in IPv6, whether or not > >> IPsec is used. > >> > >> Please see draft-belgaied-ipv6-lsopt-00.txt > >> > >> http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt > >> > >> > >> Regards, > >> Kais. > >> > >> > >> > > > --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Mar 1 13:01:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA21708; Thu, 1 Mar 2001 13:01:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29611 Thu, 1 Mar 2001 14:47:12 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Joseph D. Harwood" Cc: "Kais Belgaied" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 14:50:47 -0500 Message-Id: <20010301195047.B681435C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Joseph D. H arwood" writes: >This is a multi-part message in MIME format. > >------=_NextPart_000_0022_01C0A245.80C7E140 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit > >My understanding of the draft was that, one of the goals is for intervening >routers to be able to make routing decisions based on the contents of the >security label (Section 3.4): > > A router needs to trust the authenticity and integrity of a > packet before making routing decision based on the content of its > label. > >The proposal is to permit security labels in Hop-By-Hop Extension Headers, >which (if I remember correctly) are only protected by AH. > >This would seem to require AH. But intermediate routers don't have the keys to verify the AH header. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Mar 1 13:06:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA22159; Thu, 1 Mar 2001 13:06:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29584 Thu, 1 Mar 2001 14:43:15 -0500 (EST) From: "Joseph D. Harwood" To: , "Kais Belgaied" Cc: , Subject: RE: Internet Draft for explicit security labels in IPv6. Date: Thu, 1 Mar 2001 11:48:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C0A245.80C7E140" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20010301192729.3FF2F35C42@berkshire.research.att.com> X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0A245.80C7E140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My understanding of the draft was that, one of the goals is for intervening routers to be able to make routing decisions based on the contents of the security label (Section 3.4): A router needs to trust the authenticity and integrity of a packet before making routing decision based on the content of its label. The proposal is to permit security labels in Hop-By-Hop Extension Headers, which (if I remember correctly) are only protected by AH. This would seem to require AH. Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: smb@research.att.com [mailto:smb@research.att.com] > Sent: Thursday, March 01, 2001 11:27 AM > To: Kais Belgaied > Cc: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com; > jharwood@vesta-corp.com > Subject: Re: Internet Draft for explicit security labels in IPv6. > > > In message <200103011857.KAA10956@domus.ebay.sun.com>, Kais > Belgaied writes: > >It mandates a guarantee that the label on the IPv6 is authentic > before trustin > >g > >it. In a link-local scope, where the label is proposed to be > carried in the > >destination header, ESP is mandatory and sufficient. > >On a wider scope, AH is necessary. > > Or it could be bound to the certificate and recreated at the far end. > > > >Kais. > > > > > >This sounds like it mandates the use of AH, is that correct? > > > > > >Best Regards, > > >Joseph D. Harwood > > >jharwood@vesta-corp.com > > >www.vesta-corp.com > > > > > >> -----Original Message----- > > >> From: owner-ipsec@lists.tislabs.com > > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kais Belgaied > > >> Sent: Wednesday, February 28, 2001 7:18 PM > > >> To: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > > >> Subject: Internet Draft for explicit security labels in IPv6. > > >> > > >> > > >> Greetings, > > >> > > >> IPv4 had IPSO and CIPSO for labeling of packets assuming > we're operating > > >> within the premises of a trusted infrastructure. > > >> IPv6 only has the implicit labeling by having different > IPsec SAs convey > > >> different labels. > > >> We think there is a need to have explicit labels in IPv6, > whether or not > > >> IPsec is used. > > >> > > >> Please see draft-belgaied-ipv6-lsopt-00.txt > > >> > > >> http://www.ietf.org/internet-drafts/draft-belgaied-ipv6-lsopt-00.txt > > >> > > >> > > >> Regards, > > >> Kais. > > >> > > >> > > >> > > > > > > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > ------=_NextPart_000_0022_01C0A245.80C7E140 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0022_01C0A245.80C7E140-- From owner-ipsec@lists.tislabs.com Thu Mar 1 14:56:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29700; Thu, 1 Mar 2001 14:56:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00058 Thu, 1 Mar 2001 16:44:51 -0500 (EST) Message-Id: <200103012137.NAA12627@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 13:37:37 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: Re: Internet Draft for explicit security labels in IPv6. To: smb@research.att.com Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KyOl8DuklPNmtzrvB+nCQg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>It mandates a guarantee that the label on the IPv6 is authentic before trustin >>g >>it. In a link-local scope, where the label is proposed to be carried in the >>destination header, ESP is mandatory and sufficient. >>On a wider scope, AH is necessary. > >Or it could be bound to the certificate and recreated at the far end. It could, with the scalability limitation of implicit labeling. Kais. >> >> > >> >This sounds like it mandates the use of AH, is that correct? >> > >> >Best Regards, >> >Joseph D. Harwood >> >jharwood@vesta-corp.com From owner-ipsec@lists.tislabs.com Thu Mar 1 14:56:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29720; Thu, 1 Mar 2001 14:56:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29914 Thu, 1 Mar 2001 16:15:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103010317.TAA06305@domus.ebay.sun.com> References: <200103010317.TAA06305@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 16:15:09 -0500 To: Kais Belgaied From: Stephen Kent Subject: Re: Internet Draft for explicit security labels in IPv6. Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kais, >Greetings, > >IPv4 had IPSO and CIPSO for labeling of packets assuming we're operating >within the premises of a trusted infrastructure. >IPv6 only has the implicit labeling by having different IPsec SAs convey >different labels. >We think there is a need to have explicit labels in IPv6, whether or not >IPsec is used. > Ipsec allows for both implicit and explicit labelling, according to RFC 2401. If one wishes to carry explicit security labels in the IP header, and to protect the integrity and authenticity of these labels, there are two options: use AH or use tunnel mode ESP and have the labels appear only in the inner IP header. Steve From owner-ipsec@lists.tislabs.com Thu Mar 1 14:59:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29892; Thu, 1 Mar 2001 14:59:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00031 Thu, 1 Mar 2001 16:41:15 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Kais Belgaied Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 16:44:44 -0500 Message-Id: <20010301214444.AA30435C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200103012137.NAA12627@domus.ebay.sun.com>, Kais Belgaied writes: >>>It mandates a guarantee that the label on the IPv6 is authentic before trust >in >>>g >>>it. In a link-local scope, where the label is proposed to be carried in the >>>destination header, ESP is mandatory and sufficient. >>>On a wider scope, AH is necessary. >> >>Or it could be bound to the certificate and recreated at the far end. > >It could, with the scalability limitation of implicit labeling. > I'm afraid I don't see the limitation. The certificate itself could contain the label. There are two cases, transport mode IPsec and tunnel mode. In tunnel mode, as Kent pointed out, there is an inner IP header, option fields, etc.; in this case, the receiving gateway may wish to verify the labels in the inner header, but need do nothing. Transport mode is end-to-end, in which case the machine receiving the packet is either the ultimate end point -- in which case it can extract the label from the certificate and pass them up to TCP together -- or it's a bump-in-the-{wire,stack} on that machine. In such cases, it should be quite straightforward to add the certificate's label -- if nothing else, it's already reassembling the packet to combine the IP header and the body, which were separated by the IPsec header. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Mar 1 15:51:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02028; Thu, 1 Mar 2001 15:51:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00275 Thu, 1 Mar 2001 17:29:22 -0500 (EST) From: "Joseph D. Harwood" To: "Kais Belgaied" , Cc: , Subject: RE: Label on the H-b-H (was Re: Internet Draft for explicit security labels in IPv6. ) Date: Thu, 1 Mar 2001 14:33:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200103012217.OAA13178@domus.ebay.sun.com> X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you, that clarifies the situation a great deal. Since the packet must be tunneled between SG1 and SG2 (it's transit traffic, Tunnel Mode is required), ESP could be used as well as AH and this would also protect the security label of the inner packet. Perhaps this option could be included in the draft. Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: Kais Belgaied [mailto:kais@domus.ebay.sun.com] > Sent: Thursday, March 01, 2001 2:18 PM > To: jharwood@vesta-corp.com; smb@research.att.com > Cc: ipng@sunroof.eng.sun.com; ipsec@lists.tislabs.com > Subject: Label on the H-b-H (was Re: Internet Draft for explicit > security labels in IPv6. ) > > > For a router to trust a label in the hop-by-hop header, it has to either > *believe* the packet is authentic (packet coming in through an interface > connected to a highly secured network), or it is the other end (dst) of an > AH AS protecting the labeled packet. > > Here is an example: > > Secure (trusted) Unsecure network Secure network > network (non trustworthy) > /------\ //----\\ /------\ > | | | | | | > Host1 --| |-- SGW1--| | --SGW2--| |--- Host2 > | | | | | | > \------/ \\----// \------/ > > The security policy requires that data at certain labels follow > certain paths > inside the secure networks, and that it is offered a certain > protection when > travelling through untrusted clouds. The inside routers in the > trusted networks > will use the label for trusted routing. Edge routers SGW1 & SGW2 > MUST use an AH > SA > > If confidentiality is required, An additional AH ESP between > Host1 and Host2 > can be used. > > Kais. > > >> > >>My understanding of the draft was that, one of the goals is for > intervening > >>routers to be able to make routing decisions based on the > contents of the > >>security label (Section 3.4): > >> > >> A router needs to trust the authenticity and integrity of a > >> packet before making routing decision based on the content of its > >> label. > >> > >>The proposal is to permit security labels in Hop-By-Hop > Extension Headers, > >>which (if I remember correctly) are only protected by AH. > >> > >>This would seem to require AH. > > > >But intermediate routers don't have the keys to verify the AH header. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > > > > From owner-ipsec@lists.tislabs.com Fri Mar 2 08:01:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA14448; Fri, 2 Mar 2001 08:01:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02741 Fri, 2 Mar 2001 09:26:35 -0500 (EST) Message-Id: <200103012217.OAA13178@domus.ebay.sun.com> Date: Thu, 1 Mar 2001 14:17:51 -0800 (PST) From: Kais Belgaied Reply-To: Kais Belgaied Subject: Label on the H-b-H (was Re: Internet Draft for explicit security labels in IPv6. ) To: jharwood@vesta-corp.com, smb@research.att.com Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ewZT/G6IUA/GlJEWEZO9jw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.4 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For a router to trust a label in the hop-by-hop header, it has to either *believe* the packet is authentic (packet coming in through an interface connected to a highly secured network), or it is the other end (dst) of an AH AS protecting the labeled packet. Here is an example: Secure (trusted) Unsecure network Secure network network (non trustworthy) /------\ //----\\ /------\ | | | | | | Host1 --| |-- SGW1--| | --SGW2--| |--- Host2 | | | | | | \------/ \\----// \------/ The security policy requires that data at certain labels follow certain paths inside the secure networks, and that it is offered a certain protection when travelling through untrusted clouds. The inside routers in the trusted networks will use the label for trusted routing. Edge routers SGW1 & SGW2 MUST use an AH SA If confidentiality is required, An additional AH ESP between Host1 and Host2 can be used. Kais. >> >>My understanding of the draft was that, one of the goals is for intervening >>routers to be able to make routing decisions based on the contents of the >>security label (Section 3.4): >> >> A router needs to trust the authenticity and integrity of a >> packet before making routing decision based on the content of its >> label. >> >>The proposal is to permit security labels in Hop-By-Hop Extension Headers, >>which (if I remember correctly) are only protected by AH. >> >>This would seem to require AH. > >But intermediate routers don't have the keys to verify the AH header. > > --Steve Bellovin, http://www.research.att.com/~smb > > From owner-ipsec@lists.tislabs.com Fri Mar 2 12:44:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA02680; Fri, 2 Mar 2001 12:44:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03866 Fri, 2 Mar 2001 14:05:54 -0500 (EST) To: ddp@cips.nokia.COM CC: sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com In-reply-to: <200102222114.NAA00762@gallium.network-alchemy.com> (ddp@cips.nokia.COM) Subject: Re: exchange type 6? From: tytso@mit.edu Phone: (781) 391-3464 References: <200102222114.NAA00762@gallium.network-alchemy.com> Message-Id: Date: Fri, 02 Mar 2001 14:09:19 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Thu, 22 Feb 2001 13:14:18 -0800 From: "Derrell D. Piper" > Mark exchange type 6 as reserved/deprecated/..., and let's move on. No > need to officially document what it was, but at least mark the pit so > nobody stumbles into it by accident. I agree that informing the IANA not to allocate exchange type 6 makes sense. I'm not quite so sure that it's worthwhile to document it, at least not until ISPRA finishes its work, at which point documenting it as historical would probably make sense. There's a certain amount of negotiation here between the ISPRA and AD's that's probably required here. Hear, hear. I wish this would have happened for RIPEMD-160 HMAC as well. (I often wonder if that draft was just forgotten during the RFC process...) Yeah, it was forgotten. My bad. If there's a substantial number of people who are using it, getting it revived and pushed through a wg last call would certainly be possible. - Ted From owner-ipsec@lists.tislabs.com Fri Mar 2 12:44:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA02693; Fri, 2 Mar 2001 12:44:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03956 Fri, 2 Mar 2001 14:21:58 -0500 (EST) From: Kais Belgaied Message-Id: <200103021906.LAA20429@domus.ebay.sun.com> Subject: Re: Internet Draft for explicit security labels in IPv6. In-Reply-To: <20010301214444.AA30435C42@berkshire.research.att.com> from "Steven M. Bellovin" at "Mar 1, 2001 04:44:44 pm" To: "Steven M. Bellovin" Date: Fri, 2 Mar 2001 11:06:26 -0800 (PST) CC: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, I a gree with S Kent, J. Hardwood and S. Bellovin on the ESP tunnel mode (Thank y'all). I shall update the draft to reflect the the 2 possibilities, AH (+ESP) in transport mode, and tunnel mode ESP with the label on the h-b-h of the inner header. > >>>it. In a link-local scope, where the label is proposed to be carried in the > >>>destination header, ESP is mandatory and sufficient. > >>>On a wider scope, AH is necessary. > >> > >>Or it could be bound to the certificate and recreated at the far end. > > > >It could, with the scalability limitation of implicit labeling. > > > I'm afraid I don't see the limitation. The certificate itself could > contain the label. > > There are two cases, transport mode IPsec and tunnel mode. In tunnel > mode, as Kent pointed out, there is an inner IP header, option fields, > etc.; in this case, the receiving gateway may wish to verify the labels > in the inner header, but need do nothing. > > Transport mode is end-to-end, in which case the machine receiving the > packet is either the ultimate end point -- in which case it can extract > the label from the certificate and pass them up to TCP together -- or > it's a bump-in-the-{wire,stack} on that machine. In such cases, it > should be quite straightforward to add the certificate's label -- if > nothing else, it's already reassembling the packet to combine the IP > header and the body, which were separated by the IPsec header. > Yes, it is feasable, but my understanding is that the certificate attributes cannot be easily changed without re-negotiating it. The limitation is regarding situations like the following example: A backup server being accessed from remote multilevel secure hosts using an NFS mount. The client (system being backed up) will be using one TCP connection to the server, and the filesystems on both sides will be using the services of an RPC layer that share the use of that single connection. The data in the client packets can come from files at a very wide range of labels, and need to be preserved at the backup file system. We can have one instance of the NFS daemon per possible label, and one tcp connection at each label between the client and server. The label is retreived from the certificate, so one certificate per sensitivity is needed. A typical sensitivity label has a classification 16-bits wide, and 240 category bits, that can combine to a big number. I'm afraid maintaining that number of contexts, or switching back and forth between them can be too costly. Kais. > --Steve Bellovin, http://www.research.att.com/~smb > > From owner-ipsec@lists.tislabs.com Fri Mar 2 12:55:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA03470; Fri, 2 Mar 2001 12:55:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04148 Fri, 2 Mar 2001 14:48:31 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103021906.LAA20429@domus.ebay.sun.com> References: <200103021906.LAA20429@domus.ebay.sun.com> Date: Fri, 2 Mar 2001 14:46:12 -0500 To: Kais Belgaied From: Stephen Kent Subject: Re: Internet Draft for explicit security labels in IPv6. Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kais, >First, I a gree with S Kent, J. Hardwood and S. Bellovin on the ESP tunnel >mode (Thank y'all). I shall update the draft to reflect the the >2 possibilities, AH (+ESP) in transport mode, and tunnel mode ESP with the >label on the h-b-h of the inner header. > > > >>>it. In a link-local scope, where the label is proposed to be >carried in the > > >>>destination header, ESP is mandatory and sufficient. > > >>>On a wider scope, AH is necessary. > > >> > > >>Or it could be bound to the certificate and recreated at the far end. > > > > > >It could, with the scalability limitation of implicit labeling. > > > > > I'm afraid I don't see the limitation. The certificate itself could > > contain the label. > > > > There are two cases, transport mode IPsec and tunnel mode. In tunnel > > mode, as Kent pointed out, there is an inner IP header, option fields, > > etc.; in this case, the receiving gateway may wish to verify the labels > > in the inner header, but need do nothing. > > > > Transport mode is end-to-end, in which case the machine receiving the > > packet is either the ultimate end point -- in which case it can extract > > the label from the certificate and pass them up to TCP together -- or > > it's a bump-in-the-{wire,stack} on that machine. In such cases, it > > should be quite straightforward to add the certificate's label -- if > > nothing else, it's already reassembling the packet to combine the IP > > header and the body, which were separated by the IPsec header. > > >Yes, it is feasable, but my understanding is that the certificate attributes >cannot be easily changed without re-negotiating it. >The limitation is regarding situations like the following example: >A backup server being accessed from remote multilevel secure hosts >using an NFS >mount. The client (system being backed up) will be using one TCP connection >to the server, and the filesystems on both sides will be using the services of >an RPC layer that share the use of that single connection. >The data in the client packets can come from >files at a very wide range of labels, and need to be preserved at the backup >file system. We can have one instance of the NFS daemon per possible label, >and one tcp connection at each label between the client and server. >The label is retreived from the certificate, so one certificate per >sensitivity >is needed. >A typical sensitivity label has a classification 16-bits wide, and 240 >category bits, that can combine to a big number. I'm afraid maintaining that >number of contexts, or switching back and forth between them can be >too costly. In this example, I think it makes more sense to have the security labels carried by the application, not IP. What you are creating is a multi-level secure TCP connection to carry the file transfer traffic. Each file has a level bound to it by the client OS and you need to maintain that label at the server. Thus the server has a means to tag entries in the file system and that seems like the right place to make the labels visible. If the labels are per packet, and you rely on the OS to keep the data separated, then you would be demuxing the data stream into a lot of processes anyway, if you did it on a per level and per category set basis, which is something you seem to reject above. Steve From owner-ipsec@lists.tislabs.com Fri Mar 2 15:56:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA18348; Fri, 2 Mar 2001 15:56:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04731 Fri, 2 Mar 2001 17:18:04 -0500 (EST) Message-Id: <4.3.2.7.0.20010302150326.01bf63c0@cougar.chiplogic.com> X-Sender: ramana@cougar.chiplogic.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Mar 2001 15:07:26 -0800 To: ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Random # genaerator Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, All Are there any Random number generator algorithms that are required with in the IPSec framework? Can some body through some light there -thanks in advance -ramana From owner-ipsec@lists.tislabs.com Fri Mar 2 17:28:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA24539; Fri, 2 Mar 2001 17:28:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04953 Fri, 2 Mar 2001 18:31:38 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103012217.OAA13178@domus.ebay.sun.com> References: <200103012217.OAA13178@domus.ebay.sun.com> Date: Fri, 2 Mar 2001 18:37:12 -0500 To: Kais Belgaied From: Stephen Kent Subject: Re: Label on the H-b-H (was Re: Internet Draft for explicit security labels in IPv6. ) Cc: ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kais, >For a router to trust a label in the hop-by-hop header, it has to either >*believe* the packet is authentic (packet coming in through an interface >connected to a highly secured network), or it is the other end (dst) of an >AH AS protecting the labeled packet. > >Here is an example: > > Secure (trusted) Unsecure network Secure network > network (non trustworthy) > /------\ //----\\ /------\ > | | | | | | >Host1 --| |-- SGW1--| | --SGW2--| |--- Host2 > | | | | | | > \------/ \\----// \------/ > >The security policy requires that data at certain labels follow certain paths >inside the secure networks, and that it is offered a certain protection when >travelling through untrusted clouds. The inside routers in the >trusted networks >will use the label for trusted routing. Edge routers SGW1 & SGW2 >MUST use an AH >SA > >If confidentiality is required, An additional AH ESP between Host1 and Host2 >can be used. I would expect SGW1 and SGW2 to establish an ESP tunnel between them, invoking integrity and authenticity for that tunnel (maybe confidentiality too) and that the security label would not be "visible" to the unsecure network. IPsec mandates that this SA be a tunnel, so the protection offered to the label by that SA, as I described above, is just right for your purpose. Steve From owner-ipsec@lists.tislabs.com Fri Mar 2 19:13:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA27586; Fri, 2 Mar 2001 19:13:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05441 Fri, 2 Mar 2001 21:03:17 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Joseph D. Harwood" Cc: "Ipsec" Subject: Re: SHA-256/384/512 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Mar 2001 21:06:48 -0500 Message-Id: <20010303020649.E844435C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Joseph D. H arwood" writes: >This is a multi-part message in MIME format. > >------=_NextPart_000_0016_01C0A342.630F73E0 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit > >In looking over Steve Kent's slides from the IPsec working group meeting on >"IPsec Enhancements for High Speed Networks," it discusses only AES-MAC for >authentication. Does this mean HMAC-SHA256 (/384/512) are not being >considered? > At the moment, it's easier to build very fast hardware encryptors than very fast hardware SHA chips. No one is deprecating HMAC; it's just that it's not the best choice for very high speed nets. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Fri Mar 2 19:14:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA27606; Fri, 2 Mar 2001 19:14:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05397 Fri, 2 Mar 2001 20:53:17 -0500 (EST) From: "Joseph D. Harwood" To: "Ipsec" Subject: SHA-256/384/512 Date: Fri, 2 Mar 2001 17:58:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C0A342.630F73E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C0A342.630F73E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In looking over Steve Kent's slides from the IPsec working group meeting on "IPsec Enhancements for High Speed Networks," it discusses only AES-MAC for authentication. Does this mean HMAC-SHA256 (/384/512) are not being considered? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com ------=_NextPart_000_0016_01C0A342.630F73E0 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0016_01C0A342.630F73E0-- From owner-ipsec@lists.tislabs.com Sat Mar 3 09:26:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA19658; Sat, 3 Mar 2001 09:26:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06927 Sat, 3 Mar 2001 11:32:07 -0500 (EST) Message-ID: From: "Yap, Alister" To: "'ipsec@lists.tislabs.com'" Subject: IPSec Provisioning Tools Date: Sat, 3 Mar 2001 16:35:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi! Does anyone know/recommend any tools for provisioning IPSec VPN tunnels? Thanks in advance. Alister ********************************************************************** COLT Telecommunications Registered in England No. 2452736 Registered Office: Bishopsgate Court, 4 Norton Folgate, London E1 6DQ Tel. 020 7390 3900 This message is subject to and does not create or vary any contractual relationship between COLT Telecommunications, its subsidiaries or affiliates ("COLT") and you. Internet communications are not secure and therefore COLT does not accept legal responsibility for the contents of this message. Any view or opinions expressed are those of the author. The message is intended for the addressee only and its contents and any attached files are strictly confidential. If you have received it in error, please telephone the number above. Thank you. ********************************************************************** From owner-ipsec@lists.tislabs.com Sat Mar 3 09:26:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA19652; Sat, 3 Mar 2001 09:26:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06834 Sat, 3 Mar 2001 11:00:56 -0500 (EST) Message-Id: <200103022334.f22NXxj08064@thunk.east.sun.com> From: Bill Sommerfeld To: Kais Belgaied cc: "Steven M. Bellovin" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com, jharwood@vesta-corp.com Subject: Re: Internet Draft for explicit security labels in IPv6. In-reply-to: Your message of "Fri, 02 Mar 2001 11:06:26 PST." <200103021906.LAA20429@domus.ebay.sun.com> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 02 Mar 2001 18:33:59 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure what problem you're trying to solve, but: - The assumption in the draft seems to be that SA's are heavy-weight objects. this is not the case and it is certainly my intent to ensure that they are as lightweight as possible within Sun's ipsec implementation.. - I agree with what Steve Kent's analysis -- if you are exchanging multi-level tagged data over an transport connection, the processes on both end had better be highly trusted to bypass MLS and thus you should be able to get by labelling the connection as "system high" (or some other appropriate concept) and using application-layer tagging for the data inside. I'd hate to see what you'd need to do to a TCP implementation and API to carry through security label markings on arbitrary byte boundaries within the streams on both ends. - I can see a couple different ways to handle communicating the label through IKE. As Steve Bellovin suggested, the simplest way is for the appropriate label to end up in the certificate. That clearly doesn't scale in the case of the trusted multi-level applications you described; in that case, it makes sense for the certificate to describe a range of possible labels, and for an additional attribute to show up in the IKE phase 2 exchange containing a specific label to use for the traffic. - Bill From owner-ipsec@lists.tislabs.com Sat Mar 3 10:18:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA22930; Sat, 3 Mar 2001 10:18:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07006 Sat, 3 Mar 2001 12:24:19 -0500 (EST) From: "Joseph D. Harwood" To: Cc: "Ipsec" Subject: RE: SHA-256/384/512 Date: Sat, 3 Mar 2001 09:29:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C0A3C4.782B6040" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010303020649.E844435C42@berkshire.research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C0A3C4.782B6040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks for your feedback. A related question about AES counter mode for encryption with AES-MAC for authentication... The slides proposed AES counter mode so data blocks could be encrypted in parallel (unlike CBC, which requires the results from block N before beginning encryption of block N+1). If I remember correctly, MAC authentication would be encrypting every block via AES using some sort of feedback, and using the final ciphertext as the authentication data. Something like: Hash[n+1] = Block[n+1] ^ Encrypt(Data = Block[n+1],Key = Hash[n]) AES-MAC == Hash[Last Block] This means AES-MAC for authentication would have a similar performance to AES-CBC for encryption, so there wouldn't be an overall performance advantage in using AES counter mode with parallel hardware for encryption. Is this correct? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: smb@research.att.com [mailto:smb@research.att.com] > Sent: Friday, March 02, 2001 6:07 PM > To: Joseph D. Harwood > Cc: Ipsec > Subject: Re: SHA-256/384/512 > > > In message > , "Joseph D. H > arwood" writes: > >This is a multi-part message in MIME format. > > > >------=_NextPart_000_0016_01C0A342.630F73E0 > >Content-Type: text/plain; > > charset="iso-8859-1" > >Content-Transfer-Encoding: 7bit > > > >In looking over Steve Kent's slides from the IPsec working group > meeting on > >"IPsec Enhancements for High Speed Networks," it discusses only > AES-MAC for > >authentication. Does this mean HMAC-SHA256 (/384/512) are not being > >considered? > > > At the moment, it's easier to build very fast hardware encryptors than > very fast hardware SHA chips. No one is deprecating HMAC; it's just > that it's not the best choice for very high speed nets. > > > --Steve Bellovin, http://www.research.att.com/~smb > > > ------=_NextPart_000_0008_01C0A3C4.782B6040 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0008_01C0A3C4.782B6040-- From owner-ipsec@lists.tislabs.com Sat Mar 3 19:57:37 2001 Received: from lists.tislabs.com ([192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA00591; Sat, 3 Mar 2001 19:57:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08305 Sat, 3 Mar 2001 21:14:41 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Joseph D. Harwood" Cc: "Ipsec" Subject: Re: SHA-256/384/512 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Mar 2001 19:48:17 -0500 Message-Id: <20010304004818.EE66535C44@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Joseph D. H arwood" writes: >A related question about AES counter mode for encryption with AES-MAC for >authentication... > >The slides proposed AES counter mode so data blocks could be encrypted in >parallel (unlike CBC, which requires the results from block N before >beginning encryption of block N+1). If I remember correctly, MAC >authentication would be encrypting every block via AES using some sort of >feedback, and using the final ciphertext as the authentication data. >Something like: > >Hash[n+1] = Block[n+1] ^ Encrypt(Data = Block[n+1],Key = Hash[n]) >AES-MAC == Hash[Last Block] > >This means AES-MAC for authentication would have a similar performance to >AES-CBC for encryption, so there wouldn't be an overall performance >advantage in using AES counter mode with parallel hardware for encryption. >Is this correct? Yes -- I raised precisely this objection to counter mode, both at the IPsec wg meeting and at the NIST Modes of Operation workshop. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Mon Mar 5 14:22:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA26084; Mon, 5 Mar 2001 14:22:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13667 Mon, 5 Mar 2001 15:37:57 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "David A. McGrew" Cc: "Joseph D. Harwood" , Ipsec Subject: Re: SHA-256/384/512 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Mar 2001 15:41:32 -0500 Message-Id: <20010305204133.6A9FE35C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3AA3F843.8135D875@cisco.com>, "David A. McGrew" writes: >Steve, > > >I agree that current message authentication methods are the bottleneck in this >scenario. However, I don't agree with the inference that counter mode is not >worthwhile, as faster, paralellizable authentication methods exist and are >easily adaptable to ESP. Of course, it remains to agree which of those method >s >is worthwhile and produce a spec. > >IIRC, the other objection to CM that you raised was that the lack of an explic >it >IV makes CM vulnerable if the same key is used within multiple SAs. While thi >s >is clearly an important caveat for CM, proper key management would prevent thi >s >from happening. There would need to be a series of failures for this to happe >n >with IKE, for example. IMHO, the lower encapsulation overhead that is >achievable with CM is one of the advantages of having real key management. My two major objections to counter mode are, as you say, (a) it doesn't do any good without a suitable authentication scheme, and (b) the catastrophic failure mode if the same key and counter are reused. I'm certainly open to arguments that other authentication schemes than HMAC are fast enough and secure enough, though I don't know that there's consensus on that point. But I'm much more loathe to accept assurances on point (b). Sure, we could mandate that counter mode only be used with IKE (or better). I don't think folks will listen... More seriously, accidents do happen, if only because of bad PRNG seeds. I don't like to tempt fate. My preference is for one of the integrated secrecy+authentication modes. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Mon Mar 5 14:22:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA26094; Mon, 5 Mar 2001 14:22:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13650 Mon, 5 Mar 2001 15:27:31 -0500 (EST) Message-ID: <3AA3F843.8135D875@cisco.com> Date: Mon, 05 Mar 2001 15:34:11 -0500 From: "David A. McGrew" X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: "Joseph D. Harwood" , Ipsec Subject: Re: SHA-256/384/512 References: <20010304004818.EE66535C44@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, "Steven M. Bellovin" wrote: > > In message , "Joseph D. H > arwood" writes: > > >A related question about AES counter mode for encryption with AES-MAC for > >authentication... > > > >The slides proposed AES counter mode so data blocks could be encrypted in > >parallel (unlike CBC, which requires the results from block N before > >beginning encryption of block N+1). If I remember correctly, MAC > >authentication would be encrypting every block via AES using some sort of > >feedback, and using the final ciphertext as the authentication data. > >Something like: > > > >Hash[n+1] = Block[n+1] ^ Encrypt(Data = Block[n+1],Key = Hash[n]) > >AES-MAC == Hash[Last Block] > > > >This means AES-MAC for authentication would have a similar performance to > >AES-CBC for encryption, so there wouldn't be an overall performance > >advantage in using AES counter mode with parallel hardware for encryption. > >Is this correct? > > Yes -- I raised precisely this objection to counter mode, both at the > IPsec wg meeting and at the NIST Modes of Operation workshop. > > --Steve Bellovin, http://www.research.att.com/~smb I agree that current message authentication methods are the bottleneck in this scenario. However, I don't agree with the inference that counter mode is not worthwhile, as faster, paralellizable authentication methods exist and are easily adaptable to ESP. Of course, it remains to agree which of those methods is worthwhile and produce a spec. IIRC, the other objection to CM that you raised was that the lack of an explicit IV makes CM vulnerable if the same key is used within multiple SAs. While this is clearly an important caveat for CM, proper key management would prevent this from happening. There would need to be a series of failures for this to happen with IKE, for example. IMHO, the lower encapsulation overhead that is achievable with CM is one of the advantages of having real key management. David mcgrew@cisco.com From owner-ipsec@lists.tislabs.com Mon Mar 5 20:00:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA09100; Mon, 5 Mar 2001 20:00:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14497 Mon, 5 Mar 2001 21:24:18 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Joseph D. Harwood" Cc: "Kais Belgaied" , ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com Subject: Re: Internet Draft for explicit security labels in IPv6. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Mar 2001 21:27:41 -0500 Message-Id: <20010306022745.7F69435C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Joseph D. H arwood" writes: >This is a multi-part message in MIME format. > >------=_NextPart_000_0022_01C0A245.80C7E140 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit > >My understanding of the draft was that, one of the goals is for intervening >routers to be able to make routing decisions based on the contents of the >security label (Section 3.4): > > A router needs to trust the authenticity and integrity of a > packet before making routing decision based on the content of its > label. > >The proposal is to permit security labels in Hop-By-Hop Extension Headers, >which (if I remember correctly) are only protected by AH. > >This would seem to require AH. As I noted earlier, the intervening routers don't have the key to verify the AH protection. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Wed Mar 7 07:56:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA28958; Wed, 7 Mar 2001 07:56:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20258 Wed, 7 Mar 2001 08:59:58 -0500 (EST) From: pbs63055@etri.re.kr Message-ID: <21B2FBDAE847D411A8BA009027A128B901175FCF@cms3.etri.re.kr> To: ipsec@lists.tislabs.com Subject: [Q]work ipsec with l2tp... Date: Wed, 7 Mar 2001 16:05:43 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A6D5.065B1050" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A6D5.065B1050 Content-Type: text/plain; charset="euc-kr" I want some information about IPsec with L2TP. I'm going to build the IPsec tunnel on the L2TP tunnel. Is it strange? Is there any case like this already implemented? I'm not an english and an american so that my letter may be strange. If it is possible, please send how to work. ------_=_NextPart_001_01C0A6D5.065B1050 Content-Type: text/html; charset="euc-kr" I want some information about IPsec with L2TP. I'm going to build the IPsec tunnel on the L2TP tunnel. Is it strange? Is there any case like this already implemented? I'm not an english and an american so that my letter may be strange. If it is possible, please send how to work. ------_=_NextPart_001_01C0A6D5.065B1050-- From owner-ipsec@lists.tislabs.com Mon Mar 12 00:26:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA02737; Mon, 12 Mar 2001 00:26:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05387 Mon, 12 Mar 2001 01:51:38 -0500 (EST) MIME-Version: 1.0 Message-Id: <3AAC7329.04664@mta5> Date: Mon, 12 Mar 2001 14:56:41 +0800 (CST) From: "葛建军" To: ipsec@lists.tislabs.com Subject: hi!everyone(NULL) X-Priority: 3 X-Originating-IP: [202.204.5.27] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk _____________________________________________ 30款手机网上最低价 http://shopping.263.net/hotsale/topmobile/ 相遇的缘分 源于....... http://chat.263.net From owner-ipsec@lists.tislabs.com Mon Mar 12 08:16:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA23118; Mon, 12 Mar 2001 08:16:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06486 Mon, 12 Mar 2001 09:28:45 -0500 (EST) From: Skip Booth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15020.56429.157609.961973@ebooth-linux.cisco.com> Date: Mon, 12 Mar 2001 09:25:49 -0500 To: pbs63055@etri.re.kr Cc: ipsec@lists.tislabs.com Subject: Re: [Q]work ipsec with l2tp... In-Reply-To: <21B2FBDAE847D411A8BA009027A128B901175FCF@cms3.etri.re.kr> References: <21B2FBDAE847D411A8BA009027A128B901175FCF@cms3.etri.re.kr> X-Mailer: VM 6.90 under Emacs 20.5.1 Reply-To: ebooth@cisco.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk pbs63055@etri.re.kr writes: > I want some information about IPsec with L2TP. > > I'm going to build the IPsec tunnel on the L2TP tunnel. > > Is it strange? No. > > Is there any case like this already implemented? Yes. There are lots of interoperable solutions out there. > > > > I'm not an english and an american so that my letter may be strange. > > > > If it is possible, please send how to work. Please refer to the following draft for information on securing L2TP with IPsec. http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-security-02.txt -Skip > > > > > I want some information about IPsec with L2TP. > > I'm going to build the IPsec tunnel on the L2TP tunnel. > > Is it strange? > > Is there any case like this already implemented? > > > > I'm not an english and an american so that my letter may be strange. > > > > If it is possible, please send how to work. > > From owner-ipsec@lists.tislabs.com Mon Mar 12 11:39:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA27729; Mon, 12 Mar 2001 11:38:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07176 Mon, 12 Mar 2001 13:18:29 -0500 (EST) X-Delivered-For: X-mProtect: Mon, 12 Mar 2001 10:21:48 -0800 Nokia Silicon Valley Messaging Protection Message-ID: <3AAD13B7.64B8E000@iprg.nokia.com> Date: Mon, 12 Mar 2001 10:21:43 -0800 From: Marc Solsona-Palomar X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: Ipsec Subject: Re: SHA-256/384/512 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is this presentation available in any way from the web. marc. "Joseph D. Harwood" wrote: > In looking over Steve Kent's slides from the IPsec working group meeting on > "IPsec Enhancements for High Speed Networks," it discusses only AES-MAC for > authentication. Does this mean HMAC-SHA256 (/384/512) are not being > considered? > > Best Regards, > Joseph D. Harwood > jharwood@vesta-corp.com > www.vesta-corp.com From owner-ipsec@lists.tislabs.com Mon Mar 12 13:14:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29754; Mon, 12 Mar 2001 13:14:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07504 Mon, 12 Mar 2001 15:05:06 -0500 (EST) Message-ID: <028601c0ab2f$e0068470$e42645ab@cisco.com> From: "Scott Fanning" To: "Enno Rey" , References: Subject: Re: IPsec between W2K and Cisco router Date: Mon, 12 Mar 2001 12:06:07 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is not the correct list. If you need specific product help, please contact the Cisco TAC. I am sure they can help. Thanks Regards Scott ----- Original Message ----- From: "Enno Rey" To: Sent: Monday, March 12, 2001 11:37 AM Subject: IPsec between W2K and Cisco router > Hi, > > I'm trying to configure IPsec between a Win2000 client and a cisco router in > a test environment. > The final goal is to implement a VPN for mobile users (using W2K on their > laptops and dialing into any ISP). > As I don't like to implement IPsec on a bastion host (separation of > duties... not to speak of performance problems) the endpoint for the VPN > connections shall be a corporate cisco router which terminates the IPsec > connection (+ L2TP connection on top of it). > > I'm working with W2K SP1 on the client side and a cisco 3620 running > 'c3620-is56i-mz.121-5.T.bin' (I know: early deployment... but then I'm able > to use SSH on the router... and don't blame me for not using 3DES... too > much effort to register on cco... and, as I said, it's just a test lab). > > And I want to use cert-based authentication... > > So, I installed an W2K-based CA with CEP add-on (from the rk) and got some > certs for the router and the client. > I ended up with the cisco claiming 'certificate invalid' during IKE several > times. > > Question 1.) Which type of cert should I use for the client to avoid this? I > tried several ones (the so called 'Ipsec cert', the 'client auth cert' and > others), without any success. I think W2K CA issues standard X509v3 certs > (but I'm not sure here, can anybody confirm or deny?). > Sure, I could install an Linux or BSD-based CA (e.g. isakmpd on one of my > OpenBSD boxes) but this would add even more heterogenity. > So, where is the problem for the cisco to accept the client's certificate?? > > ----- > > Then I broke down to 'pre-shared' to get it running and potentially find my > problem. Just for testing... I don't like the idea of using 'pre-shared'... > > Now I succeed in phase 1 and then this happens [taken from the router with > 'debug crypto isakmp']: > > *Mar 6 04:45:02: ISAKMP: transform 1, ESP_DES > *Mar 6 04:45:02: ISAKMP: attributes in transform: > *Mar 6 04:45:02: ISAKMP: SA life type in seconds > *Mar 6 04:45:02: ISAKMP: SA life duration (VPI) of 0x0 0x0 0x3 0x84 > *Mar 6 04:45:02: ISAKMP: SA life type in kilobytes > *Mar 6 04:45:02: ISAKMP: SA life duration (VPI) of 0x0 0x1 0x86 0xA0 > *Mar 6 04:45:02: ISAKMP: encaps is 2 > *Mar 6 04:45:02: ISAKMP: authenticator is HMAC-MD5 > *Mar 6 04:45:02: ISAKMP (0:3): atts are acceptable. > *Mar 6 04:45:02: ISAKMP (0:3): IPSec policy invalidated proposal > *Mar 6 04:45:02: ISAKMP (0:3): phase 2 SA not acceptable! > > Question2: > > What does 'IPsec policy invalidated proposal' mean? Which policy invalidated > whose proposal and for what possible reason? > > This is what I get on the client: > > 3-12: 19:18:33:160 Setting SA timeout: 25860 > 3-12: 19:18:33:160 Added Timeout af0a0 > 3-12: 19:18:33:160 Copying temp iv to sa->crypt_iv > 3-12: 19:18:33:160 Created new conn entry 23b4f0 > 3-12: 19:18:33:160 Starting QM with mess ID bb3bac5f > 3-12: 19:18:33:160 find(ipsec): da2998ca-d62c-44c5-92c1d0257ac79274 > 3-12: 19:18:33:160 GetSpi: src = 192.168.96.4.0000, dst = > 192.168.96.12.0000, proto = 00, context = 81301F28, srcMask = > 255.255.255.255, destMask = 255.255.255.255, TunnelFilter 0 > 3-12: 19:18:33:160 Setting SPI 594964592 > 3-12: 19:18:33:160 constructing ISAKMP Header > 3-12: 19:18:33:160 constructing HASH (null) > 3-12: 19:18:33:160 constructing SA (IPSEC) > 3-12: 19:18:33:160 constructing NONCE (IPSEC) > 3-12: 19:18:33:160 constructing ID (proxy) > 3-12: 19:18:33:160 constructing ID (proxy) > 3-12: 19:18:33:160 constructing HASH (QM) > 3-12: 19:18:33:160 Construct QM Hash mess ID = 1605123003 > 3-12: 19:18:33:160 Throw: State mask=30000 > 3-12: 19:18:33:160 Doing DES > 3-12: 19:18:33:160 Added Timeout b1cd8 > 3-12: 19:18:33:160 Setting Retransmit: sa 23cc90 centry 23b4f0 handle b1cd8 > context 23ab38 > 3-12: 19:18:33:160 > 3-12: 19:18:33:160 Sending: SA = 0x0023CC90 to 192.168.96.4 > 3-12: 19:18:33:160 ISAKMP Header: (V1.0), len = 268 > 3-12: 19:18:33:160 I-COOKIE a7f1496896f5bbde > 3-12: 19:18:33:160 R-COOKIE 6408de5fe3fa3d3a > 3-12: 19:18:33:160 exchange: Oakley Quick Mode > 3-12: 19:18:33:160 flags: 1 ( encrypted ) > 3-12: 19:18:33:160 next payload: HASH > 3-12: 19:18:33:160 message ID: bb3bac5f > 3-12: 19:18:33:160 > 3-12: 19:18:33:160 Resume: (get) SA = 0x0023cc90 from 192.168.96.4 > 3-12: 19:18:33:160 ISAKMP Header: (V1.0), len = 244 > 3-12: 19:18:33:160 I-COOKIE a7f1496896f5bbde > 3-12: 19:18:33:160 R-COOKIE 6408de5fe3fa3d3a > 3-12: 19:18:33:160 exchange: ISAKMP Informational Exchange > 3-12: 19:18:33:160 flags: 1 ( encrypted ) > 3-12: 19:18:33:160 next payload: HASH > 3-12: 19:18:33:160 message ID: ec51de13 > 3-12: 19:18:33:160 Doing DES > 3-12: 19:18:33:160 Received InfoExchange with mess ID 3964788243 > 3-12: 19:18:33:160 processing HASH (ND) > 3-12: 19:18:33:160 ND Verify Hash skeyid_a 02097b90ceddbfe5f5ecb9518b5e2426 > 3-12: 19:18:33:160 e3db3240 > 3-12: 19:18:33:160 Verify ND Hash mess ID ec51de13 > 3-12: 19:18:33:160 Verify ND hash message len = 184 hdrlen=236 hashpl=24 > 3-12: 19:18:33:160 ND Hash message 000000b8000000010304000e23767070 > 3-12: 19:18:33:160 0a0000a8000000010000000100000000 > 3-12: 19:18:33:160 62533dfc000000006254994461165bac > 3-12: 19:18:33:160 010000180000007462533dfc623ab008 > 3-12: 19:18:33:160 01549944623ab08862549944623ab088 > 3-12: 19:18:33:160 62540fdc0000000802c043d800000001 > 3-12: 19:18:33:160 6207d8f461164a5862533ea40000010c > 3-12: 19:18:33:160 bb3bac5f623ab038bb3bac5f00000000 > 3-12: 19:18:33:160 0000010c61d900006207d8f4611666ec > 3-12: 19:18:33:160 61f5196c61f582d8623ab0b4623ab088 > 3-12: 19:18:33:160 0100000c6116541061a00000623ab0b0 > 3-12: 19:18:33:160 62533ec862533dc8 > 3-12: 19:18:33:160 processing payload NOTIFY > 3-12: 19:18:33:160 notify: NO-PROPOSAL-CHOSEN > > ---------- > > Thanks a lot for any advice or pointer & > > regards, > > Enno Rey > > PGP 74C0 C7E1 3875 E4EB 9B75 8B9D 5E2D 3178 685B F222 > From owner-ipsec@lists.tislabs.com Mon Mar 12 13:19:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29900; Mon, 12 Mar 2001 13:19:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07425 Mon, 12 Mar 2001 14:31:21 -0500 (EST) From: "Enno Rey" To: Subject: IPsec between W2K and Cisco router Date: Mon, 12 Mar 2001 20:37:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm trying to configure IPsec between a Win2000 client and a cisco router in a test environment. The final goal is to implement a VPN for mobile users (using W2K on their laptops and dialing into any ISP). As I don't like to implement IPsec on a bastion host (separation of duties... not to speak of performance problems) the endpoint for the VPN connections shall be a corporate cisco router which terminates the IPsec connection (+ L2TP connection on top of it). I'm working with W2K SP1 on the client side and a cisco 3620 running 'c3620-is56i-mz.121-5.T.bin' (I know: early deployment... but then I'm able to use SSH on the router... and don't blame me for not using 3DES... too much effort to register on cco... and, as I said, it's just a test lab). And I want to use cert-based authentication... So, I installed an W2K-based CA with CEP add-on (from the rk) and got some certs for the router and the client. I ended up with the cisco claiming 'certificate invalid' during IKE several times. Question 1.) Which type of cert should I use for the client to avoid this? I tried several ones (the so called 'Ipsec cert', the 'client auth cert' and others), without any success. I think W2K CA issues standard X509v3 certs (but I'm not sure here, can anybody confirm or deny?). Sure, I could install an Linux or BSD-based CA (e.g. isakmpd on one of my OpenBSD boxes) but this would add even more heterogenity. So, where is the problem for the cisco to accept the client's certificate?? ----- Then I broke down to 'pre-shared' to get it running and potentially find my problem. Just for testing... I don't like the idea of using 'pre-shared'... Now I succeed in phase 1 and then this happens [taken from the router with 'debug crypto isakmp']: *Mar 6 04:45:02: ISAKMP: transform 1, ESP_DES *Mar 6 04:45:02: ISAKMP: attributes in transform: *Mar 6 04:45:02: ISAKMP: SA life type in seconds *Mar 6 04:45:02: ISAKMP: SA life duration (VPI) of 0x0 0x0 0x3 0x84 *Mar 6 04:45:02: ISAKMP: SA life type in kilobytes *Mar 6 04:45:02: ISAKMP: SA life duration (VPI) of 0x0 0x1 0x86 0xA0 *Mar 6 04:45:02: ISAKMP: encaps is 2 *Mar 6 04:45:02: ISAKMP: authenticator is HMAC-MD5 *Mar 6 04:45:02: ISAKMP (0:3): atts are acceptable. *Mar 6 04:45:02: ISAKMP (0:3): IPSec policy invalidated proposal *Mar 6 04:45:02: ISAKMP (0:3): phase 2 SA not acceptable! Question2: What does 'IPsec policy invalidated proposal' mean? Which policy invalidated whose proposal and for what possible reason? This is what I get on the client: 3-12: 19:18:33:160 Setting SA timeout: 25860 3-12: 19:18:33:160 Added Timeout af0a0 3-12: 19:18:33:160 Copying temp iv to sa->crypt_iv 3-12: 19:18:33:160 Created new conn entry 23b4f0 3-12: 19:18:33:160 Starting QM with mess ID bb3bac5f 3-12: 19:18:33:160 find(ipsec): da2998ca-d62c-44c5-92c1d0257ac79274 3-12: 19:18:33:160 GetSpi: src = 192.168.96.4.0000, dst = 192.168.96.12.0000, proto = 00, context = 81301F28, srcMask = 255.255.255.255, destMask = 255.255.255.255, TunnelFilter 0 3-12: 19:18:33:160 Setting SPI 594964592 3-12: 19:18:33:160 constructing ISAKMP Header 3-12: 19:18:33:160 constructing HASH (null) 3-12: 19:18:33:160 constructing SA (IPSEC) 3-12: 19:18:33:160 constructing NONCE (IPSEC) 3-12: 19:18:33:160 constructing ID (proxy) 3-12: 19:18:33:160 constructing ID (proxy) 3-12: 19:18:33:160 constructing HASH (QM) 3-12: 19:18:33:160 Construct QM Hash mess ID = 1605123003 3-12: 19:18:33:160 Throw: State mask=30000 3-12: 19:18:33:160 Doing DES 3-12: 19:18:33:160 Added Timeout b1cd8 3-12: 19:18:33:160 Setting Retransmit: sa 23cc90 centry 23b4f0 handle b1cd8 context 23ab38 3-12: 19:18:33:160 3-12: 19:18:33:160 Sending: SA = 0x0023CC90 to 192.168.96.4 3-12: 19:18:33:160 ISAKMP Header: (V1.0), len = 268 3-12: 19:18:33:160 I-COOKIE a7f1496896f5bbde 3-12: 19:18:33:160 R-COOKIE 6408de5fe3fa3d3a 3-12: 19:18:33:160 exchange: Oakley Quick Mode 3-12: 19:18:33:160 flags: 1 ( encrypted ) 3-12: 19:18:33:160 next payload: HASH 3-12: 19:18:33:160 message ID: bb3bac5f 3-12: 19:18:33:160 3-12: 19:18:33:160 Resume: (get) SA = 0x0023cc90 from 192.168.96.4 3-12: 19:18:33:160 ISAKMP Header: (V1.0), len = 244 3-12: 19:18:33:160 I-COOKIE a7f1496896f5bbde 3-12: 19:18:33:160 R-COOKIE 6408de5fe3fa3d3a 3-12: 19:18:33:160 exchange: ISAKMP Informational Exchange 3-12: 19:18:33:160 flags: 1 ( encrypted ) 3-12: 19:18:33:160 next payload: HASH 3-12: 19:18:33:160 message ID: ec51de13 3-12: 19:18:33:160 Doing DES 3-12: 19:18:33:160 Received InfoExchange with mess ID 3964788243 3-12: 19:18:33:160 processing HASH (ND) 3-12: 19:18:33:160 ND Verify Hash skeyid_a 02097b90ceddbfe5f5ecb9518b5e2426 3-12: 19:18:33:160 e3db3240 3-12: 19:18:33:160 Verify ND Hash mess ID ec51de13 3-12: 19:18:33:160 Verify ND hash message len = 184 hdrlen=236 hashpl=24 3-12: 19:18:33:160 ND Hash message 000000b8000000010304000e23767070 3-12: 19:18:33:160 0a0000a8000000010000000100000000 3-12: 19:18:33:160 62533dfc000000006254994461165bac 3-12: 19:18:33:160 010000180000007462533dfc623ab008 3-12: 19:18:33:160 01549944623ab08862549944623ab088 3-12: 19:18:33:160 62540fdc0000000802c043d800000001 3-12: 19:18:33:160 6207d8f461164a5862533ea40000010c 3-12: 19:18:33:160 bb3bac5f623ab038bb3bac5f00000000 3-12: 19:18:33:160 0000010c61d900006207d8f4611666ec 3-12: 19:18:33:160 61f5196c61f582d8623ab0b4623ab088 3-12: 19:18:33:160 0100000c6116541061a00000623ab0b0 3-12: 19:18:33:160 62533ec862533dc8 3-12: 19:18:33:160 processing payload NOTIFY 3-12: 19:18:33:160 notify: NO-PROPOSAL-CHOSEN ---------- Thanks a lot for any advice or pointer & regards, Enno Rey PGP 74C0 C7E1 3875 E4EB 9B75 8B9D 5E2D 3178 685B F222 From owner-ipsec@lists.tislabs.com Mon Mar 12 14:43:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA04217; Mon, 12 Mar 2001 14:43:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07675 Mon, 12 Mar 2001 16:15:54 -0500 (EST) From: "Joseph D. Harwood" To: "Marc Solsona-Palomar" Cc: "Ipsec" Subject: RE: SHA-256/384/512 Date: Mon, 12 Mar 2001 13:21:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C0AAF7.53952060" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AAD13B7.64B8E000@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C0AAF7.53952060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Steve posted it to the IPsec mail list a couple of weeks ago. I believe you can retrieve a copy from: www.vpnc.org Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Marc Solsona-Palomar > Sent: Monday, March 12, 2001 10:22 AM > To: jharwood@vesta-corp.com > Cc: Ipsec > Subject: Re: SHA-256/384/512 > > > Is this presentation available in any way from the web. > > marc. > > "Joseph D. Harwood" wrote: > > > In looking over Steve Kent's slides from the IPsec working > group meeting on > > "IPsec Enhancements for High Speed Networks," it discusses only > AES-MAC for > > authentication. Does this mean HMAC-SHA256 (/384/512) are not being > > considered? > > > > Best Regards, > > Joseph D. Harwood > > jharwood@vesta-corp.com > > www.vesta-corp.com > > ------=_NextPart_000_0018_01C0AAF7.53952060 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0018_01C0AAF7.53952060-- From owner-ipsec@lists.tislabs.com Mon Mar 12 16:22:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA08297; Mon, 12 Mar 2001 16:22:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07839 Mon, 12 Mar 2001 17:49:38 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Mon, 12 Mar 2001 14:53:03 -0800 To: "Joseph D. Harwood" , "Marc Solsona-Palomar" From: Paul Hoffman / VPNC Subject: RE: SHA-256/384/512 Cc: "Ipsec" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Specifically, see the link near the bottom of . --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 12 20:14:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA15128; Mon, 12 Mar 2001 20:14:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08399 Mon, 12 Mar 2001 21:43:44 -0500 (EST) To: ipsec@lists.tislabs.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: AH with SHA-256/384/512 From: itojun@iijlab.net Date: Tue, 13 Mar 2001 11:47:33 +0900 Message-ID: <27541.984451653@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sorry if i'm asking a dumb thing - were there any drafts on SHA-256/384/512 use on AH? I saw ISAKMP # assigned by IANA but failed to find any draft/RFC for it. (like, how many bits of crypto checksum do i need to attach? 96bit?) itojun From owner-ipsec@lists.tislabs.com Tue Mar 13 12:23:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01321; Tue, 13 Mar 2001 12:23:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11528 Tue, 13 Mar 2001 13:17:37 -0500 (EST) Message-ID: <3AAE6525.F4752D8A@F-Secure.com> Date: Tue, 13 Mar 2001 20:21:25 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: ipsec@lists.tislabs.com Subject: Re: AH with SHA-256/384/512 References: <27541.984451653@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk itojun@iijlab.net wrote: > > sorry if i'm asking a dumb thing - were there any drafts on > SHA-256/384/512 use on AH? I saw ISAKMP # assigned by IANA > but failed to find any draft/RFC for it. (like, how many bits of > crypto checksum do i need to attach? 96bit?) > > itojun I wonder.. Is there any real reason to use these with AH or ESP? Wouldn't one have to break the authentication algorithm pretty much in real time if one wants to fake authentication? Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Mar 14 01:38:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA26227; Wed, 14 Mar 2001 01:38:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA13529 Wed, 14 Mar 2001 03:03:11 -0500 (EST) content-class: urn:content-classes:message Subject: apologies MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 14 Mar 2001 09:08:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <93E299DA8B7DD411904300D0B7D48343115FC4@ns-exchange-se.northstream.se> Thread-Topic: IPsec between W2K and Cisco router Thread-Index: AcCrR6g6YZy91P26So6MxabJImw33ABFZGsQ From: "Caerwyn Pearce" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA13526 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, Sorry, I appear to have been reposible for sending a message to the list entitled 'hi!everyone' with a couple of shopping links in it. I guess I've been a virus victim but I can't quite see how it worked there was no enclosure in the original and I didn't open the links. It doesn't seem to be destructive but apologies for proliferating email junk. (Of course I'm adding to the problem by writing this but one has to maintain some standards in a hitech world!) don't flame me, but if you have any idea how it worked or what I should check to get rid of it then I'd be happy to hear from you. Neither Norton AV or FSecure anti virus picked it up. Regards Caerwyn From owner-ipsec@lists.tislabs.com Wed Mar 14 16:40:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA02400; Wed, 14 Mar 2001 16:40:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16364 Wed, 14 Mar 2001 18:03:46 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Agenda for the Minneapolis meeting From: tytso@mit.edu Phone: (781) 391-3464 Message-Id: Date: Wed, 14 Mar 2001 18:07:40 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, My apologies for not prepared an agenda earlier; both Barbara and I have been rather swamped at work lately..... This agenda is a draft; if you would like to request some time at the IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many thanks. - Ted A. D. Keromytis On the Use of SCTP with IPsec Dan Harkins "Son of Ike" IPSEC MIB documents draft-ietf-ipsec-isakmp-di-mon-mib-03.txt draft-ietf-ipsec-ike-monitor-mib-02.txt draft-ietf-ipsec-monitor-mib-04.txt Jari Arkko -- IPSEC and IPV6 Effects on ICMPv6 on IKE and IPsec Policies Manual SA Configuration for IPv6 Link Local Messages Tissa Senevirathne http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt IPSEC and NAT Markus Stenberg draft-stenberg-ipsec-nat-traversal-02 William Dixon draft-huttunen-ipsec-esp-in-udp-01 From owner-ipsec@lists.tislabs.com Wed Mar 14 16:40:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA02414; Wed, 14 Mar 2001 16:40:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16402 Wed, 14 Mar 2001 18:29:20 -0500 (EST) Message-ID: <01d401c0acde$b430ad20$e42645ab@cisco.com> From: "Scott Fanning" To: , References: Subject: Re: Agenda for the Minneapolis meeting Date: Wed, 14 Mar 2001 15:30:07 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For those of us not able to attend Minneapolis, is there any info on "Son of IKE" that we can comment on via this list before the meeting? Thanks Scott ----- Original Message ----- From: To: Sent: Wednesday, March 14, 2001 3:07 PM Subject: Agenda for the Minneapolis meeting > Hi all, > > My apologies for not prepared an agenda earlier; both Barbara and I have > been rather swamped at work lately..... > > This agenda is a draft; if you would like to request some time at the > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many thanks. > > - Ted > > A. D. Keromytis > > On the Use of SCTP with IPsec > > Dan Harkins > > "Son of Ike" > > IPSEC MIB documents > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > draft-ietf-ipsec-ike-monitor-mib-02.txt > draft-ietf-ipsec-monitor-mib-04.txt > > Jari Arkko -- IPSEC and IPV6 > > Effects on ICMPv6 on IKE and IPsec Policies > Manual SA Configuration for IPv6 Link Local Messages > > Tissa Senevirathne > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt > > IPSEC and NAT > > Markus Stenberg > > draft-stenberg-ipsec-nat-traversal-02 > > William Dixon > > draft-huttunen-ipsec-esp-in-udp-01 > > From owner-ipsec@lists.tislabs.com Wed Mar 14 17:55:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA05896; Wed, 14 Mar 2001 17:55:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16616 Wed, 14 Mar 2001 19:50:01 -0500 (EST) Message-Id: <200103150050.f2F0oAx26150@potassium.cips.nokia.com> To: "Scott Fanning" cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: Your message of "Wed, 14 Mar 2001 15:30:07 PST." <01d401c0acde$b430ad20$e42645ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26147.984617410.1@potassium.cips.nokia.com> Date: Wed, 14 Mar 2001 16:50:10 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't have any powerpoint slides or anything like that but what I'm going to talk about is: *) what is this-- RFC2407+RFC2408+RFC2409 = new draft *) why do this? - we have an overly complex way to get SAs for IPsec. - a general feeling of "I don't like IKE", published criticism, and general fear of an overly complex security protocol. - it's not so bad that we need to throw it all out and start over again-- there are nice features to keep. *) why do we have what we have? - original idea of a generic transport (ISAKMP) which could have multiple key exchanges defined on it, a generic key exchange which can establish "security associations" for multiple services, and a service definition for IPsec. - these layers created ambiguity. - key management war resulted in a please all people at all costs mentality that caused an explosion of options. *) what does it mean to combine these three RFCs? - no "layer violations" when defining things (like the commit bit: it's from a header defined in RFC2408 used in an exchange defined in RFC2409 because of an aspect of the service defined in RFC2407) so we gain in clarity. - we lose the generic transport and generic key exchange and gain a key exchange and security association establishment protocol for IPsec. - some things, like Aggressive Mode and New Group Mode, get left behind for possible redefinition and advancement in an independent draft. - advances in the state-of-the-art should depricate some of the mandatory options-- DES, group1-- and that can happen in a rewrite. - many of the suggestions for protocol improvement can be incorporated. How many and which ones is up to the working group. I'm glad this is eliciting interest. I've brought the subject up on the list in the past and there didn't seem to be much interest. Please comment! There has also been an offline discussion about not caling it IKE anymore since it won't really be IKE and any comments on that idea are solicited as well. Dan. On Wed, 14 Mar 2001 15:30:07 PST you wrote > For those of us not able to attend Minneapolis, is there any info on "Son of > IKE" that we can comment on via this list before the meeting? > > Thanks > Scott > ----- Original Message ----- > From: > To: > Sent: Wednesday, March 14, 2001 3:07 PM > Subject: Agenda for the Minneapolis meeting > > > > Hi all, > > > > My apologies for not prepared an agenda earlier; both Barbara and I have > > been rather swamped at work lately..... > > > > This agenda is a draft; if you would like to request some time at the > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many thanks. > > > > - Ted > > > > A. D. Keromytis > > > > On the Use of SCTP with IPsec > > > > Dan Harkins > > > > "Son of Ike" > > > > IPSEC MIB documents > > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > > draft-ietf-ipsec-ike-monitor-mib-02.txt > > draft-ietf-ipsec-monitor-mib-04.txt > > > > Jari Arkko -- IPSEC and IPV6 > > > > Effects on ICMPv6 on IKE and IPsec Policies > > Manual SA Configuration for IPv6 Link Local Messages > > > > Tissa Senevirathne > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt > > > > IPSEC and NAT > > > > Markus Stenberg > > > > draft-stenberg-ipsec-nat-traversal-02 > > > > William Dixon > > > > draft-huttunen-ipsec-esp-in-udp-01 > > > > > From owner-ipsec@lists.tislabs.com Wed Mar 14 20:00:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA08622; Wed, 14 Mar 2001 20:00:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16897 Wed, 14 Mar 2001 21:59:58 -0500 (EST) From: Mike_Borella@3com.com X-Lotus-FromDomain: 3COM To: Dan Harkins cc: "Scott Fanning" , ipsec@lists.tislabs.com Message-ID: <88256A10.0010C493.00@hqoutbound.ops.3com.com> Date: Wed, 14 Mar 2001 21:01:52 -0600 Subject: Re: Agenda for the Minneapolis meeting Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FWIW, all of the below are cool ideas. My very cheap 2 cents: o Clarify the ephemerality of the IKE source port o Words on IKE over SCTP Mike Dan Harkins on 03/14/2001 06:50:10 PM Sent by: Dan Harkins To: "Scott Fanning" cc: ipsec@lists.tislabs.com (Mike Borella/MW/US/3Com) Subject: Re: Agenda for the Minneapolis meeting I don't have any powerpoint slides or anything like that but what I'm going to talk about is: *) what is this-- RFC2407+RFC2408+RFC2409 = new draft *) why do this? - we have an overly complex way to get SAs for IPsec. - a general feeling of "I don't like IKE", published criticism, and general fear of an overly complex security protocol. - it's not so bad that we need to throw it all out and start over again-- there are nice features to keep. *) why do we have what we have? - original idea of a generic transport (ISAKMP) which could have multiple key exchanges defined on it, a generic key exchange which can establish "security associations" for multiple services, and a service definition for IPsec. - these layers created ambiguity. - key management war resulted in a please all people at all costs mentality that caused an explosion of options. *) what does it mean to combine these three RFCs? - no "layer violations" when defining things (like the commit bit: it's from a header defined in RFC2408 used in an exchange defined in RFC2409 because of an aspect of the service defined in RFC2407) so we gain in clarity. - we lose the generic transport and generic key exchange and gain a key exchange and security association establishment protocol for IPsec. - some things, like Aggressive Mode and New Group Mode, get left behind for possible redefinition and advancement in an independent draft. - advances in the state-of-the-art should depricate some of the mandatory options-- DES, group1-- and that can happen in a rewrite. - many of the suggestions for protocol improvement can be incorporated. How many and which ones is up to the working group. I'm glad this is eliciting interest. I've brought the subject up on the list in the past and there didn't seem to be much interest. Please comment! There has also been an offline discussion about not caling it IKE anymore since it won't really be IKE and any comments on that idea are solicited as well. Dan. On Wed, 14 Mar 2001 15:30:07 PST you wrote > For those of us not able to attend Minneapolis, is there any info on "Son of > IKE" that we can comment on via this list before the meeting? > > Thanks > Scott > ----- Original Message ----- > From: > To: > Sent: Wednesday, March 14, 2001 3:07 PM > Subject: Agenda for the Minneapolis meeting > > > > Hi all, > > > > My apologies for not prepared an agenda earlier; both Barbara and I have > > been rather swamped at work lately..... > > > > This agenda is a draft; if you would like to request some time at the > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many thanks. > > > > - Ted > > > > A. D. Keromytis > > > > On the Use of SCTP with IPsec > > > > Dan Harkins > > > > "Son of Ike" > > > > IPSEC MIB documents > > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > > draft-ietf-ipsec-ike-monitor-mib-02.txt > > draft-ietf-ipsec-monitor-mib-04.txt > > > > Jari Arkko -- IPSEC and IPV6 > > > > Effects on ICMPv6 on IKE and IPsec Policies > > Manual SA Configuration for IPv6 Link Local Messages > > > > Tissa Senevirathne > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt > > > > IPSEC and NAT > > > > Markus Stenberg > > > > draft-stenberg-ipsec-nat-traversal-02 > > > > William Dixon > > > > draft-huttunen-ipsec-esp-in-udp-01 > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 15 09:46:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25590; Thu, 15 Mar 2001 09:46:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18659 Thu, 15 Mar 2001 11:11:53 -0500 (EST) Message-ID: <007601c0ad6a$d2acea20$e42645ab@cisco.com> From: "Scott Fanning" To: , "Dan Harkins" Cc: References: <88256A10.0010C493.00@hqoutbound.ops.3com.com> Subject: Re: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 08:13:07 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My even cheaper 2 cents :-) - Incorporate the spirit of the revised hash. - Clarify rekeying. When to use the new SAs vs Old ones etc. - Eliminate KB lifetimes. - Clearly define certificate handling. Remove ambiguities. Things like some vendors will not sent certs (even if negotiated) unless specifically asked. I think this is the right behavour as, with multiple root support, it would be nice to know what chain of trust is applicable to the peer-to-peer communication. Sending all of the certs on a head end route would no doubt be very expensive. - Any chance of Going with base mode as a compromise between AG and MM? - Better defined Notify messages and actions on receipt of them. Scott Kellys work is pretty good in this direction. - Remove new group mode. Regards Scott ----- Original Message ----- From: To: "Dan Harkins" Cc: "Scott Fanning" ; Sent: Wednesday, March 14, 2001 7:01 PM Subject: Re: Agenda for the Minneapolis meeting > > > > FWIW, all of the below are cool ideas. My very cheap 2 cents: > > o Clarify the ephemerality of the IKE source port > o Words on IKE over SCTP > > Mike > > > > > > Dan Harkins on 03/14/2001 06:50:10 PM > > Sent by: Dan Harkins > > > To: "Scott Fanning" > cc: ipsec@lists.tislabs.com (Mike Borella/MW/US/3Com) > Subject: Re: Agenda for the Minneapolis meeting > > > > I don't have any powerpoint slides or anything like that but what I'm > going to talk about is: > > *) what is this-- RFC2407+RFC2408+RFC2409 = new draft > *) why do this? > - we have an overly complex way to get SAs for IPsec. > - a general feeling of "I don't like IKE", published > criticism, and general fear of an overly complex > security protocol. > - it's not so bad that we need to throw it all out > and start over again-- there are nice features to keep. > *) why do we have what we have? > - original idea of a generic transport (ISAKMP) which could > have multiple key exchanges defined on it, a generic key > exchange which can establish "security associations" for > multiple services, and a service definition for IPsec. > - these layers created ambiguity. > - key management war resulted in a please all people at all > costs mentality that caused an explosion of options. > *) what does it mean to combine these three RFCs? > - no "layer violations" when defining things (like the commit > bit: it's from a header defined in RFC2408 used in an exchange > defined in RFC2409 because of an aspect of the service defined > in RFC2407) so we gain in clarity. > - we lose the generic transport and generic key exchange and > gain a key exchange and security association establishment > protocol for IPsec. > - some things, like Aggressive Mode and New Group Mode, get > left behind for possible redefinition and advancement in an > independent draft. > - advances in the state-of-the-art should depricate some of the > mandatory options-- DES, group1-- and that can happen in a > rewrite. > - many of the suggestions for protocol improvement can be > incorporated. How many and which ones is up to the working > group. > > I'm glad this is eliciting interest. I've brought the subject up on the > list in the past and there didn't seem to be much interest. Please comment! > There has also been an offline discussion about not caling it IKE anymore > since it won't really be IKE and any comments on that idea are solicited > as well. > > Dan. > > On Wed, 14 Mar 2001 15:30:07 PST you wrote > > For those of us not able to attend Minneapolis, is there any info on "Son of > > IKE" that we can comment on via this list before the meeting? > > > > Thanks > > Scott > > ----- Original Message ----- > > From: > > To: > > Sent: Wednesday, March 14, 2001 3:07 PM > > Subject: Agenda for the Minneapolis meeting > > > > > > > Hi all, > > > > > > My apologies for not prepared an agenda earlier; both Barbara and I have > > > been rather swamped at work lately..... > > > > > > This agenda is a draft; if you would like to request some time at the > > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many thanks. > > > > > > - Ted > > > > > > A. D. Keromytis > > > > > > On the Use of SCTP with IPsec > > > > > > Dan Harkins > > > > > > "Son of Ike" > > > > > > IPSEC MIB documents > > > > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > > > draft-ietf-ipsec-ike-monitor-mib-02.txt > > > draft-ietf-ipsec-monitor-mib-04.txt > > > > > > Jari Arkko -- IPSEC and IPV6 > > > > > > Effects on ICMPv6 on IKE and IPsec Policies > > > Manual SA Configuration for IPv6 Link Local Messages > > > > > > Tissa Senevirathne > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt > > > > > > IPSEC and NAT > > > > > > Markus Stenberg > > > > > > draft-stenberg-ipsec-nat-traversal-02 > > > > > > William Dixon > > > > > > draft-huttunen-ipsec-esp-in-udp-01 > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 15 09:47:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25609; Thu, 15 Mar 2001 09:47:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18723 Thu, 15 Mar 2001 11:29:14 -0500 (EST) Message-ID: <3AB0EEC1.87F38D05@F-Secure.com> Date: Thu, 15 Mar 2001 18:33:05 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: PKCS#1 in IKE vs. FIPS certification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just learned that FIPS will no longer approve the PKCS#1 standard, starting in June. Instead they will endorse some ANSI standard. The IKE RFC demands that PKCS#1 be used for RSA encryption and RSA signatures. So, will this mean that starting in June it will not be possible to create IKE/IPsec products for the US federal market, and use RSA signatures or RSA encryption? Or does it mean something else? Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Mar 15 10:26:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA27415; Thu, 15 Mar 2001 10:26:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18857 Thu, 15 Mar 2001 12:25:57 -0500 (EST) Message-ID: <8894CA1F87A5D411BD24009027EE783812802F@md-exchange1.nai.com> From: "Mason, David" To: "'Dan Harkins'" , Scott Fanning Cc: ipsec@lists.tislabs.com Subject: RE: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 09:25:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to see removal of the Commit Bit and just go with always using a 4 message Quick Mode (which gives the added benefit of allowing PFS Group negotiation by moving the initiator's KE payload from the first to the third message). -dave -----Original Message----- From: Dan Harkins [mailto:dharkins@cips.nokia.COM] Sent: Wednesday, March 14, 2001 7:50 PM To: Scott Fanning Cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting I don't have any powerpoint slides or anything like that but what I'm going to talk about is: *) what is this-- RFC2407+RFC2408+RFC2409 = new draft *) why do this? - we have an overly complex way to get SAs for IPsec. - a general feeling of "I don't like IKE", published criticism, and general fear of an overly complex security protocol. - it's not so bad that we need to throw it all out and start over again-- there are nice features to keep. *) why do we have what we have? - original idea of a generic transport (ISAKMP) which could have multiple key exchanges defined on it, a generic key exchange which can establish "security associations" for multiple services, and a service definition for IPsec. - these layers created ambiguity. - key management war resulted in a please all people at all costs mentality that caused an explosion of options. *) what does it mean to combine these three RFCs? - no "layer violations" when defining things (like the commit bit: it's from a header defined in RFC2408 used in an exchange defined in RFC2409 because of an aspect of the service defined in RFC2407) so we gain in clarity. - we lose the generic transport and generic key exchange and gain a key exchange and security association establishment protocol for IPsec. - some things, like Aggressive Mode and New Group Mode, get left behind for possible redefinition and advancement in an independent draft. - advances in the state-of-the-art should depricate some of the mandatory options-- DES, group1-- and that can happen in a rewrite. - many of the suggestions for protocol improvement can be incorporated. How many and which ones is up to the working group. I'm glad this is eliciting interest. I've brought the subject up on the list in the past and there didn't seem to be much interest. Please comment! There has also been an offline discussion about not caling it IKE anymore since it won't really be IKE and any comments on that idea are solicited as well. Dan. On Wed, 14 Mar 2001 15:30:07 PST you wrote > For those of us not able to attend Minneapolis, is there any info on "Son of > IKE" that we can comment on via this list before the meeting? > > Thanks > Scott > ----- Original Message ----- > From: > To: > Sent: Wednesday, March 14, 2001 3:07 PM > Subject: Agenda for the Minneapolis meeting > > > > Hi all, > > > > My apologies for not prepared an agenda earlier; both Barbara and I have > > been rather swamped at work lately..... > > > > This agenda is a draft; if you would like to request some time at the > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many thanks. > > > > - Ted > > > > A. D. Keromytis > > > > On the Use of SCTP with IPsec > > > > Dan Harkins > > > > "Son of Ike" > > > > IPSEC MIB documents > > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > > draft-ietf-ipsec-ike-monitor-mib-02.txt > > draft-ietf-ipsec-monitor-mib-04.txt > > > > Jari Arkko -- IPSEC and IPV6 > > > > Effects on ICMPv6 on IKE and IPsec Policies > > Manual SA Configuration for IPv6 Link Local Messages > > > > Tissa Senevirathne > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt > > > > IPSEC and NAT > > > > Markus Stenberg > > > > draft-stenberg-ipsec-nat-traversal-02 > > > > William Dixon > > > > draft-huttunen-ipsec-esp-in-udp-01 > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 15 10:27:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA27480; Thu, 15 Mar 2001 10:27:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18850 Thu, 15 Mar 2001 12:23:58 -0500 (EST) Message-ID: <3AB0FB5E.C89B0706@storm.ca> Date: Thu, 15 Mar 2001 12:26:54 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting References: <200103150050.f2F0oAx26150@potassium.cips.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > - advances in the state-of-the-art should depricate some of the > mandatory options-- DES, group1-- and that can happen in a > rewrite. Can we please have AES as a MUST? It has survived really intensive analysis. The teams for other AES candidates had several of the world's top people on them -- Biham, Coppersmith, ... None of them found flaws in Rijndael. It is roughly 10 times 3DES speed in software. Schneier gives figures in AC2 that have Blowfish more than 3 times single DES speed. He says elsewhere Twofish is faster than Blowfish, and AES tests showed Twofish and Rijndael roughly comparable. Finally, there are several readily available implementations with open licenses. At least the reference implementation on the authors' site and Brian Gladman's version. From owner-ipsec@lists.tislabs.com Thu Mar 15 10:29:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA27585; Thu, 15 Mar 2001 10:29:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18881 Thu, 15 Mar 2001 12:32:28 -0500 (EST) Date: Thu, 15 Mar 2001 12:35:40 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: PKCS#1 in IKE vs. FIPS certification In-Reply-To: <3AB0EEC1.87F38D05@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Mar 2001, Ari Huttunen wrote: > I just learned that FIPS will no longer approve the PKCS#1 standard... > So, will this mean that starting in June it will not be possible to > create IKE/IPsec products for the US federal market, and use RSA signatures > or RSA encryption? Or does it mean something else? No, even in the worst case, it just means that products for the US federal market have to have two modes: federal-spec-compliant mode, and actual-use mode. This is far from new. For purposes of US federal procurement, Windows is POSIX compliant. Not that you can actually *do* anything useful with it when running that way, but technically it meets the spec. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 15 11:45:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA02297; Thu, 15 Mar 2001 11:45:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19019 Thu, 15 Mar 2001 13:28:05 -0500 (EST) From: FRousseau@chrysalis-its.com Message-ID: <918C70B01822D411A87400B0D0204DFF72F671@panda.chrysalis-its.com> To: Ari.Huttunen@F-Secure.com Cc: ipsec@lists.tislabs.com Subject: RE: PKCS #1 in IKE vs. FIPS certification Date: Thu, 15 Mar 2001 13:31:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD7E.33E6456C" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0AD7E.33E6456C Content-Type: text/plain; charset="iso-8859-1" Ari, This is not exactly what I read in the Future Plans from the NIST cryptographic toolkit web page about Digital Signatures at (http://csrc.nist.gov/encryption/tkdigsigs.html): "NIST also intends to adopt PKCS #1 as an approved technique for RSA digital signatures. (Currently, this is only allowed under the transition period for FIPS 186-2, which is scheduled to end July 27, 2001.)" Note also that NIST has currently no FIPS-approved public key-based techniques as per the NIST cryptographic toolkit web page about Key Management (http://csrc.nist.gov/encryption/tkkeymgmt.html). Cheers, Francois -----Original Message----- From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com] Sent: Thursday, March 15, 2001 11:33 To: ipsec@lists.tislabs.com Subject: PKCS#1 in IKE vs. FIPS certification I just learned that FIPS will no longer approve the PKCS#1 standard, starting in June. Instead they will endorse some ANSI standard. The IKE RFC demands that PKCS#1 be used for RSA encryption and RSA signatures. So, will this mean that starting in June it will not be possible to create IKE/IPsec products for the US federal market, and use RSA signatures or RSA encryption? Or does it mean something else? Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security ------_=_NextPart_001_01C0AD7E.33E6456C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PKCS #1 in IKE vs. FIPS certification

Ari,

This is not exactly what I read in the Future Plans = from the NIST cryptographic toolkit web page about Digital Signatures = at (http://csrc.nist.gov/encryption/tkdigsigs.html):

"NIST also intends to adopt PKCS #1 as an = approved technique for RSA digital signatures.  (Currently, this = is only allowed under the transition period for FIPS 186-2, which is = scheduled to end July 27, 2001.)"

Note also that NIST has currently no FIPS-approved = public key-based techniques as per the NIST cryptographic toolkit web = page about Key Management (http://csrc.nist.gov/encryption/tkkeymgmt.html).

Cheers,

Francois


-----Original Message-----
From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.c= om]
Sent: Thursday, March 15, 2001 11:33
To: ipsec@lists.tislabs.com
Subject: PKCS#1 in IKE vs. FIPS certification


I just learned that FIPS will no longer approve the = PKCS#1 standard,
starting in June. Instead they will endorse some = ANSI standard.
The IKE RFC demands that PKCS#1 be used for RSA = encryption and RSA signatures.

So, will this mean that starting in June it will not = be possible to
create IKE/IPsec products for the US federal market, = and use RSA signatures
or RSA encryption? Or does it mean something = else?

Ari

--
Ari = Huttunen          &nbs= p;        phone: +358 9 2520 = 0700
Software = Architect          &nb= sp;  fax  : +358 9 2520 5001

F-Secure = Corporation       http://www.F-Secure.com

F-Secure products: Integrated Solutions for = Enterprise Security

------_=_NextPart_001_01C0AD7E.33E6456C-- From owner-ipsec@lists.tislabs.com Thu Mar 15 11:48:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA02524; Thu, 15 Mar 2001 11:48:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19043 Thu, 15 Mar 2001 13:31:08 -0500 (EST) Message-ID: <014301c0ad7e$46c87240$e42645ab@cisco.com> From: "Scott Fanning" To: "Sandy Harris" , References: <200103150050.f2F0oAx26150@potassium.cips.nokia.com> <3AB0FB5E.C89B0706@storm.ca> Subject: Re: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 10:32:22 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If AES is a must, would export be an issue? I am not sure what the rules around AES is. Would we then have to mandate the DH Group as well? I do not want to re-hash the argument that at every IETF for the last 2 years we have regarding this. In the networking world, and the security world, choices are just a part of life. 3DES is a MUST, AES is a SHOULD, and DES is a NOT. However, it is always the person deploying this technology that has to understand the risks. A protocol does not define a security policy, but facilitates its application. Scott ----- Original Message ----- From: "Sandy Harris" To: Sent: Thursday, March 15, 2001 9:26 AM Subject: Re: Agenda for the Minneapolis meeting > Dan Harkins wrote: > > > - advances in the state-of-the-art should depricate some of the > > mandatory options-- DES, group1-- and that can happen in a > > rewrite. > > Can we please have AES as a MUST? > > It has survived really intensive analysis. The teams for other AES candidates > had several of the world's top people on them -- Biham, Coppersmith, ... None > of them found flaws in Rijndael. > > It is roughly 10 times 3DES speed in software. Schneier gives figures in AC2 > that have Blowfish more than 3 times single DES speed. He says elsewhere Twofish > is faster than Blowfish, and AES tests showed Twofish and Rijndael roughly > comparable. > > Finally, there are several readily available implementations with open licenses. > At least the reference implementation on the authors' site and Brian Gladman's > version. From owner-ipsec@lists.tislabs.com Thu Mar 15 11:49:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA02589; Thu, 15 Mar 2001 11:49:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19105 Thu, 15 Mar 2001 13:40:13 -0500 (EST) Message-Id: <200103151842.f2FIglA17244@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: tytso@mit.edu cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-reply-to: Your message of Wed, 14 Mar 2001 18:07:40 EST. Date: Thu, 15 Mar 2001 19:42:45 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Jari Arkko -- IPSEC and IPV6 Effects on ICMPv6 on IKE and IPsec Policies Manual SA Configuration for IPv6 Link Local Messages => IPsec schedule conflicts with NGtrans first session. I suggest to find a way to get enough IPv6 people, for instance (the best way has still to be found) put this talk in the first or the last position in the agenda (of course, we need to look at this with NGtrans chairs too). Too many sessions at the same time... Regards Francis.Dupont@enst-bretagne.fr PS for Jari: I believe you need me, Itojun (or someone from KAME) and a Solaris/IPsec Sun expert (but they should prefer IPsec over NGtrans)... From owner-ipsec@lists.tislabs.com Thu Mar 15 11:57:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA02895; Thu, 15 Mar 2001 11:57:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19149 Thu, 15 Mar 2001 13:56:27 -0500 (EST) Date: Thu, 15 Mar 2001 10:59:48 -0800 (PST) From: Scott Fluhrer To: Sandy Harris cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: <3AB0FB5E.C89B0706@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Mar 2001, Sandy Harris wrote: > Dan Harkins wrote: > > > - advances in the state-of-the-art should depricate some of the > > mandatory options-- DES, group1-- and that can happen in a > > rewrite. > > Can we please have AES as a MUST? If we specify AES as a MUST, it might be somewhat helpful if we define exactly what transform/mode AES MUST be used in. I have heard nobody define how AES is to be used with IKE, although the 'CBC with implicit IV' would appear to be a good fit. There are three outstanding drafts for how AES is to be used for IPSec. I wrote up a review of them back in January on this mailing list. I would suggest that review be used as a starting place for deciding which transform should be mandated. > > It has survived really intensive analysis. The teams for other AES candidates > had several of the world's top people on them -- Biham, Coppersmith, ... None > of them found flaws in Rijndael. > > It is roughly 10 times 3DES speed in software. Schneier gives figures in AC2 > that have Blowfish more than 3 times single DES speed. He says elsewhere Twofish > is faster than Blowfish, and AES tests showed Twofish and Rijndael roughly > comparable. > > Finally, there are several readily available implementations with open licenses. > At least the reference implementation on the authors' site and Brian Gladman's > version. > From owner-ipsec@lists.tislabs.com Thu Mar 15 12:01:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA03268; Thu, 15 Mar 2001 12:01:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19194 Thu, 15 Mar 2001 14:11:29 -0500 (EST) Message-ID: <3AB11495.B431FFA5@storm.ca> Date: Thu, 15 Mar 2001 14:14:29 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting References: <200103150050.f2F0oAx26150@potassium.cips.nokia.com> <3AB0FB5E.C89B0706@storm.ca> <014301c0ad7e$46c87240$e42645ab@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fanning wrote: > > If AES is a must, would export be an issue? I am not sure what the rules > around AES is. ... Nor am I, but there is some reason for optimism. >From the site of the Wassenaar secretariat, who administer the international agreements on arms export control: "Summary of changes effective Dec 1 2000" http://www.wassenaar.org/list/Summary.html " 5.A.2. Cryptography Note " Cryptography Note d. has been deleted, as well as the related Validity Note The current text on cryptography is note 3 at: http://www.wassenaar.org/list/Cat%205P2%20-%2099.pdf The deleted point d. was the restriction to 64-bit keylength for exportable symmetric ciphers. So, in terms of international agreements -- which are, I think, what the IETF should base policy on -- there is absolutely no problem with export of AES. Of course the US gov't may do something different. The Wassenaar agreement has had a clause flatly saying public domain software was exempt from its controls for years. The US gov't ignored that clause as long as they could, despite being party to Wassenaar. They finally allowed export in their jan 2000 rule changes, but required notification to BXA. I've no idea whether or when the US will drop the 64-bit restriction. Perhaps they'll ignore the international agreement and keep the restriction. Methinks the IETF should, following RFC 1984, just go ahead and do the obviously right thing -- make AES a MUST -- whatever stance the US gov't may choose. From owner-ipsec@lists.tislabs.com Thu Mar 15 12:03:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA03361; Thu, 15 Mar 2001 12:03:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19182 Thu, 15 Mar 2001 14:09:33 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Scott Fanning'" , , "'Dan Harkins'" Cc: Subject: RE: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 14:04:35 -0500 Message-Id: <000901c0ad83$316a3960$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <007601c0ad6a$d2acea20$e42645ab@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One thing Scott said that is important is to remove ambiguity. Sometimes it is misguided to associate brevity with simpicity. ISAKMP is very long and convoluted, but at least it is unambiguous enough to prevent interoperability problems. How many times have you seen interoperability problem due to badly formed payloads on the wire as opposed to problems with rekeying or load sharing or cert usage or all those other things that were mostly left out of IKE. Some other wants: - 4 message non-encyrpting mode (i.e. base mode) - Dave Mason's 4 message QM instead of the commit bit fiasco. - message id as counter for replay protection - deprecate PFS (I wish) - specify placement of the cert request within the phase 1 exchange I still think removing the distinction between IKE and ISAKMP is very dangerous. We are only now beginning to see the benefits of separating the two. With work in progress on areas like MSEC, SMPLS, Tero's KINK draft, Jari's MAP DOI, I think we would be insane to merge the protocol layers at this point in the game Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott Fanning > Sent: Thursday, March 15, 2001 11:13 AM > To: Mike_Borella@3com.com; Dan Harkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Agenda for the Minneapolis meeting > > > My even cheaper 2 cents :-) > > - Incorporate the spirit of the revised hash. > - Clarify rekeying. When to use the new SAs vs Old ones etc. > - Eliminate KB lifetimes. > - Clearly define certificate handling. Remove ambiguities. > Things like some > vendors will not sent certs (even if negotiated) unless > specifically asked. > I think this is the right behavour as, with multiple root > support, it would > be nice to know what chain of trust is applicable to the peer-to-peer > communication. Sending all of the certs on a head end route > would no doubt > be very expensive. > - Any chance of Going with base mode as a compromise between > AG and MM? > - Better defined Notify messages and actions on receipt of them. Scott > Kellys work is pretty good in this direction. > - Remove new group mode. > > Regards > Scott > > > ----- Original Message ----- > From: > To: "Dan Harkins" > Cc: "Scott Fanning" ; > Sent: Wednesday, March 14, 2001 7:01 PM > Subject: Re: Agenda for the Minneapolis meeting > > > > > > > > > > FWIW, all of the below are cool ideas. My very cheap 2 cents: > > > > o Clarify the ephemerality of the IKE source port > > o Words on IKE over SCTP > > > > Mike > > > > > > > > > > > > Dan Harkins on 03/14/2001 06:50:10 PM > > > > Sent by: Dan Harkins > > > > > > To: "Scott Fanning" > > cc: ipsec@lists.tislabs.com (Mike Borella/MW/US/3Com) > > Subject: Re: Agenda for the Minneapolis meeting > > > > > > > > I don't have any powerpoint slides or anything like that > but what I'm > > going to talk about is: > > > > *) what is this-- RFC2407+RFC2408+RFC2409 = new draft > > *) why do this? > > - we have an overly complex way to get SAs for IPsec. > > - a general feeling of "I don't like IKE", published > > criticism, and general fear of an overly complex > > security protocol. > > - it's not so bad that we need to throw it all out > > and start over again-- there are nice features to keep. > > *) why do we have what we have? > > - original idea of a generic transport (ISAKMP) > which could > > have multiple key exchanges defined on it, a generic key > > exchange which can establish "security associations" for > > multiple services, and a service definition for IPsec. > > - these layers created ambiguity. > > - key management war resulted in a please all people at all > > costs mentality that caused an explosion of options. > > *) what does it mean to combine these three RFCs? > > - no "layer violations" when defining things > (like the commit > > bit: it's from a header defined in RFC2408 used > in an exchange > > defined in RFC2409 because of an aspect of the > service defined > > in RFC2407) so we gain in clarity. > > - we lose the generic transport and generic key exchange and > > gain a key exchange and security association establishment > > protocol for IPsec. > > - some things, like Aggressive Mode and New Group Mode, get > > left behind for possible redefinition and > advancement in an > > independent draft. > > - advances in the state-of-the-art should depricate > some of the > > mandatory options-- DES, group1-- and that can happen in a > > rewrite. > > - many of the suggestions for protocol improvement can be > > incorporated. How many and which ones is up to the working > > group. > > > > I'm glad this is eliciting interest. I've brought the > subject up on the > > list in the past and there didn't seem to be much interest. Please > comment! > > There has also been an offline discussion about not caling > it IKE anymore > > since it won't really be IKE and any comments on that idea > are solicited > > as well. > > > > Dan. > > > > On Wed, 14 Mar 2001 15:30:07 PST you wrote > > > For those of us not able to attend Minneapolis, is there > any info on > "Son of > > > IKE" that we can comment on via this list before the meeting? > > > > > > Thanks > > > Scott > > > ----- Original Message ----- > > > From: > > > To: > > > Sent: Wednesday, March 14, 2001 3:07 PM > > > Subject: Agenda for the Minneapolis meeting > > > > > > > > > > Hi all, > > > > > > > > My apologies for not prepared an agenda earlier; both > Barbara and I > have > > > > been rather swamped at work lately..... > > > > > > > > This agenda is a draft; if you would like to request > some time at the > > > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many > thanks. > > > > > > > > - Ted > > > > > > > > A. D. Keromytis > > > > > > > > On the Use of SCTP with IPsec > > > > > > > > Dan Harkins > > > > > > > > "Son of Ike" > > > > > > > > IPSEC MIB documents > > > > > > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > > > > draft-ietf-ipsec-ike-monitor-mib-02.txt > > > > draft-ietf-ipsec-monitor-mib-04.txt > > > > > > > > Jari Arkko -- IPSEC and IPV6 > > > > > > > > Effects on ICMPv6 on IKE and IPsec Policies > > > > Manual SA Configuration for IPv6 Link Local Messages > > > > > > > > Tissa Senevirathne > > > > > > > > > http://search.ietf.org/internet-drafts/draft-> tsenevir-smpls-doi-00.txt > > > > > > > > IPSEC and NAT > > > > > > > > Markus Stenberg > > > > > > > > draft-stenberg-ipsec-nat-traversal-02 > > > > > > > > William Dixon > > > > > > > > draft-huttunen-ipsec-esp-in-udp-01 > > > > > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 15 12:13:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA04013; Thu, 15 Mar 2001 12:13:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19220 Thu, 15 Mar 2001 14:22:22 -0500 (EST) Message-Id: <200103151922.f2FJMDx28708@potassium.cips.nokia.com> To: andrew.krywaniuk@alcatel.com cc: "'Scott Fanning'" , Mike_Borella@3com.com, ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: Your message of "Thu, 15 Mar 2001 14:04:35 EST." <000901c0ad83$316a3960$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28705.984684133.1@potassium.cips.nokia.com> Date: Thu, 15 Mar 2001 11:22:13 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can you be more specific on the danger? One problem I see with not combining the two is the trend to use UDP port 500 as a place to multiplex in different protocols. That is a bad thing, in my opinion. If MSEC wants to do a group DOI they should find a different port to do a multicast key exchange on. Part of this problem is compounded by the design of the SA payload in ISAKMP. The DOI is _inside_ the SA payload. So if there are multiple protocols all communicating on UDP port 500 you have to start parsing a payload before you find out the context under which you should parse it. Whoa! I think it is insane to not merge the two. We should dissuade people from this bad practice while things like kink and gdoi are still at internet-draft stage. Dan. On Thu, 15 Mar 2001 14:04:35 EST you wrote > > I still think removing the distinction between IKE and ISAKMP is very > dangerous. We are only now beginning to see the benefits of separating the > two. With work in progress on areas like MSEC, SMPLS, Tero's KINK draft, > Jari's MAP DOI, I think we would be insane to merge the protocol layers at > this point in the game > > Andrew From owner-ipsec@lists.tislabs.com Thu Mar 15 12:46:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA05427; Thu, 15 Mar 2001 12:46:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19344 Thu, 15 Mar 2001 14:52:03 -0500 (EST) Date: Thu, 15 Mar 2001 14:55:14 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: <200103151922.f2FJMDx28708@potassium.cips.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Mar 2001, Dan Harkins wrote: > One problem I see with not combining the two is the trend to use > UDP port 500 as a place to multiplex in different protocols. That is > a bad thing, in my opinion... Strongly agree. Dealing with IKE is bad enough, without adding an internal protocol multiplexer into the problem. We really ought to get the port-number assignment amended: udp/500 should be IKE, not ISAKMP. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 15 12:55:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA05649; Thu, 15 Mar 2001 12:55:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19316 Thu, 15 Mar 2001 14:47:25 -0500 (EST) Message-Id: <200103151950.f2FJor923510@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: "'Scott Fanning'" , Mike_Borella@3com.com, "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-reply-to: Your message of "Thu, 15 Mar 2001 14:04:35 EST." <000901c0ad83$316a3960$1e72788a@andrewk3.ca.alcatel.com> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 15 Mar 2001 14:50:53 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - Dave Mason's 4 message QM instead of the commit bit fiasco. IMHO, both the commit bit and 4-message QM are unnecessary. Before you can set up SA's, each end has to reserve an SPI and then communicate it to the peer. We create a "larval" SA at this time as a placeholder, since the SA tables are where we check for uniqueness of SPI values. You can buffer a (limited number) of received packets in the larval SA, and then process them once the keying material is available. This is exactly like buffering packets while you wait for an arp reply.. not strictly necessary for interoperability, but extremely useful in avoiding awkward pauses. From owner-ipsec@lists.tislabs.com Thu Mar 15 13:18:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA08175; Thu, 15 Mar 2001 13:18:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19490 Thu, 15 Mar 2001 15:26:58 -0500 (EST) Message-Id: <3.0.5.32.20010315215751.009c9bb0@pop.F-Secure.com> X-Sender: alexey@pop.F-Secure.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Mar 2001 21:57:51 +0200 To: ipsec@lists.tislabs.com From: Alexey Kirichenko Subject: RE: PKCS #1 in IKE vs. FIPS certification In-Reply-To: <918C70B01822D411A87400B0D0204DFF72F671@panda.chrysalis-its .com> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:31 PM 3/15/01 -0500, FRousseau@chrysalis-its.com wrote: >>>> Ari, This is not exactly what I read in the Future Plans from the NIST cryptographic toolkit web page about Digital Signatures at (http://csrc.nist.gov/encryption/tkdigsigs.html): "NIST also intends to adopt PKCS #1 as an approved technique for RSA digital signatures. (Currently, this is only allowed under the transition period for FIPS 186-2, which is scheduled to end July 27, 2001.)" Unfortunately, this is probably obsolete. I'm not 100% sure, but the news I got from a FIPS-140 validating lab was that effective from this June, signing with PKCS#1 RSA would not be FIPS-approved any more (but FIPS-certified modules will retain certification until next re-validating time). Vendors are encouraged to imlement, and use in FIPS mode of operating, a different method of signing with RSA specified in some ANSI document (don't remember the index). Alexey From owner-ipsec@lists.tislabs.com Thu Mar 15 13:21:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA08393; Thu, 15 Mar 2001 13:21:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19473 Thu, 15 Mar 2001 15:24:58 -0500 (EST) Message-Id: <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-reply-to: Your message of "Wed, 14 Mar 2001 16:50:10 PST." <200103150050.f2F0oAx26150@potassium.cips.nokia.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 Mar 2001 10:50:44 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> *) what does it mean to combine these three RFCs? Dan> - no "layer violations" when defining things (like the commit Dan> bit: it's from a header defined in RFC2408 used in an exchange Dan> defined in RFC2409 because of an aspect of the service defined Dan> in RFC2407) so we gain in clarity. Dan> - we lose the generic transport and generic key exchange and Dan> gain a key exchange and security association establishment Dan> protocol for IPsec. To what extent is this is a redefinition of the protocol --- i.e. a text change, and to what extent is this a change in the definition of the bits on the wire? Or is this the critical question? Will there be a requirements stage? My suggestion is: 1) rewrite/clarify the three RFCs into 1. particularly, clarify extension mechanisms. Publish. (no protocol changes) 2) establish chop list. Stuff we wish to deprecate, move to another document, etc. Publish. (only subtract/MAY-ify things) 3) establish requirements list, and identify people who want to work on these items, and form very short lived WGs to do these extensions. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Mar 15 13:23:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA08493; Thu, 15 Mar 2001 13:23:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19496 Thu, 15 Mar 2001 15:27:07 -0500 (EST) Date: Thu, 15 Mar 2001 22:29:42 +0200 (IST) From: Hugo Krawczyk To: Dan Harkins cc: ipsec list Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: <200103151922.f2FJMDx28708@potassium.cips.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I agree that one cannot expect a significant simplification of IKE without a simplification of ISAKMP. Yet it may be a good idea to keep two separate documents: one talking about formats and general functionalities related to SAs (payloads, message types, create, delete, etc) and the other describing the core cryptography. This will help mdularity which in turn should be good for implementation, for maintaining the standards, for future extensions and for analysis. These two aspects could be two parts of the same document, or they could be separate ones. What is important is that they have (at least) one editor in common. Hugo PS:If such a separation is adopted make sure that the forner document (the one talking about formats and general SA maintance actions) is agnostic about the cryptography, for example it should not mandate PFS, but leave these decisions to the other document (responsible for the cryptography itself). From owner-ipsec@lists.tislabs.com Thu Mar 15 13:26:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA08663; Thu, 15 Mar 2001 13:26:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19509 Thu, 15 Mar 2001 15:27:32 -0500 (EST) Message-ID: <8894CA1F87A5D411BD24009027EE7838128031@md-exchange1.nai.com> From: "Mason, David" To: "'sommerfeld@East.Sun.COM'" Cc: ipsec@lists.tislabs.com Subject: RE: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 12:27:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Most of the more mature IKE implementations probably already do this. The advantage of the 4 message phase two is that the group can be negotiated. If PFS is removed as someone suggested (I think it was Andrew's suggestion to just do another phase 1 as the means to provide PFS), then a 4 message phase 2 doesn't provide any benefit. But, I wouldn't object to having it for those people that don't want to do the buffering. The main thing is to get rid of the commit bit. -dave -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@East.Sun.COM] Sent: Thursday, March 15, 2001 2:51 PM To: andrew.krywaniuk@alcatel.com Cc: 'Scott Fanning'; Mike_Borella@3com.com; 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting > - Dave Mason's 4 message QM instead of the commit bit fiasco. IMHO, both the commit bit and 4-message QM are unnecessary. Before you can set up SA's, each end has to reserve an SPI and then communicate it to the peer. We create a "larval" SA at this time as a placeholder, since the SA tables are where we check for uniqueness of SPI values. You can buffer a (limited number) of received packets in the larval SA, and then process them once the keying material is available. This is exactly like buffering packets while you wait for an arp reply.. not strictly necessary for interoperability, but extremely useful in avoiding awkward pauses. From owner-ipsec@lists.tislabs.com Thu Mar 15 14:17:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA11873; Thu, 15 Mar 2001 14:17:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19831 Thu, 15 Mar 2001 15:54:41 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" Cc: Subject: RE: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 15:50:09 -0500 Message-Id: <001201c0ad91$866bd190$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200103151922.f2FJMDx28708@potassium.cips.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I think you are right about what you said concerning not reusing port 500, however that wasn't what I was thinking of. Right now, we have a division between payload formats, exchange types, and the DOI. This is a huge advantage if you are trying to write a new security protocol which is closely related to IKE. In many cases you only need to define a new DOI. Perhaps you only need a new exchange type or a new payload format. It really helps to break the problem down into its subcomponents. If there is a flaw in ISAKMP, it is that it both defines the payload formats and explains how to design a security protocol. The former is a useful reference, whereas the latter part is something you read mostly as background material. In fact, this is where most of the overlap with the IKE RFC occurs. Maybe some of the information on packet processing and protocol design should be moved into a separate document or incorporated into the new IKE document. I would be more inclined to separate the problem space into 4 or 5 shorter RFCs depending on factors like mutability, target audience, and value as an implementor's reference. Example (apologies if this wraps on your display): area currently k.a. audience referenced mutability ------------------ ------------------ ------------ ------------ -------- --- Protocol Design ISAKMP throughout integrator rare n/a Defn of Payloads ISAKMP middle implementor frequent rare DOI DOI implementor frequent frequent Negotiation IKE + ISAKMP end all frequent moderate Security Properties list archives all rare moderate Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@cips.nokia.COM] > Sent: Thursday, March 15, 2001 2:22 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Scott Fanning'; Mike_Borella@3com.com; ipsec@lists.tislabs.com > Subject: Re: Agenda for the Minneapolis meeting > > > Can you be more specific on the danger? > > One problem I see with not combining the two is the trend to use > UDP port 500 as a place to multiplex in different protocols. That is > a bad thing, in my opinion. If MSEC wants to do a group DOI > they should > find a different port to do a multicast key exchange on. Part of this > problem is compounded by the design of the SA payload in ISAKMP. The > DOI is _inside_ the SA payload. So if there are multiple protocols > all communicating on UDP port 500 you have to start parsing a payload > before you find out the context under which you should parse it. Whoa! > I think it is insane to not merge the two. We should dissuade people > from this bad practice while things like kink and gdoi are still at > internet-draft stage. > > Dan. > > On Thu, 15 Mar 2001 14:04:35 EST you wrote > > > > I still think removing the distinction between IKE and > ISAKMP is very > > dangerous. We are only now beginning to see the benefits of > separating the > > two. With work in progress on areas like MSEC, SMPLS, > Tero's KINK draft, > > Jari's MAP DOI, I think we would be insane to merge the > protocol layers at > > this point in the game > > > > Andrew > From owner-ipsec@lists.tislabs.com Thu Mar 15 14:17:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA11890; Thu, 15 Mar 2001 14:17:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19904 Thu, 15 Mar 2001 16:10:00 -0500 (EST) Message-Id: <4.3.2.7.2.20010315124326.00b5df70@mail.potlnd1.or.home.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 12:44:40 -0800 To: ipsec@lists.tislabs.com From: Mark Baugher Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: <200103151922.f2FJMDx28708@potassium.cips.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:22 AM 3/15/2001 -0800, Dan Harkins wrote: > Can you be more specific on the danger? > > One problem I see with not combining the two is the trend to use >UDP port 500 as a place to multiplex in different protocols. That is kink and gdoi are not different protocols. The extend IKE as the standard allows. Mark >a bad thing, in my opinion. If MSEC wants to do a group DOI they should >find a different port to do a multicast key exchange on. Part of this >problem is compounded by the design of the SA payload in ISAKMP. The >DOI is _inside_ the SA payload. So if there are multiple protocols >all communicating on UDP port 500 you have to start parsing a payload >before you find out the context under which you should parse it. Whoa! >I think it is insane to not merge the two. We should dissuade people >from this bad practice while things like kink and gdoi are still at >internet-draft stage. > > Dan. > >On Thu, 15 Mar 2001 14:04:35 EST you wrote > > > > I still think removing the distinction between IKE and ISAKMP is very > > dangerous. We are only now beginning to see the benefits of separating the > > two. With work in progress on areas like MSEC, SMPLS, Tero's KINK draft, > > Jari's MAP DOI, I think we would be insane to merge the protocol layers at > > this point in the game > > > > Andrew From owner-ipsec@lists.tislabs.com Thu Mar 15 14:21:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA12134; Thu, 15 Mar 2001 14:20:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19877 Thu, 15 Mar 2001 16:03:07 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.11952.276146.315199@thomasm-u1.cisco.com> Date: Thu, 15 Mar 2001 13:05:52 -0800 (PST) To: Henry Spencer Cc: IP Security List Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: References: <200103151922.f2FJMDx28708@potassium.cips.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Thu, 15 Mar 2001, Dan Harkins wrote: > > One problem I see with not combining the two is the trend to use > > UDP port 500 as a place to multiplex in different protocols. That is > > a bad thing, in my opinion... > > Strongly agree. Dealing with IKE is bad enough, without adding an > internal protocol multiplexer into the problem. We really ought to get > the port-number assignment amended: udp/500 should be IKE, not ISAKMP. Speaking from the KINK perspective, I had never assumed that we would reuse the IKE port. Which is to say that I agree with Henry who agrees with Dan. Mike From owner-ipsec@lists.tislabs.com Thu Mar 15 14:25:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA12463; Thu, 15 Mar 2001 14:25:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19846 Thu, 15 Mar 2001 15:55:44 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 15:54:21 -0500 Message-Id: <001301c0ad92$1c740590$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200103151950.f2FJor923510@thunk.east.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have no doubt that you CAN do it in 3 messages without the security hole (although it's a pain in the ass when you are doing PFS, which I tell people not to use). Obviously, we (almost) all do this already. It just seems to require more design effort to support the 3 message case. In fact, compressing the number of messages in the phase 1 and phase 2 exchanges has caused nothing but grief all 'round if you ask me. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: sommerfeld@thunk.east.sun.com > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > Sent: Thursday, March 15, 2001 2:51 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Scott Fanning'; Mike_Borella@3com.com; 'Dan Harkins'; > ipsec@lists.tislabs.com > Subject: Re: Agenda for the Minneapolis meeting > > > > - Dave Mason's 4 message QM instead of the commit bit fiasco. > > IMHO, both the commit bit and 4-message QM are unnecessary. > > Before you can set up SA's, each end has to reserve an SPI and then > communicate it to the peer. We create a "larval" SA at this time as a > placeholder, since the SA tables are where we check for uniqueness of > SPI values. > > You can buffer a (limited number) of received packets in the larval > SA, and then process them once the keying material is available. This > is exactly like buffering packets while you wait for an arp reply.. > not strictly necessary for interoperability, but extremely useful in > avoiding awkward pauses. > From owner-ipsec@lists.tislabs.com Thu Mar 15 16:02:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA19299; Thu, 15 Mar 2001 16:02:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20259 Thu, 15 Mar 2001 17:58:33 -0500 (EST) Message-Id: <200103152204.f2FM4Kx29371@potassium.cips.nokia.com> To: Mark Baugher cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: Your message of "Thu, 15 Mar 2001 12:44:40 PST." <4.3.2.7.2.20010315124326.00b5df70@mail.potlnd1.or.home.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29368.984693860.1@potassium.cips.nokia.com> Date: Thu, 15 Mar 2001 14:04:20 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That just isn't true. KINK defines new payloads and is, itself, a new exchange. The group DOI is for multicast security and since IKE establishes a shared symmetric key between two parties and two parties only a new multicast key exchange has to be defined. Neither of these things should speak out of UDP port 500. Dan. On Thu, 15 Mar 2001 12:44:40 PST you wrote > At 11:22 AM 3/15/2001 -0800, Dan Harkins wrote: > > Can you be more specific on the danger? > > > > One problem I see with not combining the two is the trend to use > >UDP port 500 as a place to multiplex in different protocols. That is > > kink and gdoi are not different protocols. The extend IKE as the > standard allows. > > Mark From owner-ipsec@lists.tislabs.com Thu Mar 15 16:03:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA19355; Thu, 15 Mar 2001 16:03:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20260 Thu, 15 Mar 2001 17:58:34 -0500 (EST) Message-Id: <200103152153.f2FLrFx29318@potassium.cips.nokia.com> To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: Your message of "Thu, 15 Mar 2001 10:50:44 EST." <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29315.984693195.1@Potassium.CIPS.Nokia.COM> Date: Thu, 15 Mar 2001 13:53:15 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is the critical question. It's something the working group has to decide upon too. My preference is to bump the major version number in the header and change the bits on the wire where needed. I don't think a pure clarification step is really necessary as the documents aren't so bad as to prevent implementation and the steps you suggest could drag on for years. But, as I said, it's up to the working group whether we're changing bits on the wire and if so how and to what extent. I'd like to see a protocol whose sole point in existing is to establish SAs for IPsec and I hope that would be the determinant in what stays, goes, or is clarified. But, again, it's up to the working group. Dan. On Thu, 15 Mar 2001 10:50:44 EST you wrote > > To what extent is this is a redefinition of the protocol --- i.e. a text > change, and to what extent is this a change in the definition of the bits on > the wire? > > Or is this the critical question? > Will there be a requirements stage? > > My suggestion is: > 1) rewrite/clarify the three RFCs into 1. > particularly, clarify extension mechanisms. > Publish. (no protocol changes) > > 2) establish chop list. Stuff we wish to deprecate, move to another > document, etc. > Publish. (only subtract/MAY-ify things) > > 3) establish requirements list, and identify people who want to > work on these items, and form very short lived WGs to do these > extensions. > > ] Train travel features AC outlets with no take-off restrictions|gigabit is n >o[ > ] Michael Richardson, Solidum Systems Oh where, oh where has|problem wit >h[ > ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 110 >0[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); > [ > > > > From owner-ipsec@lists.tislabs.com Thu Mar 15 16:04:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA19436; Thu, 15 Mar 2001 16:04:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20324 Thu, 15 Mar 2001 18:14:49 -0500 (EST) Date: Thu, 15 Mar 2001 18:18:31 -0500 From: Theodore Tso To: Dan Harkins Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting Message-ID: <20010315181831.F17735@think> References: <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> <200103152153.f2FLrFx29318@potassium.cips.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <200103152153.f2FLrFx29318@potassium.cips.nokia.com>; from dharkins@cips.nokia.COM on Thu, Mar 15, 2001 at 01:53:15PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Mar 15, 2001 at 01:53:15PM -0800, Dan Harkins wrote: > It is the critical question. It's something the working group has to > decide upon too. My preference is to bump the major version number in the > header and change the bits on the wire where needed. I don't think a > pure clarification step is really necessary as the documents aren't > so bad as to prevent implementation and the steps you suggest could > drag on for years. But, as I said, it's up to the working group whether > we're changing bits on the wire and if so how and to what extent. This question has come up before, when Tero was presenting his proposals for ways of fixing the hash so that it covered the entire IKE exchange. (Right now certain fields are not protected by the hash, and this could be a potential vulnerability, although no one has come up with an actual attack based on being able to modify the unprotected fields). There are ways we could fix this and still retain backwards compatibility --- or we could just bump the major version number and make the change. When the straw poll was done, to my surprise most folks were in favor of simply making a clean break as opposed to doing the backwards compatibility kludgery. That being said, I believe that if we did do a poll, we would see a strong mandate for something which is "implementation preserving". That is, it must be fairly easy (for most implementations) to be able to create an implementation which can simultaneously support IKE and IKE-bis without major code bloat. This is a somewhat imprecise metric, and so there is the possibility that this might get us into trouble. Still, certain changes such as "remove this exchange", should be fairly obviously "implementation preserving". Still, for the most part, the number of things which are actually *modifications* should be kept to an absolute minimum. And I believe the burden of proof should be *not* to make a modification. A modification should onle be done to fix a pre-existing bug or (maybe) if it significantly simplifies the protocol. We should *not* add new features during this exercise, or we'll never get done. Hopefully, though, most of the changes will be subtractions, not additions/modifications. - Ted From owner-ipsec@lists.tislabs.com Thu Mar 15 16:07:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA19794; Thu, 15 Mar 2001 16:07:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20304 Thu, 15 Mar 2001 18:10:59 -0500 (EST) Message-Id: <200103152311.f2FNB2x29607@potassium.cips.nokia.com> To: Mark Baugher cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: Your message of "Thu, 15 Mar 2001 14:40:32 PST." <4.3.2.7.2.20010315142427.03fb2660@mira-sjc5-6.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29604.984697861.1@potassium.cips.nokia.com> Date: Thu, 15 Mar 2001 15:11:01 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk They are "similar" but not "identical". Therefore they are different. I'm sure the implementations you refer to are very efficient and also very secure. It is still a bad idea. The complexity of the daemon listening on that port grows and the security of every protocol becomes tied to whatever else is being multiplexed. An attack on the FOO exchange in the BAR DOI could be used to create bogus IPsec SAs. Dan. On Thu, 15 Mar 2001 14:40:32 PST you wrote > Dan > It would be one thing to run, say, nfs and ftp on the same port. > I would call that "running two different protocols on the same port." > That being one case, what do you call it when DOIs which use > similar payloads, similar exchanges, and the same header with > a switch to identify them are run on the same port? It is misleading > to suggest that the first case is the same as the second. > > At 02:04 PM 3/15/2001 -0800, Dan Harkins wrote: > > That just isn't true. KINK defines new payloads and is, itself, a > >new exchange. The group DOI is for multicast security and since IKE > >establishes a shared symmetric key between two parties and two parties > >only a new multicast key exchange has to be defined. Neither of these > > GDOI uses that pair-wise symmetric key. > > >things should speak out of UDP port 500. > > I don't know yet if sharing the same port among different DOIs > is an important issue but it's clear that the protocol is designed to > demultiplex exchanges that belong to different DOIs. I know of > two implementations where this was implemented very efficiently. > > Mark > > > > Dan. > From owner-ipsec@lists.tislabs.com Thu Mar 15 16:19:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA20546; Thu, 15 Mar 2001 16:19:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20396 Thu, 15 Mar 2001 18:33:43 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Theodore Tso Cc: Dan Harkins , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Mar 2001 18:37:33 -0500 Message-Id: <20010315233734.8505035C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20010315181831.F17735@think>, Theodore Tso writes: >That being said, I believe that if we did do a poll, we would see a >strong mandate for something which is "implementation preserving". >That is, it must be fairly easy (for most implementations) to be able >to create an implementation which can simultaneously support IKE and >IKE-bis without major code bloat. I fear you're right -- when talking with implementors about throwing it out and starting over, the word "lynching" was bandied about. But if there's sentiment to go ahead and design a completely new replacement -- well, I wouldn't be disinterested in the process. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Mar 15 16:19:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA20565; Thu, 15 Mar 2001 16:19:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20367 Thu, 15 Mar 2001 18:22:48 -0500 (EST) Message-ID: <490717515EE6D41187A60003470D7136025247@kanatamail.kanata.unispherenetworks.ca> From: "Lordello, Claudio" To: "'Dan Harkins'" , Scott Fanning Cc: ipsec@lists.tislabs.com Subject: RE: Agenda for the Minneapolis meeting Date: Thu, 15 Mar 2001 18:26:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My 2 cents: Clarifications of the ID payloads and their use in phase I and phase II exchanges would be great. Claudio. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@cips.nokia.COM] > Sent: Wednesday, March 14, 2001 7:50 PM > To: Scott Fanning > Cc: ipsec@lists.tislabs.com > Subject: Re: Agenda for the Minneapolis meeting > > > I don't have any powerpoint slides or anything like that > but what I'm > going to talk about is: > > *) what is this-- RFC2407+RFC2408+RFC2409 = new draft > *) why do this? > - we have an overly complex way to get SAs for IPsec. > - a general feeling of "I don't like IKE", published > criticism, and general fear of an overly complex > security protocol. > - it's not so bad that we need to throw it all out > and start over again-- there are nice features to keep. > *) why do we have what we have? > - original idea of a generic transport (ISAKMP) which could > have multiple key exchanges defined on it, a generic key > exchange which can establish "security associations" for > multiple services, and a service definition for IPsec. > - these layers created ambiguity. > - key management war resulted in a please all people at all > costs mentality that caused an explosion of options. > *) what does it mean to combine these three RFCs? > - no "layer violations" when defining things (like > the commit > bit: it's from a header defined in RFC2408 used in > an exchange > defined in RFC2409 because of an aspect of the > service defined > in RFC2407) so we gain in clarity. > - we lose the generic transport and generic key exchange and > gain a key exchange and security association establishment > protocol for IPsec. > - some things, like Aggressive Mode and New Group Mode, get > left behind for possible redefinition and > advancement in an > independent draft. > - advances in the state-of-the-art should depricate > some of the > mandatory options-- DES, group1-- and that can happen in a > rewrite. > - many of the suggestions for protocol improvement can be > incorporated. How many and which ones is up to the working > group. > > I'm glad this is eliciting interest. I've brought the > subject up on the > list in the past and there didn't seem to be much interest. > Please comment! > There has also been an offline discussion about not caling it > IKE anymore > since it won't really be IKE and any comments on that idea > are solicited > as well. > > Dan. > > On Wed, 14 Mar 2001 15:30:07 PST you wrote > > For those of us not able to attend Minneapolis, is there > any info on "Son of > > IKE" that we can comment on via this list before the meeting? > > > > Thanks > > Scott > > ----- Original Message ----- > > From: > > To: > > Sent: Wednesday, March 14, 2001 3:07 PM > > Subject: Agenda for the Minneapolis meeting > > > > > > > Hi all, > > > > > > My apologies for not prepared an agenda earlier; both > Barbara and I have > > > been rather swamped at work lately..... > > > > > > This agenda is a draft; if you would like to request some > time at the > > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. > Many thanks. > > > > > > - Ted > > > > > > A. D. Keromytis > > > > > > On the Use of SCTP with IPsec > > > > > > Dan Harkins > > > > > > "Son of Ike" > > > > > > IPSEC MIB documents > > > > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > > > draft-ietf-ipsec-ike-monitor-mib-02.txt > > > draft-ietf-ipsec-monitor-mib-04.txt > > > > > > Jari Arkko -- IPSEC and IPV6 > > > > > > Effects on ICMPv6 on IKE and IPsec Policies > > > Manual SA Configuration for IPv6 Link Local Messages > > > > > > Tissa Senevirathne > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt > > > > IPSEC and NAT > > > > Markus Stenberg > > > > draft-stenberg-ipsec-nat-traversal-02 > > > > William Dixon > > > > draft-huttunen-ipsec-esp-in-udp-01 > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 15 16:20:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA20670; Thu, 15 Mar 2001 16:20:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20384 Thu, 15 Mar 2001 18:28:37 -0500 (EST) Message-ID: <3AB14D61.55E02AE5@cisco.com> Date: Thu, 15 Mar 2001 15:16:49 -0800 From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: andrew.krywaniuk@alcatel.com, "'Scott Fanning'" , Mike_Borella@3com.com, ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting References: <200103151922.f2FJMDx28708@potassium.cips.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, >From a philosophical perspective I understand your point of not wanting protocols to share a port. But I should point out that the Group DOI doesn't have the SA payload problem you mention. It doesn't specify a new phase 1 protocol -- the SA payload process and construct code is the same code. When phase 1 has completed it determines whether to run IKE phase 1 or GDOI is based on a trivial switch (using the DOI value) in the state machine. Putting GDOI onto its own port would just remove that switch. Will Son-of-IKE have a new port number, since it will be a different protocol from RFC 2409? Brian Dan Harkins wrote: > > Can you be more specific on the danger? > > One problem I see with not combining the two is the trend to use > UDP port 500 as a place to multiplex in different protocols. That is > a bad thing, in my opinion. If MSEC wants to do a group DOI they should > find a different port to do a multicast key exchange on. Part of this > problem is compounded by the design of the SA payload in ISAKMP. The > DOI is _inside_ the SA payload. So if there are multiple protocols > all communicating on UDP port 500 you have to start parsing a payload > before you find out the context under which you should parse it. Whoa! > I think it is insane to not merge the two. We should dissuade people > from this bad practice while things like kink and gdoi are still at > internet-draft stage. > > Dan. > > On Thu, 15 Mar 2001 14:04:35 EST you wrote > > > > I still think removing the distinction between IKE and ISAKMP is very > > dangerous. We are only now beginning to see the benefits of separating the > > two. With work in progress on areas like MSEC, SMPLS, Tero's KINK draft, > > Jari's MAP DOI, I think we would be insane to merge the protocol layers at > > this point in the game > > > > Andrew From owner-ipsec@lists.tislabs.com Thu Mar 15 17:01:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA21862; Thu, 15 Mar 2001 17:01:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20459 Thu, 15 Mar 2001 18:59:36 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15025.22572.565545.722535@thomasm-u1.cisco.com> Date: Thu, 15 Mar 2001 16:02:52 -0800 (PST) To: Mark Baugher Cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: <4.3.2.7.2.20010315124326.00b5df70@mail.potlnd1.or.home.com> References: <4.3.2.7.2.20010315124326.00b5df70@mail.potlnd1.or.home.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Baugher writes: > At 11:22 AM 3/15/2001 -0800, Dan Harkins wrote: > > Can you be more specific on the danger? > > > > One problem I see with not combining the two is the trend to use > >UDP port 500 as a place to multiplex in different protocols. That is > > kink and gdoi are not different protocols. The extend IKE as the > standard allows. This has not been decided for KINK. The two current proposals both leverage ISAKMP though. Mike From owner-ipsec@lists.tislabs.com Thu Mar 15 17:09:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA22701; Thu, 15 Mar 2001 17:09:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20575 Thu, 15 Mar 2001 19:18:53 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20010315181831.F17735@think> References: <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> <200103152153.f2FLrFx29318@potassium.cips.nokia.com> <20010315181831.F17735@think> Date: Thu, 15 Mar 2001 16:22:08 -0800 To: Theodore Tso , Dan Harkins From: Paul Hoffman / VPNC Subject: Re: Agenda for the Minneapolis meeting Cc: Michael Richardson , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:18 PM -0500 3/15/01, Theodore Tso wrote: >That being said, I believe that if we did do a poll, we would see a >strong mandate for something which is "implementation preserving". That poll was taken a year ago, by you, in Adelaide. If I remember correctly, the result was not what you have said here. The result was that people wanted a new version number in exchange for knowing that it would be much easier to implement. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 15 17:12:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA23098; Thu, 15 Mar 2001 17:12:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20510 Thu, 15 Mar 2001 19:10:22 -0500 (EST) Date: Thu, 15 Mar 2001 19:13:32 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: <20010315233734.8505035C42@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Mar 2001, Steven M. Bellovin wrote: > I fear you're right -- when talking with implementors about throwing it > out and starting over, the word "lynching" was bandied about... > But if there's sentiment to go ahead and design a completely new > replacement -- well, I wouldn't be disinterested in the process. There's always (whisper it) RFC 2522. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 15 17:50:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA25740; Thu, 15 Mar 2001 17:50:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20635 Thu, 15 Mar 2001 19:58:28 -0500 (EST) Message-ID: <3AB166A5.AF416AC3@cisco.com> Date: Thu, 15 Mar 2001 17:04:37 -0800 From: Scott Thomas Fanning X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: Theodore Tso , Dan Harkins , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting References: <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> <200103152153.f2FLrFx29318@potassium.cips.nokia.com> <20010315181831.F17735@think> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I remember that too Paul. We do not want to "negotiate" a new version. Lets treat this for what it is, a new version. Now, we just have to ask customers to use it :-) Scott Paul Hoffman / VPNC wrote: > At 6:18 PM -0500 3/15/01, Theodore Tso wrote: > >That being said, I believe that if we did do a poll, we would see a > >strong mandate for something which is "implementation preserving". > > That poll was taken a year ago, by you, in Adelaide. If I remember > correctly, the result was not what you have said here. The result was > that people wanted a new version number in exchange for knowing that > it would be much easier to implement. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Mar 15 19:10:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA27120; Thu, 15 Mar 2001 19:10:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20789 Thu, 15 Mar 2001 20:49:53 -0500 (EST) Message-Id: <3.0.32.20010315173636.00c7e100@Zsc4c004.us.nortel.com> X-Sender: tsenevir@Zsc4c004.us.nortel.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 15 Mar 2001 17:36:39 -0800 To: Dan Harkins , Mark Baugher X-Sybari-Space: 00000000 00000000 00000000 From: "Tissa Senevirathne" Subject: Re: Agenda for the Minneapolis meeting Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk But my thinking here is, still GDOI is an extension to IKE or for that matter they are all based on ISAKMP. UDP 500 is ISAKMP port number. My feeling is all applications that use IKE/ISKAMP must use 500. Otherwise ISAKMP will have list of UDP sockets for each DOI.. I agree as you said, stateful tracking of SA require bit of work. At 03:11 PM 3/15/01 -0800, Dan Harkins wrote: > They are "similar" but not "identical". Therefore they are different. > > I'm sure the implementations you refer to are very efficient and also >very secure. It is still a bad idea. The complexity of the daemon >listening on that port grows and the security of every protocol becomes >tied to whatever else is being multiplexed. An attack on the FOO exchange >in the BAR DOI could be used to create bogus IPsec SAs. > > Dan. > >On Thu, 15 Mar 2001 14:40:32 PST you wrote >> Dan >> It would be one thing to run, say, nfs and ftp on the same port. >> I would call that "running two different protocols on the same port." >> That being one case, what do you call it when DOIs which use >> similar payloads, similar exchanges, and the same header with >> a switch to identify them are run on the same port? It is misleading >> to suggest that the first case is the same as the second. >> >> At 02:04 PM 3/15/2001 -0800, Dan Harkins wrote: >> > That just isn't true. KINK defines new payloads and is, itself, a >> >new exchange. The group DOI is for multicast security and since IKE >> >establishes a shared symmetric key between two parties and two parties >> >only a new multicast key exchange has to be defined. Neither of these >> >> GDOI uses that pair-wise symmetric key. >> >> >things should speak out of UDP port 500. >> >> I don't know yet if sharing the same port among different DOIs >> is an important issue but it's clear that the protocol is designed to >> demultiplex exchanges that belong to different DOIs. I know of >> two implementations where this was implemented very efficiently. >> >> Mark >> >> >> > Dan. >> > From owner-ipsec@lists.tislabs.com Thu Mar 15 21:10:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA28927; Thu, 15 Mar 2001 21:10:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21127 Thu, 15 Mar 2001 22:57:24 -0500 (EST) Message-ID: <20010316040119.1013.qmail@web1403.mail.yahoo.com> Date: Thu, 15 Mar 2001 20:01:19 -0800 (PST) From: Pyda Srisuresh Subject: Re: Agenda for the Minneapolis meeting To: Dan Harkins , Scott Fanning Cc: ipsec@lists.tislabs.com In-Reply-To: <200103150050.f2F0oAx26150@potassium.cips.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Combining the 3 RFCs and adding clarity and deprecations where appropriate sounds good. I would like to suggest introducing a new Policy payload that replaces the ID payload in Quick mode. Jan Vilhuber and I have a draft out, titled, "IKE extensions to support Dynamic Policies"(), describing the new policy payload. In addition to drawing the distinction from ID payload, the new policy payload facilitates enforcement of application driven dynamic policies across peering nodes. Thanks. cheers, suresh --- Dan Harkins wrote: > I don't have any powerpoint slides or anything like that but what I'm > going to talk about is: > > *) what is this-- RFC2407+RFC2408+RFC2409 = new draft > *) why do this? > - we have an overly complex way to get SAs for IPsec. > - a general feeling of "I don't like IKE", published > criticism, and general fear of an overly complex > security protocol. > - it's not so bad that we need to throw it all out > and start over again-- there are nice features to keep. > *) why do we have what we have? > - original idea of a generic transport (ISAKMP) which could > have multiple key exchanges defined on it, a generic key > exchange which can establish "security associations" for > multiple services, and a service definition for IPsec. > - these layers created ambiguity. > - key management war resulted in a please all people at all > costs mentality that caused an explosion of options. > *) what does it mean to combine these three RFCs? > - no "layer violations" when defining things (like the commit > bit: it's from a header defined in RFC2408 used in an exchange > defined in RFC2409 because of an aspect of the service defined > in RFC2407) so we gain in clarity. > - we lose the generic transport and generic key exchange and > gain a key exchange and security association establishment > protocol for IPsec. > - some things, like Aggressive Mode and New Group Mode, get > left behind for possible redefinition and advancement in an > independent draft. > - advances in the state-of-the-art should depricate some of the > mandatory options-- DES, group1-- and that can happen in a > rewrite. > - many of the suggestions for protocol improvement can be > incorporated. How many and which ones is up to the working > group. > > I'm glad this is eliciting interest. I've brought the subject up on the > list in the past and there didn't seem to be much interest. Please comment! > There has also been an offline discussion about not caling it IKE anymore > since it won't really be IKE and any comments on that idea are solicited > as well. > > Dan. > > On Wed, 14 Mar 2001 15:30:07 PST you wrote > > For those of us not able to attend Minneapolis, is there any info on "Son > of > > IKE" that we can comment on via this list before the meeting? > > > > Thanks > > Scott > > ----- Original Message ----- > > From: > > To: > > Sent: Wednesday, March 14, 2001 3:07 PM > > Subject: Agenda for the Minneapolis meeting > > > > > > > Hi all, > > > > > > My apologies for not prepared an agenda earlier; both Barbara and I have > > > been rather swamped at work lately..... > > > > > > This agenda is a draft; if you would like to request some time at the > > > IPSEC meeting. Please send e-mail to Barbara and I ASAP. Many thanks. > > > > > > - Ted > > > > > > A. D. Keromytis > > > > > > On the Use of SCTP with IPsec > > > > > > Dan Harkins > > > > > > "Son of Ike" > > > > > > IPSEC MIB documents > > > > > > draft-ietf-ipsec-isakmp-di-mon-mib-03.txt > > > draft-ietf-ipsec-ike-monitor-mib-02.txt > > > draft-ietf-ipsec-monitor-mib-04.txt > > > > > > Jari Arkko -- IPSEC and IPV6 > > > > > > Effects on ICMPv6 on IKE and IPsec Policies > > > Manual SA Configuration for IPv6 Link Local Messages > > > > > > Tissa Senevirathne > > > > > > http://search.ietf.org/internet-drafts/draft-tsenevir-smpls-doi-00.txt > > > > > > IPSEC and NAT > > > > > > Markus Stenberg > > > > > > draft-stenberg-ipsec-nat-traversal-02 > > > > > > William Dixon > > > > > > draft-huttunen-ipsec-esp-in-udp-01 > > > > > > > > ===== __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Mar 15 22:24:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA29978; Thu, 15 Mar 2001 22:24:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA21251 Fri, 16 Mar 2001 00:01:35 -0500 (EST) Date: Fri, 16 Mar 2001 00:04:43 -0500 From: Theodore Tso To: Paul Hoffman / VPNC Cc: Theodore Tso , Dan Harkins , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting Message-ID: <20010316000443.G17735@think> References: <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> <200103152153.f2FLrFx29318@potassium.cips.nokia.com> <20010315181831.F17735@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from paul.hoffman@vpnc.org on Thu, Mar 15, 2001 at 04:22:08PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Mar 15, 2001 at 04:22:08PM -0800, Paul Hoffman / VPNC wrote: > At 6:18 PM -0500 3/15/01, Theodore Tso wrote: > >That being said, I believe that if we did do a poll, we would see a > >strong mandate for something which is "implementation preserving". > > That poll was taken a year ago, by you, in Adelaide. If I remember > correctly, the result was not what you have said here. The result was > that people wanted a new version number in exchange for knowing that > it would be much easier to implement. Yes, that's what I just refered to in the earlier paragraph, when I said this has come up before. A new version number, and an incompatible change to how we calculate the hash function. This basically means that we bump the major version number and make a non-backwards compatible change. However, if we go this far, then it does open the door to making other fixes to IKE that might also be backwards compatible. That's a poll which *hasn't* been done yet, but if we did do such a poll, I believe we would see support for fixing other things while we were making the above-mentioned backwards incompatible change --- as long as it were "implementation preserving." - Ted From owner-ipsec@lists.tislabs.com Thu Mar 15 23:20:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA07036; Thu, 15 Mar 2001 23:19:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA21452 Fri, 16 Mar 2001 01:18:49 -0500 (EST) Date: Fri, 16 Mar 2001 01:19:52 -0500 From: Theodore Tso To: Theodore Tso Cc: Paul Hoffman / VPNC , Dan Harkins , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting Message-ID: <20010316011952.D21035@think> References: <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> <200103152153.f2FLrFx29318@potassium.cips.nokia.com> <20010315181831.F17735@think> <20010316000443.G17735@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20010316000443.G17735@think>; from tytso@MIT.EDU on Fri, Mar 16, 2001 at 12:04:43AM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 16, 2001 at 12:04:43AM -0500, Theodore Tso wrote: > Yes, that's what I just refered to in the earlier paragraph, when I > said this has come up before. A new version number, and an > incompatible change to how we calculate the hash function. > This basically means that we bump the major version number and make a > non-backwards compatible change. > > However, if we go this far, then it does open the door to making other > fixes to IKE that might also be backwards compatible. That's a poll > which *hasn't* been done yet, but if we did do such a poll, I believe > we would see support for fixing other things while we were making the > above-mentioned backwards incompatible change --- as long as it were > "implementation preserving." Sorry, the above should read "it does open the door to making other fixes to IKE that might also NOT be backwards compatible". - Ted From owner-ipsec@lists.tislabs.com Fri Mar 16 08:10:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01840; Fri, 16 Mar 2001 08:10:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22876 Fri, 16 Mar 2001 09:43:34 -0500 (EST) From: "Christian Franzen" To: Subject: RE: Agenda for the Minneapolis meeting Date: Fri, 16 Mar 2001 05:14:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AB166A5.AF416AC3@cisco.com> x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am smiling to read your new ideas about a new version. During the last 5 month I did my thesis about interoperability of this big dinosaur IPSec. I would like to point out some of my experiences during my interop tests: - do more MUST specifications and not should or may, whatever! Because: notifications are most of the time not clear to understand, not recognized or not sent. - standard is full of options, look around, who uses them? Noone! i.e. Blowfish - lifetype kb is not used (interoperability set to 0!), lifetime is not negotiated. - timing of valid or not valid SAs is a problem -> keepalives ? Think you will solve the problems, good luck! Christian > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott Thomas Fanning > Sent: Friday, March 16, 2001 2:05 AM > To: Paul Hoffman / VPNC > Cc: Theodore Tso; Dan Harkins; Michael Richardson; > ipsec@lists.tislabs.com > Subject: Re: Agenda for the Minneapolis meeting > > > I remember that too Paul. We do not want to "negotiate" a new version. > Lets treat this for what it is, a new version. Now, we just have to ask > customers to use it :-) > > Scott > > Paul Hoffman / VPNC wrote: > > > At 6:18 PM -0500 3/15/01, Theodore Tso wrote: > > >That being said, I believe that if we did do a poll, we would see a > > >strong mandate for something which is "implementation preserving". > > > > That poll was taken a year ago, by you, in Adelaide. If I remember > > correctly, the result was not what you have said here. The result was > > that people wanted a new version number in exchange for knowing that > > it would be much easier to implement. > > > > --Paul Hoffman, Director > > --VPN Consortium > From owner-ipsec@lists.tislabs.com Fri Mar 16 08:10:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01841; Fri, 16 Mar 2001 08:10:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22956 Fri, 16 Mar 2001 10:08:19 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 16 Mar 2001 10:10:22 -0500 To: Scott Fluhrer From: Stephen Kent Subject: Re: Agenda for the Minneapolis meeting Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, The use of AES in IPsec needs to be addressed in both ESP and IKE. I think we can move ahead with an AES-based CBC mode easily for IKE and ESP. For a counter mode, Steve Bellovin made a good suggestion at the last meeting, i.e., let's wait to see what NIST adopts. Steve From owner-ipsec@lists.tislabs.com Fri Mar 16 08:12:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01992; Fri, 16 Mar 2001 08:12:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22875 Fri, 16 Mar 2001 09:43:34 -0500 (EST) Message-Id: <4.3.2.7.2.20010315153013.03fb3850@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 15:40:02 -0800 To: Dan Harkins From: Mark Baugher Subject: IKE DOIs (was Re: Agenda for the Minneapolis meeting ) Cc: ipsec@lists.tislabs.com In-Reply-To: <200103152311.f2FNB2x29607@potassium.cips.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan You mentioned a concern in your earlier note that parsing was problematic because the DOI field is in the SA payload and parsing commences before the context is identified. I think we agree that this is not necessarily inefficient. Is it insecure? At 03:11 PM 3/15/2001 -0800, Dan Harkins wrote: > They are "similar" but not "identical". Therefore they are different. > > I'm sure the implementations you refer to are very efficient and also >very secure. It is still a bad idea. The complexity of the daemon >listening on that port grows and the security of every protocol becomes >tied to whatever else is being multiplexed. An attack on the FOO exchange >in the BAR DOI could be used to create bogus IPsec SAs. I don't see why it is more secure to have N independent key management implementations updating the SAD, accessing private keys, and doing other things that impact security rather than having them integrated into one implementation, which can undergo a single security analysis. I don't understand why we would want to have one key management protocol used if there's a unicast address in an ESP flow but a different key management protocol used if there is a multicast address. I don't see how this is more secure and it sure doesn't make much sense to me. Mark > Dan. > >On Thu, 15 Mar 2001 14:40:32 PST you wrote > > Dan > > It would be one thing to run, say, nfs and ftp on the same port. > > I would call that "running two different protocols on the same port." > > That being one case, what do you call it when DOIs which use > > similar payloads, similar exchanges, and the same header with > > a switch to identify them are run on the same port? It is misleading > > to suggest that the first case is the same as the second. > > > > At 02:04 PM 3/15/2001 -0800, Dan Harkins wrote: > > > That just isn't true. KINK defines new payloads and is, itself, a > > >new exchange. The group DOI is for multicast security and since IKE > > >establishes a shared symmetric key between two parties and two parties > > >only a new multicast key exchange has to be defined. Neither of these > > > > GDOI uses that pair-wise symmetric key. > > > > >things should speak out of UDP port 500. > > > > I don't know yet if sharing the same port among different DOIs > > is an important issue but it's clear that the protocol is designed to > > demultiplex exchanges that belong to different DOIs. I know of > > two implementations where this was implemented very efficiently. > > > > Mark > > > > > > > Dan. > > From owner-ipsec@lists.tislabs.com Fri Mar 16 08:15:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02164; Fri, 16 Mar 2001 08:15:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22859 Fri, 16 Mar 2001 09:42:34 -0500 (EST) Message-Id: <4.3.2.7.2.20010315142427.03fb2660@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Mar 2001 14:40:32 -0800 To: Dan Harkins From: Mark Baugher Subject: Re: Agenda for the Minneapolis meeting Cc: ipsec@lists.tislabs.com In-Reply-To: <200103152204.f2FM4Kx29371@potassium.cips.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan It would be one thing to run, say, nfs and ftp on the same port. I would call that "running two different protocols on the same port." That being one case, what do you call it when DOIs which use similar payloads, similar exchanges, and the same header with a switch to identify them are run on the same port? It is misleading to suggest that the first case is the same as the second. At 02:04 PM 3/15/2001 -0800, Dan Harkins wrote: > That just isn't true. KINK defines new payloads and is, itself, a >new exchange. The group DOI is for multicast security and since IKE >establishes a shared symmetric key between two parties and two parties >only a new multicast key exchange has to be defined. Neither of these GDOI uses that pair-wise symmetric key. >things should speak out of UDP port 500. I don't know yet if sharing the same port among different DOIs is an important issue but it's clear that the protocol is designed to demultiplex exchanges that belong to different DOIs. I know of two implementations where this was implemented very efficiently. Mark > Dan. From owner-ipsec@lists.tislabs.com Fri Mar 16 09:16:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03850; Fri, 16 Mar 2001 09:16:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23184 Fri, 16 Mar 2001 11:00:45 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman / VPNC'" , "'Theodore Tso'" , "'Dan Harkins'" Cc: "'Michael Richardson'" , Subject: RE: Agenda for the Minneapolis meeting Date: Fri, 16 Mar 2001 10:58:56 -0500 Message-Id: <000101c0ae32$023fb020$4d31788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was also a poll at the San Diego bakeoff about whether IKEv2 was allowed to change bits on the wire and the answer was yes. That being said, I think we should leave the payload formats alone and just tweak how they are used. If I have to change any of the code in my isakmp directory, I will be disappointed. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Thursday, March 15, 2001 7:22 PM > To: Theodore Tso; Dan Harkins > Cc: Michael Richardson; ipsec@lists.tislabs.com > Subject: Re: Agenda for the Minneapolis meeting > > > At 6:18 PM -0500 3/15/01, Theodore Tso wrote: > >That being said, I believe that if we did do a poll, we would see a > >strong mandate for something which is "implementation preserving". > > That poll was taken a year ago, by you, in Adelaide. If I remember > correctly, the result was not what you have said here. The result was > that people wanted a new version number in exchange for knowing that > it would be much easier to implement. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Fri Mar 16 09:46:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA04802; Fri, 16 Mar 2001 09:46:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23306 Fri, 16 Mar 2001 11:45:22 -0500 (EST) Message-ID: <3AB24404.F9338E18@F-Secure.com> Date: Fri, 16 Mar 2001 18:49:08 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: andrew.krywaniuk@alcatel.com CC: "'Paul Hoffman / VPNC'" , "'Theodore Tso'" , "'Dan Harkins'" , "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting References: <000101c0ae32$023fb020$4d31788a@andrewk3.ca.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If the protocol is really to be upgraded/simplified, these should be done - QM ID payloads should be able to support firewall-integration and SCTP - Re-keying simplified / specified - Some heartbeat / dead-peer-detection chosen (KISS) - revised hash thingie - preferrably base mode replacing aggressive mode - if PKCS#1 is really to be deprecated by FIPS, something there Plus smaller issues one way or another, I don't care.. Ari Andrew Krywaniuk wrote: > > There was also a poll at the San Diego bakeoff about whether IKEv2 was > allowed to change bits on the wire and the answer was yes. > > That being said, I think we should leave the payload formats alone and just > tweak how they are used. If I have to change any of the code in my isakmp > directory, I will be disappointed. > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > > Sent: Thursday, March 15, 2001 7:22 PM > > To: Theodore Tso; Dan Harkins > > Cc: Michael Richardson; ipsec@lists.tislabs.com > > Subject: Re: Agenda for the Minneapolis meeting > > > > > > At 6:18 PM -0500 3/15/01, Theodore Tso wrote: > > >That being said, I believe that if we did do a poll, we would see a > > >strong mandate for something which is "implementation preserving". > > > > That poll was taken a year ago, by you, in Adelaide. If I remember > > correctly, the result was not what you have said here. The result was > > that people wanted a new version number in exchange for knowing that > > it would be much easier to implement. > > > > --Paul Hoffman, Director > > --VPN Consortium > > -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Mar 16 10:32:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA06695; Fri, 16 Mar 2001 10:32:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23361 Fri, 16 Mar 2001 12:06:55 -0500 (EST) Message-ID: <3AB248D8.CC890634@storm.ca> Date: Fri, 16 Mar 2001 12:09:44 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Christian Franzen CC: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Christian Franzen wrote: > I am smiling to read your new ideas about a new version. During the last 5 > month I did my thesis about interoperability of this big dinosaur IPSec. I > would like to point out some of my experiences during my interop tests: Is that thesis, or just the test results, online anywhere? From owner-ipsec@lists.tislabs.com Fri Mar 16 10:32:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA06724; Fri, 16 Mar 2001 10:32:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23434 Fri, 16 Mar 2001 12:37:51 -0500 (EST) Message-Id: <200103161737.f2GHbsx32907@potassium.cips.nokia.com> To: Ari Huttunen cc: ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: Your message of "Fri, 16 Mar 2001 18:49:08 +0200." <3AB24404.F9338E18@F-Secure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32904.984764274.1@potassium.cips.nokia.com> Date: Fri, 16 Mar 2001 09:37:54 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Do you have a proposal? Dan. On Fri, 16 Mar 2001 18:49:08 +0200 you wrote > If the protocol is really to be upgraded/simplified, these should be done > - Some heartbeat / dead-peer-detection chosen (KISS) From owner-ipsec@lists.tislabs.com Fri Mar 16 10:54:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA07883; Fri, 16 Mar 2001 10:54:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23459 Fri, 16 Mar 2001 12:50:07 -0500 (EST) From: "Joseph D. Harwood" To: "Stephen Kent" , "Scott Fluhrer" Cc: Subject: RE: Agenda for the Minneapolis meeting Date: Fri, 16 Mar 2001 09:54:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will a new authentication algorithm be introduced for ESP at this time, or will this wait until counter mode is addressed? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent > Sent: Friday, March 16, 2001 7:10 AM > To: Scott Fluhrer > Cc: ipsec@lists.tislabs.com > Subject: Re: Agenda for the Minneapolis meeting > > > Scott, > > The use of AES in IPsec needs to be addressed in both ESP and IKE. I > think we can move ahead with an AES-based CBC mode easily for IKE and > ESP. For a counter mode, Steve Bellovin made a good suggestion at the > last meeting, i.e., let's wait to see what NIST adopts. > > Steve > From owner-ipsec@lists.tislabs.com Fri Mar 16 10:57:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA07945; Fri, 16 Mar 2001 10:57:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23527 Fri, 16 Mar 2001 12:59:16 -0500 (EST) Message-ID: <006301c0ae43$02e6b5d0$e42645ab@cisco.com> From: "Scott Fanning" To: "Ari Huttunen" , "Dan Harkins" Cc: References: <200103161737.f2GHbsx32907@potassium.cips.nokia.com> Subject: Son of IKE (was Agenda for the Minneapolis meeting ) Date: Fri, 16 Mar 2001 10:00:39 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have heard that Nortel has some patent thing on all things kept alive :-) Does anyone know if thats true? Scott ----- Original Message ----- From: "Dan Harkins" To: "Ari Huttunen" Cc: Sent: Friday, March 16, 2001 9:37 AM Subject: Re: Agenda for the Minneapolis meeting > Do you have a proposal? > > Dan. > > On Fri, 16 Mar 2001 18:49:08 +0200 you wrote > > If the protocol is really to be upgraded/simplified, these should be done > > - Some heartbeat / dead-peer-detection chosen (KISS) From owner-ipsec@lists.tislabs.com Fri Mar 16 12:47:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14093; Fri, 16 Mar 2001 12:47:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23761 Fri, 16 Mar 2001 14:02:21 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 16 Mar 2001 14:01:02 -0500 To: "Joseph D. Harwood" From: Stephen Kent Subject: RE: Agenda for the Minneapolis meeting Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:54 AM -0800 3/16/01, Joseph D. Harwood wrote: >Will a new authentication algorithm be introduced for ESP at this time, or >will this wait until counter mode is addressed? I would not expect a new authentication algorithm to be introduced until we select a counter mode for encryption. At that time, the need for a faster authentication algorithm, to not slow down the faster encryption mode, becomes significant. Or, as Steve Bellovin suggested, we might adopt a combined mode. Steve From owner-ipsec@lists.tislabs.com Fri Mar 16 19:51:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA02085; Fri, 16 Mar 2001 19:51:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24776 Fri, 16 Mar 2001 21:35:44 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15026.52917.70913.741045@ryijy.hel.fi.ssh.com> Date: Sat, 17 Mar 2001 04:40:53 +0200 From: Tero Kivinen To: Theodore Tso Cc: Paul Hoffman / VPNC , Dan Harkins , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Agenda for the Minneapolis meeting In-Reply-To: <20010316000443.G17735@think> References: <200103151550.f2FFoiO03679@marajade.sandelman.ottawa.on.ca> <200103152153.f2FLrFx29318@potassium.cips.nokia.com> <20010315181831.F17735@think> <20010316000443.G17735@think> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Tso writes: > Yes, that's what I just refered to in the earlier paragraph, when I > said this has come up before. A new version number, and an > incompatible change to how we calculate the hash function. > This basically means that we bump the major version number and make a > non-backwards compatible change. You should state here which version number you are updating. There is ISAKMP major and minor version numbers and there is phase 1 transform identifier (key exchange IKE version number). For the revised hash we need to update only the IKE version number unless we do some other changes. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Mar 16 19:51:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA02097; Fri, 16 Mar 2001 19:51:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24735 Fri, 16 Mar 2001 21:17:25 -0500 (EST) From: Black_David@emc.com Message-ID: <0F31E5C394DAD311B60C00E029101A07080152C9@corpmx9.isus.emc.com> To: dharkins@cips.nokia.COM Cc: ipsec@lists.tislabs.com Subject: RE: Agenda for the Minneapolis meeting Date: Fri, 16 Mar 2001 21:20:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, While you're in there, I have a small request. The ECN draft, draft-ietf-tsvwg-ecn-02.txt (on which the authors hope to [finally] be able to declare victory and start on the path towards the IESG shortly after Minneapolis) contains the following text: RFC 2407 currently requires responders to reject all proposals if any proposal contains an unknown attribute; this requirement is expected to be changed to require a responder not to select proposals or transforms containing unknown attributes. Correction of this would be appreciated; everyone I've talked to about this seems to think it was an oversight. This issue arises because ECN added a new SA attribute. FWIW, ECN now treats the two bits in the IP header as a field with four possible values, and has defined a use for the fourth value, resulting in some minor changes to the IPSec tunnel encapsulation and decapsulation procedures. Take a look at the draft for details. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Sun Mar 18 03:20:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA26297; Sun, 18 Mar 2001 03:20:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27178 Sun, 18 Mar 2001 04:47:55 -0500 (EST) Message-ID: <3AB47F98.A5CFEC6C@nomadiclab.com> Date: Sun, 18 Mar 2001 11:27:52 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: IPSEC Mailing List , IPNG Mailing List Subject: A method to prevent DoS in IPv6 DAD and Mobile IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A number of recent ID:s have shown a number of potential security deficiencies in the way IPsec is used in a number of IPv6 signalling functions, including Duplicate Address Detection (DAD) and Mobile IPv6 Binding Updates (BUs). The relevant drafts include the following. draft-arkko-icmpv6-ike-effects-00.txt draft-nikander-ipng-address-ownership-00.txt The so called PBK-keys (draft-bradner-pbk-frame-00.txt) attemts to solve the Mobile IPv6 related problem by proposing a new class of identifiers, EIDs. In some respects that approach is similar to the HIP approach. While thinking about the problem, an idea of using the IPv6 interface identifier as a cryptographic token appeared to me. That is, by generating the interface identifier from components using a cryptographic one-way function, one can "bind" the interface identifier to the components, and the base security on the components. The idea is very new, and comments are solicited. Currently a working copy of the forthcoming -00 drafts is available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt I'll be working with the draft during my flights to Minneapolis, posting is as soon as drafts are accepted again. There is currently a plan to discuss related issues at the Mobile IP WG meeting and the SAAG session on Thursday. --Pekka Nikander Ericsson From owner-ipsec@lists.tislabs.com Mon Mar 19 06:35:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA11452; Mon, 19 Mar 2001 06:35:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00588 Mon, 19 Mar 2001 08:44:25 -0500 (EST) X-Envelope-To: AYap@colt-telecom.com User-Agent: Microsoft-Entourage/9.0.2509 Date: Mon, 19 Mar 2001 13:47:53 +0000 Subject: Re: IPSec Provisioning Tools From: Dirk Rosler To: "Yap, Alister" , IPSec Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Does anyone know/recommend any tools for provisioning IPSec VPN tunnels? Hi Alister, I am looking into the same things, tools for carrier-scale VPN provisioning. I haven't really gotten into the matter deeply yet, but I have superficially looked at two interesting, vendor-independent products. 1) Solsoft [solsoft.com](at the moment no IPSec support, but due shortly; neat router, firewall etc. policy tool that when extended to IPSec should become very interesting) 2) TBD Networks [tbdnetworks.com] a what appears to be very scalable solution, manageable via a browser interface. Most other management tools I have looked at yet were more or less vendor-specific, which in the case of a heterogeneous network environment that telcos have is unsuitable. I'd be very interested in your opinion and/or other solutions you -or anyone else for that matter- come across, so please let me know! Regards Dirk From owner-ipsec@lists.tislabs.com Mon Mar 19 06:41:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA11793; Mon, 19 Mar 2001 06:41:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00397 Mon, 19 Mar 2001 07:51:44 -0500 (EST) Message-ID: <3AB4B8EC.8791167A@sun.com> Date: Sun, 18 Mar 2001 14:32:28 +0100 From: gabriel montenegro X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: IPSEC Mailing List , IPNG Mailing List Subject: Re: A method to prevent DoS in IPv6 DAD and Mobile IPv6 References: <3AB47F98.A5CFEC6C@nomadiclab.com> Content-Type: multipart/mixed; boundary="------------6671185CAB32645A5EC3C3B5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------6671185CAB32645A5EC3C3B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Wow! I came up with the same scheme, although as part of a slightly more general mechanism. I've only been discussing with a couple of folks including Claude Castellucia and Erik Nordmark. But your message prompts me to send my stuff in as well. We should talk in Minneapolis. I had to name these things something, and based on the fact that what's important about them is the fact that they are: statistically unique and cryptographically verifiable, I just called them SUCV's. So we have SUCV identifiers and SUCV addresses. The latter are the ones you mentioned in your previous note. I attach my notes, although they are not yet complete nor in internet draft format. The attachments are: 1. my notes on pekka's address ownership, PBK and claude's privacy extension drafts 2. proposal and thoughts on SUCV's -gabriel -- Gabriel Montenegro (Sun Microsystems Laboratories, Europe) 29, chemin du Vieux Chene Email: gab@sun.com 38240 Meylan, FRANCE Mobile: +33 673 99 56 62 Office: +33 476 18 80 45 (sun internal: x38045) Fax: +33 476 18 88 88 --------------6671185CAB32645A5EC3C3B5 Content-Type: text/html; charset=us-ascii; name="AddressOwnershipAndPrivacyForMipV6.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="AddressOwnershipAndPrivacyForMipV6.htm" Notes on V6 address ownership problems http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt * protection against hijacking of valid addresses requires cryptographic authorization for operations that modify routing (BU's, source routing, etc) * quoting from above draft: "Currently there exists no specified mechanism for proving address ownership in Internet-wide scale." Mini Proposal: * remaining use of redirect operations: they are only allowed with non-global addresses which are bound (via a cryptographically sound binding) to anonymous or pseudonymous addresses * the above constitues perhaps the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms Notes on PBK http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt * temporary public/private pair * EID = hash(publicComponent) * Initiator sends EID to Responder * Initiator sends publicComponent to Responder Note This exchange must be secure, but it is an improvement over cookies. * Initiator sends (BU, EID)Priv to Responder Problems: * does NOT really address the address ownership problem of any publicly routable addresses * it is not specified how the EID and public component of the PK are sent by the initiator to the responder * preventing hijacking and MIM attacks depend on this sequence if not clearly specified * might as well make it secure: use HIP and its sequence Notes on simple privacy extension for Mobile IP v6 http://search.ietf.org/internet-drafts/draft-castelluccia-mobileip-privacy-00.txt What it hides: home address in the following two situations: * MN initiated traffic: hides home address from CN (a server?) and eavesdroppers * CN initiated traffic: hides home addr from eavesdropper (not from CN) What it does not hide: home address from initiating CN's when the MN is a server/responder Basics: * MN's instead of their home address use a 128 bit identifier called TMI * digest for TMI' = MD5 ( Home address | digest of TMI ) * define a new TLA (16 bits) for TMI address space * [why not SHA-1 (also required by IPSEC) given the collision resistance issues with MD5?] Works as follows: * mobile initiator * uses TMI as home address. * CN sends to TMI@COA (where the addr before the @ is carried within the home address option * mobile responder * "CN knows the MN's identity by definition" (?) * [Maybe not, if the CN can initiate to a HIP (or TMI) entity and resolve the COA by some other means.] * In this case, the MN can still hide its location (COA) by using a bi-directional tunnel with its HA and not sending any BU's to the CN. * traffic MN to CN would be of the form: homeAddr@TMI@COA * requires a new destination option to carry the real homeAddr * subsequent packets have just the TMI (essentially an SA), [so why not just use IPSEC]? Still has problems * TMI does not prevent hijacking as explained in the nikander draft on addr ownership * this is the problem our new default trust rule addresses (in conjunction with HIP) * There may be issues with its use of MD5: WeaknessInMd5 Proposal Given that: * The addr ownership problem is real. BU's and other exchanges which alter routing or tunneling open up DOS attacks. PBK attempts to solve these, but does not succeed for globally routable addresses. * Privacy concerns are also real, and the privacy extensions aim to solve this. * Neither of the above solves both at the same time, yet independently, both require non-trivial changes to BU's and other formats, as well as to the handling of SA's and IPSEC. The obvious solution is to address both: * Privacy * Address ownership In one common mechanism. I suggest it be based on HIP: * For all the cases at hand (v6 based) the HIP handshake provides for a very good and DOS-resistant sequence. * For new application layer cases (hinted at by PBK, and applicable to P2P, for example), the sequence must not be left up to the application. This may be easier to do with TCP in which existing frameworks could be extended (BEEP, TLS), but not immediately obvious how to accomplish it for UDP traffic. SCTP is another matter. -- GabrielMontenegro - 18 Mar, 2001 - 12:40:30 --------------6671185CAB32645A5EC3C3B5 Content-Type: text/html; charset=us-ascii; name="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ProposalToSolveAddressOwnershipAndPrivacyForMipV6.html" Statistical Uniqueness and Cryptographic Verifiability The Need for a Common Solution The idea is to propose one common mechanism that can solve two problems dealt with in AddressOwnershipAndPrivacyForMipV6: * address ownership: Given the different ways of altering routing information, and in particular, binding updates received at a correspondent node, how does this CN decide if it should heed it? * privacy for MIPv6: Mobile IP allows a node to keep the same home address as it changes its point of attachment to the network (care-of address or COA). There are proposals to solve each of the above. However, these proposals require modifying Mobile IP v6 and/or IPSEC separately. Instead, this is an attempt at using a common mechanism to achieve both of those goals. This note does not look at the problem from the point of view of practical Mobile IPv6 deployment, as it could be applied to, say, 3G or 4G wireless networks. Here, the assumption is that we have a network in which the nodes inherently distrust each other, and in which a global or centralized PKI or KDC will never be available. This is more akin to Peer-to-peer and to opportunistic networking. The goal is to arrive at some fundamental assumptions about trust on top of which one can build some useful communication. Statistically Unique Cryptographically Verifiable ID's (SUCV ID's) How does a node preclude other parties (eavesdroppers, correspondent nodes, etc) from gleaning too much information about its identity, or its home address or its whereabouts? The latter concern leads to ephemeral forms of addresses which typical proposals base on cryptographic hashes. These identifiers (or EID's or TMI's or HIT's) can have several interesting characteristics: * they are distinguishable from globally routable addresses * they are doled out from a separate TLA (TMI's) * they have a special form which may include an administrative prefix (HIT's) * because they are based on cryptographic hashes, they are statistically unique * this, of course, depends on the anti-collision properties of good hash functions * perhaps MD5 is to be avoided because of some concerns in this regard: WeaknessInMd5 ( http://www.cs.ucsd.edu/users/bsy/dobbertin.ps ) * they are the hashes of a public component of a self-generated Public Key (perhaps unsigned Diffie-Hellman) So these identifiers have a strong cryptographic binding with their public components (of their private-public keys). This is exactly the purpose that certificates have. There is a catch, as always. The name or identity must be communicated securely, otherwise there is a possibility of man-in-the-middle attack (which is reduced if the initiator also signs the source address, and if there is ingress filtering, etc). Whereas in other applications of self-signed certificates it is possible to secure this step, in the situation at hand (opportunistic security) there is no practical way to do this. Instead, the initiator must communicate its identity/name to the responder using in-band mechanisms. Barring this detail, the initiator proves he owns this self-signed certificate by signing stuff with his private key, and given the algorithmic characteristics of the hash used, he further shows that his identity is statistically unique (within bounds set approximately by the birthday paradox). Let's call them Statistically Unique Cryptographically Verifiable ID's, or SUCV ID's. Because of this, once a CN obtains information about one of these identifiers, it has a strong cryptographic assurance about which entity created it. Not only that, it knows that this identifier is owned and used exclusively by only one node in the universe: its peer in the current exchange. Thus, it is safe to allow that peer to effect changes (via BU's, for example) on how this address or identifier is routed to. Notice that with publically routable addresses, this assurance is much harder to arrive at, given that the address may be 'loaned' to (not owned by) the peer in question, perhaps thanks to the good service of a friendly DHCP server, for example. Despite the fact that currently there is no way to prove address ownership in the Internet, these considerations lead to the following fundamental assumption: * redirect operations are only allowed with SUCV ID's The above constitutes perhaps the only rule that operates by default, allowing any other more dangerous operation only if authorized by strong cryptographic mechanisms SUCV ID's versus SUCV Addresses What should one use: pure identifiers with no routing significance or addresses? For example, in the Mobile IPv6 case, a node could just start using its current care-of address (CoA?) as if it were its home address, and issue binding updates accordingly when it moved in the future. Of course, regular CoA?'s will not qualify under the rule above, so it would mean it might be very difficult (impossible?) for whoever sends this BU to prove that it 'owns' that CoA? address and can rightfully send redirects for it. The most the node can do is to establish some cryptographic evidence that it is sitting on that CoA? address. And it is sitting on as opposed to owning , because the former more accurately describes what is going on (from the CN's point of view at least, and maybe also in reality). With a CoA? that is not an SUCV ID it is never evident to the CN that whoever was sitting on that address actually owns it. At the very most, the CN's peer can prove that at some point it was sitting on CoA?, and later it can prove it is still the same node, but now sitting on another CoA?. But it cannot prove ownership. It may have obtained the CoA? from a DHCP server, for example. Ignoring this subtle distinction leads to DOS and hijacking attacks. Problems may also arise because of honest mistakes in configuration. For example, say node A was originally sitting on CoA?, and then moved on to CoA?'. Suppose it then asks its CN's to redirect traffic to CoA?'. In the meanwhile, the original CoA? may have been assigned to another node B, perhaps by the DHCP server that rightfully 'owns' that address. The result is that now traffic meant for B has been redirected to A at its new location. Relying on ingress filtering may limit the risk, but essentially, the only way for a node to prove ownership of an identifier (in the absence of any other centralized or global mechanism), is for it to prove that it created this statistically unique series of bits. Once you bite into using a 'home address' that is not really your home address, then what you're really trying to do is to use some identity instead of an address. And if you use identities that satisfy the conditions outlined above, then you suddenly gain the tremendous advantage that anybody can safely believe you when you claim you own that identity. Hence they can safely heed your redirects when you say that your identity is now available at some different CoA? (and later at another). Furthermore, you do not rely on ingress filtering to limit exposure. The only advantage to using an address is that the data traffic need not carry extra information in the packet to guarantee proper delivery by routing. One could, perhaps try to achieve both purposes by creating CoA?'s that can serve as both an address and as an SUCV ID. This could be accomplished by: * using the top 64 bits from your routing prefix (as in rfc3041) * defining the bottom 64 bits as an SUCV ID Using the resultant 128 bit field gives you an identifier that is routable, avoiding the need for taking extra space in the packet by sending routing options UNTIL you move and send a BU indicating this identifier is now available at another CoA?. This would leak information as to your whereabouts (or at least where you were at some point) to eavesdroppers. The top 64 bits also tells them where that identity began to be used, which could be very important information. On the other hand, if you use a 'pure' SUCV ID (without any routing significance), then your packets will always need extra information somewhere to assure they are routed properly. Eavesdroppers may still know where that identity is at any particular point in time. This is unavoidable. But at least they will not know where (under what prefix) that identity began to be used. When to use SUCV ID's versus SUCV addresses All in all, if one is more concerned about privacy then using an SUCV ID with no routing significance seems preferable. As often (perhaps even more), nodes are not particularly interested in privacy. But they (rather their users) are definitely interested in using Mobile IP v6 such that their BU's are heeded. Since this implies proving address ownership, these nodes would want to use SUCV home addresses . If they do so, CN's can safely heed BU's for these addresses, because they have reasonable confidence that in doing so they are not unwittingly participating in some DOS or hijacking attack. This follows because of the SUCV property of the lower 64 bits within the address. This SUCV-ness, by solving the address ownership problem, helps in both cases: * applications in which routing redirects need to be heeded (of which MIPv6 BU's are but one example), and * applications in which privacy is the main concern Only that in the former(no privacy, regular use) you want a routable address for optimization as in an SUCV home address, and in the latter you want an SUCV ID. With CoA?'s it is perhaps a little different in the sense that you nodes no not have to prove ownership, so SUCV may not be as necessary. However, if privacy is a concern then randomized CoA?'s (SU CoA?, without the CV part) are quite useful (as has been pointed out elsewhere). Proposal for a Solution Using these ID's or addresses depends on also communicating safely the SUCV portion, and this, in turn is dependent on the packet sequencing, etc. These concerns are not addresses at all in the PBK draft. On the other hand, HIP includes mechanisms and detailed considerations in this regard (protection against replay, DOS and MITM attacks). This is why this note proposes that a solution be drafted based heavily on HIP: * http://search.ietf.org/internet-drafts/draft-moskowitz-hip-03.txt * http://search.ietf.org/internet-drafts/draft-moskowitz-hip-arch-02.txt * http://search.ietf.org/internet-drafts/draft-moskowitz-hip-impl-01.txt We assume MIPv6 * Use HIP identities, in particular, anonymous HI's * since we assume v6 here, use HIT the 128 bit long operational representation of HI's * HIT takes the place of EID's in PBK or of TMI's in the privacy for mip6 draft TODO: continue this entire section! -- GabrielMontenegro - 18 Mar, 2001 - 13:22:02 --------------6671185CAB32645A5EC3C3B5-- From owner-ipsec@lists.tislabs.com Mon Mar 19 09:28:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23515; Mon, 19 Mar 2001 09:28:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00867 Mon, 19 Mar 2001 11:00:18 -0500 (EST) Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199AD23@mailmaestro.smartpipes.com> From: "Wang, Cliff" To: "'Dirk Rosler'" , "Yap, Alister" , IPSec Subject: RE: IPSec Provisioning Tools Date: Mon, 19 Mar 2001 16:03:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We provide advanced IP service, including VPN tunnel provisioning to customers. Check out: www.smartpipes.com The service is vendor-independent. -----Original Message----- From: Dirk Rosler [mailto:dirk@unicircuits.com] Sent: Monday, March 19, 2001 8:48 AM To: Yap, Alister; IPSec Subject: Re: IPSec Provisioning Tools > Does anyone know/recommend any tools for provisioning IPSec VPN tunnels? Hi Alister, I am looking into the same things, tools for carrier-scale VPN provisioning. I haven't really gotten into the matter deeply yet, but I have superficially looked at two interesting, vendor-independent products. 1) Solsoft [solsoft.com](at the moment no IPSec support, but due shortly; neat router, firewall etc. policy tool that when extended to IPSec should become very interesting) 2) TBD Networks [tbdnetworks.com] a what appears to be very scalable solution, manageable via a browser interface. Most other management tools I have looked at yet were more or less vendor-specific, which in the case of a heterogeneous network environment that telcos have is unsuitable. I'd be very interested in your opinion and/or other solutions you -or anyone else for that matter- come across, so please let me know! Regards Dirk From owner-ipsec@lists.tislabs.com Mon Mar 19 11:55:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA02763; Mon, 19 Mar 2001 11:55:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01898 Mon, 19 Mar 2001 13:06:10 -0500 (EST) Message-ID: <3AB63E91.F89A07F@redcreek.com> Date: Mon, 19 Mar 2001 10:14:57 -0700 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dirk Rosler CC: "Yap, Alister" , IPSec Subject: Re: IPSec Provisioning Tools References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dirk Rosler wrote: > > > Does anyone know/recommend any tools for provisioning IPSec VPN tunnels? > > Hi Alister, > > I am looking into the same things, tools for carrier-scale VPN provisioning. > > I haven't really gotten into the matter deeply yet, but I have superficially > looked at two interesting, vendor-independent products. 1) Solsoft > [solsoft.com](at the moment no IPSec support, but due shortly; neat router, > firewall etc. policy tool that when extended to IPSec should become very > interesting) 2) TBD Networks [tbdnetworks.com] a what appears to be very > scalable solution, manageable via a browser interface. > > Most other management tools I have looked at yet were more or less > vendor-specific, which in the case of a heterogeneous network environment > that telcos have is unsuitable. > > I'd be very interested in your opinion and/or other solutions you -or anyone > else for that matter- come across, so please let me know! > > Regards > > Dirk Howdy, Work on standardized configuration of IPsec devices is just in its infancy. You can follow the development of draft-ietf-ipsp-ipsecpib-02.txt and draft-ietf-ipsp-ipsec-conf-mib-00.txt. The real trick of it will be getting muitiple vendors to believe in the need for interoperable configuration of IPsec devices. Therefore I appreciate your note asking for it. And I encourage you to solicite the "IPsec Policy" working group for further updates on the progress of inter-vendor configurability. The "IPsec Policy" WG email list can be found at: General Discussion:ipsec-policy@vpnc.org To Subscribe: ipsec-policy-request@vpnc.org In Body: subscribe Archive: http://www.vpnc.org/ipsec-policy/ -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Mon Mar 19 12:46:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA06456; Mon, 19 Mar 2001 12:46:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02113 Mon, 19 Mar 2001 14:23:10 -0500 (EST) From: Bill Manning Message-Id: <200103191926.f2JJQwg05963@zed.isi.edu> Subject: Re: IPSec Provisioning Tools To: rcharlet@redcreek.com (Ricky Charlet) Date: Mon, 19 Mar 2001 11:26:58 -0800 (PST) Cc: dirk@unicircuits.com (Dirk Rosler), AYap@colt-telecom.com (Yap Alister), ipsec@lists.tislabs.com (IPSec) In-Reply-To: <3AB63E91.F89A07F@redcreek.com> from "Ricky Charlet" at Mar 19, 2001 10:14:57 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % % Dirk Rosler wrote: % > % > > Does anyone know/recommend any tools for provisioning IPSec VPN tunnels? % > the xbone project seems able to do this regardless of intervening infrastructure. contact joe touch for more detail. -- --bill From owner-ipsec@lists.tislabs.com Mon Mar 19 13:55:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA11299; Mon, 19 Mar 2001 13:55:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02399 Mon, 19 Mar 2001 15:40:10 -0500 (EST) Message-Id: <5.0.0.25.2.20010319134033.031fb400@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 19 Mar 2001 13:41:31 -0600 To: ipsec@lists.tislabs.com From: Rodney Thayer Subject: Fwd: interoperability testing of OpenPGP (with IPsec) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John asked me to forward this to the IPsec list. If anyone is interested in interoperability testing of IPsec with OpenPGP please contact him. >To: OpenPGP mailing list >From: John W Noerenberg II >Subject: interoperability testing of OpenPGP >Cc: "Philip R. Zimmermann" >Sender: owner-ietf-openpgp@mail.imc.org >List-Archive: >List-Unsubscribe: >List-ID: > >I'm investigating the possibility of hosting an openpgp interoperability >testing workshop (there's another name for this, but Pillsbury seems to >think it is improper for other organizations to use it) at Qualcomm in our >San Diego facilities. I'd like to know how many people would be >interested in participating, particularly those willing to come in >person. Please respond to me personally (rather than litter the mailing >list). I'll summarize and report back. > >Phil Zimmerman and I have discussed this, and it would be in connection >with the OpenPGP Consortium he is organizing. This has particular value >for this WG, since it will help us assess where we stand w/r/t DRAFT >status for rfc2440. I am hopeful there will be several willing and able >to participate! From owner-ipsec@lists.tislabs.com Mon Mar 19 17:20:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA23093; Mon, 19 Mar 2001 17:20:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03040 Mon, 19 Mar 2001 18:40:53 -0500 (EST) Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7064C87@rerun.lucentctc.com> From: "Cambria, Mike" To: "'ipsec@lists.tislabs.com'" Subject: Implementation Experience document? Date: Mon, 19 Mar 2001 18:44:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Do documents exist which discuss implementation experiences with IPSec related protocols? I'm looking for something similar to what was done for BGP4 in RFC1266 and/or RFC 1265; RFC 1246 / RFC 1245 for OSPF etc. Thanks, MikeC Michael C. Cambria Avaya Inc. Former Enterprise Networks Group of Lucent Technologies Voice: (978) 287 - 2807 300 Baker Avenue Fax: (978) 381 - 6415 Concord, Massachusetts 01742 Internet: mcambria@avaya.com From owner-ipsec@lists.tislabs.com Tue Mar 20 05:19:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14615; Tue, 20 Mar 2001 05:19:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04597 Tue, 20 Mar 2001 06:51:10 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 20 Mar 2001 11:54:30 +0000 Subject: Re: IPSec Provisioning Tools From: Dirk Rosler To: IPSec Message-ID: In-Reply-To: <8E1E94178828D143B34A560A7A6F2C0B0199AD23@mailmaestro.smartpipes.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Cliff, Thanks, but speaking for myself I am looking for tools not provided services. In fact I am working for a company that, like many others, is planning to do the same as you do. I know that SmartPipes are working in that area and, from what I hear, are not doing a bad job at it. What are you using to manage policies for your customers? Are you on a single platform? Regards Dirk > We provide advanced IP service, including VPN tunnel provisioning to > customers. > Check out: www.smartpipes.com > > The service is vendor-independent. From owner-ipsec@lists.tislabs.com Tue Mar 20 05:24:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14957; Tue, 20 Mar 2001 05:24:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04653 Tue, 20 Mar 2001 07:02:39 -0500 (EST) X-Envelope-To: rcharlet@redcreek.com User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 20 Mar 2001 12:06:04 +0000 Subject: Re: IPSec Provisioning Tools From: Dirk Rosler To: Ricky Charlet CC: IPSec Message-ID: In-Reply-To: <3AB63E91.F89A07F@redcreek.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ricky, thanks for your reply. I am already on the IPSec policy list. :-) I have done a review of all the Internet drafts that are on the roadmap of this IETF WG, I assume the papers you are referring to are on that list. As you say I concluded that standardised policy management is quite some time off (2-3 years?) - which is not supposed to diminish the work of the WG, by all means! Of course vendors are playing the usual tricks of trying to lock in people as long as they can. Don't know whether this includes RedCreek. I looked at a presentation of your Steve Peters for IPSec 2000 in France last year and found that this is getting closest to what the IETF WG suggests. I haven't had the time to look at all the policy tools of every vendor yet (list of almost 30 is lying somewhere on my desk). I will have to do this though within the next couple of months or so. BT Labs (who I work for) are very keen to find suitable products. Is anyone else doing something similar? Dirk > Work on standardized configuration of IPsec devices is just in its > infancy. You can follow the development of > draft-ietf-ipsp-ipsecpib-02.txt and > draft-ietf-ipsp-ipsec-conf-mib-00.txt. The real trick of it will be > getting muitiple vendors to believe in the need for interoperable > configuration of IPsec devices. Therefore I appreciate your note asking > for it. And I encourage you to solicite the "IPsec Policy" working group > for further updates on the progress of inter-vendor configurability. The > "IPsec Policy" WG email list can be found at: > > General Discussion:ipsec-policy@vpnc.org > To Subscribe: ipsec-policy-request@vpnc.org > In Body: subscribe > Archive: http://www.vpnc.org/ipsec-policy/ From owner-ipsec@lists.tislabs.com Tue Mar 20 06:15:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA17218; Tue, 20 Mar 2001 06:15:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04911 Tue, 20 Mar 2001 08:10:42 -0500 (EST) Message-ID: <006101c0b13e$cedc32c0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP Policy Conference: call for proposals Date: Tue, 20 Mar 2001 14:08:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C0B147.30669F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C0B147.30669F00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How will policies encourage the creation of new services?=20 Which services need resort to policy management? SNMPconf, COPS, SNMPV3 issues : the second edition of IP Policy will be = organized in Paris next September 11-14. A call for proposals is online at: http://www.upperside.fr/ippol01/ippolcfp.htm ------=_NextPart_000_005E_01C0B147.30669F00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How will policies encourage = the creation=20 of new services? Which=20 services need resort to policy management? SNMPconf, COPS, SNMPV3 issues : the = second=20 edition of IP Policy will be organized in Paris next September=20 11-14. A call for = proposals is=20 online at: <3d.htm>http://www.uppersid= e.fr/ippol01/ippolcfp.<3d.htm>htm ------=_NextPart_000_005E_01C0B147.30669F00-- From owner-ipsec@lists.tislabs.com Wed Mar 21 01:55:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA07631; Wed, 21 Mar 2001 01:55:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA07922 Wed, 21 Mar 2001 03:34:35 -0500 (EST) From: "Florian Heissenhuber" Organization: IABG mbH To: ipsec@lists.tislabs.com Date: Wed, 21 Mar 2001 09:37:09 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: IPSec for IPv6 on Linux available !!!! Reply-to: heissenhuber@iabg.de Message-ID: <3AB87645.20503.302145@localhost> X-mailer: Pegasus Mail for Win32 (v3.12cDE) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, we like to announce the availability of the first IPSec implementation for IPv6 running on Linux. This implementation is based on FreeS/WAN 1.8 (http://www.freeswan.org). The implementation of IPSec tunnel mode and the integration in FreeS/WAN was done by IABG as part of the EU project 6INIT (http://www.6init.org). There's still much work to do but this is the first running IPsec implementation for IPv6 on Linux. Currently the following features have been tested successfully: - IPv6 tunnel mode on gateways - Encryption algorithm: 3DES - Authentication algorithm: MD5 - Tested with Linux kernel 2.4.0 test 9 (others might work) - Tested with static routing - Tested with manual address configuration For detailed information, please read the README and INSTALL documents included in the distribution. You may download FreeS/WAN with IPv6 support from the following URL: http://www.ipv6.iabg.de/downloadframe/index.html If you have any problems downloading the distribution please send me an e-mail! Regards, Florian Heissenhuber __________________________________________________________________ Florian Heissenhuber IABG, Communication Networks Email: heissenhuber@iabg.de URL: www.iabg.de www.ipv6.iabg.de From owner-ipsec@lists.tislabs.com Wed Mar 21 01:55:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA07643; Wed, 21 Mar 2001 01:55:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA07931 Wed, 21 Mar 2001 03:35:44 -0500 (EST) Message-ID: From: "Ishola, Yemi" To: "'Tero Kivinen'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Agenda for the Minneapolis meeting Date: Wed, 21 Mar 2001 02:33:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B1E2.69EED940" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B1E2.69EED940 Content-Type: text/plain; charset="iso-8859-1" Can someone please record this and other future meetings and make the video clip available on the net (please provide address) for those of us unable to attend? Thanks -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Saturday, March 17, 2001 2:41 AM To: Theodore Tso Cc: Paul Hoffman / VPNC; Dan Harkins; Michael Richardson; Subject: Re: Agenda for the Minneapolis meeting Theodore Tso writes: > Yes, that's what I just refered to in the earlier paragraph, when I > said this has come up before. A new version number, and an > incompatible change to how we calculate the hash function. > This basically means that we bump the major version number and make a > non-backwards compatible change. You should state here which version number you are updating. There is ISAKMP major and minor version numbers and there is phase 1 transform identifier (key exchange IKE version number). For the revised hash we need to update only the IKE version number unless we do some other changes. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ------_=_NextPart_001_01C0B1E2.69EED940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Agenda for the Minneapolis meeting

Can someone please record this and other future = meetings and make the video clip available on the net (please provide = address) for those of us unable to attend?

Thanks

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@ssh.fi]
Sent: Saturday, March 17, 2001 2:41 AM
To: Theodore Tso
Cc: Paul Hoffman / VPNC; Dan Harkins; Michael = Richardson;

Subject: Re: Agenda for the Minneapolis = meeting


Theodore Tso writes:
> Yes, that's what I just refered to in the = earlier paragraph, when I
> said this has come up before.  A new = version number, and an
> incompatible change to how we calculate the = hash function.
> This basically means that we bump the major = version number and make a
> non-backwards compatible change. 

You should state here which version number you are = updating. There is
ISAKMP major and minor version numbers and there is = phase 1 transform
identifier (key exchange IKE version number).

For the revised hash we need to update only the IKE = version number
unless we do some other changes.
--
kivinen@ssh.fi        &= nbsp;           &= nbsp;          Work : +358 = 303 9870
SSH Communications = Security          &nbs= p;       http://www.ssh.fi/
SSH IPSEC = Toolkit           = ;            = ;     http://www.ssh.fi/ipsec/

------_=_NextPart_001_01C0B1E2.69EED940-- From owner-ipsec@lists.tislabs.com Wed Mar 21 04:01:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA19924; Wed, 21 Mar 2001 04:01:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08336 Wed, 21 Mar 2001 05:56:38 -0500 (EST) Message-Id: <200103202312.f2KNCJo10371@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com From: Michael Richardson Subject: CCAMP tunnel tracing reqs/proposal Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 Mar 2001 18:12:19 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FYI: Ron Bonica (10 min) draft-bonica-tunneltrace-01.txt draft-bonica-tunproto-00.txt From owner-ipsec@lists.tislabs.com Thu Mar 22 01:57:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA27675; Thu, 22 Mar 2001 01:57:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11982 Thu, 22 Mar 2001 02:39:10 -0500 (EST) Message-ID: <01f501c0b284$28772ce0$3002a8c0@tf.ispsoft.com> From: "raghu arni" To: "Dirk Rosler" , "Yap, Alister" , "IPSec" References: Subject: Re: IPSec Provisioning Tools Date: Wed, 21 Mar 2001 22:57:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk www.ispsoft.com has a product called UPX that provisions IPSec tunnels in a scalable way, browser based..pretty slick..supports a variety of devices and also has a small driver developement kit that folks can use to extend UPX to provision vendors of their choice.. A > > Does anyone know/recommend any tools for provisioning IPSec VPN tunnels? > > Hi Alister, > > I am looking into the same things, tools for carrier-scale VPN provisioning. > > I haven't really gotten into the matter deeply yet, but I have superficially > looked at two interesting, vendor-independent products. 1) Solsoft > [solsoft.com](at the moment no IPSec support, but due shortly; neat router, > firewall etc. policy tool that when extended to IPSec should become very > interesting) 2) TBD Networks [tbdnetworks.com] a what appears to be very > scalable solution, manageable via a browser interface. > > Most other management tools I have looked at yet were more or less > vendor-specific, which in the case of a heterogeneous network environment > that telcos have is unsuitable. > > I'd be very interested in your opinion and/or other solutions you -or anyone > else for that matter- come across, so please let me know! > > Regards > > Dirk > > From owner-ipsec@lists.tislabs.com Thu Mar 22 02:00:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA28237; Thu, 22 Mar 2001 02:00:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11976 Thu, 22 Mar 2001 02:37:19 -0500 (EST) Message-ID: <3AB9ACA0.F72EB2F8@cyphers.net> Date: Wed, 21 Mar 2001 23:41:22 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Minutes? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just curious if anyone took minutes at the WG meeting this week? -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Thu Mar 22 07:03:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA24345; Thu, 22 Mar 2001 07:03:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13154 Thu, 22 Mar 2001 08:34:48 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Date: Thu, 22 Mar 2001 08:38:12 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: SA identification Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk During Teusday's HIP BOF , JI raised a question that I had begun to contemplate while working on revising 2401: why do we need three values to identify an SA for incoming IPsec traffic? We currently require matching on protocol (AH vs. ESP), SPI, and destination address. It's clear that the protocol input can be made redundant by assigning SPIs without protocol specificity. Some mobility problems could be addressed if we ignored destination address. So, I have two questions for the list: - do we have any examples of plausible scenarios where we need the destination address as a discriminator for inbound traffic (inn addition to the SPI)? - how strongly would vendors feel about changing the spec to remove the requirement to match on all 3 values noted above? Note that SA identification is a local matter for an IPsec receiver, and thus it should be possible for a receiver to use just the SPI just through appropriate management of that space. So the question is really whether anyone manages SPIs in a fashion that relies on using the other two values for differentiation. Steve From owner-ipsec@lists.tislabs.com Thu Mar 22 07:03:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA24381; Thu, 22 Mar 2001 07:03:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13301 Thu, 22 Mar 2001 09:11:40 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: SA identification Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Mar 2001 08:15:39 -0600 Message-Id: <20010322141539.6C62C35C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Stephen Kent writes: >During Teusday's HIP BOF , JI raised a question that I had begun to >contemplate while working on revising 2401: why do we need three >values to identify an SA for incoming IPsec traffic? We currently >require matching on protocol (AH vs. ESP), SPI, and destination >address. It's clear that the protocol input can be made redundant by >assigning SPIs without protocol specificity. Some mobility problems >could be addressed if we ignored destination address. So, I have two >questions for the list: > > - do we have any examples of plausible scenarios where we >need the destination address as a discriminator for inbound traffic >(inn addition to the SPI)? > > - how strongly would vendors feel about changing the spec to >remove the requirement to match on all 3 values noted above? > >Note that SA identification is a local matter for an IPsec receiver, >and thus it should be possible for a receiver to use just the SPI >just through appropriate management of that space. So the question is >really whether anyone manages SPIs in a fashion that relies on using >the other two values for differentiation. The usual answer is that multicast needs it. Now that we have a multicast security group, this may be more important. I agree, though, that the 3-tuple requirement is annoying. And I suspect that people would not like the answer "use a 3-tuple for multicast, but a pair for unicast". --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Mar 22 07:35:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA27764; Thu, 22 Mar 2001 07:35:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13378 Thu, 22 Mar 2001 09:33:30 -0500 (EST) Date: Thu, 22 Mar 2001 09:36:52 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: SA identification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 22 Mar 2001, Stephen Kent wrote: > really whether anyone manages SPIs in a fashion that relies on using > the other two values for differentiation. Linux FreeS/WAN currently makes minor use of the ability to assign the same SPI to SAs of different protocols, for the case where a single connection uses multiple protocols (e.g. AH+ESP). We're not strongly attached to this, however... especially since we definitely belong to the "Death to AH!!!" faction. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 22 08:53:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA06554; Thu, 22 Mar 2001 08:53:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13622 Thu, 22 Mar 2001 10:18:10 -0500 (EST) Message-ID: From: "Ishola, Yemi" To: "'Tero Kivinen'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Agenda for the Minneapolis meeting Date: Wed, 21 Mar 2001 02:33:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B1E2.69EED940" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B1E2.69EED940 Content-Type: text/plain; charset="iso-8859-1" Can someone please record this and other future meetings and make the video clip available on the net (please provide address) for those of us unable to attend? Thanks -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Saturday, March 17, 2001 2:41 AM To: Theodore Tso Cc: Paul Hoffman / VPNC; Dan Harkins; Michael Richardson; Subject: Re: Agenda for the Minneapolis meeting Theodore Tso writes: > Yes, that's what I just refered to in the earlier paragraph, when I > said this has come up before. A new version number, and an > incompatible change to how we calculate the hash function. > This basically means that we bump the major version number and make a > non-backwards compatible change. You should state here which version number you are updating. There is ISAKMP major and minor version numbers and there is phase 1 transform identifier (key exchange IKE version number). For the revised hash we need to update only the IKE version number unless we do some other changes. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ ------_=_NextPart_001_01C0B1E2.69EED940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Agenda for the Minneapolis meeting

Can someone please record this and other future = meetings and make the video clip available on the net (please provide = address) for those of us unable to attend?

Thanks

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@ssh.fi]
Sent: Saturday, March 17, 2001 2:41 AM
To: Theodore Tso
Cc: Paul Hoffman / VPNC; Dan Harkins; Michael = Richardson;

Subject: Re: Agenda for the Minneapolis = meeting


Theodore Tso writes:
> Yes, that's what I just refered to in the = earlier paragraph, when I
> said this has come up before.  A new = version number, and an
> incompatible change to how we calculate the = hash function.
> This basically means that we bump the major = version number and make a
> non-backwards compatible change. 

You should state here which version number you are = updating. There is
ISAKMP major and minor version numbers and there is = phase 1 transform
identifier (key exchange IKE version number).

For the revised hash we need to update only the IKE = version number
unless we do some other changes.
--
kivinen@ssh.fi        &= nbsp;           &= nbsp;          Work : +358 = 303 9870
SSH Communications = Security          &nbs= p;       http://www.ssh.fi/
SSH IPSEC = Toolkit           = ;            = ;     http://www.ssh.fi/ipsec/

------_=_NextPart_001_01C0B1E2.69EED940-- From owner-ipsec@lists.tislabs.com Thu Mar 22 09:46:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10671; Thu, 22 Mar 2001 09:46:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13987 Thu, 22 Mar 2001 11:36:30 -0500 (EST) Message-ID: <3ABA2B9E.6060405@kolumbus.fi> Date: Thu, 22 Mar 2001 18:43:10 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: SA identification References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > Some mobility problems could be addressed if we ignored destination > address. > Also, the configuration of manual SAs to protect v6 control signaling traffic on e.g. an office WLAN network would be a lot easier if the destination address was ignored [draft-arkko-manual-icmpv6-sas-00.txt]. Multicast is used in that case as well, but in that particular application coordinating the multicast SPI numbers would be easier than in the general case of internet TV viewers scattered around the globe. Jari From owner-ipsec@lists.tislabs.com Thu Mar 22 09:49:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10728; Thu, 22 Mar 2001 09:49:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13936 Thu, 22 Mar 2001 11:28:18 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Ishola, Yemi" Cc: "'Tero Kivinen'" , "'ipsec@lists.tislabs.com'" Subject: Re: Agenda for the Minneapolis meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Mar 2001 10:32:05 -0600 Message-Id: <20010322163211.2519535C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Ishola, Yemi" wr ites: > >Can someone please record this and other future meetings and make the video >clip available on the net (please provide address) for those of us unable to >attend? > A few working group meetings are broadcast on the mbone; it can't be done for all meetings because of the expense of the equipment and camera crews. WG chairs can request an mbone slot, but availability isn't guaranteed; it depends on the demand for broadcast, how interesting the topic is perceived to be compared with other groups making the request, etc. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Mar 22 09:51:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10772; Thu, 22 Mar 2001 09:51:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13999 Thu, 22 Mar 2001 11:39:25 -0500 (EST) Message-Id: <200103221643.f2MGhF901685@thunk.east.sun.com> From: Bill Sommerfeld To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: SA identification In-reply-to: Your message of "Thu, 22 Mar 2001 08:38:12 EST." Reply-to: sommerfeld@East.Sun.COM Date: Thu, 22 Mar 2001 11:43:15 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Regardless of what you do, the destination address is an implicit discriminator because the IP layer ensures that packets to a different system won't make it to AH/ESP. > - do we have any examples of plausible scenarios where we > need the destination address as a discriminator for inbound traffic > (inn addition to the SPI)? Steve Bellovin also brought up the multicast case. (I'd say "non-unicast" rather than "multicast" since someone may want secure anycast some day as well). There's also the question of exactly where the SADB lies -- folks seem to be building a fair number of "non-traditional" hosts -- whether hosting multiple virtual hosts inside a single computer, or load-spreading a single destination address across many computers. No doubt someone's eventually going to want to do both of the above simultaneously. > - how strongly would vendors feel about changing the spec to > remove the requirement to match on all 3 values noted above? Our implementation allows SA's to be specified with a wildcarded destination. I'd oppose removing protocol as a discriminator for inbound SA lookup. > Note that SA identification is a local matter for an IPsec receiver, > and thus it should be possible for a receiver to use just the SPI > just through appropriate management of that space. So the question is > really whether anyone manages SPIs in a fashion that relies on using > the other two values for differentiation. Our implementation has separate loadable modules (and separate tables) for ESP vs. AH SA's. - Bill From owner-ipsec@lists.tislabs.com Thu Mar 22 09:52:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10812; Thu, 22 Mar 2001 09:52:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14045 Thu, 22 Mar 2001 11:48:54 -0500 (EST) X-Authentication-Warning: thompson.lcmi.ufsc.br: esms owned process doing -bs Date: Thu, 22 Mar 2001 13:25:55 -0300 (EST) From: Eduardo Souza Machado da Silva To: IPSec Subject: IDS (Crypto-Gram March 2001) Message-ID: X-PGP: Public Key available at web site X-URL: http://www.lcmi.ufsc.br/~esms MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk fyi, few words from Schneier in his monthly letter Crypto-Gram related with IPSec (in IDS context). regards, esms Eduardo Souza Machado da Silva http://LagoadaConceicao.com.br/~esms [ http://www.counterpane.com/crypto-gram-0103.html#9 ] The "Death" of IDS? [...] These two problems are nothing new, but several recent developments threaten to undermine IDSs completely. First is the rise of IPsec. IPsec is a security protocol that encrypts IP traffic. An IDS can't detect what it can't understand, and is useless against encrypted network traffic. (Similarly, an anti-virus program can't find viruses in encrypted e-mail attachments.) As encryption becomes more widespread on a network, an IDS becomes less useful. From owner-ipsec@lists.tislabs.com Thu Mar 22 11:16:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15596; Thu, 22 Mar 2001 11:16:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14256 Thu, 22 Mar 2001 12:46:05 -0500 (EST) Message-ID: <3ABA323A.A3B0DE33@F-Secure.com> Date: Thu, 22 Mar 2001 19:11:22 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Death to AH (was Re: SA identification) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Thu, 22 Mar 2001, Stephen Kent wrote: > > really whether anyone manages SPIs in a fashion that relies on using > > the other two values for differentiation. > > Linux FreeS/WAN currently makes minor use of the ability to assign the > same SPI to SAs of different protocols, for the case where a single > connection uses multiple protocols (e.g. AH+ESP). We're not strongly > attached to this, however... especially since we definitely belong to the > "Death to AH!!!" faction. > > Henry Spencer > henry@spsystems.net Yes, quick death to AH please! I've now been writing a new draft for how to pass AH through NATs using UDP encapsulation (a continuation of the work that was presented in the WG meeting). It just basically sucks, and I'd much rather NOT do it at all! All the people doing the relevant drafts pretty much agreed that no-one wants to do it, but IPsec requires AH so we feel we're compelled to do it. When there was discussion about why AH at all, the only real reason that I can recollect was that Mobile-IPv6 uses it to protect Binding Updates. Well, guess what, AH doesn't really work for them either, as witnessed in the WG meeting today. Even if AH is not killed at once, a decision by this WG that AH doesn't need to go through NATs would help us a lot! Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Mar 22 12:22:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA20875; Thu, 22 Mar 2001 12:22:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14551 Thu, 22 Mar 2001 14:07:53 -0500 (EST) Date: Thu, 22 Mar 2001 21:15:09 +0200 Message-Id: <200103221915.VAA27324@burp> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <3ABA2B9E.6060405@kolumbus.fi> (message from Jari Arkko on Thu, 22 Mar 2001 18:43:10 +0200) Subject: Re: SA identification References: <3ABA2B9E.6060405@kolumbus.fi> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (1) Destination address need to be stored into SA for outgoing SA's. (2) The identifaction triplet (SPI,dst,protocol) makes it problably cleaner for key management to exactly specify which SA is being operated. For incoming SA, if you want to ignore the destination address, seems to me that, this is local implementation issue (with kernel and key management). From owner-ipsec@lists.tislabs.com Thu Mar 22 14:04:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA27211; Thu, 22 Mar 2001 14:04:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14742 Thu, 22 Mar 2001 15:35:43 -0500 (EST) Message-ID: <5E686636124A2042B4E5EE1F15191F27165B1E@exchsrv3> From: Paul Lambert To: "'Ari Huttunen'" , Henry Spencer Cc: IP Security List Subject: Death to AH Now (was RE: Death to AH (was Re: SA identification )) Date: Thu, 22 Mar 2001 12:28:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B30E.AD697EA0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B30E.AD697EA0 Content-Type: text/plain; charset="iso-8859-1" I strongly agree. AH should die immediately. AH was invented before mobile-IP. It was based on an assumption that IPv6 header fields should be protected, yet still be readable by routers in transit. This was not a useful requirement. Better protection can be provided by other mechanisms (like ESP). Over the last year or two there have been few supporter of AH (perhaps just 1?). The mandatory-to-implement status of AH is expensive and unnecessary. The IETF makes it easier to add a technology than to remove it. I propose that the working group proceed with the following process: 1) The IPsec working group should have yet another straw poll on the death of AH :-( a) The following questions should be posed to working groups in the IETF Questions: i) Should AH be an IETF standards track document? If you answer was yes to the question above, please answer the following additional questions: ii) What useful security service does AH provide that can not be provided by other mechanisms (like ESP)? iii) Do you know of any significant existing application of AH? b) Since various working may have adopted AH (like mobile-IP) the poll should go to all working groups. c) The straw poll comment period should end in two weeks (last comments accepted April 6) 2) Take action if the results above indicate that AH should "die". Action items would include: a) Remove AH from the standards track by reissuing RFC 2402 as informational or experimental. b) Modify RFC 2401 to purge AH from the architecture. c) Minor as required in other specifications (to be identified). d) Retain, but do not mandate key management support for AH. Minor modifications to key management specification may be required. Paul -----Original Message----- From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com] Sent: Thursday, March 22, 2001 9:11 AM To: Henry Spencer Cc: IP Security List Subject: Death to AH (was Re: SA identification) Henry Spencer wrote: > > On Thu, 22 Mar 2001, Stephen Kent wrote: > > really whether anyone manages SPIs in a fashion that relies on using > > the other two values for differentiation. > > Linux FreeS/WAN currently makes minor use of the ability to assign the > same SPI to SAs of different protocols, for the case where a single > connection uses multiple protocols (e.g. AH+ESP). We're not strongly > attached to this, however... especially since we definitely belong to the > "Death to AH!!!" faction. > > Henry Spencer > henry@spsystems.net Yes, quick death to AH please! I've now been writing a new draft for how to pass AH through NATs using UDP encapsulation (a continuation of the work that was presented in the WG meeting). It just basically sucks, and I'd much rather NOT do it at all! All the people doing the relevant drafts pretty much agreed that no-one wants to do it, but IPsec requires AH so we feel we're compelled to do it. When there was discussion about why AH at all, the only real reason that I can recollect was that Mobile-IPv6 uses it to protect Binding Updates. Well, guess what, AH doesn't really work for them either, as witnessed in the WG meeting today. Even if AH is not killed at once, a decision by this WG that AH doesn't need to go through NATs would help us a lot! Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security ------_=_NextPart_001_01C0B30E.AD697EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Death to AH Now (was RE: Death to AH (was Re: SA = identification)) I strongly agree. AH should die immediately. AH was invented before mobile-IP. It was based = on an assumption that IPv6 header fields should be protected, yet still = be readable by routers in transit. This was not a useful = requirement. Better protection can be provided by other = mechanisms (like ESP). Over the last year or two there have been = few supporter of AH (perhaps just 1?). The mandatory-to-implement = status of AH is expensive and unnecessary. The IETF makes it easier to add a technology than to = remove it. I propose that the working group proceed with the = following process: 1) The IPsec working group should have yet another = straw poll on the death of AH :-( a) The following questions should be = posed to working groups in the IETF Questions: i) Should = AH be an IETF standards track document? = If you answer was yes to the question above, please answer the = following additional questions: ii) What useful = security service does AH provide that can not be provided by other = mechanisms (like ESP)? iii) Do you know of = any significant existing application of AH? b) Since various working may have = adopted AH (like mobile-IP) the poll should go to all working = groups. c) The straw poll comment period should = end in two weeks (last comments accepted April 6) 2) Take action if the results above indicate that AH = should "die". Action items would include: a) Remove AH from the standards track = by reissuing RFC 2402 as informational or experimental. b) Modify RFC 2401 to purge AH from the = architecture. c) Minor as required in other = specifications (to be identified). d) Retain, but do not mandate key = management support for AH. Minor modifications = to key management specification may be required. Paul -----Original Message----- From: Ari Huttunen [<3d.htm>mailto:Ari.Huttunen@F-Secure.c<3d.htm>= om] Sent: Thursday, March 22, 2001 9:11 AM To: Henry Spencer Cc: IP Security List Subject: Death to AH (was Re: SA = identification) Henry Spencer wrote: > > On Thu, 22 Mar 2001, Stephen Kent wrote: > > really whether anyone manages SPIs in a = fashion that relies on using > > the other two values for = differentiation. > > Linux FreeS/WAN currently makes minor use of = the ability to assign the > same SPI to SAs of different protocols, for the = case where a single > connection uses multiple protocols (e.g. = AH+ESP). We're not strongly > attached to this, however... especially since = we definitely belong to the > "Death to AH!!!" faction. > > = ; = ; = ; = ; = ; Henry Spencer > = ; = ; = ; = ; = henry@spsystems.net Yes, quick death to AH please! I've now been writing = a new draft for how to pass AH through NATs using UDP encapsulation (a = continuation of the work that was presented in the WG meeting). It just = basically sucks, and I'd much rather NOT do it at all! All the people = doing the relevant drafts pretty much agreed that no-one wants to do = it, but IPsec requires AH so we feel we're compelled to do it. When there was discussion about why AH at all, the = only real reason that I can recollect was that Mobile-IPv6 uses it to = protect Binding Updates. Well, guess what, AH doesn't really work for them = either, as witnessed in the WG meeting today. Even if AH is not killed at once, a decision by this = WG that AH doesn't need to go through NATs would help us a lot! Ari -- Ari = Huttunen &nbs= p; phone: +358 9 2520 = 0700 Software = Architect &nb= sp; fax : +358 9 2520 5001 F-Secure = Corporation <3d.htm>http://www.F-Secure.<3d.htm>com F-Secure products: Integrated Solutions for = Enterprise Security ------_=_NextPart_001_01C0B30E.AD697EA0-- From owner-ipsec@lists.tislabs.com Thu Mar 22 15:03:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02426; Thu, 22 Mar 2001 15:03:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15078 Thu, 22 Mar 2001 17:01:50 -0500 (EST) Message-ID: <3ABA7728.7060707@kolumbus.fi> Date: Fri, 23 Mar 2001 00:05:28 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Ari Huttunen Cc: Henry Spencer , IP Security List , tsenevir@nortelnetworks.com Subject: Re: Death to AH (was Re: SA identification) References: <3ABA323A.A3B0DE33@F-Secure.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen wrote: > > > Even if AH is not killed at once, a decision by this WG that AH doesn't > need to go through NATs would help us a lot! > I am in favor of skipping AH for NAT work. Don't drag all the baggage with you forever. Move on in new work. Also, this reminds also me of the MPLS DOI presentation where they were proposing AH and ESP-like functionality for MPLS. I haven't studied that DOI much, but it seems to me that providing only ESP-like behaviour would be sufficient, particularly given that MPLS doesn't perhaps treat IP headers in any different way in the AH/ESP cases. Jari From owner-ipsec@lists.tislabs.com Thu Mar 22 15:06:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02690; Thu, 22 Mar 2001 15:06:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15054 Thu, 22 Mar 2001 16:47:05 -0500 (EST) From: ji@research.att.com Date: Thu, 22 Mar 2001 16:50:54 -0500 (EST) Message-Id: <200103222150.QAA07427@bual.research.att.com> To: ipsec@lists.tislabs.com Subject: Re: Death to AH Now Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > AH was invented before mobile-IP. It was based on an assumption that IPv6 You mean, AH was invented before mobile IP had a use for it. I did mobile ip in 1990-1991 (paper in sigcomm'91), and the mobile ip working group has been meeting as a working group since the 23rd IETF (March 1992). I do agree, however, that AH must die a quick death. /ji From owner-ipsec@lists.tislabs.com Thu Mar 22 15:19:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03894; Thu, 22 Mar 2001 15:19:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15154 Thu, 22 Mar 2001 17:22:03 -0500 (EST) Message-Id: <200103222151.f2MLpVA44060@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ari Huttunen cc: Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of Thu, 22 Mar 2001 19:11:22 +0200. <3ABA323A.A3B0DE33@F-Secure.com> Date: Thu, 22 Mar 2001 22:51:31 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: When there was discussion about why AH at all, the only real reason that I can recollect was that Mobile-IPv6 uses it to protect Binding Updates. Well, guess what, AH doesn't really work for them either, as witnessed in the WG meeting today. => Is this opinion "IPsec is for VPN only" the opinion of the majority of the IPsec WG? I know this yours, Jeff's and Henry's too... And of course the current market is at 99% in VPNs. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Mar 22 15:40:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA05627; Thu, 22 Mar 2001 15:40:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15207 Thu, 22 Mar 2001 17:37:11 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Francis Dupont Cc: Ari Huttunen , Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Mar 2001 16:40:49 -0600 Message-Id: <20010322224051.7C92235C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200103222151.f2MLpVA44060@givry.rennes.enst-bretagne.fr>, Francis D upont writes: > In your previous mail you wrote: > > When there was discussion about why AH at all, the only real reason that > I can recollect was that Mobile-IPv6 uses it to protect Binding Updates. > Well, guess what, AH doesn't really work for them either, as witnessed > in the WG meeting today. > >=> Is this opinion "IPsec is for VPN only" the opinion of the majority >of the IPsec WG? I know this yours, Jeff's and Henry's too... >And of course the current market is at 99% in VPNs. > I don't agree that IPsec is only for VPNs. I have some projects going that rely on transport-mode IPsec, and the advent of Windows 2000, Solaris 2.8, and IPsec on NIC cards will make them much more feasible. But host-to-host versus VPN is a separate issue than the (desired) life expectancy of AH. I won't bother restating my opinions on that subject. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Mar 22 16:01:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA06734; Thu, 22 Mar 2001 16:01:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15270 Thu, 22 Mar 2001 18:02:06 -0500 (EST) Date: Thu, 22 Mar 2001 18:05:17 -0500 (EST) From: Henry Spencer To: Francis Dupont cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <200103222151.f2MLpVA44060@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 22 Mar 2001, Francis Dupont wrote: > When there was discussion about why AH at all, the only real reason that > I can recollect was that Mobile-IPv6 uses it to protect Binding Updates. > Well, guess what, AH doesn't really work for them either... > > => Is this opinion "IPsec is for VPN only" the opinion of the majority > of the IPsec WG? I know this yours, Jeff's and Henry's too... It's certainly not the opinion of the FreeS/WAN project. Our current users mostly run VPNs, but our long-term objectives are elsewhere. We think AH is just as useless and undesirable for non-VPN applications as it is for VPN applications. In fact, I don't understand why you think that "death to AH!" means "IPsec is for VPN only"; they seem to me like two completely separate issues. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 22 16:45:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA08839; Thu, 22 Mar 2001 16:44:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15349 Thu, 22 Mar 2001 18:31:55 -0500 (EST) Message-Id: <200103222334.f2MNYrA44496@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of Thu, 22 Mar 2001 18:05:17 EST. Date: Fri, 23 Mar 2001 00:34:53 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk # I don't know if you were in the mobile-ip room this morning but this was very clear (if you weren't I believe the slides will be available soon). As no IPsec people did object to Jeff's written claims about what IPsec can/should use for, I assume they are right and perhaps (so I ask) reflect a common opinion. I apologize if you didn't in the room as the claims are far more than "death to AH!" Regards Francis.Dupont@enst-bretagne.fr PS: issues are not so separate, AH lovers are not in favor of VPNs only. PPS: IESG security concerns with MIPv6 are available, I've attached them. # To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IESG security concerns with MIPv6 Date: Mon, 19 Mar 2001 15:35:30 -0500 From: Thomas Narten List-Archive: This is a note to summarize some security-related concerns that the IESG has with the Mobile IP v6 Draft (draft-ietf-mobileip-ipv6-13.txt). The concerns can be summarized as follows: The IESG has concerns about the draft's dependency on IPSEC AH to authenticate Binding Updates. There are several issues here. a) There is significant overhead associated with building and maintaining AH/IPsec SAs (both in terms of state that needs to be maintained, but also in terms of required message flows, and the processing required to implement those flows). This has negative implications for larger servers that process many 100s of thousands of connections at a time. b) The processing rules for authenticating a Binding Update with AH are complex and are apparently not readily supported by the current generation of IPsec/IKE implementations (e.g., the IPsec policies are needed that specify sufficient granularity about IPv6 packets containing binding updates). There is a concern that this will not be rectified in the short term or that providing this level of granularity is even approriate for IPsec, leading to a possible result that the Binding Update won't be implemented/supported at all, (or even worse) that it will be used without proper authentication. The IESG strongly recommends that the WG find an alternate approach that is not tied to IPsec/AH. Our recommendation is to consider approaches that are Binding Update specific, so that a solution can be tailored to meet the actual requirement at hand. The main requirement that needs to be met is that the use of MIPv6 with Binding Updates be no less secure than the level of security one currently has with IPv4 (without mobility). That does not mean that the protocol needs to be immune to *all* types of vulnerabilities. Rather, it means that a solution should not introduce significant new vulnerabilities that are not present in IPv4 today. (Of course, reducing vulnerabilities compared to IPv4 is a very desireable goal.) The WG is encouraged to look at the ID http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt. It was developed specifically as an alternate approach to addressing the problems discussed in this note. Jeff Schiller will give a brief presentation on the approach discussed in the ID during the Mobile IP session at Minneapolis. The WG chairs will likely be forming a design team to work on a specific solution to the identified problems. This also will be discussed at the Thursday session. Thomas From owner-ipsec@lists.tislabs.com Thu Mar 22 16:59:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA09900; Thu, 22 Mar 2001 16:59:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15387 Thu, 22 Mar 2001 18:56:31 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15034.37371.382654.601356@thomasm-u1.cisco.com> Date: Thu, 22 Mar 2001 15:59:55 -0800 (PST) To: Francis Dupont Cc: Ari Huttunen , Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <200103222151.f2MLpVA44060@givry.rennes.enst-bretagne.fr> References: <3ABA323A.A3B0DE33@F-Secure.com> <200103222151.f2MLpVA44060@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > When there was discussion about why AH at all, the only real reason that > I can recollect was that Mobile-IPv6 uses it to protect Binding Updates. > Well, guess what, AH doesn't really work for them either, as witnessed > in the WG meeting today. > > => Is this opinion "IPsec is for VPN only" the opinion of the majority > of the IPsec WG? I know this yours, Jeff's and Henry's too... > And of course the current market is at 99% in VPNs. Well, I certainly don't make that assumption, but I think that the real question -- especially now -- is is there anything in the IP header before ESP that's worth protecting. MIP was the previous poster child. Does anybody have a new candidate? Mike From owner-ipsec@lists.tislabs.com Thu Mar 22 17:16:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA11037; Thu, 22 Mar 2001 17:16:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15506 Thu, 22 Mar 2001 19:29:18 -0500 (EST) Date: Thu, 22 Mar 2001 19:32:29 -0500 (EST) From: Henry Spencer To: Francis Dupont cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <200103222334.f2MNYrA44496@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Mar 2001, Francis Dupont wrote: > In fact, I don't understand why you think that "death to AH!" means > "IPsec is for VPN only"... > > => I don't know if you were in the mobile-ip room this morning but > this was very clear (if you weren't I believe the slides will be > available soon). No, I wasn't there -- I'm still in Toronto. I'm skeptical of the assertion that non-VPN applications are impossible without AH; our analysis, at least for our particular applications, shows no such connection. I would believe that people might think Mobile IP -- that is, one *particular* non-VPN application -- is impossible without AH. (I think they're probably wrong, but this more-specific claim is far more plausible, and deserves careful attention.) I would also believe that careless people might think that anything which isn't Mobile IP is a VPN. That's wrong, but perhaps not obviously so. > As no IPsec people did object to Jeff's written claims > about what IPsec can/should use for, I assume they are right... The question is, how many IPsec people were present? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 22 18:00:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA12369; Thu, 22 Mar 2001 18:00:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15609 Thu, 22 Mar 2001 20:11:19 -0500 (EST) To: Henry Spencer Cc: IP Security List In-reply-to: henry's message of Thu, 22 Mar 2001 18:05:17 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Death to AH (was Re: SA identification) From: Jun-ichiro itojun Hagino Date: Fri, 23 Mar 2001 10:14:47 +0900 Message-Id: <20010323011447.48AD97E75@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >It's certainly not the opinion of the FreeS/WAN project. Our current >users mostly run VPNs, but our long-term objectives are elsewhere. We >think AH is just as useless and undesirable for non-VPN applications as it >is for VPN applications. In fact, I don't understand why you think that >"death to AH!" means "IPsec is for VPN only"; they seem to me like two >completely separate issues. in previous discussions, most of "death to AH" reasonning was (in my understanding) like this: - you can protect the whole packet by tunnel mode ESP, like IP1 ESP IP2 foo so why bother? so i guess "death to AH" and "ipsec is for VPN only" are related. it is correct that there are certain extension headers that does not need protection, however, there are certain application that needs AH (especially with transport mode). as increasing number of protocol documents are relying upon the existence of ESP and AH (like most of IPv6 routing protocols) i believe we need AH definitely. itojun From owner-ipsec@lists.tislabs.com Thu Mar 22 20:31:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA15964; Thu, 22 Mar 2001 20:31:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA15853 Thu, 22 Mar 2001 22:25:08 -0500 (EST) Date: Thu, 22 Mar 2001 22:28:20 -0500 (EST) From: Henry Spencer To: Jun-ichiro itojun Hagino cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <20010323011447.48AD97E75@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Mar 2001, Jun-ichiro itojun Hagino wrote: > in previous discussions, most of "death to AH" reasonning was > (in my understanding) like this: > - you can protect the whole packet by tunnel mode ESP... > so why bother? > so i guess "death to AH" and "ipsec is for VPN only" are related. Only if you assume that tunnel mode is useful for VPNs only. Not true, unless you define "VPN" very broadly indeed, as "anything that uses tunnels". Most people prefer a narrower definition. And while we think that is an excellent argument against AH -- notably, it provides a "backstop" solution which covers us against the possibility that some unforeseen need might someday appear -- it is not the only one. The crucial argument against AH is the lack of real requirements for it. > it is correct that there are certain extension headers that does not > need protection, however, there are certain application that needs > AH (especially with transport mode). This is the standard claim; the question is, to what extent is it really true? How many of those claimed needs stand up to careful analysis? Remember, it is not enough to show that ESP cannot meet their needs -- it is also necessary to show that AH can, which is not always a simple thing to verify. (Note, for example, IESG's recently-expressed doubts about whether the authentication requirements of Binding Updates can really be met using AH.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 22 20:41:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA16070; Thu, 22 Mar 2001 20:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA15906 Thu, 22 Mar 2001 22:43:37 -0500 (EST) Message-ID: <3ABAC453.8D629382@nortelnetworks.com> Date: Thu, 22 Mar 2001 22:34:43 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Marcus Leech" Reply-To: "Marcus Leech" Organization: Not Terribly X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: Francis Dupont , IP Security List Subject: Re: Death to AH (was Re: SA identification) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > The question is, how many IPsec people were present? > The assertion was made that the current Mobile IPV6 spec uses IPSEC in a way that just doesn't scale. AH was chosen by Mobile IPV6 because it provides protection of outer header information, including the bits of IPV6 options goop that carries Mobile IPV6 binding updates. It's not *impossible* to use ESP for this, but it's awkward. Quite apart from the AH/ESP debate in Mobile IPV6, there exists a rather ugly problem, in that requiring that binding updates be protected IPV6 requires deploying IPSEC, complete with some kind of large-scale PKI, to protect binding updates between random strangers. From a *practical* perspective, this is a non-starter. There *are* folks who believe that IPSEC is just for VPNs, and in fact that's certainly an easy and obvious starting point. There is no necessary relationship between "AH is bad", and "IPSEC is only for VPNs". From owner-ipsec@lists.tislabs.com Thu Mar 22 23:24:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA26338; Thu, 22 Mar 2001 23:24:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16180 Fri, 23 Mar 2001 01:26:25 -0500 (EST) Date: Fri, 23 Mar 2001 00:30:28 -0600 From: Theodore Tso To: Will Price Cc: ipsec@lists.tislabs.com Subject: Re: Minutes? Message-ID: <20010323003028.B23240@think> References: <3AB9ACA0.F72EB2F8@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3AB9ACA0.F72EB2F8@cyphers.net>; from wprice@cyphers.net on Wed, Mar 21, 2001 at 11:41:22PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Mar 21, 2001 at 11:41:22PM -0800, Will Price wrote: > Just curious if anyone took minutes at the WG meeting this week? > Yes, Barbara Fraser took minutes. We'll be sending cleaned-up copy of those minutes to the mailing list by early next week. In the meantime, if people who gave presentations could send me their slides, I'd greatly appreciate it. Thanks!! - Ted From owner-ipsec@lists.tislabs.com Fri Mar 23 00:57:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA12065; Fri, 23 Mar 2001 00:57:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16314 Fri, 23 Mar 2001 02:49:00 -0500 (EST) Message-Id: <200103230752.QAA06353@isl.rdc.toshiba.co.jp> To: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: henry's message of "Thu, 22 Mar 2001 22:28:20 EST." Date: Fri, 23 Mar 2001 16:52:59 +0900 From: FUKUMOTO Atsushi Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > (Note, for example, IESG's recently-expressed doubts about > whether the authentication requirements of Binding Updates can really be > met using AH.) I have read it as a doubt to the use of IPSec in general, rather than AH alone... Was I wrong? Excerpt from mobile-ip mailing list: >>The IESG has concerns about the draft's dependency on IPSEC AH to >>authenticate Binding Updates. There are several issues here. >> >> a) There is significant overhead associated with building and >> maintaining AH/IPsec SAs (both in terms of state that needs to >> be maintained, but also in terms of required message flows, and >> the processing required to implement those flows). This is about building and maintaining SA, especially the overhead of ISAKMP/IKE, not specifically about AH. >> b) The processing rules for authenticating a Binding Update with AH >> are complex and are apparently not readily supported by the >> current generation of IPsec/IKE implementations (e.g., the IPsec >> policies are needed that specify sufficient granularity about >> IPv6 packets containing binding updates). I thought this isn't specific to AH, either. FUKUMOTO Atsushi fukumoto@isl.rdc.toshiba.co.jp From owner-ipsec@lists.tislabs.com Fri Mar 23 01:31:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA17226; Fri, 23 Mar 2001 01:31:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16454 Fri, 23 Mar 2001 03:48:07 -0500 (EST) Message-ID: <3ABB0EBC.8A386D20@cyphers.net> Date: Fri, 23 Mar 2001 00:52:13 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IP Security List Subject: Re: Death to AH (was Re: SA identification) References: <3ABA323A.A3B0DE33@F-Secure.com> <3ABA7728.7060707@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We would also very much enjoy removing AH for our implementation. It introduces unnecessary complexity to solve problems which are better solved in other ways. As a vendor which has at one time or another implemented both of the current proposed NAT drafts on an experimental basis, I beg of thee to leave AH support out, :-) Jari Arkko wrote: > Ari Huttunen wrote: > > Even if AH is not killed at once, a decision by this WG that AH > > doesn't need to go through NATs would help us a lot! > > > I am in favor of skipping AH for NAT work. Don't drag > all the baggage with you forever. Move on in new work. > > Also, this reminds also me of the MPLS DOI presentation where > they were proposing AH and ESP-like functionality for > MPLS. I haven't studied that DOI much, but it seems to > me that providing only ESP-like behaviour would be > sufficient, particularly given that MPLS doesn't perhaps > treat IP headers in any different way in the AH/ESP cases. - -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBOrsOqqy7FkvPc+xMEQLisQCgnOS2Bbw4J3PWH6QsJsUt7DkYRXoAoNhW twHMnxouBmsN9qnLsH26Qf49 =5YVF -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Mar 23 07:38:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA18983; Fri, 23 Mar 2001 07:38:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19081 Fri, 23 Mar 2001 09:44:19 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E166352@MAIL.netoctave.com> From: Ray Savarda To: IP Security List Subject: RE: Death to AH (was Re: SA identification) Date: Fri, 23 Mar 2001 09:50:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To add another voice to the chorus - we would certainly like to see AH removed as a requirement. From our perspective it just adds complexity without adding much value, and at high speeds, life (IPSEC) is already complex enough! Ray Savarda Director, Hardware Engineering NetOctave Inc. -----Original Message----- From: Will Price [mailto:wprice@cyphers.net] Sent: Friday, March 23, 2001 3:52 AM To: IP Security List Subject: Re: Death to AH (was Re: SA identification) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We would also very much enjoy removing AH for our implementation. It introduces unnecessary complexity to solve problems which are better solved in other ways. As a vendor which has at one time or another implemented both of the current proposed NAT drafts on an experimental basis, I beg of thee to leave AH support out, :-) Jari Arkko wrote: > Ari Huttunen wrote: > > Even if AH is not killed at once, a decision by this WG that AH > > doesn't need to go through NATs would help us a lot! > > > I am in favor of skipping AH for NAT work. Don't drag > all the baggage with you forever. Move on in new work. > > Also, this reminds also me of the MPLS DOI presentation where > they were proposing AH and ESP-like functionality for > MPLS. I haven't studied that DOI much, but it seems to > me that providing only ESP-like behaviour would be > sufficient, particularly given that MPLS doesn't perhaps > treat IP headers in any different way in the AH/ESP cases. - -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBOrsOqqy7FkvPc+xMEQLisQCgnOS2Bbw4J3PWH6QsJsUt7DkYRXoAoNhW twHMnxouBmsN9qnLsH26Qf49 =5YVF -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Mar 23 07:40:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA19201; Fri, 23 Mar 2001 07:40:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17608 Fri, 23 Mar 2001 09:20:39 -0500 (EST) Date: Fri, 23 Mar 2001 09:24:12 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <200103230752.QAA06353@isl.rdc.toshiba.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Mar 2001, FUKUMOTO Atsushi wrote: > > (Note, for example, IESG's recently-expressed doubts about > > whether the authentication requirements of Binding Updates can really be > > met using AH.) > > I have read it as a doubt to the use of IPSec in general, rather than > AH alone... Was I wrong? You are correct, but you've missed the implication: this is an alleged "requirement for AH" which, on closer examination, cannot actually be satisfied by AH (or ESP). So it's not a requirement for AH at all, and cannot be used to justify keeping AH. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 23 08:00:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21698; Fri, 23 Mar 2001 08:00:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20033 Fri, 23 Mar 2001 09:59:03 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 23 Mar 2001 09:59:28 -0500 To: Henry Spencer From: Stephen Kent Subject: Re: Death to AH (was Re: SA identification) Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:24 AM -0500 3/23/01, Henry Spencer wrote: >On Fri, 23 Mar 2001, FUKUMOTO Atsushi wrote: >> > (Note, for example, IESG's recently-expressed doubts about >> > whether the authentication requirements of Binding Updates can really be >> > met using AH.) >> >> I have read it as a doubt to the use of IPSec in general, rather than >> AH alone... Was I wrong? > >You are correct, but you've missed the implication: this is an alleged >"requirement for AH" which, on closer examination, cannot actually be >satisfied by AH (or ESP). So it's not a requirement for AH at all, and >cannot be used to justify keeping AH. > > Henry Spencer > henry@spsystems.net I am not a big fan of keeping AH, but Herny's comments are strong enough to warrant a reply. There were several arguments made for AH initially. Some have gone away, e.g., the need for an authentication only mode of operation that would allow export when and encrypt and authenticate mode would have been export limited. The introduction of authentication-only ESP, which I championed, made this argument less germane, as has the easing of export controls on encryption products. Another requirement was more narrowly focused on protecting IP header elements for validation by intermediate routers. IP security labels used to control routing were a cited example. However, this application is hard to realize unless the AH integrity function is a signature, which is relatively slow to generate and big and thus not all that attractive for now. I have a vague understanding of IPv6 mobility use AH, but not good enough to be able to defend it, or to say why it seems infeasible. Steve From owner-ipsec@lists.tislabs.com Fri Mar 23 08:19:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA23631; Fri, 23 Mar 2001 08:19:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21367 Fri, 23 Mar 2001 10:18:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103221915.VAA27324@burp> References: <3ABA2B9E.6060405@kolumbus.fi> <200103221915.VAA27324@burp> Date: Fri, 23 Mar 2001 10:23:10 -0500 To: Markku Savela From: Stephen Kent Subject: Re: SA identification Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:15 PM +0200 3/22/01, Markku Savela wrote: >(1) Destination address need to be stored into SA for outgoing SA's. yes, the destination address is part of the SAD, but it is not an SA identifier in the same sense and that a receiver uses the SPI and dest address for SA selection >(2) The identifaction triplet (SPI,dst,protocol) makes it problably > cleaner for key management to exactly specify which SA is being > operated. "being operated?" not sure what you mean here, but in any case the focus of my question is on receiver processing. >For incoming SA, if you want to ignore the destination address, seems >to me that, this is local implementation issue (with kernel and key >management). As the SCTP presentation and ID shows, it is not purely a local matter. If we did away with the requirement to use the destination address as part of the SA selection process at a receiver, there would be no need to make this process more complex to accommodate SCTP requirements. Steve From owner-ipsec@lists.tislabs.com Fri Mar 23 08:30:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25239; Fri, 23 Mar 2001 08:30:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21982 Fri, 23 Mar 2001 10:29:25 -0500 (EST) Message-Id: <200103231532.f2NFWMA46766@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: FUKUMOTO Atsushi cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of Fri, 23 Mar 2001 16:52:59 +0900. <200103230752.QAA06353@isl.rdc.toshiba.co.jp> Date: Fri, 23 Mar 2001 16:32:22 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I have read it as a doubt to the use of IPSec in general, rather than AH alone... Was I wrong? => no, you are right: the issue is the use of IPsec/AH *and* IPsec. The AH/ESP transport/tunnel discussion was at the previous meeting and there were no message like don't use AH because we'll kill it... BTW AH was proposed because it was less complex to use than ESP and it met the requirements (in fact it met more than the requirements :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Mar 23 08:48:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA26163; Fri, 23 Mar 2001 08:48:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22388 Fri, 23 Mar 2001 10:38:32 -0500 (EST) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Fri, 23 Mar 2001 17:24:35 +0200 (EET) From: Helger Lipmaa To: ipsec@lists.tislabs.com Subject: RE: Death to AH (was Re: SA identification) In-Reply-To: <49B96FCC784BC54F9675A6B558C3464E166352@MAIL.netoctave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Mar 2001, Ray Savarda wrote: > To add another voice to the chorus - we would certainly like to see AH > removed as a requirement. From our perspective it just adds complexity > without adding much value, and at high speeds, life (IPSEC) is already > complex enough! A friend who recently got involved with ipsec has a paranoid idea that IPSec is NSA's revenge/tradeoff for enabling strong cryptography. What is the use of good algorithms if a protocol is so complex that it is almost intractable to implement, analyse and apply? Helger PS This is not my personal opinion. :-) From owner-ipsec@lists.tislabs.com Fri Mar 23 08:52:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA26393; Fri, 23 Mar 2001 08:52:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22497 Fri, 23 Mar 2001 10:51:54 -0500 (EST) Message-ID: <3ABB71EE.BC4DE27A@nomadiclab.com> Date: Fri, 23 Mar 2001 17:55:25 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.76 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: IP Security List Subject: Re: Death to AH (was Re: SA identification) References: <3ABA323A.A3B0DE33@F-Secure.com> <3ABA7728.7060707@kolumbus.fi> <3ABB0EBC.8A386D20@cyphers.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Based on discussion with some people, I'd like to ask a simple question. I know, most of this has been discussed to death before, but for me the exact reason for killing AH seems unclear. If you don't want to clutter the list, feel free to send your reply to me and I'll try to summarize whatever I receive. Thus, which do you consider a bigger problem in AH, a) the fact that AH protects the IP addresses, which make it impossible to change the addresses on the fly, or b) the fact that AH attempts to protect all of "immutable" fields in the IP address, and actually deciding which fields are immutable and which are not is not that easy, or c) doing AH right is just hard because all that hassle with mutable vs. immutable fields in the header? That is, is it that wrt NAT the IP address fields are not immutable anymore, and therefore protecting them with AH seems not that productive. Or is it that there are also other fields that are considered immutable by the AH spec but are not. Or is it that doing AH right is just so complex because you have to parse the header and zero some fields etc? (I don't see any reason for protecting the addresses since if you are doing end-to-end ipsec, protecting the addresses is (almost) pointless, and if you are not doing end-to-end and want to rely on addresses, you most probably want to do tunneling anyway). Or am I missing something, and the problem with AH is something completely different? --Pekka From owner-ipsec@lists.tislabs.com Fri Mar 23 10:30:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00490; Fri, 23 Mar 2001 10:30:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22780 Fri, 23 Mar 2001 12:30:10 -0500 (EST) Date: Fri, 23 Mar 2001 12:33:22 -0500 (EST) From: Henry Spencer To: Pekka Nikander cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <3ABB71EE.BC4DE27A@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Mar 2001, Pekka Nikander wrote: > ...for me the exact reason for killing AH seems unclear... > Or am I missing something, and the problem with AH is something > completely different? It adds substantial complexity to IPsec -- a set of protocols which is already too complex (an especially bad thing in a security system) -- for little or no benefit. That's the big one. The awkward implementation, and the incompatibilities with things like NAT, are significant but definitely secondary issues. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 23 10:32:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00581; Fri, 23 Mar 2001 10:32:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22835 Fri, 23 Mar 2001 12:38:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103221643.f2MGhF901685@thunk.east.sun.com> References: <200103221643.f2MGhF901685@thunk.east.sun.com> Date: Fri, 23 Mar 2001 12:43:49 -0500 To: sommerfeld@East.Sun.COM From: Stephen Kent Subject: Re: SA identification Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:43 AM -0500 3/22/01, Bill Sommerfeld wrote: >Regardless of what you do, the destination address is an implicit >discriminator because the IP layer ensures that packets to a different >system won't make it to AH/ESP. > >> - do we have any examples of plausible scenarios where we >> need the destination address as a discriminator for inbound traffic >> (inn addition to the SPI)? > >Steve Bellovin also brought up the multicast case. (I'd say >"non-unicast" rather than "multicast" since someone may want secure >anycast some day as well). Good point. >There's also the question of exactly where the SADB lies -- folks seem >to be building a fair number of "non-traditional" hosts -- whether >hosting multiple virtual hosts inside a single computer, or >load-spreading a single destination address across many computers. No >doubt someone's eventually going to want to do both of the above >simultaneously. Hmmm. Had't considered that issue. In the first case, this is a problem if one has a single IPsec "device" serving all of the hosts and yet not acting as a security gateway, right? Doesn't the IP implementation have to be "funny" here too? In the second case, I'm not sure how the use of the dest IP address enters into the discussion. Could you elaborate? > >> - how strongly would vendors feel about changing the spec to >> remove the requirement to match on all 3 values noted above? > >Our implementation allows SA's to be specified with a wildcarded >destination. > >I'd oppose removing protocol as a discriminator for inbound SA lookup. > >> Note that SA identification is a local matter for an IPsec receiver, >> and thus it should be possible for a receiver to use just the SPI >> just through appropriate management of that space. So the question is >> really whether anyone manages SPIs in a fashion that relies on using >> the other two values for differentiation. > >Our implementation has separate loadable modules (and separate tables) >for ESP vs. AH SA's. > So that's one vote for keeping in the AH/ESP discriminator even if AH is not required, right? Steve From owner-ipsec@lists.tislabs.com Fri Mar 23 10:41:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00794; Fri, 23 Mar 2001 10:41:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22880 Fri, 23 Mar 2001 12:48:20 -0500 (EST) Message-ID: <10C8636AE359D4119118009027AE9987064C4422@FMSMSX34> From: "Walker, Jesse" To: "'Pekka Nikander'" , IP Security List Subject: RE: Death to AH (was Re: SA identification) Date: Fri, 23 Mar 2001 09:51:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pekka, Here is my response to your question: 1. Almost no one but a very tiny minority of IPsec users employ AH, at least among our customer base. But AH doubles the testing cost of IPsec per se (as distinct from key management). Testing dominates the cost of developing and deploying IPsec, so AH seems like a non-trivial tax to impose on everyone who otherwise might want to use IPsec. This does not seem like a reasonable engineering tradeoff if an alternative exists. 2. The added complexity of AH bloats the IPsec drivers and silicon and makes it much harder to determine when they have been designed and implemented correctly. As an industry it's hard to understand how anyone can think we know whether we are really contributing to anyone's security, because correctly analyzing the security properties of implementations that do all the AH/ESP/IPPCP/Tunnel/Transport combinations with 5 different ciphers (and Null encryption, too), 3 MACs, and 2 compression protocols is something we have repeatedly proved human beings can't reliably do with much facility or grace. Eliminating rarely used options leads to simpler implementations that are easier to understand and therefore to an improved likelihood the device will operate correctly, given the same level of due diligence on our part as implementors. 3. Most users of IPsec technology can't figure out when to use AH and when to use ESP with data authentication. Any protocol that tries like IPsec to market itself as everyone's answer to wire security had better be correctly configured by any second grader, and IPsec can't exactly claim this at the moment. Getting rid of options, especially infrequently sued options, would certainly contribute toward this so far ignored requirement. There were about 6 of us (out of 2 or 3 hundred) who voted to abolish AH at the LA IETF meeting, and the subject keeps coming up with regularity every 9 months or so, but AH stays in the spec as mandatory to implement. What reason can anyone give to hope that anything has changed? This discussion has identified one AH application, and because of this it will be very hard to root it out, no matter what the relative merits of casting it out versus retaining it as mandatory to implement. -- Jesse Walker -----Original Message----- From: Pekka Nikander [mailto:Pekka.Nikander@nomadiclab.com] Sent: Friday, March 23, 2001 7:55 AM To: IP Security List Subject: Re: Death to AH (was Re: SA identification) Based on discussion with some people, I'd like to ask a simple question. I know, most of this has been discussed to death before, but for me the exact reason for killing AH seems unclear. If you don't want to clutter the list, feel free to send your reply to me and I'll try to summarize whatever I receive. Thus, which do you consider a bigger problem in AH, a) the fact that AH protects the IP addresses, which make it impossible to change the addresses on the fly, or b) the fact that AH attempts to protect all of "immutable" fields in the IP address, and actually deciding which fields are immutable and which are not is not that easy, or c) doing AH right is just hard because all that hassle with mutable vs. immutable fields in the header? That is, is it that wrt NAT the IP address fields are not immutable anymore, and therefore protecting them with AH seems not that productive. Or is it that there are also other fields that are considered immutable by the AH spec but are not. Or is it that doing AH right is just so complex because you have to parse the header and zero some fields etc? (I don't see any reason for protecting the addresses since if you are doing end-to-end ipsec, protecting the addresses is (almost) pointless, and if you are not doing end-to-end and want to rely on addresses, you most probably want to do tunneling anyway). Or am I missing something, and the problem with AH is something completely different? --Pekka From owner-ipsec@lists.tislabs.com Fri Mar 23 11:00:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA01693; Fri, 23 Mar 2001 11:00:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22982 Fri, 23 Mar 2001 13:11:19 -0500 (EST) Message-Id: <3.0.3.32.20010323101245.00d0c668@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 23 Mar 2001 10:12:45 -0800 To: Helger Lipmaa , ipsec@lists.tislabs.com From: Alex Alten Subject: RE: Death to AH (was Re: SA identification) In-Reply-To: References: <49B96FCC784BC54F9675A6B558C3464E166352@MAIL.netoctave.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:24 PM 3/23/2001 +0200, Helger Lipmaa wrote: >On Fri, 23 Mar 2001, Ray Savarda wrote: > > > To add another voice to the chorus - we would certainly like to see AH > > removed as a requirement. From our perspective it just adds complexity > > without adding much value, and at high speeds, life (IPSEC) is already > > complex enough! > >A friend who recently got involved with ipsec has a paranoid idea that >IPSec is NSA's revenge/tradeoff for enabling strong cryptography. What is >the use of good algorithms if a protocol is so complex that it is almost >intractable to implement, analyse and apply? > >Helger >PS This is not my personal opinion. :-) > When ipsec came out for last call in Feb. 1998 I voiced exactly this concern about overall complexity (including problems with AH) in a detailed email to the WG. It is a pity that so many people and firms have spent countless hours and money on it and only now are finally realizing the system design flaws. The NSA has probably been laughing behind our backs for the past two years. - Alex -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Mar 23 11:01:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA01744; Fri, 23 Mar 2001 11:01:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22947 Fri, 23 Mar 2001 13:06:20 -0500 (EST) From: ji@research.att.com Date: Fri, 23 Mar 2001 13:10:25 -0500 (EST) Message-Id: <200103231810.NAA16783@bual.research.att.com> To: ipsec@lists.tislabs.com Subject: Two issues: AH death, and SA identification Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm probably going to get lynched for this, but here it is anyway: Let's get a new protocol number, call it something like SESP (SPI-only ESP), and use that as the protocol that only uses the SPI as a selector. This way we don't have to touch AH or ESP, and most of the code can be shared between ESP and SESP. Another option is to reserve the top bit of the SPI to indicate RFC2401 processing (proto, dst addr, SPI are all significant) or not (only SPI is significant). Either way, implementations that keep separate SPI tables for AH and ESP would not be affected, as they would still get to chose the SPI for themselves. /ji -- /\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department \/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA /\ against | "Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals" (Fritz the Cat) From owner-ipsec@lists.tislabs.com Fri Mar 23 12:22:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA06385; Fri, 23 Mar 2001 12:22:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23149 Fri, 23 Mar 2001 13:58:05 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103231845.f2NIj8l26371@nyarlathotep.keromytis.org> References: <200103231845.f2NIj8l26371@nyarlathotep.keromytis.org> Date: Fri, 23 Mar 2001 13:58:44 -0500 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: SA identification Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:45 PM -0500 3/23/01, Angelos D. Keromytis wrote: >In message , Stephen Kent writes: >>At 9:15 PM +0200 3/22/01, Markku Savela wrote: >> >>As the SCTP presentation and ID shows, it is not purely a local >>matter. If we did away with the requirement to use the destination >>address as part of the SA selection process at a receiver, there >>would be no need to make this process more complex to accommodate >>SCTP requirements. > >That's correct for the receiver; the sender still has to be able to >use the destination address as part of the SA lookup, and thus has to be >able to do a many-to-one mapping based on the address. >-Angelos No argument there! Steve From owner-ipsec@lists.tislabs.com Fri Mar 23 12:29:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07275; Fri, 23 Mar 2001 12:29:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23399 Fri, 23 Mar 2001 14:36:00 -0500 (EST) Message-Id: <200103231845.f2NIj8l26371@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Stephen Kent Cc: Markku Savela , ipsec@lists.tislabs.com Subject: Re: SA identification In-reply-to: Your message of "Fri, 23 Mar 2001 10:23:10 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Mar 2001 13:45:08 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Stephen Kent writes: >At 9:15 PM +0200 3/22/01, Markku Savela wrote: > >As the SCTP presentation and ID shows, it is not purely a local >matter. If we did away with the requirement to use the destination >address as part of the SA selection process at a receiver, there >would be no need to make this process more complex to accommodate >SCTP requirements. That's correct for the receiver; the sender still has to be able to use the destination address as part of the SA lookup, and thus has to be able to do a many-to-one mapping based on the address. -Angelos From owner-ipsec@lists.tislabs.com Fri Mar 23 12:36:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07865; Fri, 23 Mar 2001 12:36:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23425 Fri, 23 Mar 2001 14:37:01 -0500 (EST) Message-Id: <200103231905.f2NJ5rl22685@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Stephen Kent Cc: sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: SA identification In-reply-to: Your message of "Fri, 23 Mar 2001 12:43:49 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Mar 2001 14:05:53 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Stephen Kent writes: > >Hmmm. Had't considered that issue. In the first case, this is a >problem if one has a single IPsec "device" serving all of the hosts >and yet not acting as a security gateway, right? Doesn't the IP >implementation have to be "funny" here too? Only in that IPsec packets have to be passed to the IPsec stack, regardless of whether the packet is destined for the local host or not -- the code for that is really minimal, especially if the OS in question has bridging support. But, I don't see where the destination address comes into it, *unless* the "device" does not also run the key management (e.g., IKE), but is somehow told what the SA parameters are. Which reminds me -- isn't 3GPP proposing to do exactly that ? Perhaps removing the destination address as an SAD selector would make this impossible (in which case, I'm in favor -- that scheme sounds hare-brained). However, it occurs to me that Bill might have meant that a single box is pretending to be multiple virtual hosts in all manners (all the way up to application land), which would imply the need for a complete separation between the different virtual hosts' SADs. Two ways to implement this is either through a two-stage lookup (find the SAD that corresponds to a particular address, then do the SA lookup in that --- or, use one SAD with (address,spi,protocol) as the key, exactly as we do now, and trust the SAD to do the separation). -Angelos From owner-ipsec@lists.tislabs.com Fri Mar 23 12:51:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA09116; Fri, 23 Mar 2001 12:51:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23479 Fri, 23 Mar 2001 15:04:49 -0500 (EST) Message-Id: <200103232008.f2NK8B902595@thunk.east.sun.com> From: Bill Sommerfeld To: Jun-ichiro itojun Hagino cc: Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of "Fri, 23 Mar 2001 10:14:47 +0900." <20010323011447.48AD97E75@starfruit.itojun.org> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 23 Mar 2001 15:08:11 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > so i guess "death to AH" and "ipsec is for VPN only" are > related. As others have pointed out, this relationship is weak at best. In particular, any IPsec implementation should include policy checks after ESP decapsulation which not only verify that the IP headers haven't been tampered during transit, but also that they were correct to begin with.. > it is correct that there are certain extension headers that does not > need protection, however, there are certain application that needs > AH (especially with transport mode). as increasing number of protocol > documents are relying upon the existence of ESP and AH (like most of > IPv6 routing protocols) Could you give pointers? (i don't follow the routing area closely). > i believe we need AH definitely. I think we need a "this is how to use ipsec to protect your protocol"/"this is what ipsec provides to upper-layer protocols" document... - Bill From owner-ipsec@lists.tislabs.com Fri Mar 23 13:15:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10736; Fri, 23 Mar 2001 13:15:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23506 Fri, 23 Mar 2001 15:18:52 -0500 (EST) Message-Id: <200103232022.f2NKMo902718@thunk.east.sun.com> From: Bill Sommerfeld To: IP Security List Subject: Re: Death to AH (was Re: SA identification) Reply-to: sommerfeld@East.Sun.COM Date: Fri, 23 Mar 2001 15:22:49 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is at least one other reason why AH's authentication of the ip header is useful.. In the case of multicast SA's, AH's checksum over the IP source address protects the ip source address from tampering. There has been interest in and work on using IPsec to protect IPv6 neighbor discovery/router discovery. While I'm not certain, I believe that it's necessary to protect the IPv6 source address to completely protect ND messages. AH does this; "transport-mode" ESP doesn't. Using a v6-in-v6 encapsulation ("tunnel mode") for ND would be tricky/annoying. - Bill From owner-ipsec@lists.tislabs.com Fri Mar 23 13:19:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10909; Fri, 23 Mar 2001 13:19:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23539 Fri, 23 Mar 2001 15:29:00 -0500 (EST) Message-ID: <3ABBB2C4.BE527C4A@storm.ca> Date: Fri, 23 Mar 2001 15:32:04 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: IP Security List Subject: Re: Death to AH (was Re: SA identification) References: <3ABA323A.A3B0DE33@F-Secure.com> <3ABA7728.7060707@kolumbus.fi> <3ABB0EBC.8A386D20@cyphers.net> <3ABB71EE.BC4DE27A@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pekka Nikander wrote: > > ... I know, most of this has been discussed to death before, > but for me the exact reason for killing AH seems unclear. One set of reasons are given in the Schneier and Ferguson analysis at: http://www.counterpane.com/ipsec.pdf I'd say several of their recommendations were absolute no-brainers: 1) eliminate transport mode 2) eliminate AH 3) make authentication mandatory for ESP 5) remove the weak key checks; just don't use algorithms where weak keys are a risk In my view, we should just do all of these. As for their other recommendations: 4) modify ESP to ensure it authenticates all data used in deciphering 6) modify KEYMAT derivation 7) modify hashing 8) modify phase 2 KEYMAT derivation These all look all look correct to me as well, but the issues are more complex and I think we'd need fairly extensive discussion before implementing them. From owner-ipsec@lists.tislabs.com Fri Mar 23 13:23:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA11015; Fri, 23 Mar 2001 13:23:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23565 Fri, 23 Mar 2001 15:36:34 -0500 (EST) Date: Fri, 23 Mar 2001 22:43:56 +0200 Message-Id: <200103232043.WAA28685@burp> From: Markku Savela To: ji@research.att.com CC: ipsec@lists.tislabs.com In-reply-to: <200103231810.NAA16783@bual.research.att.com> (ji@research.att.com) Subject: Re: Two issues: AH death, and SA identification Reply-to: Markku.Savela@iki.fi References: <200103231810.NAA16783@bual.research.att.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Let's get a new protocol number, call it something like SESP (SPI-only > ESP), and use that as the protocol that only uses the SPI as a > selector. This way we don't have to touch AH or ESP, and most of the > code can be shared between ESP and SESP. Why would you need a new protocol number if you changed this? "On the wire" format for IPSEC AH and ESP packets would not change at all. [or did I miss some sarcasm in the proposal?] Whether IPSEC implementation allows "any destination" on incoming SA, is visible to outside observer only through the key management. If a change is made, it will affect IKE negotiations and the way IKE communicates with the kernel part of the IPSEC. As for "death of AH", I agree that AH was messy to implement. But, it's a done deal, so I'm sort neutral. It's there and it works. -- Markku Savela From owner-ipsec@lists.tislabs.com Fri Mar 23 13:23:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA11029; Fri, 23 Mar 2001 13:23:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23578 Fri, 23 Mar 2001 15:39:31 -0500 (EST) Message-Id: <200103232043.f2NKhP902885@thunk.east.sun.com> From: Bill Sommerfeld To: Sandy Harris cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of "Fri, 23 Mar 2001 15:32:04 EST." <3ABBB2C4.BE527C4A@storm.ca> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 23 Mar 2001 15:43:25 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'd say several of their recommendations were absolute no-brainers: > > 1) eliminate transport mode I *strongly* disagree, unless you meant "eliminate the transport/tunnel distinction". - Bill From owner-ipsec@lists.tislabs.com Fri Mar 23 14:36:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA15348; Fri, 23 Mar 2001 14:36:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23779 Fri, 23 Mar 2001 16:46:03 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Sandy Harris Cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Mar 2001 15:17:21 -0600 Message-Id: <20010323211751.331AE35C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3ABBB2C4.BE527C4A@storm.ca>, Sandy Harris writes: >Pekka Nikander wrote: >> >> ... I know, most of this has been discussed to death before, >> but for me the exact reason for killing AH seems unclear. > >One set of reasons are given in the Schneier and Ferguson analysis at: >http://www.counterpane.com/ipsec.pdf I don't think they adequately took into account some network architecture issues. > >I'd say several of their recommendations were absolute no-brainers: > >1) eliminate transport mode No. Transport mode is for secure packets; tunnel mode creates secure wires. It creates all sorts of interesting routing table entries, makes certain checks (or attacks, in their absence -- what if the inner header has source and destination addresses of 127.0.0.1?) necessary, creates many more multi-homed hosts -- which we don't handle that cleanly in the first place, etc. And that's not even talking about bandwidth issues. >2) eliminate AH Agreed, but I've said my piece on that long ago. >3) make authentication mandatory for ESP Agreed. >5) remove the weak key checks; just don't use algorithms where weak keys are a > risk As a number of people have pointed out (I think that Bill Simpson said it first), ignore the question. Statistically, you'll never hit them anyway, so how will your test your code? Besides, unless an attacker knows that you've picked a weak key, there's no risk to you. > >In my view, we should just do all of these. > >As for their other recommendations: > >4) modify ESP to ensure it authenticates all data used in deciphering I don't have the paper handy, but how is this different from (3)? >6) modify KEYMAT derivation >7) modify hashing >8) modify phase 2 KEYMAT derivation Anything to simplify IKE! --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Fri Mar 23 14:45:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA15869; Fri, 23 Mar 2001 14:45:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23823 Fri, 23 Mar 2001 17:02:29 -0500 (EST) Date: Fri, 23 Mar 2001 16:06:01 -0600 From: Jason R Thorpe To: Bill Sommerfeld Cc: Sandy Harris , IP Security List Subject: Re: Death to AH (was Re: SA identification) Message-ID: <20010323160601.E3098@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Bill Sommerfeld , Sandy Harris , IP Security List References: <3ABBB2C4.BE527C4A@storm.ca> <200103232043.f2NKhP902885@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103232043.f2NKhP902885@thunk.east.sun.com>; from sommerfeld@East.Sun.COM on Fri, Mar 23, 2001 at 03:43:25PM -0500 Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 23, 2001 at 03:43:25PM -0500, Bill Sommerfeld wrote: > > I'd say several of their recommendations were absolute no-brainers: > > > > 1) eliminate transport mode > > I *strongly* disagree, unless you meant "eliminate the > transport/tunnel distinction". Indeed. My personal inclination would be to nuke the idea of "tunnel" mode -- if you want tunnels, build them using proto 4 or proto 41, and secure that trafic with transport mode ESP. -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Fri Mar 23 15:33:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA18759; Fri, 23 Mar 2001 15:33:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23895 Fri, 23 Mar 2001 17:47:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103232043.WAA28685@burp> References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> Date: Fri, 23 Mar 2001 17:51:24 -0500 To: Markku.Savela@iki.fi From: Stephen Kent Subject: Re: Two issues: AH death, and SA identification Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:43 PM +0200 3/23/01, Markku Savela wrote: > > Let's get a new protocol number, call it something like SESP (SPI-only >> ESP), and use that as the protocol that only uses the SPI as a >> selector. This way we don't have to touch AH or ESP, and most of the >> code can be shared between ESP and SESP. > >Why would you need a new protocol number if you changed this? "On the >wire" format for IPSEC AH and ESP packets would not change at all. [or >did I miss some sarcasm in the proposal?] The protocol is more than the format of bits on the wire; it also encompasses the processing at seder and receiver. So, if these changes affect that processing, it's not the same protocol. Steve From owner-ipsec@lists.tislabs.com Fri Mar 23 15:37:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA19017; Fri, 23 Mar 2001 15:37:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23889 Fri, 23 Mar 2001 17:47:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3ABBB2C4.BE527C4A@storm.ca> References: <3ABA323A.A3B0DE33@F-Secure.com> <3ABA7728.7060707@kolumbus.fi> <3ABB0EBC.8A386D20@cyphers.net> <3ABB71EE.BC4DE27A@nomadiclab.com> <3ABBB2C4.BE527C4A@storm.ca> Date: Fri, 23 Mar 2001 17:49:42 -0500 To: Sandy Harris From: Stephen Kent Subject: Re: Death to AH (was Re: SA identification) Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy, >Pekka Nikander wrote: >> >> ... I know, most of this has been discussed to death before, >> but for me the exact reason for killing AH seems unclear. > >One set of reasons are given in the Schneier and Ferguson analysis at: >http://www.counterpane.com/ipsec.pdf > >I'd say several of their recommendations were absolute no-brainers: > >1) eliminate transport mode >2) eliminate AH >3) make authentication mandatory for ESP >5) remove the weak key checks; just don't use algorithms where weak >keys are a risk > >In my view, we should just do all of these. I assume you have not followed the discussions on this list over the last 12 months, where we have extensively discussed some of these issues. The paper you cite has many good points, but it is not written from the perspective of folks who are IP or network experts. Some of the proposals that you consider "absolute no brainers" do not have widespread support in the WG, for good technical reasons. Steve From owner-ipsec@lists.tislabs.com Fri Mar 23 16:23:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA20940; Fri, 23 Mar 2001 16:23:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23981 Fri, 23 Mar 2001 18:20:03 -0500 (EST) Message-ID: <3ABBDAE8.10C4BD86@storm.ca> Date: Fri, 23 Mar 2001 18:23:20 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: IP Security List Subject: Re: Death to AH (was Re: SA identification) References: <200103232043.f2NKhP902885@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > > I'd say several of their recommendations were absolute no-brainers: > > > > 1) eliminate transport mode > > I *strongly* disagree, unless you meant "eliminate the > transport/tunnel distinction". The suggestion is Schneier and Ferguson's, and they said transport mode. Methinks you can implement either mode in terms of the other, either doing tunnels over transport connections or treating transport mode as a tunnel with single machines as endpoints. From owner-ipsec@lists.tislabs.com Fri Mar 23 16:23:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA20953; Fri, 23 Mar 2001 16:23:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23975 Fri, 23 Mar 2001 18:18:08 -0500 (EST) To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Death to AH (was Re: SA identification) Date: 23 Mar 2001 23:21:48 GMT Organization: University of California, Berkeley Lines: 19 Distribution: isaac Message-ID: <99glqc$4nd$1@abraham.cs.berkeley.edu> References: <200103232022.f2NKMo902718@thunk.east.sun.com> Reply-To: daw@cs.berkeley.edu (David Wagner) NNTP-Posting-Host: mozart.cs.berkeley.edu X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: >In the case of multicast SA's, AH's checksum over the IP source >address protects the ip source address from tampering. I promised myself I wouldn't get into the "Death to AH" argument, but... Could you elaborate? I can see only two cases: - Multicast where multiple sources share the same SA: If so, the AH MAC doesn't help, because each of the sources can spoof each other. - Multicast where only a single source can use that SA: If so, the AH MAC is unnecessary, because the SA should be associated (at the receiver) with a single source IP address, and receivers could simply ignore the source IP address from the packet and overwrite it with the source IP address negotiated securely when the SA was formed. In addition, all receivers who can verify the correctness of the AH MAC can forge valid MAC's, so I don't see how the MAC over the IP source address is buying you anything. Where did I go wrong? From owner-ipsec@lists.tislabs.com Fri Mar 23 16:38:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA21950; Fri, 23 Mar 2001 16:38:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24023 Fri, 23 Mar 2001 18:46:57 -0500 (EST) Message-ID: <3ABBE165.6CDAB413@isi.edu> Date: Fri, 23 Mar 2001 15:51:01 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 CC: IP Security List Subject: Re: Death to AH (was Re: SA identification) References: <200103232043.f2NKhP902885@thunk.east.sun.com> <3ABBDAE8.10C4BD86@storm.ca> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms29AFEA0AE1DD14522736AF3D" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms29AFEA0AE1DD14522736AF3D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sandy Harris wrote: > Methinks you can implement either mode in terms of the other, either doing tunnels > over transport connections or treating transport mode as a tunnel with single > machines as endpoints. Assuming you mean IPIP tunnels with IPsec transport SAs, draft-touch-ipsec-vpn-01.txt has details on the former. As for the latter, it'd be interesting to see how much overhead end-to-end tunnel mode really has (smaller MTU + slightly higher per-packet processing overhead). And current implementations (I'm familiar with) don't integrate IPsec tunnels with dynamic routing. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms29AFEA0AE1DD14522736AF3D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMyMzIzNTEwMVowIwYJKoZIhvcNAQkEMRYE FNRjpI0IfDHo/HT6ChZH+85rEAzrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAzBhba7pt/IUGPlPP+efF3+nrkTa6s/rsR9msgmwgXyh4UGrgmTnR 8DZFqI0BjC/a72WitO6YBCIfMBmh+49wS3oKbP8OMieAZa4VW5aeUPTIDjdDLzeU9zNPjJ6f L5T+vdwyXvvETGjJeHm/dqMpzegHwP8NjJ+2dMeq0hsNBDI= --------------ms29AFEA0AE1DD14522736AF3D-- From owner-ipsec@lists.tislabs.com Fri Mar 23 18:17:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA27203; Fri, 23 Mar 2001 18:17:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24291 Fri, 23 Mar 2001 20:18:52 -0500 (EST) Message-Id: <200103240122.f2O1Mn903142@thunk.east.sun.com> From: Bill Sommerfeld To: daw@cs.berkeley.edu (David Wagner) cc: ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of "23 Mar 2001 23:21:48 GMT." <99glqc$4nd$1@abraham.cs.berkeley.edu> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 23 Mar 2001 20:22:49 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - Multicast where multiple sources share the same SA: > If so, the AH MAC doesn't help, because each of the sources > can spoof each other. I'm worried about someone who is not a member of the multicast group (i.e., not in posession of the SA's key) substituting a different source address and thus subverting a communication between members of the group. > In addition, all receivers who can verify the correctness of the AH > MAC can forge valid MAC's, so I don't see how the MAC over the IP source > address is buying you anything. Where did I go wrong? It protects against forgery/tampering by parties not in posession of the SA's key. - Bill From owner-ipsec@lists.tislabs.com Fri Mar 23 20:35:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA00801; Fri, 23 Mar 2001 20:35:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24422 Fri, 23 Mar 2001 22:28:41 -0500 (EST) Date: Fri, 23 Mar 2001 21:32:12 -0600 From: Jason R Thorpe To: Sandy Harris Cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) Message-ID: <20010323213212.I3098@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Sandy Harris , IP Security List References: <200103232043.f2NKhP902885@thunk.east.sun.com> <3ABBDAE8.10C4BD86@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ABBDAE8.10C4BD86@storm.ca>; from sandy@storm.ca on Fri, Mar 23, 2001 at 06:23:20PM -0500 Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 23, 2001 at 06:23:20PM -0500, Sandy Harris wrote: > The suggestion is Schneier and Ferguson's, and they said transport mode. > > Methinks you can implement either mode in terms of the other, either doing tunnels > over transport connections or treating transport mode as a tunnel with single > machines as endpoints. Well, you *could* emulate transport mode that way, but it would mean needless overhead (extra IP header), and tunnel mode isn't really straightforward to implement (IP-IP tunnels + transport has a much nicer code path on many implementations). -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Sat Mar 24 01:30:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA27460; Sat, 24 Mar 2001 01:30:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24817 Sat, 24 Mar 2001 03:22:02 -0500 (EST) Date: Sat, 24 Mar 2001 10:29:31 +0200 Message-Id: <200103240829.KAA29352@burp> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Fri, 23 Mar 2001 17:51:24 -0500) Subject: Re: Two issues: AH death, and SA identification Reply-to: Markku.Savela@iki.fi References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Why would you need a new protocol number if you changed this? "On the > >wire" format for IPSEC AH and ESP packets would not change at all. > > The protocol is more than the format of bits on the wire; it also > encompasses the processing at seder and receiver. So, if these > changes affect that processing, it's not the same protocol. When I say "on the wire format doesn't change", I also intended to include: a change in processing on one end doesn't affect the processing on the other end. The avoid further confusions, what is the proper term to express this condition? Just say "change is internal implementation issue"? The processing of incoming SA and destination address is exactly such "internal implementation decision". => My conclusion: no new protocol number for ESP/AH is required. HOWEVER, I did say that such change probably would change the IKE negotiations. But, that is a different protocol. The tunnel vs. transport mode is related issue. As coded, a "tunnel mode" is just "transport mode applied to IP tunnel" (even though, the tunnel wrap/unwrap is also done within IPSEC) . Again, using my above definition, this is "internal implementation issue". -- Markku Savela From owner-ipsec@lists.tislabs.com Sat Mar 24 04:39:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA15678; Sat, 24 Mar 2001 04:39:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25029 Sat, 24 Mar 2001 06:55:53 -0500 (EST) To: sommerfeld@East.Sun.COM Cc: IP Security List In-reply-to: sommerfeld's message of Fri, 23 Mar 2001 15:08:11 EST. <200103232008.f2NK8B902595@thunk.east.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Death to AH (was Re: SA identification) From: Jun-ichiro itojun Hagino Date: Sat, 24 Mar 2001 20:55:06 +0900 Message-Id: <20010324115506.9ABE97E7E@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> so i guess "death to AH" and "ipsec is for VPN only" are >> related. >As others have pointed out, this relationship is weak at best. >In particular, any IPsec implementation should include policy checks >after ESP decapsulation which not only verify that the IP headers >haven't been tampered during transit, but also that they were correct >to begin with.. the verification will be able to cover only IP source/destination address and protocol number only. am I correct? >> it is correct that there are certain extension headers that does not >> need protection, however, there are certain application that needs >> AH (especially with transport mode). as increasing number of protocol >> documents are relying upon the existence of ESP and AH (like most of >> IPv6 routing protocols) >Could you give pointers? (i don't follow the routing area closely). here are a (probably incomplete) list of protocols that says "use IPsec to secure traffic". in IPv4 they provided upper-layer mechanism to secure the protocol, and now they do not provide upper-layer mechanism for IPv6 because they rely upon IPsec though I need to diagnose each of them further, my take is that for routing protocols we prefer transport mode AH than ESP. - mobile-ip6 a lot of extension headers need protection, we do not really want encryption for most of these - RIPng (RFC2080) explicitly refers AH and ESP - OSPFv3 (RFC2740) explicitly refers AH and ESP - IPv6 router renumbering (RFC2894) tries to protect site-local multicast by IPsec! - IPv6 tunnel broker (RFC3053) itojun From owner-ipsec@lists.tislabs.com Sat Mar 24 04:41:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA15896; Sat, 24 Mar 2001 04:41:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA25046 Sat, 24 Mar 2001 07:06:46 -0500 (EST) To: daw@cs.berkeley.edu (David Wagner) Cc: ipsec@lists.tislabs.com In-reply-to: daw's message of 23 Mar 2001 23:21:48 GMT. <99glqc$4nd$1@abraham.cs.berkeley.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Death to AH (was Re: SA identification) From: Jun-ichiro itojun Hagino Date: Sat, 24 Mar 2001 21:06:07 +0900 Message-Id: <20010324120607.826417E7E@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Bill Sommerfeld wrote: >>In the case of multicast SA's, AH's checksum over the IP source >>address protects the ip source address from tampering. >I promised myself I wouldn't get into the "Death to AH" argument, but... >Could you elaborate? I can see only two cases: >- Multicast where multiple sources share the same SA: > If so, the AH MAC doesn't help, because each of the sources > can spoof each other. why do you consider AH so special here? whoever has the secret key for an SA can forge anything over SA. itojun From owner-ipsec@lists.tislabs.com Sat Mar 24 10:52:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13191; Sat, 24 Mar 2001 10:52:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25837 Sat, 24 Mar 2001 12:48:14 -0500 (EST) From: "Joseph D. Harwood" To: Cc: "Ipsec" Subject: Re: Death to AH (was Re: SA identification) Date: Sat, 24 Mar 2001 09:54:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> I'd say several of their recommendations were absolute no-brainers: >> >> 1) eliminate transport mode > >I *strongly* disagree, unless you meant "eliminate the >transport/tunnel distinction". Could you elaborate on what you mean by "eliminate the transport/tunnel distinction"? Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com From owner-ipsec@lists.tislabs.com Sat Mar 24 10:54:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13303; Sat, 24 Mar 2001 10:54:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25905 Sat, 24 Mar 2001 13:17:11 -0500 (EST) Mime-Version: 1.0 X-Sender: larse@boreas.isi.edu (Unverified) Message-Id: In-Reply-To: <200103240829.KAA29352@burp> References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> <200103240829.KAA29352@burp> Date: Sat, 24 Mar 2001 10:21:15 -0800 To: ipsec@lists.tislabs.com From: Lars Eggert Subject: Re: Two issues: AH death, and SA identification Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:29 AM +0200 3/24/01, Markku Savela wrote: >The tunnel vs. transport mode is related issue. As coded, a "tunnel >mode" is just "transport mode applied to IP tunnel" (even though, the >tunnel wrap/unwrap is also done within IPSEC) . Again, using my above >definition, this is "internal implementation issue". Yes and no. Implementation choices affect upper layers, the IPsec tunnel mode is a good example. Consider a virtual network of tunnels: C / \ A--B E--F \ / D Each link in the topology is a tunnel. For a packet from A->F, B has two path choices. Using a tunneling mechanisms whose implementation is based on tunnel devices (which are represented in the routing table), you can run your dynamic favorite routing protocol on the virtual network, and things work. Using (some) IPsec tunnel implementations, where IPsec does (un)wrapping, tunnels are not represented in the routing table; the overlay is invisible to dynamic routing. For a simple topology (one tunnel between two security gateways), both implementations work; in the former case, packets are tunneled because they match a route, in the second case, because they match an IPsec SA. So my point is, internal implementation issues have visible consequences. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California From owner-ipsec@lists.tislabs.com Sat Mar 24 11:13:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA14715; Sat, 24 Mar 2001 11:13:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25967 Sat, 24 Mar 2001 13:39:07 -0500 (EST) Message-ID: <00aa01c0b492$51dc7080$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "Jun-ichiro itojun Hagino" Cc: "IP Security List" References: <20010324115506.9ABE97E7E@starfruit.itojun.org> Subject: Protocols that refer AH (was: Death to AH) Date: Sat, 24 Mar 2001 20:43:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > here are a (probably incomplete) list of protocols that says "use > IPsec to secure traffic". in IPv4 they provided upper-layer mechanism > to secure the protocol, and now they do not provide upper-layer > mechanism for IPv6 because they rely upon IPsec > though I need to diagnose each of them further, my take is that > for routing protocols we prefer transport mode AH than ESP. > > - mobile-ip6 > a lot of extension headers need protection, we do not really > want encryption for most of these > - RIPng (RFC2080) > explicitly refers AH and ESP > - OSPFv3 (RFC2740) > explicitly refers AH and ESP > - IPv6 router renumbering (RFC2894) > tries to protect site-local multicast by IPsec! > - IPv6 tunnel broker (RFC3053) A lot of pure IPv6 (e.g. RFC 2461) refers explicitly to AH (see e.g. section 4.1). I consider this to be a bug, but thought that I should mention that many such references exist. Jari From owner-ipsec@lists.tislabs.com Sun Mar 25 21:41:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA00382; Sun, 25 Mar 2001 21:41:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28816 Sun, 25 Mar 2001 21:29:33 -0500 (EST) Subject: IPSec Working Group for VPNs To: tjenkins@catena.com, john.shriver@intel.com, ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Paul J Wanish" Date: Sat, 24 Mar 2001 20:14:32 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V507_03012001.dev00 |March 9, 2001) at 03/24/2001 08:22:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have been working on a project that requires a very scalable B-2-B solution and VPNs will plays a very large part. I think that the requirements you specified in your Nov.16, 2000 Roadmap and supporting IKE Monitoring MIB Memo of 7Feb2001 include this, but I'm not sure. So, let me explain my problem and (hopefully) get some feedback. PROBLEM STATEMENT: Strong separation of authentication of a single client credential between multiple organization to isolate the roles that the authenticated user may fulfill. SOLUTION STATEMENT: Clients shall retain a person Client Certificate. This certificate shall not be owned by an employee, but rather the personal property of the individual. The company will retain it's own identity, and not be compromised by the entire employee base. The company identity shall be retained in gateway boxes that will typically support IPSec VPN connections to another company. Therefore, any application can use the tuple of (user-identity, company identity) to map roles that can be fulfilled by the particular request. The actual deployment of this would normally involve an SSL (or SOAP) transport, when the initial authentication would result in a credential being established for the user. This credential might be kept in a cookie or encoded-URL for subsequent web request. To this point, the IPSec is not really involved. RFC adjustment: The IPSec VPN negotiation will enable the ability of an application to associate an Endpoint with an ikeEndpointTable entry. By using the SNMP Framework, extract information that would result in one of the following 3 responses (to an input of a physical IP address): This address maps to a Phase 1 certificate, with an associated netmask xx.xx.xx.xx This address maps to an identity that was authenticated in another method than IPSec, with an associated netmask xx.xx.xx.xx This address does not map to a VPN, and flows through the gateway yy.yy.yy.yy This combination allows an application gateway (I'm after Policy Director, but Siteminder might fit) to establish roles for client certificates based on where they originate from. In the case of B2B, I could use the same personal Client Certificate from two business (probably through a NAT and then VPN to get to another company and be strongly isolated in the roles I could fulfill based on the negotiated VPN (and so ID). Your comments greatly appreciated.. Paul Paul Wanish Poughkeepsie (845)435-5990 [fax (845)432-9507] cellphone(914)659-6117 From owner-ipsec@lists.tislabs.com Sun Mar 25 21:41:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA00381; Sun, 25 Mar 2001 21:41:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28808 Sun, 25 Mar 2001 21:28:34 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15036.47335.769643.270317@thomasm-u1.cisco.com> Date: Sat, 24 Mar 2001 07:10:31 -0800 (PST) To: "Marcus Leech" Cc: Henry Spencer , Francis Dupont , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <3ABAC453.8D629382@nortelnetworks.com> References: <3ABAC453.8D629382@nortelnetworks.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Marcus Leech writes: > The assertion was made that the current Mobile IPV6 spec uses > IPSEC in a way that just doesn't scale. AH was chosen by > Mobile IPV6 because it provides protection of outer header > information, including the bits of IPV6 options goop that carries > Mobile IPV6 binding updates. It's not *impossible* to use ESP > for this, but it's awkward. So, as somebody who thinks that: a) the IESG's concerns about using IPsec to correspondent nodes to protect BU's are well founded b) that AH should be nuked in general to simplify IPsec c) using IPsec between the mobile node and it's home agent for binding updates as well as *some* well known CN's (ie, not for the random web browsing case) is a good thing, especially if it provides better security properties than the ultimate solution for (a) I'd say that we either need to come up with an application layer security schemes for BU's which address (a) and (c) simultaneously or have a means to have base level IPsec protect BU's which are not dependent on AH. Charlie brought up -- and I think I agree -- that it would be unfortunate if two nodes that were already running IPsec between them and they didn't raise the "global PKI" spectre couldn't use IPsec to authenticate and authorize the BU. A trivial case is a mobile SIP phone with an SA between it and its first hop proxy which have the same localized PKI properties as the SA between the HA and MN. (indeed, between HA and MN, there may be no need for a PKI at all, cf KINK). I doubt that naive tunnel mode ESP really fits the bill well here. There are a lot of concerns about bits in the air that are quite serious and using a tunnel would at base add another 40 bytes to the overhead. I'm also rather suspicious about the contention that ROHC and its ilk make tunnel/transport moot: there is a huge amount of overhead and state machinery to run compressors and counting on them -- especially when you start talking about mobile routers -- is dubious at best. Maybe we ought to entertain Bruce Schneier's suggestions. As far as I can recall, they would seemingly address the concerns I outlined above. Even if we don't try to deprecate transport altogether, an out of band negotiation of "the inner header is the same as the outer header" compressing tunnel mode would be pretty easy to cons up for ISAKMP. Mike From owner-ipsec@lists.tislabs.com Sun Mar 25 21:41:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA00379; Sun, 25 Mar 2001 21:41:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28792 Sun, 25 Mar 2001 21:25:34 -0500 (EST) Message-Id: <200103232327.f2NNRm715729@coredump.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec@lists.tislabs.com Subject: SCTP and IPsec issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Mar 2001 18:27:48 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Per Ted's suggestion at the WG meeting, here is the list of issues mentioned in draft-ietf-ipsec-sctp-00.txt which the working group needs to decide on. First, the background: SCTP endpoints can use multiple network identifiers (addresses) that are valid for the lifetime of a connection; thus, packets in that connection can use any of a number of source and destination addresses, while still referring to the same connection. Contrast this to TCP, where each host uses one address for the lifetime of the TCP connection. So, the issues: 1) Currently, IPsec SAs are identified by the triplet (destination address, SPI, security protocol) for the purposes of locating them in the SAD. Since SCTP packets can have any of a set of destination addresses, this identification needs to be extended to be ({set of destination addresses}, SPI, security protocol). The alternative (setting up a number of SAs, for each of the valid destination addresses) does not work because of SA state issues (at least the replay counter has to be synchronized across all these SAs) and the obvious memory waste. Recommendation: the architecture document should state that SAs are identified by the extended triplet. 2) Since an SCTP connection can use a number of source and destination addresses, the SPD has to accomodate this. If the two hosts use N and M number of addresses respectively, the obvious solution is to generate N*M SPD entries. The alternative is to let SPD rules use sets of addresses as the source and destination address selectors, which has linear cost in memory and processing (N+M). Recommendation: this is an implementation issue, but it's probably a good idea to include appropriate language in the architecture document. 3) The SCTP source/destination port numbers should be included as SPD selectors. Recommendation: include this in the architecture document. No-brainer. 4) The multiple source/destination addresses need to appear in the Phase 2 ID payloads in IKE. There are two ways of doing this: a) Allow multiple source/destination ID payloads in messages 1 and 2 of IKE Quick Mode. b) Introduce a new type of ID, that allows for recursive inclusion of other IDs. Thus, Phase 2 would still only send one ID payload each for source/destination; each of these would then contain a list of the addresses for the respective endpoint. Recommendation: do (b), as we think it is less intrusive for implementations than (a). However, recursion is limited to only one-deep (i.e., you can't have a recursive ID inside a recursive ID). Subissue: 1) If we do (b), what types of IDs are allowed to appear in the recursive ID: a) Any of the defined IDs (e.g., FQDNs etc.) b) Only address-based IDs. Recommendation: Do (b). The only potential use for other IDs inside the recursive ID would be to support multi-party authentication in Phase 1 (i.e., multiple signatures from different principals in Phase 1). 5) The initiator of an IKE exchange may not know all the remote host's addresses (used for SCTP), and thus may not be able to propose an accurate Phase 2 destination ID. Solutions: a) The Responder may drop the Phase 2 exchange and start a Phase 2 exchange on its own (using the same Phase 1 SA), using information from the old exchange, providing the correct set of addresses. The advantage of this approach is that it requires no protocol changes (although implementations have to be able to deal with this initial rejection). b) The Responder could modify the Responder ID received in message 1 of Quick Mode, and send it back in message 2. The Initiator then needs to verify that this is according to policy (as opposed to doing a simple bytestring comparison, as is possible today). This requires no wire changes, but a small change in the processing at the Initiator. This is a potentially more powerful and lightweight approach (everything is still done in one exchange, and the Initiator does not have to deal with a Phase 2 exchange rejection). Recommendation: A slight bias towards (a), but feedback from other IKE implementors is needed. The draft includes some more text/advice to implementors; that may eventually turn out as a document by itself. Most of the issues mentioned in this message require changes to the architecture and IKE documents. -Angelos From owner-ipsec@lists.tislabs.com Sun Mar 25 21:41:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA00380; Sun, 25 Mar 2001 21:41:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28798 Sun, 25 Mar 2001 21:26:34 -0500 (EST) Message-Id: <200103240036.f2O0aQ701233@marajade.sandelman.ottawa.on.ca> To: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of "Fri, 23 Mar 2001 17:55:25 +0200." <3ABB71EE.BC4DE27A@nomadiclab.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 23 Mar 2001 19:36:26 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I will echo Pekka's questions. I will also ask something else: - of those that want to kill AH, how many are VPN vendors? My question to you is: why did you implement it? Because VPNC or ICSA said to? (I don't recall either making AH mandatory) Why can't the VPN vendors just remove AH from their products and be done with it? ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Mar 26 02:52:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA07515; Mon, 26 Mar 2001 02:52:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29854 Mon, 26 Mar 2001 04:57:20 -0500 (EST) Message-Id: <200103261001.OAA02381@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Sandy Harris , "Steven M. Bellovin" Date: Mon, 26 Mar 2001 14:00:40 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Death to AH (was Re: SA identification) CC: IP Security List In-reply-to: <20010323211751.331AE35C42@berkshire.research.att.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 23 Mar 01, at 15:17, Steven M. Bellovin wrote: [...] > >3) make authentication mandatory for ESP > > Agreed. [...] > >4) modify ESP to ensure it authenticates all data used in deciphering > > I don't have the paper handy, but how is this different from (3)? The paper criticized IPsec's order of performing encryption and authentication (for outgoing packets first encrypt, then authenticate), making reference to "Horton principle" (authenticate what was meant, not what was said). The authors confessed that the current order helped fast discarding of fake packets, but questioned, whether it was really important and, if so, suggested to at least include decryption key in authenticated data. > >6) modify KEYMAT derivation > >7) modify hashing > >8) modify phase 2 KEYMAT derivation > > Anything to simplify IKE! Actually, the paper's suggestions on these issues don't lead to simplification of IKE - just to fixing some IKE security weaknesses. BTW, the authors seemed to make some mistakes in their analysis here, for example, they stated that HMAC algorithm cannot be used with keys longer than 64 bytes... > --Steve Bellovin, http://www.research.att.com/~smb Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Mon Mar 26 02:53:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA07602; Mon, 26 Mar 2001 02:53:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29785 Mon, 26 Mar 2001 04:37:25 -0500 (EST) Message-Id: <200103260930.f2Q9UeA71020@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: thorpej@zembu.com cc: Bill Sommerfeld , Sandy Harris , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of Fri, 23 Mar 2001 16:06:01 CST. <20010323160601.E3098@dr-evil.shagadelic.org> Date: Mon, 26 Mar 2001 11:30:40 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > > I'd say several of their recommendations were absolute no-brainers: > > > > 1) eliminate transport mode => my intention was not to reopen the AH war, not the transport/tunnel war, but if AH and transport mode are eliminated then my "VPNs only" question will become topical (:-). > I *strongly* disagree, unless you meant "eliminate the > transport/tunnel distinction". Indeed. My personal inclination would be to nuke the idea of "tunnel" mode -- if you want tunnels, build them using proto 4 or proto 41, and secure that trafic with transport mode ESP. => the source address check should be revisited too: - this is a major difference between tunnel mode and transport mode over tunnels - many current implementations are compliant but not interoperable because of this particular point. Regards Francis.Dupont@enst-bretagne.fr PS: BTW I share Jason's opinion: tunnel mode is a real mess because it doesn't give a real status to IPsec tunnels (for instance in IPv6 we don't know if they are interfaces or not - please look at IPv6 specs if you don't understand this question). From owner-ipsec@lists.tislabs.com Mon Mar 26 07:59:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA07525; Mon, 26 Mar 2001 07:59:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00535 Mon, 26 Mar 2001 09:43:47 -0500 (EST) Message-Id: <200103261438.f2QEcDA71925@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: "Marcus Leech" , Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of Sat, 24 Mar 2001 07:10:31 PST. <15036.47335.769643.270317@thomasm-u1.cisco.com> Date: Mon, 26 Mar 2001 16:38:13 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: So, as somebody who thinks that: a) the IESG's concerns about using IPsec to correspondent nodes to protect BU's are well founded => I think the only strong argument is the authentication of random CNs and this is not really a technical argument... b) that AH should be nuked in general to simplify IPsec => the issue is to nuke enough but not too much (:-) c) using IPsec between the mobile node and it's home agent for binding updates as well as *some* well known CN's (ie, not for the random web browsing case) is a good thing, especially if it provides better security properties than the ultimate solution for (a) => c) is possible and even easy for home registration (ie. MN-HA interaction) which is a case where we *want* as good as possible security. I believe an option will be necessary to go from a) (default) to c) but c) will be IPsec like, not real IPsec. I'd say that we either need to come up with an application layer security schemes for BU's which address (a) and (c) simultaneously or have a means to have base level IPsec protect BU's which are not dependent on AH. => clearly IKE as it cannot (should not) be used so this will be an IPsec like. Charlie brought up -- and I think I agree -- that it would be unfortunate if two nodes that were already running IPsec between them and they didn't raise the "global PKI" spectre couldn't use IPsec to authenticate and authorize the BU. => I have a different concern: it will be very bad to have IPsec and mobile IPv6 new built-in security fighting together. In general I think IPsec must be far more mobility aware.... A trivial case is a mobile SIP phone with an SA between it and its first hop proxy which have the same localized PKI properties as the SA between the HA and MN. (indeed, between HA and MN, there may be no need for a PKI at all, cf KINK). => between HA and MN you should have a trusted third party (provided through AAA) but I expect something better than Kerberos. I doubt that naive tunnel mode ESP really fits the bill well here. There are a lot of concerns about bits in the air that are quite serious and using a tunnel would at base add another 40 bytes to the overhead. I'm also rather suspicious about the contention that ROHC and its ilk make tunnel/transport moot: there is a huge amount of overhead and state machinery to run compressors and counting on them -- especially when you start talking about mobile routers -- is dubious at best. => tunnel mode ESP needs many improvements before to be usable in a mobile environment (just try it or read my ID). Maybe we ought to entertain Bruce Schneier's suggestions. As far as I can recall, they would seemingly address the concerns I outlined above. Even if we don't try to deprecate transport altogether, an out of band negotiation of "the inner header is the same as the outer header" compressing tunnel mode would be pretty easy to cons up for ISAKMP. => before reread Bruce Schneier's document I can say the transport mode as compressed tunnel mode really stinks (argh! A new flame war? :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Mar 26 12:32:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA23949; Mon, 26 Mar 2001 12:32:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01442 Mon, 26 Mar 2001 14:09:16 -0500 (EST) Message-ID: <012701c0b628$79c1b960$fc2645ab@cisco.com> From: "Scott Fanning" To: "Jari Arkko" , , "Jun-ichiro itojun Hagino" Cc: "IP Security List" References: <20010324115506.9ABE97E7E@starfruit.itojun.org> <00aa01c0b492$51dc7080$8a1b6e0a@arenanet.fi> Subject: Re: Protocols that refer AH (was: Death to AH) Date: Mon, 26 Mar 2001 11:10:51 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk VRRP also talks about AH (), although it is not integral to the protocol. 5.3.6.3 IP Authentication Header. Seeing that AH does authenticate more then ESP (the outside IP Header), has there been any discussion on making a header that combines ESP and AH? I know that ESP NULL provides just authentication, but not the same coverage as AH. Scott ----- Original Message ----- From: "Jari Arkko" To: ; "Jun-ichiro itojun Hagino" Cc: "IP Security List" Sent: Saturday, March 24, 2001 10:43 AM Subject: Protocols that refer AH (was: Death to AH) > > > here are a (probably incomplete) list of protocols that says "use > > IPsec to secure traffic". in IPv4 they provided upper-layer mechanism > > to secure the protocol, and now they do not provide upper-layer > > mechanism for IPv6 because they rely upon IPsec > > though I need to diagnose each of them further, my take is that > > for routing protocols we prefer transport mode AH than ESP. > > > > - mobile-ip6 > > a lot of extension headers need protection, we do not really > > want encryption for most of these > > - RIPng (RFC2080) > > explicitly refers AH and ESP > > - OSPFv3 (RFC2740) > > explicitly refers AH and ESP > > - IPv6 router renumbering (RFC2894) > > tries to protect site-local multicast by IPsec! > > - IPv6 tunnel broker (RFC3053) > > A lot of pure IPv6 (e.g. RFC 2461) refers explicitly to AH (see > e.g. section 4.1). I consider this to be a bug, but thought that > I should mention that many such references exist. > > Jari > > > From owner-ipsec@lists.tislabs.com Mon Mar 26 12:47:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA25209; Mon, 26 Mar 2001 12:47:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01577 Mon, 26 Mar 2001 14:57:38 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Scott Fanning" Cc: "Jari Arkko" , sommerfeld@East.Sun.COM, "Jun-ichiro itojun Hagino" , "IP Security List" Subject: Re: Protocols that refer AH (was: Death to AH) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Mar 2001 15:00:03 -0500 Message-Id: <20010326200052.586B235C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <012701c0b628$79c1b960$fc2645ab@cisco.com>, "Scott Fanning" writes: >VRRP also talks about AH (), although it is >not integral to the protocol. >5.3.6.3 IP Authentication Header. > >Seeing that AH does authenticate more then ESP (the outside IP Header), has >there been any discussion on making a header that combines ESP and AH? I >know that ESP NULL provides just authentication, but not the same coverage >as AH. To what end? AH's problems come because it tries to cover too much of the packet; changing ESP to do that would cause the same problems. Remember that you can often bind the source IP address to the certificate, and check that match at decryption time. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Mon Mar 26 13:18:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA27099; Mon, 26 Mar 2001 13:18:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01664 Mon, 26 Mar 2001 15:29:26 -0500 (EST) To: Francis Dupont Cc: Michael Thomas , "Marcus Leech" , Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) References: <200103261438.f2QEcDA71925@givry.rennes.enst-bretagne.fr> From: Derek Atkins Date: 26 Mar 2001 15:33:06 -0500 In-Reply-To: Francis Dupont's message of "Mon, 26 Mar 2001 16:38:13 +0200" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => I have a different concern: it will be very bad to have IPsec > and mobile IPv6 new built-in security fighting together. > In general I think IPsec must be far more mobility aware.... Nothing says you can't have multiple security systems. Indeed, I would expect there to be multiple systems in use, even for the same connection. I have no problems running e.g. SSL/TLS over IPSec. Just because MobileIP has its own security for the BU doesn't mean that IPSec cannot be used. And just because IPSec is is use does not necessarily mean that it's the right solution for MobileIP BUs. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Mar 26 14:42:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA03175; Mon, 26 Mar 2001 14:42:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01767 Mon, 26 Mar 2001 16:53:17 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'IP Security List'" Subject: RE: Protocols that refer AH (was: Death to AH) Date: Mon, 26 Mar 2001 16:52:51 -0500 Message-Id: <000001c0b63f$1b9d1c50$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <20010326200052.586B235C42@berkshire.research.att.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think there is a definite problem in education wrt AH. Just from hearing a capsule description of ESP and AH, most people seem to think that AH is necessary. It takes quite a lot of explaining in order to help them understand the issues. Michael asked "why do VPN vendors implement AH?" The answer is because it is perceived to be necessary. Various literature on deploying VPNs talks about it. If we don't have AH then our solution may fail the "checkbox test." A lot of people who are using ipsec for routing seem to think that adding a MAC to the packet is sufficient to authenticate the header. They don't understand that intermediate routers have to check the header in order for this to be useful. However, I suppose that this does add the possibility for "opportunistic authentication" if some of the intermediate routers have the keys and others don't. I think the most likely use of AH would be within a carrier's network to prevent bandwidth stealing. But I also have trouble constructing a scenario that actually seems plausible. If a carrier network is monolithic, such that traffic never leaves the network only to return later, then this doesn't seem like a very big problem. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Mon Mar 26 14:48:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA03588; Mon, 26 Mar 2001 14:48:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01811 Mon, 26 Mar 2001 16:57:14 -0500 (EST) Message-ID: <017901c0b63f$ee0c9210$fc2645ab@cisco.com> From: "Scott Fanning" To: "Steven M. Bellovin" Cc: "Jari Arkko" , , "Jun-ichiro itojun Hagino" , "IP Security List" References: <20010326200052.586B235C42@berkshire.research.att.com> Subject: Re: Protocols that refer AH (was: Death to AH) Date: Mon, 26 Mar 2001 13:58:44 -0800 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve Just wondering. Of course, the assumption that local policy (via Certificates) will compensate for any short comings of a protocol might not necessarily be correct. Thanks Scott ----- Original Message ----- From: "Steven M. Bellovin" To: "Scott Fanning" Cc: "Jari Arkko" ; ; "Jun-ichiro itojun Hagino" ; "IP Security List" Sent: Monday, March 26, 2001 12:00 PM Subject: Re: Protocols that refer AH (was: Death to AH) > In message <012701c0b628$79c1b960$fc2645ab@cisco.com>, "Scott Fanning" writes: > >VRRP also talks about AH (), although it is > >not integral to the protocol. > >5.3.6.3 IP Authentication Header. > > > >Seeing that AH does authenticate more then ESP (the outside IP Header), has > >there been any discussion on making a header that combines ESP and AH? I > >know that ESP NULL provides just authentication, but not the same coverage > >as AH. > > To what end? AH's problems come because it tries to cover too much of > the packet; changing ESP to do that would cause the same problems. > Remember that you can often bind the source IP address to the certificate, > and check that match at decryption time. > > > --Steve Bellovin, http://www.research.att.com/~smb > > From owner-ipsec@lists.tislabs.com Mon Mar 26 14:52:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA03924; Mon, 26 Mar 2001 14:52:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01876 Mon, 26 Mar 2001 17:05:16 -0500 (EST) Message-Id: <200103262208.f2QM86907730@thunk.east.sun.com> From: Bill Sommerfeld To: Francis Dupont cc: Michael Thomas , "Marcus Leech" , Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of "Mon, 26 Mar 2001 16:38:13 +0200." <200103261438.f2QEcDA71925@givry.rennes.enst-bretagne.fr> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 26 Mar 2001 17:08:06 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > a) the IESG's concerns about using IPsec to > correspondent nodes to protect BU's are > well founded > > I think the only strong argument is the authentication of random CNs > and this is not really a technical argument. The issue is not authentication of correspondant nodes; it's one of (possibly pseudonymous) authentication of the mobile nodes to the correspondant nodes. This could be accomplished within IPsec using self-signed pseudonymous certificates if CN's which accept binding updates were prepared to accept them; there's fundamentally no reason why something like PBK's couldn't be used with IKE/IPsec. I see a more fundamental problem here with piggybacking binding updates on to regular traffic.. There's a poor interaction between the AH-only-on-binding-update and what I'll call opportunistic use of AH.. Several IPsec host implementations (solaris among them) implement a concept known as policy latching.. namely, that policy on a wildcard port/socket may be "flexible", but once a particular connection is established, the policy is "latched" to a particular value so that (for instance) once a connection is established with IPsec protection you cannot then hijack it with unauthenticated traffic. So, in the MIP case, you send a BU + TCP SYN, all authenticated with ah. The receiving node's TCP notes that the SYN packet is AH protected, and accordingly requires *all subsequent traffic* on that connection to be AH-protected. The problem here is that AH authenticates both the BU option *and* the packet as a whole, and it's not possible to tell the intent of the sender from the packet headers. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 26 16:23:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA10012; Mon, 26 Mar 2001 16:23:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02080 Mon, 26 Mar 2001 18:27:51 -0500 (EST) Message-Id: <200103262331.SAA20417@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-openpgp-01.txt Date: Mon, 26 Mar 2001 18:31:56 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : OpenPGP Key Usage in IKE Author(s) : W. Price Filename : draft-ietf-ipsec-openpgp-01.txt Pages : 3 Date : 23-Mar-01 This document defines a profile for the usage of OpenPGP keys within the IKE [IKE] protocol. The ISAKMP [ISAKMP] protocol on which IKE is based defines an identifier for the use of OpenPGP [OPENPGP] keys, but does not define how they should be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-openpgp-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-openpgp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-openpgp-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010323090406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-openpgp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-openpgp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010323090406.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Mar 26 17:30:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA15265; Mon, 26 Mar 2001 17:30:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02184 Mon, 26 Mar 2001 19:37:44 -0500 (EST) Date: Mon, 26 Mar 2001 19:41:11 -0500 (EST) From: Henry Spencer To: Francis Dupont cc: IP Security List Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: <200103260930.f2Q9UeA71020@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Mar 2001, Francis Dupont wrote: > => my intention was not to reopen the AH war, not the transport/tunnel war, > but if AH and transport mode are eliminated then my "VPNs only" question > will become topical (:-). Only to people who believe that tunnels are useful only for VPNs, which is verifiably false. Tunnel mode can do anything transport mode can do, which is a large part of the F&S argument for eliminating transport mode. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 26 19:07:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA19289; Mon, 26 Mar 2001 19:07:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02461 Mon, 26 Mar 2001 21:24:43 -0500 (EST) Date: Mon, 26 Mar 2001 21:28:08 -0500 From: Theodore Tso To: "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues Message-ID: <20010326212808.A2145@think> References: <200103232327.f2NNRm715729@coredump.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <200103232327.f2NNRm715729@coredump.cis.upenn.edu>; from angelos@cis.upenn.edu on Fri, Mar 23, 2001 at 06:27:48PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 23, 2001 at 06:27:48PM -0500, Angelos D. Keromytis wrote: > > 1) Currently, IPsec SAs are identified by the triplet > > (destination address, SPI, security protocol) > > for the purposes of locating them in the SAD. Since SCTP packets can > have any of a set of destination addresses, this identification > needs to be extended to be > > ({set of destination addresses}, SPI, security protocol). > > The alternative (setting up a number of SAs, for each of the valid > destination addresses) does not work because of SA state issues (at > least the replay counter has to be synchronized across all these > SAs) and the obvious memory waste. My apologies for being pedeantic, but you don't mean that in order to access the SAD, you have to know the complete set of the destination addresses, right? Rather, that given any one of a set of the destination addresses, the SPI, and the security protocol, one can look up an SA in the SAD. Correct? One other issue to add to your list. I was talking to some SCTP folks, and the one thing which they thought would likely be successfully added to SCTP is a mechanism for adding an additional endpoint address to an existing SCTP connection. If this feature does get added to SCTP (and I can see how it might be useful; for example, to add your new IP address if you're about to be renumbered, so you can have SCTP connections survive renumbering events) then we will need some way by which we can modify the SPD to take into account the new endpoint address. I don't think we'll need a particularly complicated mechanism to handle this. A simple solution would be to just forcing a new Phase 2 exchange whenever the endpoint address set changes; after all, I don't think this will likely be a frequent operation. - Ted From owner-ipsec@lists.tislabs.com Mon Mar 26 19:58:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA20179; Mon, 26 Mar 2001 19:58:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02584 Mon, 26 Mar 2001 22:18:29 -0500 (EST) Message-ID: <3AC00756.58C55221@cisco.com> Date: Mon, 26 Mar 2001 19:21:58 -0800 From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: SA identification References: <20010322141539.6C62C35C42@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message , Stephen Kent writes: > >During Teusday's HIP BOF , JI raised a question that I had begun to > >contemplate while working on revising 2401: why do we need three > >values to identify an SA for incoming IPsec traffic? We currently > >require matching on protocol (AH vs. ESP), SPI, and destination > >address. It's clear that the protocol input can be made redundant by > >assigning SPIs without protocol specificity. Some mobility problems > >could be addressed if we ignored destination address. So, I have two > >questions for the list: > > > > - do we have any examples of plausible scenarios where we > >need the destination address as a discriminator for inbound traffic > >(inn addition to the SPI)? > > > > - how strongly would vendors feel about changing the spec to > >remove the requirement to match on all 3 values noted above? > > > >Note that SA identification is a local matter for an IPsec receiver, > >and thus it should be possible for a receiver to use just the SPI > >just through appropriate management of that space. So the question is > >really whether anyone manages SPIs in a fashion that relies on using > >the other two values for differentiation. > > The usual answer is that multicast needs it. Now that we have a > multicast security group, this may be more important. Just so the issue is clear to everyone: while the receiver chooses all its SPIs in the unicast case, in the multicast case there are multiple systems choosing SPIs it has to recognize and the SPIs could indeed collide. Even if the multicast SPIs are all centrally managed by a key server there's a potential namespace collision with unicast SPIs. > I agree, though, that the 3-tuple requirement is annoying. And I > suspect that people would not like the answer "use a 3-tuple for > multicast, but a pair for unicast". Rather than make it multicast/unicast specific, a new SA attribute could be used to denote whether or not a 3-tuple should be used for evaluation. This would give multicast apps (or any unicast apps which wanted extra assurance) the chance to protect themselves. But I'm not sure this is any more palatable as it affects the key management system (passing the SA attribute) and adds more state to the IPSec processing. The only reason that I bother to bring it up is that I think there's a lot of value in some unicast cases to disregarding the destaddr, and it would be useful to be able to accommodate that. Brian Weis bew@cisco.com > --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Mon Mar 26 22:40:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA23697; Mon, 26 Mar 2001 22:40:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02798 Tue, 27 Mar 2001 00:49:08 -0500 (EST) Message-ID: <3AC02AA5.6B580954@cisco.com> Date: Mon, 26 Mar 2001 21:52:37 -0800 From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: SA identification References: <20010327054155.4F1ED35C42@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message <3AC00756.58C55221@cisco.com>, Brian Weis writes: > >"Steven M. Bellovin" wrote: > > > > > >Rather than make it multicast/unicast specific, a new SA attribute could > >be used to denote whether or not a 3-tuple should be used for > >evaluation. This would give multicast apps (or any unicast apps which > >wanted extra assurance) the chance to protect themselves. But I'm not > >sure this is any more palatable as it affects the key management system > >(passing the SA attribute) and adds more state to the IPSec processing. > > On receipt you can't look up the SA until after you've matched > on or ... > > --Steve Bellovin, http://www.research.att.com/~smb Oops, that is problematic. Thanks for the quick correction. Brian Weis bew@cisco.com From owner-ipsec@lists.tislabs.com Mon Mar 26 22:40:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA23711; Mon, 26 Mar 2001 22:40:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02779 Tue, 27 Mar 2001 00:37:50 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Brian Weis Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: SA identification Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Mar 2001 00:41:54 -0500 Message-Id: <20010327054155.4F1ED35C42@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3AC00756.58C55221@cisco.com>, Brian Weis writes: >"Steven M. Bellovin" wrote: > > >Rather than make it multicast/unicast specific, a new SA attribute could >be used to denote whether or not a 3-tuple should be used for >evaluation. This would give multicast apps (or any unicast apps which >wanted extra assurance) the chance to protect themselves. But I'm not >sure this is any more palatable as it affects the key management system >(passing the SA attribute) and adds more state to the IPSec processing. On receipt you can't look up the SA until after you've matched on or ... --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Tue Mar 27 03:01:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA00224; Tue, 27 Mar 2001 03:01:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03684 Tue, 27 Mar 2001 05:20:22 -0500 (EST) Reply-To: From: "Limor Elbaz" To: , , , Subject: TestBed for SSL / TLS / WTLS Date: Tue, 27 Mar 2001 12:21:22 +0200 Message-ID: <001301c0b6a7$acac71b0$010710ac@discretix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Does anyone know of a company selling out-of-the-box equipment for testing SSL / TLS / WTLS? Regarding WTLS, as far as I've seen, the WAP testing environment does not cover the WTLS layer. Thanks, Limor. From owner-ipsec@lists.tislabs.com Tue Mar 27 03:01:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA00280; Tue, 27 Mar 2001 03:01:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03657 Tue, 27 Mar 2001 05:08:38 -0500 (EST) Message-Id: <200103271009.f2RA9BA76339@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Derek Atkins cc: Michael Thomas , "Marcus Leech" , Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of 26 Mar 2001 15:33:06 CDT. Date: Tue, 27 Mar 2001 12:09:11 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis Dupont writes: > => I have a different concern: it will be very bad to have IPsec > and mobile IPv6 new built-in security fighting together. > In general I think IPsec must be far more mobility aware.... Nothing says you can't have multiple security systems. Indeed, I would expect there to be multiple systems in use, even for the same connection. I have no problems running e.g. SSL/TLS over IPSec. => this is a different concern: multiple systems are bad a priori because bug likelihood increases with complexity but the same argument applies to systems which try to do too much... Just because MobileIP has its own security for the BU doesn't mean that IPSec cannot be used. And just because IPSec is is use does not necessarily mean that it's the right solution for MobileIP BUs. => this is *not* what I wrote! Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 27 06:04:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA16012; Tue, 27 Mar 2001 06:04:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04197 Tue, 27 Mar 2001 08:13:50 -0500 (EST) Message-Id: <200103271315.f2RDF6A76782@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@East.Sun.COM cc: Michael Thomas , "Marcus Leech" , Henry Spencer , IP Security List Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of Mon, 26 Mar 2001 17:08:06 CDT. <200103262208.f2QM86907730@thunk.east.sun.com> Date: Tue, 27 Mar 2001 15:15:06 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > I think the only strong argument is the authentication of random CNs > and this is not really a technical argument. The issue is not authentication of correspondant nodes; => argh! I mean by (but as the authentication is symmetrical this is both of and by). it's one of (possibly pseudonymous) authentication of the mobile nodes to the correspondant nodes. This could be accomplished within IPsec using self-signed pseudonymous certificates if CN's which accept binding updates were prepared to accept them; there's fundamentally no reason why something like PBK's couldn't be used with IKE/IPsec. => self-signed certificates are perhaps a bit too weak (this is a matter of policy/authorization and mobile IPv6 has some problems with that. Of course the trivial solution (use real good certificates) is not deployable). I see a more fundamental problem here with piggybacking binding updates on to regular traffic.. => there is no possible fundamental problem with an optional feature. But I agree the piggybacking gains a packet at the cost of far more complex implementation (so my code never sends piggybacked BUs but accepts them). There's a poor interaction between the AH-only-on-binding-update and what I'll call opportunistic use of AH.. Several IPsec host implementations (solaris among them) implement a concept known as policy latching.. namely, that policy on a wildcard port/socket may be "flexible", but once a particular connection is established, the policy is "latched" to a particular value so that (for instance) once a connection is established with IPsec protection you cannot then hijack it with unauthenticated traffic. So, in the MIP case, you send a BU + TCP SYN, all authenticated with ah. The receiving node's TCP notes that the SYN packet is AH protected, and accordingly requires *all subsequent traffic* on that connection to be AH-protected. The problem here is that AH authenticates both the BU option *and* the packet as a whole, and it's not possible to tell the intent of the sender from the packet headers. => I understand your concern and the solution is to throw away one alternative and in this case I believe the best is to drop the TCP SYN if there is an ambiguity... (ie. as usual the upper layer will retransmit it) I believe the rationale of this bad idea (piggybacking) is to send BUs when an outgoing packet is sent (if this is in this is just when...). BTW with a dedicated security I believe the piggybacking feature for BUs and BAs will be withdrawn. No regret! Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Mar 27 07:01:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA21723; Tue, 27 Mar 2001 07:01:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04392 Tue, 27 Mar 2001 09:12:26 -0500 (EST) Message-ID: <20010327141635.4400.qmail@web1401.mail.yahoo.com> Date: Tue, 27 Mar 2001 06:16:35 -0800 (PST) From: Pyda Srisuresh Subject: Re: SCTP and IPsec issues To: Theodore Tso , "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com In-Reply-To: <20010326212808.A2145@think> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angelos, You might want to take a look at . The draft addresses the problem in IKE - negotiaing an SA for an SPD entry with multiple destination addresses; ability to dynamically alter the contents of the SPD, when renumbering occurs. A new Policy Payload, replacing ID payload in Quick mode, does the trick. There is no need to negotiate a new SA, when changes to SPD can be acceptable to both IKE peers. cheers, suresh --- Theodore Tso wrote: > On Fri, Mar 23, 2001 at 06:27:48PM -0500, Angelos D. Keromytis wrote: > > > > 1) Currently, IPsec SAs are identified by the triplet > > > > (destination address, SPI, security protocol) > > > > for the purposes of locating them in the SAD. Since SCTP packets can > > have any of a set of destination addresses, this identification > > needs to be extended to be > > > > ({set of destination addresses}, SPI, security protocol). > > > > The alternative (setting up a number of SAs, for each of the valid > > destination addresses) does not work because of SA state issues (at > > least the replay counter has to be synchronized across all these > > SAs) and the obvious memory waste. > > My apologies for being pedeantic, but you don't mean that in order to > access the SAD, you have to know the complete set of the destination > addresses, right? Rather, that given any one of a set of the > destination addresses, the SPI, and the security protocol, one can > look up an SA in the SAD. Correct? > > > One other issue to add to your list. I was talking to some SCTP > folks, and the one thing which they thought would likely be > successfully added to SCTP is a mechanism for adding an additional > endpoint address to an existing SCTP connection. If this feature does > get added to SCTP (and I can see how it might be useful; for example, > to add your new IP address if you're about to be renumbered, so you > can have SCTP connections survive renumbering events) then we will > need some way by which we can modify the SPD to take into account the > new endpoint address. I don't think we'll need a particularly > complicated mechanism to handle this. A simple solution would be to > just forcing a new Phase 2 exchange whenever the endpoint address set > changes; after all, I don't think this will likely be a frequent operation. > > - Ted ===== __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text From owner-ipsec@lists.tislabs.com Tue Mar 27 08:22:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA29718; Tue, 27 Mar 2001 08:22:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04536 Tue, 27 Mar 2001 10:12:50 -0500 (EST) Message-ID: <3AC0AEE2.753170E1@F-Secure.com> Date: Tue, 27 Mar 2001 18:16:50 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Scott Fanning , Jari Arkko , sommerfeld@East.Sun.COM, Jun-ichiro itojun Hagino , IP Security List Subject: Re: Protocols that refer AH (was: Death to AH) References: <20010326200052.586B235C42@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message <012701c0b628$79c1b960$fc2645ab@cisco.com>, "Scott Fanning" writes: > >VRRP also talks about AH (), although it is > >not integral to the protocol. > >5.3.6.3 IP Authentication Header. > > > >Seeing that AH does authenticate more then ESP (the outside IP Header), has > >there been any discussion on making a header that combines ESP and AH? I > >know that ESP NULL provides just authentication, but not the same coverage > >as AH. > > To what end? AH's problems come because it tries to cover too much of > the packet; changing ESP to do that would cause the same problems. > Remember that you can often bind the source IP address to the certificate, > and check that match at decryption time. > > --Steve Bellovin, http://www.research.att.com/~smb The problems with AH are probably partly due to the way it has been fixed in standards as to exactly what header fields / options are to be protected. This gives NO flexibility in the actual usage of AH. Someone wants to protect, say, a dest. IP address, someone else doesn't, but wants to protect something else. Just for discussion we might imagine an Alternative-AH specification that has more simple rules, for IPv6: - Anything appearing after AAH header is authenticated, any option before it is not. - The reserved fields part of the AAH header contains one bit per each IPv6 header field. If the bit is one, the field is included in the hash, otherwise not. I'm not claiming this would actually work, because I'm not familiar with the IPv6 rules for ordering options, and AH, in relation to each other. It wouldn't work for IPv4 either. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Tue Mar 27 08:42:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01165; Tue, 27 Mar 2001 08:42:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04717 Tue, 27 Mar 2001 10:54:44 -0500 (EST) Message-Id: <200103270123.f2R1NU701399@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues In-reply-to: Your message of "Fri, 23 Mar 2001 18:27:48 EST." <200103232327.f2NNRm715729@coredump.cis.upenn.edu> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 26 Mar 2001 20:23:24 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Angelos" == Angelos D Keromytis writes: Angelos> The alternative (setting up a number of SAs, for each of the Angelos> valid destination addresses) does not work because of SA state Angelos> issues (at least the replay counter has to be synchronized Angelos> across all these SAs) and the obvious memory waste. Angelos> Recommendation: the architecture document should state that SAs Angelos> are identified by the extended triplet. As an alternative, it would be nice if the architecture said that the mapping of SPD->SA was an N:1 mapping, then no textual change would be necessary to support this. Angelos> 3) The SCTP source/destination port numbers should be included Angelos> as SPD selectors. Angelos> Recommendation: include this in the architecture Angelos> document. No-brainer. But, should the document be rev'ed each time a new protocol comes along that has a new set of selectors? Angelos> 4) The multiple source/destination addresses need to appear in Angelos> the Phase 2 ID payloads in IKE. There are two ways of doing Angelos> this: Angelos> a) Allow multiple source/destination ID payloads in messages 1 Angelos> and 2 of IKE Quick Mode. b) Introduce a new type of ID, that Angelos> allows for recursive inclusion of other IDs. Thus, Phase 2 would Angelos> still only send one ID payload each for source/destination; each I strongly favour (b). This is needed for proper per-host keying support for ICMP. It would also be nice if phase 2 SAs could be referenced in a consistent way such that additional selectors could be *added* to an existing SA. Angelos> Recommendation: do (b), as we think it is less intrusive for Angelos> implementations than (a). However, recursion is limited to only Angelos> one-deep (i.e., you can't have a recursive ID inside a recursive Angelos> ID). My preference is to define three "recursion" types: AND, OR and NOT. Permit at most *three* levels of such logic. Angelos> 5) The initiator of an IKE exchange may not know all the remote Angelos> host's addresses (used for SCTP), and thus may not be able to Angelos> propose an accurate Phase 2 destination ID. Solutions: Angelos> a) The Responder may drop the Phase 2 exchange and start a Phase Angelos> 2 exchange on its own (using the same Phase 1 SA), using Angelos> information from the old exchange, providing the correct set of Angelos> addresses. The advantage of this approach is that it requires no Angelos> protocol changes (although implementations have to be able to Angelos> deal with this initial rejection). b) The Responder could Angelos> modify the Responder ID received in message 1 of Quick Mode, and Angelos> send it back in message 2. The Initiator then needs to verify Angelos> that this is according to policy (as opposed to doing a simple Angelos> bytestring comparison, as is possible today). This requires no Angelos> wire changes, but a small change in the processing at the Angelos> Initiator. This is a potentially more powerful and lightweight Angelos> approach (everything is still done in one exchange, and the Angelos> Initiator does not have to deal with a Phase 2 exchange Angelos> rejection). This begins to sound like negotiation. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Mar 27 08:43:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01290; Tue, 27 Mar 2001 08:43:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04736 Tue, 27 Mar 2001 10:55:46 -0500 (EST) Message-ID: <005901c0b69f$db2ba5e0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP.Net Convention Date: Tue, 27 Mar 2001 11:25:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01C0B6B0.9E58E860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C0B6B0.9E58E860 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What does the IP standard protocol really afford today in terms of = security, quality of service, mobility and billing?=20 What types of virtual networks can be set up? Can a private network use = VoIP technologies to convey voice? Can a mobile network be included in that equation? What tools are = available and are they interoperable?=20 What services do operators propose today? The IP.Net Convention, to be held in Paris, June 19 to 22, will provide = technical and commercial answers to these questions, illustrated by = concrete implementation cases.=20 http://www.upperside.fr/ipnetworks/ipnet.htm ------=_NextPart_000_0056_01C0B6B0.9E58E860 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What does the IP standard protocol really afford = today in=20 terms of security, quality of service, mobility and billing?
What = types of=20 virtual networks can be set up? Can a private network use VoIP = technologies to=20 convey voice?
Can a mobile network be included in that equation? What = tools=20 are available and are they interoperable?
What services do operators = propose=20 today?

The IP.Net Convention, to be held in = Paris, June=20 19 to 22, will provide technical and commercial answers to these = questions,=20 illustrated by concrete implementation cases.
http://www.uppersid= e.fr/ipnetworks/ipnet.htm
------=_NextPart_000_0056_01C0B6B0.9E58E860-- From owner-ipsec@lists.tislabs.com Tue Mar 27 08:48:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01696; Tue, 27 Mar 2001 08:48:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04735 Tue, 27 Mar 2001 10:55:46 -0500 (EST) Message-Id: <200103270828.f2R8SXv16118@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SA identification In-reply-to: Your message of "Tue, 27 Mar 2001 00:41:54 EST." <20010327054155.4F1ED35C42@berkshire.research.att.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 27 Mar 2001 03:28:31 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Steven" == Steven M Bellovin writes: Steven> On receipt you can't look up the SA until after you've matched on Steven> or ... Why can't one lookup , and then look to see if there is 0, 1 or multiple addresses attached. Each entry could have different SA's referenced. If a host allocates all SPI numbers for the same pool (which seems like a wise optomization to me), the only time when the SPI number can be duplicated is in the multicast case, and that would be obvious from looking at the DA that is is class D. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Mar 27 09:58:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA05278; Tue, 27 Mar 2001 09:58:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05303 Tue, 27 Mar 2001 11:49:15 -0500 (EST) Reply-To: From: "sridharj" To: "Ipsec (E-mail)" Subject: certificate request Date: Tue, 27 Mar 2001 22:16:49 +0530 Message-Id: <000001c0b6dd$85514f60$6e0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , Can anyone help me regarding 1) Are there any RFC's which states how to REQUEST CERTIFICATE from CA for IKE implemention . I looked for the following drafts but they are obselete now draft-ietf-ipsec-pki-req-05.txt / draft-ietf-ipsec-pki-req-06.txt Thanks in advance , sridhara. j From owner-ipsec@lists.tislabs.com Wed Mar 28 02:32:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA13202; Wed, 28 Mar 2001 02:32:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08255 Wed, 28 Mar 2001 04:21:57 -0500 (EST) From: Herbert Schmid Reply-To: herbert.schmid@explido.de Organization: explido To: ipsec@lists.tislabs.com Subject: don't get any encrypted packets! - at least I think so! Date: Wed, 28 Mar 2001 09:44:12 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01032809441209.00540@herbert> Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm using the Linux-implementation of ipsec (FreeSwan), but this is a very general problem. I just wanted to check the secure tunnel between two gateways - but I didn't get any encrypted packets and I already have most of the RTFM-stuff behind me. Maybe it's just a little thing I didn't get. Here's the constellation: gw1 gw2 ------------ ------------ client | | | | _______ | | | | | | | |---| | | | | | | | | | |_______| | | | | | | | | 192.168.2.2 ------|------ ------|------ eth0 eth1 eth1 eth0 192.168.1.1 192.168.3.1 192.168.3.2 192.168.2.1 leftsubnet: \ / rightsubnet: 192.168.1.0/24 \ / 192.168.2.0/24 monitoring ______________ |_____________ | 192.168.3.3 Up to here a quite normal installation, I think. When I start ipsec no error occurs. Target is to see whether packets in the tunnel are really encrypted. On the client I start some icmp-packets (ping 192.168.1.1 -p aabbccddeeff). On the monitoring-machine I start tcpdump (tcpdump -i eth0 -v -x icmp). When the tunnel is established, the packets sniffed by monitoring-machine arrive in plain text (aabbccddeeff ...) - this must not be I suppose! Packets exchanged by the 2 gateways must be encrypted! Is it possible that packets between 192.168.2.2 (client) and 192.168.1.1 are bypassed by normal routing-machine since 192.168.3.0/24 appears in the first rang of the routing-table (just another stupid question - I know!) even if the device is eth1 not ipsec0? Kernel IP routing table (gw2) Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 192.168.3.1 255.255.255.0 UG 0 0 0 ipsec0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Could anybody help me please? Maybe there are other ways of being sure that the packets are encrypted - I think sniffing on the gateways (i.e. with ethereal) won't work - if the connection between them is not explicitly configured. But there was quite an interesting think I recognized: sniffing on ipsec0, I didn't see any encryption at all, sniffing on eth1 I saw ESP-packets. Is there an explanation for that? Thanks a lot, Herbert Herbert Schmid explido GmbH & Co. KG Gneisenaustr. 15 86167 Augsburg Tel.: (08 21) 21 77 95 20 Fax: (08 21) 2 17 79 59 www.explido.de www.promotionwelt.de www.beschaffungswelt.de ------------------------------------------------------- -- Herbert Schmid explido GmbH & Co. KG Gneisenaustr. 15 86167 Augsburg Tel.: (08 21) 21 77 95 20 Fax: (08 21) 2 17 79 59 www.explido.de www.promotionwelt.de www.beschaffungswelt.de From owner-ipsec@lists.tislabs.com Wed Mar 28 11:19:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA23649; Wed, 28 Mar 2001 11:19:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09581 Wed, 28 Mar 2001 12:56:37 -0500 (EST) Message-Id: <200103280024.f2S0OSl02125@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Theodore Tso Cc: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues In-reply-to: Your message of "Mon, 26 Mar 2001 21:28:08 EST." <20010326212808.A2145@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Mar 2001 19:24:28 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20010326212808.A2145@think>, Theodore Tso writes: > >My apologies for being pedeantic, but you don't mean that in order to >access the SAD, you have to know the complete set of the destination >addresses, right? Rather, that given any one of a set of the >destination addresses, the SPI, and the security protocol, one can >look up an SA in the SAD. Correct? You are correct. >One other issue to add to your list. I was talking to some SCTP >folks, and the one thing which they thought would likely be >successfully added to SCTP is a mechanism for adding an additional >endpoint address to an existing SCTP connection. If this feature does >get added to SCTP (and I can see how it might be useful; for example, >to add your new IP address if you're about to be renumbered, so you >can have SCTP connections survive renumbering events) then we will >need some way by which we can modify the SPD to take into account the >new endpoint address. I don't think we'll need a particularly >complicated mechanism to handle this. A simple solution would be to >just forcing a new Phase 2 exchange whenever the endpoint address set >changes; after all, I don't think this will likely be a frequent operation. You're right, and the draft already does mention this exact same case, with your assumption as a solution :-) You might have to do a complete Phase 1/Phase 2 exchange, depending on what credentials you've sent over (if you depend on them to do address verification), but that's a detail really. -Angelos From owner-ipsec@lists.tislabs.com Wed Mar 28 12:10:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA26925; Wed, 28 Mar 2001 12:10:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09751 Wed, 28 Mar 2001 14:11:41 -0500 (EST) Message-Id: <200103281832.f2SIW0c06237@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues In-reply-to: Your message of "Mon, 26 Mar 2001 20:23:24 EST." <200103270123.f2R1NU701399@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Mar 2001 13:32:00 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200103270123.f2R1NU701399@marajade.sandelman.ottawa.on.ca>, Michael Richardson writes: > > As an alternative, it would be nice if the architecture said that the >mapping of SPD->SA was an N:1 mapping, then no textual change would be >necessary to support this. I don't think this is sufficient; after all, SPDs can currently do an N:1 mapping. > But, should the document be rev'ed each time a new protocol comes along >that has a new set of selectors? Unclear, and something for the WG to decide; since the architecture document is being rev'ed anyway, I think this should go in. > It would also be nice if phase 2 SAs could be referenced in a consistent >way such that additional selectors could be *added* to an existing SA. I agree, although this has more to do with policy and thus should be brought up at the appropriate WG (and I don't want to complicate this document any more than I have to). > My preference is to define three "recursion" types: AND, OR and NOT. > Permit at most *three* levels of such logic. I don't see how these would be used in practice. I can imagine situations in manual configuration where you'd want to specify complicated combinations of hosts and networks to be protected, but that can be done by a series of Phase 2 exchanges just as easily. In any situation that involves automatic keying (e.g., "telnet -secure foo.com"), I don't see how this would buy you anything, other than increased complexity. > This begins to sound like negotiation. Yup. -Angelos From owner-ipsec@lists.tislabs.com Thu Mar 29 05:48:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA27728; Thu, 29 Mar 2001 05:48:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12015 Thu, 29 Mar 2001 07:34:22 -0500 (EST) Message-Id: <200103282306.f2SN65k02407@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues In-reply-to: Your message of "Wed, 28 Mar 2001 13:32:00 EST." <200103281832.f2SIW0c06237@nyarlathotep.keromytis.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Mar 2001 18:06:05 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Angelos" == Angelos D Keromytis writes: Angelos> but that can be done by a series of Phase 2 exchanges just as Angelos> easily. In any situation that involves automatic keying (e.g., Angelos> "telnet -secure foo.com"), I don't see how this would buy you Angelos> anything, other than increased complexity. "ftp -secure foo.com" ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Mar 29 05:48:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA27729; Thu, 29 Mar 2001 05:48:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11955 Thu, 29 Mar 2001 07:28:21 -0500 (EST) Mime-Version: 1.0 X-Sender: listmast@mail.gw.tislabs.com (Unverified) Message-Id: Date: Wed, 28 Mar 2001 14:13:00 -0500 To: ipsec@lists.tislabs.com From: owner-ipsec@lists.tislabs.com (by way of Listmaster) Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Approved; Dob.ipsec >From majordomo-owner Wed Mar 28 02:46:24 2001 Received: from wolfultra.a.profi.net (ns.hassler.net [194.8.77.20]) by lists.tislabs.com (8.9.1/8.9.1) with SMTP id CAA07963 Wed, 28 Mar 2001 02:46:23 -0500 (EST) Received: (qmail 16876 invoked from network); 28 Mar 2001 07:50:35 -0000 Received: from ethergate4.a.profi.net (HELO mail.explido.de) (root@194.8.77.9) by wolfultra.a.profi.net with SMTP; 28 Mar 2001 07:50:35 -0000 Received: from herbert ([194.8.79.51]) by mail.explido.de (8.9.3/8.9.3/Linux 8.9.3) with SMTP id JAA18456 for ; Wed, 28 Mar 2001 09:33:39 +0200 From: Herbert Schmid Reply-To: herbert.schmid@explido.de Organization: explido To: ipsec@lists.tislabs.com Subject: don't get any encrypted packets! Date: Wed, 28 Mar 2001 08:08:42 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01032808084201.00540@herbert> Content-Transfer-Encoding: 8bit Hi, I just wanted to check the secure tunnel between two gateways - but I didn't get any encrypted packets and I already have most of the RTFM-stuff behind me. Maybe it's just a little thing I didn't get. Here's the constellation: gw1 gw2 ------------ ------------ client | | | | _______ | | | | | | | |---| | | | | | | | | | |_______| | | | | | | | | 192.168.2.2 ------|------ ------|------ eth0 eth1 eth1 eth0 192.168.1.1 192.168.3.1 192.168.3.2 192.168.2.1 leftsubnet: \ / rightsubnet: 192.168.1.0/24 \ / 192.168.2.0/24 monitoring ______________ |_____________ | 192.168.3.3 Up to here a quite normal installation, I think. When I start ipsec no error occurs. Target is to see whether packets in the tunnel are really encrypted. On the client I start some icmp-packets (ping 192.168.1.1 -p aabbccddeeff). On the monitoring-machine I start tcpdump (tcpdump -i eth0 -v -x icmp). When the tunnel is established, the packets sniffed by monitoring-machine arrive in plain text (aabbccddeeff ...) - this must not be I suppose! Packets exchanged by the 2 gateways must be encrypted! Is it possible that packets between 192.168.2.2 (client) and 192.168.1.1 are bypassed by normal routing-machine since 192.168.3.0/24 appears in the first rang of the routing-table (just another stupid question - I know!) even if the device is eth1 not ipsec0? Kernel IP routing table (gw2) Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 192.168.3.1 255.255.255.0 UG 0 0 0 ipsec0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Could anybody help me please? Maybe there are other ways of being sure that the packets are encrypted - I think sniffing on the gateways (i.e. with ethereal) won't work - if the connection between them is not explicitly configured. But there was quite an interesting think I recognized: sniffing on ipsec0, I didn't see any encryption at all, sniffing on eth1 I saw ESP-packets. Is there an explanation for that? Thanks a lot, Herbert Herbert Schmid explido GmbH & Co. KG Gneisenaustr. 15 86167 Augsburg Tel.: (08 21) 21 77 95 20 Fax: (08 21) 2 17 79 59 www.explido.de www.promotionwelt.de www.beschaffungswelt.de From owner-ipsec@lists.tislabs.com Thu Mar 29 10:48:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA20334; Thu, 29 Mar 2001 10:48:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13751 Thu, 29 Mar 2001 12:23:46 -0500 (EST) From: Herbert Schmid Reply-To: herbert.schmid@explido.de Organization: explido To: ipsec@lists.tislabs.com Subject: don't get any encrypted packets! Date: Wed, 28 Mar 2001 08:08:42 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01032808084201.00540@herbert> Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I just wanted to check the secure tunnel between two gateways - but I didn't get any encrypted packets and I already have most of the RTFM-stuff behind me. Maybe it's just a little thing I didn't get. Here's the constellation: gw1 gw2 ------------ ------------ client | | | | _______ | | | | | | | |---| | | | | | | | | | |_______| | | | | | | | | 192.168.2.2 ------|------ ------|------ eth0 eth1 eth1 eth0 192.168.1.1 192.168.3.1 192.168.3.2 192.168.2.1 leftsubnet: \ / rightsubnet: 192.168.1.0/24 \ / 192.168.2.0/24 monitoring ______________ |_____________ | 192.168.3.3 Up to here a quite normal installation, I think. When I start ipsec no error occurs. Target is to see whether packets in the tunnel are really encrypted. On the client I start some icmp-packets (ping 192.168.1.1 -p aabbccddeeff). On the monitoring-machine I start tcpdump (tcpdump -i eth0 -v -x icmp). When the tunnel is established, the packets sniffed by monitoring-machine arrive in plain text (aabbccddeeff ...) - this must not be I suppose! Packets exchanged by the 2 gateways must be encrypted! Is it possible that packets between 192.168.2.2 (client) and 192.168.1.1 are bypassed by normal routing-machine since 192.168.3.0/24 appears in the first rang of the routing-table (just another stupid question - I know!) even if the device is eth1 not ipsec0? Kernel IP routing table (gw2) Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 192.168.3.1 255.255.255.0 UG 0 0 0 ipsec0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Could anybody help me please? Maybe there are other ways of being sure that the packets are encrypted - I think sniffing on the gateways (i.e. with ethereal) won't work - if the connection between them is not explicitly configured. But there was quite an interesting think I recognized: sniffing on ipsec0, I didn't see any encryption at all, sniffing on eth1 I saw ESP-packets. Is there an explanation for that? Thanks a lot, Herbert Herbert Schmid explido GmbH & Co. KG Gneisenaustr. 15 86167 Augsburg Tel.: (08 21) 21 77 95 20 Fax: (08 21) 2 17 79 59 www.explido.de www.promotionwelt.de www.beschaffungswelt.de -- John C. Kelley Computer Scientist NAILabs at Network Associates, Inc. Glenwood, MD From owner-ipsec@lists.tislabs.com Thu Mar 29 12:10:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24242; Thu, 29 Mar 2001 12:10:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14038 Thu, 29 Mar 2001 13:54:52 -0500 (EST) Date: Thu, 29 Mar 2001 13:57:44 -0500 (EST) From: Henry Spencer To: Herbert Schmid cc: ipsec@lists.tislabs.com Subject: Re: don't get any encrypted packets! In-Reply-To: <01032808084201.00540@herbert> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 28 Mar 2001, Herbert Schmid wrote: > I just wanted to check the secure tunnel between two gateways... The ipsec@lists.tislabs.com mailing list is for design work on the IPsec protocols, not for user help with a particular implementation. From context, you're presumably using FreeS/WAN; please use the FreeS/WAN mailing list for questions about it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Mar 30 01:16:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA18425; Fri, 30 Mar 2001 01:16:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15773 Fri, 30 Mar 2001 03:01:32 -0500 (EST) X-Originating-IP: [195.193.202.74] From: "Paul Aprendiz" To: ipsec@lists.tislabs.com Subject: FreeS/WAN RedHat compilation Problems Date: Fri, 30 Mar 2001 08:05:09 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Mar 2001 08:05:09.0456 (UTC) FILETIME=[238E3D00:01C0B8F0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, my IPSec is not working! I installed FreeS/WAN 1.8 in my RedHAt 7.0 I did /usr/src/linux/make menuconfig then make dep make bzImage make install make modules make modules_install lilo everything ok so far Then I went to freeswan directory /usr/src/freeswan-1.8 I made make oldgo At the end of the compilation I got the following error messages [ksyms.o] Error 1 [first_rule] Error 2 [_dir_kernel} Error 2 [loop.o] Error 2 [kernel] Error 1 When I reboot my gateway I also got messages (and IPSec doesn't work at all) in /var/log/messages the following error messages ipsec_setup: Starting FreeS/WAN IPSEC 1.8 ipsec_setup: modprobe: Can't locate module ipsec ipsec_setup: Fatal error, kernel appears to lack KLIPS ipsec_setup: Pluto debug 'none' ipsec_setup: whack: connect () for /var/run/pluto.ctl failed (111 Connection refused) Please help, what is going on regards paul _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-ipsec@lists.tislabs.com Fri Mar 30 02:40:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA29356; Fri, 30 Mar 2001 02:40:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16056 Fri, 30 Mar 2001 04:53:07 -0500 (EST) X-Originating-IP: [195.193.202.74] From: "Paul Aprendiz" To: ipsec@lists.tislabs.com Subject: Re: FreeS/WAN RedHat compilation Problems Date: Fri, 30 Mar 2001 09:56:49 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Mar 2001 09:56:49.0791 (UTC) FILETIME=[BD4438F0:01C0B8FF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK Nathalie!!!!, it was a mistake but don't be mad =( paul >From: Nathalie Weiler >Reply-To: >To: Paul Aprendiz >Subject: Re: FreeS/WAN RedHat compilation Problems >Date: Fri, 30 Mar 2001 11:43:02 +0200 (CEST) > > >Please address our configuration problems to the appropriate mailing >list!!!! > >Nathalie Weiler > >On Fri, 30 Mar 2001, Paul Aprendiz wrote: > > > > > > > Hello, my IPSec is not working! > > > > I installed FreeS/WAN 1.8 in my RedHAt 7.0 > > > > I did > > /usr/src/linux/make menuconfig > > then > > make dep > > make bzImage > > make install > > make modules > > make modules_install > > lilo > > > > everything ok so far > > > > Then I went to freeswan directory > > /usr/src/freeswan-1.8 > > I made > > make oldgo > > > > > > At the end of the compilation I got the following error messages > > [ksyms.o] Error 1 > > [first_rule] Error 2 > > [_dir_kernel} Error 2 > > [loop.o] Error 2 > > [kernel] Error 1 > > > > When I reboot my gateway I also got messages (and IPSec doesn't work > > at all) > > in /var/log/messages the following error messages > > > > ipsec_setup: Starting FreeS/WAN IPSEC 1.8 > > ipsec_setup: modprobe: Can't locate module ipsec > > ipsec_setup: Fatal error, kernel appears to lack KLIPS > > ipsec_setup: Pluto debug 'none' > > ipsec_setup: whack: connect () for /var/run/pluto.ctl failed (111 > > Connection refused) > > > > > > Please help, what is going on > > > > regards > > > > paul > > > > > > >_________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at >http://www.hotmail.com. > > > >--- >PGP-KeyID: 52D1CAB1 >PGP encrypted mail welcome > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-ipsec@lists.tislabs.com Fri Mar 30 05:17:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA13986; Fri, 30 Mar 2001 05:17:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16493 Fri, 30 Mar 2001 07:19:23 -0500 (EST) MIME-Version: 1.0 Message-Id: <3AC3DFF9.20543@bjapp4> Date: Fri, 30 Mar 2001 09:23:05 +0800 (CST) From: "zhangdongyan" To: ipsec@lists.tislabs.com Subject: help X-Priority: 3 X-Originating-IP: [202.106.170.138] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear sir: We are students of Harbin Institute of Technology of China.Now we are learning IPSec Protocol. We are have questions about IKE: 1.IKE Phase 1 Authenticated With Digital Signature: According to the RFC “The Internet IP Security Domain of Interpretation for “ISAKMP”, When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange, what we would like to know is Identification Data which is in Identification Payload is equal to which part of certificates? 2.IKE Phase 1 Authenticated With Public Key Encryption: Is Identification data to know by each other in advance? Is Identification data used to find the other’s public key and how to find the public key? 3.IKE Phase 2 Why initiator has two ID Payloads which are IDci and IDcr and How the initiator know the IDcr data? Is it necessary to have two ID Payloads by responder and send to the initiator? Could you tell me the answer in detail? We are sorry for taking trouble for you. We want to understand the IKE quickly so we are looking forward to hearing from you as soon as possible. Thank you for your attention. Best Regards, Zhang Dongyan Email:myredapple-@163.net Hou Rui Email:hithourui@yahoo.com.cn =============================================== 为你而建，为你而设，让你传递真心真意 ---- 163.net贺卡站（http://ecard.163.net） 163电子邮局全新奉献，精彩无限的电子贺卡站。 =============================================== From owner-ipsec@lists.tislabs.com Fri Mar 30 05:18:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14079; Fri, 30 Mar 2001 05:18:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16523 Fri, 30 Mar 2001 07:22:23 -0500 (EST) Message-Id: <200103300229.f2U2TDf00394@marajade.sandelman.ottawa.on.ca> To: "'IP Security List'" Subject: Re: Protocols that refer AH (was: Death to AH) In-reply-to: Your message of "Mon, 26 Mar 2001 16:52:51 EST." <000001c0b63f$1b9d1c50$1e72788a@andrewk3.ca.newbridge.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 Mar 2001 21:29:13 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> Michael asked "why do VPN vendors implement AH?" The answer is because it is Andrew> perceived to be necessary. Various literature on deploying VPNs talks about Andrew> it. If we don't have AH then our solution may fail the "checkbox test." So, why are we deprecating a protocol that may very well have future uses to make passing the checkbox test easier? The simplest action is to remove that checkbox. (Paul Hoffman? Bob? Jon McCown? You listening...) Perhaps someone wants to write a "VPN BCP" and be done with it. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Mar 30 05:18:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14099; Fri, 30 Mar 2001 05:18:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16487 Fri, 30 Mar 2001 07:18:23 -0500 (EST) Message-Id: <200103300057.f2U0vnV01573@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues In-reply-to: Your message of "Wed, 28 Mar 2001 13:32:00 EST." <200103281832.f2SIW0c06237@nyarlathotep.keromytis.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 Mar 2001 19:57:48 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Angelos" == Angelos D Keromytis writes: >> As an alternative, it would be nice if the architecture said that the >> mapping of SPD->SA was an N:1 mapping, then no textual change would be >> necessary to support this. Angelos> I don't think this is sufficient; after all, SPDs can currently Angelos> do an Angelos> N:1 mapping. Why not? >> It would also be nice if phase 2 SAs could be referenced in a consistent >> way such that additional selectors could be *added* to an existing SA. Angelos> I agree, although this has more to do with policy and thus Angelos> should be brought up at the appropriate WG (and I don't want to Angelos> complicate this document any more than I have to). It seems like a strong requirement for SCTP as they want to be able to add new interfaces, and I get the impression that they don't want to rekey during this time. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Mar 30 05:21:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA14419; Fri, 30 Mar 2001 05:21:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16511 Fri, 30 Mar 2001 07:21:23 -0500 (EST) Message-Id: <200103300225.f2U2PVm19707@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues In-reply-to: Your message of "Wed, 28 Mar 2001 18:06:05 EST." <200103282306.f2SN65k02407@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Mar 2001 21:25:31 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200103282306.f2SN65k02407@marajade.sandelman.ottawa.on.ca>, Michael Richardson writes: > > >>>>> "Angelos" == Angelos D Keromytis writes: > Angelos> but that can be done by a series of Phase 2 exchanges just as > Angelos> easily. In any situation that involves automatic keying (e.g., > Angelos> "telnet -secure foo.com"), I don't see how this would buy you > Angelos> anything, other than increased complexity. > > "ftp -secure foo.com" That won't do you any good, since in neither passive or active FTP do you know the server side's port until after you've started an exchange. -Angelos From owner-ipsec@lists.tislabs.com Fri Mar 30 09:36:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03899; Fri, 30 Mar 2001 09:36:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17260 Fri, 30 Mar 2001 11:13:44 -0500 (EST) Message-Id: <200103301614.LAA23048@ietf.org> To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 30 Mar 2001 11:14:14 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider DHCPv4 Configuration of IPSEC Tunnel Mode as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 13, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-09.txt From owner-ipsec@lists.tislabs.com Fri Mar 30 11:36:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA08301; Fri, 30 Mar 2001 11:36:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17769 Fri, 30 Mar 2001 13:31:39 -0500 (EST) Message-ID: <0f0201c0b948$55c54770$b81c550a@cisco.com> From: "Stephane Beaulieu" To: Cc: "Paul Hoffman" References: <200103301614.LAA23048@ietf.org> Subject: Re: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Date: Fri, 30 Mar 2001 13:36:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I didn't attend the last IETF. Was there a decision made to move this draft from the IPSRA WG to the IPSec WG? If so, why? Stephane. ----- Original Message ----- From: "The IESG" To: Cc: Sent: Friday, March 30, 2001 11:14 AM Subject: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard > > The IESG has received a request from the IP Security Protocol Working > Group to consider DHCPv4 Configuration of IPSEC Tunnel Mode > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by April 13, 2001. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-09.txt > > > From owner-ipsec@lists.tislabs.com Fri Mar 30 11:42:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA08638; Fri, 30 Mar 2001 11:42:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17852 Fri, 30 Mar 2001 13:48:37 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <0f0201c0b948$55c54770$b81c550a@cisco.com> References: <200103301614.LAA23048@ietf.org> <0f0201c0b948$55c54770$b81c550a@cisco.com> Date: Fri, 30 Mar 2001 10:51:51 -0800 To: "Stephane Beaulieu" , From: Paul Hoffman / VPNC Subject: Re: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:36 PM -0500 3/30/01, Stephane Beaulieu wrote: >Was there a decision made to move this draft from the IPSRA WG to the IPSec >WG? If so, why? The "location" of a draft is irrelevant. particularly when it is in IETF-wide last call. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Mar 30 23:12:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA11509; Fri, 30 Mar 2001 23:12:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA19416 Sat, 31 Mar 2001 01:07:14 -0500 (EST) Date: Sat, 31 Mar 2001 01:11:23 -0500 From: Theodore Tso To: Stephane Beaulieu Cc: ipsec@lists.tislabs.com, Paul Hoffman Subject: Re: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Message-ID: <20010331011123.A635@think> References: <200103301614.LAA23048@ietf.org> <0f0201c0b948$55c54770$b81c550a@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <0f0201c0b948$55c54770$b81c550a@cisco.com>; from stephane@cisco.com on Fri, Mar 30, 2001 at 01:36:29PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 30, 2001 at 01:36:29PM -0500, Stephane Beaulieu wrote: > I didn't attend the last IETF. > > Was there a decision made to move this draft from the IPSRA WG to the IPSec > WG? If so, why? More to the point, as far as I know, the IPSEC wg didn't request that this be considered as a proposed standard. Did the IPSRA WG so make this request? - Ted From owner-ipsec@lists.tislabs.com Sat Mar 31 10:02:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA10119; Sat, 31 Mar 2001 10:02:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20192 Sat, 31 Mar 2001 11:50:50 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20010331011123.A635@think> References: <200103301614.LAA23048@ietf.org> <0f0201c0b948$55c54770$b81c550a@cisco.com> <20010331011123.A635@think> Date: Sat, 31 Mar 2001 08:54:06 -0800 To: Theodore Tso , Stephane Beaulieu From: Paul Hoffman / VPNC Subject: Re: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:11 AM -0500 3/31/01, Theodore Tso wrote: >More to the point, as far as I know, the IPSEC wg didn't request that >this be considered as a proposed standard. Did the IPSRA WG so make >this request? Yes, we did. The draft was heavily discussed on the IPSRA WG mailing list, and we had a WG last call on it. For those of you (including the IPsec WG chairs...) who may not be subscribed to the IPSRA WG mailing list, please see for more information and a full archive. --Paul Hoffman, Director --VPN Consortium