From owner-ipsec@lists.tislabs.com Tue May 1 05:46: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 FAA29843; Tue, 1 May 2001 05:46:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02323 Tue, 1 May 2001 07:33:53 -0400 (EDT) Message-ID: <59063B5B4D98D311BC0D0001FA7E452205D99E9A@l04.research.kpn.com> From: "Tilborg, E.B.M. van" To: "'ipsec@lists.tislabs.com'" Subject: Difference IPSec IPv4-IPv6 Date: Tue, 1 May 2001 11:34:46 +0100 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 Hello, I have a very basic question: What are the differences between IPSec when using it with IPv4 and when using it with IPv6? The only difference I ever heart of is that for IPv4, IPSec is an add-on and for IPv6 it is not. I am looking for both technical differences and (dis)advantages of using IPSec with IPv4 or IPv6. It would be very nice if somebody could help me get some documentation on this. Thanks in advance! Regards, Edith van Tilborg D Edith van Tilborg KPN Research BIT UTMS Competence Center Postbus 421 2260 AK Leidschendam Mob: +31 6 53724931 From owner-ipsec@lists.tislabs.com Wed May 2 01:51: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 BAA28264; Wed, 2 May 2001 01:50:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA04456 Wed, 2 May 2001 03:31:08 -0400 (EDT) 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: finland bakeoff From: itojun@iijlab.net Date: Wed, 02 May 2001 16:35:54 +0900 Message-ID: <10877.988788954@itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sorry for a dumb question, were there any annoucnement/URL for finland bakeoff made? itojun From owner-ipsec@lists.tislabs.com Wed May 2 06:30: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 GAA21545; Wed, 2 May 2001 06:30:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05060 Wed, 2 May 2001 07:53:04 -0400 (EDT) Message-ID: <013d01c0d2e3$a7c52c20$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPSec Global Summit Date: Wed, 2 May 2001 10:41:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01C0D2F4.6AFA0FC0" 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_013A_01C0D2F4.6AFA0FC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IPSec Global Summit If you had some problems with the last URL, here it is again: The third edition of the IPsec Global Summit will be organised next = 23-26 October in Paris. A call for proposals is online at: http://www.upperside.fr/ipsec2001/ipsec01cfp.htm ------=_NextPart_000_013A_01C0D2F4.6AFA0FC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IPSec Global Summit If you had some problems with the last = URL, here it=20 is again: The third edition of the IPsec Global Summit will be = organised=20 next 23-26 October in Paris. A call for proposals is online at: <3d.htm>http://www.uppe= rside.fr/ipsec2001/ipsec01cfp.<3d.htm>htm ------=_NextPart_000_013A_01C0D2F4.6AFA0FC0-- From owner-ipsec@lists.tislabs.com Wed May 2 07:06: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 HAA24603; Wed, 2 May 2001 07:06:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05236 Wed, 2 May 2001 08:30:56 -0400 (EDT) From: khawley@silenus.com To: "Peter Lewis" Cc: Subject: Re: IPSec Global Summit X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 2 May 2001 08:17:54 -0400 X-MIMETrack: Serialize by Router on sgmain/Silenus(Release 5.0.6a |January 17, 2001) at 05/02/2001 08:18:54 AM, Serialize complete at 05/02/2001 08:18:54 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0045B97385256A40_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 0045B97385256A40_= Content-Type: text/plain; charset="us-ascii" Try it this way: http://www.upperside.fr/ipsec2001/ipsec01cfp.htm - - - - - - - - - - - - - - - - - - - - - - - - - - IPSec Global Summit If you had some problems with the last = URL, here it is again: The third edition of the IPsec Global Summit will be = organised next 23-26 October in Paris. A call for proposals is online at: http://www.uppe= rside.fr/ipsec2001/ipsec01cfp.htm --=_alternative 0045B97385256A40_= Content-Type: text/html; charset="us-ascii"
Try it this way:

http://www.upperside.fr/ipsec2001/ipsec01cfp.htm

- - - - - - - - - - - - - - - - - - - - - - - - - -



IPSec Global Summit If you had some problems with the last = URL, here it is again: The third edition of the IPsec Global Summit will be = organised next 23-26 October in Paris. A call for proposals is online at: http://www.uppe= rside.fr/ipsec2001/ipsec01cfp.htm

--=_alternative 0045B97385256A40_=-- From owner-ipsec@lists.tislabs.com Wed May 2 16:04: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 QAA03909; Wed, 2 May 2001 16:04:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06946 Wed, 2 May 2001 17:45:23 -0400 (EDT) Message-ID: <005001c0d351$84337370$872745ab@cisco.com> From: "Scott Fanning" To: , References: <10877.988788954@itojun.org> Subject: Re: finland bakeoff Date: Wed, 2 May 2001 14:47:42 -0700 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 would be interested in this as well. I also would be interested in knowing how many vendors will be going, and what will be tested. Will it be along the lines of the CALBUG bakeoffs? A quick answer to this would be appreciated as travel arrangements are cheaper the sooner you do them. Regards Scott ----- Original Message ----- From: To: Sent: Wednesday, May 02, 2001 12:35 AM Subject: finland bakeoff > sorry for a dumb question, were there any annoucnement/URL for > finland bakeoff made? > > itojun From owner-ipsec@lists.tislabs.com Wed May 2 16:32: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 QAA05463; Wed, 2 May 2001 16:32:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07112 Wed, 2 May 2001 18:38:33 -0400 (EDT) Message-ID: <004501c0d357$7f527620$fd30b0a3@netopia.com> From: "Rob Tashjian" To: References: <10877.988788954@itojun.org> <005001c0d351$84337370$872745ab@cisco.com> Subject: Re: finland bakeoff Date: Wed, 2 May 2001 15:30:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'll would be interested in this as well. Netopia would like to attend. rwt --- Robert Tashjian rwt@netopia.com ----- Original Message ----- From: "Scott Fanning" To: ; Sent: Wednesday, May 02, 2001 2:47 PM Subject: Re: finland bakeoff > I would be interested in this as well. I also would be interested in knowing > how many vendors will be going, and what will be tested. Will it be along > the lines of the CALBUG bakeoffs? A quick answer to this would be > appreciated as travel arrangements are cheaper the sooner you do them. > > Regards > Scott > ----- Original Message ----- > From: > To: > Sent: Wednesday, May 02, 2001 12:35 AM > Subject: finland bakeoff > > > > sorry for a dumb question, were there any annoucnement/URL for > > finland bakeoff made? > > > > itojun > > From owner-ipsec@lists.tislabs.com Thu May 3 04:09: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 EAA21223; Thu, 3 May 2001 04:09:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08360 Thu, 3 May 2001 05:09:28 -0400 (EDT) From: Herbert Schmid Reply-To: herbert.schmid@explido.de Organization: explido To: ipsec@lists.tislabs.com Subject: ipsec and client Date: Thu, 3 May 2001 11:34:04 +0000 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01050311340401.00961@herbert> Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm searching a good client for my road warriors out there. The two clients I found were PGPnet and sentinel - but they only support x.509-certificates as I see. Is there a possibility to bypass this way? Do you have experience with other clients? Sorry for writing to this mailinglist, but the information on ssh's site and the manual aren't sufficient. Regards, Herbert Schmid -- 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 From owner-ipsec@lists.tislabs.com Thu May 3 07:06: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 HAA06043; Thu, 3 May 2001 07:06:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08953 Thu, 3 May 2001 09:04:15 -0400 (EDT) From: tomd@sacefcu.org Message-ID: <0150CA5A623FD211B16400105A0463265DBABB@cecupdc.sacefcu.org> To: ipsec@lists.tislabs.com Subject: RE: ipsec and client Date: Thu, 3 May 2001 08:13:22 -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 Herbert, Not true, PGP will also support shared secret and a couple of other methods. What exactly are you trying to connect to and what do you want to use as authentication? Tom -----Original Message----- From: Herbert Schmid [mailto:herbert.schmid@explido.de] Sent: Thursday, May 03, 2001 6:34 AM To: ipsec@lists.tislabs.com Subject: ipsec and client Hi, I'm searching a good client for my road warriors out there. The two clients I found were PGPnet and sentinel - but they only support x.509-certificates as I see. Is there a possibility to bypass this way? Do you have experience with other clients? Sorry for writing to this mailinglist, but the information on ssh's site and the manual aren't sufficient. Regards, Herbert Schmid -- 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 From owner-ipsec@lists.tislabs.com Thu May 3 09: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 JAA19153; Thu, 3 May 2001 09:22:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09294 Thu, 3 May 2001 11:15:18 -0400 (EDT) Message-ID: From: "DePriest, Jason R." To: "'tomd@sacefcu.org'" , ipsec@lists.tislabs.com Subject: RE: ipsec and client Date: Thu, 3 May 2001 10:17:25 -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 Actually, I have been wondering how to configure PGPNet to work with a shared secret to connect to an Axent/Symantec PowerVPN server. It just seems to time out. If you can direct me to any online resources, I would appreciate it! -----Original Message----- From: tomd@sacefcu.org [mailto:tomd@sacefcu.org] Sent: Thursday, May 03, 2001 7:13 AM To: ipsec@lists.tislabs.com Subject: RE: ipsec and client Herbert, Not true, PGP will also support shared secret and a couple of other methods. What exactly are you trying to connect to and what do you want to use as authentication? Tom -----Original Message----- From: Herbert Schmid [mailto:herbert.schmid@explido.de] Sent: Thursday, May 03, 2001 6:34 AM To: ipsec@lists.tislabs.com Subject: ipsec and client Hi, I'm searching a good client for my road warriors out there. The two clients I found were PGPnet and sentinel - but they only support x.509-certificates as I see. Is there a possibility to bypass this way? Do you have experience with other clients? Sorry for writing to this mailinglist, but the information on ssh's site and the manual aren't sufficient. Regards, Herbert Schmid -- 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 From owner-ipsec@lists.tislabs.com Thu May 3 09:22: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 JAA19165; Thu, 3 May 2001 09:22:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09305 Thu, 3 May 2001 11:17:33 -0400 (EDT) From: tomd@sacefcu.org Message-ID: <0150CA5A623FD211B16400105A0463265DBAC6@cecupdc.sacefcu.org> To: jrdepriest@ftb.com, ipsec@lists.tislabs.com Subject: RE: ipsec and client Date: Thu, 3 May 2001 10:26:45 -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 http://kubarb.phsx.ukans.edu/~tbird/vpn.html -----Original Message----- From: DePriest, Jason R. [mailto:jrdepriest@ftb.com] Sent: Thursday, May 03, 2001 10:17 AM To: Tom DeSot; ipsec@lists.tislabs.com Subject: RE: ipsec and client Actually, I have been wondering how to configure PGPNet to work with a shared secret to connect to an Axent/Symantec PowerVPN server. It just seems to time out. If you can direct me to any online resources, I would appreciate it! -----Original Message----- From: tomd@sacefcu.org [mailto:tomd@sacefcu.org] Sent: Thursday, May 03, 2001 7:13 AM To: ipsec@lists.tislabs.com Subject: RE: ipsec and client Herbert, Not true, PGP will also support shared secret and a couple of other methods. What exactly are you trying to connect to and what do you want to use as authentication? Tom -----Original Message----- From: Herbert Schmid [mailto:herbert.schmid@explido.de] Sent: Thursday, May 03, 2001 6:34 AM To: ipsec@lists.tislabs.com Subject: ipsec and client Hi, I'm searching a good client for my road warriors out there. The two clients I found were PGPnet and sentinel - but they only support x.509-certificates as I see. Is there a possibility to bypass this way? Do you have experience with other clients? Sorry for writing to this mailinglist, but the information on ssh's site and the manual aren't sufficient. Regards, Herbert Schmid -- 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 From owner-ipsec@lists.tislabs.com Thu May 3 10:48:40 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 KAA25910; Thu, 3 May 2001 10:48:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09492 Thu, 3 May 2001 12:45:47 -0400 (EDT) From: "John S. Cox" To: Subject: IPSec, dynamic IPv4 addresses and FreeBSD? Date: Thu, 3 May 2001 17:50:44 +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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, This may be a simple queston but I have spent some time failing to find the answer - The short form of the question is can I tunnel from a machine with a dynamic IP address to a FreeBSD machine using IPSec? Longer form with diagram (ASCII art I'm afraid): Home m/c 1 Home m/c 2 | | |------------------| | 10.2.0.0/16 | OpenBSD firewall+NAT m/c | | ?.?.?.?/32 (not under my control and | will change from time to time) | Cable modem with DHCP | | "The internet" | | ADSL modem | | (some fixed addresses 1.2.3.0/29) | Firewall | | 10.1.0.0/16 |------------------------------------------------ | | | FreeBSD tunnel m/c Work m/c 1 ......... I want to create a secure tunnel between my home network and my work network whilst allowing the home m/cs to access the general internet via NAT (hardly a novel idea I'm sure). The obvious method seemed to be to set up IPSec with X509 certificates as proof of Id. I thought I could work out how to do that using racoon (and indeed iskmpd in OpenBSD) but the FreeBSD policy database (SPD) seems to only accept endpoints that have a fixed IP address. Is there any way round this using FreeBSD? I am aware that NAT & IPSec don't get on together but given I was intending to the the IPSec tunnel on the firewall/NAT machine it doesn't have to go via NAT. Pointers of the form "look at this FAQ you idiot" welcome. Thank you John Cox From owner-ipsec@lists.tislabs.com Thu May 3 12: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 MAA01925; Thu, 3 May 2001 12:52:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09779 Thu, 3 May 2001 14:51:27 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.43447.409138.295986@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 11:55:51 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: application layer cross checking 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 I've had a nagging question for a long time which I'm hoping that somebody can shed some light on. Suppose I have a linux box running Freeswan talking to a Solaris 8 box. Suppose also that we have a way to mutually authenticate each other at the IPsec level (pre-shared, certs, whatever). Suppose also that this is just a transport mode SA. Is there any API which prevents the following kind of attack? Mike's-box Server ------------------------------ -----------------------------> IKE: DN=mike@mtcc.com <----------------------------- IKE: DN=server@server.com -----------------------------> SIP: INVITE From: gwb@whitehouse.gov [...] <----------------------------- 200 OK, George Ie, that I can authenticate myself for IPsec, but forge my credentials at L7. I would expect that there should be an API to get the credentials presented for IPsec back up to the app. My understanding is that Microsoft doesn't provide any kernel API at all, and I didn't immediately see anything in PFKEY, though I didn't look hard so feel free to flame me. If there's not such an API, what was the reason? This would seem like a pretty heavy burden to recreate all of the identity machinery at the app level to cover this attack. Mike From owner-ipsec@lists.tislabs.com Thu May 3 13:23: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 NAA04172; Thu, 3 May 2001 13:23:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09867 Thu, 3 May 2001 15:40:45 -0400 (EDT) Message-ID: <8B204D152222D51182B7000102884137202416@postmaster.cryptek.com> From: David Aronson To: ipsec@lists.tislabs.com Cc: "'John S. Cox'" Subject: RE: IPSec, dynamic IPv4 addresses and FreeBSD? Date: Thu, 3 May 2001 16:04:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk John S. Cox [mailto:jc@sj.co.uk] wonders: > The short form of the question is can I tunnel from a machine with > a dynamic IP address to a FreeBSD machine using IPSec? Unless there's something about FreeBSD preventing it, you should certainly be able to do this. In fact, I'm using IPSec (tunneling and encapsulation) between two PCs with DHCP right now. I'm testing our (Cryptek's) next release of the network management/monitoring software, which requires a test rig with two PCs, each protected with DiamondLINK boxes. One of the PCs is the very one I'm typing this on. B-) Then again, I'm pretty new to IPSec (and for that matter, computer security in general), so for all I know, it may be some special feature of our software. -- Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714. Opinions all MINE, not by Cryptek/NRA/SCA/Mensa/HWG/LPUSA/CAUCE/FedGov/God! See my web site, at http://listen.to/davearonson (last updated 2001-03-26). Device-driver proggers: see http://www.cryptek.com and send me your resume! From owner-ipsec@lists.tislabs.com Thu May 3 13:25: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 NAA04279; Thu, 3 May 2001 13:25:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09830 Thu, 3 May 2001 15:32:43 -0400 (EDT) To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: application layer cross checking References: <15089.43447.409138.295986@thomasm-u1.cisco.com> From: Derek Atkins Date: 03 May 2001 15:37:36 -0400 In-Reply-To: Michael Thomas's message of "Thu, 3 May 2001 11:55:51 -0700 (PDT)" Message-ID: Lines: 58 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is (currently) no API available to do what you want. One reason is that IPSec authentication need not be user-based authentication, so how would you pass that up to an application and what good would it do? -derek Michael Thomas writes: > I've had a nagging question for a long time which > I'm hoping that somebody can shed some light on. > > Suppose I have a linux box running Freeswan > talking to a Solaris 8 box. Suppose also that we > have a way to mutually authenticate each other at > the IPsec level (pre-shared, certs, whatever). > Suppose also that this is just a transport mode > SA. Is there any API which prevents the following > kind of attack? > > Mike's-box Server > ------------------------------ > -----------------------------> > IKE: DN=mike@mtcc.com > > <----------------------------- > IKE: DN=server@server.com > > -----------------------------> > SIP: INVITE > From: gwb@whitehouse.gov > [...] > > <----------------------------- > 200 OK, George > > > Ie, that I can authenticate myself for IPsec, but > forge my credentials at L7. I would expect that > there should be an API to get the credentials > presented for IPsec back up to the app. My > understanding is that Microsoft doesn't provide > any kernel API at all, and I didn't immediately > see anything in PFKEY, though I didn't look hard > so feel free to flame me. > > If there's not such an API, what was the reason? > This would seem like a pretty heavy burden to > recreate all of the identity machinery at the app > level to cover this attack. > > Mike -- 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 Thu May 3 13:26: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 NAA04409; Thu, 3 May 2001 13:26:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09844 Thu, 3 May 2001 15:38:34 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.46235.12938.686570@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 12:42:19 -0700 (PDT) To: Derek Atkins Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: application layer cross checking In-Reply-To: References: <15089.43447.409138.295986@thomasm-u1.cisco.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 Derek Atkins writes: > There is (currently) no API available to do what you want. > One reason is that IPSec authentication need not be user-based > authentication, so how would you pass that up to an application > and what good would it do? Well, for one thing it could prevent this attack. Isn't that enough? I'm aware that there may be situations where the two may differ, but there are probably an equal number where identities are the same, so why should each application have to roll its own identity module in that case? Mike > > -derek > > Michael Thomas writes: > > > I've had a nagging question for a long time which > > I'm hoping that somebody can shed some light on. > > > > Suppose I have a linux box running Freeswan > > talking to a Solaris 8 box. Suppose also that we > > have a way to mutually authenticate each other at > > the IPsec level (pre-shared, certs, whatever). > > Suppose also that this is just a transport mode > > SA. Is there any API which prevents the following > > kind of attack? > > > > Mike's-box Server > > ------------------------------ > > -----------------------------> > > IKE: DN=mike@mtcc.com > > > > <----------------------------- > > IKE: DN=server@server.com > > > > -----------------------------> > > SIP: INVITE > > From: gwb@whitehouse.gov > > [...] > > > > <----------------------------- > > 200 OK, George > > > > > > Ie, that I can authenticate myself for IPsec, but > > forge my credentials at L7. I would expect that > > there should be an API to get the credentials > > presented for IPsec back up to the app. My > > understanding is that Microsoft doesn't provide > > any kernel API at all, and I didn't immediately > > see anything in PFKEY, though I didn't look hard > > so feel free to flame me. > > > > If there's not such an API, what was the reason? > > This would seem like a pretty heavy burden to > > recreate all of the identity machinery at the app > > level to cover this attack. > > > > Mike > > -- > 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 Thu May 3 13:30: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 NAA04932; Thu, 3 May 2001 13:30:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09861 Thu, 3 May 2001 15:40:37 -0400 (EDT) To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: application layer cross checking References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.com> From: Derek Atkins Date: 03 May 2001 15:45:32 -0400 In-Reply-To: Michael Thomas's message of "Thu, 3 May 2001 12:42:19 -0700 (PDT)" Message-ID: Lines: 82 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Because applications may not be ipsec peers... Or, in most cases, ipsec will be host-based, not user-based? -derek Michael Thomas writes: > Derek Atkins writes: > > There is (currently) no API available to do what you want. > > One reason is that IPSec authentication need not be user-based > > authentication, so how would you pass that up to an application > > and what good would it do? > > Well, for one thing it could prevent this attack. Isn't > that enough? I'm aware that there may be situations > where the two may differ, but there are probably > an equal number where identities are the same, so > why should each application have to roll its own > identity module in that case? > > Mike > > > > > -derek > > > > Michael Thomas writes: > > > > > I've had a nagging question for a long time which > > > I'm hoping that somebody can shed some light on. > > > > > > Suppose I have a linux box running Freeswan > > > talking to a Solaris 8 box. Suppose also that we > > > have a way to mutually authenticate each other at > > > the IPsec level (pre-shared, certs, whatever). > > > Suppose also that this is just a transport mode > > > SA. Is there any API which prevents the following > > > kind of attack? > > > > > > Mike's-box Server > > > ------------------------------ > > > -----------------------------> > > > IKE: DN=mike@mtcc.com > > > > > > <----------------------------- > > > IKE: DN=server@server.com > > > > > > -----------------------------> > > > SIP: INVITE > > > From: gwb@whitehouse.gov > > > [...] > > > > > > <----------------------------- > > > 200 OK, George > > > > > > > > > Ie, that I can authenticate myself for IPsec, but > > > forge my credentials at L7. I would expect that > > > there should be an API to get the credentials > > > presented for IPsec back up to the app. My > > > understanding is that Microsoft doesn't provide > > > any kernel API at all, and I didn't immediately > > > see anything in PFKEY, though I didn't look hard > > > so feel free to flame me. > > > > > > If there's not such an API, what was the reason? > > > This would seem like a pretty heavy burden to > > > recreate all of the identity machinery at the app > > > level to cover this attack. > > > > > > Mike > > > > -- > > 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 -- 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 Thu May 3 13:37: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 NAA05523; Thu, 3 May 2001 13:37:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09907 Thu, 3 May 2001 15:49:09 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.46873.137893.423692@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 12:52:57 -0700 (PDT) To: Derek Atkins Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: application layer cross checking In-Reply-To: References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.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 Derek Atkins writes: > Because applications may not be ipsec peers... Or, in most cases, > ipsec will be host-based, not user-based? What's the difference? Why shouldn't I be able to tell the socket layer which identity I want it to use for a particular 5-tuple, and the receiving end be able to verify that, including the application layer being able to cross check? If you can't do that, it sure seems like transport mode is severely hamstrung. As in, why bother? Mike > > -derek > > Michael Thomas writes: > > > Derek Atkins writes: > > > There is (currently) no API available to do what you want. > > > One reason is that IPSec authentication need not be user-based > > > authentication, so how would you pass that up to an application > > > and what good would it do? > > > > Well, for one thing it could prevent this attack. Isn't > > that enough? I'm aware that there may be situations > > where the two may differ, but there are probably > > an equal number where identities are the same, so > > why should each application have to roll its own > > identity module in that case? > > > > Mike > > > > > > > > -derek > > > > > > Michael Thomas writes: > > > > > > > I've had a nagging question for a long time which > > > > I'm hoping that somebody can shed some light on. > > > > > > > > Suppose I have a linux box running Freeswan > > > > talking to a Solaris 8 box. Suppose also that we > > > > have a way to mutually authenticate each other at > > > > the IPsec level (pre-shared, certs, whatever). > > > > Suppose also that this is just a transport mode > > > > SA. Is there any API which prevents the following > > > > kind of attack? > > > > > > > > Mike's-box Server > > > > ------------------------------ > > > > -----------------------------> > > > > IKE: DN=mike@mtcc.com > > > > > > > > <----------------------------- > > > > IKE: DN=server@server.com > > > > > > > > -----------------------------> > > > > SIP: INVITE > > > > From: gwb@whitehouse.gov > > > > [...] > > > > > > > > <----------------------------- > > > > 200 OK, George > > > > > > > > > > > > Ie, that I can authenticate myself for IPsec, but > > > > forge my credentials at L7. I would expect that > > > > there should be an API to get the credentials > > > > presented for IPsec back up to the app. My > > > > understanding is that Microsoft doesn't provide > > > > any kernel API at all, and I didn't immediately > > > > see anything in PFKEY, though I didn't look hard > > > > so feel free to flame me. > > > > > > > > If there's not such an API, what was the reason? > > > > This would seem like a pretty heavy burden to > > > > recreate all of the identity machinery at the app > > > > level to cover this attack. > > > > > > > > Mike > > > > > > -- > > > 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 > > -- > 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 Thu May 3 13:51: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 NAA06470; Thu, 3 May 2001 13:51:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09960 Thu, 3 May 2001 15:59:50 -0400 (EDT) Message-Id: <200105032004.f43K4J901839@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: application layer cross checking In-reply-to: Your message of "Thu, 03 May 2001 11:55:51 PDT." <15089.43447.409138.295986@thomasm-u1.cisco.com> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 03 May 2001 16:04:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An API of this form is on my list of things to add to solaris. In a sockets-API world, this info wants to show up in socket options on TCP connections and in recvmsg() ancillary data. PF_KEY is not the right place for it; PF_KEY is a privileged api used by the key management daemon (and already includes SA attributes for identities). Disclaimers: - I'm reluctant to make an API proposal until I have running code, because APIs Are Hard. - I'm not in a position to make any predictions about if/when it's going to appear in a product. - Bill From owner-ipsec@lists.tislabs.com Thu May 3 13:53: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 NAA06587; Thu, 3 May 2001 13:53:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09966 Thu, 3 May 2001 16:00:10 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Michael Thomas Cc: Derek Atkins , ipsec@lists.tislabs.com Subject: Re: application layer cross checking Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 16:05:01 -0400 Message-Id: <20010503200503.C7B3C7B7B@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <15089.46873.137893.423692@thomasm-u1.cisco.com>, Michael Thomas wri tes: >Derek Atkins writes: > > Because applications may not be ipsec peers... Or, in most cases, > > ipsec will be host-based, not user-based? > > What's the difference? Why shouldn't I be able to > tell the socket layer which identity I want it > to use for a particular 5-tuple, and the receiving > end be able to verify that, including the application > layer being able to cross check? > > If you can't do that, it sure seems like transport > mode is severely hamstrung. As in, why bother? Absolutely -- I've been asking for such an API for several years. More specifically, at a minimum I want a way for an application to find out what security mechanisms are in effect for a given socket, and whatever is known about the peer(s). It's up to the application to decide what permissions are associated with what identities, by whatever means it chooses. In that sense, it doesn't matter if it's a "user" or a "host" -- the access control mechanisms need not distinguish unless they wish to. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu May 3 13:55: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 NAA06761; Thu, 3 May 2001 13:55:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09985 Thu, 3 May 2001 16:04:59 -0400 (EDT) Message-Id: <4.3.2.7.0.20010503150211.03b471a0@posey.sctc.com> X-Sender: smith@posey.sctc.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 May 2001 15:11:54 -0500 To: Michael Thomas , ipsec@lists.tislabs.com From: Rick Smith at Secure Computing Subject: Re: application layer cross checking In-Reply-To: <15089.43447.409138.295986@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:55 PM 5/3/01, Michael Thomas wrote: >Ie, that I can authenticate myself for IPsec, but >forge my credentials at L7. Let's take this a step further. Assume that John uses his certificate to authenticate to IPSEC on a server and then masquerades as Cathy at Level 7, and performs some action that damages Cathy. If the server is keeping audit logs within both IKE and the application, then the server's owner should be able to tell which people had been authenticated to the server during the time that Cathy performed this self-destructive act, even if he can't necessarily tell which one was masquerading as Cathy. Does this provide enough granularity for your particular application? Well, it depends on what you're doing. Also, it's probably expensive to have someone extract the logs and do the forensics. In some cases, this level of security might be enough, but in other cases the application server needs to do its own authentication. This is where things like Kerberos start to pay off. Rick. smith@securecomputing.com From owner-ipsec@lists.tislabs.com Thu May 3 14:10: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 OAA07688; Thu, 3 May 2001 14:10:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10051 Thu, 3 May 2001 16:22:44 -0400 (EDT) Date: Thu, 3 May 2001 16:27:04 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: application layer cross checking In-Reply-To: <15089.46235.12938.686570@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 3 May 2001, Michael Thomas wrote: > ...I'm aware that there may be situations > where the two may differ, but there are probably > an equal number where identities are the same, so > why should each application have to roll its own > identity module in that case? If the application is passing around its own identities, then it is perfectly reasonable for the application to have its own means of verifying them. Even in your own example, note that IPsec works almost entirely in terms of IP addresses, and the identity you're claiming it should verify is based on a host *name*. Not the same thing at all, and the mapping between them is non-trivial. What IPsec perhaps *should* have an API for, is for asking "how sure are you that packets claiming to be from 10.20.30.40 are really from him?" (or, perhaps better, to say "I'm opening a connection to 10.20.30.40, please give me only packets that you are sure came from him"). It will still be necessary, in general, for an application to do its own thinking about what that assurance implies. What IPsec authentication gives us, ideally, is a world in which it is impossible to forge source addresses or alter packet contents. While that is useful, it is by no means the answer to all authentication problems. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu May 3 14:25: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 OAA09554; Thu, 3 May 2001 14:25:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10085 Thu, 3 May 2001 16:29:53 -0400 (EDT) Date: Thu, 3 May 2001 16:34:09 -0400 From: Ramin Alidousti To: Derek Atkins Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: application layer cross checking Message-ID: <20010503163408.W1548@uu.net> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from warlord@mit.edu on Thu, May 03, 2001 at 03:45:32PM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agreed. Even if the OS would pass the username or userid from one end to another (by means of some other protocol) you still need to challenge that id. Besides, it's called IPsec and meant for secure communication through an IP network; application level authentication is a different matter. You could do that though, but it will not fit into the layered approach. Ramin On Thu, May 03, 2001 at 03:45:32PM -0400, Derek Atkins wrote: > Because applications may not be ipsec peers... Or, in most cases, > ipsec will be host-based, not user-based? > > -derek > > Michael Thomas writes: > > > Derek Atkins writes: > > > There is (currently) no API available to do what you want. > > > One reason is that IPSec authentication need not be user-based > > > authentication, so how would you pass that up to an application > > > and what good would it do? > > > > Well, for one thing it could prevent this attack. Isn't > > that enough? I'm aware that there may be situations > > where the two may differ, but there are probably > > an equal number where identities are the same, so > > why should each application have to roll its own > > identity module in that case? > > > > Mike > > > > > > > > -derek > > > > > > Michael Thomas writes: > > > > > > > I've had a nagging question for a long time which > > > > I'm hoping that somebody can shed some light on. > > > > > > > > Suppose I have a linux box running Freeswan > > > > talking to a Solaris 8 box. Suppose also that we > > > > have a way to mutually authenticate each other at > > > > the IPsec level (pre-shared, certs, whatever). > > > > Suppose also that this is just a transport mode > > > > SA. Is there any API which prevents the following > > > > kind of attack? > > > > > > > > Mike's-box Server > > > > ------------------------------ > > > > -----------------------------> > > > > IKE: DN=mike@mtcc.com > > > > > > > > <----------------------------- > > > > IKE: DN=server@server.com > > > > > > > > -----------------------------> > > > > SIP: INVITE > > > > From: gwb@whitehouse.gov > > > > [...] > > > > > > > > <----------------------------- > > > > 200 OK, George > > > > > > > > > > > > Ie, that I can authenticate myself for IPsec, but > > > > forge my credentials at L7. I would expect that > > > > there should be an API to get the credentials > > > > presented for IPsec back up to the app. My > > > > understanding is that Microsoft doesn't provide > > > > any kernel API at all, and I didn't immediately > > > > see anything in PFKEY, though I didn't look hard > > > > so feel free to flame me. > > > > > > > > If there's not such an API, what was the reason? > > > > This would seem like a pretty heavy burden to > > > > recreate all of the identity machinery at the app > > > > level to cover this attack. > > > > > > > > Mike > > > > > > -- > > > 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 > > -- > 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 -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 From owner-ipsec@lists.tislabs.com Thu May 3 15:02: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 PAA13029; Thu, 3 May 2001 15:02:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10205 Thu, 3 May 2001 17:11:38 -0400 (EDT) Date: Thu, 3 May 2001 17:16:26 -0400 From: Ramin Alidousti To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: application layer cross checking Message-ID: <20010503171626.X1548@uu.net> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <15089.43447.409138.295986@thomasm-u1.cisco.com>; from mat@cisco.com on Thu, May 03, 2001 at 11:55:51AM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Take ssh for instance. It guarantees the secure communication channel. It also passes the userid/username to the other end. But it does not mean that the sshd on the other end says: "Oh, Mr XYZ, I believe who you are and the doors are wide open. Please do come in". As I said before, even if the OS passes the user information, the other end NEEDS to challenge that id. Application level authentication is not the same as AH/ESP authentication (as it stands). Ramin On Thu, May 03, 2001 at 11:55:51AM -0700, Michael Thomas wrote: > > > I've had a nagging question for a long time which > I'm hoping that somebody can shed some light on. > > Suppose I have a linux box running Freeswan > talking to a Solaris 8 box. Suppose also that we > have a way to mutually authenticate each other at > the IPsec level (pre-shared, certs, whatever). > Suppose also that this is just a transport mode > SA. Is there any API which prevents the following > kind of attack? > > Mike's-box Server > ------------------------------ > -----------------------------> > IKE: DN=mike@mtcc.com > > <----------------------------- > IKE: DN=server@server.com > > -----------------------------> > SIP: INVITE > From: gwb@whitehouse.gov > [...] > > <----------------------------- > 200 OK, George > > > Ie, that I can authenticate myself for IPsec, but > forge my credentials at L7. I would expect that > there should be an API to get the credentials > presented for IPsec back up to the app. My > understanding is that Microsoft doesn't provide > any kernel API at all, and I didn't immediately > see anything in PFKEY, though I didn't look hard > so feel free to flame me. > > If there's not such an API, what was the reason? > This would seem like a pretty heavy burden to > recreate all of the identity machinery at the app > level to cover this attack. > > Mike From owner-ipsec@lists.tislabs.com Thu May 3 15:11: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 PAA13290; Thu, 3 May 2001 15:11:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10233 Thu, 3 May 2001 17:24:30 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.52633.177939.677862@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 14:28:57 -0700 (PDT) To: Ramin Alidousti Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: application layer cross checking In-Reply-To: <20010503171626.X1548@uu.net> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <20010503171626.X1548@uu.net> 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 Ramin Alidousti writes: > Take ssh for instance. It guarantees the secure communication > channel. It also passes the userid/username to the other end. > But it does not mean that the sshd on the other end says: > "Oh, Mr XYZ, I believe who you are and the doors are wide > open. Please do come in". Not at all. As with Kerberos, if you pass the credentials to the other side and key those packets under that session key, it doesn't matter whether you send your username... Unless the application stupidly believes that username when cryptographically proveable credentials were available. > As I said before, even if the OS passes the user information, > the other end NEEDS to challenge that id. Challenge it in what way? If it's been cryptographically been challenged at the IPsec layer, all I need to do is do a strcmp to see if it matches the credentials it's using at the application layer. That assumes a 1:1 mapping, but that's likely to be just fine for many applications. > Application level > authentication is not the same as AH/ESP authentication > (as it stands). It's not necessarily the same, but it may be the same. When it is, it relieves the application of having to deal with identity -- which just about nothing gets right. Also: I don't think this is any more of a layer violation as passing up the IP address, etc, in recvfrom(). Mike From owner-ipsec@lists.tislabs.com Thu May 3 15:13: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 PAA13340; Thu, 3 May 2001 15:13:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10259 Thu, 3 May 2001 17:29:02 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Michael Thomas Cc: Ramin Alidousti , ipsec@lists.tislabs.com Subject: Re: application layer cross checking Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 May 2001 17:33:55 -0400 Message-Id: <20010503213355.E3DD27B7B@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <15089.52633.177939.677862@thomasm-u1.cisco.com>, Michael Thomas wri tes: >Ramin Alidousti writes: > > Take ssh for instance. It guarantees the secure communication > > channel. It also passes the userid/username to the other end. > > But it does not mean that the sshd on the other end says: > > "Oh, Mr XYZ, I believe who you are and the doors are wide > > open. Please do come in". > > Not at all. As with Kerberos, if you pass the credentials > to the other side and key those packets under that session > key, it doesn't matter whether you send your username... > Unless the application stupidly believes that username > when cryptographically proveable credentials were available. > Right. "Authentication is not authorization". IPsec provides the former; anything that uses that authenticated identity must provide the latter. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu May 3 15:19: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 PAA13467; Thu, 3 May 2001 15:19:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10273 Thu, 3 May 2001 17:32:37 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.53089.431725.612223@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 14:36:33 -0700 (PDT) To: Derek Atkins Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: application layer cross checking In-Reply-To: References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.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 Derek Atkins writes: > Because applications may not be ipsec peers... Or, in most cases, > ipsec will be host-based, not user-based? This seems like a rather single user PC based mentality. If we were running a multiuser timesharing system, being able to supply credentials on a per user basis would be rather necessary, no? Or perhaps I have a smart card which does the signatures which identifies me regardless of which machine I'm using, etc, etc. I don't see what prevents the SPD from having rules like "for 5-tuple [a,b,c,d,e], demand credentials in realm X" where those credentials might require a human to insert a piece of hardware, or type into a dialog box slapped up by the keying daemon, or whatever. Mike From owner-ipsec@lists.tislabs.com Thu May 3 15:22: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 PAA13521; Thu, 3 May 2001 15:22:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10303 Thu, 3 May 2001 17:35:35 -0400 (EDT) Date: Thu, 3 May 2001 17:38:47 -0400 From: Ramin Alidousti To: Michael Thomas Cc: Ramin Alidousti , ipsec@lists.tislabs.com Subject: Re: application layer cross checking Message-ID: <20010503173846.A1548@uu.net> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <20010503171626.X1548@uu.net> <15089.52633.177939.677862@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <15089.52633.177939.677862@thomasm-u1.cisco.com>; from mat@cisco.com on Thu, May 03, 2001 at 02:28:57PM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's because all the kerberized entities trust the TGA. What you're proposing here is, let's use the key exchange machanism we're using for IPsec, also for application authentication. But it does not mean that one needs to mix these two different matters. Ramin On Thu, May 03, 2001 at 02:28:57PM -0700, Michael Thomas wrote: > Ramin Alidousti writes: > > Take ssh for instance. It guarantees the secure communication > > channel. It also passes the userid/username to the other end. > > But it does not mean that the sshd on the other end says: > > "Oh, Mr XYZ, I believe who you are and the doors are wide > > open. Please do come in". > > Not at all. As with Kerberos, if you pass the credentials > to the other side and key those packets under that session > key, it doesn't matter whether you send your username... > Unless the application stupidly believes that username > when cryptographically proveable credentials were available. > > > As I said before, even if the OS passes the user information, > > the other end NEEDS to challenge that id. > > Challenge it in what way? If it's been cryptographically > been challenged at the IPsec layer, all I need to do > is do a strcmp to see if it matches the credentials it's > using at the application layer. That assumes a 1:1 > mapping, but that's likely to be just fine for many > applications. > > > Application level > > authentication is not the same as AH/ESP authentication > > (as it stands). > > It's not necessarily the same, but it may be the same. > When it is, it relieves the application of having to > deal with identity -- which just about nothing gets > right. Also: I don't think this is any more of a layer violation > as passing up the IP address, etc, in recvfrom(). > > Mike From owner-ipsec@lists.tislabs.com Thu May 3 15:41: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 PAA14741; Thu, 3 May 2001 15:41:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10372 Thu, 3 May 2001 17:54:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <15089.53089.431725.612223@thomasm-u1.cisco.com> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.com> <15089.53089.431725.612223@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 17:54:55 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: application layer cross checking Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:36 PM -0700 5/3/01, Michael Thomas wrote: >Derek Atkins writes: > > Because applications may not be ipsec peers... Or, in most cases, > > ipsec will be host-based, not user-based? > > This seems like a rather single user PC based > mentality. If we were running a multiuser timesharing > system, being able to supply credentials on a per > user basis would be rather necessary, no? Or > perhaps I have a smart card which does the > signatures which identifies me regardless of > which machine I'm using, etc, etc. I don't see > what prevents the SPD from having rules like > "for 5-tuple [a,b,c,d,e], demand credentials in > realm X" where those credentials might require > a human to insert a piece of hardware, or type > into a dialog box slapped up by the keying > daemon, or whatever. The SPD is a means of specifying access controls and security services for traffic at layer 3. It would be inappropriate to do what you suggest here. Steve From owner-ipsec@lists.tislabs.com Thu May 3 16:31: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 QAA18237; Thu, 3 May 2001 16:31:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10504 Thu, 3 May 2001 18:43:59 -0400 (EDT) Message-Id: <4.1.20010503155013.016c7970@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 May 2001 15:52:39 -0700 To: Michael Thomas , Derek Atkins From: Jonathan Trostle Subject: Re: application layer cross checking Cc: ipsec@lists.tislabs.com In-Reply-To: <15089.46873.137893.423692@thomasm-u1.cisco.com> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:52 PM 5/3/01 -0700, Michael Thomas wrote: >Derek Atkins writes: > > Because applications may not be ipsec peers... Or, in most cases, > > ipsec will be host-based, not user-based? > > What's the difference? Why shouldn't I be able to > tell the socket layer which identity I want it > to use for a particular 5-tuple, and the receiving > end be able to verify that, including the application > layer being able to cross check? > > If you can't do that, it sure seems like transport > mode is severely hamstrung. As in, why bother? Aren't there more hardware acceleration products available for use with IPSEC vs. doing data encryption at the application layer? Jonathan > > Mike > > > > > -derek > > > > Michael Thomas writes: > > > > > Derek Atkins writes: > > > > There is (currently) no API available to do what you want. > > > > One reason is that IPSec authentication need not be user-based > > > > authentication, so how would you pass that up to an application > > > > and what good would it do? > > > > > > Well, for one thing it could prevent this attack. Isn't > > > that enough? I'm aware that there may be situations > > > where the two may differ, but there are probably > > > an equal number where identities are the same, so > > > why should each application have to roll its own > > > identity module in that case? > > > > > > Mike > > > > > > > > > > > -derek > > > > > > > > Michael Thomas writes: > > > > > > > > > I've had a nagging question for a long time which > > > > > I'm hoping that somebody can shed some light on. > > > > > > > > > > Suppose I have a linux box running Freeswan > > > > > talking to a Solaris 8 box. Suppose also that we > > > > > have a way to mutually authenticate each other at > > > > > the IPsec level (pre-shared, certs, whatever). > > > > > Suppose also that this is just a transport mode > > > > > SA. Is there any API which prevents the following > > > > > kind of attack? > > > > > > > > > > Mike's-box Server > > > > > ------------------------------ > > > > > -----------------------------> > > > > > IKE: DN=mike@mtcc.com > > > > > > > > > > <----------------------------- > > > > > IKE: DN=server@server.com > > > > > > > > > > -----------------------------> > > > > > SIP: INVITE > > > > > From: gwb@whitehouse.gov > > > > > [...] > > > > > > > > > > <----------------------------- > > > > > 200 OK, George > > > > > > > > > > > > > > > Ie, that I can authenticate myself for IPsec, but > > > > > forge my credentials at L7. I would expect that > > > > > there should be an API to get the credentials > > > > > presented for IPsec back up to the app. My > > > > > understanding is that Microsoft doesn't provide > > > > > any kernel API at all, and I didn't immediately > > > > > see anything in PFKEY, though I didn't look hard > > > > > so feel free to flame me. > > > > > > > > > > If there's not such an API, what was the reason? > > > > > This would seem like a pretty heavy burden to > > > > > recreate all of the identity machinery at the app > > > > > level to cover this attack. > > > > > > > > > > Mike > > > > > > > > -- > > > > 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 > > > > -- > > 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 Thu May 3 16:33: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 QAA18412; Thu, 3 May 2001 16:33:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10519 Thu, 3 May 2001 18:46:51 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.57572.305278.721116@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 15:51:16 -0700 (PDT) To: Stephen Kent Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: application layer cross checking In-Reply-To: References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.com> <15089.53089.431725.612223@thomasm-u1.cisco.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 Stephen Kent writes: > At 2:36 PM -0700 5/3/01, Michael Thomas wrote: > >Derek Atkins writes: > > > Because applications may not be ipsec peers... Or, in most cases, > > > ipsec will be host-based, not user-based? > > > > This seems like a rather single user PC based > > mentality. If we were running a multiuser timesharing > > system, being able to supply credentials on a per > > user basis would be rather necessary, no? Or > > perhaps I have a smart card which does the > > signatures which identifies me regardless of > > which machine I'm using, etc, etc. I don't see > > what prevents the SPD from having rules like > > "for 5-tuple [a,b,c,d,e], demand credentials in > > realm X" where those credentials might require > > a human to insert a piece of hardware, or type > > into a dialog box slapped up by the keying > > daemon, or whatever. > > The SPD is a means of specifying access controls and security > services for traffic at layer 3. It would be inappropriate to do > what you suggest here. [???] What does that have to do with the means that you supply those rules into the SPD, and checking up on who was authenticated to those rules in the SADB? I can't believe you're seriously suggesting that the SPD shouldn't be able to deal with rules like: "to [src=*, dst=me, proto=UDP, sport=*, dport=1234] method=EXTERNAL, callout=GetSmartCardSignFromLuser(), realm=fOoThEFunLoVIngbAR". This is purely a local implementation issue. Likewise, an API which allows you to view the rule and credentials which a particular SA authenticted with -- or not -- is also purely a local implementation issue. How can that possibly be "inappropriate"? It's my machine, after all. Mike From owner-ipsec@lists.tislabs.com Thu May 3 16:53: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 QAA19544; Thu, 3 May 2001 16:53:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10577 Thu, 3 May 2001 19:02:55 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.58522.581761.599193@thomasm-u1.cisco.com> Date: Thu, 3 May 2001 16:07:06 -0700 (PDT) To: Henry Spencer Cc: IP Security List Subject: Re: application layer cross checking In-Reply-To: References: <15089.46235.12938.686570@thomasm-u1.cisco.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, 3 May 2001, Michael Thomas wrote: > > ...I'm aware that there may be situations > > where the two may differ, but there are probably > > an equal number where identities are the same, so > > why should each application have to roll its own > > identity module in that case? > > If the application is passing around its own identities, then it is > perfectly reasonable for the application to have its own means of > verifying them. I don't know about you, but I don't know many applications that actually do that. Even fewer which do that with strong authentication. The prospect of getting applications -- and their on the wire protocols -- to do the right thing here is, IMO, pretty dismal. > Even in your own example, note that IPsec works almost > entirely in terms of IP addresses, and the identity you're claiming it > should verify is based on a host *name*. Not the same thing at all, > and the mapping between them is non-trivial. Well, explicit coupling of identity to IP addresses isn't exactly without its own set of problems (cf HIP, multihoming, mobility, etc). But I don't think we even need to raise _that_ spectre: if you're using a wildcarded rule on the incoming IP address for a particular destination port that it is required to authenticate into a particular realm before it passes that access check, being able check which credentials were *actually* passed to create the SA is nothing different than allowing recvfrom() to pass the incoming dst IP address as a means of identity. The stack, after all, doesn't care *what* the credentials name, it just wants to know whether to permit the traffic based upon the rule. > What IPsec perhaps *should* have an API for, is for asking "how sure are > you that packets claiming to be from 10.20.30.40 are really from him?" > (or, perhaps better, to say "I'm opening a connection to 10.20.30.40, > please give me only packets that you are sure came from him"). It will > still be necessary, in general, for an application to do its own thinking > about what that assurance implies. I don't think this entirely disimilar to what I'm saying, though I don't think the IP address coupling is necessary to do what I'm thinking of. What I'm extremely skeptical of is having each application re-create IKE and its kin. Ugh. You might as well just chuck IPsec altogether and use TLS. And chuck transport mode while you're at it. Mike From owner-ipsec@lists.tislabs.com Fri May 4 05:41: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 FAA11968; Fri, 4 May 2001 05:41:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11837 Fri, 4 May 2001 07:37:46 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 03 May 2001 15:12:35 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: application layer cross checking Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA10184 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is not only a good idea, it's a very important idea in the infinitesimally slow progress towards meaningful authentication and privacy for the Internet. If this API existed then it would be so much easier to do a good job on inter-organizational access control for a wide range of applications. Hilarie >>> "Steven M. Bellovin" 05/03/01 02:05PM >>> In message <15089.46873.137893.423692@thomasm-u1.cisco.com>, Michael Thomas wri tes: >Derek Atkins writes: > > Because applications may not be ipsec peers... Or, in most cases, > > ipsec will be host-based, not user-based? > > What's the difference? Why shouldn't I be able to > tell the socket layer which identity I want it > to use for a particular 5-tuple, and the receiving > end be able to verify that, including the application > layer being able to cross check? > > If you can't do that, it sure seems like transport > mode is severely hamstrung. As in, why bother? Absolutely -- I've been asking for such an API for several years. More specifically, at a minimum I want a way for an application to find out what security mechanisms are in effect for a given socket, and whatever is known about the peer(s). It's up to the application to decide what permissions are associated with what identities, by whatever means it chooses. In that sense, it doesn't matter if it's a "user" or a "host" -- the access control mechanisms need not distinguish unless they wish to. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Fri May 4 05:41: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 FAA11981; Fri, 4 May 2001 05:41:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11849 Fri, 4 May 2001 07:38:46 -0400 (EDT) From: ark@eltex.ru Date: Fri, 4 May 2001 13:29:35 +0400 Message-Id: <200105040929.NAA02007@paranoid.eltex.ru> In-Reply-To: <15089.58522.581761.599193@thomasm-u1.cisco.com> from "Michael Thomas " Organization: "Klingon Imperial Intelligence Service" Subject: Re: application layer cross checking To: mat@cisco.com Cc: henry@spsystems.net, ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- nuqneH, The API should make things easier to control: you can tell your application to, say, "allow reusable passwords if your link is protected with reasonable crypto" or something - instead of configuring trusted ip address range and configuring policy for those addresses. Afair there was a feature like that in cisco pix ;) Michael Thomas said : > > Even in your own example, note that IPsec works almost > > entirely in terms of IP addresses, and the identity you're claiming it > > should verify is based on a host *name*. Not the same thing at all, > > and the mapping between them is non-trivial. > > Well, explicit coupling of identity to IP > addresses isn't exactly without its own set > of problems (cf HIP, multihoming, mobility, > etc). But I don't think we even need to raise > _that_ spectre: if you're using a wildcarded > rule on the incoming IP address for a > particular destination port that it is > required to authenticate into a particular > realm before it passes that access check, > being able check which credentials were > *actually* passed to create the SA is nothing > different than allowing recvfrom() to pass > the incoming dst IP address as a means of identity. > The stack, after all, doesn't care *what* the > credentials name, it just wants to know whether > to permit the traffic based upon the rule. > > > What IPsec perhaps *should* have an API for, is for asking "how sure are > > you that packets claiming to be from 10.20.30.40 are really from him?" > > (or, perhaps better, to say "I'm opening a connection to 10.20.30.40, > > please give me only packets that you are sure came from him"). It will > > still be necessary, in general, for an application to do its own thinking > > about what that assurance implies. > > I don't think this entirely disimilar to what > I'm saying, though I don't think the IP address > coupling is necessary to do what I'm thinking > of. What I'm extremely skeptical of is having > each application re-create IKE and its kin. > Ugh. You might as well just chuck IPsec > altogether and use TLS. And chuck transport > mode while you're at it. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQCVAwUBOvJ2f6H/mIJW9LeBAQEELAP/fCtHnBWxvUIUwgQkdP7rQJ4+Yq0eBrw/ erDy1kNudOdXCMVI7Y6XTqb9OoLNBPiVqFt/RlpXy0qvK2TH+BQGGt18P3k/IJwR YzmkqGKsQEj2kuR7QoSs4iOWWZfHL8z57jm86qSjFuQRn6sFjc4ca3uMmuWB+/Xh HoVbS4XqIc4= =qHGs -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri May 4 07:19: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 HAA18937; Fri, 4 May 2001 07:19:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12319 Fri, 4 May 2001 09:24:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <15089.57572.305278.721116@thomasm-u1.cisco.com> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> <15089.46235.12938.686570@thomasm-u1.cisco.com> <15089.53089.431725.612223@thomasm-u1.cisco.com> <15089.57572.305278.721116@thomasm-u1.cisco.com> Date: Fri, 4 May 2001 09:27:50 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: application layer cross checking Cc: Michael Thomas , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:51 PM -0700 5/3/01, Michael Thomas wrote: >Stephen Kent writes: > > At 2:36 PM -0700 5/3/01, Michael Thomas wrote: > > >Derek Atkins writes: > > > > Because applications may not be ipsec peers... Or, in most cases, > > > > ipsec will be host-based, not user-based? > > > > > > This seems like a rather single user PC based > > > mentality. If we were running a multiuser timesharing > > > system, being able to supply credentials on a per > > > user basis would be rather necessary, no? Or > > > perhaps I have a smart card which does the > > > signatures which identifies me regardless of > > > which machine I'm using, etc, etc. I don't see > > > what prevents the SPD from having rules like > > > "for 5-tuple [a,b,c,d,e], demand credentials in > > > realm X" where those credentials might require > > > a human to insert a piece of hardware, or type > > > into a dialog box slapped up by the keying > > > daemon, or whatever. > > > > The SPD is a means of specifying access controls and security > > services for traffic at layer 3. It would be inappropriate to do > > what you suggest here. > > [???] > > What does that have to do with the means that > you supply those rules into the SPD, and checking > up on who was authenticated to those rules in > the SADB? > > I can't believe you're seriously suggesting that > the SPD shouldn't be able to deal with rules like: > > "to [src=*, dst=me, proto=UDP, sport=*, dport=1234] > method=EXTERNAL, callout=GetSmartCardSignFromLuser(), > realm=fOoThEFunLoVIngbAR". > > This is purely a local implementation issue. > Likewise, an API which allows you to view the rule and > credentials which a particular SA authenticted with > -- or not -- is also purely a local implementation > issue. > > How can that possibly be "inappropriate"? It's my > machine, after all. 2401 defines a minimum compliant SPD, so you are right that it could be extended in ways that have only local significance and do not interfere with externally visible operation. However, you have not made a good argument why the SPD is the place where one would configure extra info re local options for how local user authentication is effected (citing your example above). Why would that be different on a per SPD entry basis, vs. consistent for all local user authentication actions. IUf one tries to extend this model to peer authentication, then it is no longer a local matter. Maybe I don't understand the scope of what you propose. The example you give above seems like an odd way to represent a simple notion, i.e., the local user has a token to protect his private key. How a private key is protected is certainly a local matter, outside the scope of IPsec. But I don't know, from your example, what "method" is supposed to apply to re an SPD entry? Why is it bound to the "me" value for the IP dest addr? Maybe it's just a poor example that you have chosen to illustrate your point, but if one tries to think about a standard API (which we don't do yet anyway), one would need to be a lot less vague about the nature of the extra parameters. Steve From owner-ipsec@lists.tislabs.com Fri May 4 07:35: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 HAA20307; Fri, 4 May 2001 07:35:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12416 Fri, 4 May 2001 09:45:50 -0400 (EDT) Date: Fri, 4 May 2001 06:40:37 -0700 (PDT) From: Rick Wessman X-Sender: Reply-To: To: Hilarie Orman cc: , , , Subject: Re: application layer cross checking In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I definitely agree. An API like this would allow applications like Oracle to work much more easily over the Internet. Oracle already allows for the use of authentication mechanisms other than username/password, so it should be relatively easy for us to plug in an IPSEC API. I use Oracle as an example not only because I work there. :-) I'm sure that a lot of other applications could use such an API. In addition, I think that a lot of users think that IPSEC already provides such an API. We get questions all of the time from people who want to know if we support IPSEC authentication. Rick On Thu, 3 May 2001, Hilarie Orman wrote: > Date: Thu, 03 May 2001 15:12:35 -0600 > From: Hilarie Orman > To: mat@cisco.com, smb@research.att.com > Cc: ipsec@lists.tislabs.com, warlord@mit.edu > Subject: Re: application layer cross checking > > This is not only a good idea, it's a very important idea in the infinitesimally > slow progress towards meaningful authentication and privacy for the > Internet. If this API existed then it would be so much easier to do > a good job on inter-organizational access control for a wide range > of applications. > > Hilarie > > >>> "Steven M. Bellovin" 05/03/01 02:05PM >>> > In message <15089.46873.137893.423692@thomasm-u1.cisco.com>, Michael Thomas wri > tes: > >Derek Atkins writes: > > > Because applications may not be ipsec peers... Or, in most cases, > > > ipsec will be host-based, not user-based? > > > > What's the difference? Why shouldn't I be able to > > tell the socket layer which identity I want it > > to use for a particular 5-tuple, and the receiving > > end be able to verify that, including the application > > layer being able to cross check? > > > > If you can't do that, it sure seems like transport > > mode is severely hamstrung. As in, why bother? > > Absolutely -- I've been asking for such an API for several years. > > More specifically, at a minimum I want a way for an application to find > out what security mechanisms are in effect for a given socket, and > whatever is known about the peer(s). It's up to the application to > decide what permissions are associated with what identities, by > whatever means it chooses. In that sense, it doesn't matter if it's a > "user" or a "host" -- the access control mechanisms need not > distinguish unless they wish to. > > > --Steve Bellovin, http://www.research.att.com/~smb > > > > > From owner-ipsec@lists.tislabs.com Sat May 5 11:52: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 LAA14571; Sat, 5 May 2001 11:52:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15651 Sat, 5 May 2001 13:39:34 -0400 (EDT) Date: Sat, 5 May 2001 13:44:32 -0400 From: Ramin Alidousti To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: application layer cross checking Message-ID: <20010505134432.E16548@uu.net> References: <15089.43447.409138.295986@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <15089.43447.409138.295986@thomasm-u1.cisco.com>; from mat@cisco.com on Thu, May 03, 2001 at 11:55:51AM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been thinking about this and I think now I understand what you're suggesting (sorry for the delay ;-). On the server you say: L3: if the remote IP is x.y.z.t L4: if the local service is xyz L7: if the remote user is abc then I accept the connection or in other words: this SPI implies the above. Is this what you suggested? If that's the case, I agree and it even doesn't have to be a "transport mode only" thing. However, I still don't get all the buzz about the API's. Ramin On Thu, May 03, 2001 at 11:55:51AM -0700, Michael Thomas wrote: > > > I've had a nagging question for a long time which > I'm hoping that somebody can shed some light on. > > Suppose I have a linux box running Freeswan > talking to a Solaris 8 box. Suppose also that we > have a way to mutually authenticate each other at > the IPsec level (pre-shared, certs, whatever). > Suppose also that this is just a transport mode > SA. Is there any API which prevents the following > kind of attack? > > Mike's-box Server > ------------------------------ > -----------------------------> > IKE: DN=mike@mtcc.com > > <----------------------------- > IKE: DN=server@server.com > > -----------------------------> > SIP: INVITE > From: gwb@whitehouse.gov > [...] > > <----------------------------- > 200 OK, George > > > Ie, that I can authenticate myself for IPsec, but > forge my credentials at L7. I would expect that > there should be an API to get the credentials > presented for IPsec back up to the app. My > understanding is that Microsoft doesn't provide > any kernel API at all, and I didn't immediately > see anything in PFKEY, though I didn't look hard > so feel free to flame me. > > If there's not such an API, what was the reason? > This would seem like a pretty heavy burden to > recreate all of the identity machinery at the app > level to cover this attack. > > Mike From owner-ipsec@lists.tislabs.com Mon May 7 10:57: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 KAA20417; Mon, 7 May 2001 10:57:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19590 Mon, 7 May 2001 13:03:41 -0400 (EDT) Date: Mon, 7 May 2001 10:08:14 -0700 (PDT) From: Jan Vilhuber To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: src addr/SPI coupling In-Reply-To: <15094.53290.539696.864321@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, section 4.1 from rfc 2401 states: A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. [...] It's not the source address. jan On Mon, 7 May 2001, Michael Thomas wrote: > > Fearlessly trudging ahead with my Stupid Question > series, it's my understanding that IPsec > implementations upon receiving a packet with AH/ESP > in it check both the SPI and the source address in > the incoming packet to determine which security > context to use. Assuming that I don't have that > part wrong, what advantage is there in coupling > the two? Ordinarily, the SPI is chosen by the > receiver and could easily be unique against it's > entire set of SA's so it doesn't seem to be > required from a demux standpoint. > > I can think of some down sides to this: mobilty, > renumbering and multihoming wouldn't find this > behavior very friendly. The reason I bring this up > is because I've been working off and on on a draft > so that MIPv6 binding updates can use ESP > instead/in addition to AH. One thing that comes us > is that the MIP folks are expecting the Home > Address option to be outside of the ESP > encapsulation so that it can be used to select the > proper security context (along with the > SPI). Since it might be encrypted if it were > inside, you obviously have a cart before horse > problem, and you obviously want it protected > from tampering... > > It seems that relaxing the source address coupling > with the SPI would address that particular > problem, as well as allow SA's to survive > renumbering and multihoming failover... > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon May 7 10:57: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 KAA20434; Mon, 7 May 2001 10:57:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19528 Mon, 7 May 2001 12:36:41 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.53290.539696.864321@thomasm-u1.cisco.com> Date: Mon, 7 May 2001 09:41:14 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: src addr/SPI coupling 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 Fearlessly trudging ahead with my Stupid Question series, it's my understanding that IPsec implementations upon receiving a packet with AH/ESP in it check both the SPI and the source address in the incoming packet to determine which security context to use. Assuming that I don't have that part wrong, what advantage is there in coupling the two? Ordinarily, the SPI is chosen by the receiver and could easily be unique against it's entire set of SA's so it doesn't seem to be required from a demux standpoint. I can think of some down sides to this: mobilty, renumbering and multihoming wouldn't find this behavior very friendly. The reason I bring this up is because I've been working off and on on a draft so that MIPv6 binding updates can use ESP instead/in addition to AH. One thing that comes us is that the MIP folks are expecting the Home Address option to be outside of the ESP encapsulation so that it can be used to select the proper security context (along with the SPI). Since it might be encrypted if it were inside, you obviously have a cart before horse problem, and you obviously want it protected from tampering... It seems that relaxing the source address coupling with the SPI would address that particular problem, as well as allow SA's to survive renumbering and multihoming failover... Mike From owner-ipsec@lists.tislabs.com Mon May 7 11:24: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 LAA23279; Mon, 7 May 2001 11:24:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19690 Mon, 7 May 2001 13:36:39 -0400 (EDT) Message-Id: <3.0.5.32.20010507191508.0430be90@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 May 2001 19:15:08 +0200 To: Michael Thomas From: Joern Sierwald Subject: Re: src addr/SPI coupling Cc: ipsec@lists.tislabs.com In-Reply-To: <15094.53290.539696.864321@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA19627 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:41 07.05.01 -0700, Michael Thomas wrote: > >Fearlessly trudging ahead with my Stupid Question >series, it's my understanding that IPsec >implementations upon receiving a packet with AH/ESP >in it check both the SPI and the source address in >the incoming packet to determine which security >context to use. Assuming that I don't have that >part wrong, what advantage is there in coupling >the two? Ordinarily, the SPI is chosen by the >receiver and could easily be unique against it's >entire set of SA's so it doesn't seem to be >required from a demux standpoint. > >I can think of some down sides to this: mobilty, >renumbering and multihoming wouldn't find this >behavior very friendly. The reason I bring this up >is because I've been working off and on on a draft >so that MIPv6 binding updates can use ESP >instead/in addition to AH. One thing that comes us >is that the MIP folks are expecting the Home >Address option to be outside of the ESP >encapsulation so that it can be used to select the >proper security context (along with the >SPI). Since it might be encrypted if it were >inside, you obviously have a cart before horse >problem, and you obviously want it protected >from tampering... > >It seems that relaxing the source address coupling >with the SPI would address that particular >problem, as well as allow SA's to survive >renumbering and multihoming failover... > > Mike > > So got it wrong. Entirely. The source address is not checked. An IPsec box can choose the SPI of _incoming_ traffic, thus it can avoid collisions easily. Jörn From owner-ipsec@lists.tislabs.com Mon May 7 12:24: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 MAA26256; Mon, 7 May 2001 12:24:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20026 Mon, 7 May 2001 14:19:52 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.59478.555839.354118@thomasm-u1.cisco.com> Date: Mon, 7 May 2001 11:24:22 -0700 (PDT) To: Jan Vilhuber Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: src addr/SPI coupling In-Reply-To: References: <15094.53290.539696.864321@thomasm-u1.cisco.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 Jan Vilhuber writes: > Actually, section 4.1 from rfc 2401 states: > > A security association is uniquely identified by a triple consisting > of a Security Parameter Index (SPI), an IP Destination Address, and a > security protocol (AH or ESP) identifier. [...] > > It's not the source address. OK, that changes the sense of the problem, but not the original question. Why does there need to be any dependency on the destination address to select the right SA? This still seems like it could run into trouble on the mobile node incoming traffic if the destination address were "wrong" (which is, I think, the way a naive stack might view it.) Mike From owner-ipsec@lists.tislabs.com Mon May 7 13:52: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 NAA02519; Mon, 7 May 2001 13:52:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20363 Mon, 7 May 2001 16:00:57 -0400 (EDT) Message-Id: <5.0.2.1.2.20010507125015.08475008@mira-sjcm-2.cisco.com> X-Sender: cmadson@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 07 May 2001 13:06:42 -0700 To: Michael Thomas From: Cheryl Madson Subject: Re: src addr/SPI coupling Cc: Jan Vilhuber , Michael Thomas , ipsec@lists.tislabs.com In-Reply-To: <15094.59478.555839.354118@thomasm-u1.cisco.com> References: <15094.53290.539696.864321@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:24 AM 5/7/2001, Michael Thomas wrote: >Jan Vilhuber writes: > > Actually, section 4.1 from rfc 2401 states: > > > > A security association is uniquely identified by a triple consisting > > of a Security Parameter Index (SPI), an IP Destination Address, and a > > security protocol (AH or ESP) identifier. [...] > > > > It's not the source address. > > OK, that changes the sense of the problem, but not > the original question. Why does there need to be > any dependency on the destination address to > select the right SA? This still seems like it > could run into trouble on the mobile node > incoming traffic if the destination address > were "wrong" (which is, I think, the way a > naive stack might view it.) > > Mike In the case of unicast traffic, one could argue that given a sufficiently large SPI space, that there might not be a need to have it on a per-destination address per box. That's assuming the IKE deamon(s) are all coordinated across the box. [Yes, there's normally one, but it probably shouldn't be that constrained...] That means being able to have one SPI space for tens of thousands of connections on a large aggregation box, and still enough for a reasonable number of rekeys of those connections. Keep in mind, though, that IPsec was originally designed with at least an eye towards multicast (even though we didn't claim to understand the problem set much then...). In the case of multicast traffic, where separate key servers may be controlling keys/SA assignment for different multicast sessions, you'd have to come up with a mechanism to ensure that there are (a) no collisions in SPI assignment across the possible universe of key servers, (b) but still have reasonable randomness to the SPI allocation (the phase 2 SPIs are used as additional randomness in the key derivation), and (c) the SPI space per address is sufficiently large enough for rekeying for some noticeable amount of time (because of (b)). In fact, we came up with (dest addr, protocol, spi) mainly because of multicast. But that was even before my time... thx - C =============================================== Cheryl Madson Strategic Cryptographic Development; Systems & Solutions Engineering Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec@lists.tislabs.com Mon May 7 15:59: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 PAA12208; Mon, 7 May 2001 15:59:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20575 Mon, 7 May 2001 17:54:26 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15095.6818.322551.69375@thomasm-u1.cisco.com> Date: Mon, 7 May 2001 14:58:58 -0700 (PDT) To: "jshukla" Cc: , "Michael Thomas" Subject: Re: src addr/SPI coupling In-Reply-To: <001801c0d740$d820f050$a4b12304@ffb5b> References: <15094.53290.539696.864321@thomasm-u1.cisco.com> <15094.59478.555839.354118@thomasm-u1.cisco.com> <001801c0d740$d820f050$a4b12304@ffb5b> 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 Now wait a minute. I thought the receiver chose the SPI. If so, it owns that number space (modulo Cheryl's comment about multicast), so there shouldn't be collisions. If another sender tried to use that SPI, it would imply that they have keying material. Mike jshukla writes: > > ----- Original Message ----- > From: "Michael Thomas" > > OK, that changes the sense of the problem, but not > > the original question. Why does there need to be > > any dependency on the destination address to > > select the right SA? This still seems like it > > To make sure that SA is unique!? SPI is only > 32 bits long and there is a finite chance of > collision. > > SPI is chosen by the destination of > SA who makes sure that it does not have two > identical SPIs (it does not prevent the source > from having the same SPI for another SA). > The source of SA uses the destination > address along with SPI to make sure that > SA is unique (in the event there is a collision and > the source ends up having two SAs that share > a common SPI). > > > could run into trouble on the mobile node > > incoming traffic if the destination address > > were "wrong" (which is, I think, the way a > > naive stack might view it.) > > > > Mike > > It will surely run into trouble. BTW, this > problem is similar to the NAT problem. > > > regards, > Jayant > From owner-ipsec@lists.tislabs.com Mon May 7 16: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 QAA14297; Mon, 7 May 2001 16:26:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20584 Mon, 7 May 2001 18:00:07 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15095.7159.477701.174007@thomasm-u1.cisco.com> Date: Mon, 7 May 2001 15:04:39 -0700 (PDT) To: Cheryl Madson Cc: Michael Thomas , Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: src addr/SPI coupling In-Reply-To: <5.0.2.1.2.20010507125015.08475008@mira-sjcm-2.cisco.com> References: <15094.53290.539696.864321@thomasm-u1.cisco.com> <5.0.2.1.2.20010507125015.08475008@mira-sjcm-2.cisco.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 Would it make sense to carve out a portion of the SPI space for multicast? Also: you can always tell the destination is multicast on the receiver, so it wouldn't be impossible to special case _that_ (ie dst=mcast implies different SPI space). Were there other reasons? I'm mostly curious here what the motivation was. Mike Cheryl Madson writes: > At 11:24 AM 5/7/2001, Michael Thomas wrote: > >Jan Vilhuber writes: > > > Actually, section 4.1 from rfc 2401 states: > > > > > > A security association is uniquely identified by a triple consisting > > > of a Security Parameter Index (SPI), an IP Destination Address, and a > > > security protocol (AH or ESP) identifier. [...] > > > > > > It's not the source address. > > > > OK, that changes the sense of the problem, but not > > the original question. Why does there need to be > > any dependency on the destination address to > > select the right SA? This still seems like it > > could run into trouble on the mobile node > > incoming traffic if the destination address > > were "wrong" (which is, I think, the way a > > naive stack might view it.) > > > > Mike > > In the case of unicast traffic, one could argue that given a sufficiently large > SPI space, that there might not be a need to have it on a per-destination > address per box. That's assuming the IKE deamon(s) are all coordinated > across the box. [Yes, there's normally one, but it probably shouldn't be > that constrained...] That means being able to have one SPI space for > tens of thousands of connections on a large aggregation box, and still > enough for a reasonable number of rekeys of those connections. > > Keep in mind, though, that IPsec was originally designed with > at least an eye towards multicast (even though we didn't claim to > understand the problem set much then...). > > In the case of multicast traffic, where separate key servers may be > controlling keys/SA assignment for different multicast sessions, > you'd have to come up with a mechanism to ensure that there are > (a) no collisions in SPI assignment across the possible universe of > key servers, (b) but still have reasonable randomness to the SPI > allocation (the phase 2 SPIs are used as additional randomness > in the key derivation), and (c) the SPI space per address is sufficiently > large enough for rekeying for some noticeable amount of time (because > of (b)). > > In fact, we came up with (dest addr, protocol, spi) mainly because of > multicast. But that was even before my time... > > thx - C > > > > =============================================== > > Cheryl Madson > Strategic Cryptographic Development; Systems & Solutions Engineering > Cisco Systems, Inc. > cmadson@cisco.com > From owner-ipsec@lists.tislabs.com Tue May 8 05:23: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 FAA19407; Tue, 8 May 2001 05:23:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21884 Tue, 8 May 2001 07:33:25 -0400 (EDT) Message-ID: <000601c0d744$cdcaecb0$adb12304@ffb5b> From: "jshukla" To: "Michael Thomas" Cc: References: <15094.53290.539696.864321@thomasm-u1.cisco.com><15094.59478.555839.354118@thomasm-u1.cisco.com><001801c0d740$d820f050$a4b12304@ffb5b> <15095.6818.322551.69375@thomasm-u1.cisco.com> Subject: Re: src addr/SPI coupling Date: Mon, 7 May 2001 15:26:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Michael Thomas" > > Now wait a minute. I thought the receiver chose > the SPI. If so, it owns that number space (modulo > Cheryl's comment about multicast), so there > shouldn't be collisions. If another sender tried > to use that SPI, it would imply that they have > keying material. > > Mike > SPI collision does not happen at the receiver, but at the sender. The receiver can ensure that the SPI does not conflict with another SPI in its database, but it cannot ensure that the sender has not chosen the same SPI for "another" SA. (because multiple key material map to the same SPI). regards, Jayant > jshukla writes: > > > > ----- Original Message ----- > > From: "Michael Thomas" > > > OK, that changes the sense of the problem, but not > > > the original question. Why does there need to be > > > any dependency on the destination address to > > > select the right SA? This still seems like it > > > > To make sure that SA is unique!? SPI is only > > 32 bits long and there is a finite chance of > > collision. > > > > SPI is chosen by the destination of > > SA who makes sure that it does not have two > > identical SPIs (it does not prevent the source > > from having the same SPI for another SA). > > The source of SA uses the destination > > address along with SPI to make sure that > > SA is unique (in the event there is a collision and > > the source ends up having two SAs that share > > a common SPI). > > > > > could run into trouble on the mobile node > > > incoming traffic if the destination address > > > were "wrong" (which is, I think, the way a > > > naive stack might view it.) > > > > > > Mike > > > > It will surely run into trouble. BTW, this > > problem is similar to the NAT problem. > > > > > > regards, > > Jayant > > From owner-ipsec@lists.tislabs.com Tue May 8 05:23: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 FAA19427; Tue, 8 May 2001 05:23:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21876 Tue, 8 May 2001 07:32:25 -0400 (EDT) Message-ID: <001801c0d740$d820f050$a4b12304@ffb5b> From: "jshukla" To: Cc: "Michael Thomas" References: <15094.53290.539696.864321@thomasm-u1.cisco.com> <15094.59478.555839.354118@thomasm-u1.cisco.com> Subject: Re: src addr/SPI coupling Date: Mon, 7 May 2001 14:58:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Michael Thomas" > OK, that changes the sense of the problem, but not > the original question. Why does there need to be > any dependency on the destination address to > select the right SA? This still seems like it To make sure that SA is unique!? SPI is only 32 bits long and there is a finite chance of collision. SPI is chosen by the destination of SA who makes sure that it does not have two identical SPIs (it does not prevent the source from having the same SPI for another SA). The source of SA uses the destination address along with SPI to make sure that SA is unique (in the event there is a collision and the source ends up having two SAs that share a common SPI). > could run into trouble on the mobile node > incoming traffic if the destination address > were "wrong" (which is, I think, the way a > naive stack might view it.) > > Mike It will surely run into trouble. BTW, this problem is similar to the NAT problem. regards, Jayant From owner-ipsec@lists.tislabs.com Tue May 8 14:28: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 OAA27890; Tue, 8 May 2001 14:28:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23648 Tue, 8 May 2001 16:15:28 -0400 (EDT) Message-ID: <002801c0d7fb$2e465be0$440105cf@vip.best.com> From: "Saqib Jang" To: Subject: Firewall/IPsec question Date: Tue, 8 May 2001 13:12:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C0D7C0.8105AF60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C0D7C0.8105AF60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had a question about tunnel-mode IPsec. Can the tunnel endpoints be separate (i.e. behind) firewalls? IN this case, what type of = configuration needs to happen on firewalls. Once the tunnel endpoints authenticate one = another and if encryption is not being used, are there security vulnerabilities = one needs to consider.=20 Thanks, Saqib ------=_NextPart_000_0025_01C0D7C0.8105AF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had a question about tunnel-mode IPsec. Can the = tunnel=20 endpoints be separate (i.e. behind) firewalls? IN this case, = what type=20 of configuration needs to happen on firewalls. Once the tunnel = endpoints=20 authenticate one another and if encryption is not being used, are there = security=20 vulnerabilities one needs to consider. Thanks, Saqib ------=_NextPart_000_0025_01C0D7C0.8105AF60-- From owner-ipsec@lists.tislabs.com Wed May 9 13:17: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 NAA13322; Wed, 9 May 2001 13:17:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26587 Wed, 9 May 2001 15:06:38 -0400 (EDT) Message-ID: <3AF99664.74B3F82C@lucent.com> Date: Wed, 09 May 2001 12:11:34 -0700 From: Emmanuel Hislen Organization: Lucent Technologies INS X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jshukla CC: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: src addr/SPI coupling References: <15094.53290.539696.864321@thomasm-u1.cisco.com><15094.59478.555839.354118@thomasm-u1.cisco.com><001801c0d740$d820f050$a4b12304@ffb5b> <15095.6818.322551.69375@thomasm-u1.cisco.com> <000601c0d744$cdcaecb0$adb12304@ffb5b> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On the outbound side we obviously need to keep track of both SPI and destination address, because we did not allocate the SPI. But it seems the only reason why we would need to keep track of an IP address along with the SPI on the inbound side is Multicast (or lack of SPI space). But even then why are we talking about "destination" address on the inbound side: we are always the destination of an inbound secured packet if we are the cryptographic endpoint, whether the packet is in transport or tunnel mode. So I think Michael was right when he first mentioned "Source" address. The RFC seems incorrect to me here, I mean for the Inbound case. RFC 2401, section 4.1: "A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier" Here destination means destination of the SA and this is absolutely correct. BUT, later on (section 4.4.1): " For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA." Why destination address??? We actually need no address at all here, and if we did it would be the Source one, not the Destination. The only case I can think of (where destination address could be useful) is a box with multiple IP interfaces, but this would be local implementation matter. Regards, Emmanuel. jshukla wrote: > ----- Original Message ----- > From: "Michael Thomas" > > > > > Now wait a minute. I thought the receiver chose > > the SPI. If so, it owns that number space (modulo > > Cheryl's comment about multicast), so there > > shouldn't be collisions. If another sender tried > > to use that SPI, it would imply that they have > > keying material. > > > > Mike > > > > SPI collision does not happen at the receiver, > but at the sender. The receiver can ensure > that the SPI does not conflict with another > SPI in its database, but it cannot ensure that > the sender has not chosen the same SPI for > "another" SA. (because multiple key material > map to the same SPI). > > regards, > Jayant > > jshukla writes: > > > > > > ----- Original Message ----- > > > From: "Michael Thomas" > > > > OK, that changes the sense of the problem, but not > > > > the original question. Why does there need to be > > > > any dependency on the destination address to > > > > select the right SA? This still seems like it > > > > > > To make sure that SA is unique!? SPI is only > > > 32 bits long and there is a finite chance of > > > collision. > > > > > > SPI is chosen by the destination of > > > SA who makes sure that it does not have two > > > identical SPIs (it does not prevent the source > > > from having the same SPI for another SA). > > > The source of SA uses the destination > > > address along with SPI to make sure that > > > SA is unique (in the event there is a collision and > > > the source ends up having two SAs that share > > > a common SPI). > > > > > > > could run into trouble on the mobile node > > > > incoming traffic if the destination address > > > > were "wrong" (which is, I think, the way a > > > > naive stack might view it.) > > > > > > > > Mike > > > > > > It will surely run into trouble. BTW, this > > > problem is similar to the NAT problem. > > > > > > > > > regards, > > > Jayant > > > From owner-ipsec@lists.tislabs.com Wed May 9 14:48: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 OAA20499; Wed, 9 May 2001 14:48:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26898 Wed, 9 May 2001 16:52:18 -0400 (EDT) Message-ID: <001501c0d8ca$83db13a0$63b02304@ffb5b> From: "jshukla" To: "Emmanuel Hislen" Cc: "Michael Thomas" , References: <15094.53290.539696.864321@thomasm-u1.cisco.com><15094.59478.555839.354118@thomasm-u1.cisco.com><001801c0d740$d820f050$a4b12304@ffb5b> <15095.6818.322551.69375@thomasm-u1.cisco.com> <000601c0d744$cdcaecb0$adb12304@ffb5b> <3AF99664.74B3F82C@lucent.com> Subject: Re: src addr/SPI coupling Date: Wed, 9 May 2001 13:56:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Emmanuel Hislen" > On the outbound side we obviously need to keep track of both SPI and > destination address, because we did not allocate the SPI. > right > > But it seems the only reason why we would need to keep track of an IP > address along with the SPI on the inbound side is Multicast (or lack of > SPI space). But even then why are we talking about "destination" address > on the inbound side: we are always the destination of an inbound secured > packet if we are the cryptographic endpoint, whether the packet is in > transport or tunnel mode. > > So I think Michael was right when he first mentioned "Source" address. > The RFC seems incorrect to me here, I mean for the Inbound case. > > RFC 2401, section 4.1: > "A security association is uniquely identified by a triple consisting > of a Security Parameter Index (SPI), an IP Destination Address, and a > > security protocol (AH or ESP) identifier" > > Here destination means destination of the SA and this is absolutely > correct. > > BUT, later on (section 4.4.1): > " For an inbound IPsec packet for which multiple IPsec SAs are to be > applied, the lookup based on destination address, IPsec protocol, and > > SPI should identify a single SA." > > Why destination address??? We actually need no address at all here, and > if we did it would be the Source one, not the Destination. > The only case I can think of (where destination address could be useful) > is a box with multiple IP interfaces, but this would be local > implementation matter. > Consider three entities A, B, and C. "A" initiates a multicast session M1, selects SPI sp1. It is entirely possible that "B" might select the same SPI sp1 for another multicast sessions M2. If you use SPI and source address, you can see the problem easily. Whenever "B" sends a message, "C" sees an ambiguity and cannot pick the right SA based on source address and SPI alone. He has two SA's that now qualify, one corresponding to the multicast session M1 and other corresponding to the session M2. Only way for "C" to pick the correct SA is to determine if the message corresponds to multicast session M1 or M2. It does so by using the destination address. I guess what you did not consider is that other nodes can also send messages in a multicast session. > > Regards, > > Emmanuel. > regards, Jayant From owner-ipsec@lists.tislabs.com Wed May 9 14:53: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 OAA21456; Wed, 9 May 2001 14:53:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26921 Wed, 9 May 2001 17:06:37 -0400 (EDT) Reply-To: From: "Davenport Michael" To: Subject: IPSec and PEPs Date: Wed, 9 May 2001 17:11:20 -0400 Message-ID: <003b01c0d8cc$9897ff40$8947509c@BAH.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To all, I am new to the group and I have a direct question that maybe someone could help me resolve. We are looking into Performance Enhancing Proxies designed for the network layer (TCP to be more specific) but are skeptical on how that would effect IPSec. To further clarify, I want to know if there has been any testing with PEPs over TCP/IP Security Devices. Any information you can provide would be greatful... Michael From owner-ipsec@lists.tislabs.com Wed May 9 19:19: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 TAA04969; Wed, 9 May 2001 19:19:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27425 Wed, 9 May 2001 21:19:16 -0400 (EDT) Message-ID: <3AF9ED8B.C3412878@hns.com> Date: Wed, 09 May 2001 21:23:23 -0400 From: borderlt X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: davenport_michael@bah.com CC: ipsec@lists.tislabs.com Subject: Re: IPSec and PEPs References: <003b01c0d8cc$9897ff40$8947509c@BAH.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The PILC PEP document includes sections on this topic... http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-07.txt John Davenport Michael wrote: > > To all, > > I am new to the group and I have a direct question that maybe someone could > help me resolve. We are looking into Performance Enhancing Proxies designed > for the network layer (TCP to be more specific) but are skeptical on how > that would effect IPSec. To further clarify, I want to know if there has > been any testing with PEPs over TCP/IP Security Devices. Any information > you can provide would be greatful... > > Michael From owner-ipsec@lists.tislabs.com Thu May 10 06:04: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 GAA25024; Thu, 10 May 2001 06:04:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28601 Thu, 10 May 2001 07:40:52 -0400 (EDT) Message-Id: <200105100214.f4A2E0n04318@road.xisp.net> To: ipsec@lists.tislabs.com Cc: gnu@toad.com Subject: Finland/Helsinki Bakeoff in August Reply-To: hugh@xisp.net Date: Wed, 09 May 2001 19:14:00 -0700 From: Hugh Daniel Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- There have been a few questions of who is going and what would be tested, so for us: The FreeS/WAN Project is currently planning on attending the August 13-18 IPsec BakeOff in Helsinki. We intend to have a new code base for our Kernel half and intend to be showing our idea of 'Opportunistic' encryption with DNSsec and IKE for IPsec. We also hope to be doing IPv6 and maybe even (depending on volunteer effort) the X.509 crud (what, me biased?). While I think that we need more bakeoffs after this one, I suspect that this will be the last one, so we intend to work quite hard in preparation for it. I would love to see a website show up with info and instructions on how to lay down our money and in general commit to participating. ||ugh Daniel hugh@freeswan.org Systems Testing & Project mis-Management The Linux FreeS/WAN Project http://www.freeswan.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: For the matching public key, finger the Reply-To: address. iQCVAwUBOvn5MlZpdJR7FBQRAQHTIgP/Ww177xEwagnGchHl3tHZSZ6TzK9mSZiN gTKvyzhppMsM6rbJuU5RNAKcyOzQyNYWzRA5jK8iHzbAdG1oQpogYcKvJJPRKURp o8cSsXAW1D/sCHTOhjyLPU5zMFAjbna0OEsYtLuQEyIXoNdvI2yN56Pr95+gQ963 OciQI2lguzg= =6oGV -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri May 11 09:53: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 JAA03359; Fri, 11 May 2001 09:53:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02207 Fri, 11 May 2001 09:34:07 -0400 (EDT) Message-ID: <0F5098A8968AD411A6EF00508BDF763502FE1872@efijont100> From: "Matti Enqvist (LMF)" To: "'ipsec@lists.tislabs.com'" Cc: "Esa Turtiainen (LMF)" , =?iso-8859-1?Q?P=E4ivi_Saarela_=28LMF=29?= , "Terttu Walther (LMF)" Subject: IPsec Interoperability Workshop Date: Fri, 11 May 2001 15:21:03 +0200 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 On behalf of the organisers I'd like to inform as follows: The next IPsec Interoperability workshop a.k.a Bakeoff will be held in Finland from August 13 thru 19 (Monday - Saturday). This is the week following the IETF meeting in London, so you may combine your travelling. The venue will be Dipoli (http://www.dipoli.hut.fi/english/) in Espoo (close to Helsinki) in the Helsinki University of Technology campus area. Flight destination will be Helsinki (Helsinki-Vantaa international airport - about 3 hour flight from London), the Bakeoff venue is under 30 minute (20 km) drive south-west from the airport, 10 km (6 miles) from downtown Helsinki. The event will start on Monday afternoon i.e. the participants may start installing their equipment then. The final day is Saturday, all equipment must be removed Saturday afternoon. There will be no storage space available before the bakeoff, therefore, you will have to schedule arrival of your equipment to Monday afternoon. The nearest hotel is Radisson SAS Espoo (http://www.hotelsfinland.com/espoo/rivoli_espoo/) only two minutes walk from Dipoli. We have reserved some 100 rooms for bakeoff attendees. If you book your hotel room at this hotel through your own channels already before registering, please, mention Bakeoff when making the reservation. Other hotels are available in Helsinki, next closest is probably Kalastajatorppa (http://www.scandic-hotels.com/br/50/hotel.asp?id=107) about 4 km (2.5 miles) from Dipoli. We shall publish web pages shortly - in about two weeks time with more information and registration. I hope this short note will help you in booking your flights. Matti Enqvist, Section Manager, Design & Verification, Mobile Networks Security, Oy L M Ericsson Ab, FIN-02420 Jorvas, tel. +358 9 299 3058 private web www.enqvist.com private mail matti@enqvist.com From owner-ipsec@lists.tislabs.com Fri May 11 17:18: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 RAA26012; Fri, 11 May 2001 17:18:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04143 Fri, 11 May 2001 18:30:43 -0400 (EDT) Date: Fri, 11 May 2001 15:33:46 -0700 (PDT) From: Geoffrey Huang To: Subject: New draft on Dead Peer Detection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello there, I just wanted to direct your attention to a draft: "A Traffic-Based Method of Detecting Dead IKE Peers". It's available at: http://search.ietf.org/internet-drafts/draft-huang-dpd-00.txt Here's the abstract: This draft describes a method of detecting a dead IKE peer. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to limit the number of IKE messages sent. DPD, like other keepalive mechanisms, is often necessary to perform IKE peer failover, or to reclaim lost resources. -g From owner-ipsec@lists.tislabs.com Mon May 14 07:02: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 HAA10457; Mon, 14 May 2001 07:02:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11114 Mon, 14 May 2001 08:43:39 -0400 (EDT) Message-ID: <8B204D152222D51182B700010288413720242E@postmaster.cryptek.com> From: David Aronson To: ipsec@lists.tislabs.com Subject: RE: New draft on Dead Peer Detection Date: Mon, 14 May 2001 09:08:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re $SUBJECT: this one is too easy. Make your own joke here, folks.... B-) From owner-ipsec@lists.tislabs.com Mon May 14 09:33: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 JAA24625; Mon, 14 May 2001 09:33:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11711 Mon, 14 May 2001 11:30:44 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: src addr/SPI coupling Date: Sun, 13 May 2001 03:33:47 -0400 Message-Id: <000701c0dc8a$85b9ae70$1e31788a@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 In-reply-to: <5.0.2.1.2.20010507125015.08475008@mira-sjcm-2.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In the case of multicast traffic, where separate key servers may be > controlling keys/SA assignment for different multicast sessions, > you'd have to come up with a mechanism to ensure that there are > (a) no collisions in SPI assignment across the possible universe of > key servers, (b) but still have reasonable randomness to the SPI > allocation (the phase 2 SPIs are used as additional randomness > in the key derivation), and (c) the SPI space per address is > sufficiently > large enough for rekeying for some noticeable amount of time (because > of (b)). Are (b) and (c) really a problem? The entropy provided by the SPIs is only needed to provide distinct keymat for multiple SAs in the same packet, right? A counter in the key derivation would serve the same purpose. 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 Cheryl Madson > Sent: Monday, May 07, 2001 4:07 PM > To: Michael Thomas > Cc: Jan Vilhuber; Michael Thomas; ipsec@lists.tislabs.com > Subject: Re: src addr/SPI coupling > > > At 11:24 AM 5/7/2001, Michael Thomas wrote: > >Jan Vilhuber writes: > > > Actually, section 4.1 from rfc 2401 states: > > > > > > A security association is uniquely identified by a > triple consisting > > > of a Security Parameter Index (SPI), an IP > Destination Address, and a > > > security protocol (AH or ESP) identifier. [...] > > > > > > It's not the source address. > > > > OK, that changes the sense of the problem, but not > > the original question. Why does there need to be > > any dependency on the destination address to > > select the right SA? This still seems like it > > could run into trouble on the mobile node > > incoming traffic if the destination address > > were "wrong" (which is, I think, the way a > > naive stack might view it.) > > > > Mike > > In the case of unicast traffic, one could argue that given a > sufficiently large > SPI space, that there might not be a need to have it on a > per-destination > address per box. That's assuming the IKE deamon(s) are all coordinated > across the box. [Yes, there's normally one, but it probably > shouldn't be > that constrained...] That means being able to have one SPI space for > tens of thousands of connections on a large aggregation box, and still > enough for a reasonable number of rekeys of those connections. > > Keep in mind, though, that IPsec was originally designed with > at least an eye towards multicast (even though we didn't claim to > understand the problem set much then...). > > In the case of multicast traffic, where separate key servers may be > controlling keys/SA assignment for different multicast sessions, > you'd have to come up with a mechanism to ensure that there are > (a) no collisions in SPI assignment across the possible universe of > key servers, (b) but still have reasonable randomness to the SPI > allocation (the phase 2 SPIs are used as additional randomness > in the key derivation), and (c) the SPI space per address is > sufficiently > large enough for rekeying for some noticeable amount of time (because > of (b)). > > In fact, we came up with (dest addr, protocol, spi) mainly because of > multicast. But that was even before my time... > > thx - C > > > > =============================================== > > Cheryl Madson > Strategic Cryptographic Development; Systems & Solutions Engineering > Cisco Systems, Inc. > cmadson@cisco.com > > From owner-ipsec@lists.tislabs.com Mon May 14 12: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 MAA02597; Mon, 14 May 2001 12:16:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12086 Mon, 14 May 2001 13:49:43 -0400 (EDT) Message-Id: <200105141754.f4EHsTC15623@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: ipsec@lists.tislabs.com Subject: Re: src addr/SPI coupling In-reply-to: Your message of "Sun, 13 May 2001 03:33:47 EDT." <000701c0dc8a$85b9ae70$1e31788a@andrewk3.ca.newbridge.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 14 May 2001 13:54:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Are (b) and (c) really a problem? The entropy provided by the SPIs is only > needed to provide distinct keymat for multiple SAs in the same packet, > right? A counter in the key derivation would serve the same purpose. One reason for random SPI's is to make it harder for an off-path attacker to flood you with with packets with valid spi's which must be decrypted before they can be discarded. - Bill From owner-ipsec@lists.tislabs.com Mon May 14 19:57: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 TAA27093; Mon, 14 May 2001 19:57:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13287 Mon, 14 May 2001 21:57:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <000701c0dc8a$85b9ae70$1e31788a@andrewk3.ca.newbridge.com> References: <000701c0dc8a$85b9ae70$1e31788a@andrewk3.ca.newbridge.com> Date: Mon, 14 May 2001 17:31:33 -0400 To: From: Stephen Kent Subject: RE: src addr/SPI coupling Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:33 AM -0400 5/13/01, Andrew Krywaniuk wrote: > > In the case of multicast traffic, where separate key servers may be >> controlling keys/SA assignment for different multicast sessions, >> you'd have to come up with a mechanism to ensure that there are >> (a) no collisions in SPI assignment across the possible universe of >> key servers, (b) but still have reasonable randomness to the SPI >> allocation (the phase 2 SPIs are used as additional randomness >> in the key derivation), and (c) the SPI space per address is >> sufficiently >> large enough for rekeying for some noticeable amount of time (because >> of (b)). > >Are (b) and (c) really a problem? The entropy provided by the SPIs is only >needed to provide distinct keymat for multiple SAs in the same packet, >right? A counter in the key derivation would serve the same purpose. > There is no security requirement, re key material derivation, for SPIs to be "random." There is some benefit for DoS purposes to have them be hard to predict, but RFC 2401 does not mandate randomness. It merely requires local uniqueness, for demuxing. steve From owner-ipsec@lists.tislabs.com Wed May 16 06:15: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 GAA27120; Wed, 16 May 2001 06:15:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18268 Wed, 16 May 2001 08:02:06 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: To: ipsec@lists.tislabs.com Subject: CR format in IKE Date: Wed, 16 May 2001 15:07:17 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could someone tell me if this is correct? In an IKE negotiation using RSA-signatures: When sending a CR the payload contains the Subject name of the CA in used and it's sent in its binary format (ASN.1 representation) When receiving it, it must match the Issuer name of the certificate to be sent. Is there any error in this? Tonino From owner-ipsec@lists.tislabs.com Wed May 16 06:15: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 GAA27140; Wed, 16 May 2001 06:15:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18278 Wed, 16 May 2001 08:04:46 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: To: ipsec@lists.tislabs.com Subject: ID payload in IKE phase I Date: Wed, 16 May 2001 15:09:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Even though the RFC 2409 says that the ID field is compulsory in all modes, is there any problem in assuming that if not received it defaults to the IP address of the peer host? It would be the same as if receiving the ayload with the IP address. Toni -----Original Message----- From: Barrera Antonio (NET/Barcelona) Sent: 16. May 2001 15:07 To: 'ipsec@lists.tislabs.com' Subject: CR format in IKE Could someone tell me if this is correct? In an IKE negotiation using RSA-signatures: When sending a CR the payload contains the Subject name of the CA in used and it's sent in its binary format (ASN.1 representation) When receiving it, it must match the Issuer name of the certificate to be sent. Is there any error in this? Tonino From owner-ipsec@lists.tislabs.com Fri May 18 06:02: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 GAA28102; Fri, 18 May 2001 06:02:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26381 Fri, 18 May 2001 07:55:18 -0400 (EDT) Message-ID: <3B050EE1.91ADA25@lmf.ericsson.se> Date: Fri, 18 May 2001 15:00:33 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: jarkko@piuha.net Subject: AES, AES-MAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I need some clarification on the current status of the new AES algorithm in the context of the IPsec standards. Am I correct in assuming the following: - There are IANA numbers for the use of AES both in IPsec and IKE - There is a draft on the use of AES (including losing candidates) in IPsec. Implementing these is quite straightforward and lots folks have implementations, including us. But what is unclear to me is the following: - Is there a need for 'use of AES in IKE' document? - What is the standards process: when do these algorithms find their way to RFCs, or is it enough with the IANA reservations and the NIST standards? In particular, when can other groups and vendors refer to the use of AES within IPsec in some way other than through working documents? - I believe it is possible to use AES as a MAC algorithm a la DES-MAC. Has this been specified by NIST? Has it been specified by IETF how to use it in the context of IPsec? - I seem to remember talk about SHA-256/384/512. What are these and have their use been specified for IPsec? What is their relationship to AES-MAC? Thanks, Jari From owner-ipsec@lists.tislabs.com Fri May 18 11:31: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 LAA14247; Fri, 18 May 2001 11:31:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27107 Fri, 18 May 2001 13:11:44 -0400 (EDT) From: "Joseph D. Harwood" To: "Ipsec" Cc: Subject: Re: AES, AES-MAC Date: Fri, 18 May 2001 10:19:41 -0700 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 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >- I believe it is possible to use AES as > a MAC algorithm a la DES-MAC. Has this > been specified by NIST? Has it been specified > by IETF how to use it in the context of IPsec? > >- I seem to remember talk about SHA-256/384/512. > What are these and have their use been > specified for IPsec? What is their relationship > to AES-MAC? The thread on SHA-256/384/512 can be found here: http://www.vpnc.org/ietf-ipsec/mail-archive/msg00337.html These are hash algorithms from NIST with 256/384/512 bits of output. From the thread above I don't believe they are going to be a requirement for IPsec because of their performance. AES-MAC was also discussed in this thread. It's performance is roughly that of AES-CBC encryption/decryption. However, there has been discussion of using a counter mode for AES encryption/decryption rather than CBC mode to improve encryption/decryption performance, so perhaps something other than a straight AES-MAC would be needed for equivalent authentication performance. Please see the following message, which contains the slides from Steve Kent's presentation that discuss this: http://www.vpnc.org/ietf-ipsec/mail-archive/msg00168.html Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com From owner-ipsec@lists.tislabs.com Fri May 18 12:32: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 MAA16800; Fri, 18 May 2001 12:32:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27397 Fri, 18 May 2001 14:37:00 -0400 (EDT) Message-ID: <75A3CEA84682D311AAC70008C791823276B7A2@zbl6c016.corpeast.baynetworks.com> From: "Jerome Freedman Jr" To: "'ipsec@lists.tislabs.com'" Cc: "Jay Xiong" Subject: IKE Rekeying Date: Fri, 18 May 2001 11:41:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DFCA.25AC71A0" 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_01C0DFCA.25AC71A0 Content-Type: text/plain; charset="iso-8859-1" Hi, Has anyone done any work on IKE rekeying? Are there any drafts? Anybody want to write one? Jerry Freedman,Jr ------_=_NextPart_001_01C0DFCA.25AC71A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IKE Rekeying

Hi,

   Has anyone done any work = on IKE rekeying? Are there any drafts? Anybody want to write = one?


Jerry Freedman,Jr

 

------_=_NextPart_001_01C0DFCA.25AC71A0-- From owner-ipsec@lists.tislabs.com Fri May 18 14:03: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 OAA23650; Fri, 18 May 2001 14:03:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27622 Fri, 18 May 2001 16:14:21 -0400 (EDT) Message-ID: <01c601c0dfd7$d6e68c50$6501a8c0@cisco.com> From: "Stephane Beaulieu" To: "Jerome Freedman Jr" , Cc: "Jay Xiong" References: <75A3CEA84682D311AAC70008C791823276B7A2@zbl6c016.corpeast.baynetworks.com> Subject: Re: IKE Rekeying Date: Fri, 18 May 2001 16:19:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C3_01C0DFB6.4F348DA0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_01C3_01C0DFB6.4F348DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IKE RekeyingThere was a draft written by Tim Jenkins before he retired = from IPsec ;) ( I know you still monitor the lists though Tim :) There was a lack of consensus in the typical IPsec fashion with 1 or 2 = very loud voices against it (particularly his concept of Continuous = Channel), and Tim gave up on it when he left TimeStep. It has a lot of = very good, very detailed analysis. There was definitely more agreement = with his phase 2 rekeying analysis than his phase 1 rekeying analysis, = in case that's what you were looking for. Some people comply with this expired draft, and some don't. So don't = assume interoperability if you implement it. But it is definitely worth = reading if you have rekeying decisions to make. I'll send a copy to you in a private email. Stephane. ----- Original Message -----=20 From: Jerome Freedman Jr=20 To: 'ipsec@lists.tislabs.com'=20 Cc: Jay Xiong=20 Sent: Friday, May 18, 2001 2:41 PM Subject: IKE Rekeying Hi,=20 Has anyone done any work on IKE rekeying? Are there any drafts? = Anybody want to write one?=20 Jerry Freedman,Jr=20 =20 ------=_NextPart_000_01C3_01C0DFB6.4F348DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IKE Rekeying
There was a draft written by Tim = Jenkins before he=20 retired from IPsec ;)  ( I know you still monitor the lists though = Tim=20 :)
 
There was a lack of consensus in the = typical IPsec=20 fashion with 1 or 2 very loud voices against it (particularly his = concept of=20 Continuous Channel), and Tim gave up on it when he left TimeStep.  = It has a=20 lot of very good, very detailed analysis.  There was definitely = more=20 agreement with his phase 2 rekeying analysis than his phase 1 rekeying = analysis,=20 in case that's what you were looking for.
 
Some people comply with this expired = draft, and=20 some don't.  So don't assume interoperability if you implement = it. =20 But it is definitely worth reading if you have rekeying decisions to=20 make.
 
I'll send a copy to you in a private=20 email.
 
Stephane.
----- Original Message -----
From:=20 Jerome Freedman Jr
To: 'ipsec@lists.tislabs.com'
Cc: Jay=20 Xiong
Sent: Friday, May 18, 2001 2:41 = PM
Subject: IKE Rekeying


Hi,

   Has anyone done any work = on IKE=20 rekeying? Are there any drafts? Anybody want to write one? =


Jerry Freedman,Jr

  =

------=_NextPart_000_01C3_01C0DFB6.4F348DA0-- From owner-ipsec@lists.tislabs.com Mon May 21 10:02:40 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 KAA11322; Mon, 21 May 2001 10:02:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03724 Mon, 21 May 2001 11:35:08 -0400 (EDT) Subject: Re: AES, AES-MAC To: "Joseph D. Harwood" , ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Palmatier" Date: Mon, 21 May 2001 11:39:21 -0400 X-MIMETrack: Serialize by Router on d27ml103/27/M/IBM(Release 5.0.7 |March 21, 2001) at 05/21/2001 10:39:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If AES-128 is being used as an encryption algorithm by IKE (or IPsec later), and IKE is generating the keys for it like it normally does, then doesn't IKE need a hash algorithm of size 256 bits or greater to create secure keys that are reasonably safe from collisions? I was under the impression that for IKE to use AES-128 it would need a hash algorithm that produced an output of at least 256 bits to be secure. If I'm misguided here can someone let me know what the alternative is? Jason Jason Palmatier IP Software Development IBM iSeries eServer Endicott, NY email: palmatie@us.ibm.com "Joseph D. Harwood" p.com> cc: Sent by: Subject: Re: AES, AES-MAC owner-ipsec@lists.t islabs.com 05/18/2001 01:19 PM >- I believe it is possible to use AES as > a MAC algorithm a la DES-MAC. Has this > been specified by NIST? Has it been specified > by IETF how to use it in the context of IPsec? > >- I seem to remember talk about SHA-256/384/512. > What are these and have their use been > specified for IPsec? What is their relationship > to AES-MAC? The thread on SHA-256/384/512 can be found here: http://www.vpnc.org/ietf-ipsec/mail-archive/msg00337.html These are hash algorithms from NIST with 256/384/512 bits of output. From the thread above I don't believe they are going to be a requirement for IPsec because of their performance. AES-MAC was also discussed in this thread. It's performance is roughly that of AES-CBC encryption/decryption. However, there has been discussion of using a counter mode for AES encryption/decryption rather than CBC mode to improve encryption/decryption performance, so perhaps something other than a straight AES-MAC would be needed for equivalent authentication performance. Please see the following message, which contains the slides from Steve Kent's presentation that discuss this: http://www.vpnc.org/ietf-ipsec/mail-archive/msg00168.html Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com From owner-ipsec@lists.tislabs.com Mon May 21 13:31: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 NAA20456; Mon, 21 May 2001 13:31:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04254 Mon, 21 May 2001 15:34:31 -0400 (EDT) Date: Mon, 21 May 2001 12:39:21 -0700 (PDT) From: Scott Fluhrer To: Jason Palmatier cc: "Joseph D. Harwood" , Subject: Re: AES, AES-MAC 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 Mon, 21 May 2001, Jason Palmatier wrote: > > If AES-128 is being used as an encryption algorithm by IKE (or IPsec > later), and IKE is generating the keys for it like it normally does, then > doesn't IKE need a hash algorithm of size 256 bits or greater to create > secure keys that are reasonably safe from collisions? Not really. When generating the SKEYID_*, IKE really doesn't care about collision attacks (finding two distinct preimages that happen to hash to the same value). The attacker does not get the choose the values to be hashed -- if he did, he'd be better off choosing values that gave a known SKEYID, and using that. The attacker could wade through 2**64 distinct sessions, and hope to find a pair with the same (say) SKEYID_e (leaving aside the questions of how he would recognize such a pair, and how he could exploit it) but that same attack could be used against just about any memoryless method of generating 128 bit AES keys, so that is not an additional weakness. > I was under the > impression that for IKE to use AES-128 it would need a hash algorithm that > produced an output of at least 256 bits to be secure. If I'm misguided > here can someone let me know what the alternative is? Because the SKEYID_e value is used to generate the encryption key, the real restriction on prf length is that if you use a prf with a length of n bits, then that IKE/IPSec session can be broken with no more than O(2**n) effort. This implies that (for example) using AES-256 with HMAC-MD5 is silly, because the extra key bits in AES-256 give you no additional strength. However, using HMAC-MD5 with AES-128 does not add such an additional weakness -- the attacker can cycle through all possible 2**128 SKEYID_e values with O(2**128) effort, but then he can cycle through all possible AES-128 keys with the same work factor, so that doesn't buy the attacker anything. > > Jason > > Jason Palmatier > IP Software Development > IBM iSeries eServer > Endicott, NY > email: palmatie@us.ibm.com > > > > > > "Joseph D. Harwood" > > p.com> cc: > Sent by: Subject: Re: AES, AES-MAC > owner-ipsec@lists.t > islabs.com > > > 05/18/2001 01:19 PM > > > > > > > >- I believe it is possible to use AES as > > a MAC algorithm a la DES-MAC. Has this > > been specified by NIST? Has it been specified > > by IETF how to use it in the context of IPsec? > > > >- I seem to remember talk about SHA-256/384/512. > > What are these and have their use been > > specified for IPsec? What is their relationship > > to AES-MAC? > > The thread on SHA-256/384/512 can be found here: > > http://www.vpnc.org/ietf-ipsec/mail-archive/msg00337.html > > These are hash algorithms from NIST with 256/384/512 bits of output. From > the thread above I don't believe they are going to be a requirement for > IPsec because of their performance. AES-MAC was also discussed in this > thread. It's performance is roughly that of AES-CBC encryption/decryption. > However, there has been discussion of using a counter mode for AES > encryption/decryption rather than CBC mode to improve encryption/decryption > performance, so perhaps something other than a straight AES-MAC would be > needed for equivalent authentication performance. Please see the following > message, which contains the slides from Steve Kent's presentation that > discuss this: > > http://www.vpnc.org/ietf-ipsec/mail-archive/msg00168.html > > Best Regards, > Joseph D. Harwood > jharwood@vesta-corp.com > www.vesta-corp.com > > > > > > From owner-ipsec@lists.tislabs.com Mon May 21 19:49: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 TAA11177; Mon, 21 May 2001 19:49:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04926 Mon, 21 May 2001 21:36:06 -0400 (EDT) content-class: urn:content-classes:message Subject: NAT traversal clarification? Date: Mon, 21 May 2001 18:41:28 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E010AB1@TNEXVS02.tahoenetworks.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: NAT traversal clarification? Thread-Index: AcDiYFIT70nXuxrtQLa9DvHc1bCosg== From: "Ly Loi" To: X-OriginalArrivalTime: 22 May 2001 01:41:28.0983 (UTC) FILETIME=[522D9270:01C0E260] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, draft-huttunen-ipsec-esp-in-udp-01.txt, section 5 "IPSec over NAT Operation" has the following: It hits the NAT, and the NAT translates the src address, and source portcreates an entry for the SPI. When the reply comes back from X, the NAT maps the SPI from X with the SPI send from A. Now the NAT knows which internal host to send the packet to, and A gets it. Assuming that the text meant to say "... source port, and creates an entry ...", I'm not sure I understand why we're referring to the SPI here or how it's being used for the following reasons: 1. the outgoing SA spi differs from the incoming SA spi, so if a spi entry was created based on an outgoing pkt, this spi entry can't be used to process an incoming pkt. 2. having NAT look at the spi field violates the requirement that says NAT should be unaware of IPSEC (or may be I misunderstood the requirement?) 3. why is the spi needed here to map a pkt to an internal host? isn't the port mapping sufficient? Thanks, - Ly From owner-ipsec@lists.tislabs.com Tue May 22 09:25: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 JAA21145; Tue, 22 May 2001 09:25:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06578 Tue, 22 May 2001 11:11:35 -0400 (EDT) Message-ID: <3B0A82D6.C10BFF93@F-Secure.com> Date: Tue, 22 May 2001 18:16:38 +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: Ly Loi CC: ipsec@lists.tislabs.com Subject: Re: NAT traversal clarification? References: <416B5AF360DED54088DAD3CA8BFBEA6E010AB1@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You shouldn't spend too much time reading this draft. We're hoping to have the combined draft(s) out soon. ('We' includes SSH Communications.) The section where this sentence is, is most confusing, but the likely intent is that the NAT box in this case is the GW, thus it's concerned with SPIs. The current draft or the new one does not require any specific handling by a NAT box. Ari Ly Loi wrote: > > Hi, draft-huttunen-ipsec-esp-in-udp-01.txt, section 5 "IPSec over NAT > Operation" has the following: > It hits the NAT, and the NAT translates the src address, and source > portcreates an entry for the SPI. When the reply comes back from X, the > NAT maps the SPI from X with the SPI send from A. Now the NAT knows > which internal host to send the packet to, and A gets it. > Assuming that the text meant to say "... source port, and creates an > entry ...", I'm not sure I understand why we're referring to the SPI > here or how it's being used for the following reasons: > 1. the outgoing SA spi differs from the incoming SA spi, so if a spi > entry was created based on an outgoing pkt, this spi entry can't be used > to process an incoming pkt. > 2. having NAT look at the spi field violates the requirement that says > NAT should be unaware of IPSEC (or may be I misunderstood the > requirement?) > 3. why is the spi needed here to map a pkt to an internal host? isn't > the port mapping sufficient? > Thanks, > - Ly -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Tue May 22 16:48: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 QAA15427; Tue, 22 May 2001 16:48:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07509 Tue, 22 May 2001 18:36:59 -0400 (EDT) From: "Geoffrey Huang" To: "Ari Huttunen" , "Ly Loi" Cc: Subject: RE: NAT traversal clarification? Date: Tue, 22 May 2001 15:44:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B0A82D6.C10BFF93@F-Secure.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > You shouldn't spend too much time reading this draft. We're hoping to > have the combined draft(s) out soon. ('We' includes SSH Communications.) Speaking of which -- can you guess an approximate date? (1 month, 2 months...?) -g > The section where this sentence is, is most confusing, but the > likely intent > is that the NAT box in this case is the GW, thus it's concerned with SPIs. > The current draft or the new one does not require any specific handling > by a NAT box. > > Ari > > Ly Loi wrote: > > > > Hi, draft-huttunen-ipsec-esp-in-udp-01.txt, section 5 "IPSec over NAT > > Operation" has the following: > > It hits the NAT, and the NAT translates the src address, and source > > portcreates an entry for the SPI. When the reply comes back from X, the > > NAT maps the SPI from X with the SPI send from A. Now the NAT knows > > which internal host to send the packet to, and A gets it. > > Assuming that the text meant to say "... source port, and creates an > > entry ...", I'm not sure I understand why we're referring to the SPI > > here or how it's being used for the following reasons: > > 1. the outgoing SA spi differs from the incoming SA spi, so if a spi > > entry was created based on an outgoing pkt, this spi entry can't be used > > to process an incoming pkt. > > 2. having NAT look at the spi field violates the requirement that says > > NAT should be unaware of IPSEC (or may be I misunderstood the > > requirement?) > > 3. why is the spi needed here to map a pkt to an internal host? isn't > > the port mapping sufficient? > > Thanks, > > - Ly > > -- > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F(ully)-Secure products: Integrated Solutions for Enterprise Security > From owner-ipsec@lists.tislabs.com Wed May 23 07:16: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 HAA20651; Wed, 23 May 2001 07:16:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09325 Wed, 23 May 2001 09:05:38 -0400 (EDT) Reply-To: From: "Jayashree J" To: Subject: IPSec over L2TP tunnels for Remote users Date: Wed, 23 May 2001 18:41:32 +0530 Message-Id: <001601c0e389$e3d6be20$0b02060a@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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have some questions in implementing IPSec over L2TP for a security gateway in case of a Remote User Access. 1) Has anyone done interop with Windows 2000 as a Remote Client? 2) It seems Windows 2000 operates only in transport mode for L2TP with IPSec( in remote user scenario). Is it necessary to supprot transport mode also in a security gateway to interop with Windows server? 3) In the above case how does Windows 2000 handle dynamic address received from PPP negotiations (is it as per the draft-ietf-l2tpext-security-02.txt>)? Thanks, Jayashree From owner-ipsec@lists.tislabs.com Wed May 23 07:24: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 HAA21921; Wed, 23 May 2001 07:24:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09392 Wed, 23 May 2001 09:30:53 -0400 (EDT) Message-ID: <75A3CEA84682D311AAC70008C791823276B7BF@zbl6c016.corpeast.baynetworks.com> From: "Jerome Freedman Jr" To: ipsec@lists.tislabs.com Subject: problems accessing the archives Date: Wed, 23 May 2001 06:35:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E38D.3AF0D710" 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_01C0E38D.3AF0D710 Content-Type: text/plain; charset="iso-8859-1" I am trying to look in the archives for discussions of IKE rekeying which, from Tim Jenkins' document ( thank you Stephane), was last year around this time. From the IETF page the ftp://ftp.tis.com/pub/lists/ipsec doesn't work and the other link ftp.ans.net/pub/archive/ipsec only goes up to 1996. Can anyone help me out? J. Freedman,Jr ------_=_NextPart_001_01C0E38D.3AF0D710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable problems accessing the archives

I am trying to look in the archives = for discussions of IKE rekeying which, from Tim Jenkins' document ( = thank you Stephane), was last year around this time. From the IETF page = the ftp://ftp.tis.com/pub/lists/ipsec doesn't work = and the other link ftp.ans.net/pub/archive/ipsec only goes up to 1996. = Can anyone help me out?


J. Freedman,Jr

 


------_=_NextPart_001_01C0E38D.3AF0D710-- From owner-ipsec@lists.tislabs.com Wed May 23 09:52: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 JAA04778; Wed, 23 May 2001 09:51:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09729 Wed, 23 May 2001 11:52:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <75A3CEA84682D311AAC70008C791823276B7BF@zbl6c016.corpeast.baynetworks.com> References: <75A3CEA84682D311AAC70008C791823276B7BF@zbl6c016.corpeast.baynetworks.com> Date: Wed, 23 May 2001 08:55:09 -0700 To: "Jerome Freedman Jr" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: problems accessing the archives Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:35 AM -0700 5/23/01, Jerome Freedman Jr wrote: >I am trying to look in the archives for discussions of IKE rekeying >which, from Tim Jenkins' document ( thank you Stephane), was last >year around this time. From the IETF page the >ftp://ftp.tis.com/pub/lists/ipsec >doesn't work and the other link ftp.ans.net/pub/archive/ipsec only >goes up to 1996. Can anyone help me out? VPNC keeps an unofficial archive at . --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed May 23 09:52: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 JAA04799; Wed, 23 May 2001 09:52:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09693 Wed, 23 May 2001 11:39:46 -0400 (EDT) From: "Joseph D. Harwood" To: "Jerome Freedman Jr" , Subject: RE: problems accessing the archives Date: Wed, 23 May 2001 08:46:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C0E364.D725FE40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <75A3CEA84682D311AAC70008C791823276B7BF@zbl6c016.corpeast.baynetworks.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_000E_01C0E364.D725FE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit problems accessing the archivesThe archives are also at 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 Jerome Freedman Jr Sent: Wednesday, May 23, 2001 6:35 AM To: ipsec@lists.tislabs.com Subject: problems accessing the archives I am trying to look in the archives for discussions of IKE rekeying which, from Tim Jenkins' document ( thank you Stephane), was last year around this time. From the IETF page the ftp://ftp.tis.com/pub/lists/ipsec doesn't work and the other link ftp.ans.net/pub/archive/ipsec only goes up to 1996. Can anyone help me out? J. Freedman,Jr ------=_NextPart_000_000E_01C0E364.D725FE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable problems accessing the archives
The=20 archives are also at www.vpnc.org
 

Best Regards,
Joseph D.=20 Harwood
jharwood@vesta-corp.com
www.vesta-corp.com

-----Original Message-----
From:=20 owner-ipsec@lists.tislabs.com = [mailto:owner-ipsec@lists.tislabs.com]On=20 Behalf Of Jerome Freedman Jr
Sent: Wednesday, May 23, = 2001 6:35=20 AM
To: ipsec@lists.tislabs.com
Subject: problems = accessing=20 the archives


I am trying to look in the archives for = discussions=20 of IKE rekeying which, from Tim Jenkins' document ( thank you = Stephane), was=20 last year around this time. From the IETF page the ftp://ftp.tis.com/pub/lists/ipsec doesn't work and = the other=20 link ftp.ans.net/pub/archive/ipsec only goes up to 1996. Can anyone = help me=20 out?


J. Freedman,Jr

 =20


------=_NextPart_000_000E_01C0E364.D725FE40-- From owner-ipsec@lists.tislabs.com Wed May 23 11:44: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 LAA09704; Wed, 23 May 2001 11:44:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09969 Wed, 23 May 2001 13:28:14 -0400 (EDT) Message-ID: <9D048F4A422CD411A56500B0D0209C5B01028B94@NS-CA> From: Michael Choung Shieh To: "'jayashreej@future.futsoft.com'" , ipsec@lists.tislabs.com Subject: RE: IPSec over L2TP tunnels for Remote users Date: Wed, 23 May 2001 10:30:33 -0700 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 believe many vendors have done interoperability test with Win2k in vpn backoff. we Netscreen did. L2tp over IPsec is to do L2TP over IPsec transport mode. There is no need to do IPsec tunnel mode since it will have duplicated outer ip address. yes, Win2k take the assigned ip address from PPP. Michael Shieh -----Original Message----- From: Jayashree J [mailto:jayashreej@future.futsoft.com] Sent: Wednesday, May 23, 2001 6:12 AM To: ipsec@lists.tislabs.com Subject: IPSec over L2TP tunnels for Remote users Hi, I have some questions in implementing IPSec over L2TP for a security gateway in case of a Remote User Access. 1) Has anyone done interop with Windows 2000 as a Remote Client? 2) It seems Windows 2000 operates only in transport mode for L2TP with IPSec( in remote user scenario). Is it necessary to supprot transport mode also in a security gateway to interop with Windows server? 3) In the above case how does Windows 2000 handle dynamic address received from PPP negotiations (is it as per the draft-ietf-l2tpext-security-02.txt>)? Thanks, Jayashree From owner-ipsec@lists.tislabs.com Wed May 23 18:55: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 SAA02367; Wed, 23 May 2001 18:55:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10934 Wed, 23 May 2001 20:57:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPSec over L2TP tunnels for Remote users Date: Wed, 23 May 2001 17:51:05 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC160F46F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IPSec over L2TP tunnels for Remote users Thread-Index: AcDj5eDPhR/rTsUXSNWEdeJYNj2AMgAAQqdg From: "Rob Trace" To: "Michael Choung Shieh" , , X-OriginalArrivalTime: 24 May 2001 00:51:05.0663 (UTC) FILETIME=[9CF70CF0:01C0E3EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA10857 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Michael, Microsoft has done quite a bit of interop testing both in house and at the various bakeoffs. We try to make sure that our version is compatible with as many gateways as possible. The Windows 2000 L2TP implementation requests an IPSEC transport mode policy only. It is possible to create a custom IPSEC policy for an L2TP connection in Windows 2000 that could include IPSEC tunnel mode but that is not supported by Microsoft. See http://support.microsoft.com/support/kb/articles/Q240/2/62.ASP?LN=EN-US& SD=gn&FR=0&qry=prohibitipsec&rnk=1&src=DHCS_MSPSS_gn_SRCH&SPR=WIN2000 for more details. We use the address that is received in IPCP to create an adapter for sending and receiving traffic over the tunnel. Please let me know if you have any other questions. Thanks!! -Robt -----Original Message----- From: Michael Choung Shieh [mailto:mshieh@netscreen.com] Sent: Wednesday, May 23, 2001 10:31 AM To: 'jayashreej@future.futsoft.com'; ipsec@lists.tislabs.com Subject: RE: IPSec over L2TP tunnels for Remote users I believe many vendors have done interoperability test with Win2k in vpn backoff. we Netscreen did. L2tp over IPsec is to do L2TP over IPsec transport mode. There is no need to do IPsec tunnel mode since it will have duplicated outer ip address. yes, Win2k take the assigned ip address from PPP. Michael Shieh -----Original Message----- From: Jayashree J [mailto:jayashreej@future.futsoft.com] Sent: Wednesday, May 23, 2001 6:12 AM To: ipsec@lists.tislabs.com Subject: IPSec over L2TP tunnels for Remote users Hi, I have some questions in implementing IPSec over L2TP for a security gateway in case of a Remote User Access. 1) Has anyone done interop with Windows 2000 as a Remote Client? 2) It seems Windows 2000 operates only in transport mode for L2TP with IPSec( in remote user scenario). Is it necessary to supprot transport mode also in a security gateway to interop with Windows server? 3) In the above case how does Windows 2000 handle dynamic address received from PPP negotiations (is it as per the draft-ietf-l2tpext-security-02.txt>)? Thanks, Jayashree From owner-ipsec@lists.tislabs.com Wed May 23 18: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 SAA02373; Wed, 23 May 2001 18:55:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10900 Wed, 23 May 2001 20:54:23 -0400 (EDT) Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F6A92@CAT01S2> From: Tim Jenkins To: "'Stephane Beaulieu'" , Jerome Freedman Jr , ipsec@lists.tislabs.com Cc: Jay Xiong Subject: RE: IKE Rekeying Date: Wed, 23 May 2001 09:14:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E38A.542CE316" 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_01C0E38A.542CE316 Content-Type: text/plain; charset="iso-8859-1" Yes, I still monitor the list. I did plan to update the draft referred to by Stephane in an attempt to submit it as informational, but I won't be doing that. The major changes needed (that I recall) were 1) related to the section that suggested there was a weakness in the responder pre-setup mechanism (many felt that the weakness was not significant) 2) removal of references to non-RFC documents. There were probably others; you could get hints to those by checking the archives. In any case, anyone is free to resurrect it if they feel so inclined. -----Original Message----- From: Stephane Beaulieu [mailto:stephane@cisco.com] Sent: Friday, May 18, 2001 4:19 PM To: Jerome Freedman Jr; ipsec@lists.tislabs.com Cc: Jay Xiong Subject: Re: IKE Rekeying There was a draft written by Tim Jenkins before he retired from IPsec ;) ( I know you still monitor the lists though Tim :) There was a lack of consensus in the typical IPsec fashion with 1 or 2 very loud voices against it (particularly his concept of Continuous Channel), and Tim gave up on it when he left TimeStep. It has a lot of very good, very detailed analysis. There was definitely more agreement with his phase 2 rekeying analysis than his phase 1 rekeying analysis, in case that's what you were looking for. Some people comply with this expired draft, and some don't. So don't assume interoperability if you implement it. But it is definitely worth reading if you have rekeying decisions to make. I'll send a copy to you in a private email. Stephane. ----- Original Message ----- From: Jerome Freedman Jr To: 'ipsec@lists.tislabs.com' Cc: Jay Xiong Sent: Friday, May 18, 2001 2:41 PM Subject: IKE Rekeying Hi, Has anyone done any work on IKE rekeying? Are there any drafts? Anybody want to write one? Jerry Freedman,Jr ------_=_NextPart_001_01C0E38A.542CE316 Content-Type: text/html; charset="iso-8859-1" IKE Rekeying
Yes, I still monitor the list.
 
I did plan to update the draft referred to by Stephane in an attempt to submit it as informational, but I won't be doing that. The major changes needed (that I recall) were
1) related to the section that suggested there was a weakness in the responder pre-setup mechanism (many felt that the weakness was not significant)
2) removal of references to non-RFC documents.
There were probably others; you could get hints to those by checking the archives.
 
In any case, anyone is free to resurrect it if they feel so inclined.
-----Original Message-----
From: Stephane Beaulieu [mailto:stephane@cisco.com]
Sent: Friday, May 18, 2001 4:19 PM
To: Jerome Freedman Jr; ipsec@lists.tislabs.com
Cc: Jay Xiong
Subject: Re: IKE Rekeying

There was a draft written by Tim Jenkins before he retired from IPsec ;)  ( I know you still monitor the lists though Tim :)
 
There was a lack of consensus in the typical IPsec fashion with 1 or 2 very loud voices against it (particularly his concept of Continuous Channel), and Tim gave up on it when he left TimeStep.  It has a lot of very good, very detailed analysis.  There was definitely more agreement with his phase 2 rekeying analysis than his phase 1 rekeying analysis, in case that's what you were looking for.
 
Some people comply with this expired draft, and some don't.  So don't assume interoperability if you implement it.  But it is definitely worth reading if you have rekeying decisions to make.
 
I'll send a copy to you in a private email.
 
Stephane.
----- Original Message -----
Sent: Friday, May 18, 2001 2:41 PM
Subject: IKE Rekeying


Hi,

   Has anyone done any work on IKE rekeying? Are there any drafts? Anybody want to write one?


Jerry Freedman,Jr

------_=_NextPart_001_01C0E38A.542CE316-- From owner-ipsec@lists.tislabs.com Wed May 23 18: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 SAA02393; Wed, 23 May 2001 18:55:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10890 Wed, 23 May 2001 20:52:23 -0400 (EDT) Message-ID: <000c01c0e31c$04c6c9e0$93b12304@ffb5b> From: "jshukla" To: "Ly Loi" , References: <416B5AF360DED54088DAD3CA8BFBEA6E010AB1@TNEXVS02.tahoenetworks.com> Subject: Re: NAT traversal clarification? Date: Tue, 22 May 2001 17:05:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Ly Loi" > Hi, draft-huttunen-ipsec-esp-in-udp-01.txt, section 5 "IPSec over NAT > Operation" has the following: > It hits the NAT, and the NAT translates the src address, and source > portcreates an entry for the SPI. When the reply comes back from X, the > NAT maps the SPI from X with the SPI send from A. Now the NAT knows > which internal host to send the packet to, and A gets it. > Assuming that the text meant to say "... source port, and creates an > entry ...", I'm not sure I understand why we're referring to the SPI > here or how it's being used for the following reasons: > > Moreover they have only described the host-to-network scenario and skipped the host-to-host scenario in Section 5. I tried to work out the host-to-host scenario in case of a VPN and am having some difficulties. Consider A 10.1.1.1 on network X 172.1.1.1 and B 10.0.0.1 on network Y 172.0.0.2 A X <----------------------- >Y B when A wants to communicate with B in a VPN environment, then the UDP encapsulation of ESP in IPSec transport mode does not work. You can easily figure it out. Now lets see what happens in the tunnel mode. Say A sends a packet (src IP=10.1.1.1, dst IP = 10.0.0.1, src pt = 601, dst pt = 79) to B. Format of the packet is +--------------------------------------------------+ | IP | UDP| ESP| IP | UDP/TCP| data| AH | +--------------------------------------------------+ encrypted <----------------------> Gateway at X (172.1.1.1) has to replace the destination address and perform NAT. NAT changes the src IP address and src port #. New packet information could be like this, (src IP=172.1.1.1, dst IP = 172.0.0.2, src pt = 602, dst pt = 79). When gateway at Y (172.0.0.2) receives this packet, how does it forward the packet to B? Because the IP address is inside the encrypted region of the packet, Y cannot look at it. Ofcourse we are assuming a true end-to-end scenario where the end-host (B) has the key required to decrypt the packet and does not share it with Y. Looks like a problem to me! regards, Jayant From owner-ipsec@lists.tislabs.com Wed May 23 18: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 SAA02394; Wed, 23 May 2001 18:55:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10925 Wed, 23 May 2001 20:55:24 -0400 (EDT) From: ano825@fr.thalesgroup.com Message-ID: <077F5F72E6F3D111A7BA00600874A9DA02036D36@nodalcch1.cch.tcc.thomson-csf.com> To: ipsec@lists.tislabs.com Subject: Cryptographic evaluation of IPSec Date: Wed, 23 May 2001 15:47:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am a trainee working at THALES Communications, studying IPSec/IKE/ISAKMP. I have read a cryptographic Evaluation of IPSec written by niels Ferguson and Bruce Schneier (www.counterpane.com) which I found interesting. I know that this paper is quiet old, but what do you think about it? Does anyone know where I can find other analysis over these protocols ? regards, Alexandre DUCROCQ From owner-ipsec@lists.tislabs.com Wed May 23 19:44: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 TAA05022; Wed, 23 May 2001 19:43:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11117 Wed, 23 May 2001 21:46:25 -0400 (EDT) Message-Id: <200105240151.VAA07099@bcn.East.Sun.COM> Date: Wed, 23 May 2001 21:51:46 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Cryptographic evaluation of IPSec To: ipsec@lists.tislabs.com, ano825@fr.thalesgroup.com Cc: ckaufman@iris.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SiUYj3OpLH+o2rf7q+jmgw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re: Alexandre DUCROCQ's query looking for papers on IPSec: Charlie Kaufman and I wrote a paper analyzing IKE that came out in the IEEE Internet Computng special issue on network security, Nov/Dec 2000. We expanded the content somewhat and it will be presented at the WET-ICE conference coming up this summer, at MIT. Ask us if you want an emailed copy (with a subject line for me like "Hi Radia" so I'll notice it). Radia From owner-ipsec@lists.tislabs.com Wed May 23 19: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 TAA05084; Wed, 23 May 2001 19:45:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10926 Wed, 23 May 2001 20:55:25 -0400 (EDT) Message-ID: <001701c0e3a6$954c5d60$8ab12304@ffb5b> From: "jshukla" To: Subject: Re: NAT traversal clarification? Date: Wed, 23 May 2001 09:36:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Ly Loi" > Hi, draft-huttunen-ipsec-esp-in-udp-01.txt, section 5 "IPSec over NAT > Operation" has the following: > It hits the NAT, and the NAT translates the src address, and source > portcreates an entry for the SPI. When the reply comes back from X, the > NAT maps the SPI from X with the SPI send from A. Now the NAT knows > which internal host to send the packet to, and A gets it. > Assuming that the text meant to say "... source port, and creates an > entry ...", I'm not sure I understand why we're referring to the SPI > here or how it's being used for the following reasons: > > Moreover they have only described the host-to-network scenario and skipped the host-to-host scenario in Section 5. I tried to work out the host-to-host scenario in case of a VPN and am having some difficulties. Consider A 10.1.1.1 on network X 172.1.1.1 and B 10.0.0.1 on network Y 172.0.0.2 A X <----------------------- >Y B when A wants to communicate with B in a VPN environment, then the UDP encapsulation of ESP in IPSec transport mode does not work. You can easily figure it out. Now lets see what happens in the tunnel mode. Say A sends a packet (src IP=10.1.1.1, dst IP = 10.0.0.1, src pt = 601, dst pt = 79) to B. Format of the packet is +--------------------------------------------------+ | IP | UDP| ESP| IP | UDP/TCP| data| AH | +--------------------------------------------------+ encrypted <----------------------> Gateway at X (172.1.1.1) has to replace the destination address and perform NAT. NAT changes the src IP address and src port #. New packet information could be like this, (src IP=172.1.1.1, dst IP = 172.0.0.2, src pt = 602, dst pt = 79). When gateway at Y (172.0.0.2) receives this packet, how does it forward the packet to B? Because the IP address is inside the encrypted region of the packet, Y cannot look at it. Ofcourse we are assuming a true end-to-end scenario where the end-host (B) has the key required to decrypt the packet and does not share it with Y. Looks like a problem to me! regards, Jayant From owner-ipsec@lists.tislabs.com Wed May 23 20:31: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 UAA05900; Wed, 23 May 2001 20:31:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11204 Wed, 23 May 2001 22:36:52 -0400 (EDT) X-Authentication-Warning: thompson.lcmi.ufsc.br: esms owned process doing -bs Date: Wed, 23 May 2001 23:41:43 -0300 (EST) From: Eduardo Souza Machado da Silva Reply-To: Eduardo Souza Machado da Silva To: ano825@fr.thalesgroup.com cc: ipsec@lists.tislabs.com Subject: Re: Cryptographic evaluation of IPSec In-Reply-To: <077F5F72E6F3D111A7BA00600874A9DA02036D36@nodalcch1.cch.tcc.thomson-csf.com> 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 Hi, take a look at list archives. Mr. Kent answered some issues about it: Date: Tue, 25 Jan 2000 08:04:01 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Counterpane comments, ASCII version regards, esms On Wed, 23 May 2001 ano825@fr.thalesgroup.com wrote: > Hi, > I am a trainee working at THALES Communications, studying IPSec/IKE/ISAKMP. > I have read a cryptographic Evaluation of IPSec written by niels Ferguson > and Bruce Schneier (www.counterpane.com) which I found interesting. > I know that this paper is quiet old, but what do you think about it? > Does anyone know where I can find other analysis over these protocols ? > regards, > Alexandre DUCROCQ > > From owner-ipsec@lists.tislabs.com Thu May 24 11:51: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 LAA26232; Thu, 24 May 2001 11:51:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12898 Thu, 24 May 2001 13:46:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3B050EE1.91ADA25@lmf.ericsson.se> References: <3B050EE1.91ADA25@lmf.ericsson.se> Date: Tue, 22 May 2001 09:06:20 -0400 To: Jari Arkko From: Stephen Kent Subject: Re: AES, AES-MAC Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:00 PM +0300 5/18/01, Jari Arkko wrote: >Hello, > >I need some clarification on the current status of >the new AES algorithm in the context of the IPsec >standards. Am I correct in assuming the following: > >- There are IANA numbers for the use of AES > both in IPsec and IKE >- There is a draft on the use of AES (including > losing candidates) in IPsec. > >Implementing these is quite straightforward >and lots folks have implementations, including >us. But what is unclear to me is the following: > >- Is there a need for 'use of AES in IKE' > document? probably > >- What is the standards process: when do > these algorithms find their way to RFCs, > or is it enough with the IANA reservations > and the NIST standards? In particular, when > can other groups and vendors refer to the > use of AES within IPsec in some way other > than through working documents? assignment of numbers by IANA does not make algorithms part of the IPsec standards. there is a desire to make AES the new default algorithm for ESP, and that will require a change to 2406. Also, there is the still open question of what modes to use with AES. > >- I believe it is possible to use AES as > a MAC algorithm a la DES-MAC. Has this > been specified by NIST? Has it been specified > by IETF how to use it in the context of IPsec? Again, this is part of revising 2406, if you want it to be a default. Steve From owner-ipsec@lists.tislabs.com Thu May 24 11:54:40 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 LAA26313; Thu, 24 May 2001 11:54:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12848 Thu, 24 May 2001 13:32:02 -0400 (EDT) Message-ID: <3B0D46BB.912B0BD2@storm.ca> Date: Thu, 24 May 2001 13:36:59 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ano825@fr.thalesgroup.com CC: ipsec@lists.tislabs.com Subject: Re: Cryptographic evaluation of IPSec References: <077F5F72E6F3D111A7BA00600874A9DA02036D36@nodalcch1.cch.tcc.thomson-csf.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ano825@fr.thalesgroup.com wrote: > > Hi, > I am a trainee working at THALES Communications, studying IPSec/IKE/ISAKMP. > I have read a cryptographic Evaluation of IPSec written by niels Ferguson > and Bruce Schneier (www.counterpane.com) which I found interesting. > I know that this paper is quiet old, but what do you think about it? > Does anyone know where I can find other analysis over these protocols ? > regards, > Alexandre DUCROCQ A list of all the evaluations I know of is in the documentation for the FreeS/WAN implementation of IPSEC for Linux: http://www.freeswan.org/freeswan_trees/freeswan-1.9/doc/web.html#analysis Please let me know if you discover anything interesting that is not on that list, so I can add it. From owner-ipsec@lists.tislabs.com Thu May 24 11:54: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 LAA26327; Thu, 24 May 2001 11:54:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12865 Thu, 24 May 2001 13:36:35 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: IPSec cert OID usage status ? Date: Thu, 24 May 2001 10:39:51 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1CF0B66@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IPSec cert OID usage status ? Thread-Index: AcDkeJtf75BmpLEFTjqjw0iSuPk6Ww== From: "William Dixon" To: Cc: "Trevor Freeman" , "David Cross" , "Paul Hoffman / VPNC" X-OriginalArrivalTime: 24 May 2001 17:39:51.0634 (UTC) FILETIME=[89414B20:01C0E478] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What do people think a PKI vendor should support as the Extended Key Usage OIDs for certificates issued for use with IPSec ? >From prior bakeoffs, I recall that everyone agreed there would be only 1 IPSec usage OID, the intermediate one as below, not the 3 that PKIX had previously defined. Rodney's old ipsec certificate profile draft suggested that the PKIX OIDs be deprecated. But that draft is expired. Consensus from the last bakeoff was also that people didn't want to agree on a particular set of requirements for cert usage in IPSec. IPSEC_KP_IKE_INTERMEDIATE "1.3.6.1.5.5.8.2.2" OID_PKIX_KP_IPSEC_END_SYSTEM "1.3.6.1.5.5.7.3.5" OID_PKIX_KP_IPSEC_TUNNEL "1.3.6.1.5.5.7.3.6" OID_PKIX_KP_IPSEC_USER "1.3.6.1.5.5.7.3.7" Wm Program Manager, Network Security, IPSec Windows Division Microsoft From owner-ipsec@lists.tislabs.com Thu May 24 12:19: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 MAA26924; Thu, 24 May 2001 12:19:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13037 Thu, 24 May 2001 14:31:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1CF0B66@win-msg-01.wingroup.windeploy.ntde v.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1CF0B66@win-msg-01.wingroup.windeploy.ntde v.microsoft.com> Date: Thu, 24 May 2001 14:36:45 -0400 To: "William Dixon" From: Stephen Kent Subject: Re: IPSec cert OID usage status ? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:39 AM -0700 5/24/01, William Dixon wrote: >What do people think a PKI vendor should support as the Extended Key >Usage OIDs for certificates issued for use with IPSec ? > >>From prior bakeoffs, I recall that everyone agreed there would be only 1 >IPSec usage OID, the intermediate one as below, not the 3 that PKIX had >previously defined. Rodney's old ipsec certificate profile draft >suggested that the PKIX OIDs be deprecated. But that draft is expired. >Consensus from the last bakeoff was also that people didn't want to >agree on a particular set of requirements for cert usage in IPSec. > >IPSEC_KP_IKE_INTERMEDIATE "1.3.6.1.5.5.8.2.2" > >OID_PKIX_KP_IPSEC_END_SYSTEM "1.3.6.1.5.5.7.3.5" > >OID_PKIX_KP_IPSEC_TUNNEL "1.3.6.1.5.5.7.3.6" > >OID_PKIX_KP_IPSEC_USER "1.3.6.1.5.5.7.3.7" > Bill, The next PKIX base standard (successor to 2459) will not contain any Extended Key usage IDs. IPsec and other PKI-enabled protocols should create documents to specify these values, and related profiles for certs. In your list above, I can understand the first and second examples, and maybe the fourth, but not the third, i.e., why would a tunnel have a cert? As for a consensus re NOT agreeing on a cert profile for IPsec, I think this is a big mistake and would like to understand the motivation behind such a statement. Steve From owner-ipsec@lists.tislabs.com Thu May 24 14:28: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 OAA05684; Thu, 24 May 2001 14:28:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13342 Thu, 24 May 2001 16:36:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: IPSec cert OID usage status ? Date: Thu, 24 May 2001 13:41:02 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1CF0B6C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IPSec cert OID usage status ? Thread-Index: AcDkgcvGcOahQ8ezQ/WdGPUU6xCCkgAAngqQ From: "William Dixon" To: "Stephen Kent" Cc: X-OriginalArrivalTime: 24 May 2001 20:41:02.0707 (UTC) FILETIME=[D8EB6430:01C0E491] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The three values with PKIX labels were from the appendix in 2459. I did a quick check on draft PKIX documents and found that the PKIX group intends on defining usage of certificates for IPSec: >From draft-ietf-pkix-roadmap-06.txt "It is one goal of PKIX to specify a profile for Internet, electronic mail, and IPSec applications, etc." >From draft-ietf-pkix-ac509prof-06.txt "The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications." I agree we need an IPsec profile for certificate usage (see interop comments below though). I don't think it matters which group does it. But it would appear to me this is an addendum to IKE itself, rather than a generic, keying-protocol-independent, "IPSec certificate" usage statement. IKE already specifies handling of certain certificate contents, such as SubjectName and SubjectAltName values with respect to the ID payload, how to do CRPs, etc. If the next base PKIX standard will omit IPSec OIDs that 2459 previously defined, does that mean those OIDs in 2459 are deprecated ? My comment in mail below was based on the last bakeoff, during discussion of the PKI interop results, we suggested these minimums for cert usage and asked the audience for consensus - no hands went up to support "requirements". Maybe the vendor reps hadn't had enough of a chance to think about it, or maybe they didn't see cert usage requirements as necessary to enable interop. When using IKE RSA-signature mode, when the CERT payload is sent, the end-entity certificate MUST have: - key type: RSA, obvious since the private key has to sign the hash for RSA-sig mode - key usage: digital signature is one of the usages SHOULD have: - 1024bit or greater key size Are there other minimums ? Is there a PKIX requirement that says an OID specifies that a cert identifies a user or machine or role, such as an intermediate point ? Prior discussion at bakeoffs was that we thought we needed just one OID to identify the certificate for use with IPSec. Since we had heard that the PKIX OIDs were going away, we settled just on the new one, intermediate OID, but I don't recall how that was chosen. While, these minimums seem perfectly reasonable to me, standardizing them in hopes of achieving interop is a different issue. The receiver determines the certificate that the initiator must send, as it's the receiver which ultimately must accept the certificate. Since there are many checks on a certificate for authorization, beyond proper PKIX chain validation for authentication, I don't think interop is actually accomplished by having such a minimal set of requirements as standard. It would seem to me that VPN remote access client to VPN server may be one profile. IPSec GW to IPSec GW doing IPSec tunneling is another profile. IPSec transport between machines another. Wm -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, May 24, 2001 11:37 AM To: William Dixon Cc: ipsec@lists.tislabs.com Subject: Re: IPSec cert OID usage status ? At 10:39 AM -0700 5/24/01, William Dixon wrote: >What do people think a PKI vendor should support as the Extended Key >Usage OIDs for certificates issued for use with IPSec ? > >>From prior bakeoffs, I recall that everyone agreed there would be only >>1 >IPSec usage OID, the intermediate one as below, not the 3 that PKIX had >previously defined. Rodney's old ipsec certificate profile draft >suggested that the PKIX OIDs be deprecated. But that draft is expired. >Consensus from the last bakeoff was also that people didn't want to >agree on a particular set of requirements for cert usage in IPSec. > >IPSEC_KP_IKE_INTERMEDIATE "1.3.6.1.5.5.8.2.2" > >OID_PKIX_KP_IPSEC_END_SYSTEM "1.3.6.1.5.5.7.3.5" > >OID_PKIX_KP_IPSEC_TUNNEL "1.3.6.1.5.5.7.3.6" > >OID_PKIX_KP_IPSEC_USER "1.3.6.1.5.5.7.3.7" > Bill, The next PKIX base standard (successor to 2459) will not contain any Extended Key usage IDs. IPsec and other PKI-enabled protocols should create documents to specify these values, and related profiles for certs. In your list above, I can understand the first and second examples, and maybe the fourth, but not the third, i.e., why would a tunnel have a cert? As for a consensus re NOT agreeing on a cert profile for IPsec, I think this is a big mistake and would like to understand the motivation behind such a statement. Steve From owner-ipsec@lists.tislabs.com Thu May 24 14: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 OAA06077; Thu, 24 May 2001 14:32:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13291 Thu, 24 May 2001 16:29:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1CF0B66@win-msg-01.wingroup.windeploy.ntde v.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1CF0B66@win-msg-01.wingroup.windeploy.ntde v.microsoft.com> Date: Thu, 24 May 2001 13:34:15 -0700 To: "William Dixon" , From: Paul Hoffman / VPNC Subject: Re: IPSec cert OID usage status ? Cc: "Trevor Freeman" , "David Cross" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:39 AM -0700 5/24/01, William Dixon wrote: >What do people think a PKI vendor should support as the Extended Key >Usage OIDs for certificates issued for use with IPSec ? I used to have a strong opinion on this. Then I asked the vendors. Everyone does something different, except for the large number who do nothing at all. > >From prior bakeoffs, I recall that everyone agreed there would be only 1 >IPSec usage OID, the intermediate one as below, not the 3 that PKIX had >previously defined. Right. Except those who said "we'll accept anything because we don't really understand PKI anyway". > Rodney's old ipsec certificate profile draft >suggested that the PKIX OIDs be deprecated. But that draft is expired. There was no interest in it. At this point, I'm the responsible party for letting it die. I'm hoping that Dan Harkins will put this in the son-of-IKE document, if that document ever gets started. >Consensus from the last bakeoff was also that people didn't want to >agree on a particular set of requirements for cert usage in IPSec. Correct. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 24 14:36: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 OAA06246; Thu, 24 May 2001 14:36:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13388 Thu, 24 May 2001 16:45:55 -0400 (EDT) Reply-To: From: "Davenport Michael" To: "Ipsec (E-mail)" Subject: IPSec over satellite Date: Thu, 24 May 2001 16:51:15 -0400 Message-ID: <000c01c0e493$46c7d280$8947509c@BAH.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, There has been issues raised in the satellite community about being able to speed TCP traffic over satellite links (whether at layer 2 or 4) that is "compliant" if you will with IPSec. Is there anything in the market today that improves performance that does not look into the encrypted packet for modification (I heard someone mention a "packet blaster" but unsure what it is)? If anyone has any ideas or experience with this issue please let me know. My first instinct is to put the VPN in front of the satellite link so modifications to the packet over the link can be done (take IPSec out of the equation and still provide protection from the internet), but there may be situations where it must be used. An example is with the TACLANE by General Dynamics that is a type 1 encryption but still tunnels data from point a to b. Any insight or suggestions? Michael Davenport From owner-ipsec@lists.tislabs.com Thu May 24 15:12: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 PAA06927; Thu, 24 May 2001 15:12:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13506 Thu, 24 May 2001 17:30:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1CF0B6C@win-msg-01.wingroup.windeploy.ntde v.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1CF0B6C@win-msg-01.wingroup.windeploy.ntde v.microsoft.com> Date: Thu, 24 May 2001 17:34:38 -0400 To: "William Dixon" From: Stephen Kent Subject: RE: IPSec cert OID usage status ? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William, Dropping the OIDs from 2459bis is not deprecating them, just not continuing to publish them in PKIX. It does not make sense for PKIX to include these values, and the analogous values for TLS and S/MIME, it its standards. A cert profile for Ipsec is definitely an IPsec WG action, if one wishes to have one. The extended key usage extension allows each application to decide how to make use of these OIDs, so there is no implication that one would need separate certs for end systems vs. security gateways, although one might choose to make such a distinction. It's really up to a PKI-enabled application to decide what it needs and the specify it. Of the examples you gave, the one that did not seem to make sense to me was the tunnel example. There's a lot more to a profile than what is covered by proper path validation, and it would be appropriate to have a spec that says that PKIX-specified path validation was defined as the appropriate base, for example. One could make statements about whether CRLs, OCSP responses or both had to be supported. One could put into the profile (vs. putting some in the profile and some in IKE) what alt name forms are acceptable/required to be supported. One could choose to discourage use of extensions that don't seem appropriate, to simplify the PKi context for IPsec, ... Steve From owner-ipsec@lists.tislabs.com Fri May 25 09:17:46 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 JAA14697; Fri, 25 May 2001 09:17:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15721 Fri, 25 May 2001 10:50:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20010525104234.00b28100@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 May 2001 10:55:07 -0400 To: Jari Arkko From: Sheila Frankel Subject: Re: AES, AES-MAC Cc: ipsec@lists.tislabs.com In-Reply-To: <3B050EE1.91ADA25@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:00 AM 5/18/01, Jari Arkko wrote:

Hello,

I need some clarification on the current status of
the new AES algorithm in the context of the IPsec
standards. Am I correct in assuming the following:

- There are IANA numbers for the use of AES
  both in IPsec and IKE

correct

- There is a draft on the use of AES (including
  losing candidates) in IPsec.

also correct


Implementing these is quite straightforward
and lots folks have implementations, including
us. But what is unclear to me is the following:

- Is there a need for 'use of AES in IKE'
  document?

The AES Internet Draft does have an "IKE Interactions" section. We would welcome comments on any material that is lacking from that section.

- What is the standards process: when do
  these algorithms find their way to RFCs,
  or is it enough with the IANA reservations
  and the NIST standards? In particular, when
  can other groups and vendors refer to the
  use of AES within IPsec in some way other
  than through working documents?

The AES Draft will be updated shortly, since it expires this month. Once the NIST FIPS is final (planned for this summer), we hope to advance to RFC status.

- I believe it is possible to use AES as
  a MAC algorithm a la DES-MAC. Has this
  been specified by NIST? Has it been specified
  by IETF how to use it in the context of IPsec?


If there is interest, this could be added to the AES Draft as well.

- I seem to remember talk about SHA-256/384/512.
  What are these and have their use been
  specified for IPsec? What is their relationship
  to AES-MAC?


Their use has not yet been specified for use with IPsec, but a draft is planned.

Sheila Frankel
sheila.frankel@nist.gov From owner-ipsec@lists.tislabs.com Tue May 29 01:11: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 BAA14692; Tue, 29 May 2001 01:11:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA24912 Tue, 29 May 2001 02:24:24 -0400 (EDT) From: "Kiran" To: Subject: Client Negotiation Date: Tue, 29 May 2001 11:53:32 +0530 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.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, I have doubts on what the std. says regarding Client Negotiation. A----X ------------- Y----B If X is doing Client Negotiation for traffic between A to B, then does it mean that finally IPSec SA will be established between A and B. What I like to know is, as a result of this negotiation, will the entire path from A to B be protected or is the protection only for path between X and Y? Regards, kiran kumar From owner-ipsec@lists.tislabs.com Tue May 29 06:52: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 GAA14340; Tue, 29 May 2001 06:52:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26051 Tue, 29 May 2001 08:38:18 -0400 (EDT) Message-ID: <20010528170507.18255.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) From: "Jose Maria" To: ipsec@lists.tislabs.com Cc: quintana21@galeon.com Date: Tue, 29 May 2001 01:05:07 +0800 Subject: Definition of new Domains of interpretation (question) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, I am trying to define a new DOI, apart from RFC 2407 and IPSEC DOI there is any other new DOI description? I am migrating SSL parameters negotiation to ISAKMP negotiation. There are any other similar work??. Thanks in advance. Juan M. Quintana. -- _______________________________________________ Get your free email from http://www.mail.com From owner-ipsec@lists.tislabs.com Tue May 29 08:55: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 IAA26433; Tue, 29 May 2001 08:55:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26507 Tue, 29 May 2001 10:52:07 -0400 (EDT) Message-ID: <3B13B054.1424AE62@miel.mot.com> Date: Tue, 29 May 2001 19:51:08 +0530 From: Rohit Aradhya Organization: Motorola, India X-Mailer: Mozilla 4.51 [en] (X11; I; HP-UX B.10.20 9000/782) X-Accept-Language: en MIME-Version: 1.0 To: Kiran CC: ipsec@lists.tislabs.com Subject: Re: Client Negotiation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Only the path between X and Y is protected, but for the traffice between A and B. This kind of negotiaion is useful whenn multiple hosts lie behind X (mostly a security gateway). -Rohit Kiran wrote: > Hi All, > > I have doubts on what the std. says regarding Client Negotiation. > > A----X ------------- Y----B > > If X is doing Client Negotiation for traffic between A to B, then does it > mean that finally > IPSec SA will be established between A and B. What I like to know is, as a > result of this > negotiation, will the entire path from A to B be protected or is the > protection only for > path between X and Y? > > Regards, > kiran kumar -- -------------------------------------------------------- [ ] General Business Information [x] Motorola Internal Use only [ ] Motorola Confidential Proprietary -------------------------------------------------------- -------------------------------------------------------- Rohit Aradhya, Motorola Banglore, India Ph- (080)5598615 X-4005 From owner-ipsec@lists.tislabs.com Tue May 29 20:34: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 UAA06554; Tue, 29 May 2001 20:34:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA28374 Tue, 29 May 2001 22:29:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20010529193026.04908c28@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 May 2001 19:32:47 -0700 To: "Jose Maria" From: Mark Baugher Subject: Re: Definition of new Domains of interpretation (question) Cc: ipsec@lists.tislabs.com, quintana21@galeon.com In-Reply-To: <20010528170507.18255.qmail@mail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You may want to go to http://search.ietf.org/search/brokers/internet-drafts/query.html and query for "domain of interpretation." There are a couple active drafts, including http://search.ietf.org/internet-drafts/draft-ietf-msec-gdoi-00.txt. Mark At 01:05 AM 5/29/2001 +0800, Jose Maria wrote: >Dear all, > > >I am trying to define a new DOI, apart from RFC 2407 and IPSEC DOI there >is any other new DOI description? > > > >I am migrating SSL parameters negotiation to ISAKMP negotiation. There >are any other similar work??. > > >Thanks in advance. > > >Juan M. Quintana. > >-- > >_______________________________________________ >Get your free email from http://www.mail.com