IPSec support within BSDi 4.0?

From owner-ipsec@lists.tislabs.com Mon May 3 14:36:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23923; Mon, 3 May 1999 14:36:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19430 Mon, 3 May 1999 14:52:09 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <37275ab5.uincaa@incaa.nl> Date: Mon, 3 May 1999 15:00:18 -0400 To: RL@incaa.nl From: Stephen Kent Subject: Re: Java crypto Cipher-Block-Chaining isn't chaining Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Robert, CBC mode, as defined in FIPS 81 does not need to "chain" from one packet to the next, only from one 8-byte block to the next, e.g., within a packet. In fact, strict adherence to the FIPS does not even require a new IV for each packet. While 2405 notes the possibility of chaining from one packet to the next, it does not require such (no use of SHOULD, MUST, or even MAY). Thus the Java implementation you cite appears to comply with both 2405 and the FIPS. Steve From owner-ipsec@lists.tislabs.com Mon May 3 15:30:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24523; Mon, 3 May 1999 15:30:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19560 Mon, 3 May 1999 15:51:36 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Date: Mon, 3 May 1999 15:51:56 -0400 To: Sankar Ramamoorthi From: Stephen Kent Subject: RE: INITIAL-CONTACT issues Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar, The TCP spec does not contain a "keepalive" mechanism (at least the one I remember did not); keepalive is a feature added by some implementations. TCP specifies timers for killing off connections, e.g., in terms of no ack for transmitted data, which is one way to deal with the situation where one end of the connection has crashed. Also, since TCP is implemented in end systems, an application may intervene to terminate a connection, e.g., because a user decides to give up. IPsec, when implemented in a host, and integrated with a socket interface, can use the same set of inputs for terminating an SA if the SA is dedicated to a TCP connection. IPsec has a harder job, in the case of an SG, because there is no direct tie to a socket interface. That's where SA management, in terms of cleanup, becomes hard. Steve From owner-ipsec@lists.tislabs.com Mon May 3 18:21:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA26020; Mon, 3 May 1999 18:21:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20089 Mon, 3 May 1999 18:57:50 -0400 (EDT) Message-ID: <111627409F79D2119FB100A0C9EEDC3E2E40D7@f5-exchange.win.net> From: Michael Barthelow To: ipsec@lists.tislabs.com Subject: IPSec support within BSDi 4.0? Date: Mon, 3 May 1999 16:04:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE95B9.5AD821E0" 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_01BE95B9.5AD821E0 Content-Type: text/plain; charset="iso-8859-1" Can anyone tell me what (if any support) is present in BSDi 4.0 for IPSec and IKE? tia, mb ------_=_NextPart_001_01BE95B9.5AD821E0 Content-Type: text/html; charset="iso-8859-1" IPSec support within BSDi 4.0?

Can anyone tell me what (if any support) is present in BSDi 4.0 for IPSec and IKE?

tia,

------_=_NextPart_001_01BE95B9.5AD821E0-- From owner-ipsec@lists.tislabs.com Mon May 3 18:54:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA26347; Mon, 3 May 1999 18:54:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20152 Mon, 3 May 1999 19:46:27 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Stephen Kent'" , Sankar Ramamoorthi Cc: ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Date: Mon, 3 May 1999 16:54:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree that tcp specs do not specify keepalive mechanism. However they discuss the issue in detail (RFC 1122), the need for it, the reason why it should not be part of TCP... I was trying to show that the problem of state-cleanup due to crashed hosts was already faced by TCP implementors. I am implementing 'COMMIT' and 'INITIAL-CONTACT' etc, and the question I keep having is. 'Is there any reason why IKE is not implemented on top of TCP?' The architecture seems to allow it - most of the implemenations using IKE also have a tcp stack (atleast the one's I have seen). Any reason why TCP was not considered as a choice (atleast a SHOULD support) for carrying IKE traffic? Thanks, -- sankar ramamoorthi -- -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, May 03, 1999 12:52 PM To: Sankar Ramamoorthi Cc: ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Sankar, The TCP spec does not contain a "keepalive" mechanism (at least the one I remember did not); keepalive is a feature added by some implementations. TCP specifies timers for killing off connections, e.g., in terms of no ack for transmitted data, which is one way to deal with the situation where one end of the connection has crashed. Also, since TCP is implemented in end systems, an application may intervene to terminate a connection, e.g., because a user decides to give up. IPsec, when implemented in a host, and integrated with a socket interface, can use the same set of inputs for terminating an SA if the SA is dedicated to a TCP connection. IPsec has a harder job, in the case of an SG, because there is no direct tie to a socket interface. That's where SA management, in terms of cleanup, becomes hard. Steve From owner-ipsec@lists.tislabs.com Mon May 3 19:16:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA29527; Mon, 3 May 1999 19:16:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20172 Mon, 3 May 1999 19:53:30 -0400 (EDT) Message-Id: <199905040001.RAA11674@potassium.network-alchemy.com> To: Michael Barthelow cc: ipsec@lists.tislabs.com Subject: Re: IPSec support within BSDi 4.0? In-reply-to: Your message of "Mon, 03 May 1999 16:04:53 PDT." <111627409F79D2119FB100A0C9EEDC3E2E40D7@f5-exchange.win.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11671.925776065.1@network-alchemy.com> Date: Mon, 03 May 1999 17:01:05 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe it has the NRL IPSec code and the Cisco IKE code. Dan. On Mon, 03 May 1999 16:04:53 PDT you wrote > 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_01BE95B9.5AD821E0 > Content-Type: text/plain; > charset="iso-8859-1" > > Can anyone tell me what (if any support) is present in BSDi 4.0 for IPSec and > IKE? > > tia, > > mb From owner-ipsec@lists.tislabs.com Mon May 3 20:37:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA10498; Mon, 3 May 1999 20:37:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20411 Mon, 3 May 1999 21:35:24 -0400 (EDT) Message-ID: <372E50EF.FA8157C6@redcreek.com> Date: Mon, 03 May 1999 18:44:15 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sankar Ramamoorthi CC: "'Stephen Kent'" , ipsec@lists.tislabs.com Subject: Re: INITIAL-CONTACT issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar Ramamoorthi wrote: > I am implementing 'COMMIT' and 'INITIAL-CONTACT' etc, > and the question I keep having is. > 'Is there any reason why IKE is not implemented on > top of TCP?' > The architecture seems to allow it - most of the > implemenations using IKE also have a tcp stack > (atleast the one's I have seen). > Any reason why TCP was not considered as a choice > (atleast a SHOULD support) for carrying IKE traffic? > For one thing, think about relatively rapid rekeying, and then think about tcp connection setup overhead... From owner-ipsec@lists.tislabs.com Mon May 3 20:42:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA11183; Mon, 3 May 1999 20:42:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20434 Mon, 3 May 1999 21:43:19 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Scott G. Kelly'" , Sankar Ramamoorthi Cc: "'Stephen Kent'" , ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Date: Mon, 3 May 1999 18:51:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If the same TCP stream is used across rekeying, then TCP connection overhead is not an issue - right? -- sankar -- -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Monday, May 03, 1999 6:44 PM To: Sankar Ramamoorthi Cc: 'Stephen Kent'; ipsec@lists.tislabs.com Subject: Re: INITIAL-CONTACT issues Sankar Ramamoorthi wrote: > I am implementing 'COMMIT' and 'INITIAL-CONTACT' etc, > and the question I keep having is. > 'Is there any reason why IKE is not implemented on > top of TCP?' > The architecture seems to allow it - most of the > implemenations using IKE also have a tcp stack > (atleast the one's I have seen). > Any reason why TCP was not considered as a choice > (atleast a SHOULD support) for carrying IKE traffic? > For one thing, think about relatively rapid rekeying, and then think about tcp connection setup overhead... From owner-ipsec@lists.tislabs.com Mon May 3 20:47:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA11759; Mon, 3 May 1999 20:47:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20404 Mon, 3 May 1999 21:34:03 -0400 (EDT) Message-Id: <4.2.0.37.19990503183745.01cea150@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Mon, 03 May 1999 18:41:52 -0700 To: Michael Barthelow , ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: IPSec support within BSDi 4.0? In-Reply-To: <111627409F79D2119FB100A0C9EEDC3E2E40D7@f5-exchange.win.net > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Can anyone tell me what (if any support) is present in BSDi 4.0 for IPSec >and IKE? This question is a prime candidate for the BSDI users list (bsdi-users@mailinglists.org). And/or the BSDI web site . And/or the BSDI 4.0 manual page 167. (Yes, that's a hint that IPsec and IKE are both supported.) This list is really for discussing the development of the protocol, not the implementations. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue May 4 00:16:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA25874; Tue, 4 May 1999 00:16:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20672 Tue, 4 May 1999 00:59:06 -0400 (EDT) Message-Id: <3.0.3.32.19990503220518.00c2b300@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 03 May 1999 22:05:18 -0700 To: Sankar Ramamoorthi , "'Scott G. Kelly'" , Sankar Ramamoorthi From: Alex Alten Subject: RE: INITIAL-CONTACT issues Cc: "'Stephen Kent'" , ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unfortunately I think you'll find that servers must handle lots of TCP connections, thus they may need to disconnect existing ones (say if they are idle) in order to allow new connections. - Alex At 06:51 PM 5/3/99 -0700, Sankar Ramamoorthi wrote: > >If the same TCP stream is used across rekeying, >then TCP connection overhead is not an issue - right? > >-- sankar -- > > >-----Original Message----- >From: Scott G. Kelly [mailto:skelly@redcreek.com] >Sent: Monday, May 03, 1999 6:44 PM >To: Sankar Ramamoorthi >Cc: 'Stephen Kent'; ipsec@lists.tislabs.com >Subject: Re: INITIAL-CONTACT issues > > >Sankar Ramamoorthi wrote: > > > >> I am implementing 'COMMIT' and 'INITIAL-CONTACT' etc, >> and the question I keep having is. >> 'Is there any reason why IKE is not implemented on >> top of TCP?' >> The architecture seems to allow it - most of the >> implemenations using IKE also have a tcp stack >> (atleast the one's I have seen). >> Any reason why TCP was not considered as a choice >> (atleast a SHOULD support) for carrying IKE traffic? >> > >For one thing, think about relatively rapid rekeying, and then think >about tcp connection setup overhead... > -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@lists.tislabs.com Tue May 4 00:18:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA26215; Tue, 4 May 1999 00:18:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20660 Tue, 4 May 1999 00:57:13 -0400 (EDT) Date: Tue, 4 May 1999 01:05:25 -0400 (EDT) Message-Id: <199905040505.BAA05807@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Kent CC: RL@incaa.nl, ipsec@lists.tislabs.com In-reply-to: Stephen Kent's message of Mon, 3 May 1999 15:00:18 -0400, Subject: Re: Java crypto Cipher-Block-Chaining isn't chaining Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2405 does require that the IV be a new random value for each packet, however, so an implementation which used the same IV for each packet would not comply with RFC 2405. (Nor would it be a good idea from a cryptographic point of view.) That being said, the original question was about the Java JCE, and it's not clear to me that the Java JCE was designed to be a IPSEC implementation. The JCE is just a crypto toolkit, is it not? - Ted From owner-ipsec@lists.tislabs.com Tue May 4 00:18:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA26217; Tue, 4 May 1999 00:18:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20742 Tue, 4 May 1999 01:19:17 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Alex Alten'" , Sankar Ramamoorthi , "'Scott G. Kelly'" , Sankar Ramamoorthi Cc: "'Stephen Kent'" , ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Date: Mon, 3 May 1999 22:27:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The server needs to maintain lots of ISAKMP connection states. How is keeping lots of TCP state any different? Anyways today many servers are optimized to handle lot of tcp connections. -----Original Message----- From: Alex Alten [mailto:Alten@Home.Com] Sent: Monday, May 03, 1999 10:05 PM To: Sankar Ramamoorthi; 'Scott G. Kelly'; Sankar Ramamoorthi Cc: 'Stephen Kent'; ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Unfortunately I think you'll find that servers must handle lots of TCP connections, thus they may need to disconnect existing ones (say if they are idle) in order to allow new connections. - Alex At 06:51 PM 5/3/99 -0700, Sankar Ramamoorthi wrote: > >If the same TCP stream is used across rekeying, >then TCP connection overhead is not an issue - right? > >-- sankar -- > > >-----Original Message----- >From: Scott G. Kelly [mailto:skelly@redcreek.com] >Sent: Monday, May 03, 1999 6:44 PM >To: Sankar Ramamoorthi >Cc: 'Stephen Kent'; ipsec@lists.tislabs.com >Subject: Re: INITIAL-CONTACT issues > > >Sankar Ramamoorthi wrote: > > > >> I am implementing 'COMMIT' and 'INITIAL-CONTACT' etc, >> and the question I keep having is. >> 'Is there any reason why IKE is not implemented on >> top of TCP?' >> The architecture seems to allow it - most of the >> implemenations using IKE also have a tcp stack >> (atleast the one's I have seen). >> Any reason why TCP was not considered as a choice >> (atleast a SHOULD support) for carrying IKE traffic? >> > >For one thing, think about relatively rapid rekeying, and then think >about tcp connection setup overhead... > -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@lists.tislabs.com Tue May 4 07:37:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11633; Tue, 4 May 1999 07:37:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21974 Tue, 4 May 1999 08:07:01 -0400 (EDT) Message-ID: <372ef2e6.uincaa@incaa.nl> From: RL@incaa.nl (Robert Luursema) Organization: INCAA Datacom b.v. To: "Theodore Y. Ts'o" , ipsec@lists.tislabs.com Date: Tue, 4 May 1999 14:11:33 +0200 Subject: Re: Java crypto Cipher-Block-Chaining isn't chaining Reply-to: RL@incaa.nl X-mailer: Pegasus Mail for Windows (v2.42a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 4 May 99 at 1:05, Theodore Y. Ts'o wrote: > RFC 2405 does require that the IV be a new random value for each packet, > however, so an implementation which used the same IV for each packet > would not comply with RFC 2405. (Nor would it be a good idea from a > cryptographic point of view.) > > That being said, the original question was about the Java JCE, and it's > not clear to me that the Java JCE was designed to be a IPSEC > implementation. The JCE is just a crypto toolkit, is it not? JCE = Java Cryptography Extension. Java is probably not suited for doing complete IPSEC, but is very good suited to do IKE, which is part of IPSEC. RFC 2409 defines IKE (partially), and it has the requirement that subsequent messages to be encrypted with IV = last CBC block. In the mean time I figured it out, and the questions have been answered. That does not alter the correctness of my initial observations; only they ware intentional, and the Java CBC implementation seems to be correct. Robert -- Robert Luursema R.Luursema@incaa.nl Incaa Datacom b.v. From owner-ipsec@lists.tislabs.com Tue May 4 07:45:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA11972; Tue, 4 May 1999 07:45:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21968 Tue, 4 May 1999 08:06:50 -0400 (EDT) Message-ID: <372ef2e6.uincaa@incaa.nl> From: RL@incaa.nl (Robert Luursema) Organization: INCAA Datacom b.v. To: Stephen Kent , ipsec@lists.tislabs.com Date: Tue, 4 May 1999 14:05:36 +0200 Subject: Re: Java crypto Cipher-Block-Chaining isn't chaining Reply-to: RL@incaa.nl X-mailer: Pegasus Mail for Windows (v2.42a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 3 May 99 at 15:00, Stephen Kent wrote: > CBC mode, as defined in FIPS 81 does not need to "chain" from one packet to > the next, only from one 8-byte block to the next, e.g., within a packet. > In fact, strict adherence to the FIPS does not even require a new IV for > each packet. While 2405 notes the possibility of chaining from one packet > to the next, it does not require such (no use of SHOULD, MUST, or even > MAY). Thus the Java implementation you cite appears to comply with both > 2405 and the FIPS. Thanks for your reply. I already figured it out how it should be done. RFC 2409, appendix B requires (MUST) chaining between packets. "Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector." At that time I didn't understand it, now I do. -- Robert Luursema R.Luursema@incaa.nl Incaa Datacom b.v. From owner-ipsec@lists.tislabs.com Tue May 4 09:16:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15351; Tue, 4 May 1999 09:16:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22150 Tue, 4 May 1999 09:48:55 -0400 (EDT) Message-Id: <199905041357.IAA21946@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Dan Harkins cc: Michael Barthelow , ipsec@lists.tislabs.com, carney@securecomputing.com Subject: Re: IPSec support within BSDi 4.0? In-reply-to: Your message of "Mon, 03 May 1999 17:01:05 PDT." <199905040001.RAA11674@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 4 May 1999 08:57:36 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I believe it has the NRL IPSec code and the Cisco IKE code. > > Dan. Yes it has an older version of the NRL code for the IPSec engine. The newer nrl-ipv6+ipsec-alpha-7_1_tar.gz should apply cleanly. Regards, Michael Carney > > On Mon, 03 May 1999 16:04:53 PDT you wrote > > 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_01BE95B9.5AD821E0 > > Content-Type: text/plain; > > charset="iso-8859-1" > > > > Can anyone tell me what (if any support) is present in BSDi 4.0 for IPSec and > > IKE? > > > > tia, > > > > mb > From owner-ipsec@lists.tislabs.com Tue May 4 09:20:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15511; Tue, 4 May 1999 09:19:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22161 Tue, 4 May 1999 09:50:40 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Date: Tue, 4 May 1999 09:59:13 -0400 To: Sankar Ramamoorthi From: Stephen Kent Subject: RE: INITIAL-CONTACT issues Cc: Sankar Ramamoorthi , ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar, The question of using TCP vs. UDP as a basis for IKE was discussed and resolved long ago on the IPsec list. I will leave it to other more deeply involved in IKE to answer that question. I thought you were asking a question re keepalive use for individual SAs. Steve From owner-ipsec@lists.tislabs.com Tue May 4 11:24:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19498; Tue, 4 May 1999 11:24:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22488 Tue, 4 May 1999 11:50:49 -0400 (EDT) Message-ID: <372F195F.A04EAB64@redcreek.com> Date: Tue, 04 May 1999 08:59:27 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sankar Ramamoorthi CC: "'Stephen Kent'" , ipsec@lists.tislabs.com Subject: Re: INITIAL-CONTACT issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sankar, I'm really swamped, so I don't have time to research all the reasons for the decision to use UDP instead of TCP. I joined the working group after that discussion occurred, but a little thought reveals a number of problems with your proposal. Sankar Ramamoorthi wrote: > > If the same TCP stream is used across rekeying, > then TCP connection overhead is not an issue - right? > 1) In this case the overhead is reduced, but not eliminated entirely. 2) This effectively removes identity PFS capability - a Very Bad Thing (tm). 3) One of the design requirements for ISAKMP, and hence IKE, was transport protocol independence. Requiring the use of TCP in order to provide keepalive capability is contrary to this design requirement. 4) A DoS attack is more easily mounted if the transport is TCP. I will add that the spec does not preclude the use of TCP, and you are welcome to implement ISAKMP over whatever transport you choose. However, the minimum interoperability requirement is for UDP port 500 support. Scott From owner-ipsec@lists.tislabs.com Tue May 4 13:23:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA22530; Tue, 4 May 1999 13:23:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22886 Tue, 4 May 1999 14:04:41 -0400 (EDT) Message-ID: <51BF55C30B4FD1118B4900207812701E345A88@WUHER> From: Steven Lee To: ipsec@lists.tislabs.com Subject: pre-shared key Date: Tue, 4 May 1999 14:14:42 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could anyone describe or direct me to a document that shows how pre-shared key is used to derive a DES key? I found the following information, but it doesn't describe how pre-shared key is used with Diffie-Hellman to derive k. Message 3: A -> B Hdr, g^x (Diffie-Hellman exchange), Nonce(A) Message 4: B -> A Hdr, g^y, Nonce(B) Both A and B now generate keying material keying material used to encrypt and authenticate next two messages a pre-shared key is needed at this point Message 5: A -> B Hdr, {ID(A), Hash(stuff[a])}(encrypted with k) Thanks, From owner-ipsec@lists.tislabs.com Tue May 4 16:43:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA28931; Tue, 4 May 1999 16:43:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23259 Tue, 4 May 1999 17:46:53 -0400 (EDT) Date: Wed, 5 May 1999 00:55:05 +0300 (EEST) Message-Id: <199905042155.AAA06703@kuvastin.ssh.fi> From: Tatu Ylonen To: ipsec@lists.tislabs.com Subject: SSH IKE for Solaris Organization: SSH Communications Security, Finland Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FYI, Sun has licensed SSH IKE for future versions of Solaris. This means that in future also Solaris will support IPSEC with IKE. More info at http://www.ssh.fi/. Tatu -- SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ipsec.com/ Free Unix SSH http://www.ssh.fi/sshprotocols2/ From owner-ipsec@lists.tislabs.com Wed May 5 03:56:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA17470; Wed, 5 May 1999 03:56:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA24718 Wed, 5 May 1999 04:10:33 -0400 (EDT) Message-ID: <372FFF30.37D0C6C5@checkpoint.com> Date: Wed, 05 May 1999 11:20:01 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: RL@incaa.nl CC: ipsec@lists.tislabs.com Subject: Re: Java crypto Cipher-Block-Chaining isn't chaining References: <372ef2e6.uincaa@incaa.nl> Content-Type: multipart/mixed; boundary="------------07319DC4C0AA26DA6FF5152F" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------07319DC4C0AA26DA6FF5152F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Luursema wrote: > On 3 May 99 at 15:00, Stephen Kent wrote: > > CBC mode, as defined in FIPS 81 does not need to "chain" from one packet to > > the next, only from one 8-byte block to the next, e.g., within a packet. > > In fact, strict adherence to the FIPS does not even require a new IV for > > each packet. While 2405 notes the possibility of chaining from one packet > > to the next, it does not require such (no use of SHOULD, MUST, or even > > MAY). Thus the Java implementation you cite appears to comply with both > > 2405 and the FIPS. > > Thanks for your reply. > > I already figured it out how it should be done. > > RFC 2409, appendix B requires (MUST) chaining between packets. > "Subsequent messages MUST use the last CBC encryption block from the > previous message as their initialization vector." > At that time I didn't understand it, now I do. > -- > Robert Luursema R.Luursema@incaa.nl Incaa Datacom b.v. Please note the difference between RFC2409 (IKE) and RFC2405(IPSEC-ESP-DES). While in IKE the IV is carried from packet to packet (as you have quoted), IPSEC-ESP-DES does not mandate packet chaining, it only recommends: RFC 2405: Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit. Implementation note: Common practice is to use random data for the first IV and the last 8 octets of encrypted data from an encryption process as the IV for the next encryption process; this logically extends the CBC across the packets. It also has the advantage of limiting the leakage of information from the random number generator. No matter which mechanism is used, the receiver MUST NOT assume any meaning for this value, other than that it is an IV. --------------07319DC4C0AA26DA6FF5152F Content-Type: text/x-vcard; charset=us-ascii; name="zegman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tamir Zegman Content-Disposition: attachment; filename="zegman.vcf" begin:vcard n:Zegman;Tamir tel;fax:+972-3-5759256 tel;work:+972-3-7534606 x-mozilla-html:TRUE url:www.checkpoint.com org:Check Point Software Technologies Ltd.;Encryption group adr:;;3A Jabotinsky St., Diamond Tower;Ramat-Gan;;52520;ISRAEL version:2.1 email;internet:zegman@checkpoint.com title:Software engineer fn:Tamir Zegman end:vcard --------------07319DC4C0AA26DA6FF5152F-- From owner-ipsec@lists.tislabs.com Wed May 5 11:03:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA21107; Wed, 5 May 1999 11:03:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25492 Wed, 5 May 1999 11:10:00 -0400 (EDT) Message-ID: <373060E1.5ADA2BC@indusriver.com> Date: Wed, 05 May 1999 11:16:49 -0400 From: Ben McCann X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Q: SA Bundles (again) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been dredging through the IPSEC mailing list archives to understand SA bundles and tunnel mode vs transport mode in IKE transform proposals. Dan Harkin's mail (included herein) was very helpful. I have two more questions about IKE payloads and inbound IPSEC SA bundle validation: 1. There was substantial discussion on the list about controlling transport vs. tunnel mode when multiple protocols are contained in one IKE proposal. (The consensus seemed to be that tunnel or transport mode should be the _same_ for the proposal and for all of its protocols). Does this agree with most implementations? For example, in the case of the tunnel mode SA between H1 and SG (in the example discussed in the attached mail), does most IKE implementations select (and expect) tunnel mode in _both_ the ESP(des3 md5) and AH(sha1) transform payloads? 2. Dan commented about inbound SA verification in gateway SG: "On the way back from h2 to h1 SG will see AH traffic and that'll match the selectors for that SPD entry." I'm confused about how H1 will verify inbound traffic against two SA bundles (one to H1 and another to SG). For the moment, assume my inbound IPSEC processing iteratively applies SA processing for each SA selected by protocol and SPI. It records a list of those SA's and eventually stops when it unwraps a non-IPSEC payload (such as TCP). The set of SA's (from outermost to innermost) encountered by H1 when processing a packet sent by H2 is: SG->h1 AH(sha1) SG->h1 ESP(des3,md5) h2->h1 AH(md5) h2->h1 ESP(blowfish,sha1) Now that I've unwrapped the innermost payload (i.e. TCP), I look for an SPD that covers H2 to H1 traffic. I'm _assuming_ that there are _TWO_ SPD entries corresponding to the two bundles: "Actually there are 2 bundles here. One is AH and ESP protecting traffic from h1 to h2, with destination h2, and another of AH and ESP protecting AH (since that'll be the protocol of the packet as it comes by) from h1 to h2, with destination SG." Those two SPD entries, in order, are: src=h1, dst=h2, prot=AH -> tunnel(SG) ESP(des3 md5) AH(sha1) src=h1, dst=h2, prot=ANY -> ESP(blowfish,sha1) AH(md5) The inbound IPSEC engine must validate the SA's that were applied to the packet by the sender. After applying four SA's to the packet, it uncovers some transport protocol and then searches the SPD. It finds the rule: src=h1, dst=h2, prot=ANY -> ESP(blowfish,sha1) AH(md5) There are only _two_ SA's bound to this rule (ESP and AH) but the number of SA's encountered by the packet during inbound processing was _four_. ==> Shouldn't the inbound IPSEC engine drop the packet because the ==> processing applied to it doesn't match the processing mandated ==> by the SPD? How is this resolved? For example: 1. Should H1 have three SPD entries, two for outbound and one for inbound? The inbound SPD entry lists all of the protocols contained in the two outbound SPD entries. 2. Should I have just one SPD entry that creates two bundles? There was some discussion on the list about single SPD entries that create multiple IKE Phase 1 and 2 SA's to separate IPSEC peers. (I personally prefer SPD entries that only address one other IPSEC peer thus I much rather follow the implementation described in Dan's mail). 3. Should the implementation search the SPD after _every_ application of an SA? If I did this, then we would get a match against the first SPD entry after applying the first two SA's. (This completes the processing of bundle between H1 and SG). Then, we empty the list of processed SA's bound to the packet and continue processing. This accumulates two more SA's for the bundle between H1 and H2. Thanks, Ben McCann P.S. Where's Dan Harkins? His e-mail address at Cisco has been disabled. Daniel Harkins wrote: > > On Fri, 22 Jan 1999 21:17:07 +0200 Markku Savela wrote > > > > For example, policy on H1 could be > > > > "dst=h2" -> ESP(blowfish,sha1) AH(md5) tunnel(SG) ESP(des3 md5) AH(sha1) > > <-----SA's with h2 ----> <---SA's with SG - --> > > > > Transforms applied to outgoing packet in the order they are listed > > above. H2 would generate following independent ACQUIRE's: > > > > ACQUIRE: h1->h2 ESP(blowfish,sha1) > > ACQUIRE: h1->h2 AH(md5) > > ACQUIRE: h1->SG ESP(des3,md5) > > ACQUIRE: h1->SG AH(sha1) > > > > The order of the ACQUIRE's is totally irrelevant to my IPSEC. The > > packet can go out when all of them complete. With matching policies at > > SG and H2, my version of IPSEC can verify that the required transforms > > are done in the order as specified by the policy. It does not need > > any bundling support from the key management. > > As the Prime Minister says during Prime Minister's Question Time, "I refer > the Right Honourable Gentleman to the comments I made some moments ago". > Specificially, those in 199901221728.JAA10408@chip.cisco.com. > > > The question that now worries me: > > > > My implementation cannot communicate with other IPSEC > > implementations, because they require SAs to be negotiated in > > bundles by ISAKMP? > > > > (A side note: in above, I need to negotiate with H2 and SG. At > > H1 there is one bundle, but the bundles that SG and H2 see, > > are only subsets of it. So, In ISAKMP world, H1 needs to split > > the big bundle into two bundles?) > > Actually there are 2 bundles here. One is AH and ESP protecting traffic > from h1 to h2, with destination h2, and another of AH and ESP protecting AH > (since that'll be the protocol of the packet as it comes by) from h1 to h2, > with destination SG. > > SG can't have policy with selectors identifying traffic from h1 to h2 > because it won't be able to look into the packet to identify that traffic. > Also there's no mechanism to inform SG of the SPI chosen by h2 to use to > protect this traffic. SG must have selectors for AH from h1 to h2. Since > you're assuming identical configs on each side h1 must also have selectors > to identify AH traffic to h2 for bundle #2. The selectors on h1 have to > be different for each bundle. > > The way this works in our implementation is that the packet from h1 to h2 > triggers an IKE negotiation to h2 to negotiate bundle #1. Depending on > policy (whether h1 and SG say that IKE traffic to h2 must also be IPSec > protected with the rest of the h1->h2 traffic) that may trigger another IKE > exchange with SG for bundle #2. If it doesn't, if IKE can go in the clear, > then the IKE exchange for bundle #2 is triggered by the first IPSec protected > packet from h1 to h2, which will have a protocol of AH. Once the 2nd IKE > exchange is finished the nested tunnels are formed and everything works. On > the way back from h2 to h1 SG will see AH traffic and that'll match the > selectors for that SPD entry. > > > How do I solve this problem? Does ISAKMP allow me to generate SAs > > individually, while other IPSEC still does the bundle checking > > correctly (it should, there are lots of verbage in RFC-2401 about > > checking the bundles while assuming totally random collection of SAs > > in SAD; at least my implementation is done that way). > > You can generate them one at a time and IKE will express them as atomic units > but as I said I think your implementation will have trouble talking to other > implementations sometimes. > > > One more clarification: I don't have a key management implemented > > myself, only the IPSEC kernel. > > We have key management and also IPSec and nested tunnels with bundled SAs-- > what you described above-- work just fine. Of course, we're not using PFKEYv2 > and, therefore, are not restricted to individual, non-conjunctive, ACQUIREs. > > Dan. -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu May 6 06:54:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28409; Thu, 6 May 1999 06:54:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28527 Thu, 6 May 1999 07:52:24 -0400 (EDT) Message-ID: <373184C4.5BD06264@indusriver.com> Date: Thu, 06 May 1999 12:02:12 +0000 From: Ben McCann X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.7 i586) X-Accept-Language: en MIME-Version: 1.0 To: kent@bbn.com CC: ipsec@lists.tislabs.com, bmccann@indusriver.com Subject: Automatic SPD Entry Creation for Remote Access IPSEC Clients Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, You posted a message to the IPSEC list (a while ago) that described dynamic creation of new inbound SPD entries for remote access clients with dynamically assigned addresses. (I.e. addresses unknown to the local system). Your rationale was that you needed to the new SPD entry to provide the final validation check for inbound packet processing. Is this always necessary? For example, please assume my inbound SPD states all UDP port 1701 (L2TP) traffic from _ANY_ address must be encrypted using Transport mode ESP(3DES-SHA). Also assume that SPD entry requires SAD element derivation (creation) using the addresses, ports, etc from the packet. (This derivation mechanism is discussed on pages 14-15 of RFC 2401). As multiple remote peers establish SA's, each of their SAD entries is created using their source IP address as defined by the IKE phase 2 identity. (I'm getting fuzzy here so please correct me if I'm wrong on this). All of those SAD entries are bound to the single SPD which contained the _ANY_ source address wildcard value. Is this an acceptable alternative to dynamically creating SPD entries? Perhaps I can answer my own question. The specific packet that triggered the SA creation is not known in the _responding_ system therefore there is insufficient information to create the SAD element. That is why you recommended waiting until the first IPSEC packet arrives and then creating the SPD entry from that. Could you create the SAD entry and bind it to the wildcard source address SPD entry instead? -Ben McCann -- --- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu May 6 06:56:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28433; Thu, 6 May 1999 06:56:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28482 Thu, 6 May 1999 07:45:07 -0400 (EDT) Message-Id: <199905061152.HAA21448@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-policy-schema-00.txt Date: Thu, 06 May 1999 07:52:51 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec Policy Schema Author(s) : J. Jason, M. Jeronimo Filename : draft-ietf-ipsec-policy-schema-00.txt Pages : 13 Date : 05-May-99 This document presents an object-oriented model of IPsec policy in order to facilitate agreement about the content and semantics of IPsec policy and to enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-policy-schema-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-policy-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-policy-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990505084040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-policy-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-policy-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990505084040.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu May 6 09:57:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA00250; Thu, 6 May 1999 09:57:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28980 Thu, 6 May 1999 10:15:11 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199905061422.HAA08967@kc.livingston.com> Subject: Re: Automatic SPD Entry Creation for Remote Access IPSEC Clients To: bmccann@indusriver.com (Ben McCann) Date: Thu, 6 May 1999 07:22:53 -0700 (PDT) Cc: kent@bbn.com, ipsec@lists.tislabs.com, bmccann@indusriver.com In-Reply-To: <373184C4.5BD06264@indusriver.com> from "Ben McCann" at May 6, 99 12:02:12 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Hi Steve, > > You posted a message to the IPSEC list (a while ago) that described > dynamic creation of new inbound SPD entries for remote access clients > with dynamically assigned addresses. (I.e. addresses unknown to the > local system). Your rationale was that you needed to the new SPD entry > to provide the final validation check for inbound packet processing. > > Is this always necessary? > I believe, so. > For example, please assume my inbound SPD states all UDP port 1701 > (L2TP) traffic from _ANY_ address must be encrypted using Transport > mode ESP(3DES-SHA). Also assume that SPD entry requires SAD element > derivation (creation) using the addresses, ports, etc from the packet. > (This derivation mechanism is discussed on pages 14-15 of RFC 2401). > So, you wish to have transport mode IPsec SAs established from an LNS system to a variety of LACs that connect to it, based on the packet selection criteria of src/dest address and src/dest ports. I donot perceive LACs as the remote access clients, generally speaking. But, I guess, this will do for the example you are exploring. > As multiple remote peers establish SA's, each of their SAD entries > is created using their source IP address as defined by the IKE > phase 2 identity. (I'm getting fuzzy here so please correct me if > I'm wrong on this). All of those SAD entries are bound to the > single SPD which contained the _ANY_ source address wildcard value. > > Is this an acceptable alternative to dynamically creating SPD > entries? > OK, here is where the issue is. You are creating a new SA for each new selection criteria of the packets. I.e., the security association (SA) created refers to a specific variation of the policy (any address, any port, my address, my LNS UDP port 1701), based on the packet for which the SA is being created. Creating a new pair of (SPD entry, inbound/outbound SAs) is important on the inbound to ensure that the SA attributes (ex: keys) are not being used by anyone that is not party to the SPD selection criteria. Creating a new pair of (SPD entry, inbound/outbound SAs) is also important on the outbound so you know which specific SA to use for an outbound packet. > > Perhaps I can answer my own question. The specific packet that triggered > the SA creation is not known in the _responding_ system therefore > there is insufficient information to create the SAD element. That is > why you recommended waiting until the first IPSEC packet arrives and then > creating the SPD entry from that. > You create a new pair of (SPD, SAD) entries when IKE phase II ID is received. I assume, this is what you meant by the first IPsec packet. > Could you create the SAD entry and bind it to the wildcard source > address SPD entry instead? > Please see my comments earlier. > -Ben McCann > > -- > --- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 > cheers, suresh From owner-ipsec@lists.tislabs.com Fri May 7 00:24:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA04720; Fri, 7 May 1999 00:24:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05813 Fri, 7 May 1999 01:09:38 -0400 (EDT) Message-Id: <3.0.3.32.19990506221537.00bbb100@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 06 May 1999 22:15:37 -0700 To: "Scott G. Kelly" , Sankar Ramamoorthi From: Alex Alten Subject: Re: INITIAL-CONTACT issues Cc: "'Stephen Kent'" , ipsec@lists.tislabs.com In-Reply-To: <372F195F.A04EAB64@redcreek.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have some questions for the WG. Has anyone had deployment experience with IKE? Do actual customers like it running over UDP? Is there any resistance with opening an IKE UDP port in firewalls? - Alex At 08:59 AM 5/4/99 -0700, Scott G. Kelly wrote: >Hi Sankar, > >I'm really swamped, so I don't have time to research all the reasons for >the decision to use UDP instead of TCP. I joined the working group after >that discussion occurred, but a little thought reveals a number of >problems with your proposal. > >Sankar Ramamoorthi wrote: >> >> If the same TCP stream is used across rekeying, >> then TCP connection overhead is not an issue - right? >> > >1) In this case the overhead is reduced, but not eliminated entirely. > >2) This effectively removes identity PFS capability - a Very Bad Thing >(tm). > >3) One of the design requirements for ISAKMP, and hence IKE, was >transport protocol independence. Requiring the use of TCP in order to >provide keepalive capability is contrary to this design requirement. > >4) A DoS attack is more easily mounted if the transport is TCP. > >I will add that the spec does not preclude the use of TCP, and you are >welcome to implement ISAKMP over whatever transport you choose. However, >the minimum interoperability requirement is for UDP port 500 support. > >Scott > -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@lists.tislabs.com Fri May 7 11:20:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14663; Fri, 7 May 1999 11:20:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14489 Fri, 7 May 1999 12:03:51 -0400 (EDT) Message-ID: <37331134.B61CE32A@redcreek.com> Date: Fri, 07 May 1999 09:13:40 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Alten CC: Sankar Ramamoorthi , ipsec@lists.tislabs.com Subject: Re: INITIAL-CONTACT issues References: <3.0.3.32.19990506221537.00bbb100@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten wrote: > > I have some questions for the WG. > > Has anyone had deployment experience with IKE? Lots of us have. > Do actual customers like it running over UDP? Many don't know what UDP is, much less care. Also, in my experience most have no idea what protocol IKE runs over. > Is there any resistance with opening an IKE UDP > port in firewalls? > Yes, some, and this applies to esp and ah as well as udp/ike. There are basically 3 cases for deployment: (1) the SAs run through the firewall to hosts inside, (2) the SAs terminate at the firewall, and (3) the ipsec device is in front of the firewall, so the firewall never sees ipsec traffic. The only time the hole is an issue is for case 1. Scott From owner-ipsec@lists.tislabs.com Fri May 7 16:43:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05748; Fri, 7 May 1999 16:43:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15493 Fri, 7 May 1999 17:39:39 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.19990506221537.00bbb100@mail> References: <372F195F.A04EAB64@redcreek.com> Date: Fri, 7 May 1999 17:45:34 -0400 To: Alex Alten From: Stephen Kent Subject: Re: INITIAL-CONTACT issues Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, >Has anyone had deployment experience with IKE? >Do actual customers like it running over UDP? >Is there any resistance with opening an IKE UDP >port in firewalls? Folks at several companies have cited problems getting IPsec traffic through in general, whether UPD for IKE or AH or ESP. Steve From owner-ipsec@lists.tislabs.com Sat May 8 00:50:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA26456; Sat, 8 May 1999 00:50:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16029 Fri, 7 May 1999 23:30:03 -0400 (EDT) Message-ID: <59726335C162D111B2CF00805FA7205D02FE9B23@csifiapp621.wepex.net> From: "Burden, James" To: "'Stephen Kent'" , Alex Alten Cc: ipsec@lists.tislabs.com Subject: RE: INITIAL-CONTACT issues Date: Fri, 7 May 1999 20:37:49 -0700 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 Greetings, I have been lurking and learning on here for awhile. This was written a couple of days ago, but I did not send it as I thought the UDP debate would have died as it did in the Intrusion Detection Work Group (IDWG). Personally, I am wary of allowing any UDP through a firewall. A couple of thoughts come to mind. With UDP, the application (layer) must keep session information (or not), do error checking, and ensure security. In addition, UDP requires some mechanism to prevent IP spoofing. This is all done at layer 7. The application (and the implementation) must be trusted, and you could potentially lose your defense in depth with the firewall. I would agree that a DoS attack is easily mounted against TCP, but it would be easier to defend than UDP. The IETF's IDWG discussed using UDP for transport. Below is a URL to the archives. Jim http://www.semper.org/idwg-public/0191.html: From: Chad Schieken Message-Id: <199903101910.OAA02823@monet.op.net> Subject: Re: SNMP satisfies most requirements To: cuber@omaha.com Date: Wed, 10 Mar 1999 14:10:33 -0500 (EST) In-Reply-To: <36E6BDB8.1517BF7D@omaha.com> from "Uber, Chet" at Mar 10, 99 12:45:12 pm That's a good point, my answer to the question is that is upto the transport method used. Most transports, TCP/IP, UDP don't have much, but it's still possible to create secure serivces using them, look at ssh an example. I think I should point out that I personally don't think that a stateless protocol (UDP) is appropreate to use if we're going to want secure channels of commincation built ontop of it. However obviously it's a tradeoff. UD P simply has alot less overhead, which makes it attractive in some situations.j Too bad ttcp didn't really take off (http://www.cis.udel.edu/~sezen/ttcp.html) that would be my suggestion for the transport mechanism. If it were more widely adopted. > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Tuesday, May 04, 1999 8:59 AM > To: Sankar Ramamoorthi > Cc: 'Stephen Kent'; ipsec@lists.tislabs.com > Subject: Re: INITIAL-CONTACT issues > > > Hi Sankar, > > I'm really swamped, so I don't have time to research all the > reasons for > the decision to use UDP instead of TCP. I joined the working > group after > that discussion occurred, but a little thought reveals a number of > problems with your proposal. > > Sankar Ramamoorthi wrote: > > > > If the same TCP stream is used across rekeying, > > then TCP connection overhead is not an issue - right? > > > > 1) In this case the overhead is reduced, but not eliminated entirely. > > 2) This effectively removes identity PFS capability - a Very Bad Thing > (tm). > > 3) One of the design requirements for ISAKMP, and hence IKE, was > transport protocol independence. Requiring the use of TCP in order to > provide keepalive capability is contrary to this design requirement. > > 4) A DoS attack is more easily mounted if the transport is TCP. > > I will add that the spec does not preclude the use of TCP, and you are > welcome to implement ISAKMP over whatever transport you > choose. However, > the minimum interoperability requirement is for UDP port 500 support. > > Scott > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, May 07, 1999 2:46 PM > To: Alex Alten > Cc: ipsec@lists.tislabs.com > Subject: Re: INITIAL-CONTACT issues > > > Alex, > > >Has anyone had deployment experience with IKE? > >Do actual customers like it running over UDP? > >Is there any resistance with opening an IKE UDP > >port in firewalls? > > Folks at several companies have cited problems getting IPsec traffic > through in general, whether UPD for IKE or AH or ESP. > > Steve > James L. Burden, Security Engineer and Architect California Independent System Operator Phone: 916.351.2243 http://www.caiso.com 41DF 0E4C 26E0 2FD3 8C81 A260 5C40 280E B4AE 7420 ____________________________________________ Know yourself, Know your enemy in a hundred battles you will never be in danger, Know the ground, Know the weather, and your victory will be total. - Sun Tzu "The Art of War" ____________________________________________ From owner-ipsec@lists.tislabs.com Sat May 8 01:16:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26609; Sat, 8 May 1999 01:16:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA16104 Sat, 8 May 1999 00:40:14 -0400 (EDT) Message-Id: <3.0.3.32.19990507214032.00b7a320@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 07 May 1999 21:40:32 -0700 To: Stephen Kent From: Alex Alten Subject: Re: INITIAL-CONTACT issues Cc: ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.19990506221537.00bbb100@mail> <372F195F.A04EAB64@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:45 PM 5/7/99 -0400, Stephen Kent wrote: >Alex, > >>Has anyone had deployment experience with IKE? >>Do actual customers like it running over UDP? >>Is there any resistance with opening an IKE UDP >>port in firewalls? > >Folks at several companies have cited problems getting IPsec traffic >through in general, whether UPD for IKE or AH or ESP. > >Steve > Hmm...I've been hearing for the past year about large corporate customers (with network security aware IS staff) being very resistance about opening up a new UDP port in their firewalls for incoming and outgoing packets (this happens to be a proprietary authentication protocol over UDP). I was wondering if anyone selling an IKE over UDP solution has experienced this resistance as well. These customers seem willing to do TCP. - Alex -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@lists.tislabs.com Sat May 8 03:18:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA29346; Sat, 8 May 1999 03:18:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16435 Sat, 8 May 1999 04:16:15 -0400 (EDT) Message-Id: <199905080824.LAA05637@torni.ssh.fi> From: "Rodney Thayer" To: Alex Alten , "Scott G. Kelly" Date: Fri, 7 May 1999 11:24:22 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: INITIAL-CONTACT issues Reply-to: rodney@ssh.fi CC: Sankar Ramamoorthi , ipsec@lists.tislabs.com In-reply-to: <37331134.B61CE32A@redcreek.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some of us are not terribly thrilled with the unreliable nature of UDP and the retry burden placed on IKE. Van Jacobsen's law applies -- "People who don't use TCP are doomed to re-invent it." Try running an IKE session between San Jose California and somewhere in the eastern Mediterranean and watch the pretty retry- logic crashes. Date sent: Fri, 07 May 1999 09:13:40 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications To: Alex Alten Copies to: Sankar Ramamoorthi , ipsec@lists.tislabs.com Subject: Re: INITIAL-CONTACT issues > > > Alex Alten wrote: > > > > I have some questions for the WG. > > > > Has anyone had deployment experience with IKE? > > Lots of us have. > > > Do actual customers like it running over UDP? > > Many don't know what UDP is, much less care. Also, in my experience most > have no idea what protocol IKE runs over. > > > Is there any resistance with opening an IKE UDP > > port in firewalls? > > > > Yes, some, and this applies to esp and ah as well as udp/ike. There are > basically 3 cases for deployment: (1) the SAs run through the firewall to > hosts inside, (2) the SAs terminate at the firewall, and (3) the ipsec > device is in front of the firewall, so the firewall never sees ipsec > traffic. The only time the hole is an issue is for case 1. > > Scott > From owner-ipsec@lists.tislabs.com Sat May 8 08:13:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00491; Sat, 8 May 1999 08:13:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16752 Sat, 8 May 1999 09:14:12 -0400 (EDT) Message-ID: <37343A63.B5254FE1@ix.netcom.com> Date: Sat, 08 May 1999 06:21:39 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: rodney@ssh.fi CC: Alex Alten , "Scott G. Kelly" , Sankar Ramamoorthi , ipsec@lists.tislabs.com Subject: Re: INITIAL-CONTACT issues References: <199905080824.LAA05637@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rodney Thayer wrote: > > Some of us are not terribly thrilled with the unreliable nature of UDP > and the retry burden placed on IKE. Van Jacobsen's law applies -- > "People who don't use TCP are doomed to re-invent it." > > Try running an IKE session between San Jose California and > somewhere in the eastern Mediterranean and watch the pretty retry- > logic crashes. > (posting from home) Before this goes any further, let me say that I too struggle with the problems inherent in the UDP decision, in which I didn't participate. I was just attempting to reconstruct some of the arguments that must have gone into it, and I'll add that the arguments are not entirely without merit. I assume you were involved in that original discussion in some fashion, Rodney. I was not participating in the ipsec wg whenever this occurred, but I assume the usual hearty debate occurred, and that this decision is on par with other ipsec consensus design decisions in terms of caliber. Am I being naive? Scott From owner-ipsec@lists.tislabs.com Sat May 8 08:16:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00516; Sat, 8 May 1999 08:16:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16796 Sat, 8 May 1999 09:37:09 -0400 (EDT) Message-ID: <37343FC2.6AF40712@ix.netcom.com> Date: Sat, 08 May 1999 06:44:34 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Burden, James" CC: "'Stephen Kent'" , Alex Alten , ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) References: <59726335C162D111B2CF00805FA7205D02FE9B23@csifiapp621.wepex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Burden, James" wrote: > > Greetings, > > I have been lurking and learning on here for awhile. This was written a > couple of days ago, but I did not send it as I thought the UDP debate would > have died as it did in the Intrusion Detection Work Group (IDWG). > Personally, I am wary of allowing any UDP through a firewall. Question: why would you be less wary of allowing tcp through? > A couple of thoughts come to mind. With UDP, the application (layer) must > keep session information (or not), do error checking, and ensure security. Is this any different with TCP? > In addition, UDP requires some mechanism to prevent IP spoofing. This is > all done at layer 7. The application (and the implementation) must be > trusted, and you could potentially lose your defense in depth with the > firewall. Again, why would tcp be different? > I would agree that a DoS attack is easily mounted against TCP, but it would > be easier to defend than UDP. How so? > The IETF's IDWG discussed using UDP for transport. Below is a URL to the > archives. > Jim additional comments follow in a new thread... From owner-ipsec@lists.tislabs.com Sat May 8 08:24:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA00590; Sat, 8 May 1999 08:24:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16825 Sat, 8 May 1999 09:41:49 -0400 (EDT) Message-ID: <373440DB.8A4ECF76@ix.netcom.com> Date: Sat, 08 May 1999 06:49:15 -0700 From: "Scott G. Kelly" X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Alten CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) References: <3.0.3.32.19990506221537.00bbb100@mail> <372F195F.A04EAB64@redcreek.com> <3.0.3.32.19990507214032.00b7a320@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk These are really 2 different discussions: one pertains to the IKE transport mechanism, and the other pertains ipsec/firewall issues. I think the two are independent, so I split them. It seems to me that firewall administrators are almost always going to be uncomfortable with letting *anything* through, given that it is their competence which is questioned should a breach occur. Again, we have the 3 situations I described in an earlier email, and I think the only problematic situation is when an end-user behind a firewall wants to establish (or permit) a secured session *through* the firewall. Some administrators simply refuse, saying "I can't see what's in the encrypted traffic, and that's unacceptable". I see no solution in this case, since they do not trust their internal systems/users. Tough situation. For clarity, here's a picture: +-----+ +----+ +-----+ | E1 |--------| FW |===INTERNET====| E2 | +-----+ +----+ +-----+ The users are E1 and E2, the firewall is FW. E1 wants to establish a SA pair with E2. The admin of FW is afraid to simply permit the encrypted flow. Some administrators may be willing to permit the session if they can authenticate E2 (and perhaps E1). This requires ipsec support in the firewall, which eventually all firewall-type systems will support (I think). In this case, the firewall will in any event establish a secured session with the external endpoint, through which the traffic between the endpoints will flow. That looks like this: +-----+ +----+ ipsec tunnel +-----+ | E1 |--------| FW |===============| E2 | +-----+ +----+ +-----+ The final decision pertains to whether or not E1 and E2 may exchange encrypted (or even authenticated) traffic. If the answer is no, then E1 could still get some additional protection by establishing a tunnel to FW in which E2's traffic is carried. If the answer is yes, we're done. Scott From owner-ipsec@lists.tislabs.com Sun May 9 08:32:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07481; Sun, 9 May 1999 08:32:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18981 Sun, 9 May 1999 09:17:37 -0400 (EDT) Message-Id: <4.1.19990509084955.0321f100@pop.erols.com> X-Sender: jehorton@pop.erols.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 09 May 1999 09:23:34 -0400 To: "Scott G. Kelly" , Alex Alten From: "John E. Horton" Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) Cc: Stephen Kent , ipsec@lists.tislabs.com In-Reply-To: <373440DB.8A4ECF76@ix.netcom.com> References: <3.0.3.32.19990506221537.00bbb100@mail> <372F195F.A04EAB64@redcreek.com> <3.0.3.32.19990507214032.00b7a320@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The 3 situations Scott has described are actually system integration strategies that administrators can use with VPN devices. As a field engineer for a VPN company who has integrated many systems in customer locations, I feel that I can provide a real world view of this issue. If this is off topic, my apoligies to the list. The objection sysadmins have to two of these strategies - parallel and behind the firewall - are because policies that control application level traffic bypass the firewall. Additionally, because the firewalls typically control TCP/UDP packets, sysadmins have trouble establishing policies for IPSec packets (IPSEC 50/51) in the firewall. Integrating in front of a firewall is problematic when the firewall controlls access from public networks to private networks (eg 10.x.x.x networks). There is a fourth integration method that has been successfully used. This implementation is to insert a third NIC in the firewall, create a trusted/private network, and connect the VPN device to that third NIC. The sysadmins are able to establish policies to application traffic that comes through the VPN. However, sysadmins who object to "fiddling" with their operational firewall usually end up adopting the parallel method. Integrating a VPN device behind a firewall has been found to be problematic when NAT is implemented as a firewall policy. I have found that working with devices that provide AH header & ESP trailer, and provide the ability of the administrator to generate a NULL digital signature for packet level authentication have proven to be successful. I can hear the howls now. Customer education is very important here because the ramifications of establishing such a policy must be explained to the customer. Having been educated, the administrator is then able determine if the implementation of such a policy with respect to VPN traffic is acceptable. Such an implementation works mainly for site to site VPNs, and has been found to be problematic with remote access VPN implementations. At 06:49 AM 5/8/99 -0700, Scott G. Kelly wrote: >These are really 2 different discussions: one pertains to the IKE >transport mechanism, and the other pertains ipsec/firewall issues. I >think the two are independent, so I split them. It seems to me that >firewall administrators are almost always going to be uncomfortable with >letting *anything* through, given that it is their competence which is >questioned should a breach occur. > >Again, we have the 3 situations I described in an earlier email, and I >think the only problematic situation is when an end-user behind a >firewall wants to establish (or permit) a secured session *through* the >firewall. Some administrators simply refuse, saying "I can't see what's >in the encrypted traffic, and that's unacceptable". I see no solution in >this case, since they do not trust their internal systems/users. Tough >situation. > >For clarity, here's a picture: > > +-----+ +----+ +-----+ > | E1 |--------| FW |===INTERNET====| E2 | > +-----+ +----+ +-----+ > >The users are E1 and E2, the firewall is FW. E1 wants to establish a SA >pair with E2. The admin of FW is afraid to simply permit the encrypted >flow. > >Some administrators may be willing to permit the session if they can >authenticate E2 (and perhaps E1). This requires ipsec support in the >firewall, which eventually all firewall-type systems will support (I >think). In this case, the firewall will in any event establish a secured >session with the external endpoint, through which the traffic between >the endpoints will flow. That looks like this: > > > +-----+ +----+ ipsec tunnel +-----+ > | E1 |--------| FW |===============| E2 | > +-----+ +----+ +-----+ > >The final decision pertains to whether or not E1 and E2 may exchange >encrypted (or even authenticated) traffic. If the answer is no, then E1 >could still get some additional protection by establishing a tunnel to >FW in which E2's traffic is carried. If the answer is yes, we're done. > >Scott From owner-ipsec@lists.tislabs.com Mon May 10 01:05:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26845; Mon, 10 May 1999 01:05:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20149 Mon, 10 May 1999 01:37:31 -0400 (EDT) Message-Id: <199905100545.IAA13287@torni.ssh.fi> From: "Rodney Thayer" To: Alex Alten , "Scott G. Kelly" Date: Mon, 10 May 1999 08:45:33 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) Reply-to: rodney@ssh.fi CC: Stephen Kent , ipsec@lists.tislabs.com In-reply-to: <373440DB.8A4ECF76@ix.netcom.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If the administrator feels that way, then I think the compromise I'd like the architecture to support is this: (minimal portions of forwarded mail copied...) > +-----+ +----+ +-----+ > | E1 |--------| FW |===INTERNET====| E2 | > +-----+ +----+ +-----+ 1. Establish an authentication-only connection between E1 and FW. This allows the operator of FW to 'trust' E1 (or not) 2. Somehow (inside the E1->FW tunnel?) E1 is then permitted to establish a tunnel with E2. Note this might require something mildly bizarre like running IKE _through_ an E1->FW, Auth-only tunnel. So suddenly I'd want E1 to allow IKE over 'raw' IP to FW as well as IKE over 'tunnelled' IP to E2. Alternatively, you have two 'butted tunnels', a tunnel from E1-FW, Auth-only, and a tunnel from FW to E2, encrypted and such. Date sent: Sat, 08 May 1999 06:49:15 -0700 From: "Scott G. Kelly" > ... I > think the only problematic situation is when an end-user behind a firewall > wants to establish (or permit) a secured session *through* the firewall. > Some administrators simply refuse, saying "I can't see what's in the > encrypted traffic, and that's unacceptable". I see no solution in this > case, since they do not trust their internal systems/users. From owner-ipsec@lists.tislabs.com Mon May 10 02:14:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27330; Mon, 10 May 1999 02:14:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA20326 Mon, 10 May 1999 03:03:24 -0400 (EDT) Message-ID: <3736863E.17911DD2@aar.alcatel-alsthom.fr> Date: Mon, 10 May 1999 09:09:50 +0200 From: Sihem Tiouajni Organization: Alcatel X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: IPsec implementation Content-Type: multipart/alternative; boundary="------------10D7F9C625C709BDE832BD07" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------10D7F9C625C709BDE832BD07 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have just subscribed to the IPsec mailing list because I would like to implement IPsec. As I am still not experienced wit IPsec, could you indicate me how to implement an IPsec stack ? Thank you for your help Sihem -- -------------------------------- Sihem TIOUAJNI Corporate Research Center Alcatel, Route de Nozay 91461 Marcoussis Cedex - France Tel: 01 69 63 41 17 -------------------------------- --------------10D7F9C625C709BDE832BD07 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I have just subscribed to the IPsec mailing list because I would like to implement IPsec.

As I am still not experienced wit IPsec, could you indicate me how to implement an IPsec stack ?

Thank you for your help

Sihem

-- 
--------------------------------
        Sihem TIOUAJNI
   Corporate Research Center
    Alcatel, Route de Nozay     
91461 Marcoussis Cedex - France
      Tel: 01 69 63 41 17
--------------------------------

--------------10D7F9C625C709BDE832BD07-- From owner-ipsec@lists.tislabs.com Mon May 10 04:48:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00727; Mon, 10 May 1999 04:48:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20753 Mon, 10 May 1999 05:16:38 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC385A12@new-exc1.ctron.com> From: "Waters, Stephen" To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: RE: ipsec through firewalls (was re:INITIAL-CONTACT issues) Date: Mon, 10 May 1999 10:24:53 +0100 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 Firewall Q: Firewall? What firewall? I know it is a leap of faith, but folk will just have to get used to trusting their IPSEC security gateways. If you can get that far, then you don't need a Firewall for the IPSEC tunnel traffic, so you don't have to poke holes. If you want to share an Internet connection for Firewalls and Security Gateways, you can set them up in parallel: (hope this line picture comes out...) Internet====Packet-Filter Router--------Firewall-----Intranet | -----SG----------Intranet i.e. the Firewall and SG both have exposure to whatever gets past the rough packet filtering of the Internet-connected router. Any application level policy can be either part of the IPSEC policy, or implemented 'out-side' IPSEC in a firewall style. Another option used by some is to feed the 'Intanet' tap of the SG back into the firewall, it all depends on what sort of policies are in place for 'private' traffic - after all, the IPSEC Tunnel should be providing the equivalent of a leased line connection to a remote office - typically there is no restriction on this traffic. In the case of Extranet links to partners, then you have more of a problem. My suggests would be (not that I know squat about firewalls): For 'private' tunnels, use an SG in parallel with simple level 2 policy. For Extranet tunnels, use an SG in parallel or use tunnel support within the firewall (if any). For the parallel SG case, either make provision within the SG for additional policy control, or feed Extranet tunnels back into the firewall (as mentioned by another noter). TCP Q: There do seem to be some cracks showing in IKE connection phase (we have been using a lot of IKE duct-tape lately). I guess it would not take us too long to get IKE running over TCP instead - it may be worth a try, and we may even offer the option for like-to-like running, if it makes life easier. Steve. From: Scott G. Kelly [ mailto:sgkelly@ix.netcom.com ] Sent: Saturday, May 08, 1999 2:49 PM To: Alex Alten Cc: Stephen Kent; Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) These are really 2 different discussions: one pertains to the IKE transport mechanism, and the other pertains ipsec/firewall issues. I think the two are independent, so I split them. It seems to me that firewall administrators are almost always going to be uncomfortable with letting *anything* through, given that it is their competence which is questioned should a breach occur. Again, we have the 3 situations I described in an earlier email, and I think the only problematic situation is when an end-user behind a firewall wants to establish (or permit) a secured session *through* the firewall. Some administrators simply refuse, saying "I can't see what's in the encrypted traffic, and that's unacceptable". I see no solution in this case, since they do not trust their internal systems/users. Tough situation. For clarity, here's a picture: +-----+ +----+ +-----+ | E1 |--------| FW |===INTERNET====| E2 | +-----+ +----+ +-----+ The users are E1 and E2, the firewall is FW. E1 wants to establish a SA pair with E2. The admin of FW is afraid to simply permit the encrypted flow. Some administrators may be willing to permit the session if they can authenticate E2 (and perhaps E1). This requires ipsec support in the firewall, which eventually all firewall-type systems will support (I think). In this case, the firewall will in any event establish a secured session with the external endpoint, through which the traffic between the endpoints will flow. That looks like this: +-----+ +----+ ipsec tunnel +-----+ | E1 |--------| FW |===============| E2 | +-----+ +----+ +-----+ The final decision pertains to whether or not E1 and E2 may exchange encrypted (or even authenticated) traffic. If the answer is no, then E1 could still get some additional protection by establishing a tunnel to FW in which E2's traffic is carried. If the answer is yes, we're done. Scott From owner-ipsec@lists.tislabs.com Mon May 10 08:28:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02584; Mon, 10 May 1999 08:28:56 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21263 Mon, 10 May 1999 08:50:28 -0400 (EDT) Date: Mon, 10 May 1999 08:50:28 -0400 (EDT) Message-Id: <199905101250.IAA21263@lists.tislabs.com> (8.8.8/8.7.3) with ESMTP id XAA03960 for ; Fri, 7 May 1999 23:09:58 -0400 (EDT) Message-ID: <3733D528.1D9FAEEC@netrover.com> Date: Fri, 07 May 1999 23:09:45 -0700 From: Loretta Zhou X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Question on IV for ESP payload Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have some questions on the creation and the size of IV for ESP payload. RFC 2407 defines the following IPSEC ESP Transform Identifiters: Transform ID Value ------------ ----- RESERVED 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 ESP_RC4 10 ESP_NULL 11 It also indicates the following for the transform ids: o For ESP_DES_IV64 (1) and ESP_DES_IV32 (9), the transform type specifie the DES-CBC transform defined RFC-1827 and RFC-1829. o For ESP_DES (2), all implementation within the IPSEC DOI MUST support the suite defined as [DES] transofrm (RFC2405). o For ESP_3DES (3), all implementation within the IPSEC DOI MUST support the suite defined as [ESPCBC] transofrm (RFC2451). By looking at the 3 RFCs mentioned above for information on IV, RFC1829 says that "A common acceptable technique is simply a counter, beginning with a randomly chosen value", while RFC2405 and RFC2451 indicate that "Common practice is to use random data for the first IV and the last 8 octets of encrypted data from an encryption process as the IV for the next encryption proces". At the mean time, appendix B of RFC2409(The Internet Key Exchange) states the following: In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1. Q1) Should we create the first IV using a random number or using the algorithm defined in appendix B of RFC2409? If we follow RFC2409, do we store IV (last phase 1 CBC output block) as part of the SA fields? Q2) RFC2406 (IP ESP) indicates that the IV size of 32 and 64 bits are required to be supported. It also states that "When the size is 32-bits, a 64-bit IV is formed from the 32-bit value followed by (concatenated with) the bit-wise complement of the 32-bit value". Since the IV is always going to be 64-bit, why do we have to support size 32 and 64? If we use the method defined in appendix B of RFC2409, we're always going to get a 64-bit block, how do we support size 32 anyway? What determines if we need to do size 32 or 64 IV for encryption (eg. user provisiong, default, ...)? Q3) What's the difference between transform ID 1/9 (ESP_DES_IV64/ESP_DES_IV32) and ID 2 (ESP_DES)? If the SA is negotiated to support ID 2, it still needs to have an IV64/IV32 for CBC operation later, is it not right? Regards, Li Zhou. From owner-ipsec@lists.tislabs.com Mon May 10 09:19:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03090; Mon, 10 May 1999 09:19:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21669 Mon, 10 May 1999 10:04:17 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <3.0.3.32.19990507214032.00b7a320@mail> References: <3.0.3.32.19990506221537.00bbb100@mail> <372F195F.A04EAB64@redcreek.com> Date: Mon, 10 May 1999 10:02:48 -0400 To: Alex Alten From: Stephen Kent Subject: Re: INITIAL-CONTACT issues Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, I should add then when I was contacted by our own IT security folks about this, we were abloe to arrive at a mutually acceptable approach to firewall port management issues for AH, ESP, and UDP for IKE. So, I think it is largely a matter of education. steve From owner-ipsec@lists.tislabs.com Mon May 10 09:25:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03161; Mon, 10 May 1999 09:25:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21678 Mon, 10 May 1999 10:04:53 -0400 (EDT) From: "Luis A. Sanchez" Message-Id: <199905101413.KAA05696@nutmeg.bbn.com> Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) In-Reply-To: <373440DB.8A4ECF76@ix.netcom.com> from "Scott G. Kelly" at "May 8, 99 06:49:15 am" To: sgkelly@ix.netcom.com (Scott G. Kelly) Date: Mon, 10 May 1999 10:13:04 -0400 (EDT) Cc: Alten@home.com, kent@bbn.com, ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Again, we have the 3 situations I described in an earlier email, and I > think the only problematic situation is when an end-user behind a > firewall wants to establish (or permit) a secured session *through* the > firewall. Some administrators simply refuse, saying "I can't see what's > in the encrypted traffic, and that's unacceptable". I see no solution in > this case, since they do not trust their internal systems/users. Tough > situation. > Scott, there are solutions, although not yet _completely_ implemented, to the problem of security gateways tunneling encrypted traffic to an end user. For example, assume that a security gateway obtain securely the policy and SPI corresponding to the tunnel traffic. Given this information, the security gateway can "dynamically" add a new SPD entry indicating that traffic from src XX to dst YY with prot 50 and SPI: ZZZZ is allowed. Now, proper inbound processing will be possible since these fields (src, dst, prot, and SPI) are in the clear and the SPI->policy relationship existed in the SPD of the security gateway apriori. A piece of this solution was presented by Charlie Lynn on behalf of Kai Martius during the IPsec Policy BOF in MN. Perhaps we didn't have enough coffee or the meeting was plain old boring (or both;-). Luis From owner-ipsec@lists.tislabs.com Mon May 10 09:25:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03171; Mon, 10 May 1999 09:25:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21716 Mon, 10 May 1999 10:12:18 -0400 (EDT) Date: Mon, 10 May 1999 10:20:03 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: ipsec through firewalls (was re:INITIAL-CONTACT issues) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 10 May 1999, Waters, Stephen wrote: > I know it is a leap of faith, but folk will just have to get used to > trusting their IPSEC security gateways. If you can get that far, then you > don't need a Firewall for the IPSEC tunnel traffic, so you don't have to > poke holes. Alas, it is not that easy. If the IPSEC is being done by a well-run security gateway, which is itself careful about what gets sent (i.e., it is itself functioning as a firewall), that may be okay. But that won't always be the case... and as a result, there are two problems: 1. You may want to know whether the IPSEC is being done right. Careful efforts to keep your networking secure aren't going to do very much good if some twit is sending company-confidential traffic encrypted with Microsoft's 40-bit DES. 2. You may want to know what's flowing through those tunnels. Firewall operators nowadays are often almost as worried about what's inside the firewall as about what's outside. (The problem is not the users, but the people who wrote the users' software.) A place that has serious concerns about either of these issues is just going to have to mandate use of IPSEC proxies on the firewalls: you don't get to make an encrypted end-to-end tunnel through the firewall, you make a tunnel to the firewall and it makes one the rest of the way. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Mon May 10 10:14:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03548; Mon, 10 May 1999 10:14:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21946 Mon, 10 May 1999 11:03:45 -0400 (EDT) Date: Mon, 10 May 1999 11:11:26 -0400 (EDT) Message-Id: <199905101511.LAA09497@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Henry Spencer CC: IP Security List In-reply-to: Henry Spencer's message of Mon, 10 May 1999 10:20:03 -0400 (EDT), Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I will observe that for many companies, the group that wishes to run the firewalls is typically anally challenged, and typically the rest of the organization typically doesn't care about security except to resent the group that runs the firewall. In that situation, it may very well make sense for the firewall and the ipsec gateway to be (logically, if not physically) the same service, and run by the firewall group. Obviously, each company's politics and technical issues will be different, but my guess would be that for many such companies, the requirement to poke holes in the firewall may not be an issue since the folks running the firewall will be the one installing the IPSEC gateway ---- possibly by replacing their firewall with one of those products which integrate the firewall and ipsec gatewaying functionality into a single box. - Ted From owner-ipsec@lists.tislabs.com Mon May 10 11:08:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04080; Mon, 10 May 1999 11:08:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22287 Mon, 10 May 1999 11:58:01 -0400 (EDT) Message-ID: <37370486.B6CA632E@redcreek.com> Date: Mon, 10 May 1999 09:08:38 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Waters, Stephen" CC: ipsec@lists.tislabs.com Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) References: <29752A74B6C5D211A4920090273CA3DC385A12@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Waters, Stephen" wrote: > > TCP Q: > > There do seem to be some cracks showing in IKE connection phase (we have > been using a lot of IKE duct-tape lately). I guess it would not take us too > long to get IKE running over TCP instead - it may be worth a try, and we may > even offer the option for like-to-like running, if it makes life easier. > I agree that there are connection-related problems with ISAKMP/IKE as currently implemented. Perhaps a better line of questioning is this: why was transport independence a design goal for ISAKMP to begin with, and is it still a design goal? When you answer these questions, you ascertain whether it is appropriate to discuss whether or not to rely upon TCP for connection-related reliability. Scott From owner-ipsec@lists.tislabs.com Mon May 10 11:11:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04114; Mon, 10 May 1999 11:11:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22343 Mon, 10 May 1999 12:04:08 -0400 (EDT) Message-ID: <373705F0.30E3CA4F@redcreek.com> Date: Mon, 10 May 1999 09:14:40 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Luis A. Sanchez" CC: "Scott G. Kelly" , Alten@home.com, kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) References: <199905101413.KAA05696@nutmeg.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Luis, "Luis A. Sanchez" wrote: > > Scott, > > there are solutions, although not yet _completely_ > implemented, to the problem of security gateways tunneling encrypted > traffic to an end user. For example, assume that a security gateway > obtain securely the policy and SPI corresponding to the tunnel > traffic. Given this information, the security gateway can > "dynamically" add a new SPD entry indicating that traffic from src XX > to dst YY with prot 50 and SPI: ZZZZ is allowed. Now, proper inbound > processing will be possible since these fields (src, dst, prot, and > SPI) are in the clear and the SPI->policy relationship existed in the > SPD of the security gateway apriori. A piece of this solution was > presented by Charlie Lynn on behalf of Kai Martius during the IPsec > Policy BOF in MN. Perhaps we didn't have enough coffee or the meeting > was plain old boring (or both;-). I caught Charlie's presentation, and I agree that this should go a long way toward resolving the problem when the administrator simply wants to have a mechanism for "safely" passing the traffic through. I was referring, though, to another situation, that being the one in which the administrator wants to know what's *inside* the encrypted payload, and therefore will not permit such traffic to traverse the firewall. Scott From owner-ipsec@lists.tislabs.com Mon May 10 11:37:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04377; Mon, 10 May 1999 11:37:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22534 Mon, 10 May 1999 12:27:24 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: "Theodore Y. Ts'o" Cc: Henry Spencer , IP Security List Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 May 1999 12:35:44 -0400 From: "Steven M. Bellovin" Message-Id: <19990510163549.5078C41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A VPN connection is, fundamentally, a (virtual) wire. Where you terminate that wire, relative to your firewall, depends on the characteristics of the other end. Is it fully trusted? Is it secure from other intrusions, including those coming in from the Internet if the ipsec setup doesn't fully block them? In such cases, you terminate it inside the firewall. If it's someone you don't want to let all the way in, you terminate it outside (for some value of "outside") the firewall, or you integrate your ipsec endpoint with a firewall that can make access decisions based on certificate name rather than IP address. But the real question that has to be answered first is how much you trust the remote endpoint. From owner-ipsec@lists.tislabs.com Mon May 10 23:17:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA06582; Mon, 10 May 1999 23:17:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24602 Tue, 11 May 1999 00:17:48 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <373440DB.8A4ECF76@ix.netcom.com> References: <3.0.3.32.19990506221537.00bbb100@mail> <372F195F.A04EAB64@redcreek.com> <3.0.3.32.19990507214032.00b7a320@mail> Date: Mon, 10 May 1999 17:08:44 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: ipsec through firewalls (was re:INITIAL-CONTACT issues) Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, As you observed, there are several issues here. IKE through a firewall is an issue because use of UDP, vs. TCP, deprives the firewall admin of the easy means of determining whether the initiator of the session is inside or outside of the firewall. Of course, with a simple application proxy, they can figure this out anyway, but with just packet filtering, and in the absence of the necessary proxy, ... With regard to AH and ESP, the concerns are analogous (wrt to initiators vs. responders), plus there is the problem of not knowing which ports on the internal machines are being accessed. The new work on policy with IPsec, which may have a WG soon, can address these problems, to first order. The work of some of the folks here at BBN provides a way for a security admin to interact with a policy module on an end system behind a firewall, to approve/reject proposed SAs, and thus gives a basis for managing IKE exchanges. With direct knowledge of the specific parameters for each SA being negotiated for a client, a sys security admin may then be comfortable with allowing IPsec traffic through a firewall. Steve From owner-ipsec@lists.tislabs.com Tue May 11 18:19:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA24753; Tue, 11 May 1999 18:19:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27477 Tue, 11 May 1999 19:13:49 -0400 (EDT) Message-ID: <3738BC37.7A16EB68@seas.gwu.edu> Date: Tue, 11 May 1999 19:24:40 -0400 From: Cyberspace Policy Institute X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: URGENT: Need crypto product info! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please forward this message to others who are interested on the topic. A WWW-version of this message can be found at http://www.seas.gwu.edu/seas/institutes/cpi/cryptosurvey/call4info.html Please excuse us for the cross-postings. -- Anya @ CPI ************************************************************** NON-U.S. CRYPTOGRAPHIC PRODUCT SURVEY CALL FOR INFORMATION ************************************************************** The George Washington University and NAI Labs, The Security Research Division of Network Associates (formerly the research division of Trusted Information Systems) are conducting a survey to identify cryptographic products manufactured outside the United States and are examining product specifications to assess their functionality and security. We are soliciting input from those with knowledge of cryptographic products through the use of this survey form. If you know of cryptographic products that are manufactured in countries other than the United States, please complete this form and submit it to the Cyberspace Policy Institute (CPI) NO LATER THAN TUESDAY MAY 18, 1999. You may submit this form via email to cpi@seas.gwu.edu or fax at (202) 994-5505 in Washington D.C. In addition, we ask you to send or post this survey to anyone or place that would have knowledge of cryptographic products. Inquiries about this survey may be made to the Cyberspace Policy Institute at cpi@seas.gwu.edu or (202) 994-5512. This survey may also be found on the CPI Web site at http://www.seas.gwu.edu/seas/institutes/cpi. Your cooperation is greatly appreciated. Professor Lance J. Hoffman, The George Washington University David Balenson, NAI Labs, The Security Research Division of Network Associates ***************************************************************** NON-U.S. CRYPTOGRAPHIC PRODUCT SURVEY DATE: COMPLETED BY: Your Name: Phone: E-mail: NAME AND ADDRESS OF MANUFACTURER Name: Address: City: State: Zip Code: Country: URL: MANUFACTURER CONTACT INFORMATION Name: Title: Phone: FAX: E-mail: 800#: PRODUCT DESCRIPTION Name (including model and version information): Product-specific URL: Is it software-only, hardware-only, or a software/hardware combination? What does it encrypt (e.g., disk, file, communications, FAX, voice, magnetic tape, electronic mail)? If embedded software or hardware, what platforms does it support (e.g., PC, Mac, UNIX workstation, IBM mainframe), else if standalone hardware, what interfaces does it support (RS-232, telephone, V.24, V.35)? If software, is it in the form of a kit or as an end-user program, else if hardware, what is the embodiment (e.g., chip, board, PCMCIA card, smart card, box, phone)? What algorithms does it employ for data encryption (including proprietary algorithms and key length)? If applicable, what algorithms does it employ for key management (including proprietary algorithms and key length)? If applicable, what algorithms does it employ for data authentication (including proprietary algorithms)? How is the product sold or distributed (e.g., store front, mail order, telephone order, World Wide Web, anonymous ftp over the Internet)? If applicable, what is the quantity one purchase price? (Optional) Approximate number of units sold or distributed? (Optional) Approximate date product was first available? Please provide a list of the names and relationships of any associated companies (e.g., parent company, sister company, distributors). Include full address and contact name, title, phone, FAX, and e-mail address. Other information: PLEASE PROVIDE A COPY OF ANY RELEVANT PRODUCT LITERATURE. Send completed forms and product literature via e-mail to cpi@seas.gwu.edu or via fax to the Cyberspace Policy Institute at 202-994-5505 in Washington D.C. THANK YOU! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This survey is part of an ongoing worldwide study of cryptographic products started in April 1994 by Trusted Information Systems and Dr. Lance J. Hoffman of the George Washington University. The December 1997 summary results of the survey are available on the World Wide Web at http://www.nai.com/products/security/tis_research/crypto/crypt_surv.asp. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ipsec@lists.tislabs.com Wed May 12 05:37:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12807; Wed, 12 May 1999 05:37:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA28869 Wed, 12 May 1999 06:14:59 -0400 (EDT) Message-ID: <59726335C162D111B2CF00805FA7205D02FE9B31@csifiapp621.wepex.net> From: "Burden, James" To: "'Scott G. Kelly'" Cc: "'Stephen Kent'" , Alex Alten , ipsec@lists.tislabs.com Subject: RE: IKE transport (was INITIAL-CONTACT issues) Date: Wed, 12 May 1999 03:23:14 -0700 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 My apologies for the late reply. First I would like to bring up that firewalls are placed in more places in a network topology than just protecting oneself from the Internet. Finance, Engineering, System Admin, and different classes of users all require different security policies and therefore different security devices to protect them. I personally do not believe that IPSEC is the silver bullet to security. Firewalls, IDS, network management, dutiful reading of logs (apps, servers, firewalls, etc), etc. are still required. In addition, the network infrastructure needs to strictly enforce security policies regarding directions data may to and from. > "Burden, James" wrote: > > Personally, I am wary of allowing any UDP through a firewall. > > Question: why would you be less wary of allowing tcp through? > Generally, logging of TCP connections, and tracing connections to the originator are both easier with TCP than UDP. The firewall is my first line of defense. I have to allow bad UDP packets forever through the firewall, and let the application take care of itself. > > > In addition, UDP requires some mechanism to prevent IP > spoofing. This is > > all done at layer 7. The application (and the > implementation) must be > > trusted, and you could potentially lose your defense in > depth with the > > firewall. > > Again, why would tcp be different? In a private network where you can control the routing tables (using static or floating static routes, or the use of a routing protocol that takes advantage of summarizing subnets)and prevent IP spoofing from subnet to subnet. The 3-way handshake becomes a great friend. > > > I would agree that a DoS attack is easily mounted against > TCP, but it would > > be easier to defend than UDP. > > How so? Yes, you can do a SYN attack against TCP, but you can limit the timers (after taking the necessary metrics), limit the number of sessions, and with UNIX you can use tcp_wrappers as an additional layer of defense. Someone spoofing the SYN packets will be soon dropped, and the real client will be able to establish a connection as he will have a valid return route for the 3-way handshake. I do see your point in that the initial TCP packet, and all the UDP packets are roughly equivalent. The major difference is that the network devices can protect the TCP connections, where the app stands alone. Even the operating system can do little to help. UDP is susceptible to buffer over flows, where I do not think that TCP would be until after the session was set up (I could be wrong). Which is more reliable, the network/security devices or the applications? This would probably be more of a religious war. My feelings are probably evident, as security devices are normally not used until they have been both proven and have withstood peer review. Applications on the other hand are first to market, and where other things such as cost and time are given higher priorities than security, to include security software. If I could equate this to chess, then the application would be like the king. What good are the other pieces? Even though Steinitz said the king could take care of himself, he still used the other pieces to their utmost potential. Someone in another email said that we should start trusting somebody sometime, and that the Security Gateway could replace the firewall/or run in parallel. +-----+ Internet +----+ ipsec tunnel +-----+ | E1 |===========| FW |===============| E2 | +-----+ +----+ +-----+ E1 and E2 are now of the same security policy (the weakest). In addition, each has to fully trust each other. In most physically secure environments you give a visitor a badge, and escort them. Would you do less with a visitor on your network? Jim From owner-ipsec@lists.tislabs.com Wed May 12 07:46:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13769; Wed, 12 May 1999 07:46:16 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29184 Wed, 12 May 1999 08:25:45 -0400 (EDT) Date: Wed, 12 May 1999 08:25:45 -0400 (EDT) Message-Id: <199905121225.IAA29184@lists.tislabs.com> (8.8.8/8.7.3) with ESMTP id AAA26476 for ; Wed, 12 May 1999 00:10:48 -0400 (EDT) Message-ID: <3739296B.EB051DA8@netrover.com> Date: Wed, 12 May 1999 00:10:35 -0700 From: Loretta Zhou X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Questions on IV for ESP payload Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have some questions on the creation and the size of IV for ESP payload. RFC 2407 defines the following IPSEC ESP Transform Identifiters: Transform ID Value ------------ ----- RESERVED 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 ESP_RC4 10 ESP_NULL 11 It also indicates the following for the transform ids: o For ESP_DES_IV64 (1) and ESP_DES_IV32 (9), the transform type specifie the DES-CBC transform defined RFC-1827 and RFC-1829. o For ESP_DES (2), all implementation within the IPSEC DOI MUST support the suite defined as [DES] transofrm (RFC2405). o For ESP_3DES (3), all implementation within the IPSEC DOI MUST support the suite defined as [ESPCBC] transofrm (RFC2451). By looking at the 3 RFCs mentioned above for information on IV, RFC1829 says that "A common acceptable technique is simply a counter, beginning with a randomly chosen value", while RFC2405 and RFC2451 indicate that "Common practice is to use random data for the first IV and the last 8 octets of encrypted data from an encryption process as the IV for the next encryption proces". At the mean time, appendix B of RFC2409(The Internet Key Exchange) states the following: In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1. Q1) Should we create the first IV using a random number or using the algorithm defined in appendix B of RFC2409? If we follow RFC2409, do we store IV (last phase 1 CBC output block) as part of the SA fields? Q2) RFC2406 (IP ESP) indicates that the IV size of 32 and 64 bits are required to be supported. It also states that "When the size is 32-bits, a 64-bit IV is formed from the 32-bit value followed by (concatenated with) the bit-wise complement of the 32-bit value". Since the IV is always going to be 64-bit, why do we have to support size 32 and 64? If we use the method defined in appendix B of RFC2409, we're always going to get a 64-bit block, how do we support size 32 anyway? What determines if we need to do size 32 or 64 IV for encryption (eg. user provisiong, default, ...)? Q3) What's the difference between transform ID 1/9 (ESP_DES_IV64/ESP_DES_IV32) and ID 2 (ESP_DES)? If the SA is negotiated to support ID 2, it still needs to have an IV64/IV32 for CBC operation later, is it not right? Regards, L Zhou. From owner-ipsec@lists.tislabs.com Wed May 12 08:49:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14327; Wed, 12 May 1999 08:49:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29455 Wed, 12 May 1999 09:35:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <373184C4.5BD06264@indusriver.com> Date: Tue, 11 May 1999 14:23:51 -0400 To: Ben McCann From: Stephen Kent Subject: Re: Automatic SPD Entry Creation for Remote Access IPSEC Clients Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ben, >For example, please assume my inbound SPD states all UDP port 1701 >(L2TP) traffic from _ANY_ address must be encrypted using Transport >mode ESP(3DES-SHA). Also assume that SPD entry requires SAD element >derivation (creation) using the addresses, ports, etc from the packet. >(This derivation mechanism is discussed on pages 14-15 of RFC 2401). > >As multiple remote peers establish SA's, each of their SAD entries >is created using their source IP address as defined by the IKE >phase 2 identity. (I'm getting fuzzy here so please correct me if >I'm wrong on this). All of those SAD entries are bound to the >single SPD which contained the _ANY_ source address wildcard value. > >Is this an acceptable alternative to dynamically creating SPD >entries? > > >Perhaps I can answer my own question. The specific packet that triggered >the SA creation is not known in the _responding_ system therefore >there is insufficient information to create the SAD element. That is >why you recommended waiting until the first IPSEC packet arrives and then >creating the SPD entry from that. > >Could you create the SAD entry and bind it to the wildcard source >address SPD entry instead? My example for the need for dynamic SPD entry creation is actually quite different, though I don't disagree with the other answer you received. Note that an SPD entry may contain an identifier of the form of a name, e.g., a DNS name, DN, etc., rather than an address. Thus, for example, one might have SPD entries for road warriors based on user names, e.g., RFC 822 names or DNs, (since the user might employ different laptops or because the laptopn might have a dynamically assigned address, etc.) But, packets don't contain names, and an SG will see the user name only when the SA is negotiated; on a steady state basis, the SG will see only the addresses of the source and destination. So, when an SA is negotiated with a user of this sort, one needs to create temporary inbound and outbound SPD entries that instantiate the address for the laptop for the duration of of this SA, to represent the user's authorization for this SA. Steve From owner-ipsec@lists.tislabs.com Wed May 12 14:42:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17162; Wed, 12 May 1999 14:42:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00696 Wed, 12 May 1999 15:25:45 -0400 (EDT) Message-ID: <3739CFE4.45D60534@americasm01.nt.com> Date: Wed, 12 May 1999 15:00:52 -0400 From: "Loretta Zhou" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Questions on IV for ESP payload Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have some questions on the creation and the size of IV for ESP payload. RFC 2407 defines the following IPSEC ESP Transform Identifiters: Transform ID Value ------------ ----- RESERVED 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 ESP_RC4 10 ESP_NULL 11 It also indicates the following for the transform ids: o For ESP_DES_IV64 (1) and ESP_DES_IV32 (9), the transform type specifie the DES-CBC transform defined RFC-1827 and RFC-1829. o For ESP_DES (2), all implementation within the IPSEC DOI MUST support the suite defined as [DES] transofrm (RFC2405). o For ESP_3DES (3), all implementation within the IPSEC DOI MUST support the suite defined as [ESPCBC] transofrm (RFC2451). By looking at the 3 RFCs mentioned above for information on IV, RFC1829 says that "A common acceptable technique is simply a counter, beginning with a randomly chosen value", while RFC2405 and RFC2451 indicate that "Common practice is to use random data for the first IV and the last 8 octets of encrypted data from an encryption process as the IV for the next encryption proces". At the mean time, appendix B of RFC2409(The Internet Key Exchange) states the following: In phase 2, material for the initialization vector for CBC mode encryption of the first message of a Quick Mode exchange is derived from a hash of a concatenation of the last phase 1 CBC output block and the phase 2 message id using the negotiated hash algorithm. The IV for subsequent messages within a Quick Mode exchange is the CBC output block from the previous message. Padding and IVs for subsequent messages are done as in phase 1. Q1) Should we create the first IV using a random number or using the algorithm defined in appendix B of RFC2409? If we follow RFC2409, do we store IV (last phase 1 CBC output block) as part of the SA fields? Q2) RFC2406 (IP ESP) indicates that the IV size of 32 and 64 bits are required to be supported. It also states that "When the size is 32-bits, a 64-bit IV is formed from the 32-bit value followed by (concatenated with) the bit-wise complement of the 32-bit value". Since the IV is always going to be 64-bit, why do we have to support size 32 and 64? If we use the method defined in appendix B of RFC2409, we're always going to get a 64-bit block, how do we support size 32 anyway? What determines if we need to do size 32 or 64 IV for encryption (eg. user provisiong, default, ...)? Q3) What's the difference between transform ID 1/9(ESP_DES_IV6/ESP_DES_IV32) and ID 2 (ESP_DES)? If the SA is negotiated to support ID 2, it still needs to have an IV64/IV32 for CBC operation later, is it not right? Regards, L Zhou. From owner-ipsec@lists.tislabs.com Thu May 13 02:09:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18865; Thu, 13 May 1999 02:09:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01980 Thu, 13 May 1999 03:02:59 -0400 (EDT) From: maria@wipinfo.soft.net Message-Id: <199905130711.MAA15601@garuda.wipro.tcpn.com> Subject: Implementing a VPN with IPsec To: ipsec@lists.tislabs.com Date: Thu, 13 May 1999 12:41:18 +0530 (GMT+0530) Reply-To: maria@wipinfo.soft.net Name: Maria Theresita Fernando X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm new to the mailing list and I've read a few drafts on IPsec . We are planning to implement a VPN with IPSec. Will an implementaion of IPSec constitute a VPN or is there something more to it? Any information or pointers in this regard will be greatly appreciated. --Thanks Maria From owner-ipsec@lists.tislabs.com Thu May 13 02:35:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19020; Thu, 13 May 1999 02:35:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA02057 Thu, 13 May 1999 03:52:58 -0400 (EDT) Message-Id: <3.0.6.32.19990513132605.0126ea20@hydmail> X-Sender: rohit@hydmail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 13 May 1999 13:26:05 To: maria@wipinfo.soft.net, ipsec@lists.tislabs.com From: Rohit Subject: Re: Implementing a VPN with IPsec In-Reply-To: <199905130711.MAA15601@garuda.wipro.tcpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPSec will form one part of total VPN implementation, VPN implementation also includes implementations of Key Management mechanisms like IKE(Internet Key exchange protocol),Manual key management, Enryption and authentication mechanisms like ESP and AH etc. -Rohit 12:41 PM 5/13/99 +0530, maria@wipinfo.soft.net wrote: >Hi, > > I'm new to the mailing list and I've read a few drafts on IPsec . We are > planning to implement a VPN with IPSec. Will an implementaion of IPSec > constitute a VPN or is there something more to it? Any information or > pointers in this regard will be greatly appreciated. > >--Thanks >Maria > ################################################################## Rohit Aradhya Software Engineer Motorola (I) Electronics Ltd TSR Towers, Rajbhavan Road Somajiguda, HYDERABAD INDIA Ph # (040)3308095/96/97 Ext 3060 ################################################################## From owner-ipsec@lists.tislabs.com Thu May 13 10:18:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24882; Thu, 13 May 1999 10:18:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02906 Thu, 13 May 1999 10:47:47 -0400 (EDT) Message-ID: <373AE7E4.327A3840@mitel.com> Date: Thu, 13 May 1999 10:55:32 -0400 From: Dave Perks Organization: Mitel Corporation X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IP Security List Subject: Re: Questions on IV for ESP payload References: <3739CFE4.45D60534@americasm01.nt.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Loretta Zhou wrote: > > Hi, > > I have some questions on the creation and the size of IV > for ESP payload. > > RFC 2407 defines the following IPSEC ESP Transform Identifiters: > > Transform ID Value > ------------ ----- > RESERVED 0 > ESP_DES_IV64 1 > ESP_DES 2 > ESP_3DES 3 > ESP_RC5 4 > ESP_IDEA 5 > ESP_CAST 6 > ESP_BLOWFISH 7 > ESP_3IDEA 8 > ESP_DES_IV32 9 > ESP_RC4 10 > ESP_NULL 11 > > It also indicates the following for the transform ids: > > o For ESP_DES_IV64 (1) and ESP_DES_IV32 (9), the transform type > specifie the DES-CBC transform defined RFC-1827 and RFC-1829. > > o For ESP_DES (2), all implementation within the IPSEC DOI MUST > support the suite defined as [DES] transofrm (RFC2405). > > o For ESP_3DES (3), all implementation within the IPSEC DOI MUST > support the suite defined as [ESPCBC] transofrm (RFC2451). > > By looking at the 3 RFCs mentioned above for information on IV, > RFC1829 says that "A common acceptable technique is simply a counter, > beginning with a randomly chosen value", while RFC2405 and RFC2451 > indicate that "Common practice is to use random data for the first IV > and the last 8 octets of encrypted data from an encryption process as > the IV for the next encryption proces". In section 6 "Security Considerations" of RFC 2405 Steve Bellovin is quoted: "The problem arises if you use a counter as an IV, or some other source with a low Hamming distance between successive IVs, for encryption in CBC mode. In CBC mode, the "effective plaintext" for an encryption is the XOR of the actual plaintext and the ciphertext of the preceeding block. Normally, that's a random value, which means that the effective plaintext is quite random. That's good, because many blocks of actual plaintext don't change very much from packet to packet, either. For the first block of plaintext, though, the IV takes the place of the previous block of ciphertext. If the IV doesn't differ much from the previous IV, and the actual plaintext block doesn't differ much from the previous packet's, then the effective plaintext won't differ much, either. This means that you have pairs of ciphertext blocks combined with plaintext blocks that differ in just a few bit positions. This can be a wedge for assorted cryptanalytic attacks." It then goes on to note The discussion on IVs has been updated to require that an implementation not use a low-Hamming distance source for IVs. which I take to mean no counters. > At the mean time, appendix B of RFC2409(The Internet Key Exchange) > states the following: > > In phase 2, material for the initialization vector for CBC mode > encryption of the first message of a Quick Mode exchange is derived > from a hash of a concatenation of the last phase 1 CBC output block > and the phase 2 message id using the negotiated hash algorithm. The > IV for subsequent messages within a Quick Mode exchange is the CBC > output block from the previous message. Padding and IVs for > subsequent messages are done as in phase 1. > > Q1) Should we create the first IV using a random number or using > the algorithm defined in appendix B of RFC2409? If we follow > RFC2409, do we store IV (last phase 1 CBC output block) as part > of the SA fields? My understanding is that the algorithms of RFC 2409 apply only to the contents of the messages exchanged over the ISAKMP SA. In this case the IVs are not included in the packets and so cannot be random. I can't answer any more of your questions since I don't know the answers :-( -- The opinions expressed in this message are my personal opinion and in no way reflect the views of my employer. S�ren Kierkegaard says "Life can only be understood backwards; but it must be lived forwards." From owner-ipsec@lists.tislabs.com Thu May 13 11:19:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25286; Thu, 13 May 1999 11:19:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03079 Thu, 13 May 1999 12:05:48 -0400 (EDT) Message-ID: <373AFA9E.23F04A75@redcreek.com> Date: Thu, 13 May 1999 09:15:26 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Burden, James" CC: "'Scott G. Kelly'" , "'Stephen Kent'" , Alex Alten , ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) References: <59726335C162D111B2CF00805FA7205D02FE9B31@csifiapp621.wepex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jim, Thanks for your detailed reply, and sorry I did not get back to you sooner. After reading and re-reading your reply, it seems to me that there were implicit assumptions behind my questions which should perhaps be made explicit to clear this up. This discussion began with a suggestion that ISAKMP/IKE should be run over tcp instead of udp, and that this requirement be listed as "SHOULD" in the RFC. I followed up that post with some speculation as to why UDP might have been chosen instead of TCP to begin with, and cited additional overhead as one possible concern. I guess I don't really need to go back through the thread in its entirety here, but I also suggested that one of the original design requirements was transport independence, and also that a DoS attack might be easier to mount if the transport was TCP, meaning that there would be more (useless) work per packet for TCP. I have the feeling from your reply that you are discussing the more general case of allowing TCP vs UDP through a firewall for any application. I view ISAKMP/IKE as a different and special case, since ISAKMP/IKE provides for endpoint authentication as part of the protocol. In my view, the issue prompting this discussion is that the current ISAKMP/IKE specification seems to not provide enough in the way of connection-oriented service, and the question we have to answer is this: should we chuck the transport independence requirement and consider TCP, or should we instead add necessary and sufficient functionality to IKE? Scott From owner-ipsec@lists.tislabs.com Thu May 13 14:03:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26603; Thu, 13 May 1999 14:03:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03728 Thu, 13 May 1999 14:49:17 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Scott G. Kelly'" , "Burden, James" Cc: "'Scott G. Kelly'" , "'Stephen Kent'" , Alex Alten , ipsec@lists.tislabs.com Subject: RE: IKE transport (was INITIAL-CONTACT issues) Date: Thu, 13 May 1999 11:57:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Scott G. Kelly [skelly@redcreek.com] >Sent: Thursday, May 13, 1999 9:15 AM >To: Burden, James >Cc: 'Scott G. Kelly'; 'Stephen Kent'; Alex Alten; >ipsec@lists.tislabs.com >Subject: Re: IKE transport (was INITIAL-CONTACT issues) > >Hi Jim, > >Thanks for your detailed reply, and sorry I did not get back to you >sooner. After reading and re-reading your reply, it seems to me that >there were implicit assumptions behind my questions which should perhaps >be made explicit to clear this up. > >This discussion began with a suggestion that ISAKMP/IKE should be run >over tcp instead of udp, and that this requirement be listed as "SHOULD" >in the RFC. minor correction - My request was that ISAKMP/IKE SHOULD be supported on tcp transport in addition to udp transport. >I followed up that post with some speculation as to why UDP >might have been chosen instead of TCP to begin with, and cited >additional overhead as one possible concern. I guess I don't really need >to go back through the thread in its entirety here, but I also suggested >that one of the original design requirements was transport independence, >and also that a DoS attack might be easier to mount if the transport was >TCP, meaning that there would be more (useless) work per packet for TCP. I am not very clear on the DoS attack issues. It is my understanding many web servers run into this problem and have addressed the DoS attack problem for TCP at a system level. > >I have the feeling from your reply that you are discussing the more >general case of allowing TCP vs UDP through a firewall for any >application. I view ISAKMP/IKE as a different and special case, since >ISAKMP/IKE provides for endpoint authentication as part of the protocol. >In my view, the issue prompting this discussion is that the current >ISAKMP/IKE specification seems to not provide enough in the way of >connection-oriented service, and the question we have to answer is this: >should we chuck the transport independence requirement and consider TCP, >or should we instead add necessary and sufficient functionality to IKE? Agree about the question to be answered. I would like to know more about the rationale for the transport independence requirement. If the two parties communicating have a common reliable transport(tcp) installed then why not use that for IKE traffic? If one of them does not have the common reliable transport installed, then the parties can always fall back to udp. Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Thu May 13 14:53:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26998; Thu, 13 May 1999 14:53:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03911 Thu, 13 May 1999 16:00:38 -0400 (EDT) From: Dan McDonald Message-Id: <199905132006.NAA22876@kebe.Eng.Sun.COM> Subject: Re: IKE transport (was INITIAL-CONTACT issues) To: Sankar@vpnet.com (Sankar Ramamoorthi) Date: Thu, 13 May 1999 13:06:15 -0700 (PDT) Cc: skelly@redcreek.com, JBurden@caiso.com, sgkelly@ix.netcom.com, kent@bbn.com, Alten@home.com, ipsec@lists.tislabs.com In-Reply-To: from "Sankar Ramamoorthi" at May 13, 99 11:57:09 am X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >that one of the original design requirements was transport independence, > >and also that a DoS attack might be easier to mount if the transport was > >TCP, meaning that there would be more (useless) work per packet for TCP. > > I am not very clear on the DoS attack issues. It is my understanding > many web servers run into this problem and have addressed the DoS > attack problem for TCP at a system level. The web servers have fixed the SYN-flooding attack. There is nothing to stop malicious injections of RST packets into a TCP stream. This is the biggest reason to not use TCP for IKE. You'll never get past the 3-way handshake if you have a malicious eavesdropper. Dan From owner-ipsec@lists.tislabs.com Fri May 14 02:52:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA00527; Fri, 14 May 1999 02:52:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05349 Fri, 14 May 1999 03:42:33 -0400 (EDT) Message-ID: <373be40f.uincaa@incaa.nl> From: RL@incaa.nl (Robert Luursema) Organization: INCAA Datacom b.v. To: ipsec@lists.tislabs.com Date: Fri, 14 May 1999 09:33:23 +0200 Subject: (Fwd) Re: Question on IV for ESP payload Reply-to: RL@incaa.nl X-mailer: Pegasus Mail for Windows (v2.42a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Forwarded message: From: Self To: owner-ipsec@lists.tislabs.com Subject: Re: Question on IV for ESP payload Reply-to: RL@incaa.nl Date: Tue, 11 May 1999 20:30:21 +0200 On 10 May 99 at 8:50, Loretta Zhou wrote: > Q1) Should we create the first IV using a random number or using > the algorithm defined in appendix B of RFC2409? If we follow > RFC2409, do we store IV (last phase 1 CBC output block) as part > of the SA fields? If you are implementing IKE, you should do it according the IKE spec RFC2409. Appendix B tells how to generate initial IV for phase 1 and 2, and how to extend the IV to the blocksize. If you are implementing IPsec IP ESP, see the ESP spec RFC2406. The IV is random and carried in the payload data. > Q2) RFC2406 (IP ESP) indicates that the IV size of 32 and 64 bits are > required to be supported. It also states that "When the size is > 32-bits, a 64-bit IV is formed from the 32-bit value followed by > (concatenated with) the bit-wise complement of the 32-bit value". > > Since the IV is always going to be 64-bit, why do we have to support > size 32 and 64? If we use the method defined in appendix B of > RFC2409, we're always going to get a 64-bit block, how do we support > size 32 anyway? What determines if we need to do size 32 or 64 IV > for encryption (eg. user provisiong, default, ...)? The blocksize of the cipher. > Q3) What's the difference between transform ID 1/9 (ESP_DES_IV64/ESP_DES_IV32) > > and ID 2 (ESP_DES)? If the SA is negotiated to support ID 2, it still > needs to have an IV64/IV32 for CBC operation later, is it not right? I would say no; you only need what is negotiated. > Regards, > Li Zhou. note: your message arrived here with a malformed mail-header. Robert. -- Robert Luursema R.Luursema@incaa.nl Incaa Datacom b.v. From owner-ipsec@lists.tislabs.com Fri May 14 14:12:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07741; Fri, 14 May 1999 14:12:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06866 Fri, 14 May 1999 14:57:37 -0400 (EDT) Message-ID: <373C670C.DB496232@redcreek.com> Date: Fri, 14 May 1999 18:10:20 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ".MailList, ipsec" , jamie.jason@intel.com, michael.jeronimo@intel.com Subject: Re: draft-ietf-ipsec-policy-schema-00.txt Content-Type: multipart/mixed; boundary="------------47EA2C5CC15AD10F58826B80" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------47EA2C5CC15AD10F58826B80 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy () Kudos on your draft, we like it very much. I have two specific architectural level complements, one architectural level question, and two detail level questions. Complements: The concept of a rule equals an OR'd list of conditions matched with an AND'd list of actions is good. I hope the LDAP schema authors take up this track also (any word on the new LDAP schema draft guy's). The Policy is a set of rules, only one of which is in effect at this time is also well matched to some customer requirements we are hearing. Architectural Question: Where should "action" fit into the class hierarchy? My expectation is that the general IETF Policy WG (different from the IPSec Policy WG) will be forming a generalized condition <-> action schema. Under that, IPSec would fit in as a particular instantiation of an action. Have you thought about merging your polices, rules, and conditions work into the policy working group and then forming a draft to detail out an instantiation of a particular (IPSec) policy action. Detail Level Questions: What an IPSec proposal contains seems to have left out compression... oversight? A couple of things about the IPSecPermitAction and IPSecDenyAction. First this list is too short. The Permit/Deny language is something we inherit from firewalls which choose between those actions. But IPSec can choose between three action: Bypass, Block, and Secure. Where Bypass means pass in clear, Secure means apply a security transform, and block means drop. In your draft you seem to imply that the absence of a Permit or Deny means Secure. I think it would be better to be explicit (use three terms) and I also think that the word "permit" allows for ambiguity (does it mean bypass or does it mean secure). Also, It seems to me that all three of these choices need to be available to tunnels as well as transports. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; --------------47EA2C5CC15AD10F58826B80 Content-Type: text/x-vcard; charset=us-ascii; name="rcharlet.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ricky Charlet Content-Disposition: attachment; filename="rcharlet.vcf" begin:vcard n:Charlet;Ricky tel;fax:(510) 745-3999 tel;work:(510) 795-6903 x-mozilla-html:FALSE org:RedCreek Communications;Engineering adr:;;3900 Newpark Mall Dr.;Newark;CA;94560;USA version:2.1 email;internet:rcharlet@redcreek.com title:Software Engineer x-mozilla-cpt:;-30400 fn:Ricky Charlet end:vcard --------------47EA2C5CC15AD10F58826B80-- From owner-ipsec@lists.tislabs.com Fri May 14 14:42:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07946; Fri, 14 May 1999 14:42:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06960 Fri, 14 May 1999 15:50:31 -0400 (EDT) Message-ID: From: "Jason, Jamie" To: "'Ricky Charlet'" , ".MailList, ipsec" , "Jeronimo, Michael" , ipsec-policy@mail.timestep.com Subject: RE: draft-ietf-ipsec-policy-schema-00.txt Date: Fri, 14 May 1999 12:58:57 -0700 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 > Architectural Question: > Where should "action" fit into the class hierarchy? My expectation is > that the general IETF Policy WG (different from the IPSec Policy WG) > will be forming a generalized condition <-> action schema. Under that, > IPSec would fit in as a particular instantiation of an > action. Agreed. It is our expectation that the policy WG will develop the core schema necessary. Other working groups would deveolop domain-dependent conditions and actions as necessary. In our particular schema, we don't have any domain specific conditions, but obviously we have domain-specific actions. > Have you thought about merging your polices, rules, and conditions > work into the policy working group and then forming a draft to detail out an > instantiation of a particular (IPSec) policy action. That is the direction we would like to see this go. The reason for our presenation at Minneapolis IETF and this draft is to stimulate discussion about policy in general as well as policy for IPSEC. It is our belief that what you state is what will eventually transpire. > What an IPSec proposal contains seems to have left out > compression...oversight? Yes. Our particular work didn't include compression, but to be complete it should indeed include compression. > In your draft you seem to imply that the absence of a Permit > or Deny means Secure. At this time, we have 4 unique IPSEC actions: (1) deny (or block), (2) permit (or bypass), (3) tunnel action, or (4) transport action. I agree that there may be some ambiguity with the terms (as you may be able to tell, my first experience in the industry was with firewalls) and will make a note of it. In our current system, there is a requirement that there be an action object associated with the condition - so the absence of a permit or deny action means that there is a transport or tunnel action (i.e., secure action). We could have been clearer about it, but if I were to draw the permit and deny actions in the class diagram, they would derive from the IPSecAction (in other words, peers to the secure actions). I will make a note for the next rev of the draft. Jamie From owner-ipsec@lists.tislabs.com Fri May 14 15:04:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08052; Fri, 14 May 1999 15:04:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07073 Fri, 14 May 1999 16:19:42 -0400 (EDT) From: Dan McDonald Message-Id: <199905142026.NAA24829@kebe.Eng.Sun.COM> Subject: Re: IKE transport (was INITIAL-CONTACT issues) To: pkoning@xedia.com (Paul Koning) Date: Fri, 14 May 1999 13:25:39 -0700 (PDT) Cc: danmcd@Eng.Sun.Com, ipsec@lists.tislabs.com In-Reply-To: <199905142019.QAA28267@tonga.xedia.com> from "Paul Koning" at May 14, 99 04:19:49 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Dan> for IKE. You'll never get past the 3-way handshake if you have > Dan> a malicious eavesdropper. > > You're talking about an active attack here, not an eavesdropper > (passive attacker). And this is a denial of service attack. When I used the word malicious, there was an implicit "active" in that word. Sorry for not being clear. > Sure, you can prevent the TCP connection from establishing. Likewise, I > believe, you can prevent an IKE handshake from completing by inserting > suitable packets, or deleting others. You don't need to ability to delete packets to thwart TCP, only the ability to inject. As for IKE, perhaps one can inject IKE-over-UDP packets to thwart IKE, but adding TCP vulnerabilities complicates the problem. > I wouldn't think that anyone claims IKE to be resistant to denial of > service attacks. Are you saying it is? No. I am saying that we're in the risk reduction business, so why bother with TCP and its vulnerabilities when UDP works equally well. Using TCP introduces new forms of attack. Finally, from an end-to-end point of view, the request-reply nature of IKE doesn't lend itself well to a reliable streaming protocol. Even though HTTP works pretty well, many would argue that a scalable request/reply (or RPC w/congestion avoidance) datagram protocol would've served better. Dan From owner-ipsec@lists.tislabs.com Fri May 14 15:04:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08065; Fri, 14 May 1999 15:04:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07033 Fri, 14 May 1999 16:11:23 -0400 (EDT) Date: Fri, 14 May 1999 16:19:49 -0400 Message-Id: <199905142019.QAA28267@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: danmcd@Eng.Sun.Com Cc: ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) References: <199905132006.NAA22876@kebe.Eng.Sun.COM> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan McDonald writes: Dan> There is nothing to stop malicious injections of RST packets Dan> into a TCP stream. This is the biggest reason to not use TCP Dan> for IKE. You'll never get past the 3-way handshake if you have Dan> a malicious eavesdropper. You're talking about an active attack here, not an eavesdropper (passive attacker). And this is a denial of service attack. Sure, you can prevent the TCP connection from establishing. Likewise, I believe, you can prevent an IKE handshake from completing by inserting suitable packets, or deleting others. I wouldn't think that anyone claims IKE to be resistant to denial of service attacks. Are you saying it is? paul From owner-ipsec@lists.tislabs.com Fri May 14 16:04:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08430; Fri, 14 May 1999 16:04:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07175 Fri, 14 May 1999 17:17:16 -0400 (EDT) Message-ID: <373C947E.E038269C@indusriver.com> Date: Fri, 14 May 1999 17:24:14 -0400 From: Ben McCann X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ISP's who assign unrouteable addresses Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My company has encountered two ISP's, US West and MediaOne, who assign unrouteable addresses (10.x.x.x) to some of their customers. The ISP's run NAT in the head-end of their cable network or ADSL network to translate those addresses before they hit the Internet. Obviously, an end-user wanting IPSEC is in trouble. Any thoughts about how to deal with this problem? I personally don't mind NAT if it is performed at the boundary between a stub network and the Internet. The owner of that network can NAT and employ a security gateway if he needs IPSEC. On the other hand, I think ISP's that use NAT are short-changing their customers. Is there anything we can offer a customer who is stuck with one of the unrouteable addresses? -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Fri May 14 16:26:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08666; Fri, 14 May 1999 16:26:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07219 Fri, 14 May 1999 17:42:39 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145150A5@RED-MSG-50> From: Richard Draves To: ipsec@lists.tislabs.com Subject: RE: ISP's who assign unrouteable addresses Date: Fri, 14 May 1999 14:50:37 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > My company has encountered two ISP's, US West and MediaOne, who assign > unrouteable addresses (10.x.x.x) to some of their customers. The ISP's > run NAT in the head-end of their cable network or ADSL > network to translate > those addresses before they hit the Internet. > > Obviously, an end-user wanting IPSEC is in trouble. > > Any thoughts about how to deal with this problem? I personally don't > mind NAT if it is performed at the boundary between a stub network > and the Internet. The owner of that network can NAT and employ a > security gateway if he needs IPSEC. > > On the other hand, I think ISP's that use NAT are short-changing their > customers. Is there anything we can offer a customer who is stuck > with one of the unrouteable addresses? How awful! I'm getting a cable modem installed next week, I hope this doesn't happen to me. Here's a solution: run IPv6 over IPv4. Then you will be oblivious to any NAT at the v4 level. Rich From owner-ipsec@lists.tislabs.com Fri May 14 16:49:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA08995; Fri, 14 May 1999 16:49:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07258 Fri, 14 May 1999 17:52:01 -0400 (EDT) Message-ID: <373C8FED.4927518C@redcreek.com> Date: Fri, 14 May 1999 21:04:45 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: ICMP in IPSec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy () There exists a draft named draft-ietf-icmp-handle-44-00.txt which is a template nameing each ICMP message and provides a space describing how to handle that ICMP message. The draft is a template because none of the descriptions are filled in. Back at the 44th (Minneapolis) I believe I recall the working group deciding that ICMP handling needed to get more specific befor closing the group. There was a call for volunteers to put in effort. I volunteered and here is a bit of effort. I have not followed Michael Richardson's draft (icmp-handle) in my 'initial thoughts' post. I find it more clear to ponder these out in terms of 'situational examples'. I hope (naively??) that my list of situations is complete. The goal would be to move from my situational format to filling in Michael's draft with the details per message rather than per situation. These are my initial thoughts. I am looking for feed back. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### ===================== || || +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | | E1 |---|Sgw1 |---| R1 |---|Sgw2 |---| R2 |----| E2 | | | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ E1' E2' Terminology: o E1 and E2 are IPSec endpoints. These endpoints are defined in Sgw1 and Sgw2 by IPSec selectors. o Sgw1 and Sgw2 are IPsec Security Gateways. o R1 and R2 are non-IPSec routers. o E1' and E2' are derived from the deffinitions of E1 and E2. These 'prime' endpoints are defined only by IP address or IP Address range. Whereas E1 and E2 may have been defined by IP address(range) and ports and protocols, and/or fqdn, and/or user@fqdn etc... ICMP traffic from Sgw1 to E1. Sgw1 needs to ask itself if it trusts that the traffic causing the ICMP event is really from E1, a trusted endpoint. Sgw1 may choose to always trust that any traffic received from this interface is authentic, may decide never to trust any traffic received on this interface, or may decide that traffic received on this interface is authentic only if its source address matches E1'. This matching, only results in weak authentication which could easily be spoofed. The choice of never trust, always trust, or match src address against E1' to determine trust, when considering whether to respond to ICMP MUST be an administratively configurable behavior per interface with the default action being never to trust. ICMP traffic from R1 to E1. This is unexpected. R1 should never have any knowledge of E1's IP address and therfore should not be able to direct ICMP messages at E1'. All such ICMP traffic MUST be silently discarded by Sgw1 unless an operator has configured an applicible bypass IPSec selector (this is NOT recomended). ICMP traffic from R1 to Sgw1. Traffic from R1 does not arrive in an SA and is therefore of highly suspect integrity. If R1 is sending an IMCP error message, then the original offending IP packet returned with the ICMP error message is almost certianly trunkated, possilby making it impossible to deterime the original sender's IP address. Also, there are extremely few ICMP messages which R1 might return that E1' could possibly be interested in. These are "fragmentation needed", "unreachable due to TOS (net and host)", and to a lessor degree "source quench" and/or ECN notifications. The Fragmentation and TOS messages are of possible interest to E1' because the associated bits from E1's IP header were copied to the tunnel mode outer IP header and therefore exposed to the Internet which might rerun valid errors related to these fields. Since the outer IP header hides all other information about the inner IP header, no ICMP reachable errors, or redirect errors, or TTL errors, or parameter problem errors relate to the IP header which E1' sent. The only other valid information that R1 may have for E1' would relate to flow control. A source quench message inticates that E1' should take some flow control action, but the soruce quench mechanism is depricated and current router implementations are advised not to originate ICMP soruce quench messages so these are safly ignorable. There is a new experimental protocol called "Explicite Congestion Notification". If it is ever embraced by the IPSec comunity, some people may wish to examine how to make it work in this scenario. But as for now, ECN will not be considered. So Sgw1 has four questions to answer about ICMP messages received from R1 intended for return to E1'. 1. Is this message intended for me directly or for some endpoint I protect? 2. Is this an interesting message? 3. Do I trust the message? 4. Is there enough information in the message to be useful to E1'? To answer question number 1 above use the following logic: If message is an ICMP query, then it is not for E1'... respond to ICMP queries to this interface as per local interface policy. If message is an ICMP error, then examine the original offending packet data IPSec Header field for a valid SPI number. Presence of an SPI implies that this message is intended for some endpoint and not for the Sgw itself. If the message is in fact intended for this Sgw, then local policy should specify whether to handle/respond or ignore the message. If message is intended for some endpoint behind this gateway, and local policy allowed ICMP processing on this interface, then proceed to question 2 from above. To answer question 2above, only the IMCP error messages: o fragmentation needed but DF set o network unreachable for TOS o host unreachable for TOS MAY be forwarded onward to E1'. All other ICMP messages intended for E1' MUST be dropped. Now you may ask yourself, "What about all those unreachable messages?" Receipt of an 'unreachable' IMCP error message on Sgw1 while it was trying to send to Sgw2 is not a problem that E1 need be informed of directly. It is an implementation concern with what to do when tunneled traffic is attempting to reach an unreachable peer gateway. To answer question number 3 above, the only secure course is to not trust messages appearing at Sgw1 which did not arrive in an SA. But an Operations and Maintenance group might evaluate the security risk (DOS attack) of accepting these limited IMCP error messages as worth the value of knowing about PMTU, and/or TOS reachability. So they will need a configurable option to allow each of these messages. The IMCP configuration MUST allow for explicit pass/block filtering on Fragmentation Needed messages, and on TOS messages. These filter rules are over and above what is achievable with IPSec selectors. To answer question 4 above, first understand the problem. It may be that the IMCP error message did not bundle the entire original offending IP packet. We know the original offending IP packet was a tunneled packet with an outer IP header, and an IPSec header, and an inner IP header and data and trailers. In order to be useful to E1', we need to recover the original inner IP header and first 8 bytes of IP data. This is because E1' will need to deliver this IMCP message to a transport protocol, therefore E1' will need to identify the exact socket this packet was sent from. Attempting to guess E1's identity from the SPI# in the SA header (almost always present in the returned original offending packet) will be insufficient to identify the exact socket on E1' and is therefore a fruitless endeavor. But recovering the inner IP header from the original offending packet may not always be possible. And even if it is possible, it will most likely be a difficult endeavor. Recovering the inner IP header in the case of an AH tunneled packet requires that we be able to see the entire outer IP header (20 bytes +options) the entire AH header (32 or more bytes), 20 or more bytes of the inner IP header (full header sans options) and 8 bytes of inner IP payload. If there is enough data present, then the inner IP packet header may be read. But it is extremely unlikely that the entire original IP packet was returned so that the data will not be able to be authenticated (but understand that if we have gotten this far, it means that an administrator has already made the choice to trust this information in spite of its inability to be authenticated). Recovering the inner IP header in the case of an ESP tunneled packet requires that we be ale to see the entire outer IP header (20 bytes +options) and enough of the ESP packet so that we may reference the SPI and then decrypt enough of the payload data to reveal the inner IP header, optinos and first 8 bytes of data. Again, it is very unlikely that we will have the entire original IP packet and will not be able to authenticate, but a trust decisions has already been made in spite of this limitation. In cases of SA bundles where there are multiple transforms applied, the SPI will indicate to us which transforms we need to undo and how much of the original IP packet we need to recover. If the original inner IP packet header cannot be recovered, cease all further processing related to handling this error and drop the ICMP packet. An implementation MAY wish to make this an auditable event. If the original inner IP packet header and the first 8 bytes of original IP packet data can be recovered, then the security gateway MUST construct a new IMCP error message. It MUST be addressed to the source address named in the original inner IP header. It's ICMP type, ICMP code, IP TOS, and IP precedence MUST match the old ICMP packet (now being discarded). And the data it contains MUST be the original inner IP packet header plus 8 bytes of the original inner IP packet data. ICMP traffic from Sgw2 to Sgw1: This situation occurs when Sgw2 receives an IP packet from Sgw1 which is addressed to Sgw2. This occurs frequently since Sgw2 is the endpoint of a tunnel. This discussion should not be confused with Sgw2 deciding to send an ICMP error to E1', which might occur after tunnel decapsulation. That situation is discussed in the next section. Sgw2 may respond to an IMCP query from Sgw1, or may generate an ICMP error to return to Sgw1. Sgw2 may respond to a query in the clear if an IPSec selector matching protocol=IMCP and src address=Sgw1 allowed the bypass action (Sgw2 might have query responded to anything in the Internet if the bypass selector for protocol=ICMP had allowed). Sgw2 may respond to an IMCP query from Sgw1 in an SA if the IPSec selector specified a Secure action. (This SA might need to be negotiated, the IMCP query response SHOULD be held until the SA is up). Sgw2 MUST NOT ever decide to generate an ICMP error message to Sgw1 at this point. Realize that this is before any SPI matching and IPSec untransforming has cured. After IPSec untransforming has occurred, Sgw2 may decide to send errors back to E1', that is covered in the next section. At this point, there is no error message that Sgw2 could send to Sgw1 which Sgw1 may find to be actionable. The IP packet was obviously deliverable. It is not yet known if it is administratively prohibited or TOS prohibited. It is not realistic to tell an ISAKMP peer to redirect. Even if the packet times out during re-assemble on Sgw2, this is not information that Sgw1 cares about (in a tunnel mode SA). ICMP traffic from Sgw2 to E1': After Sgw2 has SPI matched the tunneled packet and untransformed the packet, it has the IP header and payload from E1' in hand. Sgw2 may either realize that E1' has sent it an ICMP query or that traffic sent by E1' destined for other locations, is offending and it should send back an IMCP error to E1'. Because the traffic arrived through an SA, Sgw2 MUST consider the traffic authentic. ICMP queries should be handled as per relevant RFC and returned to E1' being sent trough the complementary SA back to Sgw1. Sgw1 must be able to recognize that ICMP traffic arriving in an SA, destined to E1' and sourced from that SA's ISAKMP peer is allowable and forward the ICMP packet. Sgw1 MUST do this even if the SA selectors did not natrually allow ICMP traffic. When Sgw2 decides to return an ICMP error to E1', similar processing occurs. Sgw2 creates the IMCP error message and MUST attach the entire offending IP packet and must ensure that the DF bit is cleared. Note, that at this point, the offending IP packet is in an un-encapsulated state. The ICMP packet which bundles the original offending IP packet is sent to E1' via Sgw1 through the complement SA of the SA it arrived on. Sgw1 recognizes that an ICMP packet to E1' arriving on an SA from the ISAKMP peer far end of the SA is allowable and forwards the packet. ICMP traffic from R2 to E1' MUST be dropped by Sgw2 due to no match with selectors. But, note a workaround here. If an operations and maintenance group wishes to trust and allow these ICMP messages (from R2 to E1'), then they may configure on Sgw1 and Sgw2, new selectors which match R1's IP addresses, to E1's IP address(es) and protocol = ICMP. In this case, R2 becomes a new, legitimate endpoint (let's say E3). An SA from Sgw2 to Sgw1 for carrying E3 to E1' ICMP traffic is negotiated and utilized. The parameters of this SA will be entirely up to the O&M group. ICMP traffic from E2' to E1': Handle as per IPSec selector specifications on Sgw2. It is recommended that even when E2 is more narrowly idenified than an IP address, that protocol=ICMP be configured to fit in the selector. New requirements for IPSec Security Gateways. o a per interface ICMP allow/deny/if-match-endpoint-IP config toggle o a per interface trust ICMP error frag-needed toggle o a per interface trust ICMP error TOS deny toggle o when generating an ICMP error, MUST bundel entire original IP datagram and clear DF bit. o Never send ICMP errors to an ISAKMP peer. From owner-ipsec@lists.tislabs.com Fri May 14 16:55:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09081; Fri, 14 May 1999 16:55:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07278 Fri, 14 May 1999 17:58:41 -0400 (EDT) Message-Id: <199905142158.OAA08963@gallium.network-alchemy.com> To: Dan McDonald cc: pkoning@xedia.com (Paul Koning), ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) In-reply-to: Your message of "Fri, 14 May 1999 13:25:39 PDT." <199905142026.NAA24829@kebe.Eng.Sun.COM> Date: Fri, 14 May 1999 14:58:55 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RE: TCP/UDP/DoS Denial-of-service is such a slipery slope. If you want to actively attack IKE, just eat the last packet of Main Mode or Quick Mode... Dan's right in that using TCP only changes the problem set. It doesn't solve anything other than by providing a fairly high-cost keepalive mechanism. Derrell From owner-ipsec@lists.tislabs.com Fri May 14 17:47:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA09482; Fri, 14 May 1999 17:47:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07365 Fri, 14 May 1999 18:57:03 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Derrell D. Piper'" , Dan McDonald Cc: pkoning@xedia.com, ipsec@lists.tislabs.com Subject: RE: IKE transport (was INITIAL-CONTACT issues) Date: Fri, 14 May 1999 16:05:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about using udp for the first IKE session between 2 endpoints and then using a tcp-over-ipsec as the transport for the rest of the IKE sessions that could happen between the end-points? DOS as the sole reason for not using TCP seems to be a high price. And udp has just changed the problem set. -- sankar -- -----Original Message----- From: Derrell D. Piper [mailto:ddp@network-alchemy.com] Sent: Friday, May 14, 1999 2:59 PM To: Dan McDonald Cc: pkoning@xedia.com; ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) RE: TCP/UDP/DoS Denial-of-service is such a slipery slope. If you want to actively attack IKE, just eat the last packet of Main Mode or Quick Mode... Dan's right in that using TCP only changes the problem set. It doesn't solve anything other than by providing a fairly high-cost keepalive mechanism. Derrell From owner-ipsec@lists.tislabs.com Fri May 14 18:55:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA09792; Fri, 14 May 1999 18:55:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07493 Fri, 14 May 1999 20:08:36 -0400 (EDT) Message-Id: <199905150016.RAA03824@potassium.network-alchemy.com> To: Sankar Ramamoorthi cc: "'Derrell D. Piper'" , Dan McDonald , pkoning@xedia.com, ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) In-reply-to: Your message of "Fri, 14 May 1999 16:05:01 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3821.926727383.1@network-alchemy.com> Date: Fri, 14 May 1999 17:16:23 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds like a pointless hack. You'd have to do an regular UDP-based IKE to generate IPSec SAs which would cover TCP traffic for IKE. And this buys you what? It sounds like the only desire for using TCP is to give some "network security aware" IS guy a warm fuzzy. If this IS guy wants end-to-end security then he has to allow stuff through his firewall (and it's more than just UDP too). If he doesn't want end-to-end security then IKE's transport mechanism isn't an issue. UDP does _not_ changed the problem set. Introduction of TCP does because there's a new problem as Dan McDonald pointed out. Dan. On Fri, 14 May 1999 16:05:01 PDT you wrote > How about using udp for the first IKE session between 2 endpoints and then > using a tcp-over-ipsec as the transport for the rest of the IKE sessions > that could happen between the end-points? > > DOS as the sole reason for not using TCP seems to be a high price. > And udp has just changed the problem set. > > -- sankar -- > > > -----Original Message----- > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > Sent: Friday, May 14, 1999 2:59 PM > To: Dan McDonald > Cc: pkoning@xedia.com; ipsec@lists.tislabs.com > Subject: Re: IKE transport (was INITIAL-CONTACT issues) > > > RE: TCP/UDP/DoS > > Denial-of-service is such a slipery slope. If you want to actively attack > IKE, just eat the last packet of Main Mode or Quick Mode... Dan's right in > that using TCP only changes the problem set. It doesn't solve anything > other > than by providing a fairly high-cost keepalive mechanism. > > Derrell From owner-ipsec@lists.tislabs.com Fri May 14 20:31:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA21970; Fri, 14 May 1999 20:31:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07618 Fri, 14 May 1999 21:49:28 -0400 (EDT) Message-Id: <199905150157.SAA04048@potassium.network-alchemy.com> To: Sankar Ramamoorthi cc: ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) In-reply-to: Your message of "Fri, 14 May 1999 18:46:52 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4045.926733447.1@network-alchemy.com> Date: Fri, 14 May 1999 18:57:27 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 14 May 1999 18:46:52 PDT you wrote > My main desire for requesting the use of a reliable transport was to avoid > the > problem of tuning retransmit timers. Except using your suggestion you'd have to establish every peer-wise relationship using UDP with retransmit timers and then you'd get to do Quick Modes over TCP. Doesn't sound like much of a benefit. > I was looking at it from the point of security gateways needing to support > thousands of IKE sessions. Supporting thousands of IKE sessions on a security gateway is not a problem. Dan. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Friday, May 14, 1999 5:16 PM > To: Sankar Ramamoorthi > Cc: 'Derrell D. Piper'; Dan McDonald; pkoning@xedia.com; > ipsec@lists.tislabs.com > Subject: Re: IKE transport (was INITIAL-CONTACT issues) > > > Sounds like a pointless hack. You'd have to do an regular UDP-based > IKE to generate IPSec SAs which would cover TCP traffic for IKE. And > this buys you what? > > It sounds like the only desire for using TCP is to give some "network > security aware" IS guy a warm fuzzy. If this IS guy wants end-to-end > security then he has to allow stuff through his firewall (and it's more > than just UDP too). If he doesn't want end-to-end security then IKE's > transport mechanism isn't an issue. > > UDP does _not_ changed the problem set. Introduction of TCP does because > there's a new problem as Dan McDonald pointed out. > > Dan. > > On Fri, 14 May 1999 16:05:01 PDT you wrote > > How about using udp for the first IKE session between 2 endpoints and then > > using a tcp-over-ipsec as the transport for the rest of the IKE sessions > > that could happen between the end-points? > > > > DOS as the sole reason for not using TCP seems to be a high price. > > And udp has just changed the problem set. > > > > -- sankar -- > > > > > > -----Original Message----- > > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > > Sent: Friday, May 14, 1999 2:59 PM > > To: Dan McDonald > > Cc: pkoning@xedia.com; ipsec@lists.tislabs.com > > Subject: Re: IKE transport (was INITIAL-CONTACT issues) > > > > > > RE: TCP/UDP/DoS > > > > Denial-of-service is such a slipery slope. If you want to actively attack > > IKE, just eat the last packet of Main Mode or Quick Mode... Dan's right > in > > that using TCP only changes the problem set. It doesn't solve anything > > other > > than by providing a fairly high-cost keepalive mechanism. > > > > Derrell From owner-ipsec@lists.tislabs.com Fri May 14 21:25:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA27490; Fri, 14 May 1999 21:25:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07600 Fri, 14 May 1999 21:38:53 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Dan Harkins'" , Sankar Ramamoorthi Cc: "'Derrell D. Piper'" , Dan McDonald , pkoning@xedia.com, ipsec@lists.tislabs.com Subject: RE: IKE transport (was INITIAL-CONTACT issues) Date: Fri, 14 May 1999 18:46:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My main desire for requesting the use of a reliable transport was to avoid the problem of tuning retransmit timers. I was looking at it from the point of security gateways needing to support thousands of IKE sessions. -- sankar -- -----Original Message----- From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] Sent: Friday, May 14, 1999 5:16 PM To: Sankar Ramamoorthi Cc: 'Derrell D. Piper'; Dan McDonald; pkoning@xedia.com; ipsec@lists.tislabs.com Subject: Re: IKE transport (was INITIAL-CONTACT issues) Sounds like a pointless hack. You'd have to do an regular UDP-based IKE to generate IPSec SAs which would cover TCP traffic for IKE. And this buys you what? It sounds like the only desire for using TCP is to give some "network security aware" IS guy a warm fuzzy. If this IS guy wants end-to-end security then he has to allow stuff through his firewall (and it's more than just UDP too). If he doesn't want end-to-end security then IKE's transport mechanism isn't an issue. UDP does _not_ changed the problem set. Introduction of TCP does because there's a new problem as Dan McDonald pointed out. Dan. On Fri, 14 May 1999 16:05:01 PDT you wrote > How about using udp for the first IKE session between 2 endpoints and then > using a tcp-over-ipsec as the transport for the rest of the IKE sessions > that could happen between the end-points? > > DOS as the sole reason for not using TCP seems to be a high price. > And udp has just changed the problem set. > > -- sankar -- > > > -----Original Message----- > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > Sent: Friday, May 14, 1999 2:59 PM > To: Dan McDonald > Cc: pkoning@xedia.com; ipsec@lists.tislabs.com > Subject: Re: IKE transport (was INITIAL-CONTACT issues) > > > RE: TCP/UDP/DoS > > Denial-of-service is such a slipery slope. If you want to actively attack > IKE, just eat the last packet of Main Mode or Quick Mode... Dan's right in > that using TCP only changes the problem set. It doesn't solve anything > other > than by providing a fairly high-cost keepalive mechanism. > > Derrell From owner-ipsec@lists.tislabs.com Sat May 15 05:24:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12720; Sat, 15 May 1999 05:24:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08087 Sat, 15 May 1999 06:31:05 -0400 (EDT) X-Lotus-FromDomain: SHIVA CORPORATION From: "Jesse Walker" To: Dan Harkins cc: ipsec@lists.tislabs.com Message-ID: <85256772.0038EEDA.00@zule.shiva.com> Date: Sat, 15 May 1999 06:31:19 -0400 Subject: Re: IKE transport (was INITIAL-CONTACT issues) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan: If supporting thousands of SAs on a security gateway is not a problem, how are you doing resource recovery again? That is, how do you recover the security associations whose keys have not yet timed out but which are no longer in use (because the peer has dropped its keys). There is no standardized algorithm to do this. Some implementations do nothing. Other implementations have an inactivity timeout. Other implementations aggressively renegotiate their keys. Others run proprietary keepalive algorithms. IKE's lack of a proper call-control or session management infrastructure is a real problem. That is why it takes hours for the implementers themselves to trouble-shoot any problem at the IPSec bakeoffs. How is this stuff supposed to work in the real world? Just my two cents... Jesse Walkere Dan Harkins on 05/14/99 09:57:27 PM To: Sankar Ramamoorthi cc: ipsec@lists.tislabs.com (bcc: Jesse Walker/Shiva Corporation) Subject: Re: IKE transport (was INITIAL-CONTACT issues) On Fri, 14 May 1999 18:46:52 PDT you wrote > My main desire for requesting the use of a reliable transport was to avoid > the > problem of tuning retransmit timers. Except using your suggestion you'd have to establish every peer-wise relationship using UDP with retransmit timers and then you'd get to do Quick Modes over TCP. Doesn't sound like much of a benefit. > I was looking at it from the point of security gateways needing to support > thousands of IKE sessions. Supporting thousands of IKE sessions on a security gateway is not a problem. Dan. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Friday, May 14, 1999 5:16 PM > To: Sankar Ramamoorthi > Cc: 'Derrell D. Piper'; Dan McDonald; pkoning@xedia.com; > ipsec@lists.tislabs.com > Subject: Re: IKE transport (was INITIAL-CONTACT issues) > > > Sounds like a pointless hack. You'd have to do an regular UDP-based > IKE to generate IPSec SAs which would cover TCP traffic for IKE. And > this buys you what? > > It sounds like the only desire for using TCP is to give some "network > security aware" IS guy a warm fuzzy. If this IS guy wants end-to-end > security then he has to allow stuff through his firewall (and it's more > than just UDP too). If he doesn't want end-to-end security then IKE's > transport mechanism isn't an issue. > > UDP does _not_ changed the problem set. Introduction of TCP does because > there's a new problem as Dan McDonald pointed out. > > Dan. > > On Fri, 14 May 1999 16:05:01 PDT you wrote > > How about using udp for the first IKE session between 2 endpoints and then > > using a tcp-over-ipsec as the transport for the rest of the IKE sessions > > that could happen between the end-points? > > > > DOS as the sole reason for not using TCP seems to be a high price. > > And udp has just changed the problem set. > > > > -- sankar -- > > > > > > -----Original Message----- > > From: Derrell D. Piper [mailto:ddp@network-alchemy.com] > > Sent: Friday, May 14, 1999 2:59 PM > > To: Dan McDonald > > Cc: pkoning@xedia.com; ipsec@lists.tislabs.com > > Subject: Re: IKE transport (was INITIAL-CONTACT issues) > > > > > > RE: TCP/UDP/DoS > > > > Denial-of-service is such a slipery slope. If you want to actively attack > > IKE, just eat the last packet of Main Mode or Quick Mode... Dan's right > in > > that using TCP only changes the problem set. It doesn't solve anything > > other > > than by providing a fairly high-cost keepalive mechanism. > > > > Derrell From owner-ipsec@lists.tislabs.com Sat May 15 19:48:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA25658; Sat, 15 May 1999 19:48:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09099 Sat, 15 May 1999 20:31:14 -0400 (EDT) Date: Sat, 15 May 1999 20:39:04 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: ISP's who assign unrouteable addresses In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D810145150A5@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 14 May 1999, Richard Draves wrote: > > On the other hand, I think ISP's that use NAT are short-changing their > > customers. Is there anything we can offer a customer who is stuck > > with one of the unrouteable addresses? ... > > Here's a solution: run IPv6 over IPv4. Then you will be oblivious to any NAT > at the v4 level. The same solution also works without IPv6 involved: create a tunnel, and do whatever you want inside it. (For extra credit, tunnel out to some cooperative site on the Internet, and have them loan you some real address space. The Linux FreeS/WAN docs call this trick "extruded subnets", as the overall effect is that part of the other end's subnet is extruded through the tunnel to you.) Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Sun May 16 12:09:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21449; Sun, 16 May 1999 12:09:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10425 Sun, 16 May 1999 12:58:02 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199905161706.KAA03333@kc.livingston.com> Subject: Re: ISP's who assign unrouteable addresses To: bmccann@indusriver.com (Ben McCann) Date: Sun, 16 May 1999 10:06:03 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <373C947E.E038269C@indusriver.com> from "Ben McCann" at May 14, 99 05:24:14 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > My company has encountered two ISP's, US West and MediaOne, who assign > unrouteable addresses (10.x.x.x) to some of their customers. The ISP's > run NAT in the head-end of their cable network or ADSL network to translate > those addresses before they hit the Internet. > That may be OK, so long as the service provided is limited - such as simple e-mail access. Specifically, if the users are assured of only certain services that are guaranteed to work and not others, I dont see this as a breach of service. > Obviously, an end-user wanting IPSEC is in trouble. > I would be surprised if they are promised end-to-end IPSec as part of the service level agreement (SLA). > Any thoughts about how to deal with this problem? This is a problem only if it violates the SLA between the service provider and the customer. > I personally don't > mind NAT if it is performed at the boundary between a stub network > and the Internet. The owner of that network can NAT and employ a > security gateway if he needs IPSEC. > > On the other hand, I think ISP's that use NAT are short-changing their > customers. Is this opinion shared by the customers using the service? probably not. > Is there anything we can offer a customer who is stuck > with one of the unrouteable addresses? > > -Ben McCann > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 > cheers, suresh From owner-ipsec@lists.tislabs.com Sun May 16 16:32:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22578; Sun, 16 May 1999 16:32:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10918 Sun, 16 May 1999 17:31:39 -0400 (EDT) Message-Id: <199905162138.QAA22798@drawbridge.damark.com> From: "william.wells" To: "'Pyda Srisuresh'" , bmccann@indusriver.com Cc: ipsec@lists.tislabs.com Subject: RE: ISP's who assign unrouteable addresses Date: Sun, 16 May 1999 16:39:57 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Seems like this could have problems if 2 of their customers wanted to communicate with each other of if the customers wanted to use the 10.x.x.x address space. It would also seem like trouble if the customers ran a protocol (as a server) which used a command and data connection (in the fashion of FTP) where the command connection passed the IP/port of the data connection back to the other end and then waited for the connection. My experience is that NAT doesn't work well in this situation unless the protocol is commonly known. For example, we use "middleware" package internally. A PC connects to us via a command connection and are then informed to reconnect to the IP of our system on a specific port. All subsequent traffic occurs on the new connection. At one remote site, we decided to use NAT and immediately ran into problems since the NAT software on the routers didn't know how to translate the PORT command. I believe there are other software packages which also utilize a form of IP/Port redirection. If the customer is only doing simple things, as Pyda has said, or has contracted for an "end-node" type service (such as an AOL customer), this is probably OK. In some senses, doesn't AOL NAT everyone who uses their software? > -----Original Message----- > From: Pyda Srisuresh [SMTP:suresh@livingston.com] > Sent: Sunday, May 16, 1999 12:06 PM > To: bmccann@indusriver.com > Cc: ipsec@lists.tislabs.com > Subject: Re: ISP's who assign unrouteable addresses > > > > > My company has encountered two ISP's, US West and MediaOne, who assign > > unrouteable addresses (10.x.x.x) to some of their customers. The ISP's > > run NAT in the head-end of their cable network or ADSL network to > translate > > those addresses before they hit the Internet. > > > > That may be OK, so long as the service provided is limited - such as > simple e-mail access. > > Specifically, if the users are assured of only certain services that are > guaranteed to work and not others, I dont see this as a breach of service. > > > Obviously, an end-user wanting IPSEC is in trouble. > > > I would be surprised if they are promised end-to-end IPSec as part of the > service level agreement (SLA). > > > Any thoughts about how to deal with this problem? > > This is a problem only if it violates the SLA between the service provider > > and the customer. > > > I personally don't > > mind NAT if it is performed at the boundary between a stub network > > and the Internet. The owner of that network can NAT and employ a > > security gateway if he needs IPSEC. > > > > On the other hand, I think ISP's that use NAT are short-changing their > > customers. > > Is this opinion shared by the customers using the service? probably not. > > > Is there anything we can offer a customer who is stuck > > with one of the unrouteable addresses? > > > > -Ben McCann > > > > -- > > Ben McCann Indus River Networks > > 31 Nagog Park > > Acton, MA, 01720 > > email: bmccann@indusriver.com web: www.indusriver.com > > phone: (978) 266-8140 fax: (978) 266-8111 > > > > cheers, > suresh From owner-ipsec@lists.tislabs.com Sun May 16 19:52:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02327; Sun, 16 May 1999 19:52:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11283 Sun, 16 May 1999 20:28:42 -0400 (EDT) To: Henry Spencer Cc: IP Security List Subject: Re: ISP's who assign unrouteable addresses References: From: Derek Atkins Date: 16 May 1999 20:36:56 -0400 In-Reply-To: Henry Spencer's message of Sat, 15 May 1999 20:39:04 -0400 (EDT) Message-Id: Lines: 40 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, Tunneling is a great idea. However, while great in theory, there are practical problems to this: 1) There aren't many ISPs that will act as a tunnel endpoint. In fact, I haven't been able to find any myself, and was considering starting one on my own just for this purpose. There is a limit to the number of 'greasible' IP Addresses available. 2) When you tunnel, you take the added latency hits of packets going from you to the tunnel endpoint, and then from the endpoint to the final host. 3) To improve outgoing latency, some people will just send out packets from their tunneled IP Addresses. Unfortunately, some ISPs have begun to implement egress filters that block 'foreign' addresses, forcing you to take on that added latency. -derek Henry Spencer writes: > The same solution also works without IPv6 involved: create a tunnel, and > do whatever you want inside it. (For extra credit, tunnel out to some > cooperative site on the Internet, and have them loan you some real address > space. The Linux FreeS/WAN docs call this trick "extruded subnets", as > the overall effect is that part of the other end's subnet is extruded > through the tunnel to you.) > > Henry Spencer > henry@spsystems.net > (henry@zoo.toronto.edu) > -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon May 17 05:50:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA15582; Mon, 17 May 1999 05:50:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12306 Mon, 17 May 1999 06:08:54 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05D046@md-exchange1.nai.com> From: "Mason, David" To: IP Security List Subject: IPCOMP Date: Mon, 17 May 1999 03:14:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When negotiating IPCOMP is it standard practice to specify an spi size of zero in the IKE proposal payload when a well-known CPI should be used? If an spi size of 4 is used, should the least (or most) significant 16 bits of the spi in the proposal be used as the CPI or should the corresponding well-known CPI of the transform selected be used instead? If the spi conflicts with the transform selected should the proposal be rejected (for instance there are multiple transforms and the spi corresponds to the well-known CPI of one of the transfoms but an alternate transform is selected)? Are people using the spi in the proposal payload to specify the CPI? -dave From owner-ipsec@lists.tislabs.com Mon May 17 10:01:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17478; Mon, 17 May 1999 10:01:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12894 Mon, 17 May 1999 09:49:08 -0400 (EDT) Date: Mon, 17 May 1999 09:57:13 -0400 Message-Id: <199905171357.JAA02195@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sankar@vpnet.com Cc: ipsec@lists.tislabs.com Subject: RE: IKE transport (was INITIAL-CONTACT issues) References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sankar" == Sankar Ramamoorthi writes: Sankar> How about using udp for the first IKE session between 2 Sankar> endpoints and then using a tcp-over-ipsec as the transport Sankar> for the rest of the IKE sessions that could happen between Sankar> the end-points? Yikes. It seems really ugly to changes horses, er., transports in midstream. There really is no major functional difference between using UDP with reliability/keepalive in the application, and TCP with some of that stuff moved into the transport. Given that the decision has been made to use UDP, my inclination is to say we should stick with it. If there is strong enough reason to switch, then let's switch. But I find it hard to imagine a reason strong enough to justify switching half the time, yet weak enough to justify not switching the rest of the time. paul From owner-ipsec@lists.tislabs.com Mon May 17 11:50:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18428; Mon, 17 May 1999 11:50:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13436 Mon, 17 May 1999 12:04:13 -0400 (EDT) Message-ID: <926A591C08E3D211960600E029101CCC15331B@mxclsa> From: Black_David@emc.com To: rcharlet@redcreek.com, ipsec@lists.tislabs.com Subject: RE: ICMP in IPSec Date: Mon, 17 May 1999 12:07:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Minor Nit: > There is a new > experimental protocol called "Explicit Congestion Notification". If it > is ever embraced by the IPSec community, some people may wish to examine > how to make it work in this scenario. But as for now, ECN will not be > considered. Actually ECN is not a concern in this context because ECN is based on flags in the existing TCP and IP headers, and does not use ICMP. See RFC 2481 for more details. ECN-ipsec interaction only shows up in tunnel mode, and is covered by a current I-D, draft-ipsec-ecn-00.txt. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com --------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon May 17 14:11:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19847; Mon, 17 May 1999 14:11:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14047 Mon, 17 May 1999 14:50:49 -0400 (EDT) Message-ID: From: Sankar Ramamoorthi To: "'Paul Koning'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: IKE transport (was INITIAL-CONTACT issues) Date: Mon, 17 May 1999 11:58:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Paul Koning [pkoning@xedia.com] >Sent: Monday, May 17, 1999 6:57 AM >To: Sankar@vpnet.com >Cc: ipsec@lists.tislabs.com >Subject: RE: IKE transport (was INITIAL-CONTACT issues) > >>>>>> "Sankar" == Sankar Ramamoorthi writes: > > Sankar> How about using udp for the first IKE session between 2 > Sankar> endpoints and then using a tcp-over-ipsec as the transport > Sankar> for the rest of the IKE sessions that could happen between > Sankar> the end-points? > >Yikes. It seems really ugly to changes horses, er., transports in >midstream. There really is no major functional difference between >using UDP with reliability/keepalive in the application, and TCP with >some of that stuff moved into the transport. Given that the decision >has been made to use UDP, my inclination is to say we should stick >with it. If there is strong enough reason to switch, then let's >switch. But I find it hard to imagine a reason strong enough to >justify switching half the time, yet weak enough to justify not >switching the rest of the time. > > paul I agree there is no functional difference with using UDP with reliablity/keepalive in the application and TCP with some of the stuff moved into the transport. However some of those functions are yet to be defined/standardized for IKE hence the desire to take advantage of TCP. Hopefully IPSecond will address many of the issues. One thing I am concerned with reliablity in the application is retransmission timers can gateways/end-stations aggressively retransmit for lost packets? If so could it have any effect on congestion (consider a gateway handling thousands of IKE sessions aggressively retransmitting). Or should the IKE implementation take into account of end-to-end characterstics (RTT..), congestion avoidance measures while retransmitting (similiar to TCP)? Or is congestion not an issue for IKE traffic? Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Tue May 18 04:27:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04212; Tue, 18 May 1999 04:27:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15846 Tue, 18 May 1999 05:03:42 -0400 (EDT) Message-ID: <37412E96.57C3DFD4@lmf.ericsson.se> Date: Tue, 18 May 1999 12:10:46 +0300 From: Ari Huttunen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: rcharlet@redcreek.com CC: ipsec@lists.tislabs.com Subject: Re: ICMP in IPSec References: <373C8FED.4927518C@redcreek.com> Content-Type: multipart/mixed; boundary="------------FE7189C7959F351653A9B5A5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------FE7189C7959F351653A9B5A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think that you're trying to approach this problem from a too low level perspective. The really important question is about trust. "Can I trust the sender of the ICMP message?" "Can I trust that the ICMP message has not been changed en-route?" There's really not much you can do if you don't know anything about the sender and the ICMP message is not IPSec protected. However, there is much else that can be done inside one ISP, for instance. You could state that every ISP router trusts every other ISP router for the purpose of sending reliable ICMP messages (or subset of them). The ISP routers as a community could also trust Vorlon VPN routers to issue reliable ICMP messages regarding Vorlon VPN traffic. Ditto for the Shadow VPN. All ICMP messages from unknown senders would be scrapped. Now the problem at hand is authentication, and the avoidance of creating an IPSec connection from every router to every other router. Supposing every router has a certificate, there're methods using X.509 to check if the router belongs to one of these sets: ISP, Vorlon, Shadow. Now, we could make our routers create a hop-by-hop IPSec connection when they first make contact. Since they're hop-by-hop, there's a limited number of them. We can then pass ICMP messages along these hop-by-hop IPSec SA's. No-one outside the group can alter (or see) these ICMP messages, we trust every router to correctly handle ICMP messages, so we can trust the ICMP message itself. There's likely some specific handling to be done at the edges between ISP and Vorlon VPN, for instance, to prevent leaking of information and incorrect ICMP message passing. Regards, Ari Huttunen Ericsson /// rcharlet@redcreek.com wrote: > > Howdy () > > There exists a draft named draft-ietf-icmp-handle-44-00.txt > which is a template nameing each ICMP message and provides a space > describing how to handle that ICMP message. The draft is a > template because none of the descriptions are filled in. Back at the > 44th (Minneapolis) I believe I recall the working group deciding that > ICMP handling needed to get more specific befor closing the group. There > was a call for volunteers to put in effort. I volunteered and here is a > bit of effort. > > I have not followed Michael Richardson's draft (icmp-handle) in > my 'initial thoughts' post. I find it more clear to ponder these out in > terms of 'situational examples'. I hope (naively??) that my list of > situations is complete. The goal would be to move from my situational > format to filling in Michael's draft with the details per message rather > than per situation. > > These are my initial thoughts. I am looking for feed back. > > -- > > #################################### > # Ricky Charlet > # (510) 795-6903 > # rcharlet@redcreek.com > #################################### --------------FE7189C7959F351653A9B5A5 Content-Type: text/x-vcard; charset=us-ascii; name="Ari.Huttunen.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ari Huttunen Content-Disposition: attachment; filename="Ari.Huttunen.vcf" begin:vcard n:Huttunen;Ari tel;fax:+358-9-2992634 tel;work:+358-9-2992472 x-mozilla-html:FALSE org:L M Ericsson;LMF/T/TK version:2.1 email;internet:Ari.Huttunen@lmf.ericsson.se title:Software Designer adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland x-mozilla-cpt:;-30024 fn:Ari Huttunen end:vcard --------------FE7189C7959F351653A9B5A5-- From owner-ipsec@lists.tislabs.com Tue May 18 11:45:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA17547; Tue, 18 May 1999 11:45:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16884 Tue, 18 May 1999 11:23:43 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA96AB7@exchange> From: Stephane Beaulieu To: ipsec , ipsra , internet-drafts@ietf.org Subject: New XAUTH draft Date: Tue, 18 May 1999 11:34:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, An updated revision of the Extended Authentication within ISAKMP/Oakley draft is now available. The URL is Comments are welcome. Stephane Beaulieu TimeStep Corporation sbeaulieu@timestep.com http://www.timestep.com (613) 599-3610 x4709 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Tue May 18 12:02:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18040; Tue, 18 May 1999 12:02:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17256 Tue, 18 May 1999 12:48:33 -0400 (EDT) Message-ID: <37418EB8.DEB61B89@redcreek.com> Date: Tue, 18 May 1999 16:00:56 +0000 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ari Huttunen CC: ipsec@lists.tislabs.com Subject: Re: ICMP in IPSec References: <37412E96.57C3DFD4@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Ari Huttunen wrote: > > Hi, > > I think that you're trying to approach this problem from a too low > level perspective. The really important question is about trust. > > "Can I trust the sender of the ICMP message?" > > "Can I trust that the ICMP message has not > been changed en-route?" > I absolutly agree that the central questions are about trust. The strategy I took was to surrender that decision to operations and mainentance groups. You may note that at several key points in my memo, I suggest that options be given to administrators to accept risk. So my idea was "let the administrator decide which ICMP to trust", Your idea is "build a new system which is capable of offering higher identity and data integrity to ICMP messages." Ah, I recognize that... it's the age old "do something expedient or do something architectual" question. Often it turns out to make sence to do both. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Tue May 18 15:25:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24141; Tue, 18 May 1999 15:25:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17841 Tue, 18 May 1999 16:10:50 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBC25@new-exc1.ctron.com> From: "Waters, Stephen" To: Stephane Beaulieu Cc: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Tue, 18 May 1999 21:19:19 +0100 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 Yes, I have a comment [on ISAKMP XAUTH]. A number of the authentication methods expressed here require the edge device to understand which authentication method is needed in advance of receiving the 'user name' from the remote peer. This seems limiting to me. Since it is likely that a these 'legacy' authentication methods are being used with RADIUS, wouldn't it be simple to re-use EAP and EAP extensions to RADIUS? This would allow the 'edge device' to be ignorant of the authentication required, or the process needed to enact it. This saves complication in the 'edge' device, allows central control of authentication policy and higher granularity on user/authentication mapping. A quote from EAP spec: "The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "back-end" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange." regards, Steve. -----Original Message----- From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] Sent: Tuesday, May 18, 1999 4:34 PM To: ipsec; ipsra; internet-drafts@ietf.org Subject: New XAUTH draft Greetings, An updated revision of the Extended Authentication within ISAKMP/Oakley draft is now available. The URL is Comments are welcome. Stephane Beaulieu TimeStep Corporation sbeaulieu@timestep.com http://www.timestep.com (613) 599-3610 x4709 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Tue May 18 18:00:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02309; Tue, 18 May 1999 18:00:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18118 Tue, 18 May 1999 18:05:48 -0400 (EDT) Message-ID: <3741E62B.61B3E97E@redcreek.com> Date: Tue, 18 May 1999 15:14:04 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Waters, Stephen" CC: Stephane Beaulieu , ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <29752A74B6C5D211A4920090273CA3DC4BBC25@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Waters, Stephen" wrote: > > Yes, I have a comment [on ISAKMP XAUTH]. A number of the authentication > methods expressed here require the edge device to understand which > authentication method is needed in advance of receiving the 'user name' from > the remote peer. I would add that *all* of the authentication methods require the edge device to understand their respective protocols. Translation? Oodles of added complexity to our (secure?) key exchange protocol. Godzillakmp. > This seems limiting to me. Since it is likely that a these 'legacy' > authentication methods are being used with RADIUS, wouldn't it be simple to > re-use EAP and EAP extensions to RADIUS? > > This would allow the 'edge device' to be ignorant of the authentication > required, or the process needed to enact it. This saves complication in the > 'edge' device, allows central control of authentication policy and higher > granularity on user/authentication mapping. > Perhaps this gets to the heart of it. What is the compelling argument for adding such complexity to the security device in order to support these legacy authentication methods? Shouldn't we instead be trying to move people toward PKI and other such mechanisms, rather than encouraging the continued use of text passwords/phrases? Scott From owner-ipsec@lists.tislabs.com Tue May 18 19:18:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA09001; Tue, 18 May 1999 19:18:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18346 Tue, 18 May 1999 20:09:04 -0400 (EDT) Message-ID: <3742031A.9A3B5821@cyphers.net> Date: Tue, 18 May 1999 17:17:42 -0700 From: Will Price X-Mailer: Mozilla 4.6 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Weak Crypto in Phase 1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We've been doing mass interoperability testing against other IKE implementations recently and I've noticed a disturbing trend in several well known products which need not be named specifically. I have encountered 2 products which are *only* capable of weak crypto (ie DES40, DES56, etc..) in Phase 1. The very same product will happily use TripleDES for Phase 2. Thus, there is no export issue, thus it seems there is no reason to make such a limitation. The second product uses only DES56 in Phase 1, similar to the above, and again will support TripleDES in Phase 2. These non-NAI products are not backwater IKE implementations, and thus the incongruity of this makes absolutely no sense. When even the hardware implementations we tested against supported TripleDES in Phase 1, these software implementations should certainly support it one would think. Protecting Phase 1 exchanges (and thus using that Phase 1 algorithm to protect all Phase 2 exchanges) with strong crypto can be at least as important as protecting Phase 2 SAs with strong crypto. Can anyone explain why it is that certain implementations have chosen to restrict their Phase 1 implementations to weak crypto, and yet in the very same product will happily use strong crypto for Phase 2?? - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5 iQA/AwUBN0ICxqy7FkvPc+xMEQIMegCg8vtBBSnuZxCtxzS9XtMGHXERY3oAn2v/ rJzwi1cewupTbolTTl29V0Fl =EyjD -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue May 18 19:31:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11693; Tue, 18 May 1999 19:31:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18424 Tue, 18 May 1999 20:34:56 -0400 (EDT) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Tue, 18 May 1999 17:30:57 -0700 (PDT) From: Glen Zorn To: "Waters, Stephen" cc: Stephane Beaulieu , ipsec@lists.tislabs.com Subject: RE: New XAUTH draft In-Reply-To: <29752A74B6C5D211A4920090273CA3DC4BBC25@new-exc1.ctron.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 18 May 1999, Waters, Stephen wrote: > > Yes, I have a comment [on ISAKMP XAUTH]. A number of the authentication > methods expressed here require the edge device to understand which > authentication method is needed in advance of receiving the 'user name' from > the remote peer. > > This seems limiting to me. Since it is likely that a these 'legacy' > authentication methods are being used with RADIUS, wouldn't it be simple to > re-use EAP and EAP extensions to RADIUS? EAP is only defined over PPP. I tried (in Orlando) to form a WG to generalize the EAP specification to allow its use over other protocols but was shot down by the Security ADs. > > This would allow the 'edge device' to be ignorant of the authentication > required, or the process needed to enact it. This saves complication in the > 'edge' device, allows central control of authentication policy and higher > granularity on user/authentication mapping. > > A quote from EAP spec: > > "The PPP Extensible Authentication Protocol (EAP) is a general > protocol for PPP authentication which supports multiple > authentication mechanisms. EAP does not select a specific > authentication mechanism at Link Control Phase, but rather postpones > this until the Authentication Phase. This allows the authenticator > to request more information before determining the specific > authentication mechanism. This also permits the use of a "back-end" > server which actually implements the various mechanisms while the PPP > authenticator merely passes through the authentication exchange." > > regards, Steve. > > -----Original Message----- > From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] > Sent: Tuesday, May 18, 1999 4:34 PM > To: ipsec; ipsra; internet-drafts@ietf.org > Subject: New XAUTH draft > > > Greetings, > > An updated revision of the Extended Authentication within > ISAKMP/Oakley draft is now available. > > The URL is > > Comments are welcome. > > > Stephane Beaulieu TimeStep Corporation > sbeaulieu@timestep.com http://www.timestep.com > (613) 599-3610 x4709 Fax: (613) 599-3617 > > From owner-ipsec@lists.tislabs.com Tue May 18 19:41:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA13288; Tue, 18 May 1999 19:41:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18456 Tue, 18 May 1999 20:47:41 -0400 (EDT) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Tue, 18 May 1999 17:43:37 -0700 (PDT) From: Glen Zorn To: "Scott G. Kelly" cc: "Waters, Stephen" , Stephane Beaulieu , ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-Reply-To: <3741E62B.61B3E97E@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 18 May 1999, Scott G. Kelly wrote: > "Waters, Stephen" wrote: > > > > Yes, I have a comment [on ISAKMP XAUTH]. A number of the authentication > > methods expressed here require the edge device to understand which > > authentication method is needed in advance of receiving the 'user name' from > > the remote peer. > > I would add that *all* of the authentication methods require the edge > device to understand their respective protocols. Translation? Oodles of > added complexity to our (secure?) key exchange protocol. Godzillakmp. An observation that many others have made, as well. IKE is just not the place to do user authentication. > > > This seems limiting to me. Since it is likely that a these 'legacy' > > authentication methods are being used with RADIUS, wouldn't it be simple to > > re-use EAP and EAP extensions to RADIUS? > > > > This would allow the 'edge device' to be ignorant of the authentication > > required, or the process needed to enact it. This saves complication in the > > 'edge' device, allows central control of authentication policy and higher > > granularity on user/authentication mapping. > > > > > > Perhaps this gets to the heart of it. What is the compelling argument > for adding such complexity to the security device in order to support > these legacy authentication methods? > Shouldn't we instead be trying to > move people toward PKI and other such mechanisms, rather than > encouraging the continued use of text passwords/phrases? > > Scott > From owner-ipsec@lists.tislabs.com Wed May 19 07:29:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22318; Wed, 19 May 1999 07:29:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20433 Wed, 19 May 1999 08:05:34 -0400 (EDT) Message-Id: <199905191213.IAA07963@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-xauth-04.txt Date: Wed, 19 May 1999 08:13:38 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Authentication Within ISAKMP/Oakley Author(s) : R. Pereira, S. Beaulieu Filename : draft-ietf-ipsec-isakmp-xauth-04.txt Pages : 16 Date : 18-May-99 This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-xauth-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-xauth-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990518122107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-xauth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990518122107.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed May 19 07:45:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22453; Wed, 19 May 1999 07:45:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20731 Wed, 19 May 1999 08:44:11 -0400 (EDT) Date: Wed, 19 May 1999 15:52:45 +0300 (EET DST) From: Rodney Thayer To: Will Price cc: ipsec@lists.tislabs.com Subject: Re: Weak Crypto in Phase 1 In-Reply-To: <3742031A.9A3B5821@cyphers.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have seen this before, originally thought it was essentially because people didn't think it mattered, or in fact hadn't thought about it or, their IKE parameters were hard-coded. In Minneapolis, I had a partial conversation with Hillarie (sp?) regarding this and I got the impression that the nature of the Phase 1 as opposed to Phase 2 exchanges might be constructed such that the crypto strength mismatch might not be a problem. Since (in some sort of curious justice-conserving twist of fate) she now works for an IPsec implementor (Novell) maybe she's on the list and can speak to this... On Tue, 18 May 1999, Will Price wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We've been doing mass interoperability testing against other IKE > implementations recently and I've noticed a disturbing trend in > several well known products which need not be named specifically. > > I have encountered 2 products which are *only* capable of weak crypto > (ie DES40, DES56, etc..) in Phase 1. The very same product will > happily use TripleDES for Phase 2. Thus, there is no export issue, > thus it seems there is no reason to make such a limitation. The > second product uses only DES56 in Phase 1, similar to the above, and > again will support TripleDES in Phase 2. > > These non-NAI products are not backwater IKE implementations, and > thus the incongruity of this makes absolutely no sense. When even > the hardware implementations we tested against supported TripleDES in > Phase 1, these software implementations should certainly support it > one would think. > > Protecting Phase 1 exchanges (and thus using that Phase 1 algorithm > to protect all Phase 2 exchanges) with strong crypto can be at least > as important as protecting Phase 2 SAs with strong crypto. > > Can anyone explain why it is that certain implementations have chosen > to restrict their Phase 1 implementations to weak crypto, and yet in > the very same product will happily use strong crypto for Phase 2?? > > > - -- Will > > Will Price, Architect/Sr. Mgr., PGP Client Products > Total Network Security Division > Network Associates, Inc. > > > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5 > > iQA/AwUBN0ICxqy7FkvPc+xMEQIMegCg8vtBBSnuZxCtxzS9XtMGHXERY3oAn2v/ > rJzwi1cewupTbolTTl29V0Fl > =EyjD > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Wed May 19 08:07:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22836; Wed, 19 May 1999 08:07:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20792 Wed, 19 May 1999 09:04:57 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA96CBC@exchange> From: Stephane Beaulieu To: Glen Zorn , "Scott G. Kelly" Cc: "Waters, Stephen" , Stephane Beaulieu , ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Wed, 19 May 1999 09:11:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > "Waters, Stephen" wrote: > > > > > > Yes, I have a comment [on ISAKMP XAUTH]. A number of the > authentication > > > methods expressed here require the edge device to understand which > > > authentication method is needed in advance of receiving > the 'user name' from > > > the remote peer. > > > > I would add that *all* of the authentication methods > require the edge > > device to understand their respective protocols. > Translation? Oodles of > > added complexity to our (secure?) key exchange protocol. > Godzillakmp. > > An observation that many others have made, as well. IKE is > just not the > place to do user authentication. We understand that we would all eventually like to do away with some of these legacy systems, however, for the time being, our customers demand that we support them. XAUTH allows for us to do this by using IKE to secure it. This provides a nice, easy migration path to those who would like to eventually fully deploy IPSec with a PKI, but for now are limited to using their existing infrastructures. XAUTH also ensures that these legacy system transactions enjoy the full security that IPSec provides. > > > > > > This seems limiting to me. Since it is likely that a > these 'legacy' > > > authentication methods are being used with RADIUS, > wouldn't it be simple to > > > re-use EAP and EAP extensions to RADIUS? > > > > > > This would allow the 'edge device' to be ignorant of the > authentication > > > required, or the process needed to enact it. This saves > complication in the > > > 'edge' device, allows central control of authentication > policy and higher > > > granularity on user/authentication mapping. > > > > > > > > > > > Perhaps this gets to the heart of it. What is the > compelling argument > > for adding such complexity to the security device in order > to support > > these legacy authentication methods? > > Shouldn't we instead be trying to > > move people toward PKI and other such mechanisms, rather than > > encouraging the continued use of text passwords/phrases? > > > > Scott > > > From owner-ipsec@lists.tislabs.com Wed May 19 09:49:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23965; Wed, 19 May 1999 09:49:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21003 Wed, 19 May 1999 10:28:58 -0400 (EDT) Message-ID: <3742CD07.DC1A1069@checkpoint.com> Date: Wed, 19 May 1999 17:39:03 +0300 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer CC: ipsec@lists.tislabs.com Subject: Re: Weak Crypto in Phase 1 References: Content-Type: multipart/mixed; boundary="------------E7C148E44C8DCA6B8F248056" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------E7C148E44C8DCA6B8F248056 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rodney Thayer wrote: > I have seen this before, originally thought it was essentially because > people didn't think it mattered, or in fact hadn't thought about it > or, their IKE parameters were hard-coded. > > In Minneapolis, I had a partial conversation with Hillarie (sp?) regarding > this and I got the impression that the nature of the Phase 1 as opposed to > Phase 2 exchanges might be constructed such that the crypto strength > mismatch might not be a problem. > Of course if you use PFS in Phase 2 then you are better protected, but I wouldn't rely too much on that. --------------E7C148E44C8DCA6B8F248056 Content-Type: text/x-vcard; charset=us-ascii; name="zegman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tamir Zegman Content-Disposition: attachment; filename="zegman.vcf" begin:vcard n:Zegman;Tamir tel;fax:+972-3-5759256 tel;work:+972-3-7534606 x-mozilla-html:TRUE url:www.checkpoint.com org:Check Point Software Technologies Ltd.;Encryption group adr:;;3A Jabotinsky St., Diamond Tower;Ramat-Gan;;52520;ISRAEL version:2.1 email;internet:zegman@checkpoint.com title:Software engineer fn:Tamir Zegman end:vcard --------------E7C148E44C8DCA6B8F248056-- From owner-ipsec@lists.tislabs.com Wed May 19 13:34:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29767; Wed, 19 May 1999 13:33:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21918 Wed, 19 May 1999 14:30:30 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 19 May 1999 12:38:25 -0600 From: "Hilarie Orman" To: , Cc: Subject: Re: Weak Crypto in Phase 1 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 OAA21913 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There's an undercurrent in some of the discussions that seems to imply that the security of the keys depends on symmetric crypto. I'd just like to point out that it's not true. The security of the keys depends on the group over which the exponentiations for Diffie-Hellman are done. The identity hiding depends on the symmetric crypto, as do the SA attributes. It would seem strange to me that an implementor would limit phase I to a lesser key length than in phase II. Does the initiator fail to offer 3DES, or does the responder default to DES? Maybe they want to hide the fact that they have stronger crypto available until they get to Phase II? Note that no can be forced to keep their identity secret during these exchanges, it the option of the sender and involves trust with the recipient (as with any secrecy); and identities are subject to compromise by active attackers. Hilarie From owner-ipsec@lists.tislabs.com Wed May 19 16:10:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA01445; Wed, 19 May 1999 16:10:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22507 Wed, 19 May 1999 17:07:43 -0400 (EDT) Message-Id: <199905192115.OAA18206@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: new IKE draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18203.927148549.1@network-alchemy.com> Date: Wed, 19 May 1999 14:15:49 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A new I-D which incorporates all the comments and suggestions made on RFC2409 has been submitted to the Internet Drafts Administrator. An advance copy can be obtained from http://www.lounge.org/son-of-ike.html. The comments can be found at http://www.lounge.org/ike_doi_errata.html. The document has also been reorganized in an effort to make it more readable. Suggestions on further improvements are encouraged. Dan. From owner-ipsec@lists.tislabs.com Wed May 19 19:00:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02904; Wed, 19 May 1999 19:00:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22855 Wed, 19 May 1999 19:54:22 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: References: <3741E62B.61B3E97E@redcreek.com> Date: Wed, 19 May 1999 19:59:45 -0400 To: Glen Zorn From: Stephen Kent Subject: Re: New XAUTH draft Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Glen, If I use a certificate in IKE that attests to my user name, not the name or address of my computer, then I am doing user authentication. You may have a point that IKE, given its existing complexity, is an unfortunate place to add other forms of user auth, but please don't say that it does not provide user auth under the right (existing) circumstances. Also, because IPsec involves access control as a basic security service, if the SPD entries take the form of user names, then it is preferable that IKE be able to verify user identity, in order to support the access control features of IPsec. If another protocol is employed to veriy user identity, then one creates a more complex interdependence between IPsec and the other protocol, right? Steve From owner-ipsec@lists.tislabs.com Thu May 20 09:54:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12661; Thu, 20 May 1999 09:54:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26741 Thu, 20 May 1999 09:55:05 -0400 (EDT) From: Pyda Srisuresh Message-Id: <199905201401.HAA10525@kc.livingston.com> Subject: Re: New XAUTH draft To: kent@po1.bbn.com (Stephen Kent) Date: Thu, 20 May 1999 07:01:49 -0700 (PDT) Cc: ipsec@lists.tislabs.com In-Reply-To: from "Stephen Kent" at May 19, 99 07:59:45 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Glen, > > If I use a certificate in IKE that attests to my user name, not the name or > address of my computer, then I am doing user authentication. > Yes, I agree. > You may have a point that IKE, given its existing complexity, is an > unfortunate place to add other forms of user auth, but please don't say > that it does not provide user auth under the right (existing) > circumstances. > Sure, IKE is limited in the authentication mechanisms it supports. But, I dont believe, it is an unfortunate place to add other forms of user authentication. > Also, because IPsec involves access control as a basic security service, if > the SPD entries take the form of user names, then it is preferable that IKE > be able to verify user identity, in order to support the access control > features of IPsec. Yes, I agree. Note however, the access control mechanism in IKE is also primitive and cumbersome. By that, I mean you cannot have more than one policy rule per SA and that rule is not granular enough to cover all access controls you wish to include for an SA. For a remote access user, there is a link level authentication done in PPP (or other variations thereof, such as L2TP), subsequent to which access control is assigned to the user, for the duration of that user connectivity. For a secure remote access, the user needs to additionally authenticate himself/herself once again over the UDP to gain access controls for security. This IKE authentication is different from the PPP authencation and the security access controls assigned during Quick Mode also take a different tack than the PPP access controls. > If another protocol is employed to veriy user identity, > then one creates a more complex interdependence between IPsec and the other > protocol, right? > I dont believe, it is so much the case of another protocol to verify user identity - rather extend IKE to support other forms of authentication. > Steve > Have a nice day. cheers, suresh From owner-ipsec@lists.tislabs.com Thu May 20 09:54:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12674; Thu, 20 May 1999 09:54:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26884 Thu, 20 May 1999 10:39:50 -0400 (EDT) From: pat.calhoun@Eng.Sun.Com (Patrice Calhoun) Message-Id: <199905201448.HAA03251@hsmpka.eng.sun.com> Date: Thu, 20 May 1999 07:41:32 -0700 To: "Stephen Kent" , "Glen Zorn" Cc: Reply-To: Subject: Re: New XAUTH draft X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Glen, > >If I use a certificate in IKE that attests to my user name, not the name or >address of my computer, then I am doing user authentication. > Steve, I think Glen's point was simply that most implementations, that I know of, have the certificate on the host. The day where smart cads that contain the user's cert becomes ubiquitous, this will not be a problem. > >Also, because IPsec involves access control as a basic security service, if >the SPD entries take the form of user names, then it is preferable that IKE >be able to verify user identity, in order to support the access control >features of IPsec. If another protocol is employed to veriy user identity, >then one creates a more complex interdependence between IPsec and the other >protocol, right? Of course, if an additional protocol is used on the back-end of the security gateway to authenticate and authorize the user, there is an inter-dependency. However, a customer may wish to do this in order to be able to centralize user configuration, which would help scale a large deployment. PatC From owner-ipsec@lists.tislabs.com Thu May 20 10:41:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13218; Thu, 20 May 1999 10:41:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27094 Thu, 20 May 1999 11:24:36 -0400 (EDT) Date: Thu, 20 May 1999 11:33:15 -0400 From: canetti Message-Id: <9905201533.AA27322@ornavella.watson.ibm.com> To: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to add a voice in favor of separating the legacy user authentication mechanisms from IKE. There are several arguments supporting this separation: * First and foremost, IKE is hard to analyze and implement correctly as is. Adding modes and functionalities will only make it harder. KISS (keep is simple and secure)! * IKE/IPSEC is primarily meant for host-to-host protection. User authentication seems to be best done on top of IKE/IPSEC, not as a part of it. * Having relatively simple and separate modules is a nice feature of the IPSEC suite, as opposed to other, monolythic security protocols. Let's keep it this way. A seemingly "natural" alternative to XAUTH is to first do IKE, and then complete the user authentication via the IPSEC-protected connection (using either AH or ESP). Are there overwhelming arguments to not do it this way, and break the modularity of IPSEC? Ran From owner-ipsec@lists.tislabs.com Thu May 20 11:37:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14070; Thu, 20 May 1999 11:37:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27310 Thu, 20 May 1999 12:35:07 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA97156@exchange> From: Tim Jenkins To: "Scott G. Kelly" , Stephane Beaulieu Cc: Glen Zorn , "Waters, Stephen" , ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 12:45:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk much snipped below... --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: May 20, 1999 12:34 PM > To: Stephane Beaulieu > Cc: Glen Zorn; Waters, Stephen; ipsec@lists.tislabs.com > Subject: Re: New XAUTH draft Stephane said: > > This provides a nice, easy migration path to those who would like to > > eventually fully deploy IPSec with a PKI, but for now are > limited to using > > their existing infrastructures. XAUTH also ensures that > these legacy system > > transactions enjoy the full security that IPSec provides. Scott replied: > I don't quite agree with this. I do agree that integrating radius (and > perhaps other "legacy" mechanisms) smoothes the transition to > IPSec, but > I have the feeling that making it too easy will breed > complacency. Also, > I think the statement about enjoying the "full security that IPSec > provides" is questionable. These mechanisms add much in the way of > complexity to IKE, and they basically reduce the authentication > mechanism to a plain-language passphrase which probably isn't too hard > to guess - meaning they *reduce* the security IPSec provides. Are you perhaps mixing up XAUTH with the hybrid draft? The only way XAUTH reduces the existing authentication of IKE is if the sysadmin use pre-shared key authentication and share it everywhere or set it to null (if that's even possible). Hybrid, on the other hand, does allow one end to drop the existing forms of authentication. But even then, the problem it's trying to solve does have a place with customers. From owner-ipsec@lists.tislabs.com Thu May 20 11:38:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14111; Thu, 20 May 1999 11:38:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27325 Thu, 20 May 1999 12:36:17 -0400 (EDT) Message-ID: <37443BEC.19FC8F1C@redcreek.com> Date: Thu, 20 May 1999 09:44:28 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Glen Zorn , ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <3741E62B.61B3E97E@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, I sent a reply to Stephane's post in which I referred to this post, but after re-reading this, I think I misrepresented/misunderstood what was being said. Additional comments below: Stephen Kent wrote: > Also, because IPsec involves access control as a basic security service, if > the SPD entries take the form of user names, then it is preferable that IKE > be able to verify user identity, in order to support the access control > features of IPsec. If another protocol is employed to veriy user identity, > then one creates a more complex interdependence between IPsec and the other > protocol, right? I think you're making a case for not using "legacy" protocols at all, and for using some other (secondary?) authentication mechanism - is that right? Scott From owner-ipsec@lists.tislabs.com Thu May 20 11:39:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14120; Thu, 20 May 1999 11:39:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27262 Thu, 20 May 1999 12:25:42 -0400 (EDT) Message-ID: <37443970.353ED9FA@redcreek.com> Date: Thu, 20 May 1999 09:33:52 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: Glen Zorn , "Waters, Stephen" , ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA96CBC@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Stephane, Stephane Beaulieu wrote: > > We understand that we would all eventually like to do away with some of > these legacy systems, however, for the time being, our customers demand that > we support them. XAUTH allows for us to do this by using IKE to secure it. Yes, our customers are placing similar pressures on us, and we also use a mechanism similar to xauth to enable radius authentication for the time being. > This provides a nice, easy migration path to those who would like to > eventually fully deploy IPSec with a PKI, but for now are limited to using > their existing infrastructures. XAUTH also ensures that these legacy system > transactions enjoy the full security that IPSec provides. I don't quite agree with this. I do agree that integrating radius (and perhaps other "legacy" mechanisms) smoothes the transition to IPSec, but I have the feeling that making it too easy will breed complacency. Also, I think the statement about enjoying the "full security that IPSec provides" is questionable. These mechanisms add much in the way of complexity to IKE, and they basically reduce the authentication mechanism to a plain-language passphrase which probably isn't too hard to guess - meaning they *reduce* the security IPSec provides. I agree with Steve Kent's comments regarding IKE's need for some mechanism by which to verify user identity, but think we must make the distinction between which IKE implementation we're referring to, and what exactly we mean. To elaborate, in the scenarios in which xauth is currently being employed, i.e. remote access, it is only the remote client's IKE which has a real need to interact with the user with respect to identity verification. To explain, let me present an example. Imagine a policy which permits any client to access a radius server behind the sgw, but limits all other access. When a client wishes to access the protected net, it forms a radius-only SA, and through this authenticates with the radius server. The radius server then interacts with a local CA (perhaps co-located) to generate a short-lived identity cert, and this is returned to the client as an extended radius attribute, or something. The client then uses this cert, for which the sgw has corresponding policy, to access the network. What are the problems with this approach? Well, for one, the radius server needs to know how to interact with a CA, but that's a straightforward problem. For another, the radius server may now be attackable through the SA. I've heard people argue that there is yet another drawback, that being the added overhead associated with the radius-only SA, but I think that security is not free, and you get what you pay for. Back to my original point, though, note an interesting characteristic of this approach: the sgw need know nothing about radius, or any other secondary authentication protocol - this effectively moves the complexity outward, away from the security device, which I think is probably a good thing. I'd be interested to hear other's thoughts on this, and I have a feeling I will :-) Scott From owner-ipsec@lists.tislabs.com Thu May 20 11:43:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14235; Thu, 20 May 1999 11:43:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27345 Thu, 20 May 1999 12:39:54 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA9715B@exchange> From: Stephane Beaulieu To: canetti , ipsec@lists.tislabs.com Cc: ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 12:50:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I'd like to add a voice in favor of separating the legacy user > authentication mechanisms from IKE. There are several arguments > supporting this separation: > > * First and foremost, IKE is hard to analyze and implement correctly > as is. Adding modes and functionalities will only make it harder. > KISS (keep is simple and secure)! > IKE is hard to implement, and it took a long time to get it right. However, the problem is that we need to provide a secure, easy to use way of providing legacy system authentication. So, what's the *best* way to do this? > * IKE/IPSEC is primarily meant for host-to-host protection. User > authentication seems to be best done on top of IKE/IPSEC, > not as a part of it. > I believe that user authentication IS part of IKE. Don't let the user into your network until he's been authenticated. > * Having relatively simple and separate modules is a nice > feature of the > IPSEC suite, as opposed to other, monolythic security > protocols. Let's keep > it this way. > > > A seemingly "natural" alternative to XAUTH is to first do > IKE, and then > complete the user authentication via the IPSEC-protected connection > (using either AH or ESP). Are there overwhelming arguments to > not do it > this way, and break the modularity of IPSEC? > I have heard many say that this is a bad alternative for several reasons. One of those reasons is that you end up setting up multiple IPSec SAs which should only live for a few minutes. Let's suppose that you need to talk to 3 different devices in order to authenticate / manage a remote user. For example, a user might need to talk to a DHCP server, a RADIUS accounting server, and an SDI server. Then, the SG might need to set up 3 IPSec SAs before he's given full access to the network. This not only takes away from the entropy of the phase 1, but creates SA management nightmares as well as slow down an edge device. If your device is supporting ten thousand remote users, setting up all these SAs is very expensive. Also, many people are adverse to letting anyone onto their network at all until they are fully authenticated. Setting up special conditions for management / authentication servers would require special care, and would require that all of these servers are invulnerable to attacks. P.S Hopefully we can resolve all of these issues at the IPSRA BOF in Oslo :) regards, Stephane. From owner-ipsec@lists.tislabs.com Thu May 20 11:44:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14260; Thu, 20 May 1999 11:44:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27389 Thu, 20 May 1999 12:47:01 -0400 (EDT) Message-ID: <37443E70.82840380@redcreek.com> Date: Thu, 20 May 1999 09:55:12 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: Stephane Beaulieu , Glen Zorn , "Waters, Stephen" , ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA97156@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tim, Tim Jenkins wrote: > Are you perhaps mixing up XAUTH with the hybrid draft? > > The only way XAUTH reduces the existing authentication of IKE is if > the sysadmin use pre-shared key authentication and share it everywhere > or set it to null (if that's even possible). > > Hybrid, on the other hand, does allow one end to drop the existing forms > of authentication. But even then, the problem it's trying to solve does > have a place with customers. Actually, I wasn't referring only to the strength of the authentication, although I think it's a valid thing to discuss. Presumably, secondary authentication is considered valuable because the primary mechanism is somehow at risk, e.g. the client's cert is in software, someone might walk off with the smart card, etc. In these cases, assume the worst has happened, and now I'm trying to access your network. If all I have to do is guess a passphrase, attacking your network seems something more doable, when compared to, say, breaking a private/public keypair. On the other hand, I know there are bolstering mechanisms (e.g. repeated challenge + rsp, secureid-type token generators, etc) which may mitigate this risk. Perhaps more importantly, I was also referring to the stability, analyzability, and other security-related properties of IKE. I think adding proxy servers for even 1 (let alone 16) secondary authentication protocols substantially impacts upon the security characteristics of the implementation. Scott From owner-ipsec@lists.tislabs.com Thu May 20 11:55:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14422; Thu, 20 May 1999 11:55:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27417 Thu, 20 May 1999 12:55:26 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA9716B@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 13:06:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, comments below... > > We understand that we would all eventually like to do away > with some of > > these legacy systems, however, for the time being, our > customers demand that > > we support them. XAUTH allows for us to do this by using > IKE to secure it. > > Yes, our customers are placing similar pressures on us, and > we also use > a mechanism similar to xauth to enable radius authentication for the > time being. > > > This provides a nice, easy migration path to those who would like to > > eventually fully deploy IPSec with a PKI, but for now are > limited to using > > their existing infrastructures. XAUTH also ensures that > these legacy system > > transactions enjoy the full security that IPSec provides. > > I don't quite agree with this. I do agree that integrating radius (and > perhaps other "legacy" mechanisms) smoothes the transition to > IPSec, but > I have the feeling that making it too easy will breed > complacency. Also, > I think the statement about enjoying the "full security that IPSec > provides" is questionable. These mechanisms add much in the way of > complexity to IKE, and they basically reduce the authentication > mechanism to a plain-language passphrase which probably isn't too hard > to guess - meaning they *reduce* the security IPSec provides. I hope Tim's comment cleared this up. > > I agree with Steve Kent's comments regarding IKE's need for some > mechanism by which to verify user identity, but think we must make the > distinction between which IKE implementation we're referring to, and > what exactly we mean. To elaborate, in the scenarios in which xauth is > currently being employed, i.e. remote access, it is only the remote > client's IKE which has a real need to interact with the user with > respect to identity verification. To explain, let me present > an example. > > Imagine a policy which permits any client to access a radius server > behind the sgw, but limits all other access. When a client wishes to > access the protected net, it forms a radius-only SA, and through this > authenticates with the radius server. The radius server then interacts > with a local CA (perhaps co-located) to generate a > short-lived identity > cert, and this is returned to the client as an extended radius > attribute, or something. The client then uses this cert, for which the > sgw has corresponding policy, to access the network. > > What are the problems with this approach? Well, for one, the radius > server needs to know how to interact with a CA, but that's a > straightforward problem. For another, the radius server may now be > attackable through the SA. I've heard people argue that there is yet > another drawback, that being the added overhead associated with the > radius-only SA, but I think that security is not free, and > you get what > you pay for. > > Back to my original point, though, note an interesting > characteristic of > this approach: the sgw need know nothing about radius, or any other > secondary authentication protocol - this effectively moves the > complexity outward, away from the security device, which I think is > probably a good thing. I'd be interested to hear other's thoughts on > this, and I have a feeling I will :-) > > Scott > I'm all for having to implement less functionality in our SG. I could sure use the rest :) However our first consideration has to be what's the most secure, most usable solution for our customers. I've expressed my concerns about setting up "special SAs" for authentication / managment servers in my response to Ran's email. I'd like to know what others think. Regards, Stephane. From owner-ipsec@lists.tislabs.com Thu May 20 12:07:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14725; Thu, 20 May 1999 12:07:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27485 Thu, 20 May 1999 13:12:21 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA97178@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Tim Jenkins Cc: Stephane Beaulieu , ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 13:22:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, comments below... > > Hi Tim, > > Tim Jenkins wrote: > > > > > Are you perhaps mixing up XAUTH with the hybrid draft? > > > > The only way XAUTH reduces the existing authentication of IKE is if > > the sysadmin use pre-shared key authentication and share it > everywhere > > or set it to null (if that's even possible). > > > > Hybrid, on the other hand, does allow one end to drop the > existing forms > > of authentication. But even then, the problem it's trying > to solve does > > have a place with customers. > > Actually, I wasn't referring only to the strength of the > authentication, > although I think it's a valid thing to discuss. Presumably, secondary > authentication is considered valuable because the primary mechanism is > somehow at risk, e.g. the client's cert is in software, someone might > walk off with the smart card, etc. In these cases, assume the > worst has > happened, and now I'm trying to access your network. If all I > have to do > is guess a passphrase, attacking your network seems something more > doable, when compared to, say, breaking a private/public > keypair. On the > other hand, I know there are bolstering mechanisms (e.g. repeated > challenge + rsp, secureid-type token generators, etc) which > may mitigate > this risk. The purpose of using secondary authentication is mostly for a migration path. ISPs for example have databases with hundreds of thousands of users. If they want to introduce IPSec, they are not going to simply tell everyone to switch to digital certificates overnight. It might take years to do so. We hope that those network admins don't get complacent and take IKE authentication too loosely when they do deploy just because they are still using their legacy systems. That being said XAUTH does provide a form of secondary authentication. Granted that it's no where near as secure as IPSec, it does *add* some security. Hopefully your RADIUS (or whatever other) server would be set up to deny a user who has submitted X number of consecutive bad passwords. > > Perhaps more importantly, I was also referring to the stability, > analyzability, and other security-related properties of IKE. I think > adding proxy servers for even 1 (let alone 16) secondary > authentication > protocols substantially impacts upon the security > characteristics of the > implementation. As does setting up X SAs for each remote user. Regards, Stephane. From owner-ipsec@lists.tislabs.com Thu May 20 12:07:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14723; Thu, 20 May 1999 12:07:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27465 Thu, 20 May 1999 13:07:18 -0400 (EDT) Message-ID: <37444331.746657BD@redcreek.com> Date: Thu, 20 May 1999 10:15:29 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: canetti , ipsec@lists.tislabs.com, ipsra Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA9715B@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane Beaulieu wrote: > > A seemingly "natural" alternative to XAUTH is to first do > > IKE, and then > > complete the user authentication via the IPSEC-protected connection > > (using either AH or ESP). Are there overwhelming arguments to > > not do it > > this way, and break the modularity of IPSEC? > > > > I have heard many say that this is a bad alternative for several reasons. > One of those reasons is that you end up setting up multiple IPSec SAs which > should only live for a few minutes. Let's suppose that you need to talk to > 3 different devices in order to authenticate / manage a remote user. For > example, a user might need to talk to a DHCP server, a RADIUS accounting > server, and an SDI server. Then, the SG might need to set up 3 IPSec SAs > before he's given full access to the network. This not only takes away from > the entropy of the phase 1, but creates SA management nightmares as well as > slow down an edge device. If your device is supporting ten thousand remote > users, setting up all these SAs is very expensive. Since I just suggested something similar in a related post, I'll try to address a few of these points. I agree that there is added overhead to this approach, along with added security. However, I'm not sure that any argument is strong enough to compel us to standardize "budget" security. I would also add that the alternative is to implement proxies for these servers within IKE, which with high probability reduces the security of the IKE implementation. Regarding the comment regarding the phase 1 entropy, I'm missing the point, I guess. If you re-use the same key material for more than one SA under *any* circumstances, you are using up some of the entropy, and I guess all I'm really hearing is the same overhead argument again. Am I missing something? Regarding the cost of setting up the SAs, I agree that it's expensive, but would present the "budget" security point again, and add that this if this is the cost of doing business, then it simply means we have to design our products to deliver. > > Also, many people are adverse to letting anyone onto their network at all > until they are fully authenticated. Setting up special conditions for > management / authentication servers would require special care, and would > require that all of these servers are invulnerable to attacks. > I think this is a good point, and this is the problem to solve with respect to my (and Ran Canetti's) previous suggestion. Scott From owner-ipsec@lists.tislabs.com Thu May 20 12:14:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14899; Thu, 20 May 1999 12:14:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27432 Thu, 20 May 1999 13:00:12 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 20 May 1999 11:07:44 -0600 From: "Hilarie Orman" To: , Subject: RE: New XAUTH draft 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 NAA27429 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I disagree that * IKE/IPSEC is primarily meant for host-to-host protection. Support for a broad set of identities was a goal from the beginning. Hilarie From owner-ipsec@lists.tislabs.com Thu May 20 12:22:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA15119; Thu, 20 May 1999 12:22:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27528 Thu, 20 May 1999 13:20:14 -0400 (EDT) Message-ID: <37444639.90CCA7B2@redcreek.com> Date: Thu, 20 May 1999 10:28:25 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: Tim Jenkins , ipsec@lists.tislabs.com, ipsra Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA97178@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephane Beaulieu wrote: > > Perhaps more importantly, I was also referring to the stability, > > analyzability, and other security-related properties of IKE. I think > > adding proxy servers for even 1 (let alone 16) secondary > > authentication > > protocols substantially impacts upon the security > > characteristics of the > > implementation. > > As does setting up X SAs for each remote user. > I'm missing the point again, I think. What is it about setting up multiple SAs (2 in this case) which is insecure, and how is this different than rekeying? Scott From owner-ipsec@lists.tislabs.com Thu May 20 12:42:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA15522; Thu, 20 May 1999 12:42:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27586 Thu, 20 May 1999 13:47:10 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA971B4@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 13:57:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Perhaps more importantly, I was also referring to the stability, > > analyzability, and other security-related properties of IKE. I think > > adding proxy servers for even 1 (let alone 16) secondary > > authentication > > protocols substantially impacts upon the security > > characteristics of the > > implementation. I assume that by this you mean that if a Phase 1 SA is used to secure XAUTH messages, then the Phase 1 SA becomes more susceptible to attack as more XAUTH data is encrypted. If not, please elaborate. > I'm missing the point again, I think. What is it about setting up > multiple SAs (2 in this case) which is insecure, and how is this > different than rekeying? If I did interprate your above comment correctly... My point was that whether you secure an XAUTH transaction with a Phase 1 SA or whether you use a Phase 1 SA to spawn a Phase 2 SA to secure an XAUTH transaction your reducing the lifetime of a Phase 1 SA. Thanks, Stephane. From owner-ipsec@lists.tislabs.com Thu May 20 12:49:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA15655; Thu, 20 May 1999 12:49:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27623 Thu, 20 May 1999 13:58:27 -0400 (EDT) Message-ID: <37444F2D.1496E565@redcreek.com> Date: Thu, 20 May 1999 11:06:37 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: ipsec@lists.tislabs.com, ipsra Subject: Re: New XAUTH draft References: <319A1C5F94C8D11192DE00805FBBADDFA971B4@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Stephane, Stephane Beaulieu wrote: > > > > > Perhaps more importantly, I was also referring to the stability, > > > analyzability, and other security-related properties of IKE. I think > > > adding proxy servers for even 1 (let alone 16) secondary > > > authentication > > > protocols substantially impacts upon the security > > > characteristics of the > > > implementation. > > > I assume that by this you mean that if a Phase 1 SA is used to secure XAUTH > messages, then the Phase 1 SA becomes more susceptible to attack as more > XAUTH data is encrypted. If not, please elaborate. > No, actually I'm referring to stability, analyzability, and other security characteristics. Adding more complexity and states to IKE makes it harder to analyze, and more susceptible to a variety of attacks. There are a number of people better qualified to discuss this than I am who might want to jump in here... > > > I'm missing the point again, I think. What is it about setting up > > multiple SAs (2 in this case) which is insecure, and how is this > > different than rekeying? > > > If I did interprate your above comment correctly... My point was that > whether you secure an XAUTH transaction with a Phase 1 SA or whether you use > a Phase 1 SA to spawn a Phase 2 SA to secure an XAUTH transaction your > reducing the lifetime of a Phase 1 SA. Okay, I agree that you're consuming phase 1 entropy, but it's only insecure if you don't have enough entropy to begin with, which can be remedied in a number of ways, including starting with more, or rekeying, right? Scott From owner-ipsec@lists.tislabs.com Thu May 20 13:15:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16158; Thu, 20 May 1999 13:15:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27659 Thu, 20 May 1999 14:06:20 -0400 (EDT) Message-Id: <199905201814.LAA20311@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: new IKE draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20308.927224069.1@network-alchemy.com> Date: Thu, 20 May 1999 11:14:29 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, it's the new, new IKE draft now. There were some errors in the last one-- namely I fat-fingered every MODP group and improperly included the generic headers in some digest calculations. Thanks to Shawn Mamros for the eagle eye! It's at http://www.lounge.org/son-of-ike.html. Dan. From owner-ipsec@lists.tislabs.com Thu May 20 13:18:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16200; Thu, 20 May 1999 13:18:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27704 Thu, 20 May 1999 14:11:37 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA971E3@exchange> From: Stephane Beaulieu To: "Scott G. Kelly" , Stephane Beaulieu Cc: ipsec@lists.tislabs.com, ipsra Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 14:22:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, > No, actually I'm referring to stability, analyzability, and other > security characteristics. Adding more complexity and states > to IKE makes > it harder to analyze, and more susceptible to a variety of attacks. > There are a number of people better qualified to discuss this > than I am > who might want to jump in here... > I see, sorry for the confusion. Please disregard my comments about reducing the entropy. I don't see how XAUTH complicates IKE to a level where IKE might become unstable. IKE simply goes from Phase1 - Phase2, to Phase1 - XAUTH - Phase2. The only other solution to the problem I've heard is Phase1 - Phase2(but only special phase2's destined to Authentication servers) - Phase2. This seems even more complicated to me. Not to mention it seems easier to make a configuration / implementation mistake here. Once again, sorry for the confusion. Stephane. From owner-ipsec@lists.tislabs.com Thu May 20 13:59:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16675; Thu, 20 May 1999 13:59:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27832 Thu, 20 May 1999 14:57:42 -0400 (EDT) Message-Id: <199905201904.MAA20447@potassium.network-alchemy.com> To: Tim Jenkins cc: "Scott G. Kelly" , Stephane Beaulieu , Glen Zorn , "Waters, Stephen" , ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 20 May 1999 12:45:41 EDT." <319A1C5F94C8D11192DE00805FBBADDFA97156@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20444.927227079.1@network-alchemy.com> Date: Thu, 20 May 1999 12:04:39 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 May 1999 12:45:41 EDT you wrote > > The only way XAUTH reduces the existing authentication of IKE is if > the sysadmin use pre-shared key authentication and share it everywhere > or set it to null (if that's even possible). But this is precisely the way it's used. If you had a pre-shared key bound to a specific user (as opposed to a group) or if you had a certificate binding a specific user to a public key then there would be no need for XAUTH. Any subsequent radius/tacacs/whatever method of authentication would be pointless. Dan. From owner-ipsec@lists.tislabs.com Thu May 20 14:34:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17076; Thu, 20 May 1999 14:34:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27925 Thu, 20 May 1999 15:37:21 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA97284@exchange> From: Tim Jenkins To: Dan Harkins Cc: "Scott G. Kelly" , Stephane Beaulieu , ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 15:47:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Or, you could put a certificate on a kiosk PC and make the (multiple) users use extended authentication for the system to figure out who they are. In the long run, yes, those users will have their certs on a token. But for now, XAUTH solves real problems that customers are having today, so XAUTH is not pointless. Finally, just because XAUTH with pre-shared keys is possible, it doesn't mean you have to implement it. Have your system do only certificates with XAUTH if you like. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: May 20, 1999 3:05 PM > To: Tim Jenkins > Cc: Scott G. Kelly; Stephane Beaulieu; Glen Zorn; Waters, Stephen; > ipsec@lists.tislabs.com > Subject: Re: New XAUTH draft > > > On Thu, 20 May 1999 12:45:41 EDT you wrote > > > > The only way XAUTH reduces the existing authentication of IKE is if > > the sysadmin use pre-shared key authentication and share it > everywhere > > or set it to null (if that's even possible). > > But this is precisely the way it's used. If you had a > pre-shared key bound > to a specific user (as opposed to a group) or if you had a certificate > binding a specific user to a public key then there would be > no need for > XAUTH. Any subsequent radius/tacacs/whatever method of authentication > would be pointless. > > Dan. > From owner-ipsec@lists.tislabs.com Thu May 20 15:44:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17665; Thu, 20 May 1999 15:44:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28027 Thu, 20 May 1999 16:48:15 -0400 (EDT) Message-Id: <199905202056.NAA20712@potassium.network-alchemy.com> To: Tim Jenkins cc: "Scott G. Kelly" , Stephane Beaulieu , ipsec@lists.tislabs.com Subject: Re: New XAUTH draft In-reply-to: Your message of "Thu, 20 May 1999 15:47:52 EDT." <319A1C5F94C8D11192DE00805FBBADDFA97284@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20709.927233779.1@network-alchemy.com> Date: Thu, 20 May 1999 13:56:19 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are two possibilities here. You do XAUTH with an IKE SA that's been authenticated in a standard, secure way, or you do it using an IKE SA that's been authenticated with a shared group key. If the former then you're building and maintaining two infrastructures, one for a PKI and another for some other authentication technique (like radius). That's pointless. Certificates can give you user authentication so there is no reason to maintain the infrastructure required for radius. The XAUTH step would provide no more authentication and would just be an additional burden on the user (yet another dialog box asking for information). More likely it's the latter. IT managers have an investment in their existing authentication scheme and don't want to throw it away. Likewise they don't want to double their burden. So the solution they buy uses group key authentication for IKE and their existing authentication scheme in XAUTH. The only problem is that the authenticity of the keys used in IPSec are derived from IKE's SKEYID state and that is not authenticated when you use a group key that everybody shares. This is alluded to in the Security Considerations section of the draft. In effect, it's saying for XAUTH to be secure (i.e. not use a group shared key) it must be extraneous. Dan. On Thu, 20 May 1999 15:47:52 EDT you wrote > Or, you could put a certificate on a kiosk PC and make the (multiple) users > use extended authentication for the system to figure out who they are. > > In the long run, yes, those users will have their certs on a token. > > But for now, XAUTH solves real problems that customers are having today, so > XAUTH is not pointless. > > Finally, just because XAUTH with pre-shared keys is possible, it doesn't > mean you have to implement it. Have your system do only certificates with > XAUTH if you like. > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Thu May 20 16:29:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18251; Thu, 20 May 1999 16:29:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28271 Thu, 20 May 1999 17:47:11 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199905201448.HAA03251@hsmpka.eng.sun.com> Date: Thu, 20 May 1999 17:52:10 -0400 To: From: Stephen Kent Subject: Re: New XAUTH draft Cc: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pat, Irrespective of whether the private key associated with the cert is stored on a laptop and protected by a password, or whether it is kept in a smart card, if the cert asserts a user identity, then it is a user authentication mechanism. If one employs a separate protocol for user auth, outside of IPsec, then the SPD cannot be used to provide the same granularity of access control as if the user auth is done as part of IPsec. Your observation is correct, based on existing deployed Radius systems, but if one always insists on sticking with existing deployed databases, migration to newer technologies is impeded. Steve From owner-ipsec@lists.tislabs.com Thu May 20 16:29:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18260; Thu, 20 May 1999 16:29:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28220 Thu, 20 May 1999 17:37:48 -0400 (EDT) Message-ID: <009901bea309$ce96e020$82346887@research.belllabs.com> From: "Jatinder Bali" To: References: <199905201904.MAA20447@potassium.network-alchemy.com> Subject: Re: New XAUTH draft Date: Thu, 20 May 1999 17:43:32 -0400 Organization: Lucent Technologies 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is something we missed here when a response came for the first post of this thread. I would like to bring that up again. If the SG has to send the first packet for XAUTH then it can be configured for only one auth type it knows about. This is severely restrictive as the SG cannot support SecurId and local radius server database. I want to propose that we discuss this in the light that some SG's may need to support more than one auth method. To do this SG's dont need to know which auth method is configured, but they simple pass the request from the client to someone else to process it. Hence the term proxy :-) I dont think that by doing 'A' form of XAUTH severely restricts or is a burden on IKE. We have to do it somewhere and doing it before or after (Phase1+Phase2) is definitely more complicated. We could never get it resolved let alone implement it. My proposal would be to do XAUTH after IKE Phase 1 and before IKE Phase 2 using some predefined payloads. We can define this and implement it in a time that we can market an interopertable solution. I don think we can say that these are legacy systems as 99% of user authentication on the internet is done using some method other that certificates. So is life and I think it is not going to change tommorrow. Thanks. From owner-ipsec@lists.tislabs.com Thu May 20 17:23:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18928; Thu, 20 May 1999 17:23:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28331 Thu, 20 May 1999 18:24:55 -0400 (EDT) Message-ID: <37448C40.BFEDCA23@ire-ma.com> Date: Thu, 20 May 1999 18:27:12 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft References: <199905202056.NAA20712@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One interesting benefit of XAUTH (or rather so-called legacy authentication schemes) is that you can revoke user from the RADIUS database very quickland reliably - for sure much faster and simpler than dealing with CRLs in it's current state of PKI. Slava Kavsan IRE From owner-ipsec@lists.tislabs.com Thu May 20 17:25:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18956; Thu, 20 May 1999 17:25:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28390 Thu, 20 May 1999 18:45:03 -0400 (EDT) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Thu, 20 May 1999 15:39:21 -0700 (PDT) From: Glen Zorn To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: New XAUTH draft 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 Wed, 19 May 1999, Stephen Kent wrote: > Glen, > > If I use a certificate in IKE that attests to my user name, not the name or > address of my computer, then I am doing user authentication. Sorry, apparently I did not make myself clear. I was using the term "user authentication" in the common sense -- that is to say, the sense that is understood in the 95+% of installations where PKI is not existent, let alone ubiquitous. In the day ("just around the corner" for the last 10 years or so) when PKI _is_ ubiquitous, you are absolutely correct. I am obviously somewhat skeptical that that day will come very soon, but I have been wrong before, so suppose I am wrong this time. In that case, the inclusion of XAUTH in IKE does nothing but add useless baggage to an already complex protocol. Conversely, suppose that I am right, and PKI is not ubiquitous for some lengthy period. In this case, the inclusion of XAUTH in IKE will likely slow PKI deployment and reduce the overall security of the system (through the use of comparatively weak user authentication methods). Either way, this is a bad idea. > > You may have a point that IKE, given its existing complexity, is an > unfortunate place to add other forms of user auth, but please don't say > that it does not provide user auth under the right (existing) > circumstances. > The fact that these circumstances do _not_ exist in any widespread sense is the only possible rationale for the development of XAUTH, no? > Also, because IPsec involves access control as a basic security service, if > the SPD entries take the form of user names, then it is preferable that IKE > be able to verify user identity, in order to support the access control > features of IPsec. Access control means many things to many people. In the scenario under discussion (remote access to some "home" network) it's hard to imagine administrators managing user-level access control via IPsec filters, especially if the home network is at all dynamic. > If another protocol is employed to veriy user identity, > then one creates a more complex interdependence between IPsec and the other > protocol, right? Not sure I understand. Is the "other protocol" RADIUS? If so, there is a much bigger problem then interdependence complexity, due to the severe and well-known security problems with the RADIUS protocol (especially in a proxied environment. > > Steve > From owner-ipsec@lists.tislabs.com Thu May 20 22:00:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA27971; Thu, 20 May 1999 22:00:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28883 Thu, 20 May 1999 23:06:11 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B1B8F77C@sothmxs06.entrust.com> From: Greg Carter To: "'ipsec@lists.tislabs.com'" Subject: RE: New XAUTH draft Date: Thu, 20 May 1999 23:14:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How is that? If you configure your box to check CRLs at each auth AND your CA is intelligent enough to push new CRLs each time a cert is revoked I don't see how the "revocation" would be slower than a RADIUS auth, and I know it is more secure Bye. > ---------- > From: Bronislav Kavsan[SMTP:bkavsan@ire-ma.com] > Sent: Thursday, May 20, 1999 6:27 PM > To: ipsec@lists.tislabs.com > Subject: Re: New XAUTH draft > > One interesting benefit of XAUTH (or rather so-called legacy > authentication > schemes) is that you can revoke user from the RADIUS database very > quickland > reliably - for sure much faster and simpler than dealing with CRLs in it's > current state of PKI. > > Slava Kavsan > IRE > > From owner-ipsec@lists.tislabs.com Fri May 21 02:43:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA13288; Fri, 21 May 1999 02:43:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29277 Fri, 21 May 1999 03:15:14 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBC46@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Fri, 21 May 1999 08:23:52 +0100 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 Since I was partly responsible for launching this monster, I'd like try to bat it back to the original point, with some 'summation' of the discussion. PKI is the right answer no doubt(apart from some CRL nightmares). We should recommend PKI where possible. The XAUTH 'concept' seems fine for folk migrating from traditional remote-access, PPTP and raw L2TP implementations towards IPSEC protected flows. Many of these installed remote-access servers will be using RADIUS to centralise the authentication database. If we use a 'low granularity' pre-shared secret for phase-1, then is should probably be a MUST that the XAUTH method is challenge or token based. Recent work in PPP/RADIUS land has come up with a great tool for Security Gateways (SG) that need to support a raft of 'legacy' authentication modes, which allows the SG to know nothing about which authentication method is needed, or how it operates: EAP. If we used something like EAP (or EAP itself preferably), the SG simply asks the remote peer for an "ID", and then passes all the 'EAP Messages' from the peer, via the RADIUS attribute 'EAP-Message' to the back-office RADIUS server which then gets busy to talk to SecurID, OTP, etc. specialised servers. Taking this approach may mean the XAUTH become trivial for the SG to implement, it just sends an initial 'Who are you' EAP message, and then passes stuff straight from client to RADIUS server until the RADIUS server says 'Access Accept'. I am tempted to start suggesting we could solve some CRL issues using the RADIUS model as well... another day :) Steve. From owner-ipsec@lists.tislabs.com Fri May 21 06:44:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA17553; Fri, 21 May 1999 06:44:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29845 Fri, 21 May 1999 07:11:49 -0400 (EDT) Message-Id: <199905211119.HAA24731@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-00.txt Date: Fri, 21 May 1999 07:19:51 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet Key Exchange (IKE) Author(s) : D. Carrel, D. Harkins Filename : draft-ietf-ipsec-ike-00.txt Pages : 46 Date : 20-May-99 This memo describes a key exchange and security negotiation protocol which is intended to depricate [HC98]. As such it will not change the 'bits on the wire' for an implementation which is compiant with [HC98] but will clarify contentious issues with [HC98] and attempt to explain the protocol in a less haphazard manner. Due to advances in computer processing some mandatory-to-implement attributes have changed between this [HC98] and this document. In addition a new and optional exchange is introduced. Like [HC98] this memo uses [MSST98] for a framework and as a language to express exchanges which are derived from [Kra96] and [Orm98]. In places where the requirements between this document and [MSST98] or [Kra96] or [Orm98] conflict, this document will be supreme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990520103846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990520103846.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri May 21 06:44:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA17564; Fri, 21 May 1999 06:44:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29884 Fri, 21 May 1999 07:32:32 -0400 (EDT) Message-ID: <374544ED.987D2D82@ire-ma.com> Date: Fri, 21 May 1999 07:35:10 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Greg Carter CC: "'ipsec@lists.tislabs.com'" Subject: Re: New XAUTH draft References: <01E1D01C12D7D211AFC70090273D20B1B8F77C@sothmxs06.entrust.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greg, Example: Mobile Corp. decides to layof f 10,000 workers who have certificates with expiration date 1 year from now. In this scenario - Mobile CA will push 10,000-entries CRL files to all IPSec devices for a year - I hope these devices have enough memory and bandwith to receve these files !! RADIUS on the other hand - simply removes these entries from the database - and they all revoked. Greg Carter wrote: > How is that? > > If you configure your box to check CRLs at each auth AND your CA is > intelligent enough to push new CRLs each time a cert is revoked I don't see > how the "revocation" would be slower than a RADIUS auth, and I know it is > more secure > > Bye. > > > ---------- > > From: Bronislav Kavsan[SMTP:bkavsan@ire-ma.com] > > Sent: Thursday, May 20, 1999 6:27 PM > > To: ipsec@lists.tislabs.com > > Subject: Re: New XAUTH draft > > > > One interesting benefit of XAUTH (or rather so-called legacy > > authentication > > schemes) is that you can revoke user from the RADIUS database very > > quickland > > reliably - for sure much faster and simpler than dealing with CRLs in it's > > current state of PKI. > > > > Slava Kavsan > > IRE > > > > From owner-ipsec@lists.tislabs.com Fri May 21 08:37:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18271; Fri, 21 May 1999 08:37:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00153 Fri, 21 May 1999 09:06:43 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBC51@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: RE: New XAUTH draft Date: Fri, 21 May 1999 14:15:05 +0100 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 ...and another thing... Since you guys in the US get the last say, I take my opportunity to have the first :) Phase-1 authentication (as we know) should give us mutual authentication. If legacy authentication is used with IKE-XAUTH, we expect that Pre-Shared is used for Phase-1, and that the pre-shared secret is 'common knowledge' or null. Well, the problem here is that a 'common knowledge' pre-shared secret is not much of a secret at all, and what you are left with is one-way authentication care of IKE-XAUTH. Since RADIUS is probably involved in this picture, and there are 'tunnel' RADIUS attributes to play with now, why not just use RADIUS to retrieve a per-user pre-shared secret? This gives the following options: 1) use just per-user pre-shared and no IKE-XAUTH 2) use per-user pre-shared and per-user token/OTP etc.. 3) as for 1) and 2), but with group pre-shared secret (better than global or NULL) The recommendation to customers would then be: 1) take the pain and do PKI 2) use RADIUS servers that support tunnel attributes and use per-user pre-shared 3) use 2) plus whatever Legacy stuff you're hooked on. Cheers, Steve. From owner-ipsec@lists.tislabs.com Fri May 21 09:06:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA18573; Fri, 21 May 1999 09:06:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00356 Fri, 21 May 1999 09:53:54 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA973BD@exchange> From: Paul Kierstead To: Bronislav Kavsan , Greg Carter