From owner-ipsec@lists.tislabs.com Thu Jun 7 06:00:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA02926; Thu, 7 Jun 2001 06:00:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21859 Thu, 7 Jun 2001 07:49:55 -0400 (EDT) Message-ID: From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: IPSEC Security Gateways & NAT Date: Thu, 7 Jun 2001 12:56:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We've come up against a number of situations where the network service provider has used NAT and the customer wants to add IP security by adding Security Gateways between their networks and the service provider's access points. RFC2401 says that a Security Gateway must use tunnel mode unless it is acting as a host (eg management). The negates the service provider's use of NAT by preventing it from translating client addresses - which in some cases overlap across across multiple private networks. Some vendors offer non-standard encryption modes - eg transport or proprietary - that do pass the IP (and even TCP/UDP) headers through in clear too. This exposes the client IP address for NAT but means that the encryption end-points probably won't agree on the selectors for the security association - as they will see different addresses for the same client. Even assuming that the management issues associated with agreeing SAs (possibly with dynamic NAT) can be fixed, there appears to be a deeper issue: Some protocols, most notably FTP, pass IP socket addresses at the application level. These need to be translated by Application Level Gateways (ALGs). However, once IP traffic has been enrypted, this information cannot be available to the ALG. This appears to imply that NAT, in general, must be performed before encryption. This is at odds with the models that a number of service providers are trying to apply. Are there any solutions to these problems? Or any papers detailing the sort of problems that occur when mixing NAT with IPSEC. Thanks, Chris ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Thu Jun 7 06:43:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA07254; Thu, 7 Jun 2001 06:43:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22072 Thu, 7 Jun 2001 08:50:34 -0400 (EDT) Message-Id: <3.0.5.32.20010607143550.047a3380@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 07 Jun 2001 14:35:50 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: IPSEC Security Gateways & NAT Cc: Chris Trobridge In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA21940 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:56 07.06.01 +0100, you wrote: >We've come up against a number of situations where the network service >provider has used NAT and the customer wants to add IP security by adding >Security Gateways between their networks and the service provider's access >points. > >RFC2401 says that a Security Gateway must use tunnel mode unless it is >acting as a host (eg management). The negates the service provider's use of >NAT by preventing it from translating client addresses - which in some cases >overlap across across multiple private networks. > >Some vendors offer non-standard encryption modes - eg transport or >proprietary - that do pass the IP (and even TCP/UDP) headers through in >clear too. This exposes the client IP address for NAT but means that the >encryption end-points probably won't agree on the selectors for the security >association - as they will see different addresses for the same client. > >Even assuming that the management issues associated with agreeing SAs >(possibly with dynamic NAT) can be fixed, there appears to be a deeper >issue: Some protocols, most notably FTP, pass IP socket addresses at the >application level. These need to be translated by Application Level >Gateways (ALGs). However, once IP traffic has been enrypted, this >information cannot be available to the ALG. > >This appears to imply that NAT, in general, must be performed before >encryption. This is at odds with the models that a number of service >providers are trying to apply. Are there any solutions to these problems? >Or any papers detailing the sort of problems that occur when mixing NAT with >IPSEC. > >Thanks, >Chris > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, and insert a UDP header in front of the ESP header. This is dead simple and works with normal NAT boxes. Problems and solutions: - some NAT boxes drop fragmented UDP packets. You'll have to mess around with TCP segment sizes and/or encrypt fragments. - The NAT box does not affect any protocols, like FTP, because it's modifying the "outer" IP header and an artifical UDP header. - There might be address collisions. Two clients might be behind firewalls and have the same address 192.168.98.6. Now they do quick mode to the same GW. Trouble ahead. You need some NAT here, be it at the GW or at the client, or private IP address by cfg-mode. Or something. J–rn From owner-ipsec@lists.tislabs.com Thu Jun 7 07:09:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA09309; Thu, 7 Jun 2001 07:09:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22319 Thu, 7 Jun 2001 09:11:14 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Joern Sierwald Cc: ipsec@lists.tislabs.com, Chris Trobridge Subject: Re: IPSEC Security Gateways & NAT Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Date: Thu, 07 Jun 2001 09:16:27 -0400 Message-Id: <20010607131627.C99717B84@berkshire.research.att.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA22315 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3.0.5.32.20010607143550.047a3380@smtp.datafellows.com>, Joern Sierw ald writes: >> > >The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, >and insert a UDP header in front of the ESP header. This is dead simple >and works with normal NAT boxes. > I don't know that I'd use the word "consensus" -- and I would note that that SSH has claimed assorted patent rights to the concept, at least as explained in draft-stenberg-ipsec-nat-traversal-*.txt. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Jun 7 08:26:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17514; Thu, 7 Jun 2001 08:26:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22624 Thu, 7 Jun 2001 10:19:26 -0400 (EDT) Message-ID: From: Chris Trobridge To: Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 7 Jun 2001 15:25:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The scenario I'm talking about is where the service provider wants to NAT the private addresses, ie the inner addresses if tunnelling. Obviously this is completely contrary to the RFCs but ownership/management issues make it hard to place the NAT before encryption (when customer encrypts and service provider NATs). I don't think it can be done but I'm looking for some consensus or other evidence on this point. Chris > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > and insert a UDP header in front of the ESP header. This is > dead simple and works with normal NAT boxes. > > Problems and solutions: > > - some NAT boxes drop fragmented UDP packets. You'll have to > mess around > with TCP segment sizes and/or encrypt fragments. > > - The NAT box does not affect any protocols, like FTP, > because it's modifying > the "outer" IP header and an artifical UDP header. > > - There might be address collisions. Two clients might be > behind firewalls > and have > the same address 192.168.98.6. Now they do quick mode to > the same GW. > Trouble ahead. You need some NAT here, be it at the GW or > at the client, > or private IP address by cfg-mode. Or something. > > J-rn > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Thu Jun 7 08:27:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17732; Thu, 7 Jun 2001 08:27:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22638 Thu, 7 Jun 2001 10:23:03 -0400 (EDT) Message-ID: <20010607142848.13984.qmail@web13801.mail.yahoo.com> Date: Thu, 7 Jun 2001 07:28:48 -0700 (PDT) From: Pyda Srisuresh Subject: Re: IPSEC Security Gateways & NAT To: Chris Trobridge , 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 --- Chris Trobridge wrote: > We've come up against a number of situations where the network service > provider has used NAT and the customer wants to add IP security by adding > Security Gateways between their networks and the service provider's access > points. Why cant the traffic between customer site and the access point be secured? There is no NAT involved thus far. All that the customer is asking for is tunnel-mode security. The Access Point at the providers's site will need a security gateway function. NAT happens after this. > > RFC2401 says that a Security Gateway must use tunnel mode unless it is > acting as a host (eg management). The negates the service provider's use of > NAT by preventing it from translating client addresses - which in some cases > overlap across across multiple private networks. > Please see my comments above. > Some vendors offer non-standard encryption modes - eg transport or > proprietary - that do pass the IP (and even TCP/UDP) headers through in > clear too. This exposes the client IP address for NAT but means that the > encryption end-points probably won't agree on the selectors for the security > association - as they will see different addresses for the same client. > > Even assuming that the management issues associated with agreeing SAs > (possibly with dynamic NAT) can be fixed, there appears to be a deeper > issue: Some protocols, most notably FTP, pass IP socket addresses at the > application level. These need to be translated by Application Level > Gateways (ALGs). However, once IP traffic has been enrypted, this > information cannot be available to the ALG. > > This appears to imply that NAT, in general, must be performed before > encryption. This is at odds with the models that a number of service > providers are trying to apply. Are there any solutions to these problems? > Or any papers detailing the sort of problems that occur when mixing NAT with > IPSEC. You might want to take a look at RFC 2709, even though that may not be the model you are looking at. > > Thanks, > Chris > > cheers, suresh ===== __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Jun 7 08:57:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA23631; Thu, 7 Jun 2001 08:57:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22748 Thu, 7 Jun 2001 10:51:34 -0400 (EDT) Message-ID: <3B1F95F9.7460D5E4@storm.ca> Date: Thu, 07 Jun 2001 10:55:53 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Chris Trobridge CC: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge wrote: > This appears to imply that NAT, in general, must be performed before > encryption. This is at odds with the models that a number of service > providers are trying to apply. Are there any solutions to these problems? > Or any papers detailing the sort of problems that occur when mixing NAT with > IPSEC. There's some discussion, and links to other things, in the FreeS/WAN docs: http://www.freeswan.org/freeswan_trees/freeswan-1.9/doc/firewall.html#NAT A new 1.91 version, slightly expanded, should appear within a few days, when 1.91 is released. I'm the author and I think that discussion could stand improvement. If you find good references on this please either post them here or send me mail about them. From owner-ipsec@lists.tislabs.com Thu Jun 7 10:28:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29577; Thu, 7 Jun 2001 10:28:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23049 Thu, 7 Jun 2001 12:10:18 -0400 (EDT) Message-ID: <3B1FA8A5.87F6B776@F-Secure.com> Date: Thu, 07 Jun 2001 19:15:33 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Joern Sierwald , ipsec@lists.tislabs.com, Chris Trobridge Subject: Re: IPSEC Security Gateways & NAT References: <20010607131627.C99717B84@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message <3.0.5.32.20010607143550.047a3380@smtp.datafellows.com>, Joern Sierw > ald writes: > > >> > > > >The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > >and insert a UDP header in front of the ESP header. This is dead simple > >and works with normal NAT boxes. > > > > I don't know that I'd use the word "consensus" -- and I would note that > that SSH has claimed assorted patent rights to the concept, at least as > explained in draft-stenberg-ipsec-nat-traversal-*.txt. Consensus is perhaps too strong a word, but the suggestions I've seen are of two kinds: they modify the NAT box, or they put a UDP header in front of the ESP (or AH) header. If one has the assumption that NAT boxes can't be modified, I'd say the concensus is on UDP encapsulation. I've seen two SSH patent applications on this, and they didn't (seem to) cover simple UDP header in front of ESP header. They cover a lot of other things, but not that. The reason is probably that some hardware gateway vendors have had this in for years. I don't know exactly how long, but that's what someone told me in San Diego last fall. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Jun 7 10:28:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA29595; Thu, 7 Jun 2001 10:28:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23127 Thu, 7 Jun 2001 12:38:08 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Steven M. Bellovin'" Cc: Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 7 Jun 2001 12:08:40 -0400 Message-Id: <000601c0ef6c$38071ab0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <20010607131627.C99717B84@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On the contrary, from what I have seen there is a consensus for ESPoUDP. At least 6 vendors are planning to implement this approach, and we are anxiously awaiting the release of the new merged NAT traversal document. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Steven M. Bellovin > Sent: Thursday, June 07, 2001 9:16 AM > To: Joern Sierwald > Cc: ipsec@lists.tislabs.com; Chris Trobridge > Subject: Re: IPSEC Security Gateways & NAT > > > In message > <3.0.5.32.20010607143550.047a3380@smtp.datafellows.com>, Joern Sierw > ald writes: > > >> > > > >The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > >and insert a UDP header in front of the ESP header. This is > dead simple > >and works with normal NAT boxes. > > > > I don't know that I'd use the word "consensus" -- and I would > note that > that SSH has claimed assorted patent rights to the concept, > at least as > explained in draft-stenberg-ipsec-nat-traversal-*.txt. > > > --Steve Bellovin, http://www.research.att.com/~smb > > > From owner-ipsec@lists.tislabs.com Fri Jun 8 04:59:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA17869; Fri, 8 Jun 2001 04:59:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25594 Fri, 8 Jun 2001 06:58:05 -0400 (EDT) Message-ID: <001a01c0ef96$2ac329a0$dbb02304@ffb5b> From: "jshukla" To: "Chris Trobridge" , References: Subject: Re: IPSEC Security Gateways & NAT Date: Thu, 7 Jun 2001 14:09:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Chris Trobridge" To: Sent: Thursday, June 07, 2001 4:56 AM Subject: IPSEC Security Gateways & NAT > > Even assuming that the management issues associated with agreeing SAs > (possibly with dynamic NAT) can be fixed, there appears to be a deeper > issue: Some protocols, most notably FTP, pass IP socket addresses at the > application level. These need to be translated by Application Level > Gateways (ALGs). However, once IP traffic has been enrypted, this > information cannot be available to the ALG. > There is another proposal to solve the IPSec and NAT conflict. It specifically shows how the FTP problem can be solved. http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible -security-00.txt Although we have not talked about the case when NAT is performed by the ISP, it is not a problem. Our new draft will address that. In addition to the issues raised by you, there are other problems, such as, peer-to-peer security, support for per-flow based QoS, and content based switching. Our proposal solves all these problems as well. On the other hand, ESPinUDP does not enable peer-to-peer security, per-flow based QoS, and use of ALGs. > This appears to imply that NAT, in general, must be performed before > encryption. This is at odds with the models that a number of service > providers are trying to apply. Are there any solutions to these problems? > Or any papers detailing the sort of problems that occur when mixing NAT with > IPSEC. > > Thanks, > Chris > regards, Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 08:04:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02351; Fri, 8 Jun 2001 08:04:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25926 Fri, 8 Jun 2001 09:48:22 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD74D@mail.ellacoya.com> From: "Chen, David" To: "'jshukla'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 8 Jun 2001 09:50:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, Why ESP over UDP does peer-to-peer secutiry? I assume you talk aoubt SG-NAT===NAT-SG situation. Thanks, --- David -----Original Message----- From: jshukla [mailto:jshukla@earthlink.net] Sent: Thursday, June 07, 2001 5:10 PM To: Chris Trobridge; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT ----- Original Message ----- From: "Chris Trobridge" To: Sent: Thursday, June 07, 2001 4:56 AM Subject: IPSEC Security Gateways & NAT > > Even assuming that the management issues associated with agreeing SAs > (possibly with dynamic NAT) can be fixed, there appears to be a deeper > issue: Some protocols, most notably FTP, pass IP socket addresses at the > application level. These need to be translated by Application Level > Gateways (ALGs). However, once IP traffic has been enrypted, this > information cannot be available to the ALG. > There is another proposal to solve the IPSec and NAT conflict. It specifically shows how the FTP problem can be solved. http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible -security-00.txt Although we have not talked about the case when NAT is performed by the ISP, it is not a problem. Our new draft will address that. In addition to the issues raised by you, there are other problems, such as, peer-to-peer security, support for per-flow based QoS, and content based switching. Our proposal solves all these problems as well. On the other hand, ESPinUDP does not enable peer-to-peer security, per-flow based QoS, and use of ALGs. > This appears to imply that NAT, in general, must be performed before > encryption. This is at odds with the models that a number of service > providers are trying to apply. Are there any solutions to these problems? > Or any papers detailing the sort of problems that occur when mixing NAT with > IPSEC. > > Thanks, > Chris > regards, Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 09:47:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13511; Fri, 8 Jun 2001 09:47:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26114 Fri, 8 Jun 2001 11:44:26 -0400 (EDT) From: "Scott G. Kelly" To: jshukla Cc: Chris Trobridge , ipsec@lists.tislabs.com Message-ID: <3B20F3FB.F6224E0B@redcreek.com> Date: Fri, 08 Jun 2001 08:49:15 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IPSEC Security Gateways & NAT References: <001a01c0ef96$2ac329a0$dbb02304@ffb5b> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In addition to the issues raised below, the current esp-in-udp proposals do not address device management. jshukla wrote: > > ----- Original Message ----- > From: "Chris Trobridge" > To: > Sent: Thursday, June 07, 2001 4:56 AM > Subject: IPSEC Security Gateways & NAT > > > > > Even assuming that the management issues associated with agreeing SAs > > (possibly with dynamic NAT) can be fixed, there appears to be a deeper > > issue: Some protocols, most notably FTP, pass IP socket addresses at the > > application level. These need to be translated by Application Level > > Gateways (ALGs). However, once IP traffic has been enrypted, this > > information cannot be available to the ALG. > > > > There is another proposal to solve the IPSec and NAT conflict. It > specifically > shows how the FTP problem can be solved. > > http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible > -security-00.txt > > Although we have not talked about the case when NAT is performed > by the ISP, it is not a problem. Our new draft will address that. > > In addition to the issues raised by you, there are other problems, > such as, peer-to-peer security, support for per-flow based QoS, > and content based switching. Our proposal solves all these problems > as well. > > On the other hand, ESPinUDP does not enable peer-to-peer > security, per-flow based QoS, and use of ALGs. > > > This appears to imply that NAT, in general, must be performed before > > encryption. This is at odds with the models that a number of service > > providers are trying to apply. Are there any solutions to these problems? > > Or any papers detailing the sort of problems that occur when mixing NAT > with > > IPSEC. > > > > Thanks, > > Chris > > > > regards, > Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 11:25:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19174; Fri, 8 Jun 2001 11:25:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26407 Fri, 8 Jun 2001 13:21:43 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD74E@mail.ellacoya.com> From: "Chen, David" To: "'jshukla'" , "Chen, David" , Chris Trobridge , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 8 Jun 2001 13:24:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets? I thought in this thread, someone mention tunneling IPSec by encapsulate in UDP/IP packet to pass through NAPT? (with the case Host-SG-NAT == NAT-SG-Host) Regards, --- David -----Original Message----- From: jshukla [mailto:jshukla@earthlink.net] Sent: Friday, June 08, 2001 1:23 PM To: Chen, David; Chris Trobridge; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT David, I am not sure I understand your question. My point is that ESPinUDP is a solution for NAT compatibility, but cannot be extended to support peer-to-peer security. It is applicable to SG-NAT ==== NAT-SG scenario only. What is the point of a solution if we have to deal with the NAT problem "again" when we move on to peer-to-peer security. In addition to this, ESPinUDP has problems with fragmented packets, ICMP messages, FTP, and higher layer QoS protocols. regards, Jayant ----- Original Message ----- From: "Chen, David" To: "'jshukla'" ; "Chris Trobridge" ; Sent: Friday, June 08, 2001 6:50 AM Subject: RE: IPSEC Security Gateways & NAT > Jayant, > Why ESP over UDP does peer-to-peer secutiry? > I assume you talk aoubt SG-NAT===NAT-SG situation. > Thanks, > --- David > > -----Original Message----- > From: jshukla [mailto:jshukla@earthlink.net] > Sent: Thursday, June 07, 2001 5:10 PM > To: Chris Trobridge; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > > ----- Original Message ----- > From: "Chris Trobridge" > To: > Sent: Thursday, June 07, 2001 4:56 AM > Subject: IPSEC Security Gateways & NAT > > > > > > Even assuming that the management issues associated with agreeing SAs > > (possibly with dynamic NAT) can be fixed, there appears to be a deeper > > issue: Some protocols, most notably FTP, pass IP socket addresses at the > > application level. These need to be translated by Application Level > > Gateways (ALGs). However, once IP traffic has been enrypted, this > > information cannot be available to the ALG. > > > > There is another proposal to solve the IPSec and NAT conflict. It > specifically > shows how the FTP problem can be solved. > > http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible > -security-00.txt > > Although we have not talked about the case when NAT is performed > by the ISP, it is not a problem. Our new draft will address that. > > In addition to the issues raised by you, there are other problems, > such as, peer-to-peer security, support for per-flow based QoS, > and content based switching. Our proposal solves all these problems > as well. > > On the other hand, ESPinUDP does not enable peer-to-peer > security, per-flow based QoS, and use of ALGs. > > > This appears to imply that NAT, in general, must be performed before > > encryption. This is at odds with the models that a number of service > > providers are trying to apply. Are there any solutions to these problems? > > Or any papers detailing the sort of problems that occur when mixing NAT > with > > IPSEC. > > > > Thanks, > > Chris > > > > regards, > Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 11:48:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19837; Fri, 8 Jun 2001 11:48:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26501 Fri, 8 Jun 2001 14:07:56 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD74F@mail.ellacoya.com> From: "Chen, David" To: "'jshukla'" , "Chen, David" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 8 Jun 2001 14:10:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, Does "ESPinUDP" apply to both transport and tunnel mode? Where is the draft? Thanks, --- David -----Original Message----- From: jshukla [mailto:jshukla@earthlink.net] Sent: Friday, June 08, 2001 2:00 PM To: Chen, David; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT ----- Original Message ----- From: "Chen, David" > Jayant, > Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets? Almost! ESPinUDP inserts an extra UDP header in IPSec packets. In IPSec, the ESP header follows the IP header. In ESPinUDP a UDP header follows the IP header and ESP header comes after that. IP header | UDP header | ESP header | encrypted payload regards, Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 12:56:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22918; Fri, 8 Jun 2001 12:56:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26601 Fri, 8 Jun 2001 14:39:54 -0400 (EDT) To: "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD74F@mail.ellacoya.com> From: Derek Atkins Date: 08 Jun 2001 14:45:34 -0400 In-Reply-To: "Chen, David"'s message of "Fri, 8 Jun 2001 14:10:01 -0400" Message-ID: Lines: 56 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My understanding was that ESPinUDP == ESPoUDP which is basically an encapsulation of ESP packets (_ANY_ ESP packet) in a UDP header. So, you use UDP as the transport mechanism to get the ESP packet from host A to host B through whatever NATs are in the way. The end-hosts decapsulate the packets, and then process the ESP as they normally would. This implies ALL protections and features you would get from normal ESP. The benefit is that this works 100% in a one-sided-NAT or Road-Warrior system. E.g., if you have something like: RW - NAT - - SG The Road Warrior can setup a NAT traversal by sending UDP packets (that happen to contain ESP), and the SG can reply back to the host (through the NAT) back to the original UDP port. -derek "Chen, David" writes: > Jayant, > Does "ESPinUDP" apply to both transport and tunnel mode? > Where is the draft? > Thanks, > --- David > > -----Original Message----- > From: jshukla [mailto:jshukla@earthlink.net] > Sent: Friday, June 08, 2001 2:00 PM > To: Chen, David; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > > ----- Original Message ----- > From: "Chen, David" > > > Jayant, > > Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets? > > Almost! ESPinUDP inserts an extra UDP header in IPSec packets. > In IPSec, the ESP header follows the IP header. In ESPinUDP > a UDP header follows the IP header and ESP header comes after > that. > > IP header | UDP header | ESP header | encrypted payload > > regards, > Jayant -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Jun 8 14:21:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29532; Fri, 8 Jun 2001 14:21:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26899 Fri, 8 Jun 2001 16:28:01 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD750@mail.ellacoya.com> From: "Chen, David" To: "'Wilson Ellington'" , "Chen, David" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 8 Jun 2001 16:26:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk just send "unsubscribe" to the WG server. (ipsec@lists.tislabs.com) -----Original Message----- From: Wilson Ellington [mailto:Wilson.Ellington@ncmail.net] Sent: Friday, June 08, 2001 4:19 PM To: Chen, David Subject: Re: IPSEC Security Gateways & NAT How can I get removed from the mailing list here?? "Chen, David" wrote: > Jayant, > Does "ESPinUDP" apply to both transport and tunnel mode? > Where is the draft? > Thanks, > --- David > > -----Original Message----- > From: jshukla [mailto:jshukla@earthlink.net] > Sent: Friday, June 08, 2001 2:00 PM > To: Chen, David; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > ----- Original Message ----- > From: "Chen, David" > > > Jayant, > > Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets? > > Almost! ESPinUDP inserts an extra UDP header in IPSec packets. > In IPSec, the ESP header follows the IP header. In ESPinUDP > a UDP header follows the IP header and ESP header comes after > that. > > IP header | UDP header | ESP header | encrypted payload > > regards, > Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 14:22:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29636; Fri, 8 Jun 2001 14:22:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26870 Fri, 8 Jun 2001 16:24:01 -0400 (EDT) Message-ID: <001601c0f044$e7b030e0$25b12304@ffb5b> From: "jshukla" To: "Chen, David" , References: <85D31AAF3DFCD4119C44000102C009707DD74E@mail.ellacoya.com> Subject: Re: IPSEC Security Gateways & NAT Date: Fri, 8 Jun 2001 11:00:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Chen, David" > Jayant, > Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets? Almost! ESPinUDP inserts an extra UDP header in IPSec packets. In IPSec, the ESP header follows the IP header. In ESPinUDP a UDP header follows the IP header and ESP header comes after that. IP header | UDP header | ESP header | encrypted payload regards, Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 14:26:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29950; Fri, 8 Jun 2001 14:26:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26851 Fri, 8 Jun 2001 16:23:01 -0400 (EDT) Message-ID: <002001c0f03f$a3c386c0$25b12304@ffb5b> From: "jshukla" To: "Chen, David" , "Chris Trobridge" , References: <85D31AAF3DFCD4119C44000102C009707DD74D@mail.ellacoya.com> Subject: Re: IPSEC Security Gateways & NAT Date: Fri, 8 Jun 2001 10:22:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, I am not sure I understand your question. My point is that ESPinUDP is a solution for NAT compatibility, but cannot be extended to support peer-to-peer security. It is applicable to SG-NAT ==== NAT-SG scenario only. What is the point of a solution if we have to deal with the NAT problem "again" when we move on to peer-to-peer security. In addition to this, ESPinUDP has problems with fragmented packets, ICMP messages, FTP, and higher layer QoS protocols. regards, Jayant ----- Original Message ----- From: "Chen, David" To: "'jshukla'" ; "Chris Trobridge" ; Sent: Friday, June 08, 2001 6:50 AM Subject: RE: IPSEC Security Gateways & NAT > Jayant, > Why ESP over UDP does peer-to-peer secutiry? > I assume you talk aoubt SG-NAT===NAT-SG situation. > Thanks, > --- David > > -----Original Message----- > From: jshukla [mailto:jshukla@earthlink.net] > Sent: Thursday, June 07, 2001 5:10 PM > To: Chris Trobridge; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > > ----- Original Message ----- > From: "Chris Trobridge" > To: > Sent: Thursday, June 07, 2001 4:56 AM > Subject: IPSEC Security Gateways & NAT > > > > > > Even assuming that the management issues associated with agreeing SAs > > (possibly with dynamic NAT) can be fixed, there appears to be a deeper > > issue: Some protocols, most notably FTP, pass IP socket addresses at the > > application level. These need to be translated by Application Level > > Gateways (ALGs). However, once IP traffic has been enrypted, this > > information cannot be available to the ALG. > > > > There is another proposal to solve the IPSec and NAT conflict. It > specifically > shows how the FTP problem can be solved. > > http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible > -security-00.txt > > Although we have not talked about the case when NAT is performed > by the ISP, it is not a problem. Our new draft will address that. > > In addition to the issues raised by you, there are other problems, > such as, peer-to-peer security, support for per-flow based QoS, > and content based switching. Our proposal solves all these problems > as well. > > On the other hand, ESPinUDP does not enable peer-to-peer > security, per-flow based QoS, and use of ALGs. > > > This appears to imply that NAT, in general, must be performed before > > encryption. This is at odds with the models that a number of service > > providers are trying to apply. Are there any solutions to these problems? > > Or any papers detailing the sort of problems that occur when mixing NAT > with > > IPSEC. > > > > Thanks, > > Chris > > > > regards, > Jayant From owner-ipsec@lists.tislabs.com Fri Jun 8 14:34:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00661; Fri, 8 Jun 2001 14:34:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26978 Fri, 8 Jun 2001 16:45:49 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD751@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" , "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 8 Jun 2001 16:47:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Thanks for the explanation. Its seems difficult for IKE to traverse NAPT in ESPoUDP. (the address/port changed) Does ESPoUDP only apply to data channel? Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@mit.edu] Sent: Friday, June 08, 2001 2:46 PM To: Chen, David Cc: 'jshukla'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT My understanding was that ESPinUDP == ESPoUDP which is basically an encapsulation of ESP packets (_ANY_ ESP packet) in a UDP header. So, you use UDP as the transport mechanism to get the ESP packet from host A to host B through whatever NATs are in the way. The end-hosts decapsulate the packets, and then process the ESP as they normally would. This implies ALL protections and features you would get from normal ESP. The benefit is that this works 100% in a one-sided-NAT or Road-Warrior system. E.g., if you have something like: RW - NAT - - SG The Road Warrior can setup a NAT traversal by sending UDP packets (that happen to contain ESP), and the SG can reply back to the host (through the NAT) back to the original UDP port. -derek "Chen, David" writes: > Jayant, > Does "ESPinUDP" apply to both transport and tunnel mode? > Where is the draft? > Thanks, > --- David > > -----Original Message----- > From: jshukla [mailto:jshukla@earthlink.net] > Sent: Friday, June 08, 2001 2:00 PM > To: Chen, David; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > > ----- Original Message ----- > From: "Chen, David" > > > Jayant, > > Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets? > > Almost! ESPinUDP inserts an extra UDP header in IPSec packets. > In IPSec, the ESP header follows the IP header. In ESPinUDP > a UDP header follows the IP header and ESP header comes after > that. > > IP header | UDP header | ESP header | encrypted payload > > regards, > Jayant -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Jun 8 14:34:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA00688; Fri, 8 Jun 2001 14:34:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27028 Fri, 8 Jun 2001 16:53:51 -0400 (EDT) To: "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD751@mail.ellacoya.com> From: Derek Atkins Date: 08 Jun 2001 16:59:36 -0400 In-Reply-To: "Chen, David"'s message of "Fri, 8 Jun 2001 16:47:56 -0400" Message-ID: Lines: 97 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Honestly, I'm not 100% sure how IKE works in this configuration. At least in this method the initiator can be behind a NAT. It's unclear how it would work if the responder is behind a NAT. In the architecture I described, the initiator is behind a NAT but the responder is not. Once an IKE SA is available, the peers must keep the NAT 'live', mostly by forcing some traffic across the UDP "connection". The IKE daemons can just cache the port mappings (it means the responder will not necessarily see the initiator coming from port 500). The good thing is that one can multiplex both IKE and ESP onto the same UDP port pairs. -derek "Chen, David" writes: > Derek, > Thanks for the explanation. > Its seems difficult for IKE to traverse NAPT in ESPoUDP. (the address/port > changed) > Does ESPoUDP only apply to data channel? > Regards, > --- David > > > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Friday, June 08, 2001 2:46 PM > To: Chen, David > Cc: 'jshukla'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > My understanding was that ESPinUDP == ESPoUDP which is basically an > encapsulation of ESP packets (_ANY_ ESP packet) in a UDP header. So, > you use UDP as the transport mechanism to get the ESP packet from host > A to host B through whatever NATs are in the way. The end-hosts > decapsulate the packets, and then process the ESP as they normally > would. This implies ALL protections and features you would get from > normal ESP. > > The benefit is that this works 100% in a one-sided-NAT or Road-Warrior > system. E.g., if you have something like: > > RW - NAT - - SG > > The Road Warrior can setup a NAT traversal by sending UDP packets > (that happen to contain ESP), and the SG can reply back to the host > (through the NAT) back to the original UDP port. > > -derek > > "Chen, David" writes: > > > Jayant, > > Does "ESPinUDP" apply to both transport and tunnel mode? > > Where is the draft? > > Thanks, > > --- David > > > > -----Original Message----- > > From: jshukla [mailto:jshukla@earthlink.net] > > Sent: Friday, June 08, 2001 2:00 PM > > To: Chen, David; ipsec@lists.tislabs.com > > Subject: Re: IPSEC Security Gateways & NAT > > > > > > > > ----- Original Message ----- > > From: "Chen, David" > > > > > Jayant, > > > Does the "ESPinUDP" mean UDP/IP encapsulate IPSec packets? > > > > Almost! ESPinUDP inserts an extra UDP header in IPSec packets. > > In IPSec, the ESP header follows the IP header. In ESPinUDP > > a UDP header follows the IP header and ESP header comes after > > that. > > > > IP header | UDP header | ESP header | encrypted payload > > > > regards, > > Jayant > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Sat Jun 9 13:46:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f59Kk6J07004; Sat, 9 Jun 2001 13:46:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28620 Sat, 9 Jun 2001 15:37:31 -0400 (EDT) To: "jshukla" Cc: "Chen, David" , Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD751@mail.ellacoya.com> <000801c0f100$c02f8e50$1ab02304@ffb5b> From: Derek Atkins Date: 09 Jun 2001 15:43:13 -0400 In-Reply-To: "jshukla"'s message of "Sat, 9 Jun 2001 09:23:48 -0700" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "jshukla" writes: > This is the only case that they discuss in their draft and > I am not sure that even this case works. My concern is > about the authenticating hash computation. > > HASH_I = pfr(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b) Um, I don't see anything here that necessarily depends upon the IP Address of either Initiator or Responder. Perhaps I am being dense, but could you please point out the specific term to which you refer? Keep in mind that the ID term is **NOT** necessarily tied to the IP Address, as you can use many types of ID (such as FQDN) that are "movable". -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 11 07:44:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BEimJ00605; Mon, 11 Jun 2001 07:44:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01901 Mon, 11 Jun 2001 09:20:37 -0400 (EDT) Message-ID: From: Chris Trobridge To: "Riley, Susie" , Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 11 Jun 2001 14:27:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The ISP wants to muck around with the inner addresses to cater for overlapping address ranges between different sites. The trouble is that there have been various cases where ISPs have 'solved' their customer's VPN problem with NAT prior to introducing security. This means they've often used NAT to move datagrams over their network, as well as to avoid overlapping subnets. I've also seen it used for more esoteric purposes. The above illustrates a scenario where the ISP has invested in NAT'ing the customers addresses. When the ISP adds encryptors they expect the existing network to need no change but IPSEC security gateways tunnel and break their model. So the ISP will ask "can you use transport mode?", so they can continue to NAT. However, I'm not convinced this would work as NAT ALGs will still not have access to the TCP/UDP payloads for the application-level NAT. Even without ALG, this would also require the transport headers to be passed in clear. Of course, as the IPSEC SG only needs one external address, there's little point for NAT on the ISP side anymore. And the ISP is still required to provide a transparent solution to the customer but isn't trusted with the security. Chris > -----Original Message----- > From: Riley, Susie [mailto:Susie_Riley@adc.com] > Sent: 11 June 2001 13:23 > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com > Subject: RE: IPSEC Security Gateways & NAT > > > > if you are trying to put an encryption/vpn box between the > customes sites > and the isp, the address assignment by the isp should be for the outer > tunnel address (to be used by the vpn box to tunnel the > traffic). in this > case, as people suggest, esp+udp should work for nat, and > it's the outside > address the isp might muck with - not the inner address > because as far as > the isp is concerned, there's only one box behind it, and that's the > ipsec/vpn box. as far as the isp is concerned all the boxes > behind the > ipsec/vpn box could be using private addresses and it should > not care. can > you describe a scenario where the isp would want to muck with > both inside > and outside addresses in a ipsec/vpn scenario, or are you > talking about a > different scenario altogether? > > susie > > -----Original Message----- > From: Chris Trobridge [mailto:CTrobridge@baltimore.com] > Sent: Thursday, June 07, 2001 10:25 AM > To: Joern Sierwald; ipsec@lists.tislabs.com > Subject: RE: IPSEC Security Gateways & NAT > > > The scenario I'm talking about is where the service provider > wants to NAT > the private addresses, ie the inner addresses if tunnelling. > Obviously this > is completely contrary to the RFCs but ownership/management > issues make it > hard to place the NAT before encryption (when customer > encrypts and service > provider NATs). > > I don't think it can be done but I'm looking for some > consensus or other > evidence on this point. > > Chris > > > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > > and insert a UDP header in front of the ESP header. This is > > dead simple and works with normal NAT boxes. > > > > Problems and solutions: > > > > - some NAT boxes drop fragmented UDP packets. You'll have to > > mess around > > with TCP segment sizes and/or encrypt fragments. > > > > - The NAT box does not affect any protocols, like FTP, > > because it's modifying > > the "outer" IP header and an artifical UDP header. > > > > - There might be address collisions. Two clients might be > > behind firewalls > > and have > > the same address 192.168.98.6. Now they do quick mode to > > the same GW. > > Trouble ahead. You need some NAT here, be it at the GW or > > at the client, > > or private IP address by cfg-mode. Or something. > > > > J-rn > > > > > > This footnote confirms that this email message has been swept by > > MIMEsweeper for the presence of computer viruses. > > > > > -------------------------------------------------------------- > -------------- > ------------------------------------- > The information contained in this message is confidential and > is intended > for the addressee(s) only. If you have received this message > in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this > message is > strictly forbidden. Baltimore Technologies plc will not be liable for > direct, > special, indirect or consequential damages arising from > alteration of the > contents of this message by a third party or as a result of > any virus being > passed on. > > In addition, certain Marketing collateral may be added from > time to time to > promote Baltimore Technologies products, services, Global > e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. > From owner-ipsec@lists.tislabs.com Mon Jun 11 08:07:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BF79J02099; Mon, 11 Jun 2001 08:07:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02108 Mon, 11 Jun 2001 10:19:00 -0400 (EDT) Message-ID: <000801c0f100$c02f8e50$1ab02304@ffb5b> From: "jshukla" To: "Chen, David" , "Derek Atkins" Cc: References: <85D31AAF3DFCD4119C44000102C009707DD751@mail.ellacoya.com> Subject: Re: IPSEC Security Gateways & NAT Date: Sat, 9 Jun 2001 09:23:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Derek Atkins" > Honestly, I'm not 100% sure how IKE works in this configuration. At > least in this method the initiator can be behind a NAT. It's unclear > how it would work if the responder is behind a NAT. In the > architecture I described, the initiator is behind a NAT but the > responder is not. > This is the only case that they discuss in their draft and I am not sure that even this case works. My concern is about the authenticating hash computation. HASH_I = pfr(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b) since NAT changes the source IP address, the initiator gets the value of HASH_I wrong. The only way, this problem can be solved is if the initiator knows how NAT translates the IP address. If the ISP is also applying NAT, it may be impossible for the initiator to get this information and will always compute HASH_I incorrectly. Same applies to the responder. regards, Jayant From owner-ipsec@lists.tislabs.com Mon Jun 11 08:07:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BF7WJ02173; Mon, 11 Jun 2001 08:07:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02114 Mon, 11 Jun 2001 10:19:59 -0400 (EDT) Message-ID: <000601c0f239$6b667bb0$6ab02304@ffb5b> From: "jshukla" To: "Derek Atkins" Cc: References: <85D31AAF3DFCD4119C44000102C009707DD751@mail.ellacoya.com> <000801c0f100$c02f8e50$1ab02304@ffb5b> Subject: Re: IPSEC Security Gateways & NAT Date: Sun, 10 Jun 2001 22:43:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Derek Atkins" > > HASH_I = pfr(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b) > > Um, I don't see anything here that necessarily depends upon the IP > Address of either Initiator or Responder. Perhaps I am being dense, > but could you please point out the specific term to which you refer? > Keep in mind that the ID term is **NOT** necessarily tied to the IP > Address, as you can use many types of ID (such as FQDN) that are > "movable". > Isn't there a problem in using pre-shared keys for authentication in the main mode? The responder uses the IP address to look up the pre-shared key. Because of NAT, it may not be able to look up the correct pre-shared key?! If you use aggressive mode, you can overcome this problem, but the authors of ESPinUSP proposal use the main mode in their example. regards, Jayant From owner-ipsec@lists.tislabs.com Mon Jun 11 08:17:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BFHwJ02711; Mon, 11 Jun 2001 08:17:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02121 Mon, 11 Jun 2001 10:21:00 -0400 (EDT) Message-ID: <95D210E03433D51188A60008C71694070111C1AB@mn02exch02.adc.com> From: "Riley, Susie" To: Chris Trobridge , Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 11 Jun 2001 07:23:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk if you are trying to put an encryption/vpn box between the customes sites and the isp, the address assignment by the isp should be for the outer tunnel address (to be used by the vpn box to tunnel the traffic). in this case, as people suggest, esp+udp should work for nat, and it's the outside address the isp might muck with - not the inner address because as far as the isp is concerned, there's only one box behind it, and that's the ipsec/vpn box. as far as the isp is concerned all the boxes behind the ipsec/vpn box could be using private addresses and it should not care. can you describe a scenario where the isp would want to muck with both inside and outside addresses in a ipsec/vpn scenario, or are you talking about a different scenario altogether? susie -----Original Message----- From: Chris Trobridge [mailto:CTrobridge@baltimore.com] Sent: Thursday, June 07, 2001 10:25 AM To: Joern Sierwald; ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT The scenario I'm talking about is where the service provider wants to NAT the private addresses, ie the inner addresses if tunnelling. Obviously this is completely contrary to the RFCs but ownership/management issues make it hard to place the NAT before encryption (when customer encrypts and service provider NATs). I don't think it can be done but I'm looking for some consensus or other evidence on this point. Chris > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > and insert a UDP header in front of the ESP header. This is > dead simple and works with normal NAT boxes. > > Problems and solutions: > > - some NAT boxes drop fragmented UDP packets. You'll have to > mess around > with TCP segment sizes and/or encrypt fragments. > > - The NAT box does not affect any protocols, like FTP, > because it's modifying > the "outer" IP header and an artifical UDP header. > > - There might be address collisions. Two clients might be > behind firewalls > and have > the same address 192.168.98.6. Now they do quick mode to > the same GW. > Trouble ahead. You need some NAT here, be it at the GW or > at the client, > or private IP address by cfg-mode. Or something. > > J-rn > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ---------------------------------------------------------------------------- ------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Mon Jun 11 09:32:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BGWsJ09178; Mon, 11 Jun 2001 09:32:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02408 Mon, 11 Jun 2001 11:02:10 -0400 (EDT) To: "jshukla" Cc: Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD751@mail.ellacoya.com> <000801c0f100$c02f8e50$1ab02304@ffb5b> <000601c0f239$6b667bb0$6ab02304@ffb5b> From: Derek Atkins Date: 11 Jun 2001 11:07:55 -0400 In-Reply-To: "jshukla"'s message of "Sun, 10 Jun 2001 22:43:18 -0700" Message-ID: Lines: 35 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok, yes, there is a problem with using pre-shared keys in main mode. -derek "jshukla" writes: > ----- Original Message ----- > From: "Derek Atkins" > > > HASH_I = pfr(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b) > > > > Um, I don't see anything here that necessarily depends upon the IP > > Address of either Initiator or Responder. Perhaps I am being dense, > > but could you please point out the specific term to which you refer? > > Keep in mind that the ID term is **NOT** necessarily tied to the IP > > Address, as you can use many types of ID (such as FQDN) that are > > "movable". > > > > Isn't there a problem in using pre-shared keys for authentication in > the main mode? The responder uses the IP address to look up the > pre-shared key. Because of NAT, it may not be able to look up the > correct pre-shared key?! If you use aggressive mode, you can overcome > this problem, but the authors of ESPinUSP proposal use the main > mode in their example. > > regards, > Jayant > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 11 11:22:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BIM1J13115; Mon, 11 Jun 2001 11:22:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02608 Mon, 11 Jun 2001 12:42:52 -0400 (EDT) Reply-To: From: "Sridhar J" To: "Ipsec" Subject: digital certificate Date: Mon, 11 Jun 2001 22:23:07 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Is it a common practise / complusory that a CERTIFICATE AUTHORITY will use the same cryptographic algorithm to sign the certificate for the public key info of a user which it is authenticating ...??? regards, sridhara .j From owner-ipsec@lists.tislabs.com Mon Jun 11 11:42:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BIgtJ13618; Mon, 11 Jun 2001 11:42:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02786 Mon, 11 Jun 2001 13:57:20 -0400 (EDT) Subject: prf's in IKE Phase 2 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Palmatier" Date: Mon, 11 Jun 2001 13:59:56 -0400 X-MIMETrack: Serialize by Router on d27ml103/27/M/IBM(Release 5.0.7 |March 21, 2001) at 06/11/2001 01:00:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question about the prf referenced in RFC 2409 in IKE Quick Mode negotiations. Where does the prf used to create the HASH values and KEYMAT come from? I would think that for HASH(1), HASH(2), and HASH(3) the prf would be the hash algorithm negotiated in Phase 1 and that for the KEYMAT it would be hash algorithm negotiated in this Phase 2 Quick Mode. An example of this would be a Phase 1 where SHA was negotiated and where MD5 is negotiated for the final Phase 2 Quick Mode SA. Then the following calculations would hold: HASH(1) = *SHA*(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ) HASH(2) = *SHA*(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ) HASH(3) = *SHA*(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) KEYMAT = *MD5*(SKEYID_d, protocol | SPI | Ni_b | Nr_b). OR KEYMAT = *MD5*(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) Is this correct? If not, what is the correct way to calculate these and still use the hash algorithm negotiated for this Quick Mode to generate the keying material used by IPsec? Any help would be appreciated. Jason Jason Palmatier iSeries IP Development IBM Corp. Endicott, NY email: palmatie@us.ibm.com From owner-ipsec@lists.tislabs.com Mon Jun 11 11:50:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BIo4J13749; Mon, 11 Jun 2001 11:50:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02779 Mon, 11 Jun 2001 13:56:16 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD758@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" , jshukla Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 11 Jun 2001 13:59:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek and Jayant, What if IKE packet is tunneled by encapsulating the UDP/IP? It seems the ESPoUDP + IKEoUDP (for IPSec) will works fine with NAPT under any circumstance? --- David -----Original Message----- From: Derek Atkins [mailto:warlord@mit.edu] Sent: Monday, June 11, 2001 11:08 AM To: jshukla Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT Ok, yes, there is a problem with using pre-shared keys in main mode. -derek "jshukla" writes: > ----- Original Message ----- > From: "Derek Atkins" > > > HASH_I = pfr(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b) > > > > Um, I don't see anything here that necessarily depends upon the IP > > Address of either Initiator or Responder. Perhaps I am being dense, > > but could you please point out the specific term to which you refer? > > Keep in mind that the ID term is **NOT** necessarily tied to the IP > > Address, as you can use many types of ID (such as FQDN) that are > > "movable". > > > > Isn't there a problem in using pre-shared keys for authentication in > the main mode? The responder uses the IP address to look up the > pre-shared key. Because of NAT, it may not be able to look up the > correct pre-shared key?! If you use aggressive mode, you can overcome > this problem, but the authors of ESPinUSP proposal use the main > mode in their example. > > regards, > Jayant > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 11 12:44:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BJihJ14964; Mon, 11 Jun 2001 12:44:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02892 Mon, 11 Jun 2001 14:32:21 -0400 (EDT) Message-ID: <95D210E03433D51188A60008C71694070111C35C@mn02exch02.adc.com> From: "Riley, Susie" To: Chris Trobridge , Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 11 Jun 2001 10:07:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk if the security box is encrypting everything - traffic destined for the vpn box at the other side, as well as traffic destined for some other site (internet), then all the traffic will end up at the vpn box at the other side, and i'm assuming there would be a router somewhere on the other side's network which will sort out the traffic and route internet destined traffic back out, and keep the locally destined traffic. the isp at the other end connected to the router could then perform nat if necessary. if the security box has more smarts, it can encrypt only the vpn destined traffic and send in the clear the internet destined traffic. in this case, the isp could perform nat on the internet destined traffic (it's not encrypted), and nat on the outer layer of the tunneled traffic (it doesn't care about the inner addresses since it's ending up in the customer's intranet anyway). would these approaches address some of the issues, and are there problems with these approaches that you can see? susie -----Original Message----- From: Chris Trobridge [mailto:CTrobridge@baltimore.com] Sent: Monday, June 11, 2001 9:27 AM To: Riley, Susie; Joern Sierwald; ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT The ISP wants to muck around with the inner addresses to cater for overlapping address ranges between different sites. The trouble is that there have been various cases where ISPs have 'solved' their customer's VPN problem with NAT prior to introducing security. This means they've often used NAT to move datagrams over their network, as well as to avoid overlapping subnets. I've also seen it used for more esoteric purposes. The above illustrates a scenario where the ISP has invested in NAT'ing the customers addresses. When the ISP adds encryptors they expect the existing network to need no change but IPSEC security gateways tunnel and break their model. So the ISP will ask "can you use transport mode?", so they can continue to NAT. However, I'm not convinced this would work as NAT ALGs will still not have access to the TCP/UDP payloads for the application-level NAT. Even without ALG, this would also require the transport headers to be passed in clear. Of course, as the IPSEC SG only needs one external address, there's little point for NAT on the ISP side anymore. And the ISP is still required to provide a transparent solution to the customer but isn't trusted with the security. Chris > -----Original Message----- > From: Riley, Susie [mailto:Susie_Riley@adc.com] > Sent: 11 June 2001 13:23 > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com > Subject: RE: IPSEC Security Gateways & NAT > > > > if you are trying to put an encryption/vpn box between the > customes sites > and the isp, the address assignment by the isp should be for the outer > tunnel address (to be used by the vpn box to tunnel the > traffic). in this > case, as people suggest, esp+udp should work for nat, and > it's the outside > address the isp might muck with - not the inner address > because as far as > the isp is concerned, there's only one box behind it, and that's the > ipsec/vpn box. as far as the isp is concerned all the boxes > behind the > ipsec/vpn box could be using private addresses and it should > not care. can > you describe a scenario where the isp would want to muck with > both inside > and outside addresses in a ipsec/vpn scenario, or are you > talking about a > different scenario altogether? > > susie > > -----Original Message----- > From: Chris Trobridge [mailto:CTrobridge@baltimore.com] > Sent: Thursday, June 07, 2001 10:25 AM > To: Joern Sierwald; ipsec@lists.tislabs.com > Subject: RE: IPSEC Security Gateways & NAT > > > The scenario I'm talking about is where the service provider > wants to NAT > the private addresses, ie the inner addresses if tunnelling. > Obviously this > is completely contrary to the RFCs but ownership/management > issues make it > hard to place the NAT before encryption (when customer > encrypts and service > provider NATs). > > I don't think it can be done but I'm looking for some > consensus or other > evidence on this point. > > Chris > > > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > > and insert a UDP header in front of the ESP header. This is > > dead simple and works with normal NAT boxes. > > > > Problems and solutions: > > > > - some NAT boxes drop fragmented UDP packets. You'll have to > > mess around > > with TCP segment sizes and/or encrypt fragments. > > > > - The NAT box does not affect any protocols, like FTP, > > because it's modifying > > the "outer" IP header and an artifical UDP header. > > > > - There might be address collisions. Two clients might be > > behind firewalls > > and have > > the same address 192.168.98.6. Now they do quick mode to > > the same GW. > > Trouble ahead. You need some NAT here, be it at the GW or > > at the client, > > or private IP address by cfg-mode. Or something. > > > > J-rn > > > > > > This footnote confirms that this email message has been swept by > > MIMEsweeper for the presence of computer viruses. > > > > > -------------------------------------------------------------- > -------------- > ------------------------------------- > The information contained in this message is confidential and > is intended > for the addressee(s) only. If you have received this message > in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this > message is > strictly forbidden. Baltimore Technologies plc will not be liable for > direct, > special, indirect or consequential damages arising from > alteration of the > contents of this message by a third party or as a result of > any virus being > passed on. > > In addition, certain Marketing collateral may be added from > time to time to > promote Baltimore Technologies products, services, Global > e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. > From owner-ipsec@lists.tislabs.com Mon Jun 11 13:52:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BKqBJ16731; Mon, 11 Jun 2001 13:52:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03070 Mon, 11 Jun 2001 15:55:14 -0400 (EDT) Message-ID: <000401c0f2ad$bdb391e0$ebb12304@ffb5b> From: "jshukla" To: "Chen, David" , "'Derek Atkins'" Cc: References: <85D31AAF3DFCD4119C44000102C009707DD758@mail.ellacoya.com> Subject: Re: IPSEC Security Gateways & NAT Date: Mon, 11 Jun 2001 12:35:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Chen, David" To: "'Derek Atkins'" ; "jshukla" Cc: Sent: Monday, June 11, 2001 10:59 AM Subject: RE: IPSEC Security Gateways & NAT > Derek and Jayant, > What if IKE packet is tunneled by encapsulating the UDP/IP? > It seems the ESPoUDP + IKEoUDP (for IPSec) will works fine with NAPT > under any circumstance? > > --- David > Simple awnser is yes, but a whole lot of other work needs to be done. 1) There needs to be a mapping at the receiver (inner IP addresses and port #s to outer IP addresses and port #s). This mapping is used to send the packets back to the initiator. 2) You can reverse the effect of NAT with this mapping and therefore the subsequent packets don't have to have the extra IP/UDP headers. 3) Its a bad idea to just use UDP for encapsulation because you are mapping TCP/UDP services to UDP. This can lead to incompatibility with QoS protocols and will make BITW implementations difficult. There might be problems with routing fragmented packets and ICMP messages. A better solution is to use TCP -> TCP and UDP-> UDP encapsulation. etc. etc. For more information you can read our draft on NAT and QoS compatible end-2-end security. We have a new and more detailed draft coming out soon. regards, Jayant From owner-ipsec@lists.tislabs.com Mon Jun 11 14:11:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BLBWJ17294; Mon, 11 Jun 2001 14:11:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03099 Mon, 11 Jun 2001 16:09:05 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD759@mail.ellacoya.com> From: "Chen, David" To: "'jshukla'" , "Chen, David" , "'Derek Atkins'" Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 11 Jun 2001 16:12:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, It seems works if IKE is encapsulated in an UDP/IP with the same as IKE's original 500/IP at initiator and the responder do not check the outer IP and knows to decapsulate the outer UDP/IP. Extra header consumes bandwidth, but it is signal; therefore, can trade for security through NAPT. For ESPoUDP, it is desirable having maping as TCP->TCP and UDP->UDP and OtherProtocol->OtherProtocol from inner to outer and not just uniformly using UDP. Furthermore, for IP QoS, it seems only DS (TOS byte) is significant for IP packets classification. It also can be copied from inner to outer. It seems, for traverse NAPT securely, the answer is copying all the inner encrypted header to outer (except addresses and checksum)? Regards, --- David -----Original Message----- From: jshukla [mailto:jshukla@earthlink.net] Sent: Monday, June 11, 2001 3:36 PM To: Chen, David; 'Derek Atkins' Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT ----- Original Message ----- From: "Chen, David" To: "'Derek Atkins'" ; "jshukla" Cc: Sent: Monday, June 11, 2001 10:59 AM Subject: RE: IPSEC Security Gateways & NAT > Derek and Jayant, > What if IKE packet is tunneled by encapsulating the UDP/IP? > It seems the ESPoUDP + IKEoUDP (for IPSec) will works fine with NAPT > under any circumstance? > > --- David > Simple awnser is yes, but a whole lot of other work needs to be done. 1) There needs to be a mapping at the receiver (inner IP addresses and port #s to outer IP addresses and port #s). This mapping is used to send the packets back to the initiator. 2) You can reverse the effect of NAT with this mapping and therefore the subsequent packets don't have to have the extra IP/UDP headers. 3) Its a bad idea to just use UDP for encapsulation because you are mapping TCP/UDP services to UDP. This can lead to incompatibility with QoS protocols and will make BITW implementations difficult. There might be problems with routing fragmented packets and ICMP messages. A better solution is to use TCP -> TCP and UDP-> UDP encapsulation. etc. etc. For more information you can read our draft on NAT and QoS compatible end-2-end security. We have a new and more detailed draft coming out soon. regards, Jayant From owner-ipsec@lists.tislabs.com Mon Jun 11 15:11:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BMBpJ18821; Mon, 11 Jun 2001 15:11:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03330 Mon, 11 Jun 2001 17:04:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Mon, 11 Jun 2001 14:08:16 -0700 To: , "Ipsec" From: Paul Hoffman / VPNC Subject: Re: digital certificate Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:23 PM +0530 6/11/01, Sridhar J wrote: > Is it a common practise / complusory that a CERTIFICATE AUTHORITY >will use the same cryptographic algorithm to sign the certificate for the >public key info of a user which it is authenticating ...??? It is common practice but not at all compulsory. At the last bakeoff, a few vendors tested with accepting DSA certs under an RSA root and it worked fine. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Jun 11 19:18:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5C2IAJ24904; Mon, 11 Jun 2001 19:18:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03718 Mon, 11 Jun 2001 21:11:34 -0400 (EDT) Message-ID: From: Chris Trobridge To: "Riley, Susie" , Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Tue, 12 Jun 2001 02:17:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, it doesn't address the problem. The problem is that service providers (rather than ISPs) have provided NAT-based VPNs without any thought of the long-term impact of this on security - and IPSEC in particular. The introduction of IPSEC, in particular, renders 'cheap' NAT solutions ineffective and this leaves the SPs in a spot of bother. Naturally, this gets taken out on the security providers ;-). This is a different problem to the more common one of running NAT on the public SG addresses. The introduction of IPSEC prevents service providers from providing a transparent VPN solution (to a group of conflicting networks) because IPSEC prevents them from manipulating the private addresses with NAT. The best (cheapest) solution is to put NAT on the security gateway but this moves the solution away from them and, presumably, some of their revenue - if only on future contracts. (this is related to the control issue over crypto managment, which is something customers appear to want to retain) Thanks for your attention anyway. I wasn't expecting a solution. I was interested to see if anyone would pop up with a proprietary solution but I think it's beyond even that! Roll on IPv6 and the abandonment of NAT... Chris > -----Original Message----- > From: Riley, Susie [mailto:Susie_Riley@adc.com] > Sent: 11 June 2001 16:08 > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com > Subject: RE: IPSEC Security Gateways & NAT > > > if the security box is encrypting everything - traffic > destined for the vpn > box at the other side, as well as traffic destined for some other site > (internet), then all the traffic will end up at the vpn box > at the other > side, and i'm assuming there would be a router somewhere on > the other side's > network which will sort out the traffic and route internet > destined traffic > back out, and keep the locally destined traffic. the isp at > the other end > connected to the router could then perform nat if necessary. > > if the security box has more smarts, it can encrypt only the > vpn destined > traffic and send in the clear the internet destined traffic. > in this case, > the isp could perform nat on the internet destined traffic (it's not > encrypted), and nat on the outer layer of the tunneled > traffic (it doesn't > care about the inner addresses since it's ending up in the customer's > intranet anyway). > > would these approaches address some of the issues, and are > there problems > with these approaches that you can see? > > susie > > -----Original Message----- > From: Chris Trobridge [mailto:CTrobridge@baltimore.com] > Sent: Monday, June 11, 2001 9:27 AM > To: Riley, Susie; Joern Sierwald; ipsec@lists.tislabs.com > Subject: RE: IPSEC Security Gateways & NAT > > > The ISP wants to muck around with the inner addresses to cater for > overlapping address ranges between different sites. > > The trouble is that there have been various cases where ISPs > have 'solved' > their customer's VPN problem with NAT prior to introducing > security. This > means they've often used NAT to move datagrams over their > network, as well > as to avoid overlapping subnets. I've also seen it used for > more esoteric > purposes. > > The above illustrates a scenario where the ISP has invested > in NAT'ing the > customers addresses. When the ISP adds encryptors they > expect the existing > network to need no change but IPSEC security gateways tunnel > and break their > model. So the ISP will ask "can you use transport mode?", so they can > continue to NAT. However, I'm not convinced this would work > as NAT ALGs > will still not have access to the TCP/UDP payloads for the > application-level > NAT. Even without ALG, this would also require the transport > headers to be > passed in clear. > > Of course, as the IPSEC SG only needs one external address, > there's little > point for NAT on the ISP side anymore. And the ISP is still > required to > provide a transparent solution to the customer but isn't > trusted with the > security. > > Chris > > > -----Original Message----- > > From: Riley, Susie [mailto:Susie_Riley@adc.com] > > Sent: 11 June 2001 13:23 > > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com > > Subject: RE: IPSEC Security Gateways & NAT > > > > > > > > if you are trying to put an encryption/vpn box between the > > customes sites > > and the isp, the address assignment by the isp should be > for the outer > > tunnel address (to be used by the vpn box to tunnel the > > traffic). in this > > case, as people suggest, esp+udp should work for nat, and > > it's the outside > > address the isp might muck with - not the inner address > > because as far as > > the isp is concerned, there's only one box behind it, and that's the > > ipsec/vpn box. as far as the isp is concerned all the boxes > > behind the > > ipsec/vpn box could be using private addresses and it should > > not care. can > > you describe a scenario where the isp would want to muck with > > both inside > > and outside addresses in a ipsec/vpn scenario, or are you > > talking about a > > different scenario altogether? > > > > susie > > > > -----Original Message----- > > From: Chris Trobridge [mailto:CTrobridge@baltimore.com] > > Sent: Thursday, June 07, 2001 10:25 AM > > To: Joern Sierwald; ipsec@lists.tislabs.com > > Subject: RE: IPSEC Security Gateways & NAT > > > > > > The scenario I'm talking about is where the service provider > > wants to NAT > > the private addresses, ie the inner addresses if tunnelling. > > Obviously this > > is completely contrary to the RFCs but ownership/management > > issues make it > > hard to place the NAT before encryption (when customer > > encrypts and service > > provider NATs). > > > > I don't think it can be done but I'm looking for some > > consensus or other > > evidence on this point. > > > > Chris > > > > > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > > > and insert a UDP header in front of the ESP header. This is > > > dead simple and works with normal NAT boxes. > > > > > > Problems and solutions: > > > > > > - some NAT boxes drop fragmented UDP packets. You'll have to > > > mess around > > > with TCP segment sizes and/or encrypt fragments. > > > > > > - The NAT box does not affect any protocols, like FTP, > > > because it's modifying > > > the "outer" IP header and an artifical UDP header. > > > > > > - There might be address collisions. Two clients might be > > > behind firewalls > > > and have > > > the same address 192.168.98.6. Now they do quick mode to > > > the same GW. > > > Trouble ahead. You need some NAT here, be it at the GW or > > > at the client, > > > or private IP address by cfg-mode. Or something. > > > > > > J-rn ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Tue Jun 12 05:08:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CC85J18232; Tue, 12 Jun 2001 05:08:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04814 Tue, 12 Jun 2001 07:07:26 -0400 (EDT) Message-ID: <009701c0f2cd$49a4abc0$c1b12304@ffb5b> From: "jshukla" To: "Chen, David" , "'Derek Atkins'" Cc: References: <85D31AAF3DFCD4119C44000102C009707DD759@mail.ellacoya.com> Subject: Re: IPSEC Security Gateways & NAT Date: Mon, 11 Jun 2001 16:21:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Chen, David" > Jayant, > > It seems works if > IKE is encapsulated in an UDP/IP with the same as IKE's original 500/IP at > initiator and the responder do not check the outer IP and knows to > decapsulate the outer UDP/IP. Yes, but the information from the outer header is needed to redirect the replies properly. > Extra header consumes bandwidth, but it is signal; therefore, can trade for > security through NAPT. > If you do it only for the first packet, then you don't even waste much bandwidth. > For ESPoUDP, > it is desirable having maping as TCP->TCP and UDP->UDP and > OtherProtocol->OtherProtocol from inner to outer and not just uniformly > using > UDP. > Yes, it is desirable to have mapping TCP-> TCP and UDP->UDP, but then it is *no longer* ESPoUDP. For them, it is TCP/UDP->UDP. It is in NGISec that you have TCP->TCP and UDP->UDP. http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible -security-00.txt > Furthermore, for IP QoS, > it seems only DS (TOS byte) is significant for IP packets classification. > It also can be copied from inner to outer. > While DS may be sufficient in some cases, it is highly desirable to have per-flow based QoS. With TCP->TCP and UDP->UDP mapping and the transport layer header visible in the clear, we can support per-flow (application level) based QoS. > It seems, for traverse NAPT securely, the answer is > copying all the inner encrypted header to outer (except addresses and > checksum)? > In short, yes. As long as you have a mechanism for decapsulating the packets with extra headers, generating the mappings from inner headers to outer headers, and using the mappings to redirect the outbound packets appropriately. regards, Jayant > Regards, > > --- David > > > > > -----Original Message----- > From: jshukla [mailto:jshukla@earthlink.net] > Sent: Monday, June 11, 2001 3:36 PM > To: Chen, David; 'Derek Atkins' > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > > ----- Original Message ----- > From: "Chen, David" > To: "'Derek Atkins'" ; "jshukla" > Cc: > Sent: Monday, June 11, 2001 10:59 AM > Subject: RE: IPSEC Security Gateways & NAT > > > > Derek and Jayant, > > What if IKE packet is tunneled by encapsulating the UDP/IP? > > It seems the ESPoUDP + IKEoUDP (for IPSec) will works fine with NAPT > > under any circumstance? > > > > --- David > > > > Simple awnser is yes, but a whole lot of other > work needs to be done. > > > 1) There needs to be a mapping at the > receiver (inner IP addresses and port #s to outer > IP addresses and port #s). This mapping is used > to send the packets back to the initiator. > > 2) You can reverse the effect of NAT with > this mapping and therefore the subsequent packets > don't have to have the extra IP/UDP headers. > > 3) Its a bad idea to just use UDP for encapsulation > because you are mapping TCP/UDP services to > UDP. This can lead to incompatibility with QoS > protocols and will make BITW implementations > difficult. There might be problems with routing > fragmented packets and ICMP messages. > A better solution is to use TCP -> TCP and > UDP-> UDP encapsulation. > > etc. etc. > > For more information you can read our draft on > NAT and QoS compatible end-2-end security. We > have a new and more detailed draft coming out soon. > > regards, > Jayant From owner-ipsec@lists.tislabs.com Tue Jun 12 08:47:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CFldJ05177; Tue, 12 Jun 2001 08:47:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05260 Tue, 12 Jun 2001 10:44:07 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD75C@mail.ellacoya.com> From: "Chen, David" To: "'jshukla'" , "Chen, David" , "'Derek Atkins'" Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Tue, 12 Jun 2001 10:46:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, In the Shukla's draft seems only talking about UDP(inner)->UDP(outer) and TCP->TCP mapping. What to do with other protocols in the IP "protocol" field? It seems to me that, to be simple, all we need is duplicate (not mapping) the original IP's header for tunneling before encrypting the inner IP packet. Afterward, forward this tunneled IP packet to NAT device(s) to reach the peer. If there is no NAT device in between IPSec peers, the tunneling will be redundant. However, we can yet have another IPSec tunneling protocol for signaling to decide if this pair of IPSec peers need tunneling. (if the first received packet's inner SIP is the same as outer SIP...) Regards, --- David -----Original Message----- From: jshukla [mailto:jshukla@earthlink.net] Sent: Monday, June 11, 2001 7:22 PM To: Chen, David; 'Derek Atkins' Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT ----- Original Message ----- From: "Chen, David" > Jayant, > > It seems works if > IKE is encapsulated in an UDP/IP with the same as IKE's original 500/IP at > initiator and the responder do not check the outer IP and knows to > decapsulate the outer UDP/IP. Yes, but the information from the outer header is needed to redirect the replies properly. > Extra header consumes bandwidth, but it is signal; therefore, can trade for > security through NAPT. > If you do it only for the first packet, then you don't even waste much bandwidth. > For ESPoUDP, > it is desirable having maping as TCP->TCP and UDP->UDP and > OtherProtocol->OtherProtocol from inner to outer and not just uniformly > using > UDP. > Yes, it is desirable to have mapping TCP-> TCP and UDP->UDP, but then it is *no longer* ESPoUDP. For them, it is TCP/UDP->UDP. It is in NGISec that you have TCP->TCP and UDP->UDP. http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible -security-00.txt > Furthermore, for IP QoS, > it seems only DS (TOS byte) is significant for IP packets classification. > It also can be copied from inner to outer. > While DS may be sufficient in some cases, it is highly desirable to have per-flow based QoS. With TCP->TCP and UDP->UDP mapping and the transport layer header visible in the clear, we can support per-flow (application level) based QoS. > It seems, for traverse NAPT securely, the answer is > copying all the inner encrypted header to outer (except addresses and > checksum)? > In short, yes. As long as you have a mechanism for decapsulating the packets with extra headers, generating the mappings from inner headers to outer headers, and using the mappings to redirect the outbound packets appropriately. regards, Jayant From owner-ipsec@lists.tislabs.com Tue Jun 12 10:08:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CH8pJ08310; Tue, 12 Jun 2001 10:08:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05572 Tue, 12 Jun 2001 12:02:04 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD75F@mail.ellacoya.com> From: "Chen, David" To: "'jshukla'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: IPSEC Security Gateways & NAT Date: Tue, 12 Jun 2001 12:03:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, I like public opinion, if you don't mind. After tunneling the IPSec's packet, the NAT device will NAT on the outer IP's address. The NAT device does not "see" the payload (IPSec packets). It seems exposing the encrypted IP addresses in the IPSec due it copies the inner address to outer for tunneling and through NAT device. Is this worse secure than "not exposing address and other header information"? Assume anything after SG (or host's w/IPSec) is unsecured communication to NAT device. Regards, --- David -----Original Message----- From: jshukla [mailto:jshukla@earthlink.net] Sent: Tuesday, June 12, 2001 11:54 AM To: Chen, David Subject: Re: IPSEC Security Gateways & NAT ----- Original Message ----- From: "Chen, David" > Jayant, > In the Shukla's draft seems only talking about UDP(inner)->UDP(outer) and > TCP->TCP mapping. > > What to do with other protocols in the IP "protocol" field? > You treat all protocls in the same fashion. > It seems to me that, to be simple, all we need is > duplicate (not mapping) the original IP's header for tunneling before That's what I mean. Except you have to update the length and checksum fields. > encrypting > the inner IP packet. > Afterward, forward this tunneled IP packet to NAT device(s) > to reach the peer. How will the NAT device forward the packet to the peer if the inner IP header is encrypted. I am assuming you want to do peer-2-peer IPSec. We went through all possible configurations, before settling on the one that we have presented in the draft. regards, Jayant From owner-ipsec@lists.tislabs.com Tue Jun 12 11:19:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CIJ2J10895; Tue, 12 Jun 2001 11:19:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05801 Tue, 12 Jun 2001 13:20:03 -0400 (EDT) Message-ID: <3B265142.F95D6D4A@loria.fr> Date: Tue, 12 Jun 2001 19:28:34 +0200 From: brakta Organization: LORIA X-Mailer: Mozilla 4.7 [fr]C-CCK-MCD (WinNT; I) X-Accept-Language: fr, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: mluticast authentication using AH Content-Type: multipart/mixed; boundary="------------9A6F0E3A86E6DF757FCF93D0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Il s'agit d'un message multivolet au format MIME. --------------9A6F0E3A86E6DF757FCF93D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, For multicast communication authentication,communicationone-way hash,algorithms combined with asymmetric signature algorithms are,appropriate.,What is solution of pulic key distribution problem in 1-N model. regards ------------------------------------------ Saber.BRAKTA LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : brakta@loria.fr ------------------------------------------ --------------9A6F0E3A86E6DF757FCF93D0 Content-Type: text/x-vcard; charset=us-ascii; name="brakta.vcf" Content-Transfer-Encoding: 7bit Content-Description: Carte pour brakta Content-Disposition: attachment; filename="brakta.vcf" begin:vcard n:; x-mozilla-html:FALSE adr:;;;;;; version:2.1 end:vcard --------------9A6F0E3A86E6DF757FCF93D0-- From owner-ipsec@lists.tislabs.com Tue Jun 12 11:44:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CIiCJ11742; Tue, 12 Jun 2001 11:44:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05903 Tue, 12 Jun 2001 13:51:47 -0400 (EDT) Message-ID: <001901c0f358$71fe59a0$3cb12304@ffb5b> From: "jshukla" To: "Chris Trobridge" , References: Subject: Re: IPSEC Security Gateways & NAT Date: Tue, 12 Jun 2001 08:57:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Chris Trobridge" > No, it doesn't address the problem. The problem is that service providers > (rather than ISPs) have provided NAT-based VPNs without any thought of the > long-term impact of this on security - and IPSEC in particular. The > introduction of IPSEC, in particular, renders 'cheap' NAT solutions > ineffective and this leaves the SPs in a spot of bother. Naturally, this > gets taken out on the security providers ;-). > > This is a different problem to the more common one of running NAT on the > public SG addresses. > > The introduction of IPSEC prevents service providers from providing a > transparent VPN solution (to a group of conflicting networks) because IPSEC > prevents them from manipulating the private addresses with NAT. The best > (cheapest) solution is to put NAT on the security gateway but this moves the > solution away from them and, presumably, some of their revenue - if only on > future contracts. (this is related to the control issue over crypto > managment, which is something customers appear to want to retain) > What you are looking at is an end-to-end VPN that can traverse through multiple NATs, right? > Thanks for your attention anyway. I wasn't expecting a solution. I was > interested to see if anyone would pop up with a proprietary solution but I We have a solution. > think it's beyond even that! Roll on IPv6 and the abandonment of NAT... > Even if you use IPv6, you run into the same problem when you install a proxy. Can you conclusively say that you will never need to use proxy in IPv6? NAT provides a level of protection from outside scrutiny of your internal network that is very valuable. I don't know if people will be willing to give up NAT even when IPv6 is deployed. regards, Jayant > Chris > > > -----Original Message----- > > From: Riley, Susie [mailto:Susie_Riley@adc.com] > > Sent: 11 June 2001 16:08 > > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com > > Subject: RE: IPSEC Security Gateways & NAT > > > > > > if the security box is encrypting everything - traffic > > destined for the vpn > > box at the other side, as well as traffic destined for some other site > > (internet), then all the traffic will end up at the vpn box > > at the other > > side, and i'm assuming there would be a router somewhere on > > the other side's > > network which will sort out the traffic and route internet > > destined traffic > > back out, and keep the locally destined traffic. the isp at > > the other end > > connected to the router could then perform nat if necessary. > > > > if the security box has more smarts, it can encrypt only the > > vpn destined > > traffic and send in the clear the internet destined traffic. > > in this case, > > the isp could perform nat on the internet destined traffic (it's not > > encrypted), and nat on the outer layer of the tunneled > > traffic (it doesn't > > care about the inner addresses since it's ending up in the customer's > > intranet anyway). > > > > would these approaches address some of the issues, and are > > there problems > > with these approaches that you can see? > > > > susie > > > > -----Original Message----- > > From: Chris Trobridge [mailto:CTrobridge@baltimore.com] > > Sent: Monday, June 11, 2001 9:27 AM > > To: Riley, Susie; Joern Sierwald; ipsec@lists.tislabs.com > > Subject: RE: IPSEC Security Gateways & NAT > > > > > > The ISP wants to muck around with the inner addresses to cater for > > overlapping address ranges between different sites. > > > > The trouble is that there have been various cases where ISPs > > have 'solved' > > their customer's VPN problem with NAT prior to introducing > > security. This > > means they've often used NAT to move datagrams over their > > network, as well > > as to avoid overlapping subnets. I've also seen it used for > > more esoteric > > purposes. > > > > The above illustrates a scenario where the ISP has invested > > in NAT'ing the > > customers addresses. When the ISP adds encryptors they > > expect the existing > > network to need no change but IPSEC security gateways tunnel > > and break their > > model. So the ISP will ask "can you use transport mode?", so they can > > continue to NAT. However, I'm not convinced this would work > > as NAT ALGs > > will still not have access to the TCP/UDP payloads for the > > application-level > > NAT. Even without ALG, this would also require the transport > > headers to be > > passed in clear. > > > > Of course, as the IPSEC SG only needs one external address, > > there's little > > point for NAT on the ISP side anymore. And the ISP is still > > required to > > provide a transparent solution to the customer but isn't > > trusted with the > > security. > > > > Chris > > > > > -----Original Message----- > > > From: Riley, Susie [mailto:Susie_Riley@adc.com] > > > Sent: 11 June 2001 13:23 > > > To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com > > > Subject: RE: IPSEC Security Gateways & NAT > > > > > > > > > > > > if you are trying to put an encryption/vpn box between the > > > customes sites > > > and the isp, the address assignment by the isp should be > > for the outer > > > tunnel address (to be used by the vpn box to tunnel the > > > traffic). in this > > > case, as people suggest, esp+udp should work for nat, and > > > it's the outside > > > address the isp might muck with - not the inner address > > > because as far as > > > the isp is concerned, there's only one box behind it, and that's the > > > ipsec/vpn box. as far as the isp is concerned all the boxes > > > behind the > > > ipsec/vpn box could be using private addresses and it should > > > not care. can > > > you describe a scenario where the isp would want to muck with > > > both inside > > > and outside addresses in a ipsec/vpn scenario, or are you > > > talking about a > > > different scenario altogether? > > > > > > susie > > > > > > -----Original Message----- > > > From: Chris Trobridge [mailto:CTrobridge@baltimore.com] > > > Sent: Thursday, June 07, 2001 10:25 AM > > > To: Joern Sierwald; ipsec@lists.tislabs.com > > > Subject: RE: IPSEC Security Gateways & NAT > > > > > > > > > The scenario I'm talking about is where the service provider > > > wants to NAT > > > the private addresses, ie the inner addresses if tunnelling. > > > Obviously this > > > is completely contrary to the RFCs but ownership/management > > > issues make it > > > hard to place the NAT before encryption (when customer > > > encrypts and service > > > provider NATs). > > > > > > I don't think it can be done but I'm looking for some > > > consensus or other > > > evidence on this point. > > > > > > Chris > > > > > > > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode, > > > > and insert a UDP header in front of the ESP header. This is > > > > dead simple and works with normal NAT boxes. > > > > > > > > Problems and solutions: > > > > > > > > - some NAT boxes drop fragmented UDP packets. You'll have to > > > > mess around > > > > with TCP segment sizes and/or encrypt fragments. > > > > > > > > - The NAT box does not affect any protocols, like FTP, > > > > because it's modifying > > > > the "outer" IP header and an artifical UDP header. > > > > > > > > - There might be address collisions. Two clients might be > > > > behind firewalls > > > > and have > > > > the same address 192.168.98.6. Now they do quick mode to > > > > the same GW. > > > > Trouble ahead. You need some NAT here, be it at the GW or > > > > at the client, > > > > or private IP address by cfg-mode. Or something. > > > > > > > > J-rn > > > -------------------------------------------------------------------------- --------------------------------------- > The information contained in this message is confidential and is intended > for the addressee(s) only. If you have received this message in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this message is > strictly forbidden. Baltimore Technologies plc will not be liable for direct, > special, indirect or consequential damages arising from alteration of the > contents of this message by a third party or as a result of any virus being > passed on. > > In addition, certain Marketing collateral may be added from time to time to > promote Baltimore Technologies products, services, Global e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. From owner-ipsec@lists.tislabs.com Tue Jun 12 15:54:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CMstJ19205; Tue, 12 Jun 2001 15:54:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06287 Tue, 12 Jun 2001 17:42:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20010612144347.04300ab8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 14:46:01 -0700 To: brakta From: Mark Baugher Subject: Re: mluticast authentication using AH Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: <3B265142.F95D6D4A@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I'm not sure what you are asking but I think it's more appropriate to address the msec WG with this question. I'm confused because AH does not support authentication by digital signature but uses a message authentication code. Mark At 07:28 PM 6/12/2001 +0200, brakta wrote: >Hello, >For multicast communication authentication,communicationone-way >hash,algorithms combined with asymmetric signature algorithms >are,appropriate.,What is solution of pulic key distribution problem > in 1-N model. > >regards >------------------------------------------ > Saber.BRAKTA > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : brakta@loria.fr >------------------------------------------ From owner-ipsec@lists.tislabs.com Wed Jun 13 05:17:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DCH3J14529; Wed, 13 Jun 2001 05:17:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07979 Wed, 13 Jun 2001 07:08:50 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 12 Jun 2001 16:34:12 -0600 From: "Hilarie Orman" To: , Cc: , Subject: [MSEC] Re: mluticast authentication using AH 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 SAA06351 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk AH SHOULD HAVE supported authentication with digital signatures. Hilarie >>> Mark Baugher 06/12/01 03:46PM >>> Hi I'm not sure what you are asking but I think it's more appropriate to address the msec WG with this question. I'm confused because AH does not support authentication by digital signature but uses a message authentication code. Mark At 07:28 PM 6/12/2001 +0200, brakta wrote: >Hello, >For multicast communication authentication,communicationone-way >hash,algorithms combined with asymmetric signature algorithms >are,appropriate.,What is solution of pulic key distribution problem > in 1-N model. > >regards >------------------------------------------ > Saber.BRAKTA > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : brakta@loria.fr >------------------------------------------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From owner-ipsec@lists.tislabs.com Wed Jun 13 07:30:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DEUNJ20554; Wed, 13 Jun 2001 07:30:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08491 Wed, 13 Jun 2001 09:27:41 -0400 (EDT) Message-Id: <200106131333.f5DDXJY23927@kebe.east.sun.com> Subject: Re: [MSEC] Re: mluticast authentication using AH In-Reply-To: from Hilarie Orman at "Jun 12, 2001 04:34:12 pm" To: Hilarie Orman Date: Wed, 13 Jun 2001 09:33:19 -0400 (EDT) CC: mbaugher@cisco.com, Saber.Brakta@loria.fr, ipsec@lists.tislabs.com, msec@securemulticast.org From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > AH SHOULD HAVE supported authentication with digital signatures. There's nothing, I believe, about AH that prevents digital signatures from being used. The Authentication Data area can be made up to 1016 bytes (just shy of 8kbits) per 2402. That should be plenty of room for a digital signature. Dan From owner-ipsec@lists.tislabs.com Wed Jun 13 07:33:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DEXeJ20713; Wed, 13 Jun 2001 07:33:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08539 Wed, 13 Jun 2001 09:46:20 -0400 (EDT) To: "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD759@mail.ellacoya.com> From: Derek Atkins Date: 13 Jun 2001 09:52:05 -0400 In-Reply-To: "Chen, David"'s message of "Mon, 11 Jun 2001 16:12:01 -0400" Message-ID: Lines: 124 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Jayant, > > It seems works if > IKE is encapsulated in an UDP/IP with the same as IKE's original 500/IP at > initiator and the responder do not check the outer IP and knows to > decapsulate the outer UDP/IP. > Extra header consumes bandwidth, but it is signal; therefore, can trade for > security through NAPT. I suppose you could use a UDP-in-UDP encapsulation for IKE, but _how_ would the IKE daemon know to do this? The Initiator may not know that it's sitting behind a NAT gateway. How could it? Now, the responder can _tell_ if the initiator is behind a NAT gateway, because the Source IP Address of the incoming packets wont match the contents (assuming the initiator says "my IP Addr is 1.2.3.4" in the IKE messages), or the source port wont be 500 (because it's been translated). At this point the responder can cache the port-num and just use it to send IKE packets back to the originator, just by responding to the source IP/Port in the first packet. Any NAT Gateway worth it's salt will make sure that multiple packets from the same source ip/port to the same dest ip/port will get mapped to the same NAT'ed ip/port, within some time window. > For ESPoUDP, > it is desirable having maping as TCP->TCP and UDP->UDP and > OtherProtocol->OtherProtocol from inner to outer and not just uniformly > using > UDP. There is no such mapping. Where do you think you could even GET one? Consider than in the "normal" IPSec case, all you get through the network is an ESP packet. You don't know what the underlying transport protocol is. So, why are you suggesting that some window be created where one doesn't exist? All UDP is giving you is an address that the NAT box can use to map the ESP between source and destination. The reasons for using UDP are that: 1) UDP is packet-oriented 2) UDP is fairly light-weight 3) UDP can easily be NAT'ed based on source/dest ip/port The problem with trying to NAT ESP is that the uniqueness is based upon 'dest ip/spi' but each 'dest' behind the NAT could use the same SPI. For example, hosts A and B behind NAT-gateway N could both choose SPI 0x01 when talking to correspondant host C. C will 'respond' with packets destined for 'N', but N wont know whether the SPI belongs to A or B. Consider UDP NATing, however. Hosts A and B share UDP port 500 between IKE and ESPoUDP. When they send messages to C, N will translate the source from A/500 and B/500 to, e.g. N/501 and N/502. Then when C responds to N/501, N knows to relay the packet to A/500; when C responds to N/502, N can relay to B/500. I suppose you could also try to put QoS in there somewhere, but you'd be better off solving the "IPSec QoS problem" in general first, because that is a more difficult problem to solve. Once you figure out how to add QoS to IPSec in general, then adding it to EDPoUDP would work exactly the same. Note that there is necessarily no protection on the QoS bits, because there is no way for an intermediate gateway to verify the security. "'jshukla'" writes: > 1) There needs to be a mapping at the > receiver (inner IP addresses and port #s to outer > IP addresses and port #s). This mapping is used > to send the packets back to the initiator. This mapping is really done at the NAT gateway. The endpoints really don't need to be NAT-aware, per se. The endpoints just need to know to respond to the source ip/port instead of automatically responding to port 500. Yes, it should also cache the source ip/port for the particular host, but that's not really much more than it's already doing. > 2) You can reverse the effect of NAT with > this mapping and therefore the subsequent packets > don't have to have the extra IP/UDP headers. This is true of IKE messages, but with IKE messages you don't need an extra header. With ESP, yes, you need the extra header so the NAT box has something to munge that is considered 'unique'. > 3) Its a bad idea to just use UDP for encapsulation > because you are mapping TCP/UDP services to > UDP. This can lead to incompatibility with QoS > protocols and will make BITW implementations > difficult. There might be problems with routing > fragmented packets and ICMP messages. > A better solution is to use TCP -> TCP and > UDP-> UDP encapsulation. HUH? What are you talking about? You are mapping ESP services (a packet-oriented service) to UDP (another packet-oriented service). There is no TCP service here. Or at least none visible to anyone except the security endpoints. As for QoS, as I mentioned above there is a bigger problem of QoS for plain vanilla IPSec. Go solve that first before trying to solve an encapsulated IPSec. > etc. etc. > > For more information you can read our draft on > NAT and QoS compatible end-2-end security. We > have a new and more detailed draft coming out soon. > > regards, > Jayant -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 07:57:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DEvtJ21518; Wed, 13 Jun 2001 07:57:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08618 Wed, 13 Jun 2001 10:05:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010613070758.042d0d10@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 07:08:45 -0700 To: Dan McDonald From: Mark Baugher Subject: Re: [MSEC] Re: mluticast authentication using AH Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: <200106131333.f5DDXJY23927@kebe.east.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > AH SHOULD HAVE supported authentication with digital signatures. > >There's nothing, I believe, about AH that prevents digital signatures from >being used. > >The Authentication Data area can be made up to 1016 bytes (just shy of >8kbits) per 2402. That should be plenty of room for a digital signature. > >Dan How is this signalled? Mark From owner-ipsec@lists.tislabs.com Wed Jun 13 07:59:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DExoJ21623; Wed, 13 Jun 2001 07:59:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08632 Wed, 13 Jun 2001 10:08:37 -0400 (EDT) Message-Id: <200106131414.f5DEEOo24149@kebe.east.sun.com> Subject: Re: [MSEC] Re: mluticast authentication using AH In-Reply-To: <4.3.2.7.2.20010613070758.042d0d10@mira-sjc5-6.cisco.com> from Mark Baugher at "Jun 13, 2001 07:08:45 am" To: Mark Baugher Date: Wed, 13 Jun 2001 10:14:24 -0400 (EDT) CC: Dan McDonald , ipsec@lists.tislabs.com, msec@securemulticast.org From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > AH SHOULD HAVE supported authentication with digital signatures. > > > >There's nothing, I believe, about AH that prevents digital signatures from > >being used. > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > >Dan > > How is this signalled? It's part of the IPsec Security Association data. Per 2401, an SA is indexed by the tuple . When you add the appropriate SA, you get all sorts of data, including the algorithm. All one would need to do is write a new "algorithm document" for using a digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) I could easily prototype one in Solaris. Dan From owner-ipsec@lists.tislabs.com Wed Jun 13 08:05:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DF5sJ21793; Wed, 13 Jun 2001 08:05:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08663 Wed, 13 Jun 2001 10:16:23 -0400 (EDT) Message-ID: <3B27777F.B50C8FB3@loria.fr> Date: Wed, 13 Jun 2001 16:23:59 +0200 From: brakta Organization: LORIA X-Mailer: Mozilla 4.7 [fr]C-CCK-MCD (WinNT; I) X-Accept-Language: fr, en MIME-Version: 1.0 To: msec@securemulticast.org, ipsec@lists.tislabs.com Subject: The use HMAC Content-Type: multipart/mixed; boundary="------------80E2285FC057F651A21F5F76" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Il s'agit d'un message multivolet au format MIME. --------------80E2285FC057F651A21F5F76 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Mechanisms that provide such integrity check based on a secret key are usually called "message authentication codes" (MAC). Typically, message authentication codes are used between (two parties) that share a secret key in order to validate information transmitted between these parties. Can i use "message authentification codes" between more than two parties, i mean in multicast application, specially 1- N mode ? -- ------------------------------------------ Saber.BRAKTA LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : brakta@loria.fr ------------------------------------------ --------------80E2285FC057F651A21F5F76 Content-Type: text/x-vcard; charset=us-ascii; name="brakta.vcf" Content-Transfer-Encoding: 7bit Content-Description: Carte pour brakta Content-Disposition: attachment; filename="brakta.vcf" begin:vcard n:; x-mozilla-html:FALSE adr:;;;;;; version:2.1 end:vcard --------------80E2285FC057F651A21F5F76-- From owner-ipsec@lists.tislabs.com Wed Jun 13 08:49:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DFntJ27222; Wed, 13 Jun 2001 08:49:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08949 Wed, 13 Jun 2001 10:50:31 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD764@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" , "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 13 Jun 2001 10:53:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, The idea of tunneling IKE by using UDP/IP will required the IPSec's IKE daemon change. In order to traverse any number of NAPT-GW between the initiator and responder, the initiator and responder have to encapsulate, de-capsulate the outer UDP/IP header fore process today's IKE packet. An example will be like this: Let's say, for today's IKE exchange, the address are assigned as following: (without NAT) Laptop <========> SG 100.10.10.49/500 <=========> 100.10.10.1/500 For tunneling IKE's IP packet through UDP/IP, the IP header (SIP->DIP) will looks like: ((100.10.10.49/500->100.10.10.1/500)100.10.10.49/500->100.10.10.1/500) from Laptop to SG. (yes, redundancy) If one directionally NAT exists between the Laptop and Home-SG: Let's say, Laptop was assigned 10.0.1.1, NAT-GW is 10.10.10.1 and Home-SG is 100.10.10.1, Laptop<->NAT-GW<=====>Home-SG 1) From Laptop to NAT ((100.10.10.49/500->100.10.10.1/500) 10.0.1.1/500->100.10.10.1/500) from NAT to SG ((100.10.10.49/500->100.10.10.1/500) 10.10.10.1/4999->100.10.10.1/500) 2)From SG to NAT ((100.10.10.1/500->100.10.10.49/500) 100.10.10.1/500->10.10.10.1/4999) From NAT to Laptop ((100.10.10.1/500->100.10.10.49/500) 100.10.10.1/500->10.0.1.1/500) Similarly, this scheme still can do IKE even another NAT in between NAT-GW and Home-SG for bi-directional NAT. In this case, the Laptop's inner IP address (100.10.10.49) are not reachable. It's function is simply an 32 bit id to get the correct "pass phrase". However, it can traverse all NATs in the path. For other IPSec packets, The UDP->UDP and TCP->TCP mapping, I mean the IPSec packet originator will copy the inner UDP/TCP/protocol to outer UDP/TCP/protocol before encryption. (slightly different of tunnel mode) The mapping along with IP's TOS field will help the applications (in a DS domain) use IPSec tunnel without changing the applications packets QoS classification. If the outer DS different inner DS (which is encrypted), it requires the DS domain crossing. Otherwise, for different class of encrypted flows will be using same (or arbitrary ) DS class. Looks like the ESPoUDP is inserting UDP in the IPSec packets? Then, there will be no mapping due to the inner IP header have been encrypted. Thanks for clarifying the ESPoUDP. Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Wednesday, June 13, 2001 9:52 AM To: Chen, David Cc: 'jshukla'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "Chen, David" writes: > Jayant, > > It seems works if > IKE is encapsulated in an UDP/IP with the same as IKE's original 500/IP at > initiator and the responder do not check the outer IP and knows to > decapsulate the outer UDP/IP. > Extra header consumes bandwidth, but it is signal; therefore, can trade for > security through NAPT. I suppose you could use a UDP-in-UDP encapsulation for IKE, but _how_ would the IKE daemon know to do this? The Initiator may not know that it's sitting behind a NAT gateway. How could it? Now, the responder can _tell_ if the initiator is behind a NAT gateway, because the Source IP Address of the incoming packets wont match the contents (assuming the initiator says "my IP Addr is 1.2.3.4" in the IKE messages), or the source port wont be 500 (because it's been translated). At this point the responder can cache the port-num and just use it to send IKE packets back to the originator, just by responding to the source IP/Port in the first packet. Any NAT Gateway worth it's salt will make sure that multiple packets from the same source ip/port to the same dest ip/port will get mapped to the same NAT'ed ip/port, within some time window. > For ESPoUDP, > it is desirable having maping as TCP->TCP and UDP->UDP and > OtherProtocol->OtherProtocol from inner to outer and not just uniformly > using > UDP. There is no such mapping. Where do you think you could even GET one? Consider than in the "normal" IPSec case, all you get through the network is an ESP packet. You don't know what the underlying transport protocol is. So, why are you suggesting that some window be created where one doesn't exist? All UDP is giving you is an address that the NAT box can use to map the ESP between source and destination. The reasons for using UDP are that: 1) UDP is packet-oriented 2) UDP is fairly light-weight 3) UDP can easily be NAT'ed based on source/dest ip/port The problem with trying to NAT ESP is that the uniqueness is based upon 'dest ip/spi' but each 'dest' behind the NAT could use the same SPI. For example, hosts A and B behind NAT-gateway N could both choose SPI 0x01 when talking to correspondant host C. C will 'respond' with packets destined for 'N', but N wont know whether the SPI belongs to A or B. Consider UDP NATing, however. Hosts A and B share UDP port 500 between IKE and ESPoUDP. When they send messages to C, N will translate the source from A/500 and B/500 to, e.g. N/501 and N/502. Then when C responds to N/501, N knows to relay the packet to A/500; when C responds to N/502, N can relay to B/500. I suppose you could also try to put QoS in there somewhere, but you'd be better off solving the "IPSec QoS problem" in general first, because that is a more difficult problem to solve. Once you figure out how to add QoS to IPSec in general, then adding it to EDPoUDP would work exactly the same. Note that there is necessarily no protection on the QoS bits, because there is no way for an intermediate gateway to verify the security. "'jshukla'" writes: > 1) There needs to be a mapping at the > receiver (inner IP addresses and port #s to outer > IP addresses and port #s). This mapping is used > to send the packets back to the initiator. This mapping is really done at the NAT gateway. The endpoints really don't need to be NAT-aware, per se. The endpoints just need to know to respond to the source ip/port instead of automatically responding to port 500. Yes, it should also cache the source ip/port for the particular host, but that's not really much more than it's already doing. > 2) You can reverse the effect of NAT with > this mapping and therefore the subsequent packets > don't have to have the extra IP/UDP headers. This is true of IKE messages, but with IKE messages you don't need an extra header. With ESP, yes, you need the extra header so the NAT box has something to munge that is considered 'unique'. > 3) Its a bad idea to just use UDP for encapsulation > because you are mapping TCP/UDP services to > UDP. This can lead to incompatibility with QoS > protocols and will make BITW implementations > difficult. There might be problems with routing > fragmented packets and ICMP messages. > A better solution is to use TCP -> TCP and > UDP-> UDP encapsulation. HUH? What are you talking about? You are mapping ESP services (a packet-oriented service) to UDP (another packet-oriented service). There is no TCP service here. Or at least none visible to anyone except the security endpoints. As for QoS, as I mentioned above there is a bigger problem of QoS for plain vanilla IPSec. Go solve that first before trying to solve an encapsulated IPSec. > etc. etc. > > For more information you can read our draft on > NAT and QoS compatible end-2-end security. We > have a new and more detailed draft coming out soon. > > regards, > Jayant -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 09:17:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DGHgJ27961; Wed, 13 Jun 2001 09:17:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09209 Wed, 13 Jun 2001 11:30:39 -0400 (EDT) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.34760.816323.352672@gargle.gargle.HOWL> Date: Wed, 13 Jun 2001 08:33:28 -0700 (PDT) To: Dan McDonald Cc: Mark Baugher , Dan McDonald , ipsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: [MSEC] Re: mluticast authentication using AH In-Reply-To: <200106131414.f5DEEOo24149@kebe.east.sun.com> References: <4.3.2.7.2.20010613070758.042d0d10@mira-sjc5-6.cisco.com> <200106131414.f5DEEOo24149@kebe.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 3) "Acadia" XEmacs Lucid X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS( ybD%5 > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > >There's nothing, I believe, about AH that prevents digital signatures from > > >being used. > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > > > >Dan > > > > How is this signalled? > > It's part of the IPsec Security Association data. Per 2401, an SA is indexed > by the tuple . When you add the appropriate > SA, you get all sorts of data, including the algorithm. > > All one would need to do is write a new "algorithm document" for using a > digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) > I could easily prototype one in Solaris. Yep. This is doable. But, I would advise against it. It would require some kind of higher math (bignum, ecc, etc) on every packet. Someone could very easily start forging packets and bring pretty much any machine ever made to a halt. But, it would make key exchange unnecessary, so it could be worth trying. chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these From owner-ipsec@lists.tislabs.com Wed Jun 13 09:18:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DGIOJ27992; Wed, 13 Jun 2001 09:18:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09172 Wed, 13 Jun 2001 11:24:48 -0400 (EDT) To: "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD764@mail.ellacoya.com> From: Derek Atkins Date: 13 Jun 2001 11:30:38 -0400 In-Reply-To: "Chen, David"'s message of "Wed, 13 Jun 2001 10:53:20 -0400" Message-ID: Lines: 96 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Derek, > The idea of tunneling IKE by using UDP/IP will required the IPSec's IKE > daemon change. > In order to traverse any number of NAPT-GW between the initiator and > responder, > the initiator and responder have to encapsulate, de-capsulate the outer > UDP/IP header > fore process today's IKE packet. I still don't understand why you need to tunnel IKE (which is already UDP) in another UDP datagram. And I don't agree that there is any encapsulation/decapsulation required here. The only requirement I see is bi-directional reachability. There is no requirement that an endpoint know the _actual_ ip address of the other endpoint. > An example will be like this: > > Let's say, for today's IKE exchange, the address are assigned as following: > (without NAT) > Laptop <========> SG > 100.10.10.49/500 <=========> 100.10.10.1/500 Ok. I agree with this. With a direct connection you need no encapsulation. > If one directionally NAT exists between the Laptop and Home-SG: > Let's say, Laptop was assigned 10.0.1.1, NAT-GW is 10.10.10.1 and > Home-SG > is 100.10.10.1, Laptop<->NAT-GW<=====>Home-SG This is easy without any encapuluation. Let's assume the NAT-GW has an EXTERNAL address of 1.2.3.4 (the internal address is, as you said, 10.10.10.1). Using your terminology: 1) from Laptop to NAT 10.10.10.49/500->100.10.10.1/500 from NAT to SG 1.2.3.4/4999->100.10.10.1/500 As you can see, the packet makes it to the SG without any problems. No, the SG doesn't know the IP address of the original source, but that's ok. Just don't use IP-address-based names. Yes, this means that the 'pre-shared static keys' authentication transform must be changed, but it should be changed for other reasons too (I wont go into that in the message). 2) from the SG to NAT: 100.10.10.1/500->1.2.3.4/4999 from NAT to Laptop 100.10.10.1/500->10.10.10.49/500 > Similarly, this scheme still can do IKE even another NAT in between > NAT-GW and Home-SG for bi-directional NAT. I'd like to see this example spelled out. If the responder is behind a NAT, there has to be some way to address it from the 'outside'. Could you please show this example fully? So far I see no need to any extra IKE encapsulation. Perhaps this variant may show the necessity, but until I see an example of how it would work (and how the endpoints are addressed) then I don't believe it. > For other IPSec packets, > > The UDP->UDP and TCP->TCP mapping, I mean the IPSec packet originator > will copy the inner UDP/TCP/protocol to outer UDP/TCP/protocol before > encryption. (slightly different of tunnel mode) There are no 'UDP' or 'TCP' IPSec packets. There is only ESP. What's below the ESP can be anything, and you just don't know. You shouldn't know. You shouldn't care. Again, I don't see why you need to do this. It's extra work, extra bytes, and IMHO no benefit. > Looks like the ESPoUDP is inserting UDP in the IPSec packets? > Then, there will be no mapping due to the inner IP header have been > encrypted. > > Thanks for clarifying the ESPoUDP. Yes, an ESPoUDP packet basically looks like this: | | So, you have the raw IP header, than the UDP header, and then the ESP Header and Data. I don't know exactly how it is specified, but I would suppose that the ESP (header + data) is really just carried along as the data portion of the UDP packet. Others may disagree :) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 09:36:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DGapJ28512; Wed, 13 Jun 2001 09:36:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09275 Wed, 13 Jun 2001 11:53:59 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD766@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" , "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 13 Jun 2001 11:56:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, My explanation: 1. IKE Problem: 1) Today's IKE using UDP/IP to exchnage packet. 2) It can not traverse through NAPT device due to the addresses are used for ID (and protected) and the addresses/ports are changed by the NAPT device. Solution: The idea to use yet another UDP/IP header is to shied the IKE packet from NAPT device. It will require the IKE deamon to encapsulate/de-encapsulate the outer UDP/IP header before processing today's IKE packets. If no NAPT device in between IPSec peers, it will be redundant. 2. IPSec data channel: The packet's format is: IPHeader, Transport header, AH, ESP, IP Header, IP payload. It constructs this packet (with header mapping) at the time of encryption, not after ESP is done. Regards, --- David From owner-ipsec@lists.tislabs.com Wed Jun 13 10:08:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DH83J29500; Wed, 13 Jun 2001 10:08:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09323 Wed, 13 Jun 2001 12:18:36 -0400 (EDT) To: "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD766@mail.ellacoya.com> From: Derek Atkins Date: 13 Jun 2001 12:24:28 -0400 In-Reply-To: "Chen, David"'s message of "Wed, 13 Jun 2001 11:56:51 -0400" Message-ID: Lines: 81 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Derek, > > My explanation: > 1. IKE > Problem: > 1) Today's IKE using UDP/IP to exchnage packet. > 2) It can not traverse through NAPT device due to the > addresses are used for ID (and protected) and > the addresses/ports are changed by the NAPT device. > > Solution: > The idea to use yet another UDP/IP header is to shied the IKE packet from > NAPT device. > It will require the IKE deamon to encapsulate/de-encapsulate the outer > UDP/IP header before > processing today's IKE packets. Would it not be easier to change the IKE naming procedures so that the endpoint identifiers are not necessarily tied to the actual source IP Address of the packets? Wouldn't that make more sense and require fewer changes overall? I agree that it is a problem that the IKE ID is tied to the source and destinatin IP address. Currently, however, the __ONLY__ time there is this particular problem is when using pre-shared static keys for authentication. Well, first, I would suggest people not use pre-shared static keys. That suggestion notwithstanding, wouldn't it be better if this problem was fixed completely, so that pre-shared static keys are _NOT_ tied to the IP Source Address? > 2. IPSec data channel: > The packet's format is: > IPHeader, Transport header, AH, ESP, IP Header, IP payload. > It constructs this packet (with header mapping) at the time of encryption, > not after ESP is done. Remember, with normal ESP/AH, there _IS_ no transport header. With normal IPSec you have: Any transport header is encrypted. Copying that transport header would be a breach in security. ESPoUDP, however, adds a UDP header up front _AFTER_ encryption, in order to give the NAT box something to change. Therefore, you get: The header just says src/dest ports 500/500 so the NAT gateway has something with which to munge between the IPSec Peers. Again, this _CAN_ be added after encryption with no ills. The only problem with this approach is if both the initiator and responder are behind a NAT. However, in that situation you would need some a-priori knowledge in order for the initiator to address a packet such that it will reach the responder (hense my requirement for reachability). This implies that UDP port 500 on the NAT box must forward to the IPSec SG behind it in order to meet the reachability requirement. So, if we fix the 'pre-shared static keys require source/dest ip address matching' problem, we fix this case as well. So, let's fix the problem in IKE that pre-shared static keys require the source/dest ip address to match. Then we don't need any of this double encapsulation of IKE, and simple UDP encapsulation of ESP continues to work. > Regards, > > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 12:16:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DJGNJ03568; Wed, 13 Jun 2001 12:16:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09600 Wed, 13 Jun 2001 14:12:54 -0400 (EDT) From: "sankar ramamoorthi" To: "Derek Atkins" , "Chen, David" Cc: "'jshukla'" , Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 13 Jun 2001 11:24:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: owner-ipsec@lists.tislabs.com on behalf of Derek Atkins >[warlord@mit.edu] >Sent: Wednesday, June 13, 2001 8:31 AM >To: Chen, David >Cc: 'jshukla'; ipsec@lists.tislabs.com >Subject: Re: IPSEC Security Gateways & NAT > >"Chen, David" writes: > >> Derek, >> The idea of tunneling IKE by using UDP/IP will required the IPSec's IKE >> daemon change. >> In order to traverse any number of NAPT-GW between the initiator and >> responder, >> the initiator and responder have to encapsulate, de-capsulate the outer >> UDP/IP header >> fore process today's IKE packet. > >I still don't understand why you need to tunnel IKE (which is already >UDP) in another UDP datagram. And I don't agree that there is any >encapsulation/decapsulation required here. The only requirement I see >is bi-directional reachability. There is no requirement that an >endpoint know the _actual_ ip address of the other endpoint. > >> An example will be like this: >> >> Let's say, for today's IKE exchange, the address are assigned as following: >> (without NAT) >> Laptop <========> SG >> 100.10.10.49/500 <=========> 100.10.10.1/500 > >Ok. I agree with this. With a direct connection you need no >encapsulation. > >> If one directionally NAT exists between the Laptop and Home-SG: >> Let's say, Laptop was assigned 10.0.1.1, NAT-GW is 10.10.10.1 and >> Home-SG > is 100.10.10.1, Laptop<->NAT-GW<=====>Home-SG > >This is easy without any encapuluation. Let's assume the NAT-GW has >an EXTERNAL address of 1.2.3.4 (the internal address is, as you said, >10.10.10.1). Using your terminology: > >1) from Laptop to NAT > 10.10.10.49/500->100.10.10.1/500 > from NAT to SG > 1.2.3.4/4999->100.10.10.1/500 > >As you can see, the packet makes it to the SG without any problems. >No, the SG doesn't know the IP address of the original source, but >that's ok. Just don't use IP-address-based names. Yes, this means >that the 'pre-shared static keys' authentication transform must be >changed, but it should be changed for other reasons too (I wont go >into that in the message). > Agree with you here. I too can not see why tunneling is required for IKE. Aggressive-mode or base-mode with non-ip identifiers seems to take care of this problem. Main-mode with certificate is also possible but you have to play tricks like accepting the SA proposal blindly and waiting till ID payload processing to actually checking whether the accepted proposal matches policy. -- sankar -- From owner-ipsec@lists.tislabs.com Wed Jun 13 12:46:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DJkCJ05168; Wed, 13 Jun 2001 12:46:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09682 Wed, 13 Jun 2001 14:56:58 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD767@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 13 Jun 2001 14:59:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Agree, it seems a good idea to abolish pre-shared key in IKE. (then, no NAPT issue) However, the pre-shared key's advantage is more effective to against DOS attack comparing to "generating prime numbers" or "check certificate revocation". Maybe MD5+DH key exchange in the first pair of transaction can prevent DOS attack and establish a secure channel for key exchange? As for ESPoUDP, it seams able to traverse NAPT device as long as it is not AH tunnel mode that protects the tunnel header (but it does not have ESP anyway). Although, it still does not fix the QoS issue. If ESPoUDP(500) can expand to ESPoTCP(500)(less secure) and copy the inner TOS value to the outer IP, it will be more popular? Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@mit.edu] Sent: Wednesday, June 13, 2001 12:24 PM To: Chen, David Cc: 'jshukla'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "Chen, David" writes: > Derek, > > My explanation: > 1. IKE > Problem: > 1) Today's IKE using UDP/IP to exchnage packet. > 2) It can not traverse through NAPT device due to the > addresses are used for ID (and protected) and > the addresses/ports are changed by the NAPT device. > > Solution: > The idea to use yet another UDP/IP header is to shied the IKE packet from > NAPT device. > It will require the IKE deamon to encapsulate/de-encapsulate the outer > UDP/IP header before > processing today's IKE packets. Would it not be easier to change the IKE naming procedures so that the endpoint identifiers are not necessarily tied to the actual source IP Address of the packets? Wouldn't that make more sense and require fewer changes overall? I agree that it is a problem that the IKE ID is tied to the source and destinatin IP address. Currently, however, the __ONLY__ time there is this particular problem is when using pre-shared static keys for authentication. Well, first, I would suggest people not use pre-shared static keys. That suggestion notwithstanding, wouldn't it be better if this problem was fixed completely, so that pre-shared static keys are _NOT_ tied to the IP Source Address? > 2. IPSec data channel: > The packet's format is: > IPHeader, Transport header, AH, ESP, IP Header, IP payload. > It constructs this packet (with header mapping) at the time of encryption, > not after ESP is done. Remember, with normal ESP/AH, there _IS_ no transport header. With normal IPSec you have: Any transport header is encrypted. Copying that transport header would be a breach in security. ESPoUDP, however, adds a UDP header up front _AFTER_ encryption, in order to give the NAT box something to change. Therefore, you get: The header just says src/dest ports 500/500 so the NAT gateway has something with which to munge between the IPSec Peers. Again, this _CAN_ be added after encryption with no ills. The only problem with this approach is if both the initiator and responder are behind a NAT. However, in that situation you would need some a-priori knowledge in order for the initiator to address a packet such that it will reach the responder (hense my requirement for reachability). This implies that UDP port 500 on the NAT box must forward to the IPSec SG behind it in order to meet the reachability requirement. So, if we fix the 'pre-shared static keys require source/dest ip address matching' problem, we fix this case as well. So, let's fix the problem in IKE that pre-shared static keys require the source/dest ip address to match. Then we don't need any of this double encapsulation of IKE, and simple UDP encapsulation of ESP continues to work. > Regards, > > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 12:48:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DJm4J05245; Wed, 13 Jun 2001 12:48:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09734 Wed, 13 Jun 2001 15:07:14 -0400 (EDT) Message-Id: <200106131903.f5DJ39c01029@dharkins@lounge.orgatty.lounge.org> To: Derek Atkins Cc: "Chen, David" , "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: Your message of "13 Jun 2001 12:24:28 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1026.992458989.1@lounge.org> Date: Wed, 13 Jun 2001 12:03:09 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 13 Jun 2001 12:24:28 EDT you wrote > > I agree that it is a problem that the IKE ID is tied to the source and > destinatin IP address. Currently, however, the __ONLY__ time there is > this particular problem is when using pre-shared static keys for > authentication. Well, first, I would suggest people not use > pre-shared static keys. That suggestion notwithstanding, wouldn't it > be better if this problem was fixed completely, so that pre-shared > static keys are _NOT_ tied to the IP Source Address? The reason it was done that way is that there was a desire to force the keys to contain something known only by the peers (which is why signature mode was described as "the least secure"). There was also a requirement for identity protection. Those two combined to give us what we have today. You need to get the pre-shared secret to use to derive a key to protect the identity which is used to find the pre-shared key. That wouldn't work so the key is bound to all you can know at that time-- the IP address. Actually, using ID_KEYID identity and Aggressive Mode can give you identity protection (since the keyid can be any opaque blob) with pre-shared keys but that's really not an elegant solution. Provided that the Diffie-Hellman is authenticated I guess we could say that the resultant secret is something known only by the parties to the exchange and therefore having g^xy (and not the pre-shared key) is good enough. But I'm not a cryptographer and I didn't come up with the key derivation. I'm all for simplifying and unifying SKEYID generation. Are there any comments on this proposal? Hugo, are you out there? Dan. From owner-ipsec@lists.tislabs.com Wed Jun 13 13:20:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DKKRJ06293; Wed, 13 Jun 2001 13:20:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09775 Wed, 13 Jun 2001 15:22:08 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD768@mail.ellacoya.com> From: "Chen, David" To: "'Dan Harkins'" , Derek Atkins Cc: "Chen, David" , "'jshukla'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 13 Jun 2001 15:24:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Preshared key seem more effective against DOS attack comparing to "generating prime number" or "check certificate revocation"? Regards, --- David -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Wednesday, June 13, 2001 3:03 PM To: Derek Atkins Cc: Chen, David; 'jshukla'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT On 13 Jun 2001 12:24:28 EDT you wrote > > I agree that it is a problem that the IKE ID is tied to the source and > destinatin IP address. Currently, however, the __ONLY__ time there is > this particular problem is when using pre-shared static keys for > authentication. Well, first, I would suggest people not use > pre-shared static keys. That suggestion notwithstanding, wouldn't it > be better if this problem was fixed completely, so that pre-shared > static keys are _NOT_ tied to the IP Source Address? The reason it was done that way is that there was a desire to force the keys to contain something known only by the peers (which is why signature mode was described as "the least secure"). There was also a requirement for identity protection. Those two combined to give us what we have today. You need to get the pre-shared secret to use to derive a key to protect the identity which is used to find the pre-shared key. That wouldn't work so the key is bound to all you can know at that time-- the IP address. Actually, using ID_KEYID identity and Aggressive Mode can give you identity protection (since the keyid can be any opaque blob) with pre-shared keys but that's really not an elegant solution. Provided that the Diffie-Hellman is authenticated I guess we could say that the resultant secret is something known only by the parties to the exchange and therefore having g^xy (and not the pre-shared key) is good enough. But I'm not a cryptographer and I didn't come up with the key derivation. I'm all for simplifying and unifying SKEYID generation. Are there any comments on this proposal? Hugo, are you out there? Dan. From owner-ipsec@lists.tislabs.com Wed Jun 13 13:49:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DKn8J07378; Wed, 13 Jun 2001 13:49:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09841 Wed, 13 Jun 2001 15:56:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Content-Class: urn:content-classes:message Subject: MTU and IPSec VPN's MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F444.601714BC" Date: Wed, 13 Jun 2001 13:06:47 -0700 Message-ID: <4EBB5C35607E7F48B4AE162D956666EF338FC3@guam.corp.axcelerant.com> Thread-Topic: IPSEC Security Gateways & NAT thread-index: AcD0OaCLJ8n2L5tCSiaWtY4zDm0I5wACPhlQ From: "Christopher Gripp" To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0F444.601714BC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When using various vendor implementations of IPSec (RedCreek and Cisco to name a couple) we have run across an issue where the MTU must be changed on the PCs and/or servers for certain traffic (Outlook/Exchange, certain WWW pages) to flow through the VPN. The problem is with large datagrams that need to be fragmented for the IPSec overhead to be added. Lowering the MTU on the PC, for instance, to ~1492 alleviates these issues. However the proposition of hacking the registry of 10,000 windows machines is at best ugly. Is there something in the vendor implementation that can be changed? Is it an RFC compliancy issue? Or is this strictly a system configuration issue with the nodes involved. ------_=_NextPart_001_01C0F444.601714BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MTU and IPSec VPN's

When using various vendor implementations of IPSec = (RedCreek and Cisco to name a couple) we have run across an issue where = the MTU must be changed on the PCs and/or servers for certain traffic = (Outlook/Exchange, certain WWW pages) to flow through the = VPN.

The problem is with large datagrams that need to be = fragmented for the IPSec overhead to be added.

Lowering the MTU on the PC, for instance, to ~1492 = alleviates these issues.

However the proposition of hacking the registry of = 10,000 windows machines is at best ugly.

Is there something in the vendor implementation that = can be changed?  Is it an RFC compliancy issue?  Or is this = strictly a system configuration issue with the nodes = involved.

------_=_NextPart_001_01C0F444.601714BC-- From owner-ipsec@lists.tislabs.com Wed Jun 13 13:57:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DKvnJ07663; Wed, 13 Jun 2001 13:57:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09875 Wed, 13 Jun 2001 16:13:48 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 13 Jun 2001 13:35:16 -0600 From: "Hilarie Orman" To: , Cc: Subject: Re: IPSEC Security Gateways & NAT 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 PAA09802 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I feel that it would be a mistake to fix pre-shared static keys. They were meant to bootstrap initial adoption of IKE and should be allowed to die a natural death from disuse. Hilarie >>> Derek Atkins 06/13/01 10:24AM >>> "Chen, David" writes: > Derek, > > My explanation: > 1. IKE > Problem: > 1) Today's IKE using UDP/IP to exchnage packet. > 2) It can not traverse through NAPT device due to the > addresses are used for ID (and protected) and > the addresses/ports are changed by the NAPT device. > > Solution: > The idea to use yet another UDP/IP header is to shied the IKE packet from > NAPT device. > It will require the IKE deamon to encapsulate/de-encapsulate the outer > UDP/IP header before > processing today's IKE packets. Would it not be easier to change the IKE naming procedures so that the endpoint identifiers are not necessarily tied to the actual source IP Address of the packets? Wouldn't that make more sense and require fewer changes overall? I agree that it is a problem that the IKE ID is tied to the source and destinatin IP address. Currently, however, the __ONLY__ time there is this particular problem is when using pre-shared static keys for authentication. Well, first, I would suggest people not use pre-shared static keys. That suggestion notwithstanding, wouldn't it be better if this problem was fixed completely, so that pre-shared static keys are _NOT_ tied to the IP Source Address? > 2. IPSec data channel: > The packet's format is: > IPHeader, Transport header, AH, ESP, IP Header, IP payload. > It constructs this packet (with header mapping) at the time of encryption, > not after ESP is done. Remember, with normal ESP/AH, there _IS_ no transport header. With normal IPSec you have: Any transport header is encrypted. Copying that transport header would be a breach in security. ESPoUDP, however, adds a UDP header up front _AFTER_ encryption, in order to give the NAT box something to change. Therefore, you get: The header just says src/dest ports 500/500 so the NAT gateway has something with which to munge between the IPSec Peers. Again, this _CAN_ be added after encryption with no ills. The only problem with this approach is if both the initiator and responder are behind a NAT. However, in that situation you would need some a-priori knowledge in order for the initiator to address a packet such that it will reach the responder (hense my requirement for reachability). This implies that UDP port 500 on the NAT box must forward to the IPSec SG behind it in order to meet the reachability requirement. So, if we fix the 'pre-shared static keys require source/dest ip address matching' problem, we fix this case as well. So, let's fix the problem in IKE that pre-shared static keys require the source/dest ip address to match. Then we don't need any of this double encapsulation of IKE, and simple UDP encapsulation of ESP continues to work. > Regards, > > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 13:58:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DKwRJ07696; Wed, 13 Jun 2001 13:58:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09863 Wed, 13 Jun 2001 16:09:48 -0400 (EDT) Message-ID: <3B27BB9D.755C314D@acm.org> Date: Wed, 13 Jun 2001 12:14:37 -0700 From: Adrian Perrig X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: brakta CC: msec@securemulticast.org, ipsec@lists.tislabs.com Subject: Re: [MSEC] The use HMAC References: <3B27777F.B50C8FB3@loria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Mechanisms that provide such integrity check based on a secret key are > usually called "message authentication codes" (MAC). Typically, message > authentication codes are used between (two parties) that share a secret > key in order to validate information transmitted between these parties. > Can i use "message authentification codes" between more than two > parties, i mean in multicast application, specially 1- N mode ? Using a simple MAC for authenticating the sender in a broadcast is unfortunately insecure if the receivers do not trust each other. Since any one of the receivers knows the MAC key, it could impersonate the sender and send forged messages to other receivers. This is why we designed the TESLA protocol. TESLA provides efficient authentication, at the cost of about one MAC computation per packet, perfect robustness to packet loss, and requires loose time synchronization between the sender and the receivers. The authentication in TESLA is delayed, but we proposed an extension that allows the receivers to immediately authenticate data (which works well in environments with low packet loss). The IETF draft is available at: http://www.ietf.org/internet-drafts/draft-irtf-smug-tesla-00.txt Papers on TESLA are available at: http://paris.cs.berkeley.edu/%7Eperrig/projects.html#TESLA Let me know if you have further questions on this, Adrian From owner-ipsec@lists.tislabs.com Wed Jun 13 14:14:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DLEeJ08220; Wed, 13 Jun 2001 14:14:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09958 Wed, 13 Jun 2001 16:29:35 -0400 (EDT) To: "Christopher Gripp" Cc: Subject: Re: MTU and IPSec VPN's References: <4EBB5C35607E7F48B4AE162D956666EF338FC3@guam.corp.axcelerant.com> From: Derek Atkins Date: 13 Jun 2001 16:35:20 -0400 In-Reply-To: "Christopher Gripp"'s message of "Wed, 13 Jun 2001 13:06:47 -0700" Message-ID: Lines: 30 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The real problem are 'net sites that block all ICMP messages, which means that they effectively disable pmtu discovery. -derek "Christopher Gripp" writes: > When using various vendor implementations of IPSec (RedCreek and Cisco > to name a couple) we have run across an issue where the MTU must be > changed on the PCs and/or servers for certain traffic (Outlook/Exchange, > certain WWW pages) to flow through the VPN. > > The problem is with large datagrams that need to be fragmented for the > IPSec overhead to be added. > > Lowering the MTU on the PC, for instance, to ~1492 alleviates these > issues. > > However the proposition of hacking the registry of 10,000 windows > machines is at best ugly. > > Is there something in the vendor implementation that can be changed? Is > it an RFC compliancy issue? Or is this strictly a system configuration > issue with the nodes involved. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 14:32:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DLWEJ08725; Wed, 13 Jun 2001 14:32:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10123 Wed, 13 Jun 2001 16:54:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20010613134800.043b1968@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 13:57:19 -0700 To: brakta From: Mark Baugher Subject: Re: [MSEC] The use HMAC Cc: msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <3B27777F.B50C8FB3@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi At 04:23 PM 6/13/2001 +0200, brakta wrote: >Hello, > Mechanisms that provide such integrity check based on a secret key are >usually called "message authentication codes" (MAC). Typically, message >authentication codes are used between (two parties) that share a secret >key in order to validate information transmitted between these parties. >Can i use "message authentification codes" between more than two >parties, i mean in multicast application, specially 1- N mode ? >-- Yes you can with Adrian's caveat that a rogue member of the group is able to impersonate a sender if you cannot uniquely authenticate the sender. And you can't uniquely authenticate the sender using "group authentication" with a MAC. But you can using digital signatures, the cost of which can be amortized over many packets using tesla or similar algorithms. Mark >------------------------------------------ > Saber.BRAKTA > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : brakta@loria.fr >------------------------------------------ From owner-ipsec@lists.tislabs.com Wed Jun 13 15:14:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DMEWJ09959; Wed, 13 Jun 2001 15:14:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10228 Wed, 13 Jun 2001 17:35:28 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" , Subject: RE: IPSEC Security Gateways & NAT (3 issues) Date: Wed, 13 Jun 2001 17:15:20 -0400 Message-Id: <002401c0f44f$54f3a020$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200106131903.f5DJ39c01029@dharkins@lounge.orgatty.lounge.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The reason the SKEYID derivations differ is because Hugo stated that he did not think DH alone was strong enough for key agreement. The last time this issue came up, Hugo suggested changing the key derivation to: SKEYID_e = prf(hash(Ni_b | Nr_b), g^xy | CKY-I | CKY-R | 2) (although he also stated that he still prefers the exiting definition.) As for removing preshared key mode, here's a good quote from Ari from the last time this was discussed: What's the point of removing a feature that: - is the most interoperable authentication mode in existance - makes possible the smallest memory footprint implementation possible - is the most resistant to DoS attacks ??? Yes, it's not really usable in large scale, but that's beside the point. As for identity protection, we have several identity protection techniques which all have vulnerabilities. You can use main mode, which is vulnerable to an active attack. Or you can send a hash of the certificate with the encryted nonces authentication method, which is vulnerable to a tracking attack. Or you can use ID_KEY_ID, which is also vulnerable to a tracking attack. The hybrid/crack approach solves the problem of protecting the initiator's id, which is usually the important one. I suggest that those who are ultra-paranoid about tracking attacks get together and design a protocol for using one-time tokens in the ID_KEY_ID. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Wednesday, June 13, 2001 3:03 PM > To: Derek Atkins > Cc: Chen, David; 'jshukla'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > On 13 Jun 2001 12:24:28 EDT you wrote > > > > I agree that it is a problem that the IKE ID is tied to the > source and > > destinatin IP address. Currently, however, the __ONLY__ > time there is > > this particular problem is when using pre-shared static keys for > > authentication. Well, first, I would suggest people not use > > pre-shared static keys. That suggestion notwithstanding, > wouldn't it > > be better if this problem was fixed completely, so that pre-shared > > static keys are _NOT_ tied to the IP Source Address? > > The reason it was done that way is that there was a desire to > force the > keys to contain something known only by the peers (which is > why signature > mode was described as "the least secure"). There was also a > requirement > for identity protection. Those two combined to give us what > we have today. > You need to get the pre-shared secret to use to derive a key > to protect > the identity which is used to find the pre-shared key. That > wouldn't work > so the key is bound to all you can know at that time-- the IP address. > Actually, using ID_KEYID identity and Aggressive Mode can > give you identity > protection (since the keyid can be any opaque blob) with > pre-shared keys > but that's really not an elegant solution. > > Provided that the Diffie-Hellman is authenticated I guess we could say > that the resultant secret is something known only by the parties to > the exchange and therefore having g^xy (and not the pre-shared key) is > good enough. But I'm not a cryptographer and I didn't come up with the > key derivation. > > I'm all for simplifying and unifying SKEYID generation. Are there any > comments on this proposal? Hugo, are you out there? > > Dan. > > From owner-ipsec@lists.tislabs.com Wed Jun 13 15:44:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DMipJ10631; Wed, 13 Jun 2001 15:44:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10298 Wed, 13 Jun 2001 18:08:17 -0400 (EDT) To: "Chen, David" Cc: "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD767@mail.ellacoya.com> From: Derek Atkins Date: 13 Jun 2001 18:14:07 -0400 In-Reply-To: "Chen, David"'s message of "Wed, 13 Jun 2001 14:59:45 -0400" Message-ID: Lines: 56 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Agree, it seems a good idea to abolish pre-shared key in IKE. > (then, no NAPT issue) > > However, the pre-shared key's advantage is more effective to > against DOS attack comparing to "generating prime numbers" or > "check certificate revocation". One does not have to get rid of pre-shared keys or DoS protection in order to "fix" this particular problem with IKE. Radia Perlman, in a recent paper she sent to me (if you want a copy, send her mail at radia.perlman@sun.com), points out this flaw (and a number of others) and proposes the following change to fix it: Instead of encrypting messages 5 and 6 in a key derived from both DH and the Shared Secret, use a key derived solely from the DH agreement. Within messages 5 and 6 you already prove knowledge of the shared secret. Note that the responder would also have to send it's identity in message 4. This small change provides: a) better identity usage (you're not limited to the source IP address) b) better identity protection (because you're not limited to the source IP, you can actually HIDE the identities from passive eavesdroppers) c) The shared secret isn't used until both endpoints know their peer's identity. d) Will let us go through NAT :) > As for ESPoUDP, it seams able to traverse NAPT device as long as it is not > AH tunnel mode that protects the tunnel header (but it does not have ESP > anyway). This is why it's ESPoUDP, not AHoUDP ;) > Although, it still does not fix the QoS issue. > If ESPoUDP(500) can expand to ESPoTCP(500)(less secure) and copy the > inner TOS value to the outer IP, it will be more popular? Um, you're still confused. The whole point of using UDP is to give the NAT box paramters to map initiator<->responder. ESPoTCP makes no sense. ESP is a packet-oriented protocol, whereas TCP is a stream-oriented protocol. Where is the ESP 'SYN' in order to setup the connection? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 15:48:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DMmmJ10713; Wed, 13 Jun 2001 15:48:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10322 Wed, 13 Jun 2001 18:15:50 -0400 (EDT) To: Dan Harkins Cc: "Chen, David" , "'jshukla'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <200106131903.f5DJ39c01029@dharkins@lounge.orgatty.lounge.org> From: Derek Atkins Date: 13 Jun 2001 18:21:32 -0400 In-Reply-To: Dan Harkins's message of "Wed, 13 Jun 2001 12:03:09 -0700" Message-ID: Lines: 52 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > The reason it was done that way is that there was a desire to force the > keys to contain something known only by the peers (which is why signature > mode was described as "the least secure"). There was also a requirement > for identity protection. Those two combined to give us what we have today. Except that there is no identity protection. The identity MUST be the IP Addresses, and those are visible to any passive eavesdropper. > You need to get the pre-shared secret to use to derive a key to protect > the identity which is used to find the pre-shared key. That wouldn't work > so the key is bound to all you can know at that time-- the IP address. >From whom are you trying to protect the identity? As I said, in the current situation, even a passive eavesdropper learns that, because it must be an IP Address. Messages 5 and 6 only verify it. An alternative by Radia, as I mentioned in a previous post, would protect both identities from a passive eavesdropper. Just encrypt the IDs in the DH secret. No, that doesn't provide you authentication, but that's ok. Messages 5 and 6 do that. You don't have to encrypt messages 5 and 6 directly with a key derived from the shared secret. In fact, I think all you need is a valid MAC (with a key derived from the shared secret) to prove authentication. > Provided that the Diffie-Hellman is authenticated I guess we could say > that the resultant secret is something known only by the parties to > the exchange and therefore having g^xy (and not the pre-shared key) is > good enough. But I'm not a cryptographer and I didn't come up with the > key derivation. Think about the process this way: 1) Compute a key agreement using DH 2) Encrypt the identities in the agreed-upon key 3) Authenticate step 1 (and 2) using the shared secret with the peer (now that you know the identity). > I'm all for simplifying and unifying SKEYID generation. Are there any > comments on this proposal? Hugo, are you out there? > > Dan. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 13 16:48:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DNlxJ11925; Wed, 13 Jun 2001 16:47:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10435 Wed, 13 Jun 2001 19:01:38 -0400 (EDT) Date: Thu, 14 Jun 2001 02:07:20 +0300 (IDT) From: Hugo Krawczyk To: Dan Harkins cc: ipsec list Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: <200106131903.f5DJ39c01029@dharkins@lounge.orgatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have witnessed this for (too many) years: people complaint about the complexity of the protocol, at the same time they ask for richer functionality, and insist to get the added features with even less complexity. Sorry guys but there is no free lunch... Yes, IKE is complex. There are two main reasons for it: (1) ISAKMP is very complex and IKE was designed with the REQUIREMENT to fit in the ISAKMP framework (2) IKE was designed with a lot of requirements and optional functionalities: in particular, four different modes of authentication, with and without public keys, with and without identity protection, with and without aggressive mode, with pfs and without pfs in quick mode, with old groups and new ones too. If you want to simplify the protocol, first decide on a SUBSET of requirements, eliminate options and voila you'll have a simpler subset of IKE. But as long as you ask for more functionality then you have to pay the current complexity price AND MORE. SKEYID and related key derivation is the SIMPLEST possible mechanism I can think of to support in a UNIFORM way the myriad of current requirements and options. I actually worked hard to make SKEYID the only changing piece with all of SKEYID_a/d/e and HASH_I/R all derived in the SAME way in spite of all the different modes. Now specifically on pre-shared key mode as referred to in this thread. As Dan said you can bind the key to ID_KEYID instead of the ip address. This will hide the party identities but different uses of the key will be "linkable". You want to eliminate linkability? No problem: ADD complexity (e.g, change the value of ID_KEYID with each use of the key, no two uses will have the same ID and an attacker will not be able to link between these values. Nice and COMPLEX). And there are other solutions to the binding of the key to the ip address. If I understand Dan correctly he wants to allow binding the keys to the party identities rather than the in-the-clear ip address. Want that? No problem: ADD COMPLEXITY. Here is the (simplest) solution. What you can do is the following: leave everything as it is defined now for pre-shared key mode, except for SKEYID_e. Instead of deriving it from SKEYID as currently done, define it as something like prf(Ni_b | Nr_b, g^xy). Now you do not need to know the pre-shared key in order to decrypt the identities. Quite simple, right? but then you DEPARTED from the uniform derivation of SKEYID_e. No big deal just some more complexity. As I said: there's no free lunch. Hugo PS: just to make it clear: the above proposed change is for pre-shared mode only, other modes and derivations are unchanged On Wed, 13 Jun 2001, Dan Harkins wrote: > On 13 Jun 2001 12:24:28 EDT you wrote > > > > I agree that it is a problem that the IKE ID is tied to the source and > > destinatin IP address. Currently, however, the __ONLY__ time there is > > this particular problem is when using pre-shared static keys for > > authentication. Well, first, I would suggest people not use > > pre-shared static keys. That suggestion notwithstanding, wouldn't it > > be better if this problem was fixed completely, so that pre-shared > > static keys are _NOT_ tied to the IP Source Address? > > The reason it was done that way is that there was a desire to force the > keys to contain something known only by the peers (which is why signature > mode was described as "the least secure"). There was also a requirement > for identity protection. Those two combined to give us what we have today. > You need to get the pre-shared secret to use to derive a key to protect > the identity which is used to find the pre-shared key. That wouldn't work > so the key is bound to all you can know at that time-- the IP address. > Actually, using ID_KEYID identity and Aggressive Mode can give you identity > protection (since the keyid can be any opaque blob) with pre-shared keys > but that's really not an elegant solution. > > Provided that the Diffie-Hellman is authenticated I guess we could say > that the resultant secret is something known only by the parties to > the exchange and therefore having g^xy (and not the pre-shared key) is > good enough. But I'm not a cryptographer and I didn't come up with the > key derivation. > > I'm all for simplifying and unifying SKEYID generation. Are there any > comments on this proposal? Hugo, are you out there? > > Dan. > > From owner-ipsec@lists.tislabs.com Wed Jun 13 16:48:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DNm8J11940; Wed, 13 Jun 2001 16:48:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10476 Wed, 13 Jun 2001 19:16:31 -0400 (EDT) Date: Thu, 14 Jun 2001 02:22:19 +0300 (IDT) From: Hugo Krawczyk To: Derek Atkins cc: ipsec list Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, I have not seen Radia's paper so I can't comment on it. However, what you say here: > Think about the process this way: > > 1) Compute a key agreement using DH > 2) Encrypt the identities in the agreed-upon key > 3) Authenticate step 1 (and 2) using the shared secret with the > peer (now that you know the identity). is indeed a good explanation of the rationale for the change to pre-shared mode I suggested in a previous message. This is why I changed SKEYID_e to depend on g^xy only but left the HASH_I/R computations to depend on the preshared key (SKEYID) Hugo From owner-ipsec@lists.tislabs.com Wed Jun 13 17:50:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5E0omJ13488; Wed, 13 Jun 2001 17:50:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10459 Wed, 13 Jun 2001 19:11:32 -0400 (EDT) Date: Thu, 14 Jun 2001 02:17:21 +0300 (IDT) From: Hugo Krawczyk To: Andrew Krywaniuk cc: ipsec list Subject: RE: IPSEC Security Gateways & NAT (3 issues) In-Reply-To: <002401c0f44f$54f3a020$1e72788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 13 Jun 2001, Andrew Krywaniuk wrote: > The reason the SKEYID derivations differ is because Hugo stated that he did > not think DH alone was strong enough for key agreement. The last time this > issue came up, Hugo suggested changing the key derivation to: > > SKEYID_e = prf(hash(Ni_b | Nr_b), g^xy | CKY-I | CKY-R | 2) > > (although he also stated that he still prefers the exiting definition.) > This is NOT the reason that the SKEYID derivations differ. They differ because in three cases (sig, pke, pre-shared) the keying material is totally different. The differences are not driven by any fancy features (or by lack of trust in DH), they are ESSENTIAL for security. Hugo From owner-ipsec@lists.tislabs.com Wed Jun 13 18:57:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5E1v3J14655; Wed, 13 Jun 2001 18:57:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA10720 Wed, 13 Jun 2001 21:12:46 -0400 (EDT) From: "sankar ramamoorthi" To: "Hugo Krawczyk" , "Derek Atkins" Cc: "ipsec list" Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 13 Jun 2001 18:23:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is'nt one step missing in the process? That is the responder on receiving the first message has to check the policy and accept a matching SA proposal. The responder needs some way of getting to the policy. It is either the identifier or ip address of the peer that has to be used as the key to get to the policy. That implies ip address has to be used as the key if identity protection is required - right? -- sankar -- -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk Sent: Wednesday, June 13, 2001 4:22 PM To: Derek Atkins Cc: ipsec list Subject: Re: IPSEC Security Gateways & NAT Derek, I have not seen Radia's paper so I can't comment on it. However, what you say here: > Think about the process this way: > > 1) Compute a key agreement using DH > 2) Encrypt the identities in the agreed-upon key > 3) Authenticate step 1 (and 2) using the shared secret with the > peer (now that you know the identity). is indeed a good explanation of the rationale for the change to pre-shared mode I suggested in a previous message. This is why I changed SKEYID_e to depend on g^xy only but left the HASH_I/R computations to depend on the preshared key (SKEYID) Hugo From owner-ipsec@lists.tislabs.com Wed Jun 13 22:00:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5E50fJ20258; Wed, 13 Jun 2001 22:00:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11021 Thu, 14 Jun 2001 00:17:32 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" , "'Andrew Krywaniuk'" Cc: "'ipsec list'" Subject: RE: IPSEC Security Gateways & NAT (3 issues) Date: Wed, 13 Jun 2001 23:39:40 -0400 Message-Id: <002b01c0f488$6822bad0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This is NOT the reason that the SKEYID derivations differ. > They differ because in three cases (sig, pke, pre-shared) the > keying material is totally different. > The differences are not driven by any fancy features (or by > lack of trust > in DH), they are ESSENTIAL for security. Not having been actively involved in the WG at the time this was decided, I researched this topic in the archives a couple of years ago. My research disagreed with your claims that the particular SKEYID derivations are essential for security, so you'll forgive me if I take them with a grain of salt. What I remember was more along the line of: "I'm using and I want to include in the calculation." "I'm not using X, so do whatever you want." You'll excuse me for being skeptical of a so called ESSENTIAL derivation which appears arbitrary and which is not officially documented anywhere. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk > Sent: Wednesday, June 13, 2001 7:17 PM > To: Andrew Krywaniuk > Cc: ipsec list > Subject: RE: IPSEC Security Gateways & NAT (3 issues) > > > > > On Wed, 13 Jun 2001, Andrew Krywaniuk wrote: > > > The reason the SKEYID derivations differ is because Hugo > stated that he did > > not think DH alone was strong enough for key agreement. The > last time this > > issue came up, Hugo suggested changing the key derivation to: > > > > SKEYID_e = prf(hash(Ni_b | Nr_b), g^xy | CKY-I | CKY-R | 2) > > > > (although he also stated that he still prefers the exiting > definition.) > > > > This is NOT the reason that the SKEYID derivations differ. > They differ because in three cases (sig, pke, pre-shared) the > keying material is totally different. > The differences are not driven by any fancy features (or by > lack of trust > in DH), they are ESSENTIAL for security. > > Hugo > > From owner-ipsec@lists.tislabs.com Wed Jun 13 22:04:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5E54wJ20489; Wed, 13 Jun 2001 22:04:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA10979 Thu, 14 Jun 2001 00:08:04 -0400 (EDT) Message-Id: <200106140404.f5E43xc01968@dharkins@lounge.orgatty.lounge.org> To: "Chen, David" Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: Your message of "Wed, 13 Jun 2001 15:24:59 EDT." <85D31AAF3DFCD4119C44000102C009707DD768@mail.ellacoya.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1965.992491439.1@lounge.org> Date: Wed, 13 Jun 2001 21:03:59 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is no requirement to generate a prime number per exchange and the cost of checking a CRL should pale in comparison to computing a Diffie-Hellman. Nothing computationally expensive is done until two messages are received from the same peer with the 2nd containing the responder's cookie. There is a DOS concern, though, since a responder will create state upon receipt of the 1st message from the initiator. If we wanted to address that we could add a stateless "cookie request" option ala Oakley and Photuris. But that would make things more complex.... Dan. On Wed, 13 Jun 2001 15:24:59 EDT you wrote > Dan, > Preshared key seem more effective against DOS attack > comparing to "generating prime number" or "check certificate revocation"? > Regards, > --- David > > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, June 13, 2001 3:03 PM > To: Derek Atkins > Cc: Chen, David; 'jshukla'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > On 13 Jun 2001 12:24:28 EDT you wrote > > > > I agree that it is a problem that the IKE ID is tied to the source and > > destinatin IP address. Currently, however, the __ONLY__ time there is > > this particular problem is when using pre-shared static keys for > > authentication. Well, first, I would suggest people not use > > pre-shared static keys. That suggestion notwithstanding, wouldn't it > > be better if this problem was fixed completely, so that pre-shared > > static keys are _NOT_ tied to the IP Source Address? > > The reason it was done that way is that there was a desire to force the > keys to contain something known only by the peers (which is why signature > mode was described as "the least secure"). There was also a requirement > for identity protection. Those two combined to give us what we have today. > You need to get the pre-shared secret to use to derive a key to protect > the identity which is used to find the pre-shared key. That wouldn't work > so the key is bound to all you can know at that time-- the IP address. > Actually, using ID_KEYID identity and Aggressive Mode can give you identity > protection (since the keyid can be any opaque blob) with pre-shared keys > but that's really not an elegant solution. > > Provided that the Diffie-Hellman is authenticated I guess we could say > that the resultant secret is something known only by the parties to > the exchange and therefore having g^xy (and not the pre-shared key) is > good enough. But I'm not a cryptographer and I didn't come up with the > key derivation. > > I'm all for simplifying and unifying SKEYID generation. Are there any > comments on this proposal? Hugo, are you out there? > > Dan. From owner-ipsec@lists.tislabs.com Thu Jun 14 05:25:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ECPmJ04809; Thu, 14 Jun 2001 05:25:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11688 Thu, 14 Jun 2001 07:15:46 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 13 Jun 2001 14:46:14 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: [MSEC] Re: multicast authentication using AH 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 QAA10012 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Might also want to encode an ident somewhere. Should there be an option for attaching a cert to the message, or would you see that being done solely by key mgmt (group mgr would multicast sender certs to the group)? Maintaining many certs does complicate SA mgmt, it's like having many keys/SA. Hilarie >>> Dan McDonald 06/13/01 08:14AM >>> > > > AH SHOULD HAVE supported authentication with digital signatures. > > > >There's nothing, I believe, about AH that prevents digital signatures from > >being used. > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > >Dan > > How is this signalled? It's part of the IPsec Security Association data. Per 2401, an SA is indexed by the tuple . When you add the appropriate SA, you get all sorts of data, including the algorithm. All one would need to do is write a new "algorithm document" for using a digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) I could easily prototype one in Solaris. Dan From owner-ipsec@lists.tislabs.com Thu Jun 14 05:25:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ECPnJ04815; Thu, 14 Jun 2001 05:25:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11705 Thu, 14 Jun 2001 07:17:47 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'Christopher Gripp'" Cc: ipsec@lists.tislabs.com Subject: RE: MTU and IPSec VPN's Date: Wed, 13 Jun 2001 15:43:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F451.EA861D00" 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_01C0F451.EA861D00 Content-Type: text/plain; charset="iso-8859-1" This is definitely a compliance issue. Per RFC 2401, 6.1.1 DF Bit In cases where a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.) This is addressed in ios 12.2, not sure about redcreek. http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 t/122t2/ftdfipsc.htm Mike Horn -----Original Message----- From: Christopher Gripp [mailto:cgripp@axcelerant.com] Sent: Wednesday, June 13, 2001 2:07 PM To: ipsec@lists.tislabs.com Subject: MTU and IPSec VPN's When using various vendor implementations of IPSec (RedCreek and Cisco to name a couple) we have run across an issue where the MTU must be changed on the PCs and/or servers for certain traffic (Outlook/Exchange, certain WWW pages) to flow through the VPN. The problem is with large datagrams that need to be fragmented for the IPSec overhead to be added. Lowering the MTU on the PC, for instance, to ~1492 alleviates these issues. However the proposition of hacking the registry of 10,000 windows machines is at best ugly. Is there something in the vendor implementation that can be changed? Is it an RFC compliancy issue? Or is this strictly a system configuration issue with the nodes involved. ------_=_NextPart_001_01C0F451.EA861D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MTU and IPSec VPN's
This is=20 definitely a compliance issue.  Per RFC = 2401,
 
6.1.1 DF=20 Bit
 
   In=20 cases where a system (host or gateway) adds an = encapsulating
  =20 header (ESP tunnel or AH tunnel), it MUST support the option = of
  =20 copying the DF bit from the original packet to the = encapsulating
  =20 header (and processing ICMP PMTU messages).  This means that it=20 MUST
   be possible to configure the system's treatment of = the DF=20 bit (set,
   clear, copy from encapsulated header) for = each=20 interface.  (See
   Appendix B for=20 rationale.)
This is addressed=20 in ios 12.2, not sure about redcreek.
 
 
Mike=20 Horn
-----Original Message-----
From: Christopher Gripp = [mailto:cgripp@axcelerant.com]
Sent: Wednesday, June 13, = 2001 2:07=20 PM
To: ipsec@lists.tislabs.com
Subject: MTU and = IPSec=20 VPN's

When using various vendor implementations of IPSec = (RedCreek=20 and Cisco to name a couple) we have run across an issue where the MTU = must be=20 changed on the PCs and/or servers for certain traffic = (Outlook/Exchange,=20 certain WWW pages) to flow through the VPN.

The problem is with large datagrams that need to be = fragmented=20 for the IPSec overhead to be added.

Lowering the MTU on the PC, for instance, to ~1492 = alleviates=20 these issues.

However the proposition of hacking the registry of = 10,000=20 windows machines is at best ugly.

Is there something in the vendor implementation = that can be=20 changed?  Is it an RFC compliancy issue?  Or is this = strictly a=20 system configuration issue with the nodes=20 involved.

------_=_NextPart_001_01C0F451.EA861D00-- From owner-ipsec@lists.tislabs.com Thu Jun 14 05:26:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ECQnJ04910; Thu, 14 Jun 2001 05:26:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11694 Thu, 14 Jun 2001 07:16:47 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 13 Jun 2001 14:48:01 -0600 From: "Hilarie Orman" To: Subject: Fwd: Re: IPSEC Security Gateways & NAT Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_3862299D.C9A8683C" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_3862299D.C9A8683C Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Derek Atkins says:=20 --=_3862299D.C9A8683C Content-Type: message/rfc822 Received: from prv-mx.provo.novell.com by prv-mail20.provo.novell.com; Wed, 13 Jun 2001 14:30:25 -0600 Received: from mail.volera.com ([64.209.184.75]) by prv-mx.provo.novell.com; Wed, 13 Jun 2001 14:24:01 -0600 Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by mail.volera.com (8.11.1/8.11.1) with ESMTP id f5DKUTf23806 for ; Wed, 13 Jun 2001 13:30:29 -0700 Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id QAA09144; Wed, 13 Jun 2001 16:30:22 -0400 To: "Hilarie Orman" Subject: Re: IPSEC Security Gateways & NAT References: From: Derek Atkins Date: 13 Jun 2001 16:30:20 -0400 In-Reply-To: "Hilarie Orman"'s message of "Wed, 13 Jun 2001 13:35:16 -0600" Message-ID: Lines: 117 X-Mailer: Gnus v5.5/Emacs 20.3 Except: a) it is the only required authentication "system", and b) it's unfortunately being used a lot. I would be more than happy to require RSA. Why wasn't that done? (rhetorical question). Besides, from the human-factors point of view, using pre-shared keys is easier from a ui standpoint: "Here is your IKE password." Moreover, this whole argument just points to the fact that pre-shared keys are a problem. If it weren't for the existing pre-shared keys protocol, NAT wouldn't be as much of a problem (except for ESP encapsulation). Ah well. -derek "Hilarie Orman" writes: > I feel that it would be a mistake to fix pre-shared static keys. > They were meant to bootstrap initial adoption of IKE and > should be allowed to die a natural death from disuse. > > Hilarie > > >>> Derek Atkins 06/13/01 10:24AM >>> > "Chen, David" writes: > > > Derek, > > > > My explanation: > > 1. IKE > > Problem: > > 1) Today's IKE using UDP/IP to exchnage packet. > > 2) It can not traverse through NAPT device due to the > > addresses are used for ID (and protected) and > > the addresses/ports are changed by the NAPT device. > > > > Solution: > > The idea to use yet another UDP/IP header is to shied the IKE packet > from > > NAPT device. > > It will require the IKE deamon to encapsulate/de-encapsulate the > outer > > UDP/IP header before > > processing today's IKE packets. > > Would it not be easier to change the IKE naming procedures so that the > endpoint identifiers are not necessarily tied to the actual source IP > Address of the packets? Wouldn't that make more sense and require > fewer changes overall? > > I agree that it is a problem that the IKE ID is tied to the source and > destinatin IP address. Currently, however, the __ONLY__ time there is > this particular problem is when using pre-shared static keys for > authentication. Well, first, I would suggest people not use > pre-shared static keys. That suggestion notwithstanding, wouldn't it > be better if this problem was fixed completely, so that pre-shared > static keys are _NOT_ tied to the IP Source Address? > > > 2. IPSec data channel: > > The packet's format is: > > IPHeader, Transport header, AH, ESP, IP Header, IP payload. > > It constructs this packet (with header mapping) at the time of > encryption, > > not after ESP is done. > > Remember, with normal ESP/AH, there _IS_ no transport header. With > normal IPSec you have: > > > > Any transport header is encrypted. Copying that transport header > would be a breach in security. > > ESPoUDP, however, adds a UDP header up front _AFTER_ encryption, in > order to give the NAT box something to change. Therefore, you get: > > > > The header just says src/dest ports 500/500 so the NAT gateway > has something with which to munge between the IPSec Peers. Again, > this _CAN_ be added after encryption with no ills. > > The only problem with this approach is if both the initiator and > responder are behind a NAT. However, in that situation you would need > some a-priori knowledge in order for the initiator to address a packet > such that it will reach the responder (hense my requirement for > reachability). This implies that UDP port 500 on the NAT box must > forward to the IPSec SG behind it in order to meet the reachability > requirement. So, if we fix the 'pre-shared static keys require > source/dest ip address matching' problem, we fix this case as well. > > So, let's fix the problem in IKE that pre-shared static keys require > the source/dest ip address to match. Then we don't need any of this > double encapsulation of IKE, and simple UDP encapsulation of ESP > continues to work. > > > Regards, > > > > --- David > > -derek > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available --=_3862299D.C9A8683C-- From owner-ipsec@lists.tislabs.com Thu Jun 14 05:28:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ECSOJ04965; Thu, 14 Jun 2001 05:28:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11706 Thu, 14 Jun 2001 07:17:48 -0400 (EDT) Message-Id: <200106140042.f5E0g7g07012@marajade.sandelman.ottawa.on.ca> To: Derek Atkins cc: ipsec@lists.tislabs.com Subject: Re: MTU and IPSec VPN's In-reply-to: Your message of "13 Jun 2001 16:35:20 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Jun 2001 20:42:07 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> The real problem are 'net sites that block all ICMP messages, Derek> which means that they effectively disable pmtu discovery. Uh, since this is occuring through their VPN, if there is any blocking of ICMPs (assuming that they are generated correctly), then it would be happening in their network. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Jun 14 08:05:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EF5XJ11315; Thu, 14 Jun 2001 08:05:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12139 Thu, 14 Jun 2001 10:04:15 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD769@mail.ellacoya.com> From: "Chen, David" To: "'Dan Harkins'" , "Chen, David" Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 14 Jun 2001 10:07:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you pre-comp a set of prime numbers for DH-key exchange... These can use only one time and they are consumed faster then you can come up new ones. This is the DOS idea that keep the IPSec responder so busy (meaninglessly) that no time for other meaningful activities. Recycling prime numbers for DH-key exchange is a implementation mistake??? The CR process requires pending on a state that waits for server search through the chains of servers to come up CRL (and it grows longer along the time). It is a classical eavesdropping. The preshared key (pass-phrase) can auth the peer with much less cost and stateless. If someone can inscribe the first pair of DH-key exchange with CHAP(or others), it seems can remove some random DOS attack. This will complement the DH-Key exchange's weakness of unknowing the peer is "DOS attacker". Regards, --- David -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Thursday, June 14, 2001 12:04 AM To: Chen, David Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT There is no requirement to generate a prime number per exchange and the cost of checking a CRL should pale in comparison to computing a Diffie-Hellman. Nothing computationally expensive is done until two messages are received from the same peer with the 2nd containing the responder's cookie. There is a DOS concern, though, since a responder will create state upon receipt of the 1st message from the initiator. If we wanted to address that we could add a stateless "cookie request" option ala Oakley and Photuris. But that would make things more complex.... Dan. On Wed, 13 Jun 2001 15:24:59 EDT you wrote > Dan, > Preshared key seem more effective against DOS attack > comparing to "generating prime number" or "check certificate revocation"? > Regards, > --- David > > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, June 13, 2001 3:03 PM > To: Derek Atkins > Cc: Chen, David; 'jshukla'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > On 13 Jun 2001 12:24:28 EDT you wrote > > > > I agree that it is a problem that the IKE ID is tied to the source and > > destinatin IP address. Currently, however, the __ONLY__ time there is > > this particular problem is when using pre-shared static keys for > > authentication. Well, first, I would suggest people not use > > pre-shared static keys. That suggestion notwithstanding, wouldn't it > > be better if this problem was fixed completely, so that pre-shared > > static keys are _NOT_ tied to the IP Source Address? > > The reason it was done that way is that there was a desire to force the > keys to contain something known only by the peers (which is why signature > mode was described as "the least secure"). There was also a requirement > for identity protection. Those two combined to give us what we have today. > You need to get the pre-shared secret to use to derive a key to protect > the identity which is used to find the pre-shared key. That wouldn't work > so the key is bound to all you can know at that time-- the IP address. > Actually, using ID_KEYID identity and Aggressive Mode can give you identity > protection (since the keyid can be any opaque blob) with pre-shared keys > but that's really not an elegant solution. > > Provided that the Diffie-Hellman is authenticated I guess we could say > that the resultant secret is something known only by the parties to > the exchange and therefore having g^xy (and not the pre-shared key) is > good enough. But I'm not a cryptographer and I didn't come up with the > key derivation. > > I'm all for simplifying and unifying SKEYID generation. Are there any > comments on this proposal? Hugo, are you out there? > > Dan. From owner-ipsec@lists.tislabs.com Thu Jun 14 10:36:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EHa3J20071; Thu, 14 Jun 2001 10:36:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13402 Thu, 14 Jun 2001 12:09:25 -0400 (EDT) Message-Id: <200106141605.f5EG5KI00577@dharkins@lounge.orgatty.lounge.org> To: "Chen, David" Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: Your message of "Thu, 14 Jun 2001 10:07:05 EDT." <85D31AAF3DFCD4119C44000102C009707DD769@mail.ellacoya.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <574.992534720.1@lounge.org> Date: Thu, 14 Jun 2001 09:05:20 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is no need to compute a set of prime numbers to do the D-H exchange in IKE. The prime number is specified in the group. In any event, you still have to do a D-H when authenticating with pre-shared keys so even if your premise was correct (that you need to generate a set of prime numbers to do a D-H in IKE) then your conclusion (that pre-shared keys is somehow less susceptible to a DOS attack) does not follow. And again, the responder does not do any work D-H-wise until it has received 2 messages from the same peer with the 2nd message containing something he created. The DOS concern is not that it is doing unnecessary D-H computation it is that it creates state upon the receipt of a single message from an initiator. Dan. On Thu, 14 Jun 2001 10:07:05 EDT you wrote > > If you pre-comp a set of prime numbers for DH-key exchange... > These can use only one time and they are consumed faster then you can come > up new ones. > This is the DOS idea that keep the IPSec responder so busy (meaninglessly) > that > no time for other meaningful activities. > Recycling prime numbers for DH-key exchange is a implementation mistake??? > > The CR process requires pending on a state that waits for server search > through the > chains of servers to come up CRL (and it grows longer along the time). > It is a classical eavesdropping. > > The preshared key (pass-phrase) can auth the peer with much less cost and > stateless. > > If someone can inscribe the first pair of DH-key exchange with CHAP(or > others), > it seems can remove some random DOS attack. > This will complement the DH-Key exchange's weakness of > unknowing the peer is "DOS attacker". > > Regards, > > --- David > From owner-ipsec@lists.tislabs.com Thu Jun 14 10:36:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EHa5J20083; Thu, 14 Jun 2001 10:36:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13677 Thu, 14 Jun 2001 12:42:48 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD76A@mail.ellacoya.com> From: "Chen, David" To: "'Dan Harkins'" Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 14 Jun 2001 12:45:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Since the phase 1 goal is to auth DH-key exchange. The DH key is generated *after* auth anyway. However, the pre-shared key (pass-phrase) authetication cost less (and stateless) for responder to verify than "public key" authentication. Regards, --- David -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Thursday, June 14, 2001 12:05 PM To: Chen, David Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT There is no need to compute a set of prime numbers to do the D-H exchange in IKE. The prime number is specified in the group. In any event, you still have to do a D-H when authenticating with pre-shared keys so even if your premise was correct (that you need to generate a set of prime numbers to do a D-H in IKE) then your conclusion (that pre-shared keys is somehow less susceptible to a DOS attack) does not follow. And again, the responder does not do any work D-H-wise until it has received 2 messages from the same peer with the 2nd message containing something he created. The DOS concern is not that it is doing unnecessary D-H computation it is that it creates state upon the receipt of a single message from an initiator. Dan. On Thu, 14 Jun 2001 10:07:05 EDT you wrote > > If you pre-comp a set of prime numbers for DH-key exchange... > These can use only one time and they are consumed faster then you can come > up new ones. > This is the DOS idea that keep the IPSec responder so busy (meaninglessly) > that > no time for other meaningful activities. > Recycling prime numbers for DH-key exchange is a implementation mistake??? > > The CR process requires pending on a state that waits for server search > through the > chains of servers to come up CRL (and it grows longer along the time). > It is a classical eavesdropping. > > The preshared key (pass-phrase) can auth the peer with much less cost and > stateless. > > If someone can inscribe the first pair of DH-key exchange with CHAP(or > others), > it seems can remove some random DOS attack. > This will complement the DH-Key exchange's weakness of > unknowing the peer is "DOS attacker". > > Regards, > > --- David > From owner-ipsec@lists.tislabs.com Thu Jun 14 10:43:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EHhtJ20273; Thu, 14 Jun 2001 10:43:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13785 Thu, 14 Jun 2001 12:53:33 -0400 (EDT) From: Ricky Charlet Cc: ipsec list Message-ID: <3B28EF1E.A66EAE0@redcreek.com> Date: Thu, 14 Jun 2001 10:06:38 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IPSEC Security Gateways & NAT References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, Question below: Hugo Krawczyk wrote: > SKEYID and related key derivation is the SIMPLEST possible mechanism I can > think of to support in a UNIFORM way the myriad of current requirements > and options. I actually worked hard to make SKEYID the only changing piece > with all of SKEYID_a/d/e and HASH_I/R all derived in the SAME way in > spite of all the different modes. > > > Hugo > Dan Harkins wrote: > > > > Provided that the Diffie-Hellman is authenticated I guess we could say > > that the resultant secret is something known only by the parties to > > the exchange and therefore having g^xy (and not the pre-shared key) is > > good enough. But I'm not a cryptographer and I didn't come up with the > > key derivation. > > > > I'm all for simplifying and unifying SKEYID generation. Are there any > > comments on this proposal? Hugo, are you out there? > > > > Dan. > > > > I have long been confused by the derivation of SKEYID. I'm certianly not expert enough to suggest changing it, but I do request that we formally document its design goals. As Dan menetions, using g^xy alone for SKEYID in all cases seems entirely sufficient to me (and I'm sure to most implementors). What goals/requiremetns lead us to wish to include other elemetns and in 2 cases NOT use g^xy at all in SKEYID? I have seen the assertion that SKEYID is a SIMPLE as it can be and yet meet all the requirements. I've also seen the assertion that these other data elements in SKEYID are ESSENTIAL to security. Well then, it sounds like something I as an impelementor should be able to understand. I need a document showing the design reqirements, how they lead to the current SKEYID derivations and how these decisions shore up security. Preferably in the form of a few added paragraphs to the son-of-ike draft. Please. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Thu Jun 14 11:04:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EI42J21721; Thu, 14 Jun 2001 11:04:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13972 Thu, 14 Jun 2001 13:10:49 -0400 (EDT) To: "sankar ramamoorthi" Cc: "Hugo Krawczyk" , "ipsec list" Subject: Re: IPSEC Security Gateways & NAT References: From: Derek Atkins Date: 14 Jun 2001 13:16:35 -0400 In-Reply-To: "sankar ramamoorthi"'s message of "Wed, 13 Jun 2001 18:23:59 -0700" Message-ID: Lines: 64 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "sankar ramamoorthi" writes: > Is'nt one step missing in the process? That is the responder on receiving > the > first message has to check the policy and accept a matching SA proposal. > The responder needs some way of getting to the policy. How much policy checking is done as part of Phase I? Indeed, in looking at 2409, ALL authentication modes of Phase-I perform the 'IKE SA Negotiation' in messages 1 and 2 before ANY identifying information is sent. Remember that this negotiation is _JUST_ about negotiation the phase-I encryption/authentation protocols. So, no, there isn't a step missing, because there is no policy verification at this step. > It is either the identifier or ip address of the peer that has to be used as > the key to get to the policy. > > That implies ip address has to be used as the key if identity protection > is required - right? No. Phase-I Main Mode agrees on a protection suite after message 2, and then you can go back and verify the policy after message 6, but before you start a Phase-II. -derek > -- sankar -- > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk > Sent: Wednesday, June 13, 2001 4:22 PM > To: Derek Atkins > Cc: ipsec list > Subject: Re: IPSEC Security Gateways & NAT > > > Derek, I have not seen Radia's paper so I can't comment on it. > However, what you say here: > > > Think about the process this way: > > > > 1) Compute a key agreement using DH > > 2) Encrypt the identities in the agreed-upon key > > 3) Authenticate step 1 (and 2) using the shared secret with the > > peer (now that you know the identity). > > is indeed a good explanation of the rationale for the change to pre-shared > mode I suggested in a previous message. > This is why I changed SKEYID_e to depend on g^xy only but left the > HASH_I/R computations to depend on the preshared key (SKEYID) > > Hugo > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 14 12:24:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EJOsJ23987; Thu, 14 Jun 2001 12:24:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14589 Thu, 14 Jun 2001 14:15:37 -0400 (EDT) From: "sankar ramamoorthi" To: "Derek Atkins" Cc: "Hugo Krawczyk" , "ipsec list" Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 14 Jun 2001 11:26:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: warlord@INDIANA.MIT.EDU on behalf of Derek Atkins >[warlord@MIT.EDU] >Sent: Thursday, June 14, 2001 10:17 AM >To: sankar ramamoorthi >Cc: Hugo Krawczyk; ipsec list >Subject: Re: IPSEC Security Gateways & NAT > >"sankar ramamoorthi" writes: > >> Is'nt one step missing in the process? That is the responder on receiving >> the >> first message has to check the policy and accept a matching SA proposal. >> The responder needs some way of getting to the policy. > >How much policy checking is done as part of Phase I? Indeed, in >looking at 2409, ALL authentication modes of Phase-I perform the 'IKE >SA Negotiation' in messages 1 and 2 before ANY identifying information >is sent. Remember that this negotiation is _JUST_ about negotiation >the phase-I encryption/authentation protocols. > >So, no, there isn't a step missing, because there is no policy >verification at this step. > >> It is either the identifier or ip address of the peer that has to be used as >> the key to get to the policy. >> >> That implies ip address has to be used as the key if identity protection >> is required - right? > >No. Phase-I Main Mode agrees on a protection suite after message 2, >and then you can go back and verify the policy after message 6, but >before you start a Phase-II. > Yes - this is the way I had implemented in the past. The only ambuguity was in deciding which protection suite to accept I used to always choose the first one to be accepted and later confirm whether it matches policy (after id is received). It would be nice to have a policy id and authentication id. Send policy id in the first message (no id protection for policy id). Getting back to the original topic of the thread - udp encapsulation for IKE traffic seems unnecessary and avoidable. -- sankar -- >-derek From owner-ipsec@lists.tislabs.com Thu Jun 14 12:25:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EJPgJ24023; Thu, 14 Jun 2001 12:25:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14651 Thu, 14 Jun 2001 14:28:36 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Chen, David'" , "'Dan Harkins'" Cc: Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 14 Jun 2001 14:26:47 -0400 Message-Id: <000f01c0f4ff$aa6d6df0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <85D31AAF3DFCD4119C44000102C009707DD769@mail.ellacoya.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If you pre-comp a set of prime numbers for DH-key exchange... > These can use only one time and they are consumed faster then > you can come > up new ones. > This is the DOS idea that keep the IPSec responder so busy > (meaninglessly) > that > no time for other meaningful activities. > Recycling prime numbers for DH-key exchange is a > implementation mistake??? As Dan said, the numbers you pre-computer are not prime. I should also point out that it is normally acceptable to recycle the precomputed DH values if the exchange fails. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Thu Jun 14 12:36:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EJauJ24336; Thu, 14 Jun 2001 12:36:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14672 Thu, 14 Jun 2001 14:40:03 -0400 (EDT) Message-Id: <200106141836.f5EIZwI02089@dharkins@lounge.orgatty.lounge.org> To: "Chen, David" Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: Your message of "Thu, 14 Jun 2001 12:45:39 EDT." <85D31AAF3DFCD4119C44000102C009707DD76A@mail.ellacoya.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2086.992543758.1@lounge.org> Date: Thu, 14 Jun 2001 11:35:58 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, the DH secret is generated *before* authentication. Re-read the RFC. Dan. On Thu, 14 Jun 2001 12:45:39 EDT you wrote > Dan, > > Since the phase 1 goal is to auth DH-key exchange. > The DH key is generated *after* auth anyway. > > However, > the pre-shared key (pass-phrase) authetication cost less (and stateless) > for responder to verify than "public key" authentication. > > Regards, > > --- David From owner-ipsec@lists.tislabs.com Thu Jun 14 12:50:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EJodJ24779; Thu, 14 Jun 2001 12:50:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14722 Thu, 14 Jun 2001 15:08:06 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD76B@mail.ellacoya.com> From: "Chen, David" To: "'Dan Harkins'" , "Chen, David" Cc: ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 14 Jun 2001 15:10:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Exactly, today's phase 1 do DH key number crunching before auth the peer. (well I think it is only intend to check integrity of the messages, but pre-shared key having more than that it also auth peer.) DH key generation cost much more than simple pass-phrase verification. Random DOS attacks can be reduced, if responder auth peer first (first tier auth) before crunching the DH-key. Regards, --- David -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Thursday, June 14, 2001 2:36 PM To: Chen, David Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT No, the DH secret is generated *before* authentication. Re-read the RFC. Dan. On Thu, 14 Jun 2001 12:45:39 EDT you wrote > Dan, > > Since the phase 1 goal is to auth DH-key exchange. > The DH key is generated *after* auth anyway. > > However, > the pre-shared key (pass-phrase) authetication cost less (and stateless) > for responder to verify than "public key" authentication. > > Regards, > > --- David From owner-ipsec@lists.tislabs.com Thu Jun 14 13:35:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EKZoJ26546; Thu, 14 Jun 2001 13:35:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14831 Thu, 14 Jun 2001 15:44:28 -0400 (EDT) To: "Chen, David" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD76B@mail.ellacoya.com> From: Derek Atkins Date: 14 Jun 2001 15:50:19 -0400 In-Reply-To: "Chen, David"'s message of "Thu, 14 Jun 2001 15:10:49 -0400" Message-ID: Lines: 62 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, it's not -random- DoS. The attacker must at least respond to message 2 with message 3 before the responder will do any work. This implies that the attacker must make their actual IP address known to the attacked. So, you may be forced to execute a DH exponentiation as a responder, but you at least know _WHO_ (IP Address) caused you to perform the operation. -derek "Chen, David" writes: > Dan, > > Exactly, today's phase 1 > do DH key number crunching before auth the peer. > (well I think it is only intend to check integrity of the messages, > but pre-shared key having more than that it also auth peer.) > > DH key generation cost much more than simple pass-phrase verification. > > Random DOS attacks can be reduced, if responder > auth peer first (first tier auth) before crunching the DH-key. > > Regards, > > --- David > > > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Thursday, June 14, 2001 2:36 PM > To: Chen, David > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > No, the DH secret is generated *before* authentication. Re-read the RFC. > > Dan. > > On Thu, 14 Jun 2001 12:45:39 EDT you wrote > > Dan, > > > > Since the phase 1 goal is to auth DH-key exchange. > > The DH key is generated *after* auth anyway. > > > > However, > > the pre-shared key (pass-phrase) authetication cost less (and stateless) > > for responder to verify than "public key" authentication. > > > > Regards, > > > > --- David -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 14 13:37:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EKbuJ26631; Thu, 14 Jun 2001 13:37:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14863 Thu, 14 Jun 2001 15:50:33 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD76D@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 14 Jun 2001 15:53:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, I heard that DDOS can steal someone's computer (with IP address) to perform the attack. Also, it could be an unreachable IP address the attacker invented (or plotted). The IP addess seems meaningless, unless it is linked to a auth method such as preshared key. Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Thursday, June 14, 2001 3:50 PM To: Chen, David Cc: 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT Well, it's not -random- DoS. The attacker must at least respond to message 2 with message 3 before the responder will do any work. This implies that the attacker must make their actual IP address known to the attacked. So, you may be forced to execute a DH exponentiation as a responder, but you at least know _WHO_ (IP Address) caused you to perform the operation. -derek "Chen, David" writes: > Dan, > > Exactly, today's phase 1 > do DH key number crunching before auth the peer. > (well I think it is only intend to check integrity of the messages, > but pre-shared key having more than that it also auth peer.) > > DH key generation cost much more than simple pass-phrase verification. > > Random DOS attacks can be reduced, if responder > auth peer first (first tier auth) before crunching the DH-key. > > Regards, > > --- David > > > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Thursday, June 14, 2001 2:36 PM > To: Chen, David > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > No, the DH secret is generated *before* authentication. Re-read the RFC. > > Dan. > > On Thu, 14 Jun 2001 12:45:39 EDT you wrote > > Dan, > > > > Since the phase 1 goal is to auth DH-key exchange. > > The DH key is generated *after* auth anyway. > > > > However, > > the pre-shared key (pass-phrase) authetication cost less (and stateless) > > for responder to verify than "public key" authentication. > > > > Regards, > > > > --- David -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 14 13:46:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EKkRJ26919; Thu, 14 Jun 2001 13:46:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14886 Thu, 14 Jun 2001 16:00:02 -0400 (EDT) To: "Chen, David" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD76D@mail.ellacoya.com> From: Derek Atkins Date: 14 Jun 2001 16:01:45 -0400 In-Reply-To: "Chen, David"'s message of "Thu, 14 Jun 2001 15:53:29 -0400" Message-ID: Lines: 111 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An unreachable IP Address would never get beyond message 2. DH doesn't happen at the responder until message 4. So you are protected against unreachable addresses. In other words, no, the IP address is NOT meaningless. It means the address is reachable _and_ interested in an IKE protocol instantiation. True, we are still subject to DDoS zombies using their own IP Address, but again, as I said, we now know _who_ is attacking us (because they are actually responding to message 2 with a valid message 3), and we can just rate-limit those addresses. Ok, I'm lying a bit. What we actually know that the attacker is somewhere on the network path between the responder and the IP Address of the initiator, such that it can read the IKE messages and grab the responder cookie in order to send message 3. -derek "Chen, David" writes: > Derek, > I heard that DDOS can steal someone's computer (with IP address) to > perform the attack. > Also, it could be an unreachable IP address the attacker invented (or > plotted). > > The IP addess seems meaningless, unless > it is linked to a auth method such as preshared key. > > Regards, > > --- David > > > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Thursday, June 14, 2001 3:50 PM > To: Chen, David > Cc: 'Dan Harkins'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > Well, it's not -random- DoS. The attacker must at least respond > to message 2 with message 3 before the responder will do any work. > This implies that the attacker must make their actual IP address > known to the attacked. > > So, you may be forced to execute a DH exponentiation as a responder, > but you at least know _WHO_ (IP Address) caused you to perform the > operation. > > -derek > > "Chen, David" writes: > > > Dan, > > > > Exactly, today's phase 1 > > do DH key number crunching before auth the peer. > > (well I think it is only intend to check integrity of the messages, > > but pre-shared key having more than that it also auth peer.) > > > > DH key generation cost much more than simple pass-phrase verification. > > > > Random DOS attacks can be reduced, if responder > > auth peer first (first tier auth) before crunching the DH-key. > > > > Regards, > > > > --- David > > > > > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Thursday, June 14, 2001 2:36 PM > > To: Chen, David > > Cc: ipsec@lists.tislabs.com > > Subject: Re: IPSEC Security Gateways & NAT > > > > > > No, the DH secret is generated *before* authentication. Re-read the RFC. > > > > Dan. > > > > On Thu, 14 Jun 2001 12:45:39 EDT you wrote > > > Dan, > > > > > > Since the phase 1 goal is to auth DH-key exchange. > > > The DH key is generated *after* auth anyway. > > > > > > However, > > > the pre-shared key (pass-phrase) authetication cost less (and stateless) > > > > for responder to verify than "public key" authentication. > > > > > > Regards, > > > > > > --- David > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 14 14:20:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ELK8J28139; Thu, 14 Jun 2001 14:20:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14917 Thu, 14 Jun 2001 16:35:34 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD76E@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Thu, 14 Jun 2001 16:37:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Derek, For aggress mode, the first message from responder will have the DH-key? Aslo, if initiator's IP address is meaningfull (without linking to an auth method) then it may not a good idea let IKE traverse through NAPT devices. Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Thursday, June 14, 2001 4:02 PM To: Chen, David Cc: 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT An unreachable IP Address would never get beyond message 2. DH doesn't happen at the responder until message 4. So you are protected against unreachable addresses. In other words, no, the IP address is NOT meaningless. It means the address is reachable _and_ interested in an IKE protocol instantiation. True, we are still subject to DDoS zombies using their own IP Address, but again, as I said, we now know _who_ is attacking us (because they are actually responding to message 2 with a valid message 3), and we can just rate-limit those addresses. Ok, I'm lying a bit. What we actually know that the attacker is somewhere on the network path between the responder and the IP Address of the initiator, such that it can read the IKE messages and grab the responder cookie in order to send message 3. -derek "Chen, David" writes: > Derek, > I heard that DDOS can steal someone's computer (with IP address) to > perform the attack. > Also, it could be an unreachable IP address the attacker invented (or > plotted). > > The IP addess seems meaningless, unless > it is linked to a auth method such as preshared key. > > Regards, > > --- David > > > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Thursday, June 14, 2001 3:50 PM > To: Chen, David > Cc: 'Dan Harkins'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > Well, it's not -random- DoS. The attacker must at least respond > to message 2 with message 3 before the responder will do any work. > This implies that the attacker must make their actual IP address > known to the attacked. > > So, you may be forced to execute a DH exponentiation as a responder, > but you at least know _WHO_ (IP Address) caused you to perform the > operation. > > -derek > > "Chen, David" writes: > > > Dan, > > > > Exactly, today's phase 1 > > do DH key number crunching before auth the peer. > > (well I think it is only intend to check integrity of the messages, > > but pre-shared key having more than that it also auth peer.) > > > > DH key generation cost much more than simple pass-phrase verification. > > > > Random DOS attacks can be reduced, if responder > > auth peer first (first tier auth) before crunching the DH-key. > > > > Regards, > > > > --- David > > > > > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Thursday, June 14, 2001 2:36 PM > > To: Chen, David > > Cc: ipsec@lists.tislabs.com > > Subject: Re: IPSEC Security Gateways & NAT > > > > > > No, the DH secret is generated *before* authentication. Re-read the RFC. > > > > Dan. > > > > On Thu, 14 Jun 2001 12:45:39 EDT you wrote > > > Dan, > > > > > > Since the phase 1 goal is to auth DH-key exchange. > > > The DH key is generated *after* auth anyway. > > > > > > However, > > > the pre-shared key (pass-phrase) authetication cost less (and stateless) > > > > for responder to verify than "public key" authentication. > > > > > > Regards, > > > > > > --- David > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 14 14:51:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ELp1J29055; Thu, 14 Jun 2001 14:51:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14958 Thu, 14 Jun 2001 16:52:40 -0400 (EDT) To: "Chen, David" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD76E@mail.ellacoya.com> From: Derek Atkins Date: 14 Jun 2001 16:51:01 -0400 In-Reply-To: "Chen, David"'s message of "Thu, 14 Jun 2001 16:37:00 -0400" Message-ID: Lines: 39 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Derek, > Derek, > > For aggress mode, the first message from responder will have the DH-key? We were talking about Main Mode, not "aggress" [sic] mode. I don't know enough about the properties of Aggressive Mode to fully reply, but as that wasn't the original discussion, I don't think it's apt. Besides, any host that is under an attack should back off aggressive mode and require a "resend with cookie" from any initiator. > Aslo, if initiator's IP address is meaningfull (without linking to an auth > method) > then it may not a good idea let IKE traverse through NAPT devices. The address isn't meaningful per se. It's meaningful to meet the reachability requirement. All I know from the IP Address is that if I (responder) receive a valid message 3, then I know that I've got a reachable IP Address. In other words, this is the same IP Address that contacted me with a message 1. All a NAPT device implies is that there could be any number of real hosts behind the NAPT device that is the bad guy. The responder can't tell, and neither can their network provider. So, you just boink the whole network behind the NAPT device. No big loss. > Regards, > > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jun 14 16:08:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EN8hJ00925; Thu, 14 Jun 2001 16:08:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15222 Thu, 14 Jun 2001 18:24:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20010614143654.04147d48@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 15:27:29 -0700 To: "Hilarie Orman" From: Mark Baugher Subject: Re: [MSEC] Re: multicast authentication using AH Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So it might not be a no brainer to put digital signatures in ESP or AH. At 02:46 PM 6/13/2001 -0600, Hilarie Orman wrote: >Might also want to encode an ident somewhere. GDOI does this in its Phase 2. >Should there be an option for attaching a cert to the message, >or would you see that being done solely by key mgmt (group mgr >would multicast sender certs to the group)? GDOI does this as part of its key management over pairwise and multicast connections. >Maintaining many certs does complicate SA mgmt, it's like having >many keys/SA. I don't think having multiple authorizations, such as to belong to multiple groups, requires having a unique signature key for each authorization. Mark >Hilarie > > >>> Dan McDonald 06/13/01 08:14AM >>> > > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > >There's nothing, I believe, about AH that prevents digital signatures from > > >being used. > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > > > >Dan > > > > How is this signalled? > >It's part of the IPsec Security Association data. Per 2401, an SA is indexed >by the tuple . When you add the appropriate >SA, you get all sorts of data, including the algorithm. > >All one would need to do is write a new "algorithm document" for using a >digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) >I could easily prototype one in Solaris. > >Dan From owner-ipsec@lists.tislabs.com Thu Jun 14 16:50:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ENoFJ01979; Thu, 14 Jun 2001 16:50:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15330 Thu, 14 Jun 2001 19:18:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20010614162130.020e9c70@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Jun 2001 16:21:45 -0700 To: "Hilarie Orman" From: Mark Baugher Subject: Re: [MSEC] Re: multicast authentication using AH Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:39 PM 6/14/2001 -0600, you wrote: >Well, maybe a small-brainer. A new DOI for IKE? >If there are multiple senders, then a recipient needs a cert from each >of them. Thus, the single SA with multiple keys. I see. Mark >Hilarie > > >>> Mark Baugher 06/14/01 04:27PM >>> >So it might not be a no brainer to put digital signatures in ESP or AH. > >At 02:46 PM 6/13/2001 -0600, Hilarie Orman wrote: > >Might also want to encode an ident somewhere. > >GDOI does this in its Phase 2. > > > >Should there be an option for attaching a cert to the message, > >or would you see that being done solely by key mgmt (group mgr > >would multicast sender certs to the group)? > >GDOI does this as part of its key management over pairwise and >multicast connections. > > > >Maintaining many certs does complicate SA mgmt, it's like having > >many keys/SA. > >I don't think having multiple authorizations, such as to belong to >multiple groups, requires having a unique signature key for each >authorization. > >Mark > > > >Hilarie > > > > >>> Dan McDonald 06/13/01 08:14AM >>> > > > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > > > >There's nothing, I believe, about AH that prevents digital > signatures from > > > >being used. > > > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > > >8kbits) per 2402. That should be plenty of room for a digital > signature. > > > > > > > >Dan > > > > > > How is this signalled? > > > >It's part of the IPsec Security Association data. Per 2401, an SA is > indexed > >by the tuple . When you add the > appropriate > >SA, you get all sorts of data, including the algorithm. > > > >All one would need to do is write a new "algorithm document" for using a > >digital signature with AH. It shouldn't be tough, and if I had cycles > (HAH!) > >I could easily prototype one in Solaris. > > > >Dan > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec From owner-ipsec@lists.tislabs.com Fri Jun 15 05:14:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FCEtJ17392; Fri, 15 Jun 2001 05:14:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16356 Fri, 15 Jun 2001 07:14:00 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 14 Jun 2001 16:39:05 -0600 From: "Hilarie Orman" To: Cc: , Subject: Re: [MSEC] Re: multicast authentication using AH 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 SAA15247 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, maybe a small-brainer. If there are multiple senders, then a recipient needs a cert from each of them. Thus, the single SA with multiple keys. Hilarie >>> Mark Baugher 06/14/01 04:27PM >>> So it might not be a no brainer to put digital signatures in ESP or AH. At 02:46 PM 6/13/2001 -0600, Hilarie Orman wrote: >Might also want to encode an ident somewhere. GDOI does this in its Phase 2. >Should there be an option for attaching a cert to the message, >or would you see that being done solely by key mgmt (group mgr >would multicast sender certs to the group)? GDOI does this as part of its key management over pairwise and multicast connections. >Maintaining many certs does complicate SA mgmt, it's like having >many keys/SA. I don't think having multiple authorizations, such as to belong to multiple groups, requires having a unique signature key for each authorization. Mark >Hilarie > > >>> Dan McDonald 06/13/01 08:14AM >>> > > > > AH SHOULD HAVE supported authentication with digital signatures. > > > > > >There's nothing, I believe, about AH that prevents digital signatures from > > >being used. > > > > > >The Authentication Data area can be made up to 1016 bytes (just shy of > > >8kbits) per 2402. That should be plenty of room for a digital signature. > > > > > >Dan > > > > How is this signalled? > >It's part of the IPsec Security Association data. Per 2401, an SA is indexed >by the tuple . When you add the appropriate >SA, you get all sorts of data, including the algorithm. > >All one would need to do is write a new "algorithm document" for using a >digital signature with AH. It shouldn't be tough, and if I had cycles (HAH!) >I could easily prototype one in Solaris. > >Dan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From owner-ipsec@lists.tislabs.com Fri Jun 15 08:34:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FFYEJ24996; Fri, 15 Jun 2001 08:34:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16807 Fri, 15 Jun 2001 10:18:51 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD76F@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 15 Jun 2001 10:21:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Consider the case: host<->NAT-WG<==>SG (responder) The NAT device changes all the SourceIP address to its own visible SrouceIP address. Since it is possible have several hosts are IKE initiator, it seems the IKE has to accept as many as messages the initiator sent with the same SIP address. The DOS attacker can using the same IP address and sending lots of 1 and 3 IKE messages to SG (with *HDR* variations)? Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@mit.edu] Sent: Thursday, June 14, 2001 4:51 PM To: Chen, David Cc: 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "Chen, David" writes: > Derek, > Derek, > > For aggress mode, the first message from responder will have the DH-key? We were talking about Main Mode, not "aggress" [sic] mode. I don't know enough about the properties of Aggressive Mode to fully reply, but as that wasn't the original discussion, I don't think it's apt. Besides, any host that is under an attack should back off aggressive mode and require a "resend with cookie" from any initiator. > Aslo, if initiator's IP address is meaningfull (without linking to an auth > method) > then it may not a good idea let IKE traverse through NAPT devices. The address isn't meaningful per se. It's meaningful to meet the reachability requirement. All I know from the IP Address is that if I (responder) receive a valid message 3, then I know that I've got a reachable IP Address. In other words, this is the same IP Address that contacted me with a message 1. All a NAPT device implies is that there could be any number of real hosts behind the NAPT device that is the bad guy. The responder can't tell, and neither can their network provider. So, you just boink the whole network behind the NAPT device. No big loss. > Regards, > > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Jun 15 10:21:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FHLjJ29504; Fri, 15 Jun 2001 10:21:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17186 Fri, 15 Jun 2001 12:19:34 -0400 (EDT) To: "Chen, David" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD76F@mail.ellacoya.com> From: Derek Atkins Date: 15 Jun 2001 12:25:20 -0400 In-Reply-To: "Chen, David"'s message of "Fri, 15 Jun 2001 10:21:37 -0400" Message-ID: Lines: 75 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Derek, > > Consider the case: > host<->NAT-WG<==>SG (responder) > > > The NAT device changes all the SourceIP address to its own > visible SrouceIP address. Yes, but each host behind the NAT device will have a unique port number on the NAT device.. Let's say we have: host1\ host2 +-<=> NAT <=> SG (responder) host3/ The SG will still see three unique addr/port pairs (because the NAT box will map host1/500 to NAT_ext/port1, host2/500 to NAT_ext/port2, etc). So the SG can still assign cookies individually. > Since it is possible have several hosts are IKE initiator, > it seems the IKE has to accept as many as messages > the initiator sent with the same SIP address. No, because the responder should generate a cookie based upon the source ip address _AND PORT_ obtained in message 1 (indeed, it could also be based on the initiator cookie, but that doesn't buy the responder much). As I just pointed out, the responder can still uniquely identify the individual initiators behind the NAT gateway based upon the unique port numbers. So an attacker would still have to present the correct cookie in message 3 based upon the port number the NAT box gives it. > The DOS attacker can using the same IP address and > sending lots of 1 and 3 IKE messages to > SG (with *HDR* variations)? If an attack exists here, NAT doesn't help (or hurt). If an initiator can send multiple message-3 requests based on a single message-1 cookie, then such an attack exists regardless of whether or not NAT is being used. There is a simple remedy to this attack: a) base the responder cookie on: i) the source ip address ii) the source port iii) the initiator cookie b) cache the message 4 response to message 3 Then if you get a 'duplicate' message 3 (where 'duplicate' means same same initiator/responder cookies) and the responder cookie verifies, the responder need only re-send the message 4 response without any additional work. Similarly, if the responder cookie does not verify, then something changed and the message can be dropped summarily. Using NAT doesn't change this behavior, and it still works fine. Indeed, this protection mechanism will still work, too. The only problem you have with NAT (in terms of DoS attacks) is that if one host is spewing tons of message-1's to a SG, you cannot figure out that it is host2 vs. host1, so you have to throttle ALL hosts behind the NAT box. > Regards, > > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Jun 15 10:28:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FHSjJ29638; Fri, 15 Jun 2001 10:28:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17263 Fri, 15 Jun 2001 12:49:45 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD775@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 15 Jun 2001 12:52:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, What I mean is, in order to traverse NAT, the responder has to respond a potential attacker that (may not behind NAT) initiates lots of (different) message1 and 3 by using only one SIP and different source port number. After this, the attacker still get the responder busy at DH key generation? (message 4) Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Friday, June 15, 2001 12:25 PM To: Chen, David Cc: 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "Chen, David" writes: > Derek, > > Consider the case: > host<->NAT-WG<==>SG (responder) > > > The NAT device changes all the SourceIP address to its own > visible SrouceIP address. Yes, but each host behind the NAT device will have a unique port number on the NAT device.. Let's say we have: host1\ host2 +-<=> NAT <=> SG (responder) host3/ The SG will still see three unique addr/port pairs (because the NAT box will map host1/500 to NAT_ext/port1, host2/500 to NAT_ext/port2, etc). So the SG can still assign cookies individually. > Since it is possible have several hosts are IKE initiator, > it seems the IKE has to accept as many as messages > the initiator sent with the same SIP address. No, because the responder should generate a cookie based upon the source ip address _AND PORT_ obtained in message 1 (indeed, it could also be based on the initiator cookie, but that doesn't buy the responder much). As I just pointed out, the responder can still uniquely identify the individual initiators behind the NAT gateway based upon the unique port numbers. So an attacker would still have to present the correct cookie in message 3 based upon the port number the NAT box gives it. > The DOS attacker can using the same IP address and > sending lots of 1 and 3 IKE messages to > SG (with *HDR* variations)? If an attack exists here, NAT doesn't help (or hurt). If an initiator can send multiple message-3 requests based on a single message-1 cookie, then such an attack exists regardless of whether or not NAT is being used. There is a simple remedy to this attack: a) base the responder cookie on: i) the source ip address ii) the source port iii) the initiator cookie b) cache the message 4 response to message 3 Then if you get a 'duplicate' message 3 (where 'duplicate' means same same initiator/responder cookies) and the responder cookie verifies, the responder need only re-send the message 4 response without any additional work. Similarly, if the responder cookie does not verify, then something changed and the message can be dropped summarily. Using NAT doesn't change this behavior, and it still works fine. Indeed, this protection mechanism will still work, too. The only problem you have with NAT (in terms of DoS attacks) is that if one host is spewing tons of message-1's to a SG, you cannot figure out that it is host2 vs. host1, so you have to throttle ALL hosts behind the NAT box. > Regards, > > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Jun 15 10:36:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FHamJ29784; Fri, 15 Jun 2001 10:36:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17291 Fri, 15 Jun 2001 12:55:58 -0400 (EDT) To: "Chen, David" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD775@mail.ellacoya.com> From: Derek Atkins Date: 15 Jun 2001 13:01:48 -0400 In-Reply-To: "Chen, David"'s message of "Fri, 15 Jun 2001 12:52:32 -0400" Message-ID: Lines: 116 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I said, this same attack can happen without NAT. A (non-NAT'ed) host can send lots of IKE messages from 'random' ports. However they have to be listening on each port in order to receive message 2 (with the responder cookie) and then send off message 3 in order to cause the responder to do any work. NAT doesn't change the viability of this attack. As I said before, if the responder is being attacked in this way, you throttle back by IP Address. -derek "Chen, David" writes: > Derek, > > What I mean is, in order to traverse NAT, the responder has > to respond a potential attacker that (may not behind NAT) > initiates lots of (different) message1 and 3 by using only one > SIP and different source port number. > After this, > the attacker still get the responder busy at DH key generation? (message 4) > > Regards, > > --- David > > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Friday, June 15, 2001 12:25 PM > To: Chen, David > Cc: 'Dan Harkins'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > "Chen, David" writes: > > > Derek, > > > > Consider the case: > > host<->NAT-WG<==>SG (responder) > > > > > > The NAT device changes all the SourceIP address to its own > > visible SrouceIP address. > > Yes, but each host behind the NAT device will have a unique port > number on the NAT device.. Let's say we have: > > host1\ > host2 +-<=> NAT <=> SG (responder) > host3/ > > The SG will still see three unique addr/port pairs (because the NAT > box will map host1/500 to NAT_ext/port1, host2/500 to NAT_ext/port2, > etc). So the SG can still assign cookies individually. > > > Since it is possible have several hosts are IKE initiator, > > it seems the IKE has to accept as many as messages > > the initiator sent with the same SIP address. > > No, because the responder should generate a cookie based upon the > source ip address _AND PORT_ obtained in message 1 (indeed, it could > also be based on the initiator cookie, but that doesn't buy the > responder much). As I just pointed out, the responder can still > uniquely identify the individual initiators behind the NAT gateway > based upon the unique port numbers. So an attacker would still have > to present the correct cookie in message 3 based upon the port number > the NAT box gives it. > > > The DOS attacker can using the same IP address and > > sending lots of 1 and 3 IKE messages to > > SG (with *HDR* variations)? > > If an attack exists here, NAT doesn't help (or hurt). If an initiator > can send multiple message-3 requests based on a single message-1 > cookie, then such an attack exists regardless of whether or not NAT is > being used. There is a simple remedy to this attack: > > a) base the responder cookie on: > i) the source ip address > ii) the source port > iii) the initiator cookie > b) cache the message 4 response to message 3 > > Then if you get a 'duplicate' message 3 (where 'duplicate' means same > same initiator/responder cookies) and the responder cookie verifies, > the responder need only re-send the message 4 response without any > additional work. Similarly, if the responder cookie does not verify, > then something changed and the message can be dropped summarily. > > Using NAT doesn't change this behavior, and it still works fine. > Indeed, this protection mechanism will still work, too. > > The only problem you have with NAT (in terms of DoS attacks) is that > if one host is spewing tons of message-1's to a SG, you cannot figure > out that it is host2 vs. host1, so you have to throttle ALL hosts > behind the NAT box. > > > Regards, > > > > --- David > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Jun 15 12:13:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FJDOJ02216; Fri, 15 Jun 2001 12:13:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17500 Fri, 15 Jun 2001 14:26:10 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD777@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Fri, 15 Jun 2001 14:28:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, The trouble is the responder can not tell if this an attack or just lots of users behind the same NAT try to connect at the same time. In addition, the DDOS can have many SIP attack at the same time. Even throttle on a address, it does not help to prevent using many SIP addresses attack. For message 1 and 2, the attacker and resonder will use (appx.) equal resource but message 3,4 is the attacker's goal, and it still be able do this. Maybe initiator's IP address need to link with auth? --- David -----Original Message----- From: Derek Atkins [mailto:warlord@mit.edu] Sent: Friday, June 15, 2001 1:02 PM To: Chen, David Cc: 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT As I said, this same attack can happen without NAT. A (non-NAT'ed) host can send lots of IKE messages from 'random' ports. However they have to be listening on each port in order to receive message 2 (with the responder cookie) and then send off message 3 in order to cause the responder to do any work. NAT doesn't change the viability of this attack. As I said before, if the responder is being attacked in this way, you throttle back by IP Address. -derek From owner-ipsec@lists.tislabs.com Mon Jun 18 12:30:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5IJURJ05627; Mon, 18 Jun 2001 12:30:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24046 Mon, 18 Jun 2001 14:15:44 -0400 (EDT) To: "Chen, David" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD777@mail.ellacoya.com> From: Derek Atkins Date: 18 Jun 2001 14:21:30 -0400 In-Reply-To: "Chen, David"'s message of "Fri, 15 Jun 2001 14:28:28 -0400" Message-ID: Lines: 49 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Derek, > > The trouble is the responder can not tell > if this an attack or just lots of users behind the > same NAT try to connect at the same time. > > In addition, the DDOS can have many SIP attack at the same time. > Even throttle on a address, it does not help to prevent using > many SIP addresses attack. I think this is just a problem with IKE in general. Let's not start mixing apples with oranges here. This conversation started on NAT traversal, and now is moving into general IKE DDoS protection. As I've said, NAT does not (IMHO) add any additional attacks that aren't already available without NAT. > For message 1 and 2, the attacker and resonder will use (appx.) equal > resource but message 3,4 is the attacker's goal, and it still > be able do this. Yes, but if an attacker at IP address X sends me several bogus "message 3" messages, or lots and lots of transactions, I can just blacklist that host. > Maybe initiator's IP address need to link with auth? Maybe. Maybe not. Certainly in the end of the process we have an authentication of the endopoint, although not necessarily the IP Address. Consider that a road-warrior practically NEVER has the same IP address, so authenticating the IP Address is meaningless. The question is: what attacks are you trying to protect against? What's your threat model? Considering IKE is already subject to DDoS attacks, I would suggest that if you consider DDoS a major threat, you need to fix IKE in that way. However that has nothing to do with IKE NAT Traversal. > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 18 13:23:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5IKN8J06856; Mon, 18 Jun 2001 13:23:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24350 Mon, 18 Jun 2001 15:38:02 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD77B@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 18 Jun 2001 15:40:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Here is my observation: In order let IKE packets traverse through NAT, the responder has to respond udp port number other than 500. For DOS attacker, he gains more attacking messages from a single address. In addition, as long as responder drop some real user's IKE messages (due to the mixing of real and attacked messages and throttling/blocked this same SIP of NAT device) the DOS attack is successfully denying others valid access to the responder. (although not as disaster as the responder is brought down). if no NAT allowed, the responder will only respond to udp port 500, Furthermore, the responder sure can block (not throttle) the SIP since it represents only one initiator (and is the attacker) Since the initiator's IP address could be the only id before DH-key exchange, it seems can help to reduce DOS attack? (by using pre-shared key to auth this ip-address before DH-key exchange) If this is the case, when traversing trough NAT, then tunneling IKE by encapsulating yet another UDP is a good method? Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Monday, June 18, 2001 2:22 PM To: Chen, David Cc: 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "Chen, David" writes: > Derek, > > The trouble is the responder can not tell > if this an attack or just lots of users behind the > same NAT try to connect at the same time. > > In addition, the DDOS can have many SIP attack at the same time. > Even throttle on a address, it does not help to prevent using > many SIP addresses attack. I think this is just a problem with IKE in general. Let's not start mixing apples with oranges here. This conversation started on NAT traversal, and now is moving into general IKE DDoS protection. As I've said, NAT does not (IMHO) add any additional attacks that aren't already available without NAT. > For message 1 and 2, the attacker and resonder will use (appx.) equal > resource but message 3,4 is the attacker's goal, and it still > be able do this. Yes, but if an attacker at IP address X sends me several bogus "message 3" messages, or lots and lots of transactions, I can just blacklist that host. > Maybe initiator's IP address need to link with auth? Maybe. Maybe not. Certainly in the end of the process we have an authentication of the endopoint, although not necessarily the IP Address. Consider that a road-warrior practically NEVER has the same IP address, so authenticating the IP Address is meaningless. The question is: what attacks are you trying to protect against? What's your threat model? Considering IKE is already subject to DDoS attacks, I would suggest that if you consider DDoS a major threat, you need to fix IKE in that way. However that has nothing to do with IKE NAT Traversal. > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 18 14:52:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5ILqEJ14926; Mon, 18 Jun 2001 14:52:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24749 Mon, 18 Jun 2001 17:10:46 -0400 (EDT) To: "Chen, David" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD77B@mail.ellacoya.com> From: Derek Atkins Date: 18 Jun 2001 17:16:40 -0400 In-Reply-To: "Chen, David"'s message of "Mon, 18 Jun 2001 15:40:20 -0400" Message-ID: Lines: 130 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unfortunately the double encapsulation is just as bad as opening up all ports. There is no verification that the Source IP is correct until it's too late in the process. The initiator can put any information they want in the 'inside' header to make it look like anything they want. The outside header can be anything as well, provided that there is something "listening" on that port. For example, an attacker can use the encapsulation method similarly to how you proposed using an open port. They sit at a machine of address 1.2.3.4, port Y, and spew out messages that look like: ((10.0.0.1/500) 1.2.3.4/Y) -> responder/500 ((10.0.0.2/500) 1.2.3.4/Y) -> responder/500 And so on. Again, there is no way for the responder to know whether there is a single attacking machine or multiple NAT'ed machines. So, you either have to accept the fact that a responder cannot differentiate between a single SIP attack and a lot of real connections from behind a NAT, or we have no NAT traversal, or you have to give up initiator ID protection from passive eavesdroppers. Like all things in computing, it is a choice, a tradeoff. Having been stuck behind NAT's, I would certainly prefer to _have_ some NAT traversal potential, so I would hope we do not choose "no NAT traversal". That leaves either losing ID protection or accepting that loaded NATs may be considered attackers, or coming up with a completely different protocol (perhaps with many more messages) to try to defeat these DDoS attacks. -derek "Chen, David" writes: > Derek, > > Here is my observation: > > In order let IKE packets traverse through NAT, > the responder has to respond udp port number other than 500. > For DOS attacker, he gains more attacking messages from a single address. > In addition, as long as responder drop some real user's IKE messages > (due to the mixing of real and attacked messages and throttling/blocked > this same SIP of NAT device) > the DOS attack is successfully denying others valid access to the > responder. (although not as disaster as the responder is brought down). > > if no NAT allowed, the responder will only respond to udp port 500, > Furthermore, the responder sure can block (not throttle) the SIP since it > represents only one initiator (and is the attacker) > > Since the initiator's IP address could be the only id before DH-key > exchange, > it seems can help to reduce DOS attack? > (by using pre-shared key to auth this ip-address before DH-key exchange) > > If this is the case, when traversing trough NAT, > then tunneling IKE by encapsulating yet another UDP is a good method? > > Regards, > > --- David > > > > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Monday, June 18, 2001 2:22 PM > To: Chen, David > Cc: 'Dan Harkins'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > "Chen, David" writes: > > > Derek, > > > > The trouble is the responder can not tell > > if this an attack or just lots of users behind the > > same NAT try to connect at the same time. > > > > In addition, the DDOS can have many SIP attack at the same time. > > Even throttle on a address, it does not help to prevent using > > many SIP addresses attack. > > I think this is just a problem with IKE in general. Let's not start > mixing apples with oranges here. This conversation started on NAT > traversal, and now is moving into general IKE DDoS protection. > > As I've said, NAT does not (IMHO) add any additional attacks > that aren't already available without NAT. > > > For message 1 and 2, the attacker and resonder will use (appx.) equal > > resource but message 3,4 is the attacker's goal, and it still > > be able do this. > > Yes, but if an attacker at IP address X sends me several bogus > "message 3" messages, or lots and lots of transactions, I can just > blacklist that host. > > > Maybe initiator's IP address need to link with auth? > > Maybe. Maybe not. Certainly in the end of the process we have an > authentication of the endopoint, although not necessarily the IP > Address. Consider that a road-warrior practically NEVER has the same > IP address, so authenticating the IP Address is meaningless. > > The question is: what attacks are you trying to protect against? > What's your threat model? Considering IKE is already subject to > DDoS attacks, I would suggest that if you consider DDoS a major > threat, you need to fix IKE in that way. However that has nothing > to do with IKE NAT Traversal. > > > --- David > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 18 16:04:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5IN4LJ17307; Mon, 18 Jun 2001 16:04:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24905 Mon, 18 Jun 2001 18:21:41 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD77C@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 18 Jun 2001 18:24:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, If IKE using the IP address as Id before DH-exchange (but still keep today's protected ID auth after DH-exchange), it can use simple pre-shared key to check this IP address (before DH-exchange). Either IKE traversing NAT or not, the inner IP address will be authenticated by a pre-shared key. A very simple method will be adding the pre-shared key /with random number appended to the message string before calculating hash. The ip address-auth process is added before today's DH-key exchange. Functionally speaking, The inner IP address for the new tunneled IKE messages are for Id and could be unreachable. Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Monday, June 18, 2001 5:17 PM To: Chen, David Cc: 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT Unfortunately the double encapsulation is just as bad as opening up all ports. There is no verification that the Source IP is correct until it's too late in the process. The initiator can put any information they want in the 'inside' header to make it look like anything they want. The outside header can be anything as well, provided that there is something "listening" on that port. For example, an attacker can use the encapsulation method similarly to how you proposed using an open port. They sit at a machine of address 1.2.3.4, port Y, and spew out messages that look like: ((10.0.0.1/500) 1.2.3.4/Y) -> responder/500 ((10.0.0.2/500) 1.2.3.4/Y) -> responder/500 And so on. Again, there is no way for the responder to know whether there is a single attacking machine or multiple NAT'ed machines. So, you either have to accept the fact that a responder cannot differentiate between a single SIP attack and a lot of real connections from behind a NAT, or we have no NAT traversal, or you have to give up initiator ID protection from passive eavesdroppers. Like all things in computing, it is a choice, a tradeoff. Having been stuck behind NAT's, I would certainly prefer to _have_ some NAT traversal potential, so I would hope we do not choose "no NAT traversal". That leaves either losing ID protection or accepting that loaded NATs may be considered attackers, or coming up with a completely different protocol (perhaps with many more messages) to try to defeat these DDoS attacks. -derek "Chen, David" writes: > Derek, > > Here is my observation: > > In order let IKE packets traverse through NAT, > the responder has to respond udp port number other than 500. > For DOS attacker, he gains more attacking messages from a single address. > In addition, as long as responder drop some real user's IKE messages > (due to the mixing of real and attacked messages and throttling/blocked > this same SIP of NAT device) > the DOS attack is successfully denying others valid access to the > responder. (although not as disaster as the responder is brought down). > > if no NAT allowed, the responder will only respond to udp port 500, > Furthermore, the responder sure can block (not throttle) the SIP since it > represents only one initiator (and is the attacker) > > Since the initiator's IP address could be the only id before DH-key > exchange, > it seems can help to reduce DOS attack? > (by using pre-shared key to auth this ip-address before DH-key exchange) > > If this is the case, when traversing trough NAT, > then tunneling IKE by encapsulating yet another UDP is a good method? > > Regards, > > --- David > > > > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Monday, June 18, 2001 2:22 PM > To: Chen, David > Cc: 'Dan Harkins'; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > "Chen, David" writes: > > > Derek, > > > > The trouble is the responder can not tell > > if this an attack or just lots of users behind the > > same NAT try to connect at the same time. > > > > In addition, the DDOS can have many SIP attack at the same time. > > Even throttle on a address, it does not help to prevent using > > many SIP addresses attack. > > I think this is just a problem with IKE in general. Let's not start > mixing apples with oranges here. This conversation started on NAT > traversal, and now is moving into general IKE DDoS protection. > > As I've said, NAT does not (IMHO) add any additional attacks > that aren't already available without NAT. > > > For message 1 and 2, the attacker and resonder will use (appx.) equal > > resource but message 3,4 is the attacker's goal, and it still > > be able do this. > > Yes, but if an attacker at IP address X sends me several bogus > "message 3" messages, or lots and lots of transactions, I can just > blacklist that host. > > > Maybe initiator's IP address need to link with auth? > > Maybe. Maybe not. Certainly in the end of the process we have an > authentication of the endopoint, although not necessarily the IP > Address. Consider that a road-warrior practically NEVER has the same > IP address, so authenticating the IP Address is meaningless. > > The question is: what attacks are you trying to protect against? > What's your threat model? Considering IKE is already subject to > DDoS attacks, I would suggest that if you consider DDoS a major > threat, you need to fix IKE in that way. However that has nothing > to do with IKE NAT Traversal. > > > --- David > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Jun 18 19:41:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5J2f7J22930; Mon, 18 Jun 2001 19:41:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25155 Mon, 18 Jun 2001 21:24:28 -0400 (EDT) To: "jshukla" Cc: "Chen, David" , "'Dan Harkins'" , Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD77C@mail.ellacoya.com> <004d01c0f85a$82af5e50$e4b02304@ffb5b> From: Derek Atkins Date: 18 Jun 2001 21:30:24 -0400 In-Reply-To: "jshukla"'s message of "Mon, 18 Jun 2001 17:55:14 -0700" Message-ID: Lines: 40 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "jshukla" writes: > This is a very good point! In pre-shared key based > authentication, there is no reason that the authentication > must wait until the DH related work is done. Authenticating > prior to DH can potentially make the IKE even more > resistant to DoS attacks under pre-shared key. Already the > anti-clogging cookies ensures that the attacker must perform > almost equal amount of work until message 4. With source > authentication before DH, we need not perform the work that > is necessary to process message 5.... if the source is not > authenticated. However in order for pre-shared key to work as you suggest (authentication before DH) you have to know a-priori the ID of your peer in order to perform the authentication. This implies that either: a) you have to deny ID protection and send IDs in the clear early in the protocol, or b) you have use IP Addresses as names. You cannot use IP Addresses as names when traversing NAT, because the IP Address is going to be changed by the NAT gateway to an unknown address. So, you either have to send IDs in the clear, or you have to perform the DH first. Note than an attacking initiator need not request pre-shared keys in order to mount a DDoS attack against a responder. Other authentication means are just as susceptible. > regards, > Jayant -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 19 05:19:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JCJMJ05809; Tue, 19 Jun 2001 05:19:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26596 Tue, 19 Jun 2001 07:12:21 -0400 (EDT) Message-ID: <3B2EEFFC.9EC6BD1C@pgp.com> Date: Mon, 18 Jun 2001 23:23:56 -0700 From: Will Price Reply-To: wprice@pgp.com X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "'ipsec@lists.tislabs.com'" Subject: Bakeoff? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I saw one message a while ago giving vague details about a next Bakeoff August 13-18 in Finland. Is there a web page for this? Is this definite? Are all the usual suspects planning to attend? Thanks. -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Tue Jun 19 05:19:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JCJWJ05855; Tue, 19 Jun 2001 05:19:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26574 Tue, 19 Jun 2001 07:11:21 -0400 (EDT) Message-ID: <004d01c0f85a$82af5e50$e4b02304@ffb5b> From: "jshukla" To: "Chen, David" , "'Derek Atkins'" Cc: "'Dan Harkins'" , References: <85D31AAF3DFCD4119C44000102C009707DD77C@mail.ellacoya.com> Subject: Re: IPSEC Security Gateways & NAT Date: Mon, 18 Jun 2001 17:55:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Chen, David" > > If IKE using the IP address as Id before DH-exchange (but > still keep today's protected ID auth after DH-exchange), > it can use simple pre-shared key to check this IP address (before > DH-exchange). > > Either IKE traversing NAT or not, the inner IP address will be authenticated > by a pre-shared key. > A very simple method will be adding the pre-shared key /with random number > appended to the message string before calculating hash. > This sounds good, but you must ensure that the verifier has access to the same random number.;-) You could also just use quantities that are known to both parties (cookies?) and compute a hash using the shared key. > The ip address-auth process is added before > today's DH-key exchange. > This is a very good point! In pre-shared key based authentication, there is no reason that the authentication must wait until the DH related work is done. Authenticating prior to DH can potentially make the IKE even more resistant to DoS attacks under pre-shared key. Already the anti-clogging cookies ensures that the attacker must perform almost equal amount of work until message 4. With source authentication before DH, we need not perform the work that is necessary to process message 5.... if the source is not authenticated. regards, Jayant From owner-ipsec@lists.tislabs.com Tue Jun 19 07:32:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JEW4J12489; Tue, 19 Jun 2001 07:32:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27000 Tue, 19 Jun 2001 09:48:27 -0400 (EDT) Reply-To: From: "=?iso-8859-1?Q?Tuomas_A._Sir=E9n?=" To: Subject: VPN Bakeoff, Finland, August 13 thru 18, http://bakeoff.ipsec.com/ Date: Tue, 19 Jun 2001 16:50:46 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk http://bakeoff.ipsec.com/ The next IPsec Interoperability workshop a.k.a Bakeoff will be held in Finland from August 13 thru 18 (Monday - Saturday). This is the week following the IETF meeting in London, so you may combine your travelling. The venue will be Dipoli (http://www.dipoli.hut.fi/english/) in Espoo (close to Helsinki) in the Helsinki University of Technology campus area. Flight destination will be Helsinki (Helsinki-Vantaa international airport - about 3 hour flight from London), the Bakeoff venue is under 30 minute (20 km) drive south-west from the airport, 10 km (6 miles) from downtown Helsinki. The event will start on Monday afternoon i.e. the participants may start installing their equipment then. The final day is Saturday, all equipment must be removed Saturday afternoon. There will be no storage space available before the bakeoff, therefore, you will have to schedule arrival of your equipment to Monday afternoon. The nearest hotel is Radisson SAS Espoo (http://www.hotelsfinland.com/espoo/rivoli_espoo/) only two minutes walk from Dipoli. We have reserved some 100 rooms for bakeoff attendees. If you book your hotel room at this hotel through your own channels already before registering, please, mention Bakeoff when making the reservation. Other hotels are available in Helsinki, next closest is probably Kalastajatorppa (http://www.scandic-hotels.com/br/50/hotel.asp?id=107) about 4 km (2.5 miles) from Dipoli. -Tuomas A. SirÈn tuomas.siren@ssh.com SSH Communications Security Corporation From owner-ipsec@lists.tislabs.com Tue Jun 19 07:35:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JEZEJ12560; Tue, 19 Jun 2001 07:35:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26964 Tue, 19 Jun 2001 09:36:20 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD77D@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" , jshukla Cc: "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Tue, 19 Jun 2001 09:38:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Id protection still valid as of today's mechanism (after DH-key exchange). The IP address is not a user Id for user authorization, authentication. The IP address is the machine Id (and maybe group user id) that will help to reduce randomly DOS attack *only*. If we tunneled the IKE message, the inner IP address is not altered by the NAT device(s) that in-between two SGs. It could be unreachable addresses. Either NAT existing or not, the outer IP address are reachable address the inner address may or may not routable and only for preventing DOS attack. As for the mechanism, it seems enough by using as simple as modified CHAP mechanism with the freedom of choosing hashing algorithm. The random number is visible but to protect from replay attack. (replay helps DOS attack) It is idea to let initiator to generate random number. Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Monday, June 18, 2001 9:30 PM To: jshukla Cc: Chen, David; 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "jshukla" writes: > This is a very good point! In pre-shared key based > authentication, there is no reason that the authentication > must wait until the DH related work is done. Authenticating > prior to DH can potentially make the IKE even more > resistant to DoS attacks under pre-shared key. Already the > anti-clogging cookies ensures that the attacker must perform > almost equal amount of work until message 4. With source > authentication before DH, we need not perform the work that > is necessary to process message 5.... if the source is not > authenticated. However in order for pre-shared key to work as you suggest (authentication before DH) you have to know a-priori the ID of your peer in order to perform the authentication. This implies that either: a) you have to deny ID protection and send IDs in the clear early in the protocol, or b) you have use IP Addresses as names. You cannot use IP Addresses as names when traversing NAT, because the IP Address is going to be changed by the NAT gateway to an unknown address. So, you either have to send IDs in the clear, or you have to perform the DH first. Note than an attacking initiator need not request pre-shared keys in order to mount a DDoS attack against a responder. Other authentication means are just as susceptible. > regards, > Jayant -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 19 07:49:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JEnBJ12899; Tue, 19 Jun 2001 07:49:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27046 Tue, 19 Jun 2001 10:03:43 -0400 (EDT) To: "Chen, David" Cc: jshukla , "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD77D@mail.ellacoya.com> From: Derek Atkins Date: 19 Jun 2001 10:09:42 -0400 In-Reply-To: "Chen, David"'s message of "Tue, 19 Jun 2001 09:38:37 -0400" Message-ID: Lines: 82 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Derek, > > Id protection still valid as of today's mechanism (after DH-key exchange). > The IP address is not a user Id for user authorization, authentication. Except that in this case the enclosed ID means absolutely nothing. Indeed, that ID _must_ be the IP Address. > The IP address is the machine Id (and maybe group user id) > that will help to reduce randomly DOS attack *only*. Insufficient. A road-warrior does not necessarily know their IP Address, because the IP Address is always changing. Unless you recommend that road-warriors use a pre-defined, "non-routable" IP Address as their ID and ALWAYS just encapsulate that "special" SIP in their currently real address? > If we tunneled the IKE message, the inner IP address is not altered by the > NAT device(s) that in-between two SGs. > It could be unreachable addresses. > Either NAT existing or not, the outer IP address are reachable address the > inner address may or may not routable and only for preventing DOS attack. Right, as I said above, you could always have the inner IP Address be some pre-determined, static, non-routable address which can be used to assure linkability as a road-warrior moves. In other words, your inner IP is your ID, and you are sending your ID in the clear. If you are going to do that, you might as well just send an ID payload as part of the initial exchange. In my mind, this means you are willing to live without Identity Protection (because, indeed, the Identity MUST be the Source IP Address -- in your case the "inner" IP Address). As I said, the IDs "protected" in messages 5 and 6 means nothing, as they MUST be the SIPs in order for anything to work right. Either that, or you need to share _TWO_ sets of keys, one for the SIP, and one for the actual protected ID. But you don't seem to be talking about this, so I assume you are talking about the existing standard where the ID must be the SIP. > As for the mechanism, > it seems enough by using as simple as modified CHAP mechanism with > the freedom of choosing hashing algorithm. > The random number is visible but > to protect from replay attack. (replay helps DOS attack) > It is idea to let initiator to generate random number. Since you seem to feel that ID protection isn't necessary for pre-shared key authentication, why not just change the protocol so the endpoints send their IDs in the clear as part of messages 1 and 2 (or perhaps 2 and 3?). Then you can use a MAC based on the shared secret to verify messages 3 and 4. This solves the DoS problem for pre-shared auth. However, it doesn't solve it for other auth mechanisms. You seem to be willing to give up "privacy" (ID protection) for "security" (some protection against DoS). Please remember the immortal words of an American Forefather who said (paraphrased): "he who gives up privacy for security will live with neither." As I keep saying (and this is the LAST time I will say it -- I will ignore any more messages on the topic): If you want to protect against DoS, then build a DoS protection protocol that works for ALL of IKE. And unfortunately I (and many other people) do not believe that giving up ID protection is a valid (or necessary) step to protect against DoS. Have a Nice Day. -derek PS: If you'd like to continue this discussion, I suggest you come to London and we can spend as much time as you would like talking about this. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 19 08:27:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JFRhJ13992; Tue, 19 Jun 2001 08:27:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27135 Tue, 19 Jun 2001 10:31:51 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD77E@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: jshukla , "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Tue, 19 Jun 2001 10:34:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Id protection is important. That's why today's IKE exchange ID and authentication peer after secured communication channel - i.e. DH-key exchange. In the real world, one person have several different ids in different domain of society. Each of them has different function and "privacy". However, collectively, these Ids perceived by environment as an unique Id. The suggestion here, is adding one *more* id beside what IKE had to improve IKE's resistance to DOS attack. It will not reduce today's Id protection security but add one more to reduce DOS attack. You have a nice vacation-flight to UK. I will land mine in my backyard. --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Tuesday, June 19, 2001 10:10 AM To: Chen, David Cc: jshukla; 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "Chen, David" writes: > Derek, > > Id protection still valid as of today's mechanism (after DH-key exchange). > The IP address is not a user Id for user authorization, authentication. Except that in this case the enclosed ID means absolutely nothing. Indeed, that ID _must_ be the IP Address. > The IP address is the machine Id (and maybe group user id) > that will help to reduce randomly DOS attack *only*. Insufficient. A road-warrior does not necessarily know their IP Address, because the IP Address is always changing. Unless you recommend that road-warriors use a pre-defined, "non-routable" IP Address as their ID and ALWAYS just encapsulate that "special" SIP in their currently real address? > If we tunneled the IKE message, the inner IP address is not altered by the > NAT device(s) that in-between two SGs. > It could be unreachable addresses. > Either NAT existing or not, the outer IP address are reachable address the > inner address may or may not routable and only for preventing DOS attack. Right, as I said above, you could always have the inner IP Address be some pre-determined, static, non-routable address which can be used to assure linkability as a road-warrior moves. In other words, your inner IP is your ID, and you are sending your ID in the clear. If you are going to do that, you might as well just send an ID payload as part of the initial exchange. In my mind, this means you are willing to live without Identity Protection (because, indeed, the Identity MUST be the Source IP Address -- in your case the "inner" IP Address). As I said, the IDs "protected" in messages 5 and 6 means nothing, as they MUST be the SIPs in order for anything to work right. Either that, or you need to share _TWO_ sets of keys, one for the SIP, and one for the actual protected ID. But you don't seem to be talking about this, so I assume you are talking about the existing standard where the ID must be the SIP. > As for the mechanism, > it seems enough by using as simple as modified CHAP mechanism with > the freedom of choosing hashing algorithm. > The random number is visible but > to protect from replay attack. (replay helps DOS attack) > It is idea to let initiator to generate random number. Since you seem to feel that ID protection isn't necessary for pre-shared key authentication, why not just change the protocol so the endpoints send their IDs in the clear as part of messages 1 and 2 (or perhaps 2 and 3?). Then you can use a MAC based on the shared secret to verify messages 3 and 4. This solves the DoS problem for pre-shared auth. However, it doesn't solve it for other auth mechanisms. You seem to be willing to give up "privacy" (ID protection) for "security" (some protection against DoS). Please remember the immortal words of an American Forefather who said (paraphrased): "he who gives up privacy for security will live with neither." As I keep saying (and this is the LAST time I will say it -- I will ignore any more messages on the topic): If you want to protect against DoS, then build a DoS protection protocol that works for ALL of IKE. And unfortunately I (and many other people) do not believe that giving up ID protection is a valid (or necessary) step to protect against DoS. Have a Nice Day. -derek PS: If you'd like to continue this discussion, I suggest you come to London and we can spend as much time as you would like talking about this. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 19 10:34:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JHYwJ20827; Tue, 19 Jun 2001 10:34:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27360 Tue, 19 Jun 2001 12:28:37 -0400 (EDT) To: "jshukla" Cc: "Chen, David" , "'Dan Harkins'" , Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD77C@mail.ellacoya.com> <004d01c0f85a$82af5e50$e4b02304@ffb5b> <003501c0f8dc$8095d310$f6b02304@ffb5b> From: Derek Atkins Date: 19 Jun 2001 12:34:35 -0400 In-Reply-To: "jshukla"'s message of "Tue, 19 Jun 2001 09:25:31 -0700" Message-ID: Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "jshukla" writes: > Right! The point is that pre-shared keys based authentication > can be made more robust against DoS attacks compared to > the other three authentication methods. In their current form, > all authencitation methods are susceptible to DoS attacks. Well, an attacker need not request pre-shared key based authentication. Also, this DoS prevention is at the expense of ID protection. > regards, > Jayant -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 19 10:37:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JHbuJ20907; Tue, 19 Jun 2001 10:37:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27410 Tue, 19 Jun 2001 12:55:01 -0400 (EDT) Message-Id: <200106191651.f5JGowu00723@dharkins@lounge.orgatty.lounge.org> To: "jshukla" Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: Your message of "Tue, 19 Jun 2001 09:25:31 PDT." <003501c0f8dc$8095d310$f6b02304@ffb5b> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <720.992969458.1@lounge.org> Date: Tue, 19 Jun 2001 09:50:58 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 19 Jun 2001 09:25:31 PDT you wrote > > Right! The point is that pre-shared keys based authentication > can be made more robust against DoS attacks compared to > the other three authentication methods. In their current form, > all authencitation methods are susceptible to DoS attacks. The DoS attack mounted against IKE is one that exploits the fact that the responder creates state upon receipt of a single message from the initiator. That will not be addressed by moving the authentication step. It will be addressed by further complicating the protocol with a new stateless "cookie request" option. Your suggestion to move the authentication step would further complicate the protocol. The way it is now there is a uniform progression of state for each of the authentication methods. As someone who has implemented this protocol I can tell you it makes it much simpler to code that way. As has been pointed out repeatedly in this thread (and in the past) a DoS attack that attempts to force the responser to do needless Diffie- Hellman work would expose its IP address and the attack could be properly addressed because of it. There are all sorts of changes that can be made to IKE but one that would make the protocol much more complicated for such a small (perhaps even non-existent) benefit is not something we should consider. Dan. From owner-ipsec@lists.tislabs.com Tue Jun 19 11:00:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JI0LJ21507; Tue, 19 Jun 2001 11:00:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27463 Tue, 19 Jun 2001 13:19:10 -0400 (EDT) To: "Chen, David" Cc: jshukla , "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <85D31AAF3DFCD4119C44000102C009707DD77E@mail.ellacoya.com> From: Derek Atkins Date: 19 Jun 2001 13:25:08 -0400 In-Reply-To: "Chen, David"'s message of "Tue, 19 Jun 2001 10:34:43 -0400" Message-ID: Lines: 60 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chen, David" writes: > Derek, > > Id protection is important. > > That's why today's IKE exchange ID and authentication peer after secured > communication channel - i.e. DH-key exchange. Except that with pre-shared keys, there is no ID protection. The ID must be the Source IP Address, and that is world-visible to anyone. All the other mechanisms hide the ID within the DH. > In the real world, one person have several different ids in different domain > of society. Each of them has different function and "privacy". > However, collectively, these Ids perceived by environment as an unique Id. > > The suggestion here, is adding one *more* id beside what IKE had > to improve IKE's resistance to DOS attack. The difference is that generally one does not use multiple identities during one transaction. Any single transaction generally uses one single identity. For example, you present your credit card to a merchant, or you present your driver's license to a police officer, or you present your passport to a custom's agent. You are proposing IKE have TWO identities per transaction. The first is a pre-shared host key based upon some publically visible name (SIP or a message-1/message-2 ID payload) and the second is some other authentication based upon a protected identity. I think many people believe that this added complexity is not worth the benefits. Because I _know_ that IP Address 1.2.3.4 is bombarding me with IKE traffic (real or not), I can just throttle that traffic down. Your added cleartext-identity with pre-shared key: a) doesn't scale, and b) doesn't protect you from a DDoS zombie. > It will not reduce today's Id protection security but > add one more to reduce DOS attack. Considering there is no ID protection in pre-shared keys, it could hardly reduce it any more. > You have a nice vacation-flight to UK. > > I will land mine in my backyard. Who said anything about Vacation? I was referring to the IETF Meeting in August. > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 19 11:28:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JISCJ22094; Tue, 19 Jun 2001 11:28:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27513 Tue, 19 Jun 2001 13:47:52 -0400 (EDT) Message-ID: <003501c0f8dc$8095d310$f6b02304@ffb5b> From: "jshukla" To: "Derek Atkins" Cc: "Chen, David" , "'Dan Harkins'" , References: <85D31AAF3DFCD4119C44000102C009707DD77C@mail.ellacoya.com> <004d01c0f85a$82af5e50$e4b02304@ffb5b> Subject: Re: IPSEC Security Gateways & NAT Date: Tue, 19 Jun 2001 09:25:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Derek Atkins" > > > This is a very good point! In pre-shared key based > > authentication, there is no reason that the authentication > > must wait until the DH related work is done. Authenticating > > prior to DH can potentially make the IKE even more > > resistant to DoS attacks under pre-shared key. Already the > > anti-clogging cookies ensures that the attacker must perform > > almost equal amount of work until message 4. With source > > authentication before DH, we need not perform the work that > > is necessary to process message 5.... if the source is not > > authenticated. > > However in order for pre-shared key to work as you suggest > (authentication before DH) you have to know a-priori the ID of your > peer in order to perform the authentication. This implies that > either: > a) you have to deny ID protection and send IDs in > the clear early in the protocol, or > b) you have use IP Addresses as names. > I was talking about IKE and not IKE in presence of NAT. I have pointed out to you earlier that IKE does not work for pre-shared keys in main mode and ESPoUDP does not fix it. That e-mail is included at the bottom. Back to IKE in absence of NAT, standard practice in pre-shared key base authentication is to use IP addresses as names. The suggestion was to make it more robust to DoS attacks by authenticating before DH. > You cannot use IP Addresses as names when traversing NAT, because the > IP Address is going to be changed by the NAT gateway to an unknown > address. So, you either have to send IDs in the clear, or you have to > perform the DH first. > see earlier comment. > Note than an attacking initiator need not request pre-shared keys in > order to mount a DDoS attack against a responder. Other > authentication means are just as susceptible. > Right! The point is that pre-shared keys based authentication can be made more robust against DoS attacks compared to the other three authentication methods. In their current form, all authencitation methods are susceptible to DoS attacks. regards, Jayant ---------------------------------------------------------------------------- --- > ----- Original Message ----- > From: "Derek Atkins" Ok, yes, there is a problem with using pre-shared keys in main mode. -derek "jshukla" writes: > ----- Original Message ----- > From: "Derek Atkins" > > > HASH_I = pfr(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b) > > > > Um, I don't see anything here that necessarily depends upon the IP > > Address of either Initiator or Responder. Perhaps I am being dense, > > but could you please point out the specific term to which you refer? > > Keep in mind that the ID term is **NOT** necessarily tied to the IP > > Address, as you can use many types of ID (such as FQDN) that are > > "movable". > > > > Isn't there a problem in using pre-shared keys for authentication in > the main mode? The responder uses the IP address to look up the > pre-shared key. Because of NAT, it may not be able to look up the > correct pre-shared key?! If you use aggressive mode, you can overcome > this problem, but the authors of ESPinUSP proposal use the main > mode in their example. > > regards, > Jayant > > From owner-ipsec@lists.tislabs.com Tue Jun 19 11:32:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JIW4J22222; Tue, 19 Jun 2001 11:32:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27512 Tue, 19 Jun 2001 13:47:51 -0400 (EDT) Message-Id: <200106191429.f5JETtw02577@road.xisp.net> To: ipsec@lists.tislabs.com Cc: gnu@toad.com, interoperability@tsgcongress.fi Subject: Can we get the bakeoff registration in a non Java(tm) form? Reply-To: hugh@xisp.net Date: Tue, 19 Jun 2001 07:29:54 -0700 From: Hugh Daniel Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Since I do security work Java(TM or die) is turned off on all my machines, I vastly prefer HTML anyway for some reason... Can we get a copy of the registration form in something Internet friendly? Like maybe ASCII via this list or just a page of SSL secured HTML forms? Oh, and while I am at it maybe you could let my browser decide what font size to use? Or maybe I should just buy an MS-Intel machine to read your web site, would that be better? ||ugh Daniel hugh@freeswan.org Systems Testing & Project mis-Management The Linux FreeS/WAN Project http://www.freeswan.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: For the matching public key, finger the Reply-To: address. iQCVAwUBOy9h4FZpdJR7FBQRAQFg7QP/eD0D2E3DM9cM1mxGRWs1D+XCSZqWuBAo VapGA7QJ+zuQjZJCZ0zoo7gaSmMgF0iIk2FEP8mc20axUXUpF3/68VMI4Gkwm1Kt wdzt2ve6tEds7yRWjEJCMw7DiMBa3+2akWYJ3iR7g8aw8tiVNVK0gYv6qo00jd6L Sgiryz7kU1c= =aVIf -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jun 19 12:52:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JJqEJ24505; Tue, 19 Jun 2001 12:52:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27727 Tue, 19 Jun 2001 15:00:34 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD780@mail.ellacoya.com> From: "Chen, David" To: "'Derek Atkins'" Cc: jshukla , "'Dan Harkins'" , ipsec@lists.tislabs.com Subject: RE: IPSEC Security Gateways & NAT Date: Tue, 19 Jun 2001 15:03:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Welcome back Derek, There are plenty examples to have at least two authenticated id to proceed in the real life. The higher security, the more cross checking (could be implicitly) required. (Just image a few Derek Atkins out there, they all have valid driver license but I don't know which one (maybe 2) is the one (maybe 2) in this thread :-) If today's IKE has ID protection (well, not today's pre-shared key), how could the security is reduced if one CID (clear text id) (such as IP address) is added that does not link to PID (protected id)? Under this suggestion, any (D)DOS attacker has the CID but no pre-shared key/ pass-phrase the responder will not send any message if the first initiator's message does not pass hashing check. The "scale" is not an issue in the view of the domain "user" community. Potentially it will require "secured key distribution" that can happen in other channel and not real time. It is certainly not the "everyone is welcome" as today's IKE's first pair of messages. As for throttle method, the DOS attacker will successfully deny valid service request to responder if NAT traverse is enabled as we have analyzed. In addition, the DDOS still can make the responder throttle on five hundred addresses and no time for other process. (with or without NAT) Even the responder does not crash, the DOS goal is reached. The IKE's NAT traverse helps DOS attack. Or should I say "No NAT traverse will reduce DOS attack". Regards, --- David -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Tuesday, June 19, 2001 1:25 PM To: Chen, David Cc: jshukla; 'Dan Harkins'; ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT "Chen, David" writes: > Derek, > > Id protection is important. > > That's why today's IKE exchange ID and authentication peer after secured > communication channel - i.e. DH-key exchange. Except that with pre-shared keys, there is no ID protection. The ID must be the Source IP Address, and that is world-visible to anyone. All the other mechanisms hide the ID within the DH. > In the real world, one person have several different ids in different domain > of society. Each of them has different function and "privacy". > However, collectively, these Ids perceived by environment as an unique Id. > > The suggestion here, is adding one *more* id beside what IKE had > to improve IKE's resistance to DOS attack. The difference is that generally one does not use multiple identities during one transaction. Any single transaction generally uses one single identity. For example, you present your credit card to a merchant, or you present your driver's license to a police officer, or you present your passport to a custom's agent. You are proposing IKE have TWO identities per transaction. The first is a pre-shared host key based upon some publically visible name (SIP or a message-1/message-2 ID payload) and the second is some other authentication based upon a protected identity. I think many people believe that this added complexity is not worth the benefits. Because I _know_ that IP Address 1.2.3.4 is bombarding me with IKE traffic (real or not), I can just throttle that traffic down. Your added cleartext-identity with pre-shared key: a) doesn't scale, and b) doesn't protect you from a DDoS zombie. > It will not reduce today's Id protection security but > add one more to reduce DOS attack. Considering there is no ID protection in pre-shared keys, it could hardly reduce it any more. > You have a nice vacation-flight to UK. > > I will land mine in my backyard. Who said anything about Vacation? I was referring to the IETF Meeting in August. > --- David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 19 23:26:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5K6Qlk14662; Tue, 19 Jun 2001 23:26:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28993 Wed, 20 Jun 2001 01:29:37 -0400 (EDT) Message-ID: <20010620053503.62843.qmail@web8005.mail.in.yahoo.com> Date: Wed, 20 Jun 2001 06:35:03 +0100 (BST) From: =?iso-8859-1?q?ranjeet=20barve?= Subject: ESP Transport Mode Encryption Payload To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, While doing the Implementation of ESP in Transport mode,I am a bit confused about the amount of Data that goes for Encryption. Are the Pad Length and Next header fields a part of the cipher text along with the Payload? Also is the Padding calculated after considering the sum of (Payload + Pad Length + Next Header) to make it a multiple number of 8 bytes required for encryption by DES/3DES-CBC mode? Please let me know, Regards, Ranjeet Barve. ____________________________________________________________ Do You Yahoo!? For regular News updates go to http://in.news.yahoo.com From owner-ipsec@lists.tislabs.com Wed Jun 20 05:04:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KC4Wk15692; Wed, 20 Jun 2001 05:04:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29587 Wed, 20 Jun 2001 07:19:30 -0400 (EDT) Reply-To: From: "=?iso-8859-1?Q?Tuomas_A._Sir=E9n?=" To: Subject: The registration form URL (WAS: VPN Bakeoff, Finland, August 13 thru 18, http://bakeoff.ipsec.com/ (Re: Can we get the bakeoff registration in a non Java(tm) form?)) Date: Tue, 19 Jun 2001 23:14:53 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hugh Daniel" wrote in message > -----BEGIN PGP SIGNED MESSAGE----- > > Since I do security work Java(TM or die) is turned off on all my > machines, I vastly prefer HTML anyway for some reason... > Can we get a copy of the registration form in something Internet > friendly? Like maybe ASCII via this list or just a page of SSL > secured HTML forms? The registration form URL: https://services.tsgcongress.fi/interoperability/ Tested with Netscape with Java and Javascript disabled. > Oh, and while I am at it maybe you could let my browser decide what > font size to use? Or maybe I should just buy an MS-Intel machine to > read your web site, would that be better? Mumble. Sigh. Groan. Our (fi-ipsec-interop) outsourced web-design company seems to be too "marketing-enabled". Tuomas A. SirÈn tuomas.siren@ssh.com SSH Communications Security Corporation From owner-ipsec@lists.tislabs.com Wed Jun 20 05:09:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KC9dk15878; Wed, 20 Jun 2001 05:09:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29595 Wed, 20 Jun 2001 07:20:31 -0400 (EDT) Message-ID: <001901c0f904$8b9b4c90$f6b02304@ffb5b> From: "jshukla" To: "Dan Harkins" Cc: References: <200106191651.f5JGowu00723@dharkins@lounge.orgatty.lounge.org> Subject: Re: IPSEC Security Gateways & NAT Date: Tue, 19 Jun 2001 14:12:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Dan Harkins" > > The DoS attack mounted against IKE is one that exploits the fact that > the responder creates state upon receipt of a single message from the > initiator. That will not be addressed by moving the authentication > step. It will be addressed by further complicating the protocol with > a new stateless "cookie request" option. > Can't we just use the ISAKMP cookies instead of creating new ones? What criteria they don't fulfill? I agree that it will complicate the protocol as the HASH_I must be sent before DH and must be computed without relying on g^xy, if that is what you mean. > Your suggestion to move the authentication step would further complicate > the protocol. The way it is now there is a uniform progression of state > for each of the authentication methods. As someone who has implemented > this protocol I can tell you it makes it much simpler to code that way. > Yes it does complicate the protocol, but I am not suggesting changes to IKE. I am just curious why it is done the way it is done. > As has been pointed out repeatedly in this thread (and in the past) a > DoS attack that attempts to force the responser to do needless Diffie- > Hellman work would expose its IP address and the attack could be properly > addressed because of it. > Not necessarily....... The responder will perform DH if the reply includes the correct responder cookie. If a router is compromised (one that is in the path between the spoofed IP addresses and the target), you can spoof a whole bunch of addresses and send message 1's. Based on the message 2 from the responder, send replies with the correct cookies. I Guess this will make a successful DoS attack as the effort required to generate message 1's and 3's is not much. You can't even throttle on IP address as you are getting messages from different IP addresses. > There are all sorts of changes that can be made to IKE but one that > would make the protocol much more complicated for such a small (perhaps > even non-existent) benefit is not something we should consider. > I think IKE is pretty good. regards, Jayant From owner-ipsec@lists.tislabs.com Wed Jun 20 09:31:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KGVrk28740; Wed, 20 Jun 2001 09:31:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00361 Wed, 20 Jun 2001 11:20:32 -0400 (EDT) From: "Joseph D. Harwood" To: "ranjeet barve" , Subject: RE: ESP Transport Mode Encryption Payload Date: Wed, 20 Jun 2001 08:28:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010620053503.62843.qmail@web8005.mail.in.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pad Length and Next Header are encrypted. The total amount of data encrypted must be a multiple of 8 bytes (DES/3DES), so (Payload Data + Padding + 2) mod 8 = 0, where (+ 2) accounts for Pad Length and Next Header (1 byte each). Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ranjeet barve > Sent: Tuesday, June 19, 2001 10:35 PM > To: ipsec@lists.tislabs.com > Subject: ESP Transport Mode Encryption Payload > > > Hi, > While doing the Implementation of ESP in Transport > mode,I am a bit confused about the amount of Data that > goes for Encryption. > Are the Pad Length and Next header fields a part of > the cipher text along with the Payload? > Also is the Padding calculated after considering the > sum of (Payload + Pad Length + Next Header) to make it > a multiple number of 8 bytes required for encryption > by DES/3DES-CBC mode? > > Please let me know, > > Regards, > Ranjeet Barve. > > > ____________________________________________________________ > Do You Yahoo!? > For regular News updates go to http://in.news.yahoo.com From owner-ipsec@lists.tislabs.com Wed Jun 20 14:23:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KLN4k06553; Wed, 20 Jun 2001 14:23:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01029 Wed, 20 Jun 2001 16:13:15 -0400 (EDT) Date: Wed, 20 Jun 2001 23:13:27 +0300 (IDT) From: Hugo Krawczyk To: Ricky Charlet cc: dharkins@lounge.org, ipsec list Subject: Re: IPSEC Security Gateways & NAT In-Reply-To: <3B28EF1E.A66EAE0@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 14 Jun 2001, Ricky Charlet wrote: > Howdy, > > Question below: Answer below. > > Hugo Krawczyk wrote: > > > SKEYID and related key derivation is the SIMPLEST possible mechanism I can > > think of to support in a UNIFORM way the myriad of current requirements > > and options. I actually worked hard to make SKEYID the only changing piece > > with all of SKEYID_a/d/e and HASH_I/R all derived in the SAME way in > > spite of all the different modes. > > > > > > Hugo > > Dan Harkins wrote: > > > > > > Provided that the Diffie-Hellman is authenticated I guess we could say > > > that the resultant secret is something known only by the parties to > > > the exchange and therefore having g^xy (and not the pre-shared key) is > > > good enough. But I'm not a cryptographer and I didn't come up with the > > > key derivation. > > > > > > I'm all for simplifying and unifying SKEYID generation. Are there any > > > comments on this proposal? Hugo, are you out there? > > > > > > Dan. > > > > > > > > I have long been confused by the derivation of SKEYID. I'm certianly > not expert enough to suggest changing it, but I do request that we > formally document its design goals. As Dan menetions, using g^xy alone > for SKEYID in all cases seems entirely sufficient to me (and I'm sure to I don't think that Dan was suggesting what you say, but in any case such suggestion would make all non-signature modes insecure. In particular, the preshared mode. > most implementors). What goals/requiremetns lead us to wish to include > other elemetns and in 2 cases NOT use g^xy at all in SKEYID? I have written a note intended to give a high level answer to this. I'll send it next to the list. > > I have seen the assertion that SKEYID is a SIMPLE as it can be and yet > meet all the requirements. I've also seen the assertion that these other > data elements in SKEYID are ESSENTIAL to security. Well then, it sounds > like something I as an impelementor should be able to understand. I need > a document showing the design reqirements, how they lead to the current > SKEYID derivations and how these decisions shore up security. Preferably > in the form of a few added paragraphs to the son-of-ike draft. Please. The note is trying to explain this too (btw, what I called "essential" is the fact that SKEYID needs to be different in the different modes). The note maybe a bit too long to be included in son-of-ike draft, but Dan is welcome to transcribe any information from there to the draft. Hugo > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > From owner-ipsec@lists.tislabs.com Wed Jun 20 14:39:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KLdDk07045; Wed, 20 Jun 2001 14:39:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01107 Wed, 20 Jun 2001 16:56:29 -0400 (EDT) Date: Wed, 20 Jun 2001 23:23:19 +0300 (IDT) From: Hugo Krawczyk To: ipsec list Subject: Rationale for the definitions of SKEYID (long msg) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Recent discussion in the list have made clear the need for some clarification of the rationale behind the definition of SKEYID for each of the authentication modes in IKE. The following note is intended to provide an intuitive account of the basic cryptographic rationale behind these specifications without getting too technical. As with everything regarding cryptographic design, intuition alone is dangerous. So take this as a high-level (and simplistic) overview of the considerations. A full analysis of these modes would require far more elaboration. Note that this is not a discussion on the merits and need for the different authentication modes but an account of how, after the different authentication modes were selected, we designed the SKEYID derivation. (For reference I am appending at the end of this message the definitions of SKEYID and related elements from the IKE rfc) GUIDING PRINCIPLES (1) The main principle guiding this design was, of course, to make each of the authentication modes secure. (2) Second, to reduce the complexity of specification and implementation of the different modes by defining a mechanism for key derivation and key usage which is common to all modes. NOTE: this is achieved to a maximal degre by IKE where only the definition of SKEYID differs between modes, these differences are essential given the essential differences in the type of authentication credentials that each mode assumes. Hopefully the presentation below will help clarifying these issues. (3) Third, to use a single cryptographic function, "prf", for the derivation of all keys in the protocol. This simplifies the design, analysis, and implementation: if you choose a weak prf all fails, but if it is good then you are safe. This approach also makes sure that you are not using the same key to key two different algorithms ("key separation" principle). NOTE: PRFs, for pseudo-random functions, are powerful cryptographic tools: they provide for derivation of multiple keys that are indistinguishable from randomness and cryptographically independent from each other, and they provide mixing properties as we'll see later. They can be built out of any secure block cipher or keyed hash function, and do not require any idealized properties such as "random oracles". CBC-MAC and HMAC are common realizations. In addition to the above basic principles I have always adhered to the following rule: (4) Avoid using the result of a DH exchange, denoted by g^xy in IKE, as a direct key to cryptographic algorithms. Whenever possible first hash this value. Then use the hashed value as a key to a prf for deriving further keys. This has the effect of not relying on the security of each independent bit in g^xy but rather on the overall "cryptographic entropy" present in g^xy. NOTE: I won't get here into a deep cryptographic discussion of things like the "decisional DH assumption", etc., but let me just say that assuming all bits in g^xy to be all equally and simultaneously pseudorandom is, in my view, a too optimistic and unnecessary assumption, given that a simple and performance-insignificant hashing of the key can achieve a much better mixing. IKE uses its prf also to achieve this mixing. Moreover, in some cases (pre-shared and PK encryption modes) this prf-based mixing makes the key material dependent on a secret quantity in addition to g^xy; this means that even if the specific DH group in use is broken 10 years from now, the attacker that recorded the communication will still be unable to read it since it does not have the secret prf key which is independent from g^xy! (In the case of PK encryption mode the attacker will need to be able to break the PK encryption in addition to the DH group.) I personally prefer these added lines-of-defense than going to 5000-bit DH keys as some people have been suggesting recently (and at what cost!) NOTE: Those interested in reading more about these design principles and the compact multi-mode approach can take a look at my 1995 paper: ``SKEME: A Versatile Secure Key Exchange Mechanism for Internet", Proceedings of the 1996 Internet Society Symposium on Network and Distributed System Security, Feb. 1996. (Available from www.research.ibm.com/security/skeme.ps) In particular, you can see there how simpler IKE could have been; but, for good and bad, IKE is the result of a multi-year huge-committee work and "rough consensus" and this shows in its final design. SKEYID FUNCTIONALITY All phase 1 modes in IKE establish a key via a Diffie-Hellman (DH) exchange. The modes differ mainly in the way this exchange is authenticated. The key SKEYID exists in all three modes and has as its most essential role to provide the DH authentication. The definition of SKEYID is thus strongly tied to the type of keying material and cryptographic functions available in each of the modes. However, once we define SKEYID, its use in the authentication process is common to all modes and is defined via the expressions HASH_I and HASH_R. In addition, SKEYID is used for deriving further keying material out of the DH key g^xy. This keying material is used during phase 1 itself (mainly, for identity protection), and in phase 2 for phase2 authentication and for derivation of the key material needed by ipsec for securing IP data. These three derived keys are called SKEYID_e, SKEYID_a, and SKEYID_d, respectively, and their derivation is identical for all modes. All these key derivations, and the definition of HASH_I/R, use a prf and SKEYID as the prf key. Moreover, SKEYID is never used (and should never be used) as a key for anything else than for keying the prf. NOTE: As I noted many times in the past, there is an unfortunate typo in the definition of HASH_R in the IKE rfc (where SAi_b appears instead of SAr_b). Next I explain the SKEYID derivation for each of the three authentication modes. Signature mode is presented last because it is the most complex to explain. PRESHARED MODE In this mode the two parties to the exchange are assumed to share a STRONG secret key (the mode is not concerned with the way this sharing happened; it assumes the sharing is secure: i.e., the key belongs and is known only to the exchange parties). The underlying idea is simple: use a MAC function keyed with the preshared key in order to authenticate the DH exponents, g^x and g^y, as exchanged during the protocol. Since a prf is, in particular, a secure MAC function then the HASH_I and HASH_R computations provide this functionality. There is no need to authenticate g^xy directly since this authentication is implied by the authentication of g^x and g^y by each of the parties. In this case one could have simply definded SKEYID = pre-shared-key. Instead we defined: SKEYID = prf(pre-shared-key, Ni | Nr) in order to force SKEYID to be different and fresh with each exchange (as the nonces Ni and Nb are); this is just a safer and more robust use of the long-lived pre-shared key. PUBLIC KEY ENCRYPTION MODE Here the authentication of the protocol happens by each party "proving" possesion of its own private decryption key. More precisely, the initiator sends a nonce Ni encrypted under the responder's public key. Now the responder has to prove it was able to decrypt Ni. Same happens in the other direction. How do they prove knowledge of these nonces? By their ability to compute hash(Ni,Nb). This knowledge and ability is then bound to the authentication process, namely, the parties do not reveal hash(Ni | Nb) but use this value to authenticate the exchanged information (including the DH exponents g^x and g^y). In this case one could have simply definded SKEYID = hash(Ni | Nb) Instead we defined: SKEYID = prf(hash(Ni | Nb), CKY-I | CKY-R) Why CKY-I | CKY-R? This is not strictly necessary since Ni and Nb are already fresh material. However, in the above way we get the key material out of the prf (as in all other key derivations) and also we tie the key to a specific key-exchange session which in ISAKMP is identified by the pair of cookies. NOTE: In a recent paper with Canetti (Eurocrypt'2001) we prove the security of this mechanism but for the case where authentication is performed uni-directionally by each party (using the other party's nonce as the key rather than hashing the nonces together). In this uni-directional case, tying the nonce to the session identifier is fundamental for security. Without it the protocol is open to key reuse/replay attacks. The same principle is used above. SIGNATURE MODE Here things are not as intuitive as above, and much care is required. Some background is needed and I'll try to sketch it here. The signature mode of IKE was a development out of Photuris signature-based authentication. In turn, Photuris was based on the STS protocol by Diffie, van Oorschot, and Wiener (described in their excellent paper ``Authentication and Authenticated Key Exchanges'', Designs, Codes and Cryptography, V. 2, 1992, and whose reading I strongly recommend to anyone interested in the design of key exchange protocols -- btw, does anyone know of an electronic version in the web?) One great contribution of the above paper is in pointing out to a subtle attack against the authenticity of key exchange protocols, in particular those based on signature authentication (the attack is sometimes referred to as "unknown key-share attack"). In this attack a man-in-the-middle does not get to learn the exchanged key but succeeds in "confusing" the parties as for whom they are talking to (party A believes she exchanged the key with B, while B is convinced that the key was exchanged with Eve). This problem is somewhat counter-intuitive and shows that plain signature authentication is not sufficient and careful BINDING of the exchanged key and the party's identity is required. To makes things more understandable, one can think that what is needed is a proof by the signer that it knows the key g^xy. The solution proposed by STS was to sign the exponents g^x and g^y and then encrypt the resultant signature with the exchanged key g^xy. Photuris adopted this technique since the encryption was needed anyway to hide identities, a requirement set by the ipsec WG. Unfortunately, the STS solution is not as strong as we would like. The source of the problem is in using an encryption function for solving an authentication problem (encryption is especially bad to bind things together, just think of stream ciphers). One explicit weakness of the STS protocol is that if a party is using a certificate for which the CA does not require a proof of possession then the "unknown key-share attack" is possible even after encrypting the signature. Other attacks and weaknesses may be possible. Another potential problem with the use of encryption as an authentication function is the possibility that implementations will use weaker encryption than authentication (either for reasons such as export regulations or just because the encryption may be regarded, as many did with Photuris, as necessary only for identity protection and then its strength may be set well below the "authenticity level") The right and simple solution is not to use encryption but a MAC function to bind together the signature, the party identities and the key g^xy. (Encryption is still there but only for identity protection.) There were two options: to apply a MAC keyed with g^xy on top of the signature, or to first apply a MAC keyed with g^xy on the identity (of the sender) and then apply the signature on top of the MAC. IKE implemented the later option (this was particularly convenient for uniformity with other modes). That is, each party to the exchange, let's call it A, produces a signature of the form SIGN_A(MAC(g^xy, id_A | g^x | g^y | cookies | SA)) (where g^xy acts as the key to the MAC). In IKE the MAC is implemented via the prf and instead of using g^xy directly as a key we first hash it (see above "rule" for always hashing g^xy before using it as a key). This is how we obtain the usage of HASH_I/R in signature mode (which is nothing but the above MAC() expression). Now note that HASH_I/R are defined to use SKEYID as the key. This is why in signature mode we should have defined SKEYID=g^xy, or more precisely SKEYID=hash(g^xy). And this is exactly what we did except that instead of applying hash(g^xy) we defined: SKEYID = prf(Ni | Nr, g^xy) This use of a prf, with a random but known key (this is what Ni|Nr is), is equivalent to the use of a mixing hash function as needed to extract the "cryptographic entropy" from g^xy. NOTE: one consequence of the above design is that the signature mode cannot be guaranteed, in general, to provide non-repudiation of the signed information since one is signing the result of a prf, and prf's are not required to be collision resistant. This was a conscious decision: there is no requirement for IKE to provide non-repudiation. If at all, such a property should be regarded as a privacy drawback. (Still, if someone wants to provide this property it can use a prf which is assumed to be also collision resistant, e.g. HMAC) NOTE: if identity protection would have not been a requirement a simpler signature mode would have been possible (one that dispenses at all of encryption or a MAC in addition to the signature). ISO 9796 has such a simple protocol. However its implementation in IKE would have required giving up identity protection or adding more round trips to the protocol. Hope this helps clarifying things. Hugo Appendix: SKEYID definitions from the RFC For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) The result of either Main Mode or Aggressive Mode is three groups of authenticated keying material: SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) and agreed upon policy to protect further communications. The values of 0, 1, and 2 above are represented by a single octet. The key used for encryption is derived from SKEYID_e in an algorithm-specific manner (see appendix B). To authenticate either exchange the initiator of the protocol generates HASH_I and the responder generates HASH_R where: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) From owner-ipsec@lists.tislabs.com Thu Jun 21 10:52:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5LHqYk09258; Thu, 21 Jun 2001 10:52:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19324 Thu, 21 Jun 2001 12:48:07 -0400 (EDT) Message-ID: From: Mohammad Ghaeini To: "'ipsec@lists.tislabs.com'" Subject: IPsec with pre-shares keys on Solaris 8 Date: Thu, 21 Jun 2001 10:52:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Is there a way to set up IPsec with pre-shared keys on Solaris 8? Has any one gone this route before? Any hint would be appreciated. Thanks in advance. Mohammad Ghaeini Unix Policy Engineer Center 7 Inc. 333 South 520 West Lindon, Utah 84042 Phone: 801.805.3150 Fax: 801.805.3030 Mobile: 801.554.7630 E-mail: m.ghaeini@center7.com www.center7.com From owner-ipsec@lists.tislabs.com Thu Jun 21 11:41:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5LIfJk10625; Thu, 21 Jun 2001 11:41:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21292 Thu, 21 Jun 2001 13:56:46 -0400 (EDT) Message-ID: <9D048F4A422CD411A56500B0D0209C5B01185D06@NS-CA> From: Jay Ratford To: "'ipsec@lists.tislabs.com'" Cc: Pu Zhang Subject: NAT-Traversal interop testing in Helsinki Date: Thu, 21 Jun 2001 10:59:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just wanted to get a sense of who will be testing NAT-Traversal at the Auguest BakeOff based on these drafts? draft-ietf-ipsec-nat-t-ike-00.txt draft-ietf-ipsec-udp-encaps-00.txt If you are interested in doing some prior testing over the Internet today please let me know. We make a Gateway box and are looking to test esp-tunnel mode using NAT-T. Havn't heard much noise on NAT-T in a while Jay Ratford Product Marketing Engineer Netscreen Technologies, Inc. 350 Oakmead Parkway, Mail Stop 100 Sunnyvale, CA 94085 http://www.netscreen.com * jratford@netscreen.com * Tel: 408.730.6214 * Fax: 408.730.6200 * Cell: 408.307.5066 From owner-ipsec@lists.tislabs.com Thu Jun 21 11:50:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5LIolk10845; Thu, 21 Jun 2001 11:50:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21719 Thu, 21 Jun 2001 14:15:35 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE7838128150@md-exchange1.nai.com> From: "Mason, David" To: "'Jay Ratford'" , "'ipsec@lists.tislabs.com'" Cc: Pu Zhang Subject: RE: NAT-Traversal interop testing in Helsinki Date: Thu, 21 Jun 2001 11:20:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there copies of these IDs available somewhere? -dave -----Original Message----- From: Jay Ratford [mailto:Jratford@netscreen.com] Sent: Thursday, June 21, 2001 1:59 PM To: 'ipsec@lists.tislabs.com' Cc: Pu Zhang Subject: NAT-Traversal interop testing in Helsinki Just wanted to get a sense of who will be testing NAT-Traversal at the Auguest BakeOff based on these drafts? draft-ietf-ipsec-nat-t-ike-00.txt draft-ietf-ipsec-udp-encaps-00.txt If you are interested in doing some prior testing over the Internet today please let me know. We make a Gateway box and are looking to test esp-tunnel mode using NAT-T. Havn't heard much noise on NAT-T in a while Jay Ratford Product Marketing Engineer Netscreen Technologies, Inc. 350 Oakmead Parkway, Mail Stop 100 Sunnyvale, CA 94085 http://www.netscreen.com * jratford@netscreen.com * Tel: 408.730.6214 * Fax: 408.730.6200 * Cell: 408.307.5066 From owner-ipsec@lists.tislabs.com Thu Jun 21 16:29:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5LNTZk17033; Thu, 21 Jun 2001 16:29:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29446 Thu, 21 Jun 2001 18:21:16 -0400 (EDT) Message-ID: <3B327623.23CE7552@cisco.com> Date: Thu, 21 Jun 2001 15:33:07 -0700 From: Cheryl Madson X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Ratford CC: "'ipsec@lists.tislabs.com'" , Pu Zhang Subject: Re: NAT-Traversal interop testing in Helsinki References: <9D048F4A422CD411A56500B0D0209C5B01185D06@NS-CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since these drafts don't yet appear to be publicly available, I'd say the answer is "almost no one"... thx - C Jay Ratford wrote: > Just wanted to get a sense of who will be testing NAT-Traversal at the > Auguest BakeOff based on these drafts? > > draft-ietf-ipsec-nat-t-ike-00.txt > draft-ietf-ipsec-udp-encaps-00.txt > > If you are interested in doing some prior testing over the Internet today > please let me know. > We make a Gateway box and are looking to test esp-tunnel mode using NAT-T. > > Havn't heard much noise on NAT-T in a while > > Jay Ratford > Product Marketing Engineer > Netscreen Technologies, Inc. > 350 Oakmead Parkway, Mail Stop 100 > Sunnyvale, CA 94085 > http://www.netscreen.com > > * jratford@netscreen.com > * Tel: 408.730.6214 > * Fax: 408.730.6200 > * Cell: 408.307.5066 -- ========================================================= Cheryl Madson Strategic Cryptographic Development; Core IP Engineering Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec@lists.tislabs.com Fri Jun 22 04:47:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5MBlsk01601; Fri, 22 Jun 2001 04:47:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04289 Fri, 22 Jun 2001 07:06:36 -0400 (EDT) Message-Id: <200106221112.HAA15893@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-nat-t-ike-00.txt Date: Fri, 22 Jun 2001 07:12:03 -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 : Negotiation of NAT-Traversal in the IKE Author(s) : T. Kivinen et al. Filename : draft-ietf-ipsec-nat-t-ike-00.txt Pages : 8 Date : 21-Jun-01 This document describes how to detect one or more NATs between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-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-nat-t-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-nat-t-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: <20010621134347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-t-ike-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jun 22 04:47:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5MBlsk01602; Fri, 22 Jun 2001 04:47:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04295 Fri, 22 Jun 2001 07:06:42 -0400 (EDT) Message-Id: <200106221112.HAA15909@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-udp-encaps-00.txt Date: Fri, 22 Jun 2001 07:12:08 -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 : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen et al. Filename : draft-ietf-ipsec-udp-encaps-00.txt Pages : Date : 21-Jun-01 This draft defines methods to encapsulate and decapsulate ESP and AH packets inside UDP packets for the purpose of traversing NATs. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. AH encapsulation is defined for IPv4 scenarios only. The encapsulation is used whenever negotiated using IKE, as defined in [Kiv00]. The design choices are documented in [Dixon00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-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-udp-encaps-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-udp-encaps-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: <20010621134355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134355.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jun 22 04:49:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5MBn9k01646; Fri, 22 Jun 2001 04:49:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04282 Fri, 22 Jun 2001 07:06:32 -0400 (EDT) Message-Id: <200106221111.HAA15877@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-nat-reqts-00.txt Date: Fri, 22 Jun 2001 07:11:58 -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-NAT Compatibility Requirements Author(s) : B. Aboba Filename : draft-ietf-ipsec-nat-reqts-00.txt Pages : 11 Date : 21-Jun-01 Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of VPNs is to provide tele-commuter access to the corporate Intranet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by tele-commuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier to deployment of IPsec in one of its principal uses. This draft describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-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-nat-reqts-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-nat-reqts-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: <20010621134339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134339.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jun 22 04:49:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5MBnGk01658; Fri, 22 Jun 2001 04:49:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04276 Fri, 22 Jun 2001 07:06:27 -0400 (EDT) Message-Id: <200106221111.HAA15861@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-udp-encaps-justification-00.txt Date: Fri, 22 Jun 2001 07:11:53 -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 over NAT Justification for UDP Encapsulation Author(s) : W. Dixon et al. Filename : draft-ietf-ipsec-udp-encaps-justification-00.txt Pages : 17 Date : 21-Jun-01 This draft explains the design justification and alternatives for two IPsec over NAT drafts, UDP Encapsulation of IPsec Packets, [Hutt01] and [Kiv00]. This draft sets the requirements for a solution in terms of scenarios in which NAT is used, and NAT operations. This draft is specifies the requirements for IPsec NAT traversal, scenarios these extensions enable, and design rationale for the proposed solution. This draft assumes that the reader is familiar with the interactions of NAT with IPsec documented in [Aboba04]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-justification-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-udp-encaps-justification-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-udp-encaps-justification-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: <20010621134330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-justification-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-justification-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134330.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jun 22 13:30:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5MKUbk20614; Fri, 22 Jun 2001 13:30:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05939 Fri, 22 Jun 2001 15:36:21 -0400 (EDT) Message-Id: <200106221936.PAA05935@lists.tislabs.com> Date: Fri, 22 Jun 2001 12:42:24 -0700 From: Will Price Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: NAT-Traversal interop testing in Helsinki Cc: Jay Ratford , "'ipsec@lists.tislabs.com'" To: Cheryl Madson X-Mailer: Apple Mail (2.388) In-Reply-To: <3B327623.23CE7552@cisco.com> Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Now that the drafts have been released, I would say quite a few. The drafts are similar to the previous NAT T and ESP Over UDP drafts, so for many people it will be only minor modifications. We will be there testing this. On Thursday, June 21, 2001, at 03:33 PM, Cheryl Madson wrote: > Since these drafts don't yet appear to be publicly available, I'd > say the answer is "almost no one"... > > thx - C > > > Jay Ratford wrote: > >> Just wanted to get a sense of who will be testing NAT-Traversal at the >> Auguest BakeOff based on these drafts? >> >> draft-ietf-ipsec-nat-t-ike-00.txt >> draft-ietf-ipsec-udp-encaps-00.txt >> >> If you are interested in doing some prior testing over the >> Internet today >> please let me know. >> We make a Gateway box and are looking to test esp-tunnel mode >> using NAT-T. >> >> Havn't heard much noise on NAT-T in a while >> >> Jay Ratford >> Product Marketing Engineer >> Netscreen Technologies, Inc. >> 350 Oakmead Parkway, Mail Stop 100 >> Sunnyvale, CA 94085 >> http://www.netscreen.com >> >> * jratford@netscreen.com >> * Tel: 408.730.6214 >> * Fax: 408.730.6200 >> * Cell: 408.307.5066 > > -- > ========================================================= > Cheryl Madson > Strategic Cryptographic Development; Core IP Engineering > Cisco Systems, Inc. > cmadson@cisco.com -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Fri Jun 22 16:43:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5MNhnk24358; Fri, 22 Jun 2001 16:43:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06430 Fri, 22 Jun 2001 19:01:38 -0400 (EDT) Message-ID: <23051C9F9BABD411A7850002B30847991EE963@delta.allegrosys.com> From: jeff To: ipsec@lists.tislabs.com Subject: ID payloads semantics for phase 2 SAs Date: Fri, 22 Jun 2001 16:07:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm wondering what are the semantics of the ID payloads in phase 2. Look at this example: [Host1 (206.1.1.1)] ====== [Host2 (206.1.1.2)] Suppose that Host1 has SPD (in priority order): send-clear udp any send-crypt ip-dst 206.1.1.2 ;; Host1 will send all UDP in the clear, and ;; any non-UDP traffic to 206.1.1.2 will get ;; encrypted Suppose that Host2 has SPD (in priority order): send-clear udp 500 send-crypt ip-dst 206.1.1.1 ;; Host2 will send all UDP port 500 traffic in ;; the clear and all non-UDP/500 traffic will to ;; 206.1.1.1 will get encrypted The ID payloads are sent on the wire, and the IPSec SAs get setup. These ID payloads don't (cannot) express the actual set of traffic that will be protected. Traffic starts, Host2 initiates a top-secret transaction using UDP port 2000, and Host1 sends the top-secret response in the clear! Is this expected behavior? Shouldn't the ID payloads give you some expectation of protection? With this behavior, all the ID payload really says is that some classes of traffic won't make it into the tunnel, but there is no guarentee that *any* class of traffic will! Should IKE at some point be enhanced so that ID payloads can be chained to express more complex classes of traffic? Sorry if this has been mulled over before, Jeff From owner-ipsec@lists.tislabs.com Sat Jun 23 13:53:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5NKrFk27444; Sat, 23 Jun 2001 13:53:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07981 Sat, 23 Jun 2001 15:46:23 -0400 (EDT) Message-ID: <3B34F362.CF7F2B4D@storm.ca> Date: Sat, 23 Jun 2001 15:52:02 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Fwd: Re: P1363: prudent fields] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Forwarding this because it seems to raise some concerns for at least one of the IKE DH groups. Is this a serious worry? Should the IKE ECC groups be dropped or replaced? -------- Original Message -------- Subject: Re: P1363: prudent fields Date: Sat, 23 Jun 2001 07:55:50 -0400 (EDT) From: Alfred John Menezes To: Richard Schroeppel CC: Don Johnson , stds-p1363-discuss@majordomo.ieee.org,himanee --------------------------------------------------------------------- This is a stds-p1363-discuss broadcast. See the IEEE P1363 web page (http://grouper.ieee.org/groups/1363/) for more information. For list info, see http://grouper.ieee.org/groups/1363/WorkingGroup/maillist.html --------------------------------------------------------------------- On Fri, 22 Jun 2001, Richard Schroeppel wrote: > Take a look at Nigel Smart's recent talk at Eurocrypt 2001, > where he takes on the IPSEC Oakley curve over GF[2^155]. > The attack reduces the estimated work for breaking the > curve from "10^11 years" to "over 10^10 years". > > [deleted] > > > Rich Schroeppel rcs@cs.arizona.edu You may be interested in the preprint" "Solving Elliptic Curve Discrete Logarithm Problems Using Weil Descent" by M. Jacobson, A. Menezes and A. Stein available from eprint.iacr.org (Report #2001/041). In this paper, we solve an instance of the ECDLP over the field GF(2^124) by using the Gaudry-Hess-Smart (GHS) Weil descent method to reduce the ECDLP to an instance of the HCDLP (hyperelliptic curve discrete logarithm problem) in a genus 31 hyperelliptic curve over GF(2^4), and then solving the latter problem using the Enge-Gaudry method. The elliptic curve chosen has order twice a prime, and so resists all other known attacks, including Pollard rho which would take about 2^62 steps. Our implementation of Enge-Gaudry solved the HCDLP instance in less time than it took to solve the 108-bit ECC2-108K Certicom challenge. We have also identified a class of elliptic curves over GF(2^155) for which the ECDLP can be efficiently reduced to the HCDLP in a genus 31 hyperelliptic curve over GF(2^5). These HCDLP instances can be solved in about 27,000 days on a single 1GHz Pentium III machine, or in 30 days on a network of 1000 such machines. This is less time than it takes to perform exhaustive search for a 56-bit DES key. Note that Pollard rho on an elliptic curve over GF(2^155) whose order is twice a prime would take 2^77 steps which is considered infeasible. We did not actually solve an instance of the ECDLP for an elliptic curve over GF(2^155). Note however that the expected time of 27,000 days mentioned above is *exact* (see the paper for details). That is, we did not make wild estimates based on asymptotic running times which include O() or o(1) expressions as is done, for example, in estimating the running time of the Number Field Sieve for factoring large integers. We carefully point out that the above attack only applies to 2^32 of the 2^156 isomorphism classes of elliptic curves over GF(2^155). Thus, the GHS attack is virtually certain to fail against a randomly chosen curve over GF(2^155). However, given that there is much more work that remains to be done understanding Weil descent, and that there are many possible ways in which to extend the attack, my opinion is that elliptic curves over GF(2^155) should be altogether avoided. If you wish to learn more about Weil descent, see Nigel Smart's collection of papers at www.cs.bris.ac.uk/~nigel/weil_descent.html - Alfred From owner-ipsec@lists.tislabs.com Mon Jun 25 05:16:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PCGpk03686; Mon, 25 Jun 2001 05:16:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11504 Mon, 25 Jun 2001 07:12:10 -0400 (EDT) X-Authentication-Warning: brahmi.ee.iitb.ac.in: sandy owned process doing -bs Date: Sat, 23 Jun 2001 16:43:01 +0530 (IST) From: Sandeep Kumar S_97D07017_ To: =?iso-8859-1?q?ranjeet=20barve?= cc: Subject: Re: ESP Transport Mode Encryption Payload In-Reply-To: <20010620053503.62843.qmail@web8005.mail.in.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi I'm just back frm vacation...I'll just check up and reply soon bye sandy On Wed, 20 Jun 2001, ranjeet barve wrote: > Hi, > While doing the Implementation of ESP in Transport > mode,I am a bit confused about the amount of Data that > goes for Encryption. > Are the Pad Length and Next header fields a part of > the cipher text along with the Payload? > Also is the Padding calculated after considering the > sum of (Payload + Pad Length + Next Header) to make it > a multiple number of 8 bytes required for encryption > by DES/3DES-CBC mode? > > Please let me know, > > Regards, > Ranjeet Barve. > > > ____________________________________________________________ > Do You Yahoo!? > For regular News updates go to http://in.news.yahoo.com > -- "No matter how fast your new CPU, software has already been written to make it feel slow" ------------------------------------------------------------------------------ S.Sandeep kumar email: Dept. of Electrical Engineering sandy7de@ccs.iitb.ernet.in Indian Institute of Technology sandy@ee.iitb.ernet.in Mumbai ------------------------------------------------------------------------------ From owner-ipsec@lists.tislabs.com Mon Jun 25 06:27:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PDR0k07101; Mon, 25 Jun 2001 06:27:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11747 Mon, 25 Jun 2001 08:40:20 -0400 (EDT) From: Steve.Robinson@psti.com Subject: Re: ID payloads semantics for phase 2 SAs To: jeff Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 25 Jun 2001 08:49:34 -0400 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at 06/25/2001 01:50:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jeff, I really don't see a problem with the infrastructure of the current set of IP Security protocols here, it is a matter of modifying the local policy to get the correct behaviour. However, if you want to avoid problems like this, you may want to look at a recent discussion about decorrelating policy which removes the need for total ordering. Matt Condell recently sent around an e-mail describing a decorrelation algorithm that you might find interesting. I have no idea if this is going to be incorporated into any future drafts or not, but I'd certainly like to see it. Steve ====Precise. Making your ideas an embedded reality==== Steve Robinson Software Designer Precise Software Technologies Inc. 301 Moodie Drive, Suite 308 Nepean, Ontario, Canada K2H 9C4 Telephone: 613-596-2251 x237 Facsimile: 613-596-6713 http://www.psti.com/ Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and Precise Software Technologies Inc. or any of its affiliates. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to Precise may be subject to monitoring other than by the addressee. jeff cc: Sent by: Subject: ID payloads semantics for phase 2 SAs owner-ipsec@lists.t islabs.com 06/22/01 07:07 PM I'm wondering what are the semantics of the ID payloads in phase 2. Look at this example: [Host1 (206.1.1.1)] ====== [Host2 (206.1.1.2)] Suppose that Host1 has SPD (in priority order): send-clear udp any send-crypt ip-dst 206.1.1.2 ;; Host1 will send all UDP in the clear, and ;; any non-UDP traffic to 206.1.1.2 will get ;; encrypted Suppose that Host2 has SPD (in priority order): send-clear udp 500 send-crypt ip-dst 206.1.1.1 ;; Host2 will send all UDP port 500 traffic in ;; the clear and all non-UDP/500 traffic will to ;; 206.1.1.1 will get encrypted The ID payloads are sent on the wire, and the IPSec SAs get setup. These ID payloads don't (cannot) express the actual set of traffic that will be protected. Traffic starts, Host2 initiates a top-secret transaction using UDP port 2000, and Host1 sends the top-secret response in the clear! Is this expected behavior? Shouldn't the ID payloads give you some expectation of protection? With this behavior, all the ID payload really says is that some classes of traffic won't make it into the tunnel, but there is no guarentee that *any* class of traffic will! Should IKE at some point be enhanced so that ID payloads can be chained to express more complex classes of traffic? Sorry if this has been mulled over before, Jeff From owner-ipsec@lists.tislabs.com Mon Jun 25 09:35:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PGZvk15088; Mon, 25 Jun 2001 09:35:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12464 Mon, 25 Jun 2001 11:28:53 -0400 (EDT) Message-ID: <3B37556E.9B53C800@F-Secure.com> Date: Mon, 25 Jun 2001 18:14:54 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: jshukla , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT References: <200106191651.f5JGowu00723@dharkins@lounge.orgatty.lounge.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > On Tue, 19 Jun 2001 09:25:31 PDT you wrote > > > > Right! The point is that pre-shared keys based authentication > > can be made more robust against DoS attacks compared to > > the other three authentication methods. In their current form, > > all authencitation methods are susceptible to DoS attacks. > > The DoS attack mounted against IKE is one that exploits the fact that > the responder creates state upon receipt of a single message from the > initiator. That will not be addressed by moving the authentication > step. It will be addressed by further complicating the protocol with > a new stateless "cookie request" option. > > Your suggestion to move the authentication step would further complicate > the protocol. The way it is now there is a uniform progression of state > for each of the authentication methods. As someone who has implemented > this protocol I can tell you it makes it much simpler to code that way. > > As has been pointed out repeatedly in this thread (and in the past) a > DoS attack that attempts to force the responser to do needless Diffie- > Hellman work would expose its IP address and the attack could be properly > addressed because of it. > > There are all sorts of changes that can be made to IKE but one that > would make the protocol much more complicated for such a small (perhaps > even non-existent) benefit is not something we should consider. > > Dan. Is anyone still interested in Base Mode? It would be possible to create a Base Mode where reception of the first message is stateless to the Responder, by sending the state back in msg2 encrypted with some locally known symmetric key, and verified upon reception in msg3. This modified Base Mode could then be used to replace Aggressive Mode. The rationale for changing Base Mode would be that nobody's yet really using it (?), and that it's cool :). There's a paper by Pekka Nikander explaining the theory of making protocols stateless, forget where that is though. Of course, this all may not be worth the trouble. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Jun 25 11:01:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PI1nk16527; Mon, 25 Jun 2001 11:01:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12794 Mon, 25 Jun 2001 13:14:27 -0400 (EDT) Message-Id: <200106251719.f5PHJvx16649@thunk.east.sun.com> From: Bill Sommerfeld To: Ari Huttunen cc: Dan Harkins , jshukla , ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT In-reply-to: Your message of "Mon, 25 Jun 2001 18:14:54 +0300." <3B37556E.9B53C800@F-Secure.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 25 Jun 2001 13:19:57 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Is anyone still interested in Base Mode? It would be possible to create > a Base Mode where reception of the first message is stateless to the Responder, > by sending the state back in msg2 encrypted with some locally known symmetric > key, and verified upon reception in msg3. This modified Base Mode > could then be used to replace Aggressive Mode. The rationale for changing > Base Mode would be that nobody's yet really using it (?), and that it's cool :). > There's a paper by Pekka Nikander explaining the theory of making protocols > stateless, forget where that is though. I'd be very interested in seeing a mode which is initially stateless for the responder; it's a key bit of technology from photuris which was never carried forward to IKE. - Bill From owner-ipsec@lists.tislabs.com Mon Jun 25 11:31:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PIVbk17326; Mon, 25 Jun 2001 11:31:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12873 Mon, 25 Jun 2001 13:52:31 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Ari Huttunen'" Cc: Subject: RE: IPSEC Security Gateways & NAT Date: Mon, 25 Jun 2001 13:35:24 -0400 Message-Id: <000c01c0fd9e$f6971350$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <3B37556E.9B53C800@F-Secure.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The state payload could be used in any exchange, not just base mode. It is a good general-purpose replacement for the functionality originally assigned to cookies -- without some of the drawbacks as well. Base mode was a good idea, but someone (Bill?) also suggested that an equally viable solution was just to make identity protection an optional feature of main mode. That's an interesting tradeoff: adding a bit of complexity to main mode vs. the need to support multiple exchange types. I personally prefer using a separate exchange in this case. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen > Sent: Monday, June 25, 2001 11:15 AM > To: Dan Harkins > Cc: jshukla; ipsec@lists.tislabs.com > Subject: Re: IPSEC Security Gateways & NAT > > > > > Dan Harkins wrote: > > > > On Tue, 19 Jun 2001 09:25:31 PDT you wrote > > > > > > Right! The point is that pre-shared keys based authentication > > > can be made more robust against DoS attacks compared to > > > the other three authentication methods. In their current form, > > > all authencitation methods are susceptible to DoS attacks. > > > > The DoS attack mounted against IKE is one that exploits the > fact that > > the responder creates state upon receipt of a single > message from the > > initiator. That will not be addressed by moving the authentication > > step. It will be addressed by further complicating the protocol with > > a new stateless "cookie request" option. > > > > Your suggestion to move the authentication step would > further complicate > > the protocol. The way it is now there is a uniform > progression of state > > for each of the authentication methods. As someone who has > implemented > > this protocol I can tell you it makes it much simpler to > code that way. > > > > As has been pointed out repeatedly in this thread (and in > the past) a > > DoS attack that attempts to force the responser to do > needless Diffie- > > Hellman work would expose its IP address and the attack > could be properly > > addressed because of it. > > > > There are all sorts of changes that can be made to IKE but one that > > would make the protocol much more complicated for such a > small (perhaps > > even non-existent) benefit is not something we should consider. > > > > Dan. > > Is anyone still interested in Base Mode? It would be possible > to create > a Base Mode where reception of the first message is stateless > to the Responder, > by sending the state back in msg2 encrypted with some locally > known symmetric > key, and verified upon reception in msg3. This modified Base Mode > could then be used to replace Aggressive Mode. The rationale > for changing > Base Mode would be that nobody's yet really using it (?), and > that it's cool :). > There's a paper by Pekka Nikander explaining the theory of > making protocols > stateless, forget where that is though. > > Of course, this all may not be worth the trouble. > > Ari > > -- > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F(ully)-Secure products: Integrated Solutions for Enterprise Security > From owner-ipsec@lists.tislabs.com Mon Jun 25 17:49:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5Q0nwm08708; Mon, 25 Jun 2001 17:49:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13418 Mon, 25 Jun 2001 19:53:10 -0400 (EDT) Message-ID: <3B37D061.576FC5FB@certicom.com> Date: Mon, 25 Jun 2001 19:59:29 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Sandy Harris CC: ipsec@lists.tislabs.com Subject: Re: [Fwd: Re: P1363: prudent fields] References: <9E882A5ABF9FA94985256A7400701E5A.007073AE85256A74@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We recommend to either drop or replace Group 3 (ECC) and Group 4 (ECC). I asked Alfred to comment on the Weil Descent attack. His reply is below. Thanks, Yuri Poeluev ==================================================================== Some further words on the message below which was originally posted to the IEEE P1363 working group. The paper "Solving Elliptic Curve Discrete Logarithm Problems Using Weil Descent" shows that a special class of elliptic curves over the finite field GF(2^155) that was previously considered to be secure is in fact *not* secure. This special class of elliptic curves is a small fraction of the set of all elliptic curves over GF(2^155). In particular, the IPSEC Oakley curve over GF(2^155) is *not* included in this special class, and so is still considered to be secure against the Weil Descent attack. However, it is our opinion that this provides strong evidence for the weakness of *all* elliptic curves over GF(2^155), and that it would be prudent to avoid such curves all together. It is perfectly reasonably to expect that the Weil Descent attack could be extended to succeed against a larger class of elliptic curves over GF(2^155). More generally, we recommend that elliptic curves over GF(2^n) where be n is composite be avoided, including elliptic curves over GF(2^185). Please note that the Weil descent attack fails against all elliptic curves over GF(2^n) where n is a prime number in the interval [160,600]. For example, the Weil descent attack fails against elliptic curves over GF(2^163) and GF(2^283). For further details about why the attack fails in these cases, see the paper "Analysis of the Weil descent attack of Gaudry, Hess and Smart" by Menezes and Qu in the Proceedings of the RSA 2001 conference. Thus, our recommendation, is to: 1) Remove the IPSEC Oakley elliptic curves over GF(2^155) and GF(2^185). These are also called Groups 3 and 4. 2) Retain the IPSEC Oakley elliptic curves over GF(2^163), GF(2^283), GF(2^409) and GF(2^571). The are also called Groups 6, 7, 8, 9, 10, 11, 12 and 13. We would like to emphasize that our recommendations are based purely on security arguments. Regards, Alfred Sandy Harris wrote: > > Forwarding this because it seems to raise some concerns for at least one of > the IKE DH groups. > > Is this a serious worry? Should the IKE ECC groups be dropped or replaced? > > -------- Original Message -------- > Subject: Re: P1363: prudent fields > Date: Sat, 23 Jun 2001 07:55:50 -0400 (EDT) > From: Alfred John Menezes > To: Richard Schroeppel > CC: Don Johnson , > stds-p1363-discuss@majordomo.ieee.org,himanee > > --------------------------------------------------------------------- > This is a stds-p1363-discuss broadcast. See the IEEE P1363 web page > (http://grouper.ieee.org/groups/1363/) for more information. For list > info, see http://grouper.ieee.org/groups/1363/WorkingGroup/maillist.html > --------------------------------------------------------------------- > > On Fri, 22 Jun 2001, Richard Schroeppel wrote: > > > Take a look at Nigel Smart's recent talk at Eurocrypt 2001, > > where he takes on the IPSEC Oakley curve over GF[2^155]. > > The attack reduces the estimated work for breaking the > > curve from "10^11 years" to "over 10^10 years". > > > > [deleted] > > > > > > Rich Schroeppel rcs@cs.arizona.edu > > You may be interested in the preprint" "Solving Elliptic Curve Discrete > Logarithm Problems Using Weil Descent" by M. Jacobson, A. Menezes and > A. Stein available from eprint.iacr.org (Report #2001/041). In this > paper, we solve an instance of the ECDLP over the field GF(2^124) > by using the Gaudry-Hess-Smart (GHS) Weil descent method to reduce > the ECDLP to an instance of the HCDLP (hyperelliptic curve discrete > logarithm problem) in a genus 31 hyperelliptic curve over GF(2^4), > and then solving the latter problem using the Enge-Gaudry method. > The elliptic curve chosen has order twice a prime, and so resists > all other known attacks, including Pollard rho which would take about > 2^62 steps. Our implementation of Enge-Gaudry solved the HCDLP instance > in less time than it took to solve the 108-bit ECC2-108K Certicom > challenge. > > We have also identified a class of elliptic curves over GF(2^155) > for which the ECDLP can be efficiently reduced to the HCDLP in a genus > 31 hyperelliptic curve over GF(2^5). These HCDLP instances can be solved > in about 27,000 days on a single 1GHz Pentium III machine, or in 30 > days on a network of 1000 such machines. This is less time than it takes > to perform exhaustive search for a 56-bit DES key. Note that Pollard > rho on an elliptic curve over GF(2^155) whose order is twice a prime would > take 2^77 steps which is considered infeasible. > > We did not actually solve an instance of the ECDLP for an elliptic curve > over GF(2^155). Note however that the expected time of 27,000 days > mentioned above is *exact* (see the paper for details). That is, we > did not make wild estimates based on asymptotic running times which > include O() or o(1) expressions as is done, for example, in estimating > the running time of the Number Field Sieve for factoring large integers. > > We carefully point out that the above attack only applies to 2^32 of the > 2^156 isomorphism classes of elliptic curves over GF(2^155). Thus, the > GHS attack is virtually certain to fail against a randomly chosen curve > over GF(2^155). However, given that there is much more work that remains > to be done understanding Weil descent, and that there are many possible > ways in which to extend the attack, my opinion is that elliptic curves > over GF(2^155) should be altogether avoided. > > If you wish to learn more about Weil descent, see Nigel Smart's collection > of papers at www.cs.bris.ac.uk/~nigel/weil_descent.html > > - Alfred From owner-ipsec@lists.tislabs.com Tue Jun 26 04:51:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QBpdm16241; Tue, 26 Jun 2001 04:51:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14771 Tue, 26 Jun 2001 07:10:14 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Mon, 25 Jun 2001 18:37:10 -0600 From: "Hilarie Orman" To: Cc: Subject: Re: IPSEC Security Gateways & NAT 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 UAA13546 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The statelessness seems to exist only in non-stressed circumstances. If there really is a resource shortage, such as would occur in a denial of service attack, then one needs to start keeping track of resource usage, and that means keeping state around, doesn't it? The stateless cryptographic cookie seems to have the disadvantage of requiring extra computation even in the non-attack situation, whereas, the stateful approach requires no extra work until an attack is underway. Hilarie >>> Bill Sommerfeld 06/25/01 11:19AM >>> > Is anyone still interested in Base Mode? It would be possible to create > a Base Mode where reception of the first message is stateless to the Responder, > by sending the state back in msg2 encrypted with some locally known symmetric > key, and verified upon reception in msg3. This modified Base Mode > could then be used to replace Aggressive Mode. The rationale for changing > Base Mode would be that nobody's yet really using it (?), and that it's cool :). > There's a paper by Pekka Nikander explaining the theory of making protocols > stateless, forget where that is though. I'd be very interested in seeing a mode which is initially stateless for the responder; it's a key bit of technology from photuris which was never carried forward to IKE. - Bill From owner-ipsec@lists.tislabs.com Tue Jun 26 04:51:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QBpfm16254; Tue, 26 Jun 2001 04:51:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA14738 Tue, 26 Jun 2001 06:55:54 -0400 (EDT) Message-Id: <200106261101.HAA27044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-07.txt Date: Tue, 26 Jun 2001 07:01:20 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-07.txt Pages : 11 Date : 25-Jun-01 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-07.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-shacham-ippcp-rfc2393bis-07.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-shacham-ippcp-rfc2393bis-07.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: <20010625095435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010625095435.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 26 07:53:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QErlm25516; Tue, 26 Jun 2001 07:53:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15283 Tue, 26 Jun 2001 09:53:33 -0400 (EDT) To: "Hilarie Orman" Cc: , Subject: Re: IPSEC Security Gateways & NAT References: From: Derek Atkins Date: 26 Jun 2001 09:59:33 -0400 In-Reply-To: "Hilarie Orman"'s message of "Mon, 25 Jun 2001 18:37:10 -0600" Message-ID: Lines: 51 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The "extra computation" is really not much more than creating the cookie itself. It doesn't have to be encrypted data; it can be a keyed hash or some other verifiable system. It's probably just as much work as running a PRNG to generate a random NONCE for a cookie. It is certainly much less work than having to keep track of N message-1 messages sitting around and then seeing if you're under attack by counting N. You don't really need to keep track of resource usage; you _can_ choose do so. However, no, this does not require the same amount of state as recording all your message-1 state for each initiator. What's easier, keeping a counter or keeping all the cookie state from all the initiators? -derek PS: I have no objection to an optional stateless cookie round-trip. "Hilarie Orman" writes: > The statelessness seems to exist only in non-stressed circumstances. > If there really is a resource shortage, such as would occur in a denial > of service attack, then one needs to start keeping track of resource > usage, and that means keeping state around, doesn't it? The stateless > cryptographic cookie seems to have the disadvantage of requiring > extra computation even in the non-attack situation, whereas, the > stateful approach requires no extra work until an attack is underway. > > Hilarie > > >>> Bill Sommerfeld 06/25/01 11:19AM >>> > > Is anyone still interested in Base Mode? It would be possible to create > > a Base Mode where reception of the first message is stateless to the Responder, > > by sending the state back in msg2 encrypted with some locally known symmetric > > key, and verified upon reception in msg3. This modified Base Mode > > could then be used to replace Aggressive Mode. The rationale for changing > > Base Mode would be that nobody's yet really using it (?), and that it's cool :). > > There's a paper by Pekka Nikander explaining the theory of making protocols > > stateless, forget where that is though. > > I'd be very interested in seeing a mode which is initially stateless > for the responder; it's a key bit of technology from photuris which > was never carried forward to IKE. > > - Bill -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 26 10:51:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QHpYm06266; Tue, 26 Jun 2001 10:51:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15846 Tue, 26 Jun 2001 12:41:29 -0400 (EDT) Message-ID: From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: AES Key Integrity Date: Tue, 26 Jun 2001 17:48:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It has just occurred to me that I've not noticed any references to a standard integrity mechanism for AES. Will there be one? DES has parity, but a CRC would be better. As crypto gets (theoretically) stronger issues like reliability become much more important. Chris ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Tue Jun 26 11:13:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QIDGm06757; Tue, 26 Jun 2001 11:13:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16016 Tue, 26 Jun 2001 13:22:36 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 26 Jun 2001 11:14:26 -0600 From: "Hilarie Orman" To: , Cc: Subject: Re: [Fwd: Re: P1363: prudent fields] 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 NAA15957 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Given that the groups have no demonstrated mathematical weaknesses and that they have significant computational performance advantages, there appears to be no reason to drop them. Hilarie >>> Yuri Poeluev 06/25/01 05:59PM >>> We recommend to either drop or replace Group 3 (ECC) and Group 4 (ECC). I asked Alfred to comment on the Weil Descent attack. His reply is below. Thanks, Yuri Poeluev ==================================================================== Some further words on the message below which was originally posted to the IEEE P1363 working group. The paper "Solving Elliptic Curve Discrete Logarithm Problems Using Weil Descent" shows that a special class of elliptic curves over the finite field GF(2^155) that was previously considered to be secure is in fact *not* secure. This special class of elliptic curves is a small fraction of the set of all elliptic curves over GF(2^155). In particular, the IPSEC Oakley curve over GF(2^155) is *not* included in this special class, and so is still considered to be secure against the Weil Descent attack. However, it is our opinion that this provides strong evidence for the weakness of *all* elliptic curves over GF(2^155), and that it would be prudent to avoid such curves all together. It is perfectly reasonably to expect that the Weil Descent attack could be extended to succeed against a larger class of elliptic curves over GF(2^155). More generally, we recommend that elliptic curves over GF(2^n) where be n is composite be avoided, including elliptic curves over GF(2^185). Please note that the Weil descent attack fails against all elliptic curves over GF(2^n) where n is a prime number in the interval [160,600]. For example, the Weil descent attack fails against elliptic curves over GF(2^163) and GF(2^283). For further details about why the attack fails in these cases, see the paper "Analysis of the Weil descent attack of Gaudry, Hess and Smart" by Menezes and Qu in the Proceedings of the RSA 2001 conference. Thus, our recommendation, is to: 1) Remove the IPSEC Oakley elliptic curves over GF(2^155) and GF(2^185). These are also called Groups 3 and 4. 2) Retain the IPSEC Oakley elliptic curves over GF(2^163), GF(2^283), GF(2^409) and GF(2^571). The are also called Groups 6, 7, 8, 9, 10, 11, 12 and 13. We would like to emphasize that our recommendations are based purely on security arguments. Regards, Alfred Sandy Harris wrote: > > Forwarding this because it seems to raise some concerns for at least one of > the IKE DH groups. > > Is this a serious worry? Should the IKE ECC groups be dropped or replaced? > > -------- Original Message -------- > Subject: Re: P1363: prudent fields > Date: Sat, 23 Jun 2001 07:55:50 -0400 (EDT) > From: Alfred John Menezes > To: Richard Schroeppel > CC: Don Johnson , > stds-p1363-discuss@majordomo.ieee.org,himanee > > --------------------------------------------------------------------- > This is a stds-p1363-discuss broadcast. See the IEEE P1363 web page > (http://grouper.ieee.org/groups/1363/) for more information. For list > info, see http://grouper.ieee.org/groups/1363/WorkingGroup/maillist.html > --------------------------------------------------------------------- > > On Fri, 22 Jun 2001, Richard Schroeppel wrote: > > > Take a look at Nigel Smart's recent talk at Eurocrypt 2001, > > where he takes on the IPSEC Oakley curve over GF[2^155]. > > The attack reduces the estimated work for breaking the > > curve from "10^11 years" to "over 10^10 years". > > > > [deleted] > > > > > > Rich Schroeppel rcs@cs.arizona.edu > > You may be interested in the preprint" "Solving Elliptic Curve Discrete > Logarithm Problems Using Weil Descent" by M. Jacobson, A. Menezes and > A. Stein available from eprint.iacr.org (Report #2001/041). In this > paper, we solve an instance of the ECDLP over the field GF(2^124) > by using the Gaudry-Hess-Smart (GHS) Weil descent method to reduce > the ECDLP to an instance of the HCDLP (hyperelliptic curve discrete > logarithm problem) in a genus 31 hyperelliptic curve over GF(2^4), > and then solving the latter problem using the Enge-Gaudry method. > The elliptic curve chosen has order twice a prime, and so resists > all other known attacks, including Pollard rho which would take about > 2^62 steps. Our implementation of Enge-Gaudry solved the HCDLP instance > in less time than it took to solve the 108-bit ECC2-108K Certicom > challenge. > > We have also identified a class of elliptic curves over GF(2^155) > for which the ECDLP can be efficiently reduced to the HCDLP in a genus > 31 hyperelliptic curve over GF(2^5). These HCDLP instances can be solved > in about 27,000 days on a single 1GHz Pentium III machine, or in 30 > days on a network of 1000 such machines. This is less time than it takes > to perform exhaustive search for a 56-bit DES key. Note that Pollard > rho on an elliptic curve over GF(2^155) whose order is twice a prime would > take 2^77 steps which is considered infeasible. > > We did not actually solve an instance of the ECDLP for an elliptic curve > over GF(2^155). Note however that the expected time of 27,000 days > mentioned above is *exact* (see the paper for details). That is, we > did not make wild estimates based on asymptotic running times which > include O() or o(1) expressions as is done, for example, in estimating > the running time of the Number Field Sieve for factoring large integers. > > We carefully point out that the above attack only applies to 2^32 of the > 2^156 isomorphism classes of elliptic curves over GF(2^155). Thus, the > GHS attack is virtually certain to fail against a randomly chosen curve > over GF(2^155). However, given that there is much more work that remains > to be done understanding Weil descent, and that there are many possible > ways in which to extend the attack, my opinion is that elliptic curves > over GF(2^155) should be altogether avoided. > > If you wish to learn more about Weil descent, see Nigel Smart's collection > of papers at www.cs.bris.ac.uk/~nigel/weil_descent.html > > - Alfred From owner-ipsec@lists.tislabs.com Tue Jun 26 11:19:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QIJhm06849; Tue, 26 Jun 2001 11:19:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16049 Tue, 26 Jun 2001 13:31:31 -0400 (EDT) From: Internet-Drafts@ietf.org X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:51:09 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Tue, 26 Jun 2001 16:51:09 +0100 Message-Id: <200106261101.HAA27044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-07.txt Date: Tue, 26 Jun 2001 07:01:20 -0400 X-OriginalArrivalTime: 26 Jun 2001 17:39:06.0659 (UTC) FILETIME=[E6146730:01C0FE66] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-07.txt Pages : 11 Date : 25-Jun-01 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-07.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-shacham-ippcp-rfc2393bis-07.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-shacham-ippcp-rfc2393bis-07.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: <20010625095435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Con From owner-ipsec@lists.tislabs.com Tue Jun 26 11:29:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QITTm06978; Tue, 26 Jun 2001 11:29:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16082 Tue, 26 Jun 2001 13:42:43 -0400 (EDT) Message-ID: <3B38CAF7.DC67B322@storm.ca> Date: Tue, 26 Jun 2001 13:48:39 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: [Fwd: Re: P1363: prudent fields] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie Orman wrote: > > Given that the groups have no demonstrated mathematical > weaknesses However, enough problems with composite exponents have shown up that we just got this advice from a wel--known crytographer: | More generally, we recommend that elliptic curves over GF(2^n) | where be n is composite be avoided, including elliptic curves | over GF(2^185). > and that they have significant computational performance advantages, If performance depends only on the size of exponent, then those groups -- 2^155 and 2^185 -- have about the same performance as the group using 2^163. > there appears to be no reason to drop them. I'd say there's enough doubt that the cautious course would be to drop them. From owner-ipsec@lists.tislabs.com Tue Jun 26 11:54:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QIsmm07502; Tue, 26 Jun 2001 11:54:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16120 Tue, 26 Jun 2001 13:57:37 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 26 Jun 2001 11:35:16 -0600 From: "Hilarie Orman" To: Cc: Subject: Re: IPSEC Security Gateways & NAT 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 NAA16085 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A random nonce can be computed much more quickly than a hash. What's "counting N"? The point about the resource usage is that if you are under a severe attack, whether or not you have cookies you need to keep track of state. The cookies help only against mild attacks. Even then, I'd assume any resilient system would be managing resources carefully, balancing connection state memory against other memory demands. Such systems *should* be able to adjust to mild attacks without noticeable loss of service. Hilarie >>> Derek Atkins 06/26/01 07:59AM >>> The "extra computation" is really not much more than creating the cookie itself. It doesn't have to be encrypted data; it can be a keyed hash or some other verifiable system. It's probably just as much work as running a PRNG to generate a random NONCE for a cookie. It is certainly much less work than having to keep track of N message-1 messages sitting around and then seeing if you're under attack by counting N. You don't really need to keep track of resource usage; you _can_ choose do so. However, no, this does not require the same amount of state as recording all your message-1 state for each initiator. What's easier, keeping a counter or keeping all the cookie state from all the initiators? -derek PS: I have no objection to an optional stateless cookie round-trip. "Hilarie Orman" writes: > The statelessness seems to exist only in non-stressed circumstances. > If there really is a resource shortage, such as would occur in a denial > of service attack, then one needs to start keeping track of resource > usage, and that means keeping state around, doesn't it? The stateless > cryptographic cookie seems to have the disadvantage of requiring > extra computation even in the non-attack situation, whereas, the > stateful approach requires no extra work until an attack is underway. > > Hilarie > > >>> Bill Sommerfeld 06/25/01 11:19AM >>> > > Is anyone still interested in Base Mode? It would be possible to create > > a Base Mode where reception of the first message is stateless to the Responder, > > by sending the state back in msg2 encrypted with some locally known symmetric > > key, and verified upon reception in msg3. This modified Base Mode > > could then be used to replace Aggressive Mode. The rationale for changing > > Base Mode would be that nobody's yet really using it (?), and that it's cool :). > > There's a paper by Pekka Nikander explaining the theory of making protocols > > stateless, forget where that is though. > > I'd be very interested in seeing a mode which is initially stateless > for the responder; it's a key bit of technology from photuris which > was never carried forward to IKE. > > - Bill -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Jun 26 12:32:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QJWum08691; Tue, 26 Jun 2001 12:32:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16236 Tue, 26 Jun 2001 14:42:49 -0400 (EDT) Message-Id: <200106261848.f5QImKx06872@thunk.east.sun.com> From: Bill Sommerfeld To: "Hilarie Orman" cc: warlord@mit.edu, ipsec@lists.tislabs.com Subject: Re: IPSEC Security Gateways & NAT In-reply-to: Your message of "Tue, 26 Jun 2001 11:35:16 MDT." Reply-to: sommerfeld@East.Sun.COM Date: Tue, 26 Jun 2001 14:48:20 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stateless cookies provide a complete defense against a limited class of attacks which are very easy to mount: namely, packet-flooding programs which merely spew correctly-formatted requests onto the network, possibly with forged source addresses. Stateless cookies are a first line of defense; they're not a substitute for the careful resource management needed to protect against more sophisticated denial-of-service attacks. That said, in the presence of a packet flood, stateless cookies make the chance that a legitimate user will be dropped significantly less. > A random nonce can be computed much more quickly than > a hash. If the protocol allowed for stateless cookies, implementors could choose to implement stateful cookies if they felt it made more sense to tie up large amounts of memory instead of small amounts of cpu. In most cases, folks are using hash-based random number generators and have enough cpu that they're comfortable using the same hash function for protecting AH & ESP traffic. Also, someone pointed out to me that there's no particular need to add a round-trip for stateless cookies; you merely need to make sure that message 3 contains everything in message 1 plus the cookie from message 2.. - Bill From owner-ipsec@lists.tislabs.com Tue Jun 26 12:37:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QJbkm08845; Tue, 26 Jun 2001 12:37:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16248 Tue, 26 Jun 2001 14:44:41 -0400 (EDT) Date: Tue, 26 Jun 2001 11:22:56 -0700 (PDT) From: Avram Shacham X-Sender: shacham@zev.net To: ippcp@external.cisco.com cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-shacham-ippcp-rfc2393bis-07.txt In-Reply-To: <200106261101.HAA27044@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Attached is the annotated content diff between versions -06 and -07 of rfc2393bis. The changes in version -07 are based on the comments by Thomas Narten, the Internet AD. (Note: http://shacham.net/ipcomp/ provides details on rfc2393bis et al.) Regards, avram 1. Compressing before encryption is now defined as 'must' instead of 'MUST'. In addition to not being a protocol requirement, some threads of the ipsec alias insisted that the policy (i.e., order of protocols as negotiated) is holy, and could not agree that compression after encryption makes no sense. Still, "Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol... ineffective." *** 49,64 **** to be random in nature, rendering compression at lower protocol layers (e.g., PPP Compression Control Protocol [RFC-1962]) ineffective. If both compression and encryption are required, ! compression MUST be applied before encryption. --- 49,64 ---- to be random in nature, rendering compression at lower protocol layers (e.g., PPP Compression Control Protocol [RFC-1962]) ineffective. If both compression and encryption are required, ! compression must be applied before encryption. *************** 2. Typo: 'MUST NOT' should have been here always. *** 126,132 **** In the IPv6 context, IPComp is viewed as an end-to-end payload, and ! MUST not apply to hop-by-hop, routing, and fragmentation extension headers. The compression is applied starting at the first IP Header Option field that does not carry information that must be examined --- 126,132 ---- In the IPv6 context, IPComp is viewed as an end-to-end payload, and ! MUST NOT apply to hop-by-hop, routing, and fragmentation extension headers. The compression is applied starting at the first IP Header Option field that does not carry information that must be examined *************** 3. s/than MTU/than the MTU/ *** 159,169 **** IPComp header is added to the datagram. This policy ensures saving the decompression processing cycles and avoiding incurring IP ! datagram fragmentation when the expanded datagram is larger than MTU. --- 159,170 ---- IPComp header is added to the datagram. This policy ensures saving the decompression processing cycles and avoiding incurring IP ! datagram fragmentation when the expanded datagram is larger than the ! MTU. *************** 4. Clarifying the description of some of the constants in the adaptive algorithm. *** 177,188 **** an upper layer in the communication stack, or by an off-line compression utility. An adaptive algorithm should be implemented to avoid the performance hit. For example, if the compression of i ! consecutive IP datagrams of an IPCA fails, the next k IP datagrams ! are sent without attempting compression. If the next j datagrams are ! also failing to compress, the next k+n datagrams are sent without ! attempting compression. Once a datagram is compressed successfully, ! the normal process of IPComp restarts. Such an adaptive algorithm, ! including all the related thresholds, is implementation dependent. --- 178,190 ---- an upper layer in the communication stack, or by an off-line compression utility. An adaptive algorithm should be implemented to avoid the performance hit. For example, if the compression of i ! consecutive IP datagrams of an IPCA fails, the next several IP ! datagrams, say k, are sent without attempting compression. If then ! the next j datagrams also fail to compress, a larger number of ! datagrams, say k+n, are sent without attempting compression. Once a ! datagram is compressed successfully, the normal process of IPComp ! restarts. Such an adaptive algorithm, including all the related ! thresholds, is implementation dependent. *************** 5. Adding a section for 'IANA Considerations' *** 457,468 **** ! 6. References --- 459,475 ---- + 6. IANA Considerations ! This document does not require any IANA actions. The well-known ! numbers used in this document are defined elsewhere; see [SECDOI]. ! 7. References === eom === On Tue, 26 Jun 2001 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Payload Compression Protocol (IPComp) > Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas > Filename : draft-shacham-ippcp-rfc2393bis-07.txt > Pages : 11 > Date : 25-Jun-01 > > This document describes a protocol intended to provide lossless > compression for Internet Protocol datagrams in an Internet > environment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt > [...] From owner-ipsec@lists.tislabs.com Tue Jun 26 20:50:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5R3oCm05471; Tue, 26 Jun 2001 20:50:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17372 Tue, 26 Jun 2001 23:00:36 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD78C@mail.ellacoya.com> From: "Chen, David" To: "'Hilarie Orman '" , "'warlord@mit.edu '" Cc: "'ipsec@lists.tislabs.com '" Subject: RE: IPSEC Security Gateways & NAT Date: Tue, 26 Jun 2001 23:03:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie, One idea of deter/defend a DOS attack is the attacker (initiator) will use more computing resource than the responder. By designing the protocol to implement this idea, it seems redundant to count responder's resources (therefore keep state) to prevent from its resouce starvation. The reason is that when a responder throttle on communication or resource and "deny valid service request", it is a successful DOS attack. Regards, --- David -----Original Message----- From: Hilarie Orman To: warlord@mit.edu Cc: ipsec@lists.tislabs.com Sent: 6/26/01 1:35 PM Subject: Re: IPSEC Security Gateways & NAT A random nonce can be computed much more quickly than a hash. What's "counting N"? The point about the resource usage is that if you are under a severe attack, whether or not you have cookies you need to keep track of state. The cookies help only against mild attacks. Even then, I'd assume any resilient system would be managing resources carefully, balancing connection state memory against other memory demands. Such systems *should* be able to adjust to mild attacks without noticeable loss of service. Hilarie >>> Derek Atkins 06/26/01 07:59AM >>> The "extra computation" is really not much more than creating the cookie itself. It doesn't have to be encrypted data; it can be a keyed hash or some other verifiable system. It's probably just as much work as running a PRNG to generate a random NONCE for a cookie. It is certainly much less work than having to keep track of N message-1 messages sitting around and then seeing if you're under attack by counting N. You don't really need to keep track of resource usage; you _can_ choose do so. However, no, this does not require the same amount of state as recording all your message-1 state for each initiator. What's easier, keeping a counter or keeping all the cookie state from all the initiators? -derek PS: I have no objection to an optional stateless cookie round-trip. "Hilarie Orman" writes: > The statelessness seems to exist only in non-stressed circumstances. > If there really is a resource shortage, such as would occur in a denial > of service attack, then one needs to start keeping track of resource > usage, and that means keeping state around, doesn't it? The stateless > cryptographic cookie seems to have the disadvantage of requiring > extra computation even in the non-attack situation, whereas, the > stateful approach requires no extra work until an attack is underway. > > Hilarie > > >>> Bill Sommerfeld 06/25/01 11:19AM >>> > > Is anyone still interested in Base Mode? It would be possible to create > > a Base Mode where reception of the first message is stateless to the Responder, > > by sending the state back in msg2 encrypted with some locally known symmetric > > key, and verified upon reception in msg3. This modified Base Mode > > could then be used to replace Aggressive Mode. The rationale for changing > > Base Mode would be that nobody's yet really using it (?), and that it's cool :). > > There's a paper by Pekka Nikander explaining the theory of making protocols > > stateless, forget where that is though. > > I'd be very interested in seeing a mode which is initially stateless > for the responder; it's a key bit of technology from photuris which > was never carried forward to IKE. > > - Bill -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jun 27 01:22:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5R8Mpm28181; Wed, 27 Jun 2001 01:22:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17792 Wed, 27 Jun 2001 03:20:42 -0400 (EDT) Message-ID: From: Chris Trobridge To: Helger Lipmaa Cc: ipsec@lists.tislabs.com Subject: RE: AES Key Integrity Date: Wed, 27 Jun 2001 08:27:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On Tue, 26 Jun 2001, Chris Trobridge wrote: > > > It has just occurred to me that I've not noticed any references to a > > standard integrity mechanism for AES. > > > > Will there be one? > > > > DES has parity, but a CRC would be better. > > > > As crypto gets (theoretically) stronger issues like > reliability become much > > more important. > > This is an important issue, but it does not (and should not) > depend on the concrete algorithm like AES. The subscribers from NIST to > this list might want to consider adopting a standard for storing > cryptographic keys (of any algorithm) for increasing reliability. Agreed. > Of course, standard here is mainly needed for interoperability: That's really what I'm thinking about. While there aren't a lot of direct transfers of keys between IPSEC instances (pre-shared and multicast cases?), there will be standard crypto libraries that should include key integrity. In most cases we check the key integrity in the crypto-hardware when the key is loaded, so this would involve the chip designers. > All you need is an error-correcting code (ECC) together with an optional > (keyed?) hash. (Unkeyed hash does not really seem to be necessary if one > already employes an ECC.) > For most of the purposes a very simple ECC like Hamming code is good enough. Yes. I've not come across ECC on keys - I think that the rational may be that its better to detect and discard corrupted keys (and generate new ones) than correct keys with a lower probability of success. Of course if you're not in a position to renogotiate then ECC is clearly the better option. > Helger > PS What a nice scary signature... Quite! I'm afraid there's nothing I can do about it - it's added somewhere downstream... Chris ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Jun 27 05:15:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RCF7m07913; Wed, 27 Jun 2001 05:15:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18617 Wed, 27 Jun 2001 06:57:49 -0400 (EDT) Message-Id: <200106271103.HAA26170@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-msec-gkmarch-00.txt Date: Wed, 27 Jun 2001 07:03:10 -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 Multicast Security Working Group of the IETF. Title : Group Key Management Architecture Author(s) : M. Baugher, R. Canetti, L. Dondeti Filename : draft-ietf-msec-gkmarch-00.txt Pages : 22 Date : 26-Jun-01 This document presents a group key-management architecture for MSEC. The purpose of this document is to define the common architecture for MSEC group key-management protocols that support a variety of application, transport, and internetwork security protocols. To address these diverse uses, MSEC may need to standardize two or more group key management protocols that have common requirements, abstractions, overall design, and messages. The framework and guidelines in this document allow for a modular and flexible design of group key management protocols for a variety different settings that are specialized to application needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-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-msec-gkmarch-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-msec-gkmarch-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: <20010626132202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gkmarch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gkmarch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010626132202.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jun 27 07:24:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5REOOm11470; Wed, 27 Jun 2001 07:24:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18893 Wed, 27 Jun 2001 09:32:32 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Tue, 26 Jun 2001 15:31:39 -0600 From: "Hilarie Orman" To: Cc: Subject: Re: [Fwd: Re: P1363: prudent fields] 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 RAA16753 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Composite exponents permit implementation using field towers and lead to performance advantages. Hilarie >>> Sandy Harris 06/26/01 11:48AM >>> Hilarie Orman wrote: > > Given that the groups have no demonstrated mathematical > weaknesses However, enough problems with composite exponents have shown up that we just got this advice from a wel--known crytographer: | More generally, we recommend that elliptic curves over GF(2^n) | where be n is composite be avoided, including elliptic curves | over GF(2^185). > and that they have significant computational performance advantages, If performance depends only on the size of exponent, then those groups -- 2^155 and 2^185 -- have about the same performance as the group using 2^163. > there appears to be no reason to drop them. I'd say there's enough doubt that the cautious course would be to drop them. From owner-ipsec@lists.tislabs.com Wed Jun 27 07:31:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5REV9m11705; Wed, 27 Jun 2001 07:31:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18899 Wed, 27 Jun 2001 09:33:32 -0400 (EDT) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Wed, 27 Jun 2001 08:54:54 +0300 (EET DST) From: Helger Lipmaa To: Chris Trobridge cc: Subject: Re: AES Key Integrity 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 Tue, 26 Jun 2001, Chris Trobridge wrote: > It has just occurred to me that I've not noticed any references to a > standard integrity mechanism for AES. > > Will there be one? > > DES has parity, but a CRC would be better. > > As crypto gets (theoretically) stronger issues like reliability become much > more important. This is an important issue, but it does not (and should not) depend on the concrete algorithm like AES. The subscribers from NIST to this list might want to consider adopting a standard for storing cryptographic keys (of any algorithm) for increasing reliability. Of course, standard here is mainly needed for interoperability: All you need is an error-correcting code (ECC) together with an optional (keyed?) hash. (Unkeyed hash does not really seem to be necessary if one already employes an ECC.) For most of the purposes a very simple ECC like Hamming code is good enough. Helger PS What a nice scary signature... > ----------------------------------------------------------------------------------------------------------------- > The information contained in this message is confidential and is intended > for the addressee(s) only. If you have received this message in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this message is > strictly forbidden. Baltimore Technologies plc will not be liable for direct, > special, indirect or consequential damages arising from alteration of the > contents of this message by a third party or as a result of any virus being > passed on. > > In addition, certain Marketing collateral may be added from time to time to > promote Baltimore Technologies products, services, Global e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. > From owner-ipsec@lists.tislabs.com Wed Jun 27 08:56:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RFuXm18735; Wed, 27 Jun 2001 08:56:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19181 Wed, 27 Jun 2001 10:53:29 -0400 (EDT) Message-ID: <8B204D152222D51182B7000102884137202475@postmaster.cryptek.com> From: "Aronson, David" To: "'Chen, David'" Cc: "'ipsec@lists.tislabs.com '" , "'Hilarie Orman '" , "'warlord@mit.edu '" Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 27 Jun 2001 11:21:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Chen writes: > One idea of deter/defend a DOS attack is the attacker > (initiator) will use more computing resource than the responder. But sometimes the attacking person doesn't care. Imagine these scenarios: - The attacker's CPU horsepower is greater than yours, by enough that he can drown you out without affecting too much whatever else he wants to do. This could be either because he has a much faster system, or because he has several systems attacking yours at once (i.e., a *Distributed* Denial of Service Attack). - The attacking *system* (or group thereof) is not the property of the attacking *person*, so the person doesn't care. This is generally the case in a DDoS attack, launched via a number of zombies, and often the case in others, just for track-covering purposes. - The attacking system (or group thereof) is in fact a secondary *victim* of the attacking person, so the person is even *happy* that the attacking system is using up its CPU horsepower. - Lastly, don't forget the non-technical aspects. Maybe the attacker simply doesn't have anything better to do with his time. (Mainly CPU time, but I suspect many skr1pt k1dd13s have nothing better to do with their real-world time!) He can thus essentially subtract his CPU horsepower (or a significant fraction thereof) from yours, without really being bothered; in fact, he may find it entertaining, at least more so than homework. -- Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714. Opinions all MINE, not by Cryptek/NRA/SCA/Mensa/HWG/LPUSA/CAUCE/FedGov/God! See my web site, at http://listen.to/davearonson (last updated 2001-06-27). Device-driver proggers: see http://www.cryptek.com and send me your resume! From owner-ipsec@lists.tislabs.com Wed Jun 27 09:48:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RGmpm20424; Wed, 27 Jun 2001 09:48:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19318 Wed, 27 Jun 2001 11:44:21 -0400 (EDT) Message-ID: <85D31AAF3DFCD4119C44000102C009707DD78D@mail.ellacoya.com> From: "Chen, David" To: "'Aronson, David '" Cc: "''ipsec@lists.tislabs.com ' '" , "''Hilarie Orman ' '" , "''warlord@mit.edu ' '" Subject: RE: IPSEC Security Gateways & NAT Date: Wed, 27 Jun 2001 11:46:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David A., Agreed, However, Only the higher security system will have more resource and will be highly visiable to community (the order could be reversed). If this is a valuable IPSec server, the organization will have alocated more valuable computing resource to it. If the protocol design such a way that the (D)DOS attacker will at least do such or more, then the attacker will be equally located (due to consume lots of valuable resource) as the responder. It is better than require all ISP and POP trace all the "suspect" traffic which is in-effective and sacrifies the "privacy" that the IPSec started from. Regards, --- David -----Original Message----- From: Aronson, David To: 'Chen, David' Cc: 'ipsec@lists.tislabs.com '; 'Hilarie Orman '; 'warlord@mit.edu ' Sent: 6/27/01 11:21 AM Subject: RE: IPSEC Security Gateways & NAT David Chen writes: > One idea of deter/defend a DOS attack is the attacker > (initiator) will use more computing resource than the responder. But sometimes the attacking person doesn't care. Imagine these scenarios: - The attacker's CPU horsepower is greater than yours, by enough that he can drown you out without affecting too much whatever else he wants to do. This could be either because he has a much faster system, or because he has several systems attacking yours at once (i.e., a *Distributed* Denial of Service Attack). - The attacking *system* (or group thereof) is not the property of the attacking *person*, so the person doesn't care. This is generally the case in a DDoS attack, launched via a number of zombies, and often the case in others, just for track-covering purposes. - The attacking system (or group thereof) is in fact a secondary *victim* of the attacking person, so the person is even *happy* that the attacking system is using up its CPU horsepower. - Lastly, don't forget the non-technical aspects. Maybe the attacker simply doesn't have anything better to do with his time. (Mainly CPU time, but I suspect many skr1pt k1dd13s have nothing better to do with their real-world time!) He can thus essentially subtract his CPU horsepower (or a significant fraction thereof) from yours, without really being bothered; in fact, he may find it entertaining, at least more so than homework. -- Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714. Opinions all MINE, not by Cryptek/NRA/SCA/Mensa/HWG/LPUSA/CAUCE/FedGov/God! See my web site, at http://listen.to/davearonson (last updated 2001-06-27). Device-driver proggers: see http://www.cryptek.com and send me your resume! From owner-ipsec@lists.tislabs.com Wed Jun 27 11:40:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RIenm23580; Wed, 27 Jun 2001 11:40:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19587 Wed, 27 Jun 2001 13:34:30 -0400 (EDT) Message-ID: <3B3A1A8F.719CC71A@columbia.sparta.com> Date: Wed, 27 Jun 2001 13:40:31 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Content-Type: multipart/mixed; boundary="------------16E7FAA3FE0F613E9E63D3F3" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------16E7FAA3FE0F613E9E63D3F3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------16E7FAA3FE0F613E9E63D3F3 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> Date: Wed, 27 Jun 2001 13:30:31 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt References: <200106271103.HAA26170@ietf.org> Content-Type: multipart/alternative; boundary="------------E7B7F4EE607BF84BF270BC1C" --------------E7B7F4EE607BF84BF270BC1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, etal, Initial comments on the architecture -- 1. Section 1. -- > Extensions to IKE, however, are probably the best solution for IPsec > protocols over IP multicast services [GDOI]. > The architecture document is not an appropriate place for blatant editorialisms. 2. > A "secure group" is a collection of principals, > called "members," who may be senders, receivers or both receivers and > senders to other members of the group. (Note that group membership may > vary over time.) A "group key management protocol" ensures that only > members of a secure group gain access to group data (by gaining access > to group keys) and can authenticate group data. > A secure group is a group in which access to data is restricted to particular entities. This access can be of read and/or write access. In other words, a group may only have write restrictions and no read restrictions. While this access may be enforced with group keys, it is mandated by a policy that claims data will only be accepted from particular entities, which could also be enforced with signature keys. A key distribution protocol alone does not define a secure group. This really demands a _security management_ protocol that can manage keys and policy. 3. > 4. The key-management protocol must be secure against man-in-the- > middle, connection-hijacking, and reflection/replay attacks; it must > use best-known practices to thwart denial-of-service attacks. > And type attacks. And attacks resulting from lack of explicitness (mis-routed, mis-interpreted). And interleaved with other protocols (protocol-oracle), etc. Perhaps it would be better to generalize this statement. 4. In general all the requirements for a group key management protocol refer to a group security management protocol. For example: Changes in algorithms, access, etc are changes to POLICY. Policy is _so_ much more than "meta-data describing the keys." 5. Re: video on demand example. The example shows a pre-existing group of all possible members subject to pre-broadcast rekey. One broadcast would destroy this property. 6. > A centralized > group controller (or KDC) that is used in this architecture may not be > the best design for small, interactive groups. But for large, single- > source multicast groups, it is generally undesirable to distribute key > management functions among group members: Unlike small, interactive > groups, large single-source multicast groups generally need a > specialized KDC to support large numbers of group members. Large > distributed simulations, moreover, may combine the need for large-grou > operation with many senders. > Large groups require distributed initial key distribution! Large dynamic groups cannot rely upon a centralized KDC. This does not scale. This is highly inflexible. The VoD example demonstrates this. While the interactions with distributed rekey entities is more complicated, this functionality may be needed in composite multicast groups of limited scope. 7. > It may be that no > single key management protocol can satisfy the scalability requirements > of all group-security applications. This is for further study. > It may be that the security protocols protecting group communications data cannot satisfy each of the possible sender/receiver profiles. This is less of a security management problem. 8. > This design is based upon a "group controller" model > [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > owner as the root-of-trust. The group owner designates a key > distribution center for member registration and re-key. > As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers. 9. Section 3.2 -- The term TEK is inappropriately specific. The group may not have encryption requirements, but only authentication. 10. > Only one SA is optional and that is the Re-key > SA. > Actually, one policy for the Re-Key SA is that there is none. It is null. Explicitly stating this prevents confusion between missing SA info and optional SA info. Likewise, the registration protocol may involve manual methods. 11. > The KDC, moreover, can be delegated when the > trust infrastructure supports delegation to permit distributed > operation of the KDC. > This statement, while correct, seems to conflict with the statement quoted in Comment #6. 12. > MSEC assumes that at least the following group-policy information is > externally managed. > o Group owner, authentication method, and delegation method for > identifying a KDC for the group > o Group KDC, authentication method, and any method used for > delegating other KDCs for the group > o Group membership rules or list and authentication method > These assumptions are unnecessary as was shown by GSAKMP. I. While the group owner may be published externally, the group owner can also be disclosed during the registration protocol. It can be decided during this time whether the owner is acceptable prior to completion of registration. Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI. II. The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP. III. Ditto for membership rules and lists IV. The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc. External management of these can be done, but should not be assumed in the architecture document. 13. In general, this document contains very little new information. The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs. The architecture document should work toward providing interoperable solutions. --- Andrea Colegrove Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : Group Key Management Architecture > Author(s) : M. Baugher, R. Canetti, L. Dondeti > Filename : draft-ietf-msec-gkmarch-00.txt > Pages : 22 > Date : 26-Jun-01 > > This document presents a group key-management architecture for MSEC. > The purpose of this document is to define the common architecture for > MSEC group key-management protocols that support a variety of > application, transport, and internetwork security protocols. To > address these diverse uses, MSEC may need to standardize two or more > group key management protocols that have common requirements, > abstractions, overall design, and messages. The framework and > guidelines in this document allow for a modular and flexible design of > group key management protocols for a variety different settings that > are specialized to application needs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-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-msec-gkmarch-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-msec-gkmarch-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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20010626132202.I-D@ietf.org> --------------E7B7F4EE607BF84BF270BC1C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, etal,
Initial comments on the architecture --

1.  Section 1. -- 

Extensions to IKE, however, are probably the best solution for IPsec 
protocols over IP multicast services [GDOI].
The architecture document is not an appropriate place for blatant editorialisms.

2. 

A "secure group" is a collection of principals, 
called "members," who may be senders, receivers or both receivers and 
senders to other members of the group. (Note that group membership may 
vary over time.) A "group key management protocol" ensures that only 
members of a secure group gain access to group data (by gaining access 
to group keys) and can authenticate group data.
A secure group is a group in which access to data is restricted to particular entities.  This access can be of read and/or write access.  In other words, a group may only have write restrictions and no read restrictions.  While this access may be enforced with group keys, it is mandated by a policy that claims data will only be accepted from particular entities, which could also be enforced with signature keys.  A key distribution protocol alone does not define a secure group.  This really demands a _security management_ protocol that can manage keys and policy.

3. 

4. The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay attacks; it must
   use best-known practices to thwart denial-of-service attacks.


And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.

4.  In general all the requirements for a group key management protocol refer to a group security management protocol.  For example:  Changes in algorithms, access, etc are changes to POLICY.  Policy is _so_ much more than "meta-data describing the keys."

5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

6. 

A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large, single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.

While the interactions with distributed rekey entities is more complicated, this functionality may be needed in composite multicast groups of limited scope.

7. 

It may be that no 
single key management protocol can satisfy the scalability requirements
of all group-security applications.  This is for further study.
It may be that the security protocols protecting group communications data cannot satisfy each of the possible sender/receiver profiles.  This is less of a security management problem.

8. 

This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

9.  Section 3.2 -- The term TEK is inappropriately specific.  The group may not have encryption requirements, but only authentication.

10. 

Only one SA is optional and that is the Re-key 
SA.


Actually, one policy for the Re-Key SA is that there is none.  It is null.  Explicitly stating this prevents confusion between missing SA info and optional SA info.  Likewise, the registration protocol may involve manual methods.

11. 

The KDC, moreover, can be delegated when the 
trust infrastructure supports delegation to permit distributed 
operation of the KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.

12. 

MSEC assumes that at least the following group-policy information is
externally managed.
  o Group owner, authentication method, and delegation method for 
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication method


These assumptions are unnecessary as was shown by GSAKMP.
    I.  While the group owner may be published externally, the group owner can also be disclosed during the registration protocol.  It can be decided during this time whether the owner is acceptable prior to completion of registration.  Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI.
    II.  The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP.
    III.  Ditto for membership rules and lists
    IV.  The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc.

    External management of these can be done, but should not be assumed in the architecture document.

13.  In general, this document contains very little new information.  The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs.  The architecture document should work toward providing interoperable solutions.

--- Andrea Colegrove
 
 

Internet-Drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast Security Working Group of the IETF.

        Title           : Group Key Management Architecture
        Author(s)       : M. Baugher, R. Canetti, L. Dondeti
        Filename        : draft-ietf-msec-gkmarch-00.txt
        Pages           : 22
        Date            : 26-Jun-01

This document presents a group key-management architecture for MSEC.
The purpose of this document is to define the common architecture for
MSEC group key-management protocols that support a variety of
application, transport, and internetwork security protocols.  To
address these diverse uses, MSEC may need to standardize two or more
group key management protocols that have common requirements,
abstractions, overall design, and messages. The framework and
guidelines in this document allow for a modular and flexible design of
group key management protocols for a variety different settings that
are specialized to application needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-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-msec-gkmarch-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-msec-gkmarch-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.

  ------------------------------------------------------------------------
Content-Type: text/plain
Content-ID:     <20010626132202.I-D@ietf.org>

--------------E7B7F4EE607BF84BF270BC1C-- --------------16E7FAA3FE0F613E9E63D3F3-- From owner-ipsec@lists.tislabs.com Wed Jun 27 15:04:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RM4vm29945; Wed, 27 Jun 2001 15:04:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20142 Wed, 27 Jun 2001 17:14:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Jun 2001 14:19:06 -0700 To: Andrea Colegrove From: Mark Baugher Subject: Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Cc: msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <3B3A1A8F.719CC71A@columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrea I respond to your first point in this note. At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: >X-Mozilla-Status2: 00000000 >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> >Date: Wed, 27 Jun 2001 13:30:31 -0400 >From: Andrea Colegrove >X-Mailer: Mozilla 4.75 [en] (Win98; U) >X-Accept-Language: en >MIME-Version: 1.0 >To: msec@securemulticast.org >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt >References: <200106271103.HAA26170@ietf.org> >Content-Type: multipart/alternative; > boundary="------------E7B7F4EE607BF84BF270BC1C" > >Mark, etal, >Initial comments on the architecture -- > >1. Section 1. -- >> >>Extensions to IKE, however, are probably the best solution for IPsec >>protocols over IP multicast services [GDOI]. >The architecture document is not an appropriate place for blatant >editorialisms. It is not as you say it is. I'll ignore the rudeness of this sentence and focus on the issue: It makes no sense to force AH and ESP to select a key management application based on whether it has a unicast or a multicast destination address in the packet it is processing. One may want to do that, but extensions to IKE are probably the best solution for IPsec protocols over IP multicast services. This is an architectural issue for it involves multiple functional blocks (data security protocols and key management protocol) , and it is why msec will likely standardize an IKE-based specification in addition to a something like GSAKMP (at least the key management protocol of it once that's separated out). I'll spare ipsec my comments on the rest of your points and post only to msec. Mark >2. >> >>A "secure group" is a collection of principals, >>called "members," who may be senders, receivers or both receivers and >>senders to other members of the group. (Note that group membership may >>vary over time.) A "group key management protocol" ensures that only >>members of a secure group gain access to group data (by gaining access >>to group keys) and can authenticate group data. >A secure group is a group in which access to data is restricted to >particular entities. This access can be of read and/or write access. In >other words, a group may only have write restrictions and no read >restrictions. While this access may be enforced with group keys, it is >mandated by a policy that claims data will only be accepted from >particular entities, which could also be enforced with signature keys. A >key distribution protocol alone does not define a secure group. This >really demands a _security management_ protocol that can manage keys and >policy. > >3. >> >>4. The key-management protocol must be secure against man-in-the- >> middle, connection-hijacking, and reflection/replay attacks; it must >> use best-known practices to thwart denial-of-service attacks. > > >And type attacks. And attacks resulting from lack of explicitness >(mis-routed, mis-interpreted). And interleaved with other protocols >(protocol-oracle), etc. Perhaps it would be better to generalize this >statement. > >4. In general all the requirements for a group key management protocol >refer to a group security management protocol. For example: Changes in >algorithms, access, etc are changes to POLICY. Policy is _so_ much more >than "meta-data describing the keys." > >5. Re: video on demand example. The example shows a pre-existing group >of all possible members subject to pre-broadcast rekey. One broadcast >would destroy this property. > >6. >> >>A centralized >>group controller (or KDC) that is used in this architecture may not be >>the best design for small, interactive groups. But for large, single- >>source multicast groups, it is generally undesirable to distribute key >>management functions among group members: Unlike small, interactive >>groups, large single-source multicast groups generally need a >>specialized KDC to support large numbers of group members. Large >>distributed simulations, moreover, may combine the need for large-grou >>operation with many senders. >Large groups require distributed initial key distribution! Large dynamic >groups cannot rely upon a centralized KDC. This does not scale. This is >highly inflexible. The VoD example demonstrates this. > >While the interactions with distributed rekey entities is more >complicated, this functionality may be needed in composite multicast >groups of limited scope. > >7. >> >>It may be that no >>single key management protocol can satisfy the scalability requirements >>of all group-security applications. This is for further study. >It may be that the security protocols protecting group communications data >cannot satisfy each of the possible sender/receiver profiles. This is >less of a security management problem. > >8. >> >>This design is based upon a "group controller" model >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group >>owner as the root-of-trust. The group owner designates a key >>distribution center for member registration and re-key. >As was originally envisioned, the group owner CAN (and for large or sparse >groups SHOULD) designate multiple key servers. > >9. Section 3.2 -- The term TEK is inappropriately specific. The group >may not have encryption requirements, but only authentication. > >10. >> >>Only one SA is optional and that is the Re-key >>SA. > > >Actually, one policy for the Re-Key SA is that there is none. It is >null. Explicitly stating this prevents confusion between missing SA info >and optional SA info. Likewise, the registration protocol may involve >manual methods. > >11. >> >>The KDC, moreover, can be delegated when the >>trust infrastructure supports delegation to permit distributed >>operation of the KDC. >This statement, while correct, seems to conflict with the statement quoted >in Comment #6. > >12. >> >>MSEC assumes that at least the following group-policy information is >>externally managed. >> o Group owner, authentication method, and delegation method for >> identifying a KDC for the group >> o Group KDC, authentication method, and any method used for >> delegating other KDCs for the group >> o Group membership rules or list and authentication method > > >These assumptions are unnecessary as was shown by GSAKMP. > I. While the group owner may be published externally, the group > owner can also be disclosed during the registration protocol. It can be > decided during this time whether the owner is acceptable prior to > completion of registration. Once this occurs, authenticated group policy > can be conveyed to the new member using traditional mechanisms such as > digital signatures tied to a PKI. > II. The delegation can be stated (authorized) through the > authenticated policy statement as was done with GSAKMP. > III. Ditto for membership rules and lists > IV. The security association characteristics of the registration > protocol can be determined early in the registration exchange or in > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > properties the Key Server will accept using cipher suite restrictions, > SPD constraints, etc. > > External management of these can be done, but should not be assumed > in the architecture document. > >13. In general, this document contains very little new information. The >framework for the architecture was already provided by the building block >documents with the category 1,2, and 3 SAs. The architecture document >should work toward providing interoperable solutions. > >--- Andrea Colegrove > > > >Internet-Drafts@ietf.org wrote: >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Multicast Security Working Group of the >>IETF. >> >> Title : Group Key Management Architecture >> Author(s) : M. Baugher, R. Canetti, L. Dondeti >> Filename : draft-ietf-msec-gkmarch-00.txt >> Pages : 22 >> Date : 26-Jun-01 >> >>This document presents a group key-management architecture for MSEC. >>The purpose of this document is to define the common architecture for >>MSEC group key-management protocols that support a variety of >>application, transport, and internetwork security protocols. To >>address these diverse uses, MSEC may need to standardize two or more >>group key management protocols that have common requirements, >>abstractions, overall design, and messages. The framework and >>guidelines in this document allow for a modular and flexible design of >>group key management protocols for a variety different settings that >>are specialized to application needs. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-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-msec-gkmarch-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-msec-gkmarch-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. >> >> ------------------------------------------------------------------------ >>Content-Type: text/plain >>Content-ID: <20010626132202.I-D@ietf.org> From owner-ipsec@lists.tislabs.com Wed Jun 27 17:09:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5S09km03403; Wed, 27 Jun 2001 17:09:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20468 Wed, 27 Jun 2001 19:25:42 -0400 (EDT) Message-ID: <3B3A6CDE.A29BA9A6@columbia.sparta.com> Date: Wed, 27 Jun 2001 19:31:42 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher CC: msec@securemulticast.org, ipsec@lists.tislabs.com Subject: Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] References: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, Since you are the primary author (editor?) of GDOI I am sure that you feel GDOI is best. The architecture document, however, is not the place to promote your solution. Many feel that modifications to a standard to support multicast is not a good solution. IKE is designed with certain assumptions which hold for pairwise paradigms but not necessarily groups. Also, because SPD and SAD values for a group cannot be completely determined in advance and are more likely distributed as part of the Join/Registration process, IKE will not likely be automatically fired off anyway (analogous to PPKs). Regardless of how you feel on this issue, it is inappropriate to state that GDOI is probably the best solution at this point in general and certainly not in the architecture document. Wrt GSAKMP and separating out the "key management protocol": key management involves more than distribution. --- Andrea Mark Baugher wrote: > Andrea > I respond to your first point in this note. > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > >X-Mozilla-Status2: 00000000 > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > >From: Andrea Colegrove > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: msec@securemulticast.org > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > >References: <200106271103.HAA26170@ietf.org> > >Content-Type: multipart/alternative; > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > >Mark, etal, > >Initial comments on the architecture -- > > > >1. Section 1. -- > >> > >>Extensions to IKE, however, are probably the best solution for IPsec > >>protocols over IP multicast services [GDOI]. > >The architecture document is not an appropriate place for blatant > >editorialisms. > > It is not as you say it is. I'll ignore the rudeness of this sentence and > focus > on the issue: It makes no sense to force AH and ESP to select a key management > application based on whether it has a unicast or a multicast destination > address in > the packet it is processing. One may want to do that, but extensions to > IKE are probably > the best solution for IPsec protocols over IP multicast services. This is > an architectural > issue for it involves multiple functional blocks (data security protocols > and key > management protocol) , and it is why msec will likely standardize an IKE-based > specification in addition to a something like GSAKMP (at least the key > management > protocol of it once that's separated out). > > I'll spare ipsec my comments on the rest of your points and post only to msec. > > Mark > > >2. > >> > >>A "secure group" is a collection of principals, > >>called "members," who may be senders, receivers or both receivers and > >>senders to other members of the group. (Note that group membership may > >>vary over time.) A "group key management protocol" ensures that only > >>members of a secure group gain access to group data (by gaining access > >>to group keys) and can authenticate group data. > >A secure group is a group in which access to data is restricted to > >particular entities. This access can be of read and/or write access. In > >other words, a group may only have write restrictions and no read > >restrictions. While this access may be enforced with group keys, it is > >mandated by a policy that claims data will only be accepted from > >particular entities, which could also be enforced with signature keys. A > >key distribution protocol alone does not define a secure group. This > >really demands a _security management_ protocol that can manage keys and > >policy. > > > >3. > >> > >>4. The key-management protocol must be secure against man-in-the- > >> middle, connection-hijacking, and reflection/replay attacks; it must > >> use best-known practices to thwart denial-of-service attacks. > > > > > >And type attacks. And attacks resulting from lack of explicitness > >(mis-routed, mis-interpreted). And interleaved with other protocols > >(protocol-oracle), etc. Perhaps it would be better to generalize this > >statement. > > > >4. In general all the requirements for a group key management protocol > >refer to a group security management protocol. For example: Changes in > >algorithms, access, etc are changes to POLICY. Policy is _so_ much more > >than "meta-data describing the keys." > > > >5. Re: video on demand example. The example shows a pre-existing group > >of all possible members subject to pre-broadcast rekey. One broadcast > >would destroy this property. > > > >6. > >> > >>A centralized > >>group controller (or KDC) that is used in this architecture may not be > >>the best design for small, interactive groups. But for large, single- > >>source multicast groups, it is generally undesirable to distribute key > >>management functions among group members: Unlike small, interactive > >>groups, large single-source multicast groups generally need a > >>specialized KDC to support large numbers of group members. Large > >>distributed simulations, moreover, may combine the need for large-grou > >>operation with many senders. > >Large groups require distributed initial key distribution! Large dynamic > >groups cannot rely upon a centralized KDC. This does not scale. This is > >highly inflexible. The VoD example demonstrates this. > > > >While the interactions with distributed rekey entities is more > >complicated, this functionality may be needed in composite multicast > >groups of limited scope. > > > >7. > >> > >>It may be that no > >>single key management protocol can satisfy the scalability requirements > >>of all group-security applications. This is for further study. > >It may be that the security protocols protecting group communications data > >cannot satisfy each of the possible sender/receiver profiles. This is > >less of a security management problem. > > > >8. > >> > >>This design is based upon a "group controller" model > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > >>owner as the root-of-trust. The group owner designates a key > >>distribution center for member registration and re-key. > >As was originally envisioned, the group owner CAN (and for large or sparse > >groups SHOULD) designate multiple key servers. > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > >may not have encryption requirements, but only authentication. > > > >10. > >> > >>Only one SA is optional and that is the Re-key > >>SA. > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > >null. Explicitly stating this prevents confusion between missing SA info > >and optional SA info. Likewise, the registration protocol may involve > >manual methods. > > > >11. > >> > >>The KDC, moreover, can be delegated when the > >>trust infrastructure supports delegation to permit distributed > >>operation of the KDC. > >This statement, while correct, seems to conflict with the statement quoted > >in Comment #6. > > > >12. > >> > >>MSEC assumes that at least the following group-policy information is > >>externally managed. > >> o Group owner, authentication method, and delegation method for > >> identifying a KDC for the group > >> o Group KDC, authentication method, and any method used for > >> delegating other KDCs for the group > >> o Group membership rules or list and authentication method > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > I. While the group owner may be published externally, the group > > owner can also be disclosed during the registration protocol. It can be > > decided during this time whether the owner is acceptable prior to > > completion of registration. Once this occurs, authenticated group policy > > can be conveyed to the new member using traditional mechanisms such as > > digital signatures tied to a PKI. > > II. The delegation can be stated (authorized) through the > > authenticated policy statement as was done with GSAKMP. > > III. Ditto for membership rules and lists > > IV. The security association characteristics of the registration > > protocol can be determined early in the registration exchange or in > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > properties the Key Server will accept using cipher suite restrictions, > > SPD constraints, etc. > > > > External management of these can be done, but should not be assumed > > in the architecture document. > > > >13. In general, this document contains very little new information. The > >framework for the architecture was already provided by the building block > >documents with the category 1,2, and 3 SAs. The architecture document > >should work toward providing interoperable solutions. > > > >--- Andrea Colegrove > > > > > > > >Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >>This draft is a work item of the Multicast Security Working Group of the > >>IETF. > >> > >> Title : Group Key Management Architecture > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > >> Filename : draft-ietf-msec-gkmarch-00.txt > >> Pages : 22 > >> Date : 26-Jun-01 > >> > >>This document presents a group key-management architecture for MSEC. > >>The purpose of this document is to define the common architecture for > >>MSEC group key-management protocols that support a variety of > >>application, transport, and internetwork security protocols. To > >>address these diverse uses, MSEC may need to standardize two or more > >>group key management protocols that have common requirements, > >>abstractions, overall design, and messages. The framework and > >>guidelines in this document allow for a modular and flexible design of > >>group key management protocols for a variety different settings that > >>are specialized to application needs. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-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-msec-gkmarch-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-msec-gkmarch-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. > >> > >> ------------------------------------------------------------------------ > >>Content-Type: text/plain > >>Content-ID: <20010626132202.I-D@ietf.org> From owner-ipsec@lists.tislabs.com Wed Jun 27 18:43:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5S1hMm05313; Wed, 27 Jun 2001 18:43:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20772 Wed, 27 Jun 2001 20:59:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20010627174400.0422be38@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Jun 2001 18:04:18 -0700 To: Andrea Colegrove From: Mark Baugher Subject: Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt] Cc: msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <3B3A6CDE.A29BA9A6@columbia.sparta.com> References: <4.3.2.7.2.20010627140639.04301090@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrea I am a co-author of the GDOI spec and have written part of the spec. My co-authors have not given me any additional titles. I gave you a technical argument and you give me back an ad hominem when you state that my concerns are merely to promote another specification through the architecture document. I'm telling you that is not the case and we'll do well to keep focused on the technical issues and not pretend to be omniscient with respect to others' intentions. You should ask for your refund from the Mind Reading Institute. When an IETF working group is promoting two specifications that do the same function, then an explanation is in order. When the function is key management, then the key management architecture document is an appropriate place to do the explaining. The sentence that upsets you so much is the rationale for doing GDOI. We are doing GDOI because a majority of the working group want a solution that is consistent with IKE, or else find out why we cannot have that. We are doing GSAKMP because the working group also wants a solution that will work over security transports such as IPsec or SSL. So far, our experience with GDOI (third-party analysis and implementation experience) leads us to believe that modifications to the IKE standard to support group key management is a good solution. Mark At 07:31 PM 6/27/2001 -0400, Andrea Colegrove wrote: >Mark, > Since you are the primary author (editor?) of GDOI I am sure that you > feel GDOI is best. The architecture document, however, is not the >place to promote your solution. > Many feel that modifications to a standard to support multicast is > not a good solution. IKE is designed with certain assumptions which >hold for pairwise paradigms but not necessarily groups. > Also, because SPD and SAD values for a group cannot be completely > determined in advance and are more likely distributed as part of the >Join/Registration process, IKE will not likely be automatically fired off >anyway (analogous to PPKs). > Regardless of how you feel on this issue, it is inappropriate to > state that GDOI is probably the best solution at this point in general >and certainly not in the architecture document. > Wrt GSAKMP and separating out the "key management protocol": key > management involves more than distribution. > >--- Andrea > > > >Mark Baugher wrote: > > > Andrea > > I respond to your first point in this note. > > > > At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote: > > > > >X-Mozilla-Status2: 00000000 > > >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com> > > >Date: Wed, 27 Jun 2001 13:30:31 -0400 > > >From: Andrea Colegrove > > >X-Mailer: Mozilla 4.75 [en] (Win98; U) > > >X-Accept-Language: en > > >MIME-Version: 1.0 > > >To: msec@securemulticast.org > > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt > > >References: <200106271103.HAA26170@ietf.org> > > >Content-Type: multipart/alternative; > > > boundary="------------E7B7F4EE607BF84BF270BC1C" > > > > > >Mark, etal, > > >Initial comments on the architecture -- > > > > > >1. Section 1. -- > > >> > > >>Extensions to IKE, however, are probably the best solution for IPsec > > >>protocols over IP multicast services [GDOI]. > > >The architecture document is not an appropriate place for blatant > > >editorialisms. > > > > It is not as you say it is. I'll ignore the rudeness of this sentence and > > focus > > on the issue: It makes no sense to force AH and ESP to select a key > management > > application based on whether it has a unicast or a multicast destination > > address in > > the packet it is processing. One may want to do that, but extensions to > > IKE are probably > > the best solution for IPsec protocols over IP multicast services. This is > > an architectural > > issue for it involves multiple functional blocks (data security protocols > > and key > > management protocol) , and it is why msec will likely standardize an > IKE-based > > specification in addition to a something like GSAKMP (at least the key > > management > > protocol of it once that's separated out). > > > > I'll spare ipsec my comments on the rest of your points and post only > to msec. > > > > Mark > > > > >2. > > >> > > >>A "secure group" is a collection of principals, > > >>called "members," who may be senders, receivers or both receivers and > > >>senders to other members of the group. (Note that group membership may > > >>vary over time.) A "group key management protocol" ensures that only > > >>members of a secure group gain access to group data (by gaining access > > >>to group keys) and can authenticate group data. > > >A secure group is a group in which access to data is restricted to > > >particular entities. This access can be of read and/or write access. In > > >other words, a group may only have write restrictions and no read > > >restrictions. While this access may be enforced with group keys, it is > > >mandated by a policy that claims data will only be accepted from > > >particular entities, which could also be enforced with signature keys. A > > >key distribution protocol alone does not define a secure group. This > > >really demands a _security management_ protocol that can manage keys and > > >policy. > > > > > >3. > > >> > > >>4. The key-management protocol must be secure against man-in-the- > > >> middle, connection-hijacking, and reflection/replay attacks; it must > > >> use best-known practices to thwart denial-of-service attacks. > > > > > > > > >And type attacks. And attacks resulting from lack of explicitness > > >(mis-routed, mis-interpreted). And interleaved with other protocols > > >(protocol-oracle), etc. Perhaps it would be better to generalize this > > >statement. > > > > > >4. In general all the requirements for a group key management protocol > > >refer to a group security management protocol. For example: Changes in > > >algorithms, access, etc are changes to POLICY. Policy is _so_ much more > > >than "meta-data describing the keys." > > > > > >5. Re: video on demand example. The example shows a pre-existing group > > >of all possible members subject to pre-broadcast rekey. One broadcast > > >would destroy this property. > > > > > >6. > > >> > > >>A centralized > > >>group controller (or KDC) that is used in this architecture may not be > > >>the best design for small, interactive groups. But for large, single- > > >>source multicast groups, it is generally undesirable to distribute key > > >>management functions among group members: Unlike small, interactive > > >>groups, large single-source multicast groups generally need a > > >>specialized KDC to support large numbers of group members. Large > > >>distributed simulations, moreover, may combine the need for large-grou > > >>operation with many senders. > > >Large groups require distributed initial key distribution! Large dynamic > > >groups cannot rely upon a centralized KDC. This does not scale. This is > > >highly inflexible. The VoD example demonstrates this. > > > > > >While the interactions with distributed rekey entities is more > > >complicated, this functionality may be needed in composite multicast > > >groups of limited scope. > > > > > >7. > > >> > > >>It may be that no > > >>single key management protocol can satisfy the scalability requirements > > >>of all group-security applications. This is for further study. > > >It may be that the security protocols protecting group communications data > > >cannot satisfy each of the possible sender/receiver profiles. This is > > >less of a security management problem. > > > > > >8. > > >> > > >>This design is based upon a "group controller" model > > >>[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group > > >>owner as the root-of-trust. The group owner designates a key > > >>distribution center for member registration and re-key. > > >As was originally envisioned, the group owner CAN (and for large or sparse > > >groups SHOULD) designate multiple key servers. > > > > > >9. Section 3.2 -- The term TEK is inappropriately specific. The group > > >may not have encryption requirements, but only authentication. > > > > > >10. > > >> > > >>Only one SA is optional and that is the Re-key > > >>SA. > > > > > > > > >Actually, one policy for the Re-Key SA is that there is none. It is > > >null. Explicitly stating this prevents confusion between missing SA info > > >and optional SA info. Likewise, the registration protocol may involve > > >manual methods. > > > > > >11. > > >> > > >>The KDC, moreover, can be delegated when the > > >>trust infrastructure supports delegation to permit distributed > > >>operation of the KDC. > > >This statement, while correct, seems to conflict with the statement quoted > > >in Comment #6. > > > > > >12. > > >> > > >>MSEC assumes that at least the following group-policy information is > > >>externally managed. > > >> o Group owner, authentication method, and delegation method for > > >> identifying a KDC for the group > > >> o Group KDC, authentication method, and any method used for > > >> delegating other KDCs for the group > > >> o Group membership rules or list and authentication method > > > > > > > > >These assumptions are unnecessary as was shown by GSAKMP. > > > I. While the group owner may be published externally, the group > > > owner can also be disclosed during the registration protocol. It can be > > > decided during this time whether the owner is acceptable prior to > > > completion of registration. Once this occurs, authenticated group policy > > > can be conveyed to the new member using traditional mechanisms such as > > > digital signatures tied to a PKI. > > > II. The delegation can be stated (authorized) through the > > > authenticated policy statement as was done with GSAKMP. > > > III. Ditto for membership rules and lists > > > IV. The security association characteristics of the registration > > > protocol can be determined early in the registration exchange or in > > > almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what > > > properties the Key Server will accept using cipher suite restrictions, > > > SPD constraints, etc. > > > > > > External management of these can be done, but should not be assumed > > > in the architecture document. > > > > > >13. In general, this document contains very little new information. The > > >framework for the architecture was already provided by the building block > > >documents with the category 1,2, and 3 SAs. The architecture document > > >should work toward providing interoperable solutions. > > > > > >--- Andrea Colegrove > > > > > > > > > > > >Internet-Drafts@ietf.org wrote: > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > >>directories. > > >>This draft is a work item of the Multicast Security Working Group of the > > >>IETF. > > >> > > >> Title : Group Key Management Architecture > > >> Author(s) : M. Baugher, R. Canetti, L. Dondeti > > >> Filename : draft-ietf-msec-gkmarch-00.txt > > >> Pages : 22 > > >> Date : 26-Jun-01 > > >> > > >>This document presents a group key-management architecture for MSEC. > > >>The purpose of this document is to define the common architecture for > > >>MSEC group key-management protocols that support a variety of > > >>application, transport, and internetwork security protocols. To > > >>address these diverse uses, MSEC may need to standardize two or more > > >>group key management protocols that have common requirements, > > >>abstractions, overall design, and messages. The framework and > > >>guidelines in this document allow for a modular and flexible design of > > >>group key management protocols for a variety different settings that > > >>are specialized to application needs. > > >> > > >>A URL for this Internet-Draft is: > > >>ht > tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-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-msec-gkmarch-00.txt". > > >> > > >>A list of Internet-Drafts directories can be found in > > >>http://www.ietf.org/shadow.html > > >>or > > >>ftp://ftp.ietf.org/ietf/1sh > adow-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-msec-gkmarch-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. > > >> > > >> > ------------------------------------------------------------------------ > > >>Content-Type: text/plain > > >>Content-ID: <20010626132202.I-D@ietf.org>