From owner-ipsec@lists.tislabs.com Thu May 1 03:53:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Armi2051367; Thu, 1 May 2003 03:53:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13636 Thu, 1 May 2003 06:11:49 -0400 (EDT) Message-ID: <3EB0F42D.F1E18B51@enst.fr> Date: Thu, 01 May 2003 12:17:17 +0200 From: Ibrahim X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: mbaugher@cisco.com, kent@bbn.com, ekr@rtfm.com, bew@cisco.com, mcr@sandelman.ottawa.on.ca Subject: Re: ISAKMP and SSL References: <3EB00CC9.333D63EF@enst.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME, SKIP…) even in SSH are based on Diffie-Hellman. This can be an additional reason to this issue if we saw that we develop the same key management protocols but every time with a little bit change. what i want to say is why every security protocol should propose his own key management schemes if we can unify all this work? I think the first ISAKMP proposition was in this road. In addition, 1 – about identity protection new service. I am not convinced with (a) + (b) solution for SSL. Identity protection can also be the mask of a number of people using the same IP address. Id. Prot. can be used when one host has multiple identities and wishes to mask who is behind a specific handshake. (even with different X509 Cert.). 2 - Modularity of SSL Protocol. SSL is a module security protocol. Any ISAKMP integration requires changing only the Handshake part. 3 – TLS extension proposes to extend the work of TLS protocol in new environment (..) and to add some new mechanism in authentication (Sending URL certificate, authentication with attribute …) All these mechanisms are even implemented in ISAKMP or can be quickly done. For ISAKMP the new environment can be multi-cast diffusion, MAP protocol for UMTS... 4 - Interoperability between different security protocols. Several security protocols could share the same key management code. This simplifies migration from one protocol to another and reduces the amount of duplicated functionality within each security protocol. Ibrahim Eric Rescorla wrote: > > When I read RFC 2408 they described ISAKMP as a generic key management > > protocol for all security protocols but till now the large deployment of > > ISAKMP was only with IPSEC > > My question is, can we use it with SSL/TLS? > > The goal of this issue is to add new services in SSL/TLS (identity > > protection, attribute certificate passing for access control schemes, > > non-repudiation…). > > The basic answer here is no. > > TLS has its own key management scheme and really isn't designed > to have pluggable key management. That said, with respect to your > specific desired security services: > > (1) You can get identity protection for TLS in a number of ways, > none quite as good as you would get with IPsec. > > (a) do an initial anonymous DH exchange and then do the > ordinary handshake. This still allows an active attacker > to get both identities. > > (b) do an initial cert-based exchange (this exposes the > server's identity) and then rehandshake to have the > client identify. > > (c) combine the above two techniques :) > > (2) TLS has an extensions mechanism so you could use that to > pass around attribute certificates. > > (3) ISAKMP doesn't really offer non-repudiation either, so you > wouldn't get any benefit from melding it with TLS. > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > Web Log: http://www.rtfm.com/movabletype -- ____________________________________________________ Ibrahim HAJJEH Ecole Nationale Supérieure des Télécommunications Departement Informatique et Réseaux Tél.:+33 01 45 81 71 06 Fax.: +33 01 45 81 31 19 46 rue Barrault, 75634 PARIS cedex 13 From owner-ipsec@lists.tislabs.com Thu May 1 06:41:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41DfTi2061047; Thu, 1 May 2003 06:41:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13939 Thu, 1 May 2003 08:59:22 -0400 (EDT) Message-ID: <001701c30fe2$28439890$0c23c08c@cti.depaul.edu> From: "Salah Aly" To: "Ibrahim" , References: <3EB00CC9.333D63EF@enst.fr> <3EB0F42D.F1E18B51@enst.fr> Subject: Re: ISAKMP and SSL Date: Thu, 1 May 2003 08:04:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi all, > Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME, SKIP.) > even in SSH are based on Diffie-Hellman. I do not think your statement is correct, not all of the key management protocols depend on Deffie-Hellman.. for example, Shamir's Secret Sharing is a way to manage and distribute the key, it depends on polynomial interpolations... > This can be an additional reason to this issue if we saw that we develop the > same key management protocols but every time with a little bit change. > what i want to say is why every security protocol should propose his own key > management schemes if we can unify all this work? I think the first ISAKMP > proposition was in this road. > > In addition, > > 1 - about identity protection new service. I am not convinced with (a) + > (b) solution for SSL. Identity protection can also be the mask of a > number of people using the same IP address. Id. Prot. can be > used when one host has multiple identities and wishes to mask who is > behind a specific handshake. (even with different X509 Cert.). > > 2 - Modularity of SSL Protocol. > SSL is a module security protocol. Any ISAKMP integration requires > changing only the Handshake part. > > 3 - TLS extension proposes to extend the work of TLS protocol in new > environment (..) and to add some new mechanism in authentication > (Sending URL certificate, authentication with attribute .) All these > mechanisms are even implemented in ISAKMP or can be quickly done. For > ISAKMP the new environment can be multi-cast diffusion, MAP protocol for > UMTS... > > 4 - Interoperability between different security protocols. > Several security protocols could share the same key management code. > This simplifies migration from one protocol to another and reduces the > amount of duplicated functionality within each security protocol. > > Ibrahim > > > Eric Rescorla wrote: > > > > When I read RFC 2408 they described ISAKMP as a generic key management > > > protocol for all security protocols but till now the large deployment of > > > ISAKMP was only with IPSEC > > > My question is, can we use it with SSL/TLS? > > > The goal of this issue is to add new services in SSL/TLS (identity > > > protection, attribute certificate passing for access control schemes, > > > non-repudiation.). > > > > The basic answer here is no. > > > > TLS has its own key management scheme and really isn't designed > > to have pluggable key management. That said, with respect to your > > specific desired security services: > > > > (1) You can get identity protection for TLS in a number of ways, > > none quite as good as you would get with IPsec. > > > > (a) do an initial anonymous DH exchange and then do the > > ordinary handshake. This still allows an active attacker > > to get both identities. > > > > (b) do an initial cert-based exchange (this exposes the > > server's identity) and then rehandshake to have the > > client identify. > > > > (c) combine the above two techniques :) > > > > (2) TLS has an extensions mechanism so you could use that to > > pass around attribute certificates. > > > > (3) ISAKMP doesn't really offer non-repudiation either, so you > > wouldn't get any benefit from melding it with TLS. > > > > -Ekr > > > > -- > > [Eric Rescorla ekr@rtfm.com] > > Web Log: http://www.rtfm.com/movabletype > > -- > ____________________________________________________ > Ibrahim HAJJEH > Ecole Nationale Supérieure des Télécommunications > Departement Informatique et Réseaux > Tél.:+33 01 45 81 71 06 Fax.: +33 01 45 81 31 19 > 46 rue Barrault, 75634 PARIS cedex 13 > > > From owner-ipsec@lists.tislabs.com Thu May 1 06:41:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41DfXi2061048; Thu, 1 May 2003 06:41:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13953 Thu, 1 May 2003 09:06:16 -0400 (EDT) Message-ID: <006f01c30fdd$b02dda90$010aa8c0@joe> From: "Hannes Tschofenig" To: References: Subject: EAP Handling in IKEv2 Date: Thu, 1 May 2003 14:32:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, in Section 2.16 you mention the mechanism for protecting against man-in-the-middle attacks: " For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the Initiator and Responder to generate an AUTH payload using the syntax for shared secrets specified in section 2.15. This shared key MUST NOT be used for any other purpose. " This covers the case where the EAP method establishes a session key. Which procedure do you suggest for cases where EAP methods do not create a session key such as the One-Time Password (OTP)? Ciao Hannes From owner-ipsec@lists.tislabs.com Thu May 1 06:52:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41DqUi2061260; Thu, 1 May 2003 06:52:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13974 Thu, 1 May 2003 09:17:40 -0400 (EDT) To: Ibrahim Cc: ipsec@lists.tislabs.com, mbaugher@cisco.com, kent@bbn.com, bew@cisco.com, mcr@sandelman.ottawa.on.ca Subject: Re: ISAKMP and SSL References: <3EB00CC9.333D63EF@enst.fr> <3EB0F42D.F1E18B51@enst.fr> Reply-To: EKR From: Eric Rescorla Date: 01 May 2003 06:27:52 -0700 In-Reply-To: <3EB0F42D.F1E18B51@enst.fr> Message-ID: Lines: 48 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ibrahim writes: > Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME, SKIP…) > even in SSH are based on Diffie-Hellman. > This can be an additional reason to this issue if we saw that we develop the > same key management protocols but every time with a little bit change. > what i want to say is why every security protocol should propose his own key > management schemes if we can unify all this work? I think the first ISAKMP > proposition was in this road. That's reasonable sounding. I'm just telling you that it's not practical to retrofit it to TLS. > 1 – about identity protection new service. I am not convinced with (a) + > (b) solution for SSL. Identity protection can also be the mask of a > number of people using the same IP address. Id. Prot. can be > used when one host has multiple identities and wishes to mask who is > behind a specific handshake. (even with different X509 Cert.). I don't understand what point you're trying to make here. > 2 - Modularity of SSL Protocol. > SSL is a module security protocol. Any ISAKMP integration requires > changing only the Handshake part. In theory perhaps. In practice the TLS key management and record protocol are relatively tightly coupled. Moreover, like 75% of the TLS code is key management so it's not clear why you'd want to gut it, shove in ISAKMP, but retain the record layer. > 3 – TLS extension proposes to extend the work of TLS protocol in new > environment (..) and to add some new mechanism in authentication > (Sending URL certificate, authentication with attribute …) All these > mechanisms are even implemented in ISAKMP or can be quickly done. For > ISAKMP the new environment can be multi-cast diffusion, MAP protocol for > UMTS... I don't understand what point you're trying to make here. I don't deny that you can obtain the requested security services using some mechanism other than TLS, but the probability of TLS incorporating ISAKMP key management is approximately zero. Therefore, if you want to use TLS and you want these services, you need to start thinking about a different approach. > 4 - Interoperability between different security protocols. > Several security protocols could share the same key management code. > This simplifies migration from one protocol to another and reduces the > amount of duplicated functionality within each security protocol. Yes, that's fine, but we live in a world where TLS code is already very widely deployed, so creating a new TLS/ISAKMP hybrid is going to introduce complication, not reduce it. -Ekr From owner-ipsec@lists.tislabs.com Thu May 1 08:28:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41FS5i2067540; Thu, 1 May 2003 08:28:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14238 Thu, 1 May 2003 10:33:02 -0400 (EDT) Importance: Normal Subject: Re: Confirm decision on identity handling. To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000 Message-ID: From: David Wierbowski Date: Thu, 1 May 2003 10:37:30 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V602_04202003|April 20, 2003) at 05/01/2003 10:37:31 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> >> Hi Scott, >> >> The verification/authentication is the cert. I >> haven't proposed removing the authentication, so >> I'm not sure why you say there's no defined >> verification mechanism. > >I'm saying this because the proposed language says the ID payload does >not have to match anything in the cert. If we allow this and you choose >your policy based on the ID payload, I may be able to misdirect you to >the "wrong" policy by simply enclosing the "right" ID payload. I agree. This seems like an obvious flaw. If the ID is not required to match the identity in the cert there does not seem to be a defined verification mechanism. From owner-ipsec@lists.tislabs.com Thu May 1 09:42:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Gg0i2070347; Thu, 1 May 2003 09:42:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14538 Thu, 1 May 2003 12:07:35 -0400 (EDT) Message-ID: <3EB146DD.AB9E3A6A@airespace.com> Date: Thu, 01 May 2003 09:10:05 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2003 16:12:05.0825 (UTC) FILETIME=[68A3DB10:01C30FFC] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Andrew, Can you give a real-world example of the process you describe below? That is, what sort of ID payload would be sent, what might it contain, and how would the policies look against which this compared? Thanks, Scott Andrew Krywaniuk wrote: > > >And what is the point of this? It seems to make the policy lookup > >slightly simpler, since you can get the ID payload from the packet > >instead of parsing the cert. But this is only on the front end, because > >you still have to parse the cert, and you have the added step of > >verifying that the ID matches something in the cert (if you care about > >security). > > Some people have been referring to the id as a "key for policy lookup". The > idea is that if you have a decorrelated database (or an ordered database > where more specific rules serve only to grant privileges and not to take > them away), a unique id can allow a very fast policy lookup. > > However, once this lookup is complete, you can throw the id away. It is not > necessary to check the id against a field in the certificate. You only have > to check the certificate against the policy (and the signature against the > public key and the validity of the cert chain). > > I wish people would stop saying thing like "you can check the id against the > certificate if you require a more stringent policy check." > > Andrew > -------------------------------------- > The odd thing about fairness is when > we strive so hard to be equitable > that we forget to be correct. > > _________________________________________________________________ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Thu May 1 09:42:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Ggui2070378; Thu, 1 May 2003 09:42:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14471 Thu, 1 May 2003 11:52:33 -0400 (EDT) Message-Id: <5.1.1.5.2.20030501084954.0489be48@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 01 May 2003 08:56:35 -0700 To: Ibrahim From: Mark Baugher Subject: Re: ISAKMP and SSL Cc: ipsec@lists.tislabs.com In-Reply-To: <3EB0F42D.F1E18B51@enst.fr> References: <3EB00CC9.333D63EF@enst.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA14468 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi Ibrahim, In addition to some of the advantages that you cite, another claimed benefit of the ISAKMP approach is increased security by having a single key establishment entity on the computer rather than several. Although some of us "drank that kool aid," I think that this is not the current direction of IPsec (there are some good arguments against it, notably complexity) and the matter is probably of little interest to most people on this list. At least that's my impression of the way things stand. Best regards, Mark At 12:17 PM 5/1/2003 +0200, Ibrahim wrote: >Hi all, >Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME, SKIP…) >even in SSH are based on Diffie-Hellman. >This can be an additional reason to this issue if we saw that we develop the >same key management protocols but every time with a little bit change. >what i want to say is why every security protocol should propose his own key >management schemes if we can unify all this work? I think the first ISAKMP >proposition was in this road. > > In addition, > >1 ­ about identity protection new service. I am not convinced with (a) + >(b) solution for SSL. Identity protection can also be the mask of a >number of people using the same IP address. Id. Prot. can be >used when one host has multiple identities and wishes to mask who is >behind a specific handshake. (even with different X509 Cert.). > >2 - Modularity of SSL Protocol. >SSL is a module security protocol. Any ISAKMP integration requires >changing only the Handshake part. > >3 ­ TLS extension proposes to extend the work of TLS protocol in new >environment (..) and to add some new mechanism in authentication >(Sending URL certificate, authentication with attribute …) All these >mechanisms are even implemented in ISAKMP or can be quickly done. For >ISAKMP the new environment can be multi-cast diffusion, MAP protocol for >UMTS... > >4 - Interoperability between different security protocols. >Several security protocols could share the same key management code. >This simplifies migration from one protocol to another and reduces the >amount of duplicated functionality within each security protocol. > >Ibrahim > > >Eric Rescorla wrote: > > > > When I read RFC 2408 they described ISAKMP as a generic key management > > > protocol for all security protocols but till now the large deployment of > > > ISAKMP was only with IPSEC > > > My question is, can we use it with SSL/TLS? > > > The goal of this issue is to add new services in SSL/TLS (identity > > > protection, attribute certificate passing for access control schemes, > > > non-repudiation…). > > > > The basic answer here is no. > > > > TLS has its own key management scheme and really isn't designed > > to have pluggable key management. That said, with respect to your > > specific desired security services: > > > > (1) You can get identity protection for TLS in a number of ways, > > none quite as good as you would get with IPsec. > > > > (a) do an initial anonymous DH exchange and then do the > > ordinary handshake. This still allows an active attacker > > to get both identities. > > > > (b) do an initial cert-based exchange (this exposes the > > server's identity) and then rehandshake to have the > > client identify. > > > > (c) combine the above two techniques :) > > > > (2) TLS has an extensions mechanism so you could use that to > > pass around attribute certificates. > > > > (3) ISAKMP doesn't really offer non-repudiation either, so you > > wouldn't get any benefit from melding it with TLS. > > > > -Ekr > > > > -- > > [Eric Rescorla ekr@rtfm.com] > > Web Log: http://www.rtfm.com/movabletype > >-- >____________________________________________________ >Ibrahim HAJJEH >Ecole Nationale Supérieure des Télécommunications >Departement Informatique et Réseaux >Tél.:+33 01 45 81 71 06 Fax.: +33 01 45 81 31 19 >46 rue Barrault, 75634 PARIS cedex 13 From owner-ipsec@lists.tislabs.com Thu May 1 09:57:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Gv2i2070685; Thu, 1 May 2003 09:57:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14523 Thu, 1 May 2003 12:02:48 -0400 (EDT) Message-Id: <200305011607.h41G7Dof031438@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mark Siler" cc: ipsec@lists.tislabs.com Subject: Re: IPSec Passthrough In-reply-to: Your message of Wed, 30 Apr 2003 10:07:43 CDT. <1772A2E865ABD411B18900508BB1B88F05ED7D8C@SVARLEXC07> Date: Thu, 01 May 2003 18:07:13 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I'm curious on how IPSec passthrough works. I know AH prevents a traditional NAT from occurring, but how do the SOHO routers (Linksys, D-Link, Ascend, etc) accomplish the IPSec passthrough? => I know at least one of the cited SOHO routers which just puts on the "other side" any packet with an "unknown" protocol when the IPsec passthrough is enabled (i.e., it behaves like a bridge). It is a bit surprising but convenient for my usage (IPv6 over IPv4 passthrough). But some others seem to be "smart", i.e., they believe they know IPsec and try to do "clever" things, for instance they try to support many IPsec "clients", including of the same VPN. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu May 1 11:02:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41I2Ui2073321; Thu, 1 May 2003 11:02:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14911 Thu, 1 May 2003 13:27:11 -0400 (EDT) From: jknowles@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Confirm decision on identity handling. Date: Thu, 1 May 2003 10:32:04 -0700 Message-ID: <385918F84B55DC4E9542E0A4812F413106E2A3@us0exb01.us.sonicwall.com> Thread-Topic: Confirm decision on identity handling. Thread-Index: AcMPeTeAwKDAg9ZBSAqfCAZwc6OUGwAg/Wzw To: Cc: , , X-OriginalArrivalTime: 01 May 2003 17:32:05.0118 (UTC) FILETIME=[953DD9E0:01C31007] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA14908 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, > -----Original Message----- < snip> > > The verification/authentication is the cert. I > > haven't proposed removing the authentication, so > > I'm not sure why you say there's no defined > > verification mechanism. > > I'm saying this because the proposed language says the ID payload does > not have to match anything in the cert. If we allow this and > you choose > your policy based on the ID payload, I may be able to misdirect you to > the "wrong" policy by simply enclosing the "right" ID payload. Sure, but you've authenticated to me via the AUTH payload, so the ID is verified. It is not directly verified by the issuer of the cert, true. But, people seem to want be able to allow this case (ID explicitly de-coupled from the cert). > > > You had earlier proposed > > omitting the ID payload and just using the cert as > > policy selector. Which identity in the cert would > > you use? That's local policy as well. > > This is precisely my point: since it's the responder's decision, and > since there are multiple choices and combinations, how can > the initiator > reliably know what to put in the ID payload? Through configuration the sender can know what to put in the ID payload. Or, send the proposed "ID_CERT" payload. > And supposing > the responder > tells the intiator in advance, what is the responder to do if the ID > payload is the "wrong" one? If the configuration allows an authenticated ID to select the wrong policy, then fix the configuration. That could include requiring the match as a local policy decision so that misconfiguration results in SA failure. > It only works if the responder > verifies the > ID payload against the credential, and in this case, there is nothing > saved by using the separate payload, rather than simply extracting it > from the cert. In some cases, the ID payload can be useful. Here's one case: early rejection of wrong ID configuration before cert processing. It the ID is wrong, I don't need to authenticate it to know that. I can simply reject it. If the ID is right, I do need to authenticate so, in that case, you're correct, nothing is saved. > > > You may > > authenticate the cert and still reject the identity > > based on your policy. You've eliminated the > > requirement for configuring which ID payload > > to send. That's fine - less headaches although > > you still need to configure which cert to send. > > At least there's no ID payload/cert impedence > > mismatch. But, I don't see any security issue > > with allowing an ID payload. > > The security issues arise if you decouple the ID payload from > the cert, > i.e. when the ID payload is no longer a reliable policy selector. If you say "configuration issues", I agree. And, yes, misconfiguration can lead to bad security. I understand your position that we should remove points of possible misconfiguration as a security concern. > It sounds like your client is putting something that can be verified > against the cert into the ID payload. So long as you verify > this against > the cert, this is probably okay, though as I said in an earlier post, > there really is no computational benefit to this, and I think it > actually may complicate the processing. We disagree about the computational benefit, at least in some cases. The complication is minor and worth the benefit, IMHO. > The main point, > though, is that > your implementation appears to verify the ID payload against > the cert - > the proposed language I'm disgreeing with says this is not required. Not required, not prevented. And I still get the ID payload. If others agree with you, that the security risk arising from having a misconfigured ID payload is too great for us to allow this in the spec (ID payload when there is a CERT payload), fine. I can live with that. > > Scott > Regards, Jim From owner-ipsec@lists.tislabs.com Thu May 1 11:02:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41I2ji2073357; Thu, 1 May 2003 11:02:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14880 Thu, 1 May 2003 13:23:39 -0400 (EDT) Message-ID: <3EB15959.AE510A0A@enst.fr> Date: Thu, 01 May 2003 19:28:57 +0200 From: Ibrahim X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: EKR , mbaugher@cisco.com, kent@bbn.com, bew@cisco.com, mcr@sandelman.ottawa.on.ca Subject: Re: ISAKMP and SSL References: <3EB00CC9.333D63EF@enst.fr> <3EB0F42D.F1E18B51@enst.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, I totally agree with you The idea of extending the work of ISAKMP to other security protocols began in 1996 by Cisco corp. J. Smith has also talk about it in the ietf-tls mailing list. But i think that the work and effort involved in this WG during all last period in defining a robust key exchange mechanism should be used and gained in other WG. Centralizing ISAKMP usage to IPsec (IKEv2) remove all the advantage of this “generic” key exchange protocol. We should not forget that ISAKMP was designed as an application layer protocol so normally it benefit of all the advantage of this layer and can especially establish a secure connection for all network security protocols so why we don’t try to implement it outside IPsec? Eric Rescorla wrote: > Ibrahim writes: > > > 1 – about identity protection new service. I am not convinced with (a) + > > (b) solution for SSL. Identity protection can also be the mask of a > > number of people using the same IP address. Id. Prot. can be > > used when one host has multiple identities and wishes to mask who is > > behind a specific handshake. (even with different X509 Cert.). > I don't understand what point you're trying to make here. You should read the proposed TLS extension draft about authenticating TLS server that host multiple virtual servers. > > > 2 - Modularity of SSL Protocol. > > SSL is a module security protocol. Any ISAKMP integration requires > > changing only the Handshake part. > In theory perhaps. In practice the TLS key management and record protocol > are relatively tightly coupled. Moreover, like 75% of the TLS code > is key management so it's not clear why you'd want to gut it, > shove in ISAKMP, but retain the record layer. > > > 3 – TLS extension proposes to extend the work of TLS protocol in new > > environment (..) and to add some new mechanism in authentication > > (Sending URL certificate, authentication with attribute …) All these > > mechanisms are even implemented in ISAKMP or can be quickly done. For > > ISAKMP the new environment can be multi-cast diffusion, MAP protocol for > > UMTS... > I don't understand what point you're trying to make here. I > don't deny that you can obtain the requested security services > using some mechanism other than TLS, but the probability of > TLS incorporating ISAKMP key management is approximately zero. > Therefore, if you want to use TLS and you want these services, > you need to start thinking about a different approach. Sure, SSL will not offer these services but ISAKMP can. > > > 4 - Interoperability between different security protocols. > > Several security protocols could share the same key management code. > > This simplifies migration from one protocol to another and reduces the > > amount of duplicated functionality within each security protocol. > Yes, that's fine, but we live in a world where TLS code > is already very widely deployed, so creating a new TLS/ISAKMP hybrid > is going to introduce complication, not reduce it. > I know that SSL is the most deployed security protocol but this is only due to his native integration in web server, client browsers and because 80% of the SSL usage is with HTTP. Adapting SSL for new services, the deployment of IPv6 arch., IKEv2 design can also introduce complication. Ibrahim ____________________________________________________ Ibrahim HAJJEH Ecole Nationale Supérieure des Télécommunications Departement Informatique et Réseaux Tél.:+33 01 45 81 71 06 Fax.: +33 01 45 81 31 19 46 rue Barrault, 75634 PARIS cedex 13 From owner-ipsec@lists.tislabs.com Thu May 1 11:04:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41I4Wi2073523; Thu, 1 May 2003 11:04:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14931 Thu, 1 May 2003 13:30:47 -0400 (EDT) To: Ibrahim Cc: ipsec@lists.tislabs.com, mbaugher@cisco.com, kent@bbn.com, bew@cisco.com, mcr@sandelman.ottawa.on.ca Subject: Re: ISAKMP and SSL References: <3EB00CC9.333D63EF@enst.fr> <3EB0F42D.F1E18B51@enst.fr> <3EB15959.AE510A0A@enst.fr> Reply-To: EKR From: Eric Rescorla Date: 01 May 2003 10:41:03 -0700 In-Reply-To: <3EB15959.AE510A0A@enst.fr> Message-ID: Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ibrahim writes: > Eric Rescorla wrote: > > > Ibrahim writes: > > > > > 1 – about identity protection new service. I am not convinced with (a) + > > > (b) solution for SSL. Identity protection can also be the mask of a > > > number of people using the same IP address. Id. Prot. can be > > > used when one host has multiple identities and wishes to mask who is > > > behind a specific handshake. (even with different X509 Cert.). > > I don't understand what point you're trying to make here. > > You should read the proposed TLS extension draft about authenticating > TLS server that host multiple virtual servers. Ibrahim, I'm the editor of the main TLS document. I've read the extensions draft times. I still don't understand what point you're trying to make here about identity protection. > > I don't understand what point you're trying to make here. I > > don't deny that you can obtain the requested security services > > using some mechanism other than TLS, but the probability of > > TLS incorporating ISAKMP key management is approximately zero. > > Therefore, if you want to use TLS and you want these services, > > you need to start thinking about a different approach. > > Sure, SSL will not offer these services but ISAKMP can. Right, but since noone is going to use ISAKMP with SSL, if you want these features in the context of SSL you have to think about how to add them to SSL. > > > 4 - Interoperability between different security protocols. > > > Several security protocols could share the same key management code. > > > This simplifies migration from one protocol to another and reduces the > > > amount of duplicated functionality within each security protocol. > > Yes, that's fine, but we live in a world where TLS code > > is already very widely deployed, so creating a new TLS/ISAKMP hybrid > > is going to introduce complication, not reduce it. > > > > I know that SSL is the most deployed security protocol but this is only > due to his native integration in web server, client browsers and because > 80% of the SSL usage is with HTTP. Adapting SSL for new services, the > deployment of IPv6 arch., IKEv2 design can also introduce complication. TLS has been quite robust when applied to new application layer protocols, actually. Very little has had to be done (the virtual servers stuff being the notable exception) IPv6 architecture and IKEv2 design have nothing to do with TLS because TLS sits at a different layer of the stack. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu May 1 11:04:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41I4ji2073538; Thu, 1 May 2003 11:04:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14748 Thu, 1 May 2003 13:01:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v568.1) In-Reply-To: <1051769403.1131.40.camel@lima.royalchallenge.com> References: <1772A2E865ABD411B18900508BB1B88F05ED7D8C@SVARLEXC07> <1051769403.1131.40.camel@lima.royalchallenge.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <29664595-7BF7-11D7-96C9-000A959D832C@apple.com> Content-Transfer-Encoding: 7bit From: Joshua Graessley Subject: Re: IPSec Passthrough Date: Thu, 1 May 2003 10:05:51 -0700 To: ipsec@lists.tislabs.com X-Mailer: Apple Mail (2.568.1) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday, April 30, 2003, at 23:10, Vinay K Nallamothu wrote: > On Wed, 2003-04-30 at 20:37, Mark Siler wrote: >> I'm curious on how IPSec passthrough works. I know AH prevents a >> traditional NAT from occurring, but how do the SOHO routers (Linksys, >> D-Link, Ascend, etc) accomplish the IPSec passthrough? > > These devices track the IPsec connections by looking at the SPI in > IKE/ESP headers. > > When they first see the IKE packets from the client behind the NAT they > note down the SPI value, client address and then masquarade the packet > as usual with its own IP. > > When they see the packets from the remote IPsec peer, it looks into the > table using SPI and replaces the destination with client's IP. > > This mechanism works only with ESP and not with AH which is fine as > most > of the road warriors connect to IPsec gateways. > > You can get more details about this in sections 9.0 to 9.3 of > draft-ietf-ipsec-ikev2-tutorial-01.txt. The SPI for traffic in each direction will be different. As a result, the NAT will not know which node to send incoming packets to. Most NATs will only support IPSec NAT Transparency for one node behind the NAT. The remote IP address can be used as a selector to support multiple devices behind one NAT as long as they all communicate with different remote hosts. >> Do they >> encapsulate the entire IPSec packet from the client? > No > >> I keep reading >> about a Transparent Mode and Tunnel Mode, > For NAT-T unware IPsec peers, the above mentioned mechanism is not > visible and hence called transparent. Further this works only when the > client behind the NAT is a road warrior. There are two "modes" that IPSec operates in, tunnel mode and transport mode. This is, in my opinion, a little bogus because "tunnel mode" is really just transport mode where the next header is an IP header instead of UDP, TCP, ICMP or some other protocol. Anyhow, the NAT transparency only works with Tunnel mode (where the next header after the ESP header is IP). In transport mode, the TCP and UDP checksums will be screwed up. ESP encrypts and authenticates the payload so the NAT can't molest it. The UDP and TCP checksums take bits of the IP header in to account, most notably the source and destination IP addresses. The NAT modifies the destination IP address. Since it can't see or modify the TCP or UDP checksum to compensate for the address change, TCP and UDP packets will be dropped due to a bad checksum. -josh From owner-ipsec@lists.tislabs.com Thu May 1 12:14:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JE1i2076668; Thu, 1 May 2003 12:14:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15206 Thu, 1 May 2003 14:31:35 -0400 (EDT) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899B0105F21A@01MAIL> To: vinay-rc@naturesoft.net, msiler@hcin.net Cc: ipsec@lists.tislabs.com Date: Thu, 1 May 2003 11:14:55 -0700 Subject: RE: IPSec Passthrough MIME-Version: 1.0 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually since the SPI values are different in the 2 directions, these devices first try to associate the incoming and outgoing SPIs by preventing further new connections to the same IPSec server from clients behind the NAT device till they see atleast one incoming packet containing the SPI from the server. Once that association is made, the connection information is considered complete and they allow other clients to connect to the same server. It is dependent on the server implementation to distinguish 2 different connections coming from the same IP address (of the NAT device) and is not a very reliable method of doing things.. Regards -Bik -----Original Message----- From: Vinay K Nallamothu [mailto:vinay-rc@naturesoft.net] Sent: Wednesday, April 30, 2003 11:10 PM To: Mark Siler Cc: ipsec@lists.tislabs.com Subject: Re: IPSec Passthrough On Wed, 2003-04-30 at 20:37, Mark Siler wrote: > I'm curious on how IPSec passthrough works. I know AH prevents a > traditional NAT from occurring, but how do the SOHO routers (Linksys, > D-Link, Ascend, etc) accomplish the IPSec passthrough? These devices track the IPsec connections by looking at the SPI in IKE/ESP headers. When they first see the IKE packets from the client behind the NAT they note down the SPI value, client address and then masquarade the packet as usual with its own IP. When they see the packets from the remote IPsec peer, it looks into the table using SPI and replaces the destination with client's IP. This mechanism works only with ESP and not with AH which is fine as most of the road warriors connect to IPsec gateways. You can get more details about this in sections 9.0 to 9.3 of draft-ietf-ipsec-ikev2-tutorial-01.txt. > Do they > encapsulate the entire IPSec packet from the client? No > I keep reading > about a Transparent Mode and Tunnel Mode, For NAT-T unware IPsec peers, the above mentioned mechanism is not visible and hence called transparent. Further this works only when the client behind the NAT is a road warrior. vinay From owner-ipsec@lists.tislabs.com Thu May 1 14:36:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Lavi2081105; Thu, 1 May 2003 14:36:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15650 Thu, 1 May 2003 17:04:22 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Protocol ID Field To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Thu, 1 May 2003 17:07:30 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/01/2003 05:09:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is a field called "Protocol ID", which I intended to leave unchanged from IKEv1 in the SA, Notify, and Delete payloads. But I initially misread IKEv1 and then fixed it incorrectly. It is now inconsistently specified in the spec and I'd like to fix it. I assume this will be non-controversial, but don't want to make any non-obvious changes at this point without warning. Protocol ID is a one byte field that indicates whether we're talking about an IKE SA, an ESP SA, an AH SA, or an IPcomp SA (though in IKEv2 this code is never used). I originally believed that the values came from the Protocol ID IP header field (50 for ESP, 51 for AH, and 108 for IPcomp), with the special value zero used for the IKE SA. But IKEv1 actually took values from a different IANA registry "Security Protocol" with assigned values: 1 for ISAKMP, 2 for AH, 3 for ESP, 4 for IPcomp. When I switched back from suites to a la carte crypto negotiation (where this field figure prominently in the SA payload), I changed the codes but made two mistakes. I left the field name as Protocol ID, making it easily confused with the field called Protocol ID in the traffic selector field. In the traffic selector, the Protocol ID field does take its values from the IP header, most commonly using the codes for TCP and UDP. More dramatically, I used values different from the ones in the existing IANA registry (0 for IKE, 1 for ESP, and 2 for AH). Someone pointed these errors out to me in private email, and I tried to fix it in -07, changing the field name to Security Protocol ID and the values to match those in IKEv1. But I apparently missed some places. In particular, in the Proposal structure, it still has the old name and old values. I'd like to complete the fix by making the numbers and name in the proposal structure match the values elsewhere. Any objections? --Charlie p.s. A subtlety is that in the IANA registry, the value 1 is for "ISAKMP", while I am using the value 1 for "IKE". I believe the IKE is a protocol while ISAKMP is a syntax and that it therefore makes more sense to call the value IKE. But if anyone believes otherwise, and perhaps believes we should assign a new code for IKE, now would be a good time to speak up. From owner-ipsec@lists.tislabs.com Thu May 1 15:56:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Mu8i2083588; Thu, 1 May 2003 15:56:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15958 Thu, 1 May 2003 18:27:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66CD7@SARATOGA.netscreen.com> References: <541402FFDC56DA499E7E13329ABFEA87E66CD7@SARATOGA.netscreen.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 1 May 2003 14:05:37 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Requirements for IKEv2 implementations Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:20 PM -0700 4/29/03, Gregory Lebovitz wrote: >MY WG and Security Area member perspective: >Certificates are good security and we should try as much as we can to help >implementations adopt them. That's what SHOULD is for. The current text says MUST. > Any worthwhile IKEv1 implementation today can >handle certs. Sorry, but that is just plain wrong. There are many "worthwhile" implementations that don't do certs. There are plenty of "worthwhile" implementations that do certs wrong, such as doing things with certs that the IKEv1 specs say they SHOULD NOT do. >Market observer perspective: >PKI has been a royal pain for many interested in IPsec VPNs. Just ask the >PKI vendors. They have abandoned the application as a focus for their >development, marketing and sales. At an absolute minimum, PSS is a MUST. Exactly right. But there is no reason for two MUSTs for authentication. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 1 15:57:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41MvUi2083818; Thu, 1 May 2003 15:57:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15951 Thu, 1 May 2003 18:25:18 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: Requirements for IKEv2 implementations To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Thu, 1 May 2003 18:09:34 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/01/2003 06:30:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Greetings again. The -05 draft of IKEv2 introduced the following requirements: > > For an implementation to be called conforming to this specification, > it MUST be possible to configure it to accept the following: > > PKIX Certificates containing and signed by RSA keys of size 1024 or > 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, > ID_RFC822_ADDR, or ID_DER_ASN1_DN. > > Shared key authentication where the ID passes is any of ID_KEY_ID, > ID_FQDN, or ID_RFC822_ADDR. > > Authentication where the responder authenticates using PKIX > Certificates and the initiator authenticates using shared key > authentication. > > I don't remember seeing this discussed in the WG before now. There was a long though indecisive discussion of RSA vs DSS keys and required key sizes about six months ago. I don't believe the other issues have been discussed. I believe there has been expressed a consensus for for following very ambitious goal: it must be possible to configure any two implementations that conform to the RFC to interoperate. I have been adding conformance requirements as people point out places where the spec allows two implementations that include all of the MUSTs to fail to interoperate. I'm sure we will find more in interoperability testing, but we should find only bugs in implementations and bugs in the spec. Not legitimately differing interpretations. There will certainly be cases where the goal will not be met. There are asymmetric cases where a laptop designed to connect to a corporate firewall may not have a smarts to accept a connection from a similarly configured laptop. And the "can be configured" language is critical. Deployments are likely to restrict what forms of authentication they accept and what algorithms they use. So in some sense, requiring configurability doesn't guarantee anything. But in practice, I believe it will make a big difference. > There are many reasons why an implementation might not want to > support PKIX certificates, including the fact that many vendors find > that PKIX is too complicated to support securely. In some security > environments, other forms of public key infrastructures are more > appropriate for some security uses. And, of course, for systems that > have the ability to create and distribute good shared secrets, PKIX > support is just dangerous bloat. > > The minimum that is needed for interoperability is shared secrets. > The document already has requirements for handling large shared > secrets, so we don't need to worry about limitations that reduce to > passwords. Requiring both shared secrets *and* PKIX-specific public > key support does not help interoperability, and because of the nature > of PKIX, hurts it significantly. We only need to mandate one or the > other, and given the ugly reality of PKIX, it should only be > sufficiently long shared secrets. I have no particular preference here. In the early days of IKEv2, there was no shared key authentication, so certificate based authentication was a MUST. At first, shared key authentication was optional, but I was convinced that because of its wide deployment in IKEv1, it also should be a MUST. I think it would be fairly harmless to make authentication using raw RSA keys also be a MUST, but no one made a case for it until now. I think it would be a mistake to remove the requirement for certificate based authentication, because it is hard, people would be tempted to leave it out, and I believe that's where we want to end up in the long run. But it's not my decision... what do people want? I would have expected the issue of ID types to be more controversial. I added the language last year attempting to respond to the issues raised by your Revised Identity proposals. > PKIX Certificates containing and signed by RSA keys of size 1024 or > 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, > ID_RFC822_ADDR, or ID_DER_ASN1_DN. As currently written, a node may identify itself by any of those four ID types, and the other end MUST be capable of accepting any of them and using them to find a policy (again, must be capable of being configured to accept any of them). If this set were smaller, it would make life easier for the parsers but less flexible in terms of allowed configurations. --Charlie From owner-ipsec@lists.tislabs.com Thu May 1 16:19:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41NJbi2084535; Thu, 1 May 2003 16:19:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16061 Thu, 1 May 2003 18:52:33 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: Crypto algorithms for IKEv2 To: "Andrew Krywaniuk" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Thu, 1 May 2003 18:55:40 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/01/2003 06:57:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Come to think of it, I don't think we ever resolved the issue of what to do > when the initiator of a CREATE_CHILD_SA exchange doesn't propose PFS but the > responder requires it. This could be accomplished with a > NOTIFY_PFS_REQUIRED_ALWAYS or NOTIFY_PFS_REQUIRED_NEXT_SA message. > My reading of the current specification is that if the initiator doesn't propose PFS but the responder requires it, the proposal will be rejected with a NO_PROPOSAL_CHOSEN notification, just as would any other time there is no overlap between what the initiator proposes and what the responder is prepared to accept. If the initiator supports more than he proposed, he can try again with a different proposal. After the initial exchange, doing so does not have a "negotiate-down" vulnerability. > Not that we could really change it now, but did anyone consider the idea of > acheiving PFS simply by applying a one-way hash to SKEYSEED_D, either > periodically or after every CREATE_CHILD_SA exchange? Sure, there are race > conditions, but I think they are easily fixed. I believe this would be a great enhancement to the protocol, albeit a little late for this time around. I proposed it informally a while back, but it was shot down by some of the crypto people. I still don't understand why, but decided not to rock the boat. It is likely I miscommunicated the proposal. --Charlie From owner-ipsec@lists.tislabs.com Thu May 1 17:36:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h420a1i2086114; Thu, 1 May 2003 17:36:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16349 Thu, 1 May 2003 20:02:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 1 May 2003 15:56:57 -0700 To: Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: Re: Requirements for IKEv2 implementations Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:09 PM -0400 5/1/03, Charlie_Kaufman@notesdev.ibm.com wrote: >I think it would >be a mistake to remove the requirement for certificate based >authentication, because it is hard, people would be tempted to leave it >out, and I believe that's where we want to end up in the long run. That's all well and good, but that doesn't match the definition for MUST in 2119. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 1 18:34:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h421YQi2087721; Thu, 1 May 2003 18:34:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16497 Thu, 1 May 2003 21:03:20 -0400 (EDT) Message-ID: From: "Zimmerman, Mark" To: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Subject: RE: Requirements for IKEv2 implementations Date: Thu, 1 May 2003 21:07:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Thursday, May 01, 2003 5:06 PM To: ipsec@lists.tislabs.com Subject: RE: Requirements for IKEv2 implementations At 4:20 PM -0700 4/29/03, Gregory Lebovitz wrote: >MY WG and Security Area member perspective: >Certificates are good security and we should try as much as we can to help >implementations adopt them. >That's what SHOULD is for. The current text says MUST. > Any worthwhile IKEv1 implementation today can >handle certs. >Sorry, but that is just plain wrong. There are many "worthwhile" >implementations that don't do certs. There are plenty of "worthwhile" >implementations that do certs wrong, such as doing things with certs >that the IKEv1 specs say they SHOULD NOT do. Agreed, and as with anything it also depends on how the solution is being implemented. ICSA Labs has 47 tested IKEv1 products using PSK that have been certified as interoperable. None of which I would call "not" worthwhile. As the alternative, for those that have implemented PKI, 11 products have been tested and certified within our 1.1 Criteria program which mandates Certificate authentication all which have been tested and certified as being interoperable with each other. It all depends on what the customer needs, but making PKI a MUST at this point is jumping the gun. SHOULD is appropriate. >>Market observer perspective: >>PKI has been a royal pain for many interested in IPsec VPNs. Just ask the >>PKI vendors. They have abandoned the application as a focus for their >>development, marketing and sales. At an absolute minimum, PSS is a MUST. >Exactly right. But there is no reason for two MUSTs for authentication. Again, Agreed,I feel like a red headed step-child when trying to resolve issues with PKI vendors or even getting support on our own test bench CA's Mark Zimmerman IPSec Technology Program Manager ICSA Labs >--Paul Hoffman, Director >--VPN Consortium *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** From owner-ipsec@lists.tislabs.com Thu May 1 21:28:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h424S9i2091450; Thu, 1 May 2003 21:28:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17032 Thu, 1 May 2003 23:52:51 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3EB0F42D.F1E18B51@enst.fr> Subject: Re: ISAKMP and SSL To: Ibrahim Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Thu, 1 May 2003 22:12:51 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/01/2003 11:57:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id XAA17029 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi all, > Most key management protocols (ISAKMP, TLS Handshake, Oakley, SKEME, SKIP…) > even in SSH are based on Diffie-Hellman. > This can be an additional reason to this issue if we saw that we develop the > same key management protocols but every time with a little bit change. > what i want to say is why every security protocol should propose his own key > management schemes if we can unify all this work? I think the first ISAKMP > proposition was in this road. It seems like whenever someone needs a key management protocol, they look at the ones that already exist (maybe), decide that they are all too complicated and don't match their needs very well, so they invent a new one. Then they add features to make it possible for future designers to use theirs instead of inventing a new one again. In the process, they end up with a design that is too complicated and doesn't match anyone's needs very well. Some people would say that where we've failed is in coming up with a key management protocol that works for everyone. I disagree. I think that our failure has been in believing that a single key management protocol can work for everyone and continue trying to invent it. The cryptographic guts of these protocols has evolved over time, but not that much. The real differences come from the different requirements of different protocols. SSL/TLS runs over TCP, making all kinds of framing and retransmission issues much simpler. It was developed for browsers and web servers, where authentication is inherently asymmetric. The browser wants to authenticate the DNS name of the server, which is fairly tightly tied to the IP address. But the server doesn't care about the browser's address... it wants to authenticate the name of the user at the browser; a user who is likely to move around. Usually today, the server doesn't authenticate the browser at all. That authentication takes place at a higher layer (typically with a password in the http header or even a higher layer). IPsec serves a different audience. Actually several different audiences, and we're still dealing with their different requirements. So I believe the "lets design this thing once and for all and have everyone use it" is a distraction from getting real work done. Yes, look at what's out there. But don't lose track of the problem you're trying to solve, and don't spend too much time trying to solve the problems you think someone else may have someday. They won't thank you for it. --Charlie From owner-ipsec@lists.tislabs.com Thu May 1 21:55:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h424tci2092100; Thu, 1 May 2003 21:55:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17105 Fri, 2 May 2003 00:26:14 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: ikev2-07: last nits To: Hugo Krawczyk Cc: IPsec WG X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Thu, 1 May 2003 23:51:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/02/2003 12:31:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've indicated the changes I've made to reflect these proposals. If anyone disagrees, please speak up. I can back them out, but it's easier to do the edits as I go along... --Charlie > (1) Page 23 sec 2.10: > > Current text: These nonces are used to add freshness to the key derivation > technique used to obtain keys for CHILD_SAs. > > Proposed text: These nonces are used to add freshness to the key derivation > technique used to obtain keys for CHILD_SA, and to extract strong > pseudorandom bits from the Diffie-Hellman key. > > Explanation: I added the text after the comma which is an essential > part of the rationale behind IKE's key derivation technique [SIGMA] > Done. > (2) Page 26 2.14 > > Current text: Ni and Nr are the nonces, stripped of any headers. If the > negotiated prf takes a fixed length key, Ni and Nr MUST each be truncated to > one half of the fixed key length. > > Proposed text: Ni and Nr are the nonces, stripped of any headers. If the > negotiated prf takes a fixed length key, the key Ni | Nr MUST be formed by > truncating each of Ni and Nr to one half of the fixed key length (if > truncation is performed then the exceeding most significant bits of each > nonce are not used when forming the prf key Ni | Nr). > > Explanation: I added the specification that in case of truncation one uses the > least significant bits of the nonces (choosing the "lsb" was arbitrary). The > current text is under-specified since it says to truncate the nonces to half > the key length but is silent about which bits to use. (Also, I tried to write > this in a way that makes clear that the truncation is done only for the sake > of forming the key to prf, but not for other uses of the nonces -- if this is > still not clear maybe more explicit text on this is needed.) > I agree the current text could be misinterpreted, but I don't like your fix. Most significant and least significant is a confusing concept when dealing with bit strings, and may not even be well defined. Adding to the confusion, the nonces are strings of octets, where msb and lsb are well defined within the octet but I don't believe it's obvious which are the most and least significant octet. How about the following? "If the negotiated prf takes a fixed length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits from each." > (3) Page 27 2.15: > > Current text: This is typically insecure because user chosen passwords are > unlikely to have sufficient unpredictability to resist dictionary attacks. > > Proposed text: This is typically insecure because user chosen passwords are > unlikely to have sufficient unpredictability to resist dictionary attacks, > and these attacks are not prevented in this authentication method > (applications using password-based authentication for bootstrapping an IKE > exchange should use the authentication method in section 2.16 which is > designed to prevent off-line dictionary attacks). > > Explanation: I added this explicit design decision, namely, not having > designed pre-shared mode to prevent dictionary attacks; also it is important > to say explicitly that password authentication should be used only in the > framework of the EAP methods from sec 2.16. If you do not like this text here, > it can be moved to security considerations. > Done. > (4) Page 27 2.15 > Current text: The pad string is added so that if the shared secret is derived > from a password, the IKE implementation need not store the password in > cleartext, but rather can store a one way transformation of it that could not > be used as a password equivalent for protocols other than IKEv2. > > Proposed text: The pad string is added so that if the shared secret is derived > from a password, the IKE implementation need not store the password in > cleartext, but rather can store the value prf(Shared Secret,"Key Pad for > IKEv2") that could not be used as a password equivalent for protocols other > than IKEv2. > > Explanation: the current text is too general. The above is more specific > and then probably clearer. > Done. > (5) Page 29 2.17 > > Current text: > > For CREATE_CHILD_SA exchanges with PFS the keying material is defined as: > > KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) > > Proposed text: erase g^ir (ph2) > > Explanation: this is a leftover from 06. You erased g^ir from other places > where it was unneeded but this one stayed. If I understand correctly, the > value SK_d used in this derivation is computed in section 2.18 using > SKEYSEED which, in turn, is already derived from g^ir (new) . > Thus re-using g^ir (ph2) (here `ph2' and `new' refer to the same thing) > under SK_d is of no help (and spoils the theoretical analysis). > We understand differently :-} I took out the g^ir in the derivation of the IKE keys from SKEYSEED because g^ir was used in the derivation of SKEYSEED. But for child SAs, if there is a second Diffie-Hellman exchange specifically for the creation of that child SA, that g^ir needs to be wound in somewhere. In the construction above SK_d is derived from SKEYSEED, which is derived from g^ir. But that's a different g^ir than the one here. This section and section 2.18 are parallel. This one talks about keying material for an ESP or AH SA. 2.18 talks about keying material for a new IKE SA. In both cases, the (optional) new g^ir must be wound in. The label 'ph2' is an obsolete reference to 'Phase 2'. I changed it to 'new' to match the language in section 2.18. Am I missing something? > (6) Page 81 Sec 5 (Security Considerations) > > Current text: The strength of all keys are limited by the size of the output > of the negotiated prf function. For this reason, a prf function whose output > is less than 128 bits (e.g. 3DES-CBC) MUST never be used with this protocol. > > Discussion: You may want to add that a prf that outputs less bits than its > own key is also unsuited for use (even if its output is longer than 128 bits). > The reason for this is that SKEYSEED is produced by a (single) application > of the prf and its length needs to be that of the prf key. > > Important: The above specifications on the usable prf's should go to the > normative part of the document (sections 2.13 or 2.14) rather than in these > Security Considerations. I suggest to also add there that SKEYSEED is to be at > least of the length of a secure key for the negotiated prf (and if this prf is > of fixed-length key then SKEYSEED is to be of exactly this length). > I believe that the use of a prf other than HMAC (or at least not accepting a variable length key) is dangerously poorly thought out, and my inclination is to take out all references to it. Since it got added there have been a series of problems (including the one earlier in this note). I hadn't noticed - but you are certainly correct - that the spec assumes that if the prf has a fixed length key that the key length is the same as the output length. That allows AES128-CBC, but no others come to mind. We could keep patching, but is this really a requirement? It was motivated by people who were going to put AES in hardware and didn't want to have to implement a digest function as well. I'll buy that for the fast path (packet integrity checks), but do we really need to engineer for that case for the performance-irrelevant key expansion case? If so, could someone make a more specific suggestion as to how to fix this. > (7) Security Considerations > > Add text (possibly before the last paragraph on NAT traversal): For > information on the rationale of many of the cryptographic design choices in > this protocol see [SIGMA]. > > Explanation: it is important to provide a pointer for analysts of the > protocol (especially due to the many subtleties surrounding this design), > and for those that may need to update/change the protocol in the future. > (And for this purpose a ps/pdf document seems more useful than a ascii based > rfc.) > Done. > Hopefully my LAST set of comments before the closing of this WG (am I > being too optimistic?) > Dream on! > Hugo > > --charlie From owner-ipsec@lists.tislabs.com Fri May 2 00:53:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h427rgi2016030; Fri, 2 May 2003 00:53:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17585 Fri, 2 May 2003 03:29:03 -0400 (EDT) Subject: RE: IPSec Passthrough From: Vinay K Nallamothu To: BSingh@Nomadix.com Cc: msiler@hcin.net, ipsec@lists.tislabs.com In-Reply-To: <89680B404BA1DD419E6D93B28B41899B0105F21A@01MAIL> References: <89680B404BA1DD419E6D93B28B41899B0105F21A@01MAIL> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 02 May 2003 11:39:19 +0530 Message-Id: <1051855760.1160.14.camel@lima.royalchallenge.com> Mime-Version: 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2003-05-01 at 23:44, BSingh@Nomadix.com wrote: > server. It is dependent on the server implementation to distinguish 2 > different connections coming from the same IP address (of the NAT device) > and is not a very reliable method of doing things.. what tricks were used by the NAT-T unware IPsec gateways? Few mechanisms i could imagine the IPsec gateways did: 1. Use L2TP over IPsec and tie (using firewall rules) the PPP/L2TP assigned IP address to the IPsec SA. 2. Do some sort of (static?) NAT (again using firewall) on the packets coming out an SA so that the packets on the reverse path can be reliably channeled to the correct SA. Any better ways of doing that? vinay From owner-ipsec@lists.tislabs.com Fri May 2 00:55:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h427t1i2016428; Fri, 2 May 2003 00:55:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17546 Fri, 2 May 2003 03:20:58 -0400 (EDT) Message-Id: <5.1.0.14.0.20030502104650.00a2a7d0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 May 2003 11:05:04 +0530 To: Stephen Kent , Jyothi From: Jyothi Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I had a doubt in the following scenario: >>Office1Network-----SG1---------Internet------------SG2-------Office2Network. SG1 has two outbound and two inbound policies of auto key management outbound policies: 1. source as office1network, destination as office2network, protocol as TCP, source port and destination port 80. IPSEC attributes: ESP, DES. This policy is configured with higher priority. 2. source as office1network, destination as office2network, protocol as ANY, IPSEC attributes: AH, MD5. This policy is configured with low priority. inbound policies: 1. source as office2network, destination as office1network, protocol as TCP, source port and destination port 80. IPSEC attributes: ESP, DES. This policy is configured with higher priority. 2. source as office2network, destination as office1network, protocol as ANY, IPSEC attributes: AH, MD5. This policy is configured with low priority. SG2 has one outbound and one inbound policy of auto key management: outbound policy: 1. source as office2network, destination as office1network, protocol as ANY, IPSEC attributes: AH, MD5. inbound policy: 1. source as office1network, destination as office2network, protocol as ANY, IPSEC attributes: AH, MD5. SG2 started IKE negotiation with its configured IPSEC policy. After IKE negotiation , IPSEC SAs will be created both sides with IPSEC attributes : AH and MD5. When SG2 sends the HTTP traffic with the using above SAs, SG1 process the inbound IPSEC packets, after processing it finds the IPSEC policy with the packet selectors. In this case SG1 has separate IPSEC policy is configured for HTTP traffic (IPSEC attributes ESP,DES) with higher priority. My doubt was "Should we need to drop such inbound traffic in SG1 side???" As per Ramana's mail I have gone through the RFC 2401 section 5.2.1. Now my understanding is that we should not drop such traffic. I hope the above description is clear. Please let me know if my understanding is correct. Thanks Jyothi At 05:14 PM 4/30/03 -0400, Stephen Kent wrote: >At 9:58 AM +0530 4/29/03, Jyothi wrote: >>Hi, >> >>Office1Network-----SG1---------Internet------------SG2-------Office2Network. >> >>SG1 contains the 2 IPSEC policies: >> 1. protocol TCP and port 80 >> 2. protocol ANY >> >>SG2 contains the one IPSEC policy of protocol ANY. >> >>Office2Network starts the IKE negotiation for protocol ANY, after the >>negotiation SG2 will send the HTTP traffic with SAs created. >> >>In IKE negotiation, we are informing the allowable traffic as protocol ANY. >> In this case, HTTP is part of protocol ANY. >> >>So, if SG1 rejects inbound traffic coming from SG2, then how SG2 knows?? >> >>Thanks >>Jyothi > >I don't understand all of the assumptions underlying your example. Note >that SPD entries are directional, and thus must be separately defined for >inbound and outbound traffic flows. So, please restate your example in >those terms, and let's see if there is a problem. Ramana's message >indicated why this might not be a problem, but until you state the full >set of assumptions about the SPDs at each end, I don't know how to >interpret the example. > >Steve From owner-ipsec@lists.tislabs.com Fri May 2 07:23:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42ENHi2046817; Fri, 2 May 2003 07:23:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18491 Fri, 2 May 2003 09:49:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <5.1.1.5.2.20030430154837.04a592f8@mira-sjc5-6.cisco.com> References: <3EB00CC9.333D63EF@enst.fr> <3EB00CC9.333D63EF@enst.fr> <5.1.1.5.2.20030430154837.04a592f8@mira-sjc5-6.cisco.com> Date: Fri, 2 May 2003 09:37:34 -0400 To: Mark Baugher From: Stephen Kent Subject: Re: ISAKMP and SSL Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA18488 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:49 PM -0700 4/30/03, Mark Baugher wrote: >At 05:40 PM 4/30/2003 -0400, Stephen Kent wrote: >>At 7:50 PM +0200 4/30/03, Ibrahim wrote: >>>Hi all, >>>When I read RFC 2408 they described ISAKMP as a generic key management >>>protocol for all security protocols but till now the large deployment of >>>ISAKMP was only with IPSEC >>>My question is, can we use it with SSL/TLS? >>>The goal of this issue is to add new services in SSL/TLS (identity >>>protection, attribute certificate passing for access control schemes, >>>non-repudiation…). >>>Thank you in advance >>>Ibrahim >> >>SSL/TLS has its own, tightly couple key management protocol, so it >>would not be appropriate to try to use ISAKMP. > >I think the confusion comes from the fact that the ISAKMP RFC says >it could be applied to TLS. > >Mark It lied :-) Steve From owner-ipsec@lists.tislabs.com Fri May 2 08:10:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42FAvi2049006; Fri, 2 May 2003 08:10:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18695 Fri, 2 May 2003 10:45:24 -0400 (EDT) Message-Id: <200305021450.h42EoJMI032614@Vindhya.com> Date: Fri, 2 May 2003 7:55:07 -0700 From: "Srao" To: "Jyothi" , "Stephen Kent" Cc: "ipsec@lists.tislabs.com" Reply-to: "Srao" Subject: Re: Question on inbound IPSEC policy check X-Priority: 3 X-Mailer: Intoto Mail 1.2 Content-Transfer-Encoding: 8bit X-MSMail-Priority: Medium Importance: Medium Content-Type: text/html; charset="iso-8859-1"; MIME-Version: 1.0 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jyothi,
   Since, the traffic does not follow the policies created by the administartor,
   the traffic has to be dropped. If the standard is ambiguous, it needs to be
   fixed.
Srini


--------- Original Message --------
From: "Jyothi" <vjyothi@intotoinc.com>
To: "Stephen Kent" <kent@bbn.com>, "Jyothi" <vjyothi@intotoinc.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Question on inbound IPSEC policy check
Date: Thu 05/01/03 06:08 PM


Hi,

I had a doubt in the following scenario:

>>Office1Network-----SG1---------Internet------------SG2-------Office2Network.

SG1 has two outbound and two inbound policies of auto key management

outbound policies:
1. source as office1network, destination as office2network, protocol as TCP,
source port and destination port 80. IPSEC attributes: ESP, DES.
This policy is configured with higher priority.

2. source as office1network, destination as office2network, protocol as ANY,
IPSEC attributes: AH, MD5.
This policy is configured with low priority.

inbound policies:
1. source as office2network, destination as office1network, protocol as TCP,
source port and destination port 80. IPSEC attributes: ESP, DES.
This policy is configured with higher priority.

2. source as office2network, destination as office1network, protocol as ANY,
IPSEC attributes: AH, MD5.
This policy is configured with low priority.

SG2 has one outbound and one inbound policy of auto key management:

outbound policy:
1. source as office2network, destination as office1network, protocol as ANY,
IPSEC attributes: AH, MD5.

inbound policy:
1. source as office1network, destination as office2network, protocol as ANY,
IPSEC attributes: AH, MD5.

SG2 started IKE negotiation with its configured IPSEC policy.

After IKE negotiation , IPSEC SAs will be created both sides with IPSEC
attributes : AH and MD5.

When SG2 sends the HTTP traffic with the using above SAs,
SG1 process the inbound IPSEC packets, after processing it finds the IPSEC
policy with the packet selectors.

In this case SG1 has separate IPSEC policy is configured for HTTP traffic
(IPSEC attributes ESP,DES) with higher priority.

My doubt was "Should we need to drop such inbound traffic in SG1 side???"

As per Ramana's mail I have gone through the RFC 2401 section 5.2.1.

Now my understanding is that we should not drop such traffic.

I hope the above description is clear.

Please let me know if my understanding is correct.

Thanks
Jyothi


At 05:14 PM 4/30/03 -0400, Stephen Kent wrote:
>At 9:58 AM +0530 4/29/03, Jyothi wrote:
>>Hi,
>>
>>Office1Network-----SG1---------Internet------------SG2-------Office2Network.
>>
>>SG1 contains the 2 IPSEC policies:
>> 1. protocol TCP and port 80
>> 2. protocol ANY
>>
>>SG2 contains the one IPSEC policy of protocol ANY.
>>
>>Office2Network starts the IKE negotiation for protocol ANY, after the
>>negotiation SG2 will send the HTTP traffic with SAs created.
>>
>>In IKE negotiation, we are informing the allowable traffic as protocol ANY.
>> In this case, HTTP is part of protocol ANY.
>>
>>So, if SG1 rejects inbound traffic coming from SG2, then how SG2 knows??
>>
>>Thanks
>>Jyothi
>
>I don't understand all of the assumptions underlying your example. Note
>that SPD entries are directional, and thus must be separately defined for
>inbound and outbound traffic flows. So, please restate your example in
>those terms, and let's see if there is a problem. Ramana's message
>indicated why this might not be a problem, but until you state the full
>set of assumptions about the SPDs at each end, I don't know how to
>interpret the example.
>
>Steve




From owner-ipsec@lists.tislabs.com Fri May 2 08:45:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42FjSi2054366; Fri, 2 May 2003 08:45:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18755 Fri, 2 May 2003 11:09:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.1.0.14.0.20030502104650.00a2a7d0@172.16.1.10> References: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030502104650.00a2a7d0@172.16.1.10> Date: Fri, 2 May 2003 11:13:40 -0400 To: Jyothi From: Stephen Kent Subject: Re: Question on inbound IPSEC policy check Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jyothi, Thanks for spelling out all the SPD entries. That clarifies the question. I'm afraid 2401 was not precise enough about this, and the text that describes how to match incoming traffic against the SPD in section 5.2.1 is poor and has been the source of confusion for many folks over the last few years. As you note in your example, if one merely checks inbound traffic against the SPD entry that was used to create the SAD entry, the intent of the inbound SPD may not be realized, because the SPD is ordered and allows overlapping entries. In revising 2401, we plan to use a different model for how one creates SAD entries from the SPD, and how one can use a cache of SPD entries to facilitate faster outbound processing. The concept that underlies this new model is that of a de-correlated SPD. De-correlation transforms overlapping entries into entries that no longer overlap, by creating additional, distinct entries. If one de-correlates an SPD, one can cache entries for outbound and inbound checks, because ordering no longer matters. That should avoid the problem you noted, since the de-correlated entries at SG1 for inbound traffic would include only one that covers traffic with source = officenetwork2, dest = offficenetwork1, protocol = TCP and dest port = 80, i.e., the one that calls for using ESP instead of AH. In IKE v2, because the headers from the packet that triggered the exchange are sent to the responder, the responder would create an SA that would be willing to receive traffic OTHER than the port 80 traffic, avoiding the problem you noted. Steve From owner-ipsec@lists.tislabs.com Fri May 2 09:51:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42Gpli2056142; Fri, 2 May 2003 09:51:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18941 Fri, 2 May 2003 12:09:52 -0400 (EDT) Message-ID: <073601c310c5$e98ab810$5505010a@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Jyothi" , "Stephen Kent" Cc: References: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030502104650.00a2a7d0@172.16.1.10> Subject: Re: Question on inbound IPSEC policy check Date: Fri, 2 May 2003 09:14:19 -0700 Organization: Intoto Inc. 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Kent, Thank you for the clarification. As it stands today, implementations have to look for inbound SPD in their order and drop packets that don't match the policies. Thanks Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Stephen Kent" To: "Jyothi" Cc: Sent: Friday, May 02, 2003 8:13 AM Subject: Re: Question on inbound IPSEC policy check > Jyothi, > > Thanks for spelling out all the SPD entries. That clarifies the question. > > I'm afraid 2401 was not precise enough about this, and the text that > describes how to match incoming traffic against the SPD in section > 5.2.1 is poor and has been the source of confusion for many folks > over the last few years. > > As you note in your example, if one merely checks inbound traffic > against the SPD entry that was used to create the SAD entry, the > intent of the inbound SPD may not be realized, because the SPD is > ordered and allows overlapping entries. > > In revising 2401, we plan to use a different model for how one > creates SAD entries from the SPD, and how one can use a cache of SPD > entries to facilitate faster outbound processing. The concept that > underlies this new model is that of a de-correlated SPD. > De-correlation transforms overlapping entries into entries that no > longer overlap, by creating additional, distinct entries. > If one de-correlates an SPD, one can cache entries for outbound and > inbound checks, because ordering no longer matters. That should avoid > the problem you noted, since the de-correlated entries at SG1 for > inbound traffic would include only one that covers traffic with > source = officenetwork2, dest = offficenetwork1, protocol = TCP and > dest port = 80, i.e., the one that calls for using ESP instead of AH. > > In IKE v2, because the headers from the packet that triggered the > exchange are sent to the responder, the responder would create an SA > that would be willing to receive traffic OTHER than the port 80 > traffic, avoiding the problem you noted. > > Steve From owner-ipsec@lists.tislabs.com Fri May 2 12:05:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42J5Yi2063209; Fri, 2 May 2003 12:05:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19387 Fri, 2 May 2003 14:23:33 -0400 (EDT) Message-Id: <200305021817.OAA23957@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-ciph-aes-cbc-05.txt Date: Fri, 02 May 2003 14:17:06 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The AES Cipher Algorithms and Their Use With IPsec Author(s) : S. Frankel, S. Kelly, R. Glenn Filename : draft-ietf-ipsec-ciph-aes-cbc-05.txt Pages : 14 Date : 2003-5-2 This document describes the use of the AES Cipher Algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ciph-aes-cbc-05.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-ciph-aes-cbc-05.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: <2003-5-2142614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-cbc-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-2142614.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri May 2 12:09:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42J9Xi2063329; Fri, 2 May 2003 12:09:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19428 Fri, 2 May 2003 14:32:31 -0400 (EDT) Message-Id: <4.3.2.7.1.20030502112555.02509100@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 May 2003 11:38:51 -0700 To: "Srinivasa Rao Addepalli" , "Jyothi" , "Stephen Kent" From: Ramana Yarlagadda Subject: Re: Question on inbound IPSEC policy check Cc: In-Reply-To: <073601c310c5$e98ab810$5505010a@SindhuSriha> References: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030502104650.00a2a7d0@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Shall we igonre the text note that i refered to in section 5.2.1 of rfc 2401. And if that is the case, then with the setup Jyothi has described the SA negotiation should fail. -ramana At 09:14 AM 5/2/03 -0700, Srinivasa Rao Addepalli wrote: >Hi Kent, > Thank you for the clarification. As it stands today, > implementations have to look for inbound SPD in their order > and drop packets that don't match the policies. >Thanks > > > > Thanks for spelling out all the SPD entries. That clarifies the question. > > > > I'm afraid 2401 was not precise enough about this, and the text that > > describes how to match incoming traffic against the SPD in section > > 5.2.1 is poor and has been the source of confusion for many folks > > over the last few years. > > > > As you note in your example, if one merely checks inbound traffic > > against the SPD entry that was used to create the SAD entry, the > > intent of the inbound SPD may not be realized, because the SPD is > > ordered and allows overlapping entries. > > > > In revising 2401, we plan to use a different model for how one > > creates SAD entries from the SPD, and how one can use a cache of SPD > > entries to facilitate faster outbound processing. The concept that > > underlies this new model is that of a de-correlated SPD. > > De-correlation transforms overlapping entries into entries that no > > longer overlap, by creating additional, distinct entries. > > If one de-correlates an SPD, one can cache entries for outbound and > > inbound checks, because ordering no longer matters. That should avoid > > the problem you noted, since the de-correlated entries at SG1 for > > inbound traffic would include only one that covers traffic with > > source = officenetwork2, dest = offficenetwork1, protocol = TCP and > > dest port = 80, i.e., the one that calls for using ESP instead of AH. > > > > In IKE v2, because the headers from the packet that triggered the > > exchange are sent to the responder, the responder would create an SA > > that would be willing to receive traffic OTHER than the port 80 > > traffic, avoiding the problem you noted. > > > > Steve > > > From owner-ipsec@lists.tislabs.com Fri May 2 12:13:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42JDOi2063560; Fri, 2 May 2003 12:13:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19487 Fri, 2 May 2003 14:40:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <29664595-7BF7-11D7-96C9-000A959D832C@apple.com> References: <1772A2E865ABD411B18900508BB1B88F05ED7D8C@SVARLEXC07> <1051769403.1131.40.camel@lima.royalchallenge.com> <29664595-7BF7-11D7-96C9-000A959D832C@apple.com> Date: Fri, 2 May 2003 14:40:40 -0400 To: Joshua Graessley From: Stephen Kent Subject: Re: IPSec Passthrough Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >There are two "modes" that IPSec operates in, tunnel mode and >transport mode. This is, in my opinion, a little bogus because >"tunnel mode" is really just transport mode where the next header is >an IP header instead of UDP, TCP, ICMP or some other protocol. >Anyhow, the NAT transparency only works with Tunnel mode (where the >next header after the ESP header is IP). In transport mode, the TCP >and UDP checksums will be screwed up. ESP encrypts and authenticates >the payload so the NAT can't molest it. The UDP and TCP checksums >take bits of the IP header in to account, most notably the source >and destination IP addresses. The NAT modifies the destination IP >address. Since it can't see or modify the TCP or UDP checksum to >compensate for the address change, TCP and UDP packets will be >dropped due to a bad checksum. Josh, Tunnel and transport mode differ in several ways that make them more different that what you suggest above, for example: - in tunnel mode we discard the outer IP header, whereas in transport mode we don't discard anything from the inbound packet - the modes differ in terms of which headers are checked for inbound access control (the topic of a recent thread on this list) Steve From owner-ipsec@lists.tislabs.com Fri May 2 12:21:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42JLDi2063781; Fri, 2 May 2003 12:21:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19513 Fri, 2 May 2003 14:52:07 -0400 (EDT) Message-ID: <08eb01c310dc$987e7620$5505010a@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Jyothi" , "Stephen Kent" , "Ramana Yarlagadda" Cc: References: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030502104650.00a2a7d0@172.16.1.10> <4.3.2.7.1.20030502112555.02509100@golf.cpgdesign.analog.com> Subject: Re: Question on inbound IPSEC policy check Date: Fri, 2 May 2003 11:56:53 -0700 Organization: Intoto Inc. 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ramana, As Kent mentioned, in quick mode, implementations send selectors defined in the SPD policies. Due to this, quick mode initiation by SG2 will succeed as SG1 has policy associated with these selectors. But, HTTP packets will be dropped by SG1 as it does not match SAs in SP with HTTP selectors. It is configuration issue between two administrators and for now, it has to be resolved out of band way. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Ramana Yarlagadda" To: "Srinivasa Rao Addepalli" ; "Jyothi" ; "Stephen Kent" Cc: Sent: Friday, May 02, 2003 11:38 AM Subject: Re: Question on inbound IPSEC policy check > Hi, > > Shall we igonre the text note that i refered to in section 5.2.1 of rfc 2401. > > And if that is the case, then with the setup Jyothi has described the SA > negotiation should fail. > > -ramana > > At 09:14 AM 5/2/03 -0700, Srinivasa Rao Addepalli wrote: > >Hi Kent, > > Thank you for the clarification. As it stands today, > > implementations have to look for inbound SPD in their order > > and drop packets that don't match the policies. > >Thanks > > > > > > > > > > > > Thanks for spelling out all the SPD entries. That clarifies the question. > > > > > > I'm afraid 2401 was not precise enough about this, and the text that > > > describes how to match incoming traffic against the SPD in section > > > 5.2.1 is poor and has been the source of confusion for many folks > > > over the last few years. > > > > > > As you note in your example, if one merely checks inbound traffic > > > against the SPD entry that was used to create the SAD entry, the > > > intent of the inbound SPD may not be realized, because the SPD is > > > ordered and allows overlapping entries. > > > > > > In revising 2401, we plan to use a different model for how one > > > creates SAD entries from the SPD, and how one can use a cache of SPD > > > entries to facilitate faster outbound processing. The concept that > > > underlies this new model is that of a de-correlated SPD. > > > De-correlation transforms overlapping entries into entries that no > > > longer overlap, by creating additional, distinct entries. > > > If one de-correlates an SPD, one can cache entries for outbound and > > > inbound checks, because ordering no longer matters. That should avoid > > > the problem you noted, since the de-correlated entries at SG1 for > > > inbound traffic would include only one that covers traffic with > > > source = officenetwork2, dest = offficenetwork1, protocol = TCP and > > > dest port = 80, i.e., the one that calls for using ESP instead of AH. > > > > > > In IKE v2, because the headers from the packet that triggered the > > > exchange are sent to the responder, the responder would create an SA > > > that would be willing to receive traffic OTHER than the port 80 > > > traffic, avoiding the problem you noted. > > > > > > Steve > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Fri May 2 12:41:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42JfQi2064320; Fri, 2 May 2003 12:41:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19586 Fri, 2 May 2003 15:12:26 -0400 (EDT) Message-Id: <4.3.2.7.1.20030502121318.02480d10@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 May 2003 12:18:43 -0700 To: Vinay K Nallamothu , BSingh@Nomadix.com From: Ramana Yarlagadda Subject: RE: IPSec Passthrough Cc: msiler@hcin.net, ipsec@lists.tislabs.com In-Reply-To: <1051855760.1160.14.camel@lima.royalchallenge.com> References: <89680B404BA1DD419E6D93B28B41899B0105F21A@01MAIL> <89680B404BA1DD419E6D93B28B41899B0105F21A@01MAIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Vinay >Few mechanisms i could imagine the IPsec gateways did: >1. Use L2TP over IPsec and tie (using firewall rules) the PPP/L2TP >assigned IP address to the IPsec SA. > >2. Do some sort of (static?) NAT (again using firewall) on the packets >coming out an SA so that the packets on the reverse path can be reliably >channeled to the correct SA. The static NAT requires more no of IP addresses. But with out static NAT this can be done, by serializing the IPSEC connections of hosts behind the NAT device. Linux implementation is available for this problem. >Any better ways of doing that? From owner-ipsec@lists.tislabs.com Fri May 2 12:44:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42Jifi2064392; Fri, 2 May 2003 12:44:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19609 Fri, 2 May 2003 15:17:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.1.20030502112555.02509100@golf.cpgdesign.analog.com> References: <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030423130203.00a43540@172.16.1.10> <5.1.0.14.0.20030428110102.00a2ae70@172.16.1.10> <5.1.0.14.0.20030429090406.00a2fec0@172.16.1.10> <5.1.0.14.0.20030502104650.00a2a7d0@172.16.1.10> <4.3.2.7.1.20030502112555.02509100@golf.cpgdesign.analog.com> Date: Fri, 2 May 2003 15:22:18 -0400 To: Ramana Yarlagadda From: Stephen Kent Subject: Re: Question on inbound IPSEC policy check Cc: "Srinivasa Rao Addepalli" , "Jyothi" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:38 AM -0700 5/2/03, Ramana Yarlagadda wrote: >Hi, > >Shall we igonre the text note that i refered to in section 5.2.1 of rfc 2401. > >And if that is the case, then with the setup Jyothi has described the SA >negotiation should fail. > >-ramana As I mentioned, the text needs to be fixed and I described how I plan to fix it, in general terms. I can't fault anyone for interpreting the text in different ways, but I do believe that our goal should be to prevent IPsec from behaving in a "surprising" fashion. Use that as your guide, and you have a defensible position. Steve From owner-ipsec@lists.tislabs.com Fri May 2 13:01:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42K1oi2064786; Fri, 2 May 2003 13:01:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19677 Fri, 2 May 2003 15:26:12 -0400 (EDT) Message-ID: <090d01c310e1$5da44ac0$5505010a@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Vinay K Nallamothu" , Cc: , References: <89680B404BA1DD419E6D93B28B41899B0105F21A@01MAIL> <1051855760.1160.14.camel@lima.royalchallenge.com> Subject: Re: IPSec Passthrough Date: Fri, 2 May 2003 12:31:01 -0700 Organization: Intoto Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, These are the ways to run IPSEC tunnel between two SGs with Firewall/NATs in between the security gateways. 1. L2TP over IPSEC (rfc3193): It works well and very useful to provide remote access for VPN clients. As you may be aware, WINXP/WIN2000 comes with built in client. Microsoft also provides free client software for WIN98. More and more vendors are supporting LNS with IPSEC. Disadvantage: More bandwidth is used. 2. IPSEC NAT Traversal: There is very less penalty on bandwidth compared to L2TP over IPSEC (use v2 onwards). Most of the vendors support this feature and is interoperable. 3. NAT boxes having ESP/IKE intelligence: In this case, there is no bandwidth penalty. But there are some disadvantages with this: A. Can't expect this intelligence to be there in all NAT boxes. B. Though many clients can establish tunnels with the corp. gateway, until tunnel is established in both ways, other clients can't connect to the same peer. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Vinay K Nallamothu" To: Cc: ; Sent: Thursday, May 01, 2003 11:09 PM Subject: RE: IPSec Passthrough > On Thu, 2003-05-01 at 23:44, BSingh@Nomadix.com wrote: > > server. It is dependent on the server implementation to distinguish 2 > > different connections coming from the same IP address (of the NAT device) > > and is not a very reliable method of doing things.. > what tricks were used by the NAT-T unware IPsec gateways? > > Few mechanisms i could imagine the IPsec gateways did: > 1. Use L2TP over IPsec and tie (using firewall rules) the PPP/L2TP > assigned IP address to the IPsec SA. > > 2. Do some sort of (static?) NAT (again using firewall) on the packets > coming out an SA so that the packets on the reverse path can be reliably > channeled to the correct SA. > > Any better ways of doing that? > > vinay From owner-ipsec@lists.tislabs.com Fri May 2 13:04:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42K4ii2064883; Fri, 2 May 2003 13:04:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19745 Fri, 2 May 2003 15:36:55 -0400 (EDT) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899B0105F29D@01MAIL> To: srao@intotoinc.com, vinay-rc@naturesoft.net, BSingh@Nomadix.com Cc: msiler@hcin.net, ipsec@lists.tislabs.com Date: Fri, 2 May 2003 12:20:19 -0700 Subject: RE: IPSec Passthrough MIME-Version: 1.0 Content-Type: text/plain X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For 3. I will add that what is listed is one way of doing things.. In the Nomadix USG we have the patent-pending iNAT functionality that does away with the requirement of sequencing multiple IPSec connections to the same server and adding reliability by reducing the confusion for the server.. And also it doesn't require keeping track of ESP SPIs as well.. -----Original Message----- From: Srinivasa Rao Addepalli [mailto:srao@intotoinc.com] Sent: Friday, May 02, 2003 12:31 PM To: Vinay K Nallamothu; BSingh@Nomadix.com Cc: msiler@hcin.net; ipsec@lists.tislabs.com Subject: Re: IPSec Passthrough Hi, These are the ways to run IPSEC tunnel between two SGs with Firewall/NATs in between the security gateways. 1. L2TP over IPSEC (rfc3193): It works well and very useful to provide remote access for VPN clients. As you may be aware, WINXP/WIN2000 comes with built in client. Microsoft also provides free client software for WIN98. More and more vendors are supporting LNS with IPSEC. Disadvantage: More bandwidth is used. 2. IPSEC NAT Traversal: There is very less penalty on bandwidth compared to L2TP over IPSEC (use v2 onwards). Most of the vendors support this feature and is interoperable. 3. NAT boxes having ESP/IKE intelligence: In this case, there is no bandwidth penalty. But there are some disadvantages with this: A. Can't expect this intelligence to be there in all NAT boxes. B. Though many clients can establish tunnels with the corp. gateway, until tunnel is established in both ways, other clients can't connect to the same peer. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Vinay K Nallamothu" To: Cc: ; Sent: Thursday, May 01, 2003 11:09 PM Subject: RE: IPSec Passthrough > On Thu, 2003-05-01 at 23:44, BSingh@Nomadix.com wrote: > > server. It is dependent on the server implementation to distinguish 2 > > different connections coming from the same IP address (of the NAT device) > > and is not a very reliable method of doing things.. > what tricks were used by the NAT-T unware IPsec gateways? > > Few mechanisms i could imagine the IPsec gateways did: > 1. Use L2TP over IPsec and tie (using firewall rules) the PPP/L2TP > assigned IP address to the IPsec SA. > > 2. Do some sort of (static?) NAT (again using firewall) on the packets > coming out an SA so that the packets on the reverse path can be reliably > channeled to the correct SA. > > Any better ways of doing that? > > vinay From owner-ipsec@lists.tislabs.com Fri May 2 15:23:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42MNWi2069242; Fri, 2 May 2003 15:23:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20216 Fri, 2 May 2003 17:53:43 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Terminology question: "suites" vs "set of cryptographic algorithms" To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Fri, 2 May 2003 17:56:07 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/02/2003 05:59:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When I changed IKEv2 back to a la carte cryptographic algorithm negotiation, in many places I continued to use the terms "suite" and "cryptographic suite" to refer to the set of algorithms proposed and accepted even though there is no longer a concept of named suites or meaning beyond a "set of algorithms to be used together". I believe this is a common use of the term, but at least one reader found it confusing, particularly since "we aren't negotiating suites anymore". What do others think? I'm not averse to replacing the term, but I'm reluctant to make last minute changes that someone else might object to. This is only a terminology question. Opinions? --Charlie From owner-ipsec@lists.tislabs.com Fri May 2 15:55:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42Mthi2070364; Fri, 2 May 2003 15:55:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20303 Fri, 2 May 2003 18:28:43 -0400 (EDT) Message-Id: <5.0.2.1.0.20030502151347.00afea68@10.1.5.10> X-Sender: suren@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 02 May 2003 15:31:49 -0700 To: ipsec@lists.tislabs.com From: suren Subject: IPSEC in High Availability scenarios Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Small introduction: We find the IPSEC is being used in critical applications and high availability is one of requirements of customers. Typically two SGs are used - one acting as Master and other acting as backup device. VRRP like kind of utilities are used to detect the aliveness of master SG. Backup SG inherits the same IP address. In these cases, the remote peers don't know that that there are two SGs and control is transferred from master to backup device. Problem: Due to critical timing nature of applications run on IPSEC tunnels, customers are increasingly asking for SA transfer between master and backup so that backup can take over tunnel when master fails (To avoid new tunnel establishment). There is a problem when anti-replay is enabled on SAs, which is MUST in most of the cases. Transferring this change of sequence number information between master and backup device,might have performance implications and some times not practical. Solution: Today, we have proprietary mechanism to solve this problem, but it works between same kind of implementations. We are trying to see if there is any inter-operable solution for this problem. We feel that backup device can send notification message (when tunnels in backup device get activated) indicating to the peer that it can accept the packets with some specific sequence number. Basically, synchronizing the sequence numbers in the tunnel. What do others think of this solution: Having SYNCH-SEQUENCE notification message. We can force that this has to be protected message. Also, we can have sequence number information for detecting replaying of this notification message. Do you see any problem with this approach? Or Is there any inter-operable solution already defined? Thank you for you time. Suren Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA www.intotoinc.com From owner-ipsec@lists.tislabs.com Fri May 2 17:34:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h430YWi2072905; Fri, 2 May 2003 17:34:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20610 Fri, 2 May 2003 20:02:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 2 May 2003 16:40:30 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Terminology question: "suites" vs "set of cryptographic algorithms" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The term "suite" is used inconsistently in the current document. In some places, it means "the set of things chosen by the responder". However, there are exceptions. I have listed what I think are the main problems with the term "suite" in the current draft. The third paragraph of 2.7 says: This hierarchical structure was designed to be able to efficiently encode proposals for cryptographic suites when the number of supported suites is large because multiple values are acceptable for multiple transforms. The responder MUST choose a single suite, which MAY be any subset of the SA proposal following the rules below: This use of "suites" is talking about the proposals offered by the initiator, which is the "old" use of suites. The last sentence in 2.7 says: Alice MUST again propose her full set of acceptable cryptographic suites because the rejection message was unauthenticated and otherwise an active attacker could trick Alice and Bob into negotiating a weaker suite than a stronger one that they both prefer. But Alice isn't proposing suites, she is proposing individual algorithms. In 3.10.1 it says: NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. But no suites were proposed: algorithm choices were proposed. Section 6: Values of the Cryptographic Suite-ID define a set of cryptographic algorithms to be used in an IKE, ESP, or AH SA. We removed Suite-ID completely. Appedix B: Future IANA-registered and private use Suite-IDs MAY use Diffie- Hellman groups that have modulus values and generators that are different than those in this document or in [ADDGROUP]. Ditto. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri May 2 17:34:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h430Yei2072917; Fri, 2 May 2003 17:34:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20629 Fri, 2 May 2003 20:02:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 2 May 2003 16:54:23 -0700 To: Charlie_Kaufman@notesdev.ibm.com, Hugo Krawczyk From: Paul Hoffman / VPNC Subject: Re: ikev2-07: last nits Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:51 PM -0400 5/1/03, Charlie_Kaufman@notesdev.ibm.com wrote: >I believe that the use of a prf other than HMAC (or at least not accepting >a variable length key) is dangerously poorly thought out, and my >inclination is to take out all references to it. Fully agree. > Since it got added there >have been a series of problems (including the one earlier in this note). Here's more. Section 2.15 says: If the negotiated prf takes a fixed size key, the shared secret MUST be of that fixed size. This is completely wrong. It means that the two sides need to know before they choose their preshared secret what the prf that they will negotiate every time will be. > I >hadn't noticed - but you are certainly correct - that the spec assumes that >if the prf has a fixed length key that the key length is the same as the >output length. That allows AES128-CBC, but no others come to mind. We could >keep patching, but is this really a requirement? It was motivated by people >who were going to put AES in hardware and didn't want to have to implement >a digest function as well. I'll buy that for the fast path (packet >integrity checks), but do we really need to engineer for that case for the >performance-irrelevant key expansion case? If so, could someone make a more >specific suggestion as to how to fix this. I support your original suggestion: prohibit prfs with fixed-size keys. If someone really wants to add one or more of them later, they can write an extension to IKEv2 that clearly specifies how to do it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri May 2 17:35:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h430ZLi2072958; Fri, 2 May 2003 17:35:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20613 Fri, 2 May 2003 20:02:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 2 May 2003 16:45:36 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Rekeying in IKEv2: optional or mandatory? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi again. In section 2.8 of draft -07, it talks about MUSTs and SHOULDs in rekeying. However, later in the document it says that the ability to rekey is optional. This is pretty confusing. Personally, I think that rekeying should be optional, but it is clear that folks haven't read this too carefully and this needs to be cleared up before we finish. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri May 2 17:35:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h430ZTi2072969; Fri, 2 May 2003 17:35:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20621 Fri, 2 May 2003 20:02:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 2 May 2003 17:06:17 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Vendor IDs and reserved values Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi again. Section 3.12 says: If parameter values "reserved for use by consenting parties" are used, they must be preceded by a Vendor ID payload that disambiguates them. This will hinder interoperability. Given that Vendor IDs are also "reserved for use by consenting parties", this requirement doesn't make sense. A private value is a private value: the two sides have already agreed to what it means. Sending a private Vendor ID doesn't add any information, and is another place where a failure can happen. This sentence should be removed. --Paul Hoffman, Director --VPN Consortium From medwardyp0sg1rr@msn.com Sat May 3 04:26:40 2003 Received: from hotmail.com (bay5-dav13.bay5.hotmail.com [65.54.172.117]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h43BQei2023960 for ; Sat, 3 May 2003 04:26:40 -0700 (PDT) (envelope-from medwardyp0sg1rr@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 3 May 2003 04:26:35 -0700 Received: from 213.189.83.102 by bay5-dav13.bay5.hotmail.com with DAV; Sat, 03 May 2003 11:26:35 +0000 X-Originating-IP: [213.189.83.102] X-Originating-Email: [medwardyp0sg1rr@msn.com] Subject: Maintain Your Septic Tank Correctly From: "Colgrove Watrous" To: "Schoewe Trifiletti" X-Accept-Language: en Organization: 4tk33Y6X22GN2lNk1Kua053P8wQF8v1U Content-Type: multipart/alternative; boundary="7uwfBJn1IY3CO4hhU082ir7EpgLj7UStpiorO51PUe7N04JLhSgIG27G4o3Er1ACQ" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 03 May 2003 11:26:35.0965 (UTC) FILETIME=[DB4626D0:01C31166] Date: 3 May 2003 04:26:35 -0700 --7uwfBJn1IY3CO4hhU082ir7EpgLj7UStpiorO51PUe7N04JLhSgIG27G4o3Er1ACQ Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="US-ASCII"
*** Prolong The Life Of Your Septic System ***

Try SPC Septic Cleaner For Free and judge for yourself.

Visit Our Web Site Here

 Keep your septic system non-clogging and free flowing!
It's 100% environmentally safe and the best product available
So what do you have to lose?

Click here now and get a FREE trial!

To be removed click here
--7uwfBJn1IY3CO4hhU082ir7EpgLj7UStpiorO51PUe7N04JLhSgIG27G4o3Er1ACQ-- From owner-ipsec@lists.tislabs.com Sat May 3 11:58:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h43Iwci2047650; Sat, 3 May 2003 11:58:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00256 Sat, 3 May 2003 14:16:47 -0400 (EDT) Message-Id: <200305031738.h43HctnJ002678@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Wed, 30 Apr 2003 18:07:07 PDT." <3EB0733B.80BA8E5B@airespace.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 03 May 2003 13:38:55 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> If the cert contents are not meaningful to the receiver, the discussion Scott> is moot, is it not? Not entirely. If the cert contents is not meaningful to the receiver, and the sender does not send an ID payload, then the negotiation fails. It is this risk that I am trying avoid. >> So, the situation where all of your conditions hold true is the >> road warrior case, where access is granted not by configuration, but >> by permitting any client to connect that has a certificate signed by >> some CA. Scott> No, this is not the only case. I may construct a policy filter which Scott> looks like this: Scott> ISSUER: me Scott> DN FILTER: c=*,o=ietf,ou=ipsec-wg,cn=Michael*,* Scott> GN FILTER: * Scott> In this case, if you know that I require the DN, you can send it, or I Scott> can simply extract it from the cert. But what if I want to construct Scott> filters using things other than DN and GN? If I use issuerName, there is Scott> no ID payload you can send me that makes sense. If I require multiple Scott> criteria to be satisfied (e.g. issuer + dn fields + gn fields), there is Scott> no way to express this using currently defined IDs - and why should you, Scott> as the sender, have to know what to extract from the cert? I agree that the ID payload is a problem. You'll get no argument from me. As I've said, I'd prefer to fix the ID payload. I am just concerned about the proposed solution of dropping the ID payload in this situation leads to lack of interoperability. >> I.e. the situation where you can omit the ID payload is one the >> one where you have intentionally mixed authentication with authorization. Scott> Can't really argue with you there, but I don't see how this can be Scott> avoided. The thing that I'm trying to emphasis is that it happens with the awareness of both parties. As such, the sender can easily be configured to either put something meaningful in the ID payload, or to put recognizeable nonsense in. Scott> As I said in my first post on this topic, I think the next best thing is Scott> to require that the ID payload, when present, match something in the Scott> cert. The text on the table renders this optional. I think that's a Scott> mistake. I agree. As an alternative, how about: ID_PKIX_CERT 12 No identifier is provided, derive one from the provided certificate. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrFprIqHRg3pndX9AQFrPwQA22ML0cYBOd3WhfYDr2iWoqcBjcpjcMXD Uul6AnYdCWzQxsG43EO0Cl+kwn1brT2QnBgbBAfEBiV57NTLhUBkztknzj7WkLAi kzLxwi0RcBNapPmU7poBqe1GZWb1aMkFiU4qZ3O/An7gn2mklVxyu9VU9Z3V1bky sKphN4BHuhE= =Zg7J -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat May 3 14:45:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h43LjFi2052334; Sat, 3 May 2003 14:45:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00788 Sat, 3 May 2003 17:14:39 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: IPSec Passthrough Date: Sat, 3 May 2003 09:49:29 -0700 Message-ID: <007501c31193$f9836b30$10c0140a@SGOSWAMIPCL> 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, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Transport Mode and Tunnel Mode are also different in how fragmentation is handled. A Transport Mode ESP implementation needs to have its own fragmentation function as per RFC 2401. Subrata > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Stephen Kent > Sent: Friday, May 02, 2003 11:41 AM > To: Joshua Graessley > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSec Passthrough > > > > > >There are two "modes" that IPSec operates in, tunnel mode and > >transport mode. This is, in my opinion, a little bogus because > >"tunnel mode" is really just transport mode where the next header is > >an IP header instead of UDP, TCP, ICMP or some other protocol. > >Anyhow, the NAT transparency only works with Tunnel mode (where the > >next header after the ESP header is IP). In transport mode, the TCP > >and UDP checksums will be screwed up. ESP encrypts and authenticates > >the payload so the NAT can't molest it. The UDP and TCP checksums > >take bits of the IP header in to account, most notably the source > >and destination IP addresses. The NAT modifies the destination IP > >address. Since it can't see or modify the TCP or UDP checksum to > >compensate for the address change, TCP and UDP packets will be > >dropped due to a bad checksum. > > Josh, > > Tunnel and transport mode differ in several ways that make them more > different that what you suggest above, for example: > > - in tunnel mode we discard the outer IP header, whereas in > transport mode we don't discard anything from the inbound packet > > - the modes differ in terms of which headers are checked for > inbound access control (the topic of a recent thread on this list) > > Steve > From owner-ipsec@lists.tislabs.com Sun May 4 22:08:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4558Zi2038888; Sun, 4 May 2003 22:08:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA04349 Mon, 5 May 2003 00:27:32 -0400 (EDT) Message-Id: <5.2.0.9.2.20030505003025.01990948@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 05 May 2003 00:31:05 -0400 To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Terminology question: "suites" vs "set of cryptographic algorithms" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie: I do not see a problem using the term, as long as it is defined toward the beginning of the document. Russ At 05:56 PM 5/2/2003 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: >When I changed IKEv2 back to a la carte cryptographic algorithm >negotiation, in many places I continued to use the terms "suite" and >"cryptographic suite" to refer to the set of algorithms proposed and >accepted even though there is no longer a concept of named suites or >meaning beyond a "set of algorithms to be used together". I believe this is >a common use of the term, but at least one reader found it confusing, >particularly since "we aren't negotiating suites anymore". > >What do others think? I'm not averse to replacing the term, but I'm >reluctant to make last minute changes that someone else might object to. >This is only a terminology question. > >Opinions? > > --Charlie From owner-ipsec@lists.tislabs.com Mon May 5 06:43:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Dhgi2089707; Mon, 5 May 2003 06:43:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05439 Mon, 5 May 2003 09:05:30 -0400 (EDT) Message-ID: <3EB5E68F.2010203@roc.co.in> Date: Mon, 05 May 2003 09:50:31 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gregory Lebovitz CC: Michael Choung Shieh , "'ddukes@cisco.com'" , ipsec@lists.tislabs.com Subject: Re: Peer liveliness References: <541402FFDC56DA499E7E13329ABFEA87E66CDA@SARATOGA.netscreen.com> Content-Type: multipart/alternative; boundary="------------080009000908060704000704" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------080009000908060704000704 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, In the text below, I also try to use the same terminology used by you. Rebooted Peer and Persistent Peer. In your email, under 'Recommendations to solve the solution', regarding second point: In my view, whether Peer is alive or not does not solve the problem completely. Persistent node should know aliveness of Tunnel on the other side. It is possible that peer reboots and responds to DPD requests, but tunnels are not there. We should have a mechanism to detect the Tunnel aliveness. With respect to DoS attack: You addressed the issue of DoS attack on the persistent side. I am also concerned about DoS attack on rebooting machine. If MITM keeps sending the packets with some dummy SPI and valid source IP, then the IPSEC SG keeps sending the INVALID_SPI and for this,it keeps creating IKE SAs. That is one of the reason, some implementations do not support generationof INVALID_SPI notifications. I feel that having a standard and interoperable mechanism to detect the dead tunnels will solve the problem. regards, Ravi Gregory Lebovitz wrote: > [WE] won't achieve interoperability unless it's mandated that >[IMPLEMENTORS] must > > >>reply INVALID_SPI (in clear or initiate IKE back to the >>sender) whenever it >>receives bad spi packets. Current IKEv2 draft doesn't >>address this issue >>(only states you MAY reply a clear notify message). >> >>IKEv1 vendors has implemented many ways to solve it which leave poor >>interoperability. We should just pick a method and clarify >>it in IKEv2. >>=============== >>Michael Shieh >> >> >> > >We have been having quite a debate in the ICSA IPsec consortium mail list >recently trying to figure out how to handle this in IKEv1 (YES, STILL!!!) > >Here is what we know for sure of this problem statement: >(a) detecting liveness/deadness of peer is a good thing, but does not solve >all the failure cases in and of itself > (b) the behavior of a recently rebooted device when it receives an >encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated, or >else implementations will not interoperate (as is the case in IKEv1, 5 years >later). > (c) the behavior of a peer that receives a new IKE from a peer that it has >an existing IKE-SA with (i.e. the rebooted peer that is trying to initiate a >new connection) MUST be mandated, or else implementations will not >interoperate (as is the case in IKEv1, 5 years later). > >Darren Dukes wrote: > > >>I believe INVALID_SPI does what you are looking for. If I receive an >>INVALID_SPI notify via an IKE SA I know to delete the SA and >>traffic will >>bring up a new one. >> >> > >I don't believe this will work, since it assumes that an IKE SA is >established. In the scenario, the IKE-SA would have been lost along with the >SPI of the CHILD-SA by the rebooted peer. > >Recommendations to solve the solution: >- the empty notify as an aliveness check is a good idea. It accomplishes >what the DPD draft did. Keep using this. > >- do what you can to use empty notify to detect dead peer ASAP. The faster >the persisting peer can delete the old SPI and IKE-SA, the better. The best >case is for Persisting Peer to detect death and initiate new IKE to rebooted >peer before rebooted peer gets packets with old SPI, IKE-SA. > >- On the Rebooted peer side: If an implementation receives a protected >packet from an unkown SPI, > - simply relying on sending back an unprotected INVALID_SPI is not a good >idea. It is too easy to DoS the persisting peer by simply spoofing the >rebooted peer's address. > - initiate IKE to the persisting peer. > >- On the Persisting Peer: > - If you get a new IKE request from a peer already in your SADB, respond >with the under-attack, 6 message method. This will mitigate the DoS attack. >If you get all the way through SA and TS negotiation successfully, you are >assured (unless I'm missing something) that this really is your peer, and >that he re-initiated because he lost the original IKE-SA. Start using the >new IKE-SA and the new CHILD-SA and delete the previous ones after some wait >period. > >Would this proposal explicitly solve things? > >Gregory. > > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------080009000908060704000704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit 
Hi,
In the text below, I also try to use the same terminology used by you.
     Rebooted Peer and Persistent Peer.

     In your email, under 'Recommendations to solve the solution', regarding
     second point:
     In my view, whether Peer is alive or not does not solve the problem completely.
     Persistent node should know aliveness of Tunnel on the other side. It is possible that
     peer reboots and responds to DPD requests, but tunnels are not there. We should
     have a mechanism to detect the Tunnel aliveness.

     With respect to DoS attack:
     You addressed the issue of DoS attack on the persistent side. I am also concerned
     about DoS attack on rebooting machine. If MITM keeps sending the packets with
     some dummy SPI and valid source IP, then the IPSEC SG keeps sending the
     INVALID_SPI and for this,it keeps creating IKE SAs. That is one of the reason, 
     some implementations do not support generationof INVALID_SPI notifications.

     I feel that having a standard and interoperable mechanism to detect the dead
     tunnels will solve the problem.
regards,
Ravi


Gregory Lebovitz wrote:
 [WE] won't achieve interoperability unless it's mandated that 
[IMPLEMENTORS] must
  
reply INVALID_SPI (in clear or initiate IKE back to the 
sender) whenever it
receives bad spi packets.  Current IKEv2 draft doesn't 
address this issue
(only states you MAY reply a clear notify message).

IKEv1 vendors has implemented many ways to solve it which leave poor
interoperability.  We should just pick a method and clarify 
it in IKEv2. 
===============
Michael Shieh

    

We have been having quite a debate in the ICSA IPsec consortium mail list
recently trying to figure out how to handle this in IKEv1 (YES, STILL!!!)

Here is what we know for sure of this problem statement:
(a) detecting liveness/deadness of peer is a good thing, but does not solve
all the failure cases in and of itself
 (b) the behavior of a recently rebooted device when it receives an
encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated, or
else implementations will not interoperate (as is the case in IKEv1, 5 years
later).
 (c) the behavior of a peer that receives a new IKE from a peer that it has
an existing IKE-SA with (i.e. the rebooted peer that is trying to initiate a
new connection) MUST be mandated, or else implementations will not
interoperate (as is the case in IKEv1, 5 years later).

Darren Dukes wrote:
  
I believe INVALID_SPI does what you are looking for.  If I receive an
INVALID_SPI notify via an IKE SA I know to delete the SA and 
traffic will
bring up a new one.  
    

I don't believe this will work, since it assumes that an IKE SA is
established. In the scenario, the IKE-SA would have been lost along with the
SPI of the CHILD-SA by the rebooted peer. 

Recommendations to solve the solution:
- the empty notify as an aliveness check is a good idea. It accomplishes
what the DPD draft did. Keep using this.

- do what you can to use empty notify to detect dead peer ASAP. The faster
the persisting peer can delete the old SPI and IKE-SA, the better. The best
case is for Persisting Peer to detect death and initiate new IKE to rebooted
peer before rebooted peer gets packets with old SPI, IKE-SA.

- On the Rebooted peer side: If an implementation receives a protected
packet from an unkown SPI,  
 - simply relying on sending back an unprotected INVALID_SPI is not a good
idea. It is too easy to DoS the persisting peer by simply spoofing the
rebooted peer's address.
 - initiate IKE to the persisting peer.

- On the Persisting Peer:
 - If you get a new IKE request from a peer already in your SADB, respond
with the under-attack, 6 message method. This will mitigate the DoS attack.
If you get all the way through SA and TS negotiation successfully, you are
assured (unless I'm missing something) that this really is your peer, and
that he re-initiated because he lost the original IKE-SA. Start using the
new IKE-SA and the new CHILD-SA and delete the previous ones after some wait
period.

Would this proposal explicitly solve things?

Gregory.

--
signature

The views presented in this mail are completely mine. The company is not responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page



--------------080009000908060704000704-- From owner-ipsec@lists.tislabs.com Mon May 5 06:43:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Dhgi2089708; Mon, 5 May 2003 06:43:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05433 Mon, 5 May 2003 09:04:29 -0400 (EDT) Message-ID: <3EB5E5E5.3000705@roc.co.in> Date: Mon, 05 May 2003 09:47:41 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: suren CC: ipsec@lists.tislabs.com Subject: Re: IPSEC in High Availability scenarios References: <5.0.2.1.0.20030502151347.00afea68@10.1.5.10> Content-Type: multipart/alternative; boundary="------------090607060706000409000808" X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------090607060706000409000808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Suren, This is one of the problem I am trying to solve for one of my customers. But fortunately, we don't have requirement of using same tunnel when the backup takes over. Even without having to have new tunnel to be established, I did not see any proper and interoperable solution. This is one of the reason I propose to have 'Dead Peer Tunnel (SA) detection'. With this, the other party know eventually that tunnel got terminated on other side and creates new tunnel. SA transfer may not be a good idea for several reasons. A. Keying material also has to be sent. There may be security issues with this. B. SA is not stateful. If it is not there, IPSEC nodes creates new SA. No connection will be terminated. It is not like Firewall/NAT sessions, where some state information needs to be syn'ed up for smooth takeover. I don't see any requirement for this with my limited knowledge. But if there is need for it, then the proposal you suggested seems one possible solution. Regards Ravi suren wrote: > Hi, > > Small introduction: > We find the IPSEC is being used in critical applications and > high availability is one of requirements of customers. Typically > two SGs are used - one acting as Master and other acting as > backup device. VRRP like kind of utilities are used to detect > the aliveness of master SG. Backup SG inherits the same IP > address. In these cases, the remote peers don't know that > that there are two SGs and control is transferred from master > to backup device. > > Problem: > Due to critical timing nature of applications run on IPSEC tunnels, > customers are increasingly asking for SA transfer between master and > backup > so that backup can take over tunnel when master fails (To avoid new > tunnel establishment). > There is a problem when anti-replay is enabled on SAs, which is MUST in > most of the cases. Transferring this change of sequence number > information between master and backup device,might have performance > implications and some times not practical. > > Solution: > Today, we have proprietary mechanism to solve this problem, but > it works between same kind of implementations. We are trying to > see if there is any inter-operable solution for this problem. We > feel that > backup device can send notification message (when tunnels in backup > device get activated) indicating to the peer that it can accept the > packets with some specific sequence number. Basically, synchronizing > the sequence numbers in the tunnel. > What do others think of this solution: Having SYNCH-SEQUENCE > notification message. We can force that this has to be protected > message. > Also, we can have sequence number information for detecting replaying > of this notification message. > > Do you see any problem with this approach? Or Is there any > inter-operable > solution already defined? > > Thank you for you time. > Suren > Intoto Inc. > 3160, De La Cruz Blvd #100 > Santa Clara, CA > www.intotoinc.com > > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page --------------090607060706000409000808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Suren,
     This is one of the problem I am trying to solve for one of my customers.
     But fortunately, we don't have requirement of using same tunnel when
     the backup takes over.
     Even without having to have new tunnel to be established, I did not see
     any proper and interoperable solution. This is one of the reason I propose
     to have 'Dead Peer Tunnel (SA) detection'. With this, the other party 
     know eventually that tunnel got terminated on other side and creates 
     new tunnel. 

     SA transfer may not be a good idea for several reasons.
     A. Keying material also has to be sent. There may be security issues 
         with this. 
     B. SA is not stateful. If it is not there, IPSEC nodes creates new SA.
         No connection will be terminated.
         It is not like Firewall/NAT sessions, where some state information
         needs to be syn'ed up for smooth takeover.

     I don't see any requirement for this with my limited knowledge.
     But if there is need for it, then the proposal you suggested seems
     one possible solution.

     Regards
     Ravi


suren wrote:
Hi,

  Small introduction:
  We find the IPSEC is being used in critical applications and
  high availability is one of requirements of customers. Typically
  two SGs are used - one acting as Master and other acting as
  backup device. VRRP like kind of utilities are used to detect
  the aliveness of master SG. Backup SG inherits the same IP
  address. In these cases, the remote peers don't know that
  that there are two SGs and control is transferred from master
  to backup device.

  Problem:
  Due to critical timing nature of applications run on IPSEC tunnels,
  customers are increasingly asking for SA transfer between master and backup
  so that backup can take over tunnel when master fails (To avoid new tunnel establishment).
  There is a problem when anti-replay is enabled on SAs, which is MUST in
  most of the cases. Transferring this change of sequence number
  information between master and backup device,might have performance
  implications and some times not practical.

  Solution:
  Today, we have proprietary mechanism to solve this problem, but
  it works between same kind of implementations. We are trying to
  see if there is any inter-operable solution for this problem. We feel that
  backup device can send notification message (when tunnels in backup
  device get activated) indicating to the peer that it can accept the
  packets with some specific sequence number. Basically, synchronizing
  the sequence numbers in the tunnel.
  What do others think of this solution: Having SYNCH-SEQUENCE
  notification message. We can force that this has to be protected message.
  Also, we can have sequence number information for detecting replaying
  of this notification message.

  Do you see any problem with this approach? Or Is there any inter-operable
  solution already defined?

Thank you for you time.
Suren
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
www.intotoinc.com

 

--
signature

The views presented in this mail are completely mine. The company is not responsible for whatsoever.
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page



--------------090607060706000409000808-- From owner-ipsec@lists.tislabs.com Mon May 5 10:31:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45HVNi2003206; Mon, 5 May 2003 10:31:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06401 Mon, 5 May 2003 12:56:31 -0400 (EDT) Date: Mon, 5 May 2003 18:51:35 +0300 From: Lauri Tarkkala To: Russ Housley Cc: ipsec@lists.tislabs.com Subject: Re: Requirements for IKEv2 implementations Message-ID: <20030505155135.GA3161@tehdas> References: <541402FFDC56DA499E7E13329ABFEA87E66CD7@SARATOGA.netscreen.com> <5.2.0.9.2.20030430161520.034b0a28@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030430161520.034b0a28@mail.binhost.com> User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Apr 30, 2003 at 04:17:47PM -0400, Russ Housley wrote: > Greg: > > I question the PSS as the mandatory to implement. While I am for an > advocate for this algorithm, I do not think that it is widely deployed > today. I think that RSA PKCS#1 v1.5 is a more appropriate signature > algorithm for MUST. RSA PSS is the up and coming signature algorithm, and > as such I think that SHOULD is the way to go. I agree. Technically PSS is superior to PKSC#1, but I have seen very little support for it in practice. Considering that it would be an advantage to preserve the ability to generate these signatures on misc. devices (smart-cards, USB tokens, and other things I seldom see people using ;-) I would be in favor of the above proposal. Lauri -- Lauri Tarkkala SSH Communications Security Corp From owner-ipsec@lists.tislabs.com Mon May 5 10:41:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Hfli2003469; Mon, 5 May 2003 10:41:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06456 Mon, 5 May 2003 13:08:53 -0400 (EDT) Message-ID: <3EB69BAD.F3CCB359@airespace.com> Date: Mon, 05 May 2003 10:13:17 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <200305031738.h43HctnJ002678@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2003 17:13:32.0118 (UTC) FILETIME=[A77E8760:01C31329] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Michael, Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > >>>>> "Scott" == Scott G Kelly writes: > Scott> If the cert contents are not meaningful to the receiver, the discussion > Scott> is moot, is it not? > > Not entirely. If the cert contents is not meaningful to the receiver, > and the sender does not send an ID payload, then the negotiation fails. I think we're talking past one another here. I meant that if the contents aren't meaningful to the receiver, the receiver most likely can't parse the cert or use the public key contained therein. I think you must mean something different (like maybe the ID doesn't matter, since the receiver only requires that the sender present a cert from a given issuer). > > I agree that the ID payload is a problem. > You'll get no argument from me. > As I've said, I'd prefer to fix the ID payload. > > I am just concerned about the proposed solution of dropping the ID payload > in this situation leads to lack of interoperability. > > I agree. > > As an alternative, how about: > > ID_PKIX_CERT 12 > > No identifier is provided, derive one from the provided certificate. This is essentially what Jim Knowles proposed (I think), and I think this is a reasonable compromise. However, I think it will only improve interoperability if all implementations are required to support it. Scott From owner-ipsec@lists.tislabs.com Mon May 5 13:01:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45K16i2007646; Mon, 5 May 2003 13:01:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06994 Mon, 5 May 2003 15:27:06 -0400 (EDT) Message-Id: <200305051932.h45JW6Ng003456@sandelman.ottawa.on.ca> To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Mon, 05 May 2003 10:13:17 PDT." <3EB69BAD.F3CCB359@airespace.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 May 2003 15:32:05 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> If the cert contents are not meaningful to the receiver, the Scott> discussion is moot, is it not? >> Not entirely. If the cert contents is not meaningful to the receiver, >> and the sender does not send an ID payload, then the negotiation fails. Scott> I think we're talking past one another here. I meant that if the Scott> contents aren't meaningful to the receiver, the receiver most Scott> likely can't parse the cert or use the public key contained Scott> therein. I think Imagine a situation where the receiver has been made aware of the sender's public key, and it has been attached to an ID that the sender is expected to use. (remember, this may even occur by trial-and-error, plus reading of logs by the receiver!) The receiver can't parse the CERT in real time, but they can attach the public key. So, if you drop the ID, then the protocols gets weird, and the receiver can't cope. >> As an alternative, how about: >> >> ID_PKIX_CERT 12 >> >> No identifier is provided, derive one from the provided certificate. Scott> This is essentially what Jim Knowles proposed (I think), and I think Scott> this is a reasonable compromise. However, I think it will only Scott> improve interoperability if all implementations are required to Scott> support it. Unless we make CERTs a MUST, you won't get that. But, I keep suggesting that VPNs should have a difference set of MUSTs. Let's not mix up different applicability situations. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPra8M4qHRg3pndX9AQG6qgQAsNprZgmPOH3nxC3503MgmBYupl5Eczzt epEY5NaVrHZsKzRj+bMKJ4kGWfBYK04ML9xj8Ykuo/pc4P+E0J52dHylEO9iMR5U LN8GND6hymgve4F14axhCXnq8Da64ydKjndb42RbplYRwDYiH33R1dkJczXX3XeM gtyEMDH6jtc= =cYDm -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon May 5 15:54:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Ms3i2013152; Mon, 5 May 2003 15:54:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07585 Mon, 5 May 2003 18:22:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.0.2.1.0.20030502151347.00afea68@10.1.5.10> References: <5.0.2.1.0.20030502151347.00afea68@10.1.5.10> Date: Mon, 5 May 2003 18:24:55 -0400 To: suren , ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: IPSEC in High Availability scenarios Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:31 PM -0700 5/2/03, suren wrote: >Hi, > > Small introduction: > We find the IPSEC is being used in critical applications and > high availability is one of requirements of customers. Typically > two SGs are used - one acting as Master and other acting as > backup device. VRRP like kind of utilities are used to detect > the aliveness of master SG. Backup SG inherits the same IP > address. In these cases, the remote peers don't know that > that there are two SGs and control is transferred from master > to backup device. Perhaps this is not a good model. The backup SG, in order to be able to take over the SAs from the primary SG must have access to all the keys in use, and the movement of keys between the two may create security assurance problems. For example, are any of the implementations that support this approach evaluated under FIPS 140-1/2 at level 3 or 4? An alternative would be to have backup SAs created at the same time as the primary SAs, but homed to the backup SG, at its own address, and then move the traffic to the existing, backup SAs, which would avoid the sequence number problem you noted. > > Problem: > Due to critical timing nature of applications run on IPSEC tunnels, > customers are increasingly asking for SA transfer between master and backup > so that backup can take over tunnel when master fails (To avoid >new tunnel establishment). > There is a problem when anti-replay is enabled on SAs, which is MUST in > most of the cases. Transferring this change of sequence number > information between master and backup device,might have performance > implications and some times not practical. > > Solution: > Today, we have proprietary mechanism to solve this problem, but > it works between same kind of implementations. We are trying to > see if there is any inter-operable solution for this problem. We feel that > backup device can send notification message (when tunnels in backup > device get activated) indicating to the peer that it can accept the > packets with some specific sequence number. Basically, synchronizing > the sequence numbers in the tunnel. > What do others think of this solution: Having SYNCH-SEQUENCE > notification message. We can force that this has to be protected message. > Also, we can have sequence number information for detecting replaying > of this notification message. > > Do you see any problem with this approach? Or Is there any inter-operable > solution already defined? I'm not saying this can't be done securely, but you have no provided sufficient detail to know. For example, is this new message sent over the IKE SA or over the subscriber SA? If via IKE, then there may be problems matching the SYNCH-SEQUENCE to the data path sequence numbers. If via the subscriber SA, then how is this message accepted out of order? Also, is this proprietary mechanism patented? Steve From owner-ipsec@lists.tislabs.com Mon May 5 18:53:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h461roi2017757; Mon, 5 May 2003 18:53:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08410 Mon, 5 May 2003 21:23:54 -0400 (EDT) Message-Id: <5.0.2.1.0.20030505181006.024bb860@10.1.5.10> X-Sender: suren@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 05 May 2003 18:27:24 -0700 To: Stephen Kent , ipsec@lists.tislabs.com From: suren Subject: Re: IPSEC in High Availability scenarios In-Reply-To: References: <5.0.2.1.0.20030502151347.00afea68@10.1.5.10> <5.0.2.1.0.20030502151347.00afea68@10.1.5.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Stephen, Thank you for the response. You stated that the backup SA can be created to avoid the transferring SA key material and thereby avoiding transfer sequence number information. This works fine, if backup device has IP address different from the master device. Also, it requires peer to have knowledge of backup IP address for a given tunnel. In the case, which I was referring in my last email, backup device inherits the IP address of master device, when master fails. We understand that transferring the keying material is not a good thing. But... Notification message: SYNCH_SEQUENCE notification message can be sent on IKE SA with Protocol ID as ESP or AH and notification data containing sequence number of this notification message and inbound SA's SPI on the peer. We have following options: 1. Mandate that backup device has new IP address. I am not sure it flies as customers use backup device for state transfer of other applications such as NAT/Firewall/QoS etc.. This requires that backup device inherits the IP address. ==> It means that backup SA may not be possible in this case. 2. Have some sort of detection mechanism, beyond Peer detection ie Dead Tunnel detection ( as mentioned by Ravi ) so that Peer eventually knows that tunnel is no longer exist and create new Tunnel and this time it goes to backup device. But in this case, there may not be any communication for the period Dead Peer Tunnel detection and time it takes to establish the tunnel. 3. SA Transfer: It does not seem to be good thing... By the way, our proprietary method is not patented. 4. Any new proposal from the members in this list? Thanks Suren At 06:24 PM 5/5/2003 -0400, Stephen Kent wrote: >At 3:31 PM -0700 5/2/03, suren wrote: >>Hi, >> >> Small introduction: >> We find the IPSEC is being used in critical applications and >> high availability is one of requirements of customers. Typically >> two SGs are used - one acting as Master and other acting as >> backup device. VRRP like kind of utilities are used to detect >> the aliveness of master SG. Backup SG inherits the same IP >> address. In these cases, the remote peers don't know that >> that there are two SGs and control is transferred from master >> to backup device. > >Perhaps this is not a good model. The backup SG, in order to be able to >take over the SAs from the primary SG must have access to all the keys in >use, and the movement of keys between the two may create security >assurance problems. For example, are any of the implementations that >support this approach evaluated under FIPS 140-1/2 at level 3 or 4? > >An alternative would be to have backup SAs created at the same time as the >primary SAs, but homed to the backup SG, at its own address, and then move >the traffic to the existing, backup SAs, which would avoid the sequence >number problem you noted. > >> >> Problem: >> Due to critical timing nature of applications run on IPSEC tunnels, >> customers are increasingly asking for SA transfer between master and >> backup >> so that backup can take over tunnel when master fails (To avoid new >> tunnel establishment). >> There is a problem when anti-replay is enabled on SAs, which is MUST in >> most of the cases. Transferring this change of sequence number >> information between master and backup device,might have performance >> implications and some times not practical. >> >> Solution: >> Today, we have proprietary mechanism to solve this problem, but >> it works between same kind of implementations. We are trying to >> see if there is any inter-operable solution for this problem. We feel that >> backup device can send notification message (when tunnels in backup >> device get activated) indicating to the peer that it can accept the >> packets with some specific sequence number. Basically, synchronizing >> the sequence numbers in the tunnel. >> What do others think of this solution: Having SYNCH-SEQUENCE >> notification message. We can force that this has to be protected message. >> Also, we can have sequence number information for detecting replaying >> of this notification message. >> >> Do you see any problem with this approach? Or Is there any inter-operable >> solution already defined? > >I'm not saying this can't be done securely, but you have no provided >sufficient detail to know. For example, is this new message sent over the >IKE SA or over the subscriber SA? If via IKE, then there may be problems >matching the SYNCH-SEQUENCE to the data path sequence numbers. If via the >subscriber SA, then how is this message accepted out of order? Also, is >this proprietary mechanism patented? > >Steve From owner-ipsec@lists.tislabs.com Mon May 5 19:58:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h462wMi2019432; Mon, 5 May 2003 19:58:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08519 Mon, 5 May 2003 22:23:38 -0400 (EDT) Message-Id: <4.3.2.7.1.20030505191555.00ec9350@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 May 2003 19:30:13 -0700 To: ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: TIME OUT value Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, All From section 5.1 of RFC 2408: 1. Set a timer and initialize a retry counter. NOTE: Implementations MUST NOT use a fixed timer. Instead, transmission timer values should be adjusted dynamically based on measured round trip times. In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals (e.g., exponential backoff). 2. If the timer expires, the ISAKMP message is resent and the retry counter is decremented. 3. If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file. 4. The ISAKMP protocol machine clears all states and returns to IDLE. -------------------- My question is what are the minimum and maximum TIMEOUT values? Is there any guideline for this? I see a problem when one of the gateway has a small TIMEOUT value and the other gateway takes quite a good amount of time to calculate the DH or RSA? The one with a small TIMEOUT value might go to step 4 easily. -thanks in advance -ramana From owner-ipsec@lists.tislabs.com Tue May 6 00:47:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h467lSi2040370; Tue, 6 May 2003 00:47:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA09127 Tue, 6 May 2003 03:10:10 -0400 (EDT) Reply-To: From: "Rajesh Mohan" To: "'suren'" , "'Stephen Kent'" , Subject: RE: IPSEC in High Availability scenarios Date: Tue, 6 May 2003 12:43:38 +0530 Message-Id: <004801c3139f$04de2120$7b06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <5.0.2.1.0.20030505181006.024bb860@10.1.5.10> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Suren, I understand, your solution is only for outbound sequence number. I see one problem with this solution. IPSec Packet may be processed before IKE INFO packet though it may arrive before IPSec packet. You may have few dropped packets. BTW what will be the sequnce number on these IPSec packets. Are you planning to reset it or have regular updates and use last known value? Another possible solution is to update the backup at regular intervals with the current state of the window. After failover, just advance the outgoing sequnce number (the value depends on rate of traffic and update interval). In this case, some sequence numbers may not be used. I think lot of people do this. Regarding, FIPS certification for transferring keying material between HA pairs, I think it is OK for Level 2, if the key is encrypted. We are planning to use IKE SA between HA pair to secure HA traffic and we think it is good enough for FIPS 140-2 Level 2. -Rajesh Mohan > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of suren > Sent: Tuesday, May 06, 2003 6:57 AM > To: Stephen Kent; ipsec@lists.tislabs.com > Subject: Re: IPSEC in High Availability scenarios > > > Hi Stephen, > Thank you for the response. You stated that the backup SA > can be created to avoid the transferring SA key material and > thereby avoiding transfer sequence number information. > This works fine, if backup device has IP address different > from the master device. Also, it requires peer to have > knowledge of backup IP address for a given tunnel. > > In the case, which I was referring in my last email, > backup device > inherits the IP address of master device, when master fails. We > understand > that transferring the keying material is not a good thing. But... > > Notification message: > SYNCH_SEQUENCE notification message can be sent > on IKE SA with Protocol ID as ESP or AH and notification data > containing sequence number of this notification message and > inbound SA's SPI on the peer. > > We have following options: > 1. Mandate that backup device has new IP address. > I am not sure it flies as customers use backup device > for state > transfer > of other applications such as NAT/Firewall/QoS etc.. > This requires > that backup device inherits the IP address. > ==> It means that backup SA may not be possible in this case. > 2. Have some sort of detection mechanism, beyond Peer detection ie > Dead Tunnel detection ( as mentioned by Ravi ) so that > Peer eventually > knows that tunnel is no longer exist and create new > Tunnel and this > time it goes to backup device. But in this case, there > may not be > any communication for the period Dead Peer Tunnel detection and > time it takes to establish the tunnel. > 3. SA Transfer: It does not seem to be good thing... By the way, > our proprietary method is not patented. > 4. Any new proposal from the members in this list? > > Thanks > Suren > > > > > At 06:24 PM 5/5/2003 -0400, Stephen Kent wrote: > >At 3:31 PM -0700 5/2/03, suren wrote: > >>Hi, > >> > >> Small introduction: > >> We find the IPSEC is being used in critical applications and > >> high availability is one of requirements of customers. Typically > >> two SGs are used - one acting as Master and other acting as > >> backup device. VRRP like kind of utilities are used to detect > >> the aliveness of master SG. Backup SG inherits the same IP > >> address. In these cases, the remote peers don't know that > >> that there are two SGs and control is transferred from master > >> to backup device. > > > >Perhaps this is not a good model. The backup SG, in order to > be able to > >take over the SAs from the primary SG must have access to > all the keys in > >use, and the movement of keys between the two may create security > >assurance problems. For example, are any of the > implementations that > >support this approach evaluated under FIPS 140-1/2 at level 3 or 4? > > > >An alternative would be to have backup SAs created at the > same time as the > >primary SAs, but homed to the backup SG, at its own address, > and then move > >the traffic to the existing, backup SAs, which would avoid > the sequence > >number problem you noted. > > > >> > >> Problem: > >> Due to critical timing nature of applications run on > IPSEC tunnels, > >> customers are increasingly asking for SA transfer > between master and > >> backup > >> so that backup can take over tunnel when master fails > (To avoid new > >> tunnel establishment). > >> There is a problem when anti-replay is enabled on SAs, > which is MUST in > >> most of the cases. Transferring this change of sequence number > >> information between master and backup device,might have > performance > >> implications and some times not practical. > >> > >> Solution: > >> Today, we have proprietary mechanism to solve this problem, but > >> it works between same kind of implementations. We are trying to > >> see if there is any inter-operable solution for this > problem. We feel that > >> backup device can send notification message (when > tunnels in backup > >> device get activated) indicating to the peer that it can > accept the > >> packets with some specific sequence number. Basically, > synchronizing > >> the sequence numbers in the tunnel. > >> What do others think of this solution: Having SYNCH-SEQUENCE > >> notification message. We can force that this has to be > protected message. > >> Also, we can have sequence number information for > detecting replaying > >> of this notification message. > >> > >> Do you see any problem with this approach? Or Is there > any inter-operable > >> solution already defined? > > > >I'm not saying this can't be done securely, but you have no provided > >sufficient detail to know. For example, is this new message > sent over the > >IKE SA or over the subscriber SA? If via IKE, then there > may be problems > >matching the SYNCH-SEQUENCE to the data path sequence > numbers. If via the > >subscriber SA, then how is this message accepted out of > order? Also, is > >this proprietary mechanism patented? > > > >Steve > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ipsec@lists.tislabs.com Tue May 6 02:54:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h469sAi2060604; Tue, 6 May 2003 02:54:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09596 Tue, 6 May 2003 05:23:13 -0400 (EDT) From: "Jesse Alpert" To: Cc: "'suren'" Subject: RE: IPSEC in High Availability scenarios Date: Tue, 6 May 2003 12:29:16 +0300 Message-ID: <005801c313b1$f78a4900$7b2e1dc2@jesse> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.0.2.1.0.20030502151347.00afea68@10.1.5.10> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Suren, The problem you described can be solved using the existing standards, if you consider the fact that an IPsec peer should be willing to accept (large) forward leaps in the replay counter value. The backup GW can start it's replay counter sequence from some larger value. Note however that for Load Sharing scenarios (as apposed to the High Availability scenario you described) the solution may not be as simple. Jesse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of suren Sent: Saturday, May 03, 2003 1:32 AM To: ipsec@lists.tislabs.com Subject: IPSEC in High Availability scenarios Hi, Small introduction: We find the IPSEC is being used in critical applications and high availability is one of requirements of customers. Typically two SGs are used - one acting as Master and other acting as backup device. VRRP like kind of utilities are used to detect the aliveness of master SG. Backup SG inherits the same IP address. In these cases, the remote peers don't know that that there are two SGs and control is transferred from master to backup device. Problem: Due to critical timing nature of applications run on IPSEC tunnels, customers are increasingly asking for SA transfer between master and backup so that backup can take over tunnel when master fails (To avoid new tunnel establishment). There is a problem when anti-replay is enabled on SAs, which is MUST in most of the cases. Transferring this change of sequence number information between master and backup device,might have performance implications and some times not practical. Solution: Today, we have proprietary mechanism to solve this problem, but it works between same kind of implementations. We are trying to see if there is any inter-operable solution for this problem. We feel that backup device can send notification message (when tunnels in backup device get activated) indicating to the peer that it can accept the packets with some specific sequence number. Basically, synchronizing the sequence numbers in the tunnel. What do others think of this solution: Having SYNCH-SEQUENCE notification message. We can force that this has to be protected message. Also, we can have sequence number information for detecting replaying of this notification message. Do you see any problem with this approach? Or Is there any inter-operable solution already defined? Thank you for you time. Suren Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA www.intotoinc.com From owner-ipsec@lists.tislabs.com Tue May 6 06:41:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46DfYi2075620; Tue, 6 May 2003 06:41:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10258 Tue, 6 May 2003 09:11:02 -0400 (EDT) Message-ID: <3EB7A539.C4B4E32C@americasm01.nt.com> Date: Tue, 06 May 2003 08:06:17 -0400 From: "Wei-Jen Yeh" Organization: Nortel Networks X-Mailer: Mozilla 4.79 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Jesse Alpert CC: ipsec@lists.tislabs.com, "'suren'" Subject: Re: IPSEC in High Availability scenarios References: <005801c313b1$f78a4900$7b2e1dc2@jesse> Content-Type: multipart/alternative; boundary="------------DFEDE9D4D9BCE74FC267590A" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------DFEDE9D4D9BCE74FC267590A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, You need to handle replay info from both sender & receiver perspectives, and there's also the lifetime info that needs to be considered. How about redundancy support for the KMP? What if you need to have secured traffic to the spare unit, too? You also need to engineer your `private network' based on the amount of SAs that need to be mirrored (assuming you go this route) and do your queuing right! -- Wei-Jen Yeh weijyeh@nortelnetworks.com Nortel, RTP, NC Office Phone: (919) 991-2707, ESN: 35-12707 Fax: (919) 991-8073 --------------DFEDE9D4D9BCE74FC267590A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
  You need to handle replay info from both sender & receiver perspectives, and
there's also the lifetime info that needs to be considered.
  How about redundancy support for the KMP?
  What if you need to have secured traffic to the spare unit, too?
  You also need to engineer your `private network' based on the amount of
SAs that need to be mirrored (assuming you go this route) and do your queuing
right! 
-- 
Wei-Jen Yeh
weijyeh@nortelnetworks.com      Nortel, RTP, NC
Office Phone: (919) 991-2707,   ESN: 35-12707
Fax: (919) 991-8073
  --------------DFEDE9D4D9BCE74FC267590A-- From owner-ipsec@lists.tislabs.com Tue May 6 08:56:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Fu8i2083917; Tue, 6 May 2003 08:56:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10772 Tue, 6 May 2003 11:22:04 -0400 (EDT) Message-Id: <200305061526.h46FQdof051279@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Hugo Krawczyk cc: Charlie_Kaufman@notesdev.ibm.com, IPsec WG Subject: Re: ikev2-07: last nits In-reply-to: Your message of Wed, 30 Apr 2003 03:09:31 +0300. Date: Tue, 06 May 2003 17:26:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: (5) Page 29 2.17 Current text: For CREATE_CHILD_SA exchanges with PFS the keying material is defined as: KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) Proposed text: erase g^ir (ph2) Explanation: this is a leftover from 06. You erased g^ir from other places where it was unneeded but this one stayed. If I understand correctly, the value SK_d used in this derivation is computed in section 2.18 using => I am afraid that you are wrong here: section 2.18 is about CREATE_CHILD_SAs rekeying IKE SAs, section 2.17 is about CREATE_CHILD_SA in general (i.e., for IKE SAs and IPsec SAs), and KEYMAT is (this is not written in the draft!) for IPsec SAs only. SKEYSEED which, in turn, is already derived from g^ir (new) . Thus re-using g^ir (ph2) (here `ph2' and `new' refer to the same thing) under SK_d is of no help (and spoils the theoretical analysis). => in fact there are at least two improvements to do: - explain again what is a CHILD_SA (the term is introduced in the overview) - as a consequence make clearer that KEYMAT is the keying material of the being established IPsec SA pair. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed May 7 20:53:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h483rmi2017460; Wed, 7 May 2003 20:53:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16622 Wed, 7 May 2003 23:11:15 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Message-Id: <200305080316.h483GF415582@sydney.East.Sun.COM> Date: Wed, 7 May 2003 23:17:16 -0400 To: "Hannes Tschofenig" , Reply-To: Subject: Re: EAP Handling in IKEv2 X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If it doesn't create a session key you really can't protect against man-in-the-middle. Radia "Hannes Tschofenig" wrote: >Dear all, > > > >in Section 2.16 you mention the mechanism for protecting against >man-in-the-middle attacks: > >" For EAP methods that create a shared key as a side effect of > >authentication, that shared key MUST be used by both the Initiator > >and Responder to generate an AUTH payload using the syntax for shared > >secrets specified in section 2.15. This shared key MUST NOT be used > >for any other purpose. > >" > >This covers the case where the EAP method establishes a session key. > >Which procedure do you suggest for cases where EAP methods do not create a >session key such as the One-Time Password (OTP)? > > > >Ciao > >Hannes > From owner-ipsec@lists.tislabs.com Wed May 7 22:34:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h485YIi2020272; Wed, 7 May 2003 22:34:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16862 Thu, 8 May 2003 01:08:35 -0400 (EDT) Message-ID: <3EB9E73B.80100@kolumbus.fi> Date: Thu, 08 May 2003 08:12:27 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: radia.perlman@sun.com Cc: Hannes Tschofenig , ipsec@lists.tislabs.com, Bernard Aboba Subject: Re: EAP Handling in IKEv2 References: <200305080316.h483GF415582@sydney.East.Sun.COM> In-Reply-To: <200305080316.h483GF415582@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking wrote: > If it doesn't create a session key you really can't protect > against man-in-the-middle. I think you meant "can't protect against mitm *and* still use the same credentials outside IKEv2". But surprisingly, even this may not be a real limitation. The problem is that it isn't clear exactly what it means to support "legacy authentication". For example, are we trying to support 1. "Password authentication" i.e. the use of existing passwords in a new context? or 2. Are we trying to support existing methods, e.g. MD-Challenge/CHAP? It seems that the main interest is *not* supporting legacy authentication methods. I believe that the issue is rather supporting legacy credentials, such as passwords or token cards. If so, it may be possible to keep the credentials as they are but replace the existing method with a modified one when running inside IKEv2. When running outside IKEv2 or other sort of "EAP tunnels", use the existing method as-is. There appears to be key generating variants available for many of the popular legacy credentials. For instance, the existing passwords for dial-in PPP MSCHAPv2 could be used as-is when running EAP MSCHAPv2, which can generate keys. So, what does the WG want to do: 1) Allow the non-kg methods as is. Mitm possible. This is the current approach. 2) Disallow non-kg methods. May limit usability of IKEv2 EAP support. (But note that today there exists also a number of EAP methods that *do* generate keys; CHAP passwords for dial-in might not be possible to reuse but e.g. cell phone sim cards could still be.) 3) Disallow non-kg methods, but provide a set of key generating replacement methods for the commonly used non-kg methods. See also http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20123 --Jari From owner-ipsec@lists.tislabs.com Wed May 7 23:24:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h486OTi2027185; Wed, 7 May 2003 23:24:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17009 Thu, 8 May 2003 02:01:06 -0400 (EDT) Date: Wed, 7 May 2003 22:45:29 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: radia.perlman@sun.com, Hannes Tschofenig , ipsec@lists.tislabs.com Subject: Re: EAP Handling in IKEv2 In-Reply-To: <3EB9E73B.80100@kolumbus.fi> Message-ID: References: <200305080316.h483GF415582@sydney.East.Sun.COM> <3EB9E73B.80100@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It seems that the main interest is *not* supporting legacy > authentication methods. I believe that the issue is rather > supporting legacy credentials, such as passwords or token cards. Exactly. Since virtually every RADIUS server (including FreeRADIUS) already supports EAP, the issue is support for legacy credentials rather than legacy algorithms -- since EAP support allows algorithms to be easily changed. I'd also note that in both the "password" and "token card" categories, key generating methods exist -- although there are some token cards that do not support key generation. > If so, it may be possible to keep the credentials as they are but > replace the existing method with a modified one when running inside IKEv2. > When running outside IKEv2 or other sort of "EAP tunnels", use the existing > method as-is. Yes, this "modified method" approach is one of the proposals for dealing with non-key generating methods. From owner-ipsec@lists.tislabs.com Thu May 8 07:58:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48EwSi2077733; Thu, 8 May 2003 07:58:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19094 Thu, 8 May 2003 10:25:01 -0400 (EDT) Message-Id: <200305080938.FAA17804@lists.tislabs.com> From: "=?GB2312?Q?=C2=ED=D4=C6=DD=BA?=" To: "ipsec@lists.tislabs.com" Subject: How to support vendor in dpd? X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Thu, 8 May 2003 17:42:2 +0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, According to draft-ietf-ipsec-dpd-02.txt, the vendor ID describe here is "HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1,0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}". But cisco router changes vendor id every time. Why? From owner-ipsec@lists.tislabs.com Thu May 8 09:20:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48GK1i2082343; Thu, 8 May 2003 09:20:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19282 Thu, 8 May 2003 11:44:21 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Rekeying in IKEv2: optional or mandatory? To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Wed, 7 May 2003 22:37:14 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/08/2003 11:47:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi again. In section 2.8 of draft -07, it talks about MUSTs and > SHOULDs in rekeying. However, later in the document it says that > the ability to rekey is optional. This is pretty confusing. > > Personally, I think that rekeying should be optional, but it is > clear that folks haven't read this too carefully and this needs > to be cleared up before we finish. This was my error. My intent was that a minimal implementation need not support the CREATE_CHILD_SA exchange at all. That the initial exchange sets up an IKE SA and an ESP SA and that the only thing the IKE SA can subsequently be used for is keepalives. In that case, if either SA expires (based on time or data), the end discovering the expiration closes the IKE SA and starts over. This behavior is less efficient, but easier to code and debug (it has fewer states in its state machine). In most places, the language of the draft makes clear that this behavior is allowable, but I missed it in 2.8, making the document internally inconsistent. Would anyone object to my adding it? --Charlie From owner-ipsec@lists.tislabs.com Thu May 8 09:23:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48GN1i2082915; Thu, 8 May 2003 09:23:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19281 Thu, 8 May 2003 11:44:21 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Vendor IDs and reserved values To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Wed, 7 May 2003 22:39:50 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/08/2003 11:47:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi again. Section 3.12 says: >> If parameter values "reserved for use by consenting parties" are >> used, they must be preceded by a Vendor ID payload that disambiguates >> them. > This will hinder interoperability. Given that Vendor IDs are also > "reserved for use by consenting parties", this requirement doesn't > make sense. A private value is a private value: the two sides have > already agreed to what it means. Sending a private Vendor ID doesn't > add any information, and is another place where a failure can happen. > This sentence should be removed. I agree. Any objections? --charlie From owner-ipsec@lists.tislabs.com Fri May 9 07:56:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h49EuTi2067650; Fri, 9 May 2003 07:56:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22750 Fri, 9 May 2003 10:16:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Question about DPD Date: Fri, 9 May 2003 10:25:18 -0400 Message-ID: <84F76C427247FF4D873B1C39CDBA85520A9179@BATMAN.cryptek.net> Thread-Topic: Question about DPD Thread-Index: AcMWNsq+wurDyV6KTZ2z6AwphL6fOw== From: "Hu, Shicai" To: Cc: "Geoffrey Huang" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA22747 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just read the ID http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dpd-02.txt I am not sure that the IV used for Dpd exchange should be the phase I's IV or phase II's IV? And this IV should be updated every time a DPD exch sent? From owner-ipsec@lists.tislabs.com Fri May 9 14:48:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h49LmVi2089561; Fri, 9 May 2003 14:48:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23783 Fri, 9 May 2003 17:08:40 -0400 (EDT) Message-Id: <5.2.0.9.2.20030509171300.038cf0e8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 09 May 2003 17:13:41 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: IKEv2-07 Comment on Signature Usage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IKEv2-07 says: Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload. The signature or MAC will be computed using algorithms dictated by the type of key used by the signer, an RSA-signed PKCS1-padded-hash for an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital ... Unfortunately, this does not really work. Consider a certificate with an RSA public key. The subject public key info contains the rsaEncryption algorithm identifier. This public key can be used to validate signatures generated with PKCS #1 version 1.5 or PSS. And, each of these signature algorithms can be used with many different one-way hash functions. A signature value needs to be coupled with an algorithm identifier. Russ From owner-ipsec@lists.tislabs.com Fri May 9 20:01:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4A31Ai2097090; Fri, 9 May 2003 20:01:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24647 Fri, 9 May 2003 22:26:39 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <5.2.0.9.2.20030509171300.038cf0e8@mail.binhost.com> Subject: Re: IKEv2-07 Comment on Signature Usage To: Russ Housley Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Fri, 9 May 2003 21:49:08 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/09/2003 10:32:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ Housley wrote on 05/09/2003 05:13:41 PM: > IKEv2-07 says: > > Optionally, messages 3 and 4 MAY include a certificate, or > certificate chain providing evidence that the key used to compute a > digital signature belongs to the name in the ID payload. The > signature or MAC will be computed using algorithms dictated by the > type of key used by the signer, an RSA-signed PKCS1-padded-hash for > an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital > ... > > Unfortunately, this does not really work. Consider a certificate with an > RSA public key. The subject public key info contains the rsaEncryption > algorithm identifier. This public key can be used to validate signatures > generated with PKCS #1 version 1.5 or PSS. And, each of these signature > algorithms can be used with many different one-way hash functions. > > A signature value needs to be coupled with an algorithm identifier. > > Russ > I agree. There is a one byte field in the AUTH payload called Auth Method that could be used to specify the algorithm. Currently, it has three defined values: 1=RSA signature formatted using PKCS#1; 2=PRF computed using the shared key; and 3=DSS signature currently specified as "using a DSS private key over a SHA-1 hash" (I believe the DSS signature standard (unlike RSA) specifies the padding and the use of a SHA-1 hash). If I changed the wording of the text you quoted to list those as examples rather than mandates with a pointer to section 3.8, and changed section 3.8 to specify that in the future new codes could be assigned to existing key types, would that satisfy your concern? Related issues: should these algorithms be listed in the algorithms spec instead of or in addition to this one, and should we define a code for PSS signatures now or should it wait? (And is there an RFC to reference?). --Charlie From owner-ipsec@lists.tislabs.com Fri May 9 21:37:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4A4bci2098594; Fri, 9 May 2003 21:37:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24893 Sat, 10 May 2003 00:13:21 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Terminology question: "suites" vs "set of cryptographic algorithms" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Fri, 9 May 2003 23:33:11 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/10/2003 12:19:22 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote on 05/02/2003 07:40:30 PM: > The term "suite" is used inconsistently in the current document. In > some places, it means "the set of things chosen by the responder". > However, there are exceptions. I have listed what I think are the > main problems with the term "suite" in the current draft. > I've tried to use it to mean "a collection of algorithms used together in an SA". The initiator proposes multiple suites (not as a list, but as a Chinese menu (I hope that term has not become politically incorrect)), and the responder selects one. To clarify this, I changed the third paragraph of IKE Protocol Overview to the following: IKE performs mutual authentication between two parties and establishes an IKE security association that includes shared secret information that can be used to efficiently establish SAs for ESP [RFC2406] and/or AH [RFC2402] and a set of cryptographic algorithms to be used to protect the SAs. In this document, the term "suite" or "cryptographic suite" refers to a complete set of algorithms used to protect an SA. An initiator proposes one or more suites by listing supported algorithms that can be combined into suites in a mix and match fashion. IKE can also negotiate use of IPcomp [RFC2393] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get set up through that IKE_SA we call "CHILD_SA"s. Does that help? > The third paragraph of 2.7 says: > This hierarchical structure was designed to be able to efficiently > encode proposals for cryptographic suites when the number of > supported suites is large because multiple values are acceptable for > multiple transforms. The responder MUST choose a single suite, which > MAY be any subset of the SA proposal following the rules below: > This use of "suites" is talking about the proposals offered by the > initiator, which is the "old" use of suites. > This seems clear to me. Do you have an alternate wording to propose? > The last sentence in 2.7 says: > Alice MUST again propose her full > set of acceptable cryptographic suites because the rejection message > was unauthenticated and otherwise an active attacker could trick > Alice and Bob into negotiating a weaker suite than a stronger one > that they both prefer. > But Alice isn't proposing suites, she is proposing individual algorithms. > > In 3.10.1 it says: > NO_PROPOSAL_CHOSEN 14 > None of the proposed crypto suites was acceptable. > But no suites were proposed: algorithm choices were proposed. > Likewise, these seem clear to me; do you have an alternate wording. > Section 6: > Values of the Cryptographic Suite-ID define a set of cryptographic > algorithms to be used in an IKE, ESP, or AH SA. > We removed Suite-ID completely. > You're right on this one. It's an obsolete reference. I removed it. > Appedix B: > Future IANA-registered and private use Suite-IDs MAY use Diffie- > Hellman groups that have modulus values and generators that are > different than those in this document or in [ADDGROUP]. > Ditto. > This is also obsolete, and I removed it. Was there ever a declared consensus on whether the algorithm definitions (including all of Appendix B) should be removed so as not to duplicate information in the algorithms document? Barbara? Ted? > --Paul Hoffman, Director > --VPN Consortium --Charlie From owner-ipsec@lists.tislabs.com Sat May 10 09:30:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4AGUZi2060861; Sat, 10 May 2003 09:30:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26455 Sat, 10 May 2003 11:49:55 -0400 (EDT) From: "Subrata Goswami" To: "'IPsec WG'" Subject: ESP in Link Layers Date: Sat, 10 May 2003 08:52:25 -0700 Message-ID: <009801c3170c$420a3f00$0400a8c0@SGOSWAMIPCL> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b3ee6afaaf182b775d50c08c50a15948f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have submitted a new draft for using ESP in non-IP layers. The new Internet-Draft version is available from the on-line Internet-Drafts directories. Title : Encapsulating Security Payload for Link Layers (ESPLL) Author(s) : Subrata Goswami Filename : draft-goswami-ipsec-espll-00.txt http://ietfreport.isoc.org/ids/draft-goswami-ipsec-espll-00.txt Pages : 10 Date : 04-may-03 The trend has been to use different encryption mechanism for different layers. Although it can be argued that encryption in multiple layers is good protection, such an approach is highly inefficient from the point of view of performance and necessity. In some situations this kind of separate encryption mechanism may afford the bytes 7 levels of encryption, for example : AES (from 802.11)+ 3DES (from IPSec) + 3DES (from TLS/SSL). Recently link layer encryption has become an important issue, specially in the context of wireless networks. Although this document does not attempt to solve this multiple layer encryption issue, it is an effort to that goal. Specifically, this document describes a way to use ESP in several link layer technologies. From owner-ipsec@lists.tislabs.com Sat May 10 09:30:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4AGUXi2060860; Sat, 10 May 2003 09:30:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26462 Sat, 10 May 2003 11:56:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sat, 10 May 2003 09:01:45 -0700 To: Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: Re: Terminology question: "suites" vs "set of cryptographic algorithms" Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:33 PM -0400 5/9/03, Charlie_Kaufman@notesdev.ibm.com wrote: >Paul Hoffman / VPNC wrote on 05/02/2003 07:40:30 >PM: >> The term "suite" is used inconsistently in the current document. In >> some places, it means "the set of things chosen by the responder". >> However, there are exceptions. I have listed what I think are the >> main problems with the term "suite" in the current draft. >> >I've tried to use it to mean "a collection of algorithms used together >in an SA". The initiator proposes multiple suites (not as a list, but >as a Chinese menu (I hope that term has not become politically >incorrect)), and the responder selects one. > >To clarify this, I changed the third paragraph of IKE Protocol Overview to >the following: > >IKE performs mutual authentication between two parties and establishes >an IKE security association that includes shared secret information >that can be used >to efficiently establish SAs for ESP [RFC2406] and/or AH [RFC2402] and >a set of cryptographic algorithms to be used to protect the SAs. >In this document, the term "suite" or "cryptographic suite" refers to >a complete set of algorithms used to protect an SA. An initiator >proposes one or more suites by listing supported algorithms that can >be combined into suites in a mix and match fashion. >IKE can also negotiate use of IPcomp >[RFC2393] in connection with an ESP and/or AH SA. >We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH >that get set up through that IKE_SA we call "CHILD_SA"s. > >Does that help? Yes, definitely. It encompasses both the proposal and the result. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat May 10 16:41:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4ANfLi2070830; Sat, 10 May 2003 16:41:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27396 Sat, 10 May 2003 19:13:00 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: EAP Handling in IKEv2 To: Bernard Aboba Cc: Hannes Tschofenig , ipsec@lists.tislabs.com, Jari Arkko , owner-ipsec@lists.tislabs.com, radia.perlman@sun.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Sat, 10 May 2003 18:46:57 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/10/2003 07:18:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bernard Aboba wrote: > > If so, it may be possible to keep the credentials as they are but > > replace the existing method with a modified one when running inside IKEv2. > > When running outside IKEv2 or other sort of "EAP tunnels", use the existing > > method as-is. > > Yes, this "modified method" approach is one of the proposals for dealing > with non-key generating methods. Uhhh... have I missed something? Where is this proposal? Since IKE does a Diffie-Hellman exchange, it will have keying material whether EAP generates a key or not. Using the EAP key protects against MITM attacks. If there is no EAP key, then I believe there can be no protection for MITM attacks (as Radia noted). So what did you have in mind? --Charlie From owner-ipsec@lists.tislabs.com Sat May 10 16:41:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4ANfLi2070828; Sat, 10 May 2003 16:41:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27388 Sat, 10 May 2003 19:11:58 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: EAP Handling in IKEv2 To: "Hannes Tschofenig" , X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Sat, 10 May 2003 18:23:34 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/10/2003 07:18:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hannes Tschofenig" wrote: >in Section 2.16 you mention the mechanism for protecting against >man-in-the-middle attacks: > >" For EAP methods that create a shared key as a side effect of >authentication, that shared key MUST be used by both the Initiator >and Responder to generate an AUTH payload using the syntax for shared >secrets specified in section 2.15. This shared key MUST NOT be used >for any other purpose." > >This covers the case where the EAP method establishes a session key. > >Which procedure do you suggest for cases where EAP methods do not create a >session key such as the One-Time Password (OTP)? For EAP methods that don't generate session keys, the AUTH payloads are not sent. I'll make that clearer in the spec. --Charlie From owner-ipsec@lists.tislabs.com Sat May 10 16:41:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4ANfLi2070829; Sat, 10 May 2003 16:41:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27395 Sat, 10 May 2003 19:13:00 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3EB9E73B.80100@kolumbus.fi> Subject: Re: EAP Handling in IKEv2 To: Jari Arkko Cc: Bernard Aboba , Hannes Tschofenig , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, radia.perlman@sun.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Sat, 10 May 2003 18:41:24 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/10/2003 07:18:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari Arkko wrote: > It seems that the main interest is *not* supporting legacy > authentication methods. I believe that the issue is rather > supporting legacy credentials, such as passwords or token cards. > > If so, it may be possible to keep the credentials as they are but > replace the existing method with a modified one when running inside IKEv2. > When running outside IKEv2 or other sort of "EAP tunnels", use the existing > method as-is. > > There appears to be key generating variants available for many of the > popular legacy credentials. For instance, the existing passwords for > dial-in PPP MSCHAPv2 could be used as-is when running EAP MSCHAPv2, > which can generate keys. I'm confused. I did not mean to imply that if EAP is used with IKE then the same EAP credentials could not be used with other protocols. That would be nice from a security perspective, but would be impossible to enforce and not practical. What the text says is that if the EAP method generates a shared session key as a side effect of authentication, then that session key for that authentication must not be used outside the context of IKE. This seems much less restrictive. I'm assuming (perhaps naively) that if EAP produces a shared session key as a side effect of authentication, then it will produce a different one on each run of the protocol. For interoperability, it would be good to specify recommended EAP algorithms, probably in the algorithms document. Do people know what algorithms we're expecting to see? --Charlie Kaufman From owner-ipsec@lists.tislabs.com Sun May 11 00:12:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4B7CUi2092295; Sun, 11 May 2003 00:12:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA28409 Sun, 11 May 2003 02:38:47 -0400 (EDT) From: "Yoav Nir" To: Cc: , Subject: RE: EAP Handling in IKEv2 Date: Sun, 11 May 2003 09:41:11 +0200 Message-ID: <003901c31790$b1c764b0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Several legacy authentication schemes involve some secret (or password) shared between the user and a backend authentication server, such as RADIUS. The "authenticator" or PPP server or access concentrator or LNS or whatever it's called acts as a passthrough for the authentication, and does not ever see the password. While this is very attractive from a security POV, this has the limitation that the authentication algorithm must be shared between the client and the backend. This is not always practical, because we're talking about old authentication backends that may not support EAP. In fact, there are plenty of RADIUS servers out there that do not support EAP. IMO there are two EAP algorithms that should be recommended: 6 - Generic Token Card 29 - EAP-MSCHAP-V2 The former simply passes to the user a string such as "What is your password?" and receives the password in the "clear". This allows the AC to support any legacy backend server that we wish, since the AC has the real password and can do whatever hashing is required. The latter also works for user/password schemes and has the advantage of generating a session key. It does require the backend server to support EAP-MSCHAP-V2, but I suppose this support is coming. -----Original Message----- From: Charlie_Kaufman@notesdev.ibm.com Sent: Sunday, May 11, 2003 12:41 AM Subject: Re: EAP Handling in IKEv2 > For interoperability, it would be good to specify recommended EAP > algorithms, probably in the algorithms document. Do people know what > algorithms we're expecting to see? > > --Charlie Kaufman From owner-ipsec@lists.tislabs.com Sun May 11 00:53:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4B7rDi2097224; Sun, 11 May 2003 00:53:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA28540 Sun, 11 May 2003 03:29:41 -0400 (EDT) Message-ID: <3EBDFC91.3020806@kolumbus.fi> Date: Sun, 11 May 2003 10:32:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com Cc: Bernard Aboba , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, radia.perlman@sun.com Subject: Re: EAP Handling in IKEv2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com wrote: > Uhhh... have I missed something? Where is this proposal? Since IKE does a > Diffie-Hellman exchange, it will have keying material whether EAP generates > a key or not. Using the EAP key protects against MITM attacks. If there is > no EAP key, then I believe there can be no protection for MITM attacks (as > Radia noted). So what did you have in mind? We are quite happy with the IKEv2 specification as far as the key-generating EAP methods are used. Then everything is fine. The discussion is about what to do with non-key-generating methods. The approach chosen in current IKEv2 draft is that such methods are allowed. As is generally known, this results in a MitM attack vulnerability. We do agree that for non-kg methods there can be no MitM attack protection. However, we question a bit the need to support such *methods*. We do see a need to support the *credentials* that are currently used by non-kg methods, such as CHAP in PPP or EAP-MD5 in EAP. That is, the legacy support we see as necessary is keeping the currently deployed credentials. However, this does not imply that we have to use the deployed methods. The same credentials could be used by newer, updated methods that do generate keys as well. So, we see two potential approaches here: 1. Allow non-kg methods. 2. Disallow non-kg methods, but use the same credentials with existing or new methods that do produce keys. Either way, the corporate network manager with a RADIUS database for dial-in can use the same database for IKEv2. And publication of IKEv2 can be done in about the same time either way. Both approaches require implementation work in clients and VPN gateways, because IKEv2 is new. However, the approaches differ in the following respects: - Approach 1 has a MitM vulnerability. - Approach 2 may require work to develop kg EAP methods to correspond to existing non-kg methods. This does not need to be done within IKEv2 document, however. And a number of such methods appear to exist already, so its not clear to me how much new work, if any is needed. Bernard, did you have a list of old => new methods? - In approach 2, the final home RADIUS server needs to support the kg methods. (Like in the case of the method development, they may already do this.) In conclusion this appears to be a choice where we can in any case reuse existing corporate investments and require no new effort for credential deployment, and publish IKEv2 document timely. The differences are security vs. possibly some work in finding or developing kg methods. Does this clarify the issue? How do you see the tradeoffs and what do you want to do? --Jari From owner-ipsec@lists.tislabs.com Sun May 11 01:40:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4B8e9i2006278; Sun, 11 May 2003 01:40:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA28657 Sun, 11 May 2003 04:08:25 -0400 (EDT) From: "Yoav Nir" To: "'Jari Arkko'" Cc: , Subject: RE: EAP Handling in IKEv2 Date: Sun, 11 May 2003 11:11:24 +0200 Message-ID: <003c01c3179d$4c182160$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EBDFC91.3020806@kolumbus.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While there seems to be a consensus that kg methods are preferrable, I don't believe that we can disallow non-kg methods. There simply are too many authentication schemes and servers out there for us to mandate throwing them all away. The MitM vulnerability should be mentioned and kg methods should be recommended over non-kg methods, but disallowing them will lead to non-adoption of IKEv2. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jari Arkko Sent: Sunday, May 11, 2003 9:33 AM To: Charlie_Kaufman@notesdev.ibm.com Cc: Bernard Aboba; ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com; radia.perlman@sun.com Subject: Re: EAP Handling in IKEv2 Charlie_Kaufman@notesdev.ibm.com wrote: > Uhhh... have I missed something? Where is this proposal? Since IKE does a > Diffie-Hellman exchange, it will have keying material whether EAP generates > a key or not. Using the EAP key protects against MITM attacks. If there is > no EAP key, then I believe there can be no protection for MITM attacks (as > Radia noted). So what did you have in mind? We are quite happy with the IKEv2 specification as far as the key-generating EAP methods are used. Then everything is fine. The discussion is about what to do with non-key-generating methods. The approach chosen in current IKEv2 draft is that such methods are allowed. As is generally known, this results in a MitM attack vulnerability. We do agree that for non-kg methods there can be no MitM attack protection. However, we question a bit the need to support such *methods*. We do see a need to support the *credentials* that are currently used by non-kg methods, such as CHAP in PPP or EAP-MD5 in EAP. That is, the legacy support we see as necessary is keeping the currently deployed credentials. However, this does not imply that we have to use the deployed methods. The same credentials could be used by newer, updated methods that do generate keys as well. So, we see two potential approaches here: 1. Allow non-kg methods. 2. Disallow non-kg methods, but use the same credentials with existing or new methods that do produce keys. Either way, the corporate network manager with a RADIUS database for dial-in can use the same database for IKEv2. And publication of IKEv2 can be done in about the same time either way. Both approaches require implementation work in clients and VPN gateways, because IKEv2 is new. However, the approaches differ in the following respects: - Approach 1 has a MitM vulnerability. - Approach 2 may require work to develop kg EAP methods to correspond to existing non-kg methods. This does not need to be done within IKEv2 document, however. And a number of such methods appear to exist already, so its not clear to me how much new work, if any is needed. Bernard, did you have a list of old => new methods? - In approach 2, the final home RADIUS server needs to support the kg methods. (Like in the case of the method development, they may already do this.) In conclusion this appears to be a choice where we can in any case reuse existing corporate investments and require no new effort for credential deployment, and publish IKEv2 document timely. The differences are security vs. possibly some work in finding or developing kg methods. Does this clarify the issue? How do you see the tradeoffs and what do you want to do? --Jari From owner-ipsec@lists.tislabs.com Sun May 11 04:53:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4BBroi2019138; Sun, 11 May 2003 04:53:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29072 Sun, 11 May 2003 07:18:46 -0400 (EDT) Message-ID: <3EBE3242.5020306@kolumbus.fi> Date: Sun, 11 May 2003 14:21:38 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: EAP Handling in IKEv2 References: <003c01c3179d$4c182160$292e1dc2@YnirNew> In-Reply-To: <003c01c3179d$4c182160$292e1dc2@YnirNew> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: > While there seems to be a consensus that kg methods are preferrable, I don't > believe that we can disallow non-kg methods. There simply are too many > authentication schemes and servers out there for us to mandate throwing them > all away. The MitM vulnerability should be mentioned and kg methods should > be recommended over non-kg methods, but disallowing them will lead to > non-adoption of IKEv2. Well, I think we have discussed in the past throwing out old legacy methods, and found that it was clearly not possible. However, the input we're trying to give now is that there may be a significant difference with respect to throwing out credentials, and throwing out methods. I agree that credentials should not be thrown away. The replacement of non-kg methods with kg-methods appears easier though for the following reasons: - Existing credentials can be used. - All EAP intermediaries (such as AAA proxies or maybe the VPN gateway) need no modifications. - Clients have to be modified anyway for the introduction of IKEv2, so an update of a new auth method code at the same time does not appear to be technically infeasible. - There already exists methods for this purpose, e.g. MS-CHAP can be replaced with EAP MS-CHAPv2 which does generate keys. We do need the final AAA server to support the kg method, and we for every non-kg method we need a corresponding kg method. I wish I could say something definite about the likelihood of the availability of this. But I don't agree that this means throwing out authentication servers. EAP support on a server seems a fairly reasonable requirement these days (for wireless LANs etc), so in the worst case the server needs an update to support a new method. Perhaps we should also develop a list of common authentication methods, to see how large fraction of them has corresponding kg methods. Does anyone who "owns" a particular method want to step out and say that they don't have or can't produce a kg variant? --Jari From owner-ipsec@lists.tislabs.com Sun May 11 05:15:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4BCFCi2022562; Sun, 11 May 2003 05:15:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29174 Sun, 11 May 2003 07:45:39 -0400 (EDT) From: "Yoav Nir" To: "'Jari Arkko'" Cc: , Subject: RE: EAP Handling in IKEv2 Date: Sun, 11 May 2003 14:48:28 +0200 Message-ID: <004e01c317bb$a35f2270$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EBE3242.5020306@kolumbus.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As far as possible, we'd like to have simple clients - we don't want to have an IKE client that supports every conceivable EAP method. The smarts should be at the server. Ideally, the client would pass all credentials to the VPN server. The server would then be able to work with whatever authentication method the backend server supports. The problem with all the kg methods that I know of (such as TLS or MS-CHAPv2) is that the gateway is oblivious to the credentials passed, so the client has to be able to work with the method. MS-CHAPv2 is a good method for all user/password methods including token cards, one-time passwords and lots of others, but it requires all backend servers to support this protocol. This is not the case at this time. We've been asked to support everything from private fields in LDAP servers, Unix and NT passwords to RACF databases, VM/ESA directories and various TOD based algorithms. It is naive to expect all these things to support MS-CHAPv2. Unfortunately, I don't know of any EAP method that generates a key, but gives the password to the authenticator. If there was, then this would be the recommended EAP method IMO. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Sunday, May 11, 2003 1:22 PM To: Yoav Nir Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com Subject: Re: EAP Handling in IKEv2 Yoav Nir wrote: > While there seems to be a consensus that kg methods are preferrable, I don't > believe that we can disallow non-kg methods. There simply are too many > authentication schemes and servers out there for us to mandate throwing them > all away. The MitM vulnerability should be mentioned and kg methods should > be recommended over non-kg methods, but disallowing them will lead to > non-adoption of IKEv2. Well, I think we have discussed in the past throwing out old legacy methods, and found that it was clearly not possible. However, the input we're trying to give now is that there may be a significant difference with respect to throwing out credentials, and throwing out methods. I agree that credentials should not be thrown away. The replacement of non-kg methods with kg-methods appears easier though for the following reasons: - Existing credentials can be used. - All EAP intermediaries (such as AAA proxies or maybe the VPN gateway) need no modifications. - Clients have to be modified anyway for the introduction of IKEv2, so an update of a new auth method code at the same time does not appear to be technically infeasible. - There already exists methods for this purpose, e.g. MS-CHAP can be replaced with EAP MS-CHAPv2 which does generate keys. We do need the final AAA server to support the kg method, and we for every non-kg method we need a corresponding kg method. I wish I could say something definite about the likelihood of the availability of this. But I don't agree that this means throwing out authentication servers. EAP support on a server seems a fairly reasonable requirement these days (for wireless LANs etc), so in the worst case the server needs an update to support a new method. Perhaps we should also develop a list of common authentication methods, to see how large fraction of them has corresponding kg methods. Does anyone who "owns" a particular method want to step out and say that they don't have or can't produce a kg variant? --Jari From owner-ipsec@lists.tislabs.com Sun May 11 06:22:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4BDMSi2027582; Sun, 11 May 2003 06:22:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29390 Sun, 11 May 2003 08:45:28 -0400 (EDT) Date: Sun, 11 May 2003 05:27:52 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, radia.perlman@sun.com Subject: Re: EAP Handling in IKEv2 In-Reply-To: <3EBDFC91.3020806@kolumbus.fi> Message-ID: References: <3EBDFC91.3020806@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Bernard, did you have a list of old => new methods? Here's a small list: EAP MD5 => EAP MS-CHAP-V2 or EAP-ARCHIE GTC => EAP SECURID From owner-ipsec@lists.tislabs.com Sun May 11 07:31:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4BEVZi2030642; Sun, 11 May 2003 07:31:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29554 Sun, 11 May 2003 09:53:06 -0400 (EDT) From: "Yoav Nir" To: "'Bernard Aboba'" , "'Jari Arkko'" Cc: , Subject: RE: EAP Handling in IKEv2 Date: Sun, 11 May 2003 16:56:57 +0200 Message-ID: <005b01c317cd$921a2f70$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I must have missed something here. How does EAP SECURID generage keys? Has it been developed since http://www.drizzle.com/~aboba/IEEE/draft-josefsson-eap-securid-01.txt ? -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Bernard Aboba Sent: Sunday, May 11, 2003 2:28 PM To: Jari Arkko Cc: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com; radia.perlman@sun.com Subject: Re: EAP Handling in IKEv2 > Bernard, did you have a list of old => new methods? Here's a small list: EAP MD5 => EAP MS-CHAP-V2 or EAP-ARCHIE GTC => EAP SECURID From owner-ipsec@lists.tislabs.com Sun May 11 19:54:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4C2sDi2053369; Sun, 11 May 2003 19:54:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01378 Sun, 11 May 2003 22:18:40 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200304251940.h3PJes820577@yogi> Subject: Re: IKEV2 - INVALID_KE_PAYLOAD not defined To: "Stephen C. Koehler" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Sat, 10 May 2003 21:28:59 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/11/2003 10:24:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Stephen C. Koehler" wrote on 04/25/2003: > > I noticed that draft 7 refers to INVALID_KE_PAYLOAD (e.g., in section 2.6), > but this notify message is not defined in the section on the notify payload. > Fixed. > Procedural question: is it better to post minor issues, like this, > to the list, > or should these go directly to the editor? > Post them if there is any chance of controversy. Probably wasn't necessary here. (Does someone out there want to prove me wrong?) --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Sun May 11 19:54:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4C2sHi2053381; Sun, 11 May 2003 19:54:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01381 Sun, 11 May 2003 22:18:44 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66CDA@SARATOGA.netscreen.com> Subject: RE: Peer liveliness To: Gregory Lebovitz Cc: "'ddukes@cisco.com'" , ipsec@lists.tislabs.com, Michael Choung Shieh , owner-ipsec@lists.tislabs.com, Ravi X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Sat, 10 May 2003 22:36:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04292003NP|April 29, 2003) at 05/11/2003 10:24:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe that the current IKEv2 spec addresses this issue in a way that puts minimal requirements on implementations, guarantees interoperability (though with less than ideal convergence time), and allows implementations to do better. But it's quite possible that I don't understand all of the things that could go wrong, or have inadequately expressed what implementations MUST do, or just plain screwed up. The implementation requirements for robust interoperability are: (1) An IKE SA and all of its associated child SAs fail together. You aren't allowed a "partial crash" where some of the state is lost but some is kept. This will fall out naturally in most implementations, but may require some modular designs to have different modules poll one another for liveness. (2) A node may not send on a set of SAs associated with a single IKE SA indefinitely without hearing something back. If it hears nothing for long enough, it should send an IKE message requiring a reply, and if no reply comes it must declare all of the SAs dead. (3) A node that has packets to send according to its SPD and no SA to send them on must periodically attempt to open an SA for them. I believe these three requirements along guarantee that the right thing will happen eventually. But it doesn't prescribe what the timers should be. So it's possible it will take unacceptably long for things to converge. (If network delays are long enough and timeouts short enough, the system could fail to work at all, but I believe that problem is unavoidable). The problem with more sophisticated strategies is that they may be exploitable for denial of service attacks. Anyone can forge an INVALID_SPI notification message from an IP address of their choice (since such a message is not cryptographically protected). If such a message were sufficient to cause its recipient to shut down and restart the SA, it would be a very effective attack. So the spec says that such a message may be used only as a hint to a problem - for example to trigger a cryptographically protected liveness test. This will cause the failure to be detected more quickly, but will never cause one to be detected falsely. Similarly, the INITIAL_CONTACT notification can be used when setting up an SA to assure the other end that it should abandon any SAs it has open to the same identity. This is useful in - for example - the firewall case where an identity is tied to a single box and it would be an error for that box to bring up two connections at once. It would not be useful in the case of a user who is allowed to remotely log in from multiple workstations at the same time. Again, this makes convergence happen faster while never making the wrong thing happen. Responding to the individual comments below... Gregory Lebovitz wrote on 04/29/2003: > > [WE] won't achieve interoperability unless it's mandated that > [IMPLEMENTORS] must > > reply INVALID_SPI (in clear or initiate IKE back to the > > sender) whenever it > > receives bad spi packets. Current IKEv2 draft doesn't > > address this issue > > (only states you MAY reply a clear notify message). > > > > IKEv1 vendors has implemented many ways to solve it which leave poor > > interoperability. We should just pick a method and clarify > > it in IKEv2. > > =============== > > Michael Shieh > > I think we did, but if you don't think it works, explain why. > > We have been having quite a debate in the ICSA IPsec consortium mail list > recently trying to figure out how to handle this in IKEv1 (YES, STILL!!!) > > Here is what we know for sure of this problem statement: > (a) detecting liveness/deadness of peer is a good thing, but does not solve > all the failure cases in and of itself Which ones does it not solve? > (b) the behavior of a recently rebooted device when it receives an > encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated, or > else implementations will not interoperate (as is the case in IKEv1, 5 years > later). Can you give an example of how two implementations following IKEv2 could fail to interoperate? > (c) the behavior of a peer that receives a new IKE from a peer that it has > an existing IKE-SA with (i.e. the rebooted peer that is trying to initiate a > new connection) MUST be mandated, or else implementations will not > interoperate (as is the case in IKEv1, 5 years later). I believe it is mandated that the new IKE-SA must be accepted, and the old one either closed immediately or closed after a timeout, though perhaps that's just what I was thinking and not what I wrote. Is there anything specific you would recommend? > > Darren Dukes wrote: > > I believe INVALID_SPI does what you are looking for. If I receive an > > INVALID_SPI notify via an IKE SA I know to delete the SA and > > traffic will > > bring up a new one. > > I don't believe this will work, since it assumes that an IKE SA is > established. In the scenario, the IKE-SA would have been lost along with the > SPI of the CHILD-SA by the rebooted peer. > Until a new IKE-SA is established, any INVALID_SPI message would be cryptographically unprotected and therefore not to be taken as other than a hint. If a new IKE-SA is established, the INVALID_SPI could be taken as trustworthy and used to abandon the old SA. Without the INVALID_SPI message, abandonment would still happen but it would take longer. > Recommendations to solve the solution: > - the empty notify as an aliveness check is a good idea. It accomplishes > what the DPD draft did. Keep using this. > Generating them is not mandated, but the ability to respond to them is. > - do what you can to use empty notify to detect dead peer ASAP. The faster > the persisting peer can delete the old SPI and IKE-SA, the better. The best > case is for Persisting Peer to detect death and initiate new IKE to rebooted > peer before rebooted peer gets packets with old SPI, IKE-SA. > If the rebooted peer knows that the SA is needed, it can do that. If it sets them up based on traffic, it has to wait until a packet comes in from one side or the other. > - On the Rebooted peer side: If an implementation receives a protected > packet from an unkown SPI, > - simply relying on sending back an unprotected INVALID_SPI is not a good > idea. It is too easy to DoS the persisting peer by simply spoofing the > rebooted peer's address. > - initiate IKE to the persisting peer. This is allowed, although sending what looks like protected messages from randomly chosen IP addresses to cause the node to attempt lots of IKE connections is also a plausible DOS attack. Sending the INVALID_SPI message will tell the other end to probe this end for liveness and initiate its own new IKE connection if that liveness test fails. That's the path guaranteed to work. Others will speed things up if implementations choose to do them. > > - On the Persisting Peer: > - If you get a new IKE request from a peer already in your SADB, respond > with the under-attack, 6 message method. This will mitigate the DoS attack. > If you get all the way through SA and TS negotiation successfully, you are > assured (unless I'm missing something) that this really is your peer, and > that he re-initiated because he lost the original IKE-SA. Start using the > new IKE-SA and the new CHILD-SA and delete the previous ones after some wait > period. > Only if there is an INITIAL_CONTACT notification message. Otherwise it's possible that the peer is opening multiple IKE SAs, perhaps because he is replicated. In some configurations this might be acceptable. In firewall to firewall tunnels, it would not and an implementation might reasonably treat any IKE-SA as an INITIAL_CONTACT. > Would this proposal explicitly solve things? > > Gregory. --Charlie From owner-ipsec@lists.tislabs.com Mon May 12 11:28:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CISVi2031620; Mon, 12 May 2003 11:28:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03645 Mon, 12 May 2003 13:48:11 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: Re: Crypto algorithms for IKEv2 Date: Mon, 12 May 2003 13:41:10 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 May 2003 17:41:10.0821 (UTC) FILETIME=[AD0CC550:01C318AD] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Come to think of it, I don't think we ever resolved the issue of what to >do > > when the initiator of a CREATE_CHILD_SA exchange doesn't propose PFS but >the > > responder requires it. This could be accomplished with a > > NOTIFY_PFS_REQUIRED_ALWAYS or NOTIFY_PFS_REQUIRED_NEXT_SA message. > > >My reading of the current specification is that if the initiator doesn't >propose PFS but the responder requires it, the proposal will be rejected >with a NO_PROPOSAL_CHOSEN notification, just as would any other time there >is no overlap between what the initiator proposes and what the responder is >prepared to accept. I guess the danger I was thinking of is that some people have been talking about PFS as a run-time parameter rather than a configuration parameter. I.e. you have a PFS interval for the original phase 1 key. Once that interval has elapsed, you delete SKEYSEED_D and require PFS for every subsequent CREATE_CHILD_SA (possibly reusing the exponent). The trouble is that when you receive a NO_PROPOSAL_CHOSEN message, this normally represents a configuration error (where the administrator has to check that both sides are using the same ciphersuites). Now we have a case where the NO_PROPOSAL_CHOSEN message could also occur for an already functioning SA. As I pointed out earlier, the UI suites in draft-hoffman-ipsec-algorithms-00.txt make no mention of PFS. So my guess is that half the implementations will have it on by default and half will have it off by default. This means that we either need a PFS on/off checkbox in the GUI (which defeats the purpose of a single configuration knob via UI suites) or we have to implement a routine to retry with PFS any time you receive a NO_PROPOSAL_CHOSEN message. I suspect that most people will choose the former. (God forbid that anyone actually attempts the strategy where you rekey without PFS for the first N minutes and then with PFS for the remainder of the SA lifetime.) Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From aamandajjel2oksw4@msn.com Mon May 12 12:30:21 2003 Received: from hotmail.com (bay3-dav128.bay3.hotmail.com [65.54.169.158]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CJULi2035358 for ; Mon, 12 May 2003 12:30:21 -0700 (PDT) (envelope-from aamandajjel2oksw4@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 May 2003 12:30:08 -0700 Received: from 211.21.68.30 by bay3-dav128.bay3.hotmail.com with DAV; Mon, 12 May 2003 10:56:47 +0000 X-Originating-IP: [211.21.68.30] X-Originating-Email: [aamandajjel2oksw4@msn.com] To: "Rolff Samuel" Subject: Save Thousands Of Dollars In Septic Tank Repairs From: "Stambach Perpall" X-Accept-Language: en X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-MSMail-Priority: Normal Content-Type: multipart/alternative; boundary="JAFDp5ccw8Y0d4pfkame5p108EaH168q7yUo7GKMbtaKH05i2P2F48CDslRBY62Y8H" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 12 May 2003 19:30:08.0710 (UTC) FILETIME=[E5EF7660:01C318BC] Date: 12 May 2003 12:30:08 -0700 --JAFDp5ccw8Y0d4pfkame5p108EaH168q7yUo7GKMbtaKH05i2P2F48CDslRBY62Y8H Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="ISO-8859-1"
Wonder what happens to a poorly maintained septic system?

Click here a FREE Trial of SPC Septic cleaner while supplies last!

And hopefully you won't have to!

With SPC you won't have to see what an improperly maintained septic systems can do!
Not only to your property, but your bank account!

Visit us now to see how we can protect your septic system

click and remove your email
--JAFDp5ccw8Y0d4pfkame5p108EaH168q7yUo7GKMbtaKH05i2P2F48CDslRBY62Y8H-- From owner-ipsec@lists.tislabs.com Mon May 12 12:30:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CJUNi2035367; Mon, 12 May 2003 12:30:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04064 Mon, 12 May 2003 14:55:57 -0400 (EDT) Date: Mon, 12 May 2003 22:01:13 +0300 (IDT) From: Hugo Krawczyk To: Bernard Aboba cc: Jari Arkko , IPsec WG Subject: Re: EAP Handling in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > If so, it may be possible to keep the credentials as they are but > > replace the existing method with a modified one when running inside IKEv2. > > When running outside IKEv2 or other sort of "EAP tunnels", use the existing > > method as-is. > > Yes, this "modified method" approach is one of the proposals for dealing > with non-key generating methods. > I like the distinction between reusing "legacy credentials" as opposed to reusing "legacy methods". However, this means that we are willing to *change* the authentication methods traditionally used by the "legacy credentials". If this is a practical approach (namely, it can gain widespread support in corporate organizations, etc) then the solution is very simple and does not require the design of key-generating methods. All is needed is that the modified methods authenticate the "context" in which they are run. Specifically, when run with ikev2 the authenticated information should include a unique "protocol identifier" (such as "ikev2", "rfc-xxxx", "port-yyy", etc). This is the simplest and least "intrusive" solution to the man in the middle problem while allowing use of the same credentials in different contexts. INPORTANT NOTE: Even in this case let's keep in mind that if the credential used under an EAP method in ikev2 has low entropy (such as a password) and is also used in another method that is vulnerable to off-line dictionary attacks then its use in ikev2 becomes insecure too. Hugo > From owner-ipsec@lists.tislabs.com Mon May 12 13:02:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CK2Ui2037867; Mon, 12 May 2003 13:02:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04189 Mon, 12 May 2003 15:38:19 -0400 (EDT) Date: Mon, 12 May 2003 12:22:24 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Hugo Krawczyk , IPsec WG Subject: Re: EAP Handling in IKEv2 In-Reply-To: <3EBFF722.7080306@kolumbus.fi> Message-ID: References: <3EBFF722.7080306@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > reusing "legacy methods". However, this means that we are willing to > > *change* the authentication methods traditionally used by the "legacy > > credentials". If this is a practical approach (namely, it can gain > > widespread support in corporate organizations, etc) then the solution is > > very simple and does not require the design of key-generating methods. > > All is needed is that the modified methods authenticate the "context" in > > which they are run. Specifically, when run with ikev2 the authenticated > > information should include a unique "protocol identifier" (such as > > "ikev2", "rfc-xxxx", "port-yyy", etc). This is the simplest and least > > "intrusive" solution to the man in the middle problem while allowing use > > of the same credentials in different contexts. > > Yes, this is also one of the proposed approaches for > dealing with MitM. I'd like to see this included in the EAP WG MiTM document :( Hugo -- can we prevail upon you to do a review of draft-puthenkulam-eap-binding-02.txt and post this and other relevant comments to the EAP WG mailing list? From owner-ipsec@lists.tislabs.com Mon May 12 13:04:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CK4Qi2037934; Mon, 12 May 2003 13:04:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04195 Mon, 12 May 2003 15:38:32 -0400 (EDT) Date: Mon, 12 May 2003 22:43:22 +0300 (IDT) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG Subject: Re: ikev2-07: last nits In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > (6) Page 81 Sec 5 (Security Considerations) > > > > Current text: The strength of all keys are limited by the size of the output > > of the negotiated prf function. For this reason, a prf function whose output > > is less than 128 bits (e.g. 3DES-CBC) MUST never be used with this protocol. > > > > Discussion: You may want to add that a prf that outputs less bits than its > > own key is also unsuited for use (even if its output is longer than 128 > bits). > > The reason for this is that SKEYSEED is produced by a (single) application > > of the prf and its length needs to be that of the prf key. > > > > Important: The above specifications on the usable prf's should go to the > > normative part of the document (sections 2.13 or 2.14) rather than in > these > > Security Considerations. I suggest to also add there that SKEYSEED is to > be at > > least of the length of a secure key for the negotiated prf (and if this > prf is > > of fixed-length key then SKEYSEED is to be of exactly this length). > > > I believe that the use of a prf other than HMAC (or at least not accepting > a variable length key) is dangerously poorly thought out, and my I do not think so. I believe that the interesting cases are well treated, if not at the outmost generality. It's true that HMAC has the nice property of taking care of variable lenth prf's but the problems raised by fixed-length prf's are not that significant and are dealt with satisfactorily in 07 (except for the above remark on |key| <= |block| and an additional remark that I have below). > inclination is to take out all references to it. Since it got added there > have been a series of problems (including the one earlier in this note). I > hadn't noticed - but you are certainly correct - that the spec assumes that > if the prf has a fixed length key that the key length is the same as the > output length. That allows AES128-CBC, but no others come to mind. First, AES128-CBC is THE fixed-key prf one would like to use in addition to HMAC, so it is not a worthless example (after all what you have in mind is yet another single prf instantiation, namely, HMAC-SHA1). Second, there are ways to deal with the case in which block length is shorter than the key size (as long as the block length is not too short as in the case of 3DES) but at this point this may add more complexity (or feelings of "not thought enough") than necessary, especially that at the end this will be used with AES128 anyway). > keep patching, but is this really a requirement? It was motivated by people > who were going to put AES in hardware and didn't want to have to implement > a digest function as well. I'll buy that for the fast path (packet > integrity checks), but do we really need to engineer for that case for the > performance-irrelevant key expansion case? If so, could someone make a more > specific suggestion as to how to fix this. I believe the text in 07 regarding fixed-length keys is good. It needs the addition that I noted in my prvious msg (point (6) above) and the following fix that I missed the previous time: In section 2.13 you write: When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula. This rule of padding with zeros is bad and, fortunately, unnecessary. In all places where a fixed-length key prf is allowed you already have specific language that tells you how to deal with this case and none of them requires such a padding. So I suggest that you remove the above text. Finally, I will take the opportunity to respond to Paul Hoffman's complaint regarding the fixed-length prf that he raised in another email on this thread: Paul> Here's more. Section 2.15 says: Paul> If the negotiated prf takes a fixed size key, the shared secret MUST Paul> be of that fixed size. Paul> Paul> This is completely wrong. It means that the two sides need to know Paul> before they choose their preshared secret what the prf that they will Paul> negotiate every time will be. I do not see this as a reason to disqualify support of AES as prf. In most cases the parties sharing a preshared key out of band will know (or even fix) the prf they will be using. Moreover, the ikev2 draft says explicitly (page 27) that: "if the keys were exchanged out of band, the key types must have been similarly learned." Those who dislike the idea of having to commit to a specific key length at the time of presharing, can always use the HMAC-based prf. Hugo From owner-ipsec@lists.tislabs.com Mon May 12 13:13:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CKDGi2038152; Mon, 12 May 2003 13:13:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04165 Mon, 12 May 2003 15:30:00 -0400 (EDT) Message-ID: <3EBFF722.7080306@kolumbus.fi> Date: Mon, 12 May 2003 22:33:54 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugo Krawczyk Cc: Bernard Aboba , IPsec WG Subject: Re: EAP Handling in IKEv2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > I like the distinction between reusing "legacy credentials" as opposed to > reusing "legacy methods". However, this means that we are willing to > *change* the authentication methods traditionally used by the "legacy > credentials". If this is a practical approach (namely, it can gain > widespread support in corporate organizations, etc) then the solution is > very simple and does not require the design of key-generating methods. > All is needed is that the modified methods authenticate the "context" in > which they are run. Specifically, when run with ikev2 the authenticated > information should include a unique "protocol identifier" (such as > "ikev2", "rfc-xxxx", "port-yyy", etc). This is the simplest and least > "intrusive" solution to the man in the middle problem while allowing use > of the same credentials in different contexts. Yes, this is also one of the proposed approaches for dealing with MitM. I agree that it works. I'm not 100% sure which way is easier, certainly this would be easier than designing a new kg method. But it might also be the case that the RADIUS server being used already supports EAP MS-CHAPv2 (for instance) which can be used if you have passwords. So switching to an existing kg method is of course even easier. > INPORTANT NOTE: Even in this case let's keep in mind that if the > credential used under an EAP method in ikev2 has low entropy (such as a > password) and is also used in another method that is vulnerable to > off-line dictionary attacks then its use in ikev2 becomes insecure too. Right. --Jari From owner-ipsec@lists.tislabs.com Mon May 12 16:31:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CNVmi2045817; Mon, 12 May 2003 16:31:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04700 Mon, 12 May 2003 18:55:16 -0400 (EDT) Date: Tue, 13 May 2003 02:00:07 +0300 (IDT) From: Hugo Krawczyk To: Charlie_Kaufman@notesdev.ibm.com cc: IPsec WG Subject: Re: ikev2-07: last nits In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (this msg was supposed to be sent before the message I sent earlier today, but somehow it managed to hide in my "postponed" folder) Charlie, I agree with most of your decisions here. I will refer to a couple on which I have some additional comments. On Thu, 1 May 2003 Charlie_Kaufman@notesdev.ibm.com wrote: > I agree the current text could be misinterpreted, but I don't like your > fix. Most significant and least significant is a confusing concept when > dealing with bit strings, and may not even be well defined. Adding to the > confusion, the nonces are strings of octets, where msb and lsb are well > defined within the octet but I don't believe it's obvious which are the > most and least significant octet. > > How about the following? > > "If the negotiated prf takes a fixed length key and the lengths of Ni and > Nr do not add up to that length, half the bits must come from Ni and half > from Nr, taking the first bits from each." sounds perfect to me. > > > (5) Page 29 2.17 > > > > > Current text: > > > > For CREATE_CHILD_SA exchanges with PFS the keying material is defined > as: > > > > KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr ) > > > > Proposed text: erase g^ir (ph2) > > > > Explanation: this is a leftover from 06. You erased g^ir from other > places > > where it was unneeded but this one stayed. If I understand correctly, the > > value SK_d used in this derivation is computed in section 2.18 using > > SKEYSEED which, in turn, is already derived from g^ir (new) . > > Thus re-using g^ir (ph2) (here `ph2' and `new' refer to the same thing) > > under SK_d is of no help (and spoils the theoretical analysis). > > > We understand differently :-} > > I took out the g^ir in the derivation of the IKE keys from SKEYSEED because > g^ir was used in the derivation of SKEYSEED. But for child SAs, if there is > a second Diffie-Hellman exchange specifically for the creation of that > child SA, that g^ir needs to be wound in somewhere. In the construction > above SK_d is derived from SKEYSEED, which is derived from g^ir. But that's > a different g^ir than the one here. > > This section and section 2.18 are parallel. This one talks about keying > material for an ESP or AH SA. 2.18 talks about keying material for a new > IKE SA. In both cases, the (optional) new g^ir must be wound in. > > The label 'ph2' is an obsolete reference to 'Phase 2'. I changed it to > 'new' to match the language in section 2.18. > > Am I missing something? No. I was the one missing something (important). You are right and the g^ir should stay for the reasons you exlain. Now that I (seem to) understand the differentiation between sections 2.17 and 2.18, I'd like to ask this question: is there any good reason to make this distinction? What I mean is that one could specify that all child-sa negotiations must rekey the IKE SA. Namely, in every child-sa negotiation one first computes a new SKEYSEED (as specified now in section 2.18) and then derives SK_a/d/e. This simplifies a bit the specification and has no real performance issue since the cost of computing SKEYSEED is negligible. This approach enhances the security of the protocol by providing significant forward security even in the cases where the child-sa does not use a new DH exponent. Of course, doing so raises some synchronization issues between the parties but these already exist when rekeying an IKE SA as per section 2.18. I will answer to your coments on point (6) below in a separate message. Thanks for taking care of these fixes Hugo > > > > (6) Page 81 Sec 5 (Security Considerations) > > > > Current text: The strength of all keys are limited by the size of the > output > > of the negotiated prf function. For this reason, a prf function whose > output > > is less than 128 bits (e.g. 3DES-CBC) MUST never be used with this > protocol. > > > > Discussion: You may want to add that a prf that outputs less bits than > its > > own key is also unsuited for use (even if its output is longer than 128 > bits). > > The reason for this is that SKEYSEED is produced by a (single) > application > > of the prf and its length needs to be that of the prf key. > > > > Important: The above specifications on the usable prf's should go to the > > normative part of the document (sections 2.13 or 2.14) rather than in > these > > Security Considerations. I suggest to also add there that SKEYSEED is to > be at > > least of the length of a secure key for the negotiated prf (and if this > prf is > > of fixed-length key then SKEYSEED is to be of exactly this length). > > > I believe that the use of a prf other than HMAC (or at least not accepting > a variable length key) is dangerously poorly thought out, and my > inclination is to take out all references to it. Since it got added there > have been a series of problems (including the one earlier in this note). I > hadn't noticed - but you are certainly correct - that the spec assumes that > if the prf has a fixed length key that the key length is the same as the > output length. That allows AES128-CBC, but no others come to mind. > keep patching, but is this really a requirement? It was motivated by people > who were going to put AES in hardware and didn't want to have to implement > a digest function as well. I'll buy that for the fast path (packet > integrity checks), but do we really need to engineer for that case for the > performance-irrelevant key expansion case? If so, could someone make a more > specific suggestion as to how to fix this. > From owner-ipsec@lists.tislabs.com Tue May 13 01:27:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4D8Rqi2091995; Tue, 13 May 2003 01:27:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06107 Tue, 13 May 2003 03:52:25 -0400 (EDT) From: "Yoav Nir" To: Subject: RE: EAP Handling in IKEv2 Date: Tue, 13 May 2003 10:56:33 +0200 Message-ID: <001a01c3192d$8de629c0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EBFF722.7080306@kolumbus.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Granted, if the RADIUS server supports EAP MS-CHAPv2 we can use the legacy passwords with the new method and everybody's happy. The problem with legacy authentication is that it sometimes comes with a legacy authentication server that may not support EAP at all. Take a hypothetical administrator who wants to use a mainframe RACF database as their user directory. 10 years ago they wrote an assembly language program (the mainframe administrator's favorite language) that mimics a RADIUS server that supports only PAP. Their program is simple: it just receives the name and password, translates them into EBCDIC and runs a RACHECK macro to verify that the user password is correct and that the user is allowed to use the resource "VPN". This was easily integrated with XAuth. Should we now force the administrator to rewrite his program so that it supports MS-CHAPv2? I would rather have the client just send the password to the VPN gateway and have the VPN gateway communicate with the authentication server by whatever means necessary. In a previous post I suggested using the GTC method which simply sends the password. Untunneled GTC, just like PAP, is so insecure that no client will ever be configured to use it. GTC will only be used either through a tunnel or through a secure medium. Now if there was a method that passed the password to the gateway and also generated keys, that would be great, but none of the EAP methods has a published document (draft or RFC) and does that. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jari Arkko Sent: Monday, May 12, 2003 9:34 PM To: Hugo Krawczyk Cc: Bernard Aboba; IPsec WG Subject: Re: EAP Handling in IKEv2 Hugo Krawczyk wrote: > I like the distinction between reusing "legacy credentials" as opposed to > reusing "legacy methods". However, this means that we are willing to > *change* the authentication methods traditionally used by the "legacy > credentials". If this is a practical approach (namely, it can gain > widespread support in corporate organizations, etc) then the solution is > very simple and does not require the design of key-generating methods. > All is needed is that the modified methods authenticate the "context" in > which they are run. Specifically, when run with ikev2 the authenticated > information should include a unique "protocol identifier" (such as > "ikev2", "rfc-xxxx", "port-yyy", etc). This is the simplest and least > "intrusive" solution to the man in the middle problem while allowing use > of the same credentials in different contexts. Yes, this is also one of the proposed approaches for dealing with MitM. I agree that it works. I'm not 100% sure which way is easier, certainly this would be easier than designing a new kg method. But it might also be the case that the RADIUS server being used already supports EAP MS-CHAPv2 (for instance) which can be used if you have passwords. So switching to an existing kg method is of course even easier. > INPORTANT NOTE: Even in this case let's keep in mind that if the > credential used under an EAP method in ikev2 has low entropy (such as a > password) and is also used in another method that is vulnerable to > off-line dictionary attacks then its use in ikev2 becomes insecure too. Right. --Jari From owner-ipsec@lists.tislabs.com Tue May 13 05:50:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DCoPi2013307; Tue, 13 May 2003 05:50:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06880 Tue, 13 May 2003 08:15:21 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: scott@airespace.com Cc: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. Date: Mon, 12 May 2003 17:55:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 May 2003 21:55:40.0082 (UTC) FILETIME=[3A3D1920:01C318D1] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Can you give a real-world example of the process you describe below? >That is, what sort of ID payload would be sent, what might it contain, >and how would the policies look against which this compared? Sorry for the late reply (I wasn't following the list last week). Anyway, I think we sometimes get too hung up on defining scenarios, rather than providing a framework for interoperability and allowing vendors to choose their own problem spaces. But nonetheless, I can give you a few scenarios: 1. A customer decides to consolidate its VPNs. Previously, there were 3 different VPNs at various branch offices and the policies were not homogenous. Some of the policies are expressed in terms of USER_FQDNs, others by IP address and still others by distinguished name. The id payload provides a key into the policy database and allows a single search pass instead of 3. 2. For remote access, it is common to use some kind of XAuth-like process where the true identity of the user is not authenticated by IKE itsself. For IKEv2, the decision on whether to authenticate the user with EAP may depend on the contents of the id payload. Imagine that the phase 1 authentication is performed with a machine certificate and the user's id is completely divorced from the certificate. Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. >From: "Scott G. Kelly" >To: Andrew Krywaniuk >CC: ipsec@lists.tislabs.com >Subject: Re: Confirm decision on identity handling. >Date: Thu, 01 May 2003 09:10:05 -0700 > >Hi Andrew, > > >Thanks, > >Scott > >Andrew Krywaniuk wrote: > > > > >And what is the point of this? It seems to make the policy lookup > > >slightly simpler, since you can get the ID payload from the packet > > >instead of parsing the cert. But this is only on the front end, because > > >you still have to parse the cert, and you have the added step of > > >verifying that the ID matches something in the cert (if you care about > > >security). > > > > Some people have been referring to the id as a "key for policy lookup". >The > > idea is that if you have a decorrelated database (or an ordered database > > where more specific rules serve only to grant privileges and not to take > > them away), a unique id can allow a very fast policy lookup. > > > > However, once this lookup is complete, you can throw the id away. It is >not > > necessary to check the id against a field in the certificate. You only >have > > to check the certificate against the policy (and the signature against >the > > public key and the validity of the cert chain). > > > > I wish people would stop saying thing like "you can check the id against >the > > certificate if you require a more stringent policy check." > > > > Andrew > > -------------------------------------- > > The odd thing about fairness is when > > we strive so hard to be equitable > > that we forget to be correct. > > > > _________________________________________________________________ > > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > > http://join.msn.com/?page=features/junkmail _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-ipsec@lists.tislabs.com Tue May 13 15:52:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4DMqPHN050049; Tue, 13 May 2003 15:52:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08664 Tue, 13 May 2003 18:13:49 -0400 (EDT) Message-ID: <3EC16F2D.123CEA1D@airespace.com> Date: Tue, 13 May 2003 15:18:21 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2003 22:18:39.0329 (UTC) FILETIME=[9ABF3D10:01C3199D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Basically, every example given so far uses an ID value which can be verified against the cert. Can anyone give a realistic example of a case where we would *not* want the ID to match something in the cert? Scott From owner-ipsec@lists.tislabs.com Tue May 13 16:57:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4DNvJAF052026; Tue, 13 May 2003 16:57:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08842 Tue, 13 May 2003 19:29:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3EC16F2D.123CEA1D@airespace.com> References: <3EC16F2D.123CEA1D@airespace.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 13 May 2003 16:30:03 -0700 To: "Scott G. Kelly" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Confirm decision on identity handling. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:18 PM -0700 5/13/03, Scott G. Kelly wrote: >Basically, every example given so far uses an ID value which can be >verified against the cert. Can anyone give a realistic example of a case >where we would *not* want the ID to match something in the cert? The ID can always match something in the cert. The question is really, can we force the specific ID to match something in the specific cert. In order to do so: - The VPN administrator has to control the CA that issues the certs so that he/she can get the right value into the right slot of the certs. Sometimes this is easy, sometimes this is impossible (such as when some other person in IT controls the CA and as a "better idea" for how the identities in the certs should look, or when the company has chosen an inflexible CA product). - The user has to know which identities are in their cert. - The UI for the user's VPN system (often client software) has to be flexible enough to handle the different types of identities. Even if those three requirements are met, the receiving software has to know where in the cert to look for the identity. Email addresses and FQDNs can be in either the Subject or SubjectAltName. And I've even see IP addresses in the Subject, as the CommonName. So, yes you can make this work, but the likelihood of interoperability quickly approaches zero. Even if we said "the cert must have the identities here", there is lots of CA software out there that will ignore that new rule. Further, since lots of IKEv1 software will expect the certs to look differently, boxes that want to speak both IKEv1 and IKEv2 may need (at least) two certificates for the same identity. The admin interface for that situation will be ugly, to say the least. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed May 14 09:51:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4EGpMAF024000; Wed, 14 May 2003 09:51:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11815 Wed, 14 May 2003 11:48:46 -0400 (EDT) Message-Id: <200305141551.h4EFpq008935@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3526 on More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) Cc: rfc-editor@rfc-editor.org, ipsec@lists.tislabs.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 14 May 2003 08:51:52 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3526 Title: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) Author(s): T. Kivinen, M. Kojo Status: Standards Track Date: May 2003 Mailbox: kivinen@ssh.fi, mika.kojo@helsinki.fi Pages: 10 Characters: 19166 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-ike-modp-groups-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3526.txt This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. This document is a product of the IP Security Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030514084849.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3526 --OtherAccess Content-Type: Message/External-body; name="rfc3526.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030514084849.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed May 14 17:07:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4F070AF040883; Wed, 14 May 2003 17:07:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13210 Wed, 14 May 2003 19:37:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 14 May 2003 16:42:23 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Crypto algorithms for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Based on the feedback from the WG, I have revised my crypto algorithms for IKEv2 draft. The new version is available at . The changes are: 2.1: Removed ENCR_DES_IV32 and ENCR_RC4, which didn't have references, and renumbered the ones below them. Also added draft names for AES ciphers. 2.2: Added a reference for PRF_AES128_CBC, but am not sure this is correct or sufficient. 2.3: Removed DES_MAC because there was no reference for it. Renumbered. Added reference for AUTH_AES_XCBC_96. 3.1 and 3.2: Added requirements for perfect forward secrecy. 3.2: Updated the IDs because of the renumbering in sections 2.1 and 2.3. Please review the document and post any comments to the WG mailing list. It would be good to get this part of the IKEv2 work finished soon. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed May 14 22:13:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4F5DMAF049037; Wed, 14 May 2003 22:13:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA14038 Thu, 15 May 2003 00:45:22 -0400 (EDT) Message-ID: <3EC31E89.6060300@roc.co.in> Date: Thu, 15 May 2003 10:28:49 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: Gregory Lebovitz , "'ddukes@cisco.com'" , ipsec@lists.tislabs.com, Michael Choung Shieh , owner-ipsec@lists.tislabs.com Subject: Re: Peer liveliness References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In IKEv2, the IKE SA are bound to the IPSEC SA and IPSEC SAs (Child SAs) are deleted whenever IKE SA is dead. Due to this, I don't see any problem with the approach mentioned in IKEv2 specifications. But, in IKEv1, this binding is not mandated and IPSEC SA can exist without corresponding IKE SA. This is where I see problem and current DPD specification does not seem to be considering this. I was proposing before, the need for Dead Tunnel detection on the remote SGs. I plan to come out with draft in 1 to 2 weeks on this. It is only applicable for IKEv1 implementations. Regards Ravi Charlie_Kaufman@notesdev.ibm.com wrote: > > > > I believe that the current IKEv2 spec addresses this issue in a way that > puts minimal requirements on implementations, guarantees interoperability > (though with less than ideal convergence time), and allows implementations > to do better. > > But it's quite possible that I don't understand all of the things that > could go wrong, or have inadequately expressed what implementations MUST > do, or just plain screwed up. > > The implementation requirements for robust interoperability are: > > (1) An IKE SA and all of its associated child SAs fail together. You aren't > allowed a "partial crash" where some of the state is lost but some is kept. > This will fall out naturally in most implementations, but may require some > modular designs to have different modules poll one another for liveness. > > (2) A node may not send on a set of SAs associated with a single IKE SA > indefinitely without hearing something back. If it hears nothing for long > enough, it should send an IKE message requiring a reply, and if no reply > comes it must declare all of the SAs dead. > > (3) A node that has packets to send according to its SPD and no SA to send > them on must periodically attempt to open an SA for them. > > I believe these three requirements along guarantee that the right thing > will happen eventually. But it doesn't prescribe what the timers should be. > So it's possible it will take unacceptably long for things to converge. (If > network delays are long enough and timeouts short enough, the system could > fail to work at all, but I believe that problem is unavoidable). > > The problem with more sophisticated strategies is that they may be > exploitable for denial of service attacks. Anyone can forge an INVALID_SPI > notification message from an IP address of their choice (since such a > message is not cryptographically protected). If such a message were > sufficient to cause its recipient to shut down and restart the SA, it would > be a very effective attack. So the spec says that such a message may be > used only as a hint to a problem - for example to trigger a > cryptographically protected liveness test. This will cause the failure to > be detected more quickly, but will never cause one to be detected falsely. > > Similarly, the INITIAL_CONTACT notification can be used when setting up an > SA to assure the other end that it should abandon any SAs it has open to > the same identity. This is useful in - for example - the firewall case > where an identity is tied to a single box and it would be an error for that > box to bring up two connections at once. It would not be useful in the case > of a user who is allowed to remotely log in from multiple workstations at > the same time. Again, this makes convergence happen faster while never > making the wrong thing happen. > > Responding to the individual comments below... > > Gregory Lebovitz wrote on 04/29/2003: > >> [WE] won't achieve interoperability unless it's mandated that >>[IMPLEMENTORS] must >> >>>reply INVALID_SPI (in clear or initiate IKE back to the >>>sender) whenever it >>>receives bad spi packets. Current IKEv2 draft doesn't >>>address this issue >>>(only states you MAY reply a clear notify message). >>> >>>IKEv1 vendors has implemented many ways to solve it which leave poor >>>interoperability. We should just pick a method and clarify >>>it in IKEv2. >>>=============== >>>Michael Shieh >>> >> > I think we did, but if you don't think it works, explain why. > > >>We have been having quite a debate in the ICSA IPsec consortium mail list >>recently trying to figure out how to handle this in IKEv1 (YES, STILL!!!) >> >>Here is what we know for sure of this problem statement: >>(a) detecting liveness/deadness of peer is a good thing, but does not > > solve > >>all the failure cases in and of itself > > Which ones does it not solve? > > >> (b) the behavior of a recently rebooted device when it receives an >>encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated, > > or > >>else implementations will not interoperate (as is the case in IKEv1, 5 > > years > >>later). > > Can you give an example of how two implementations following IKEv2 could > fail to interoperate? > > >> (c) the behavior of a peer that receives a new IKE from a peer that it > > has > >>an existing IKE-SA with (i.e. the rebooted peer that is trying to > > initiate a > >>new connection) MUST be mandated, or else implementations will not >>interoperate (as is the case in IKEv1, 5 years later). > > I believe it is mandated that the new IKE-SA must be accepted, and the old > one either closed immediately or closed after a timeout, though perhaps > that's just what I was thinking and not what I wrote. Is there anything > specific you would recommend? > > >>Darren Dukes wrote: >> >>>I believe INVALID_SPI does what you are looking for. If I receive an >>>INVALID_SPI notify via an IKE SA I know to delete the SA and >>>traffic will >>>bring up a new one. >> >>I don't believe this will work, since it assumes that an IKE SA is >>established. In the scenario, the IKE-SA would have been lost along with > > the > >>SPI of the CHILD-SA by the rebooted peer. >> > > Until a new IKE-SA is established, any INVALID_SPI message would be > cryptographically unprotected and therefore not to be taken as other > than a hint. If a new IKE-SA is established, the INVALID_SPI could > be taken as trustworthy and used to abandon the old SA. Without the > INVALID_SPI message, abandonment would still happen but it would take > longer. > > >>Recommendations to solve the solution: >>- the empty notify as an aliveness check is a good idea. It accomplishes >>what the DPD draft did. Keep using this. >> > > Generating them is not mandated, but the ability to respond to them is. > > >>- do what you can to use empty notify to detect dead peer ASAP. The > > faster > >>the persisting peer can delete the old SPI and IKE-SA, the better. The > > best > >>case is for Persisting Peer to detect death and initiate new IKE to > > rebooted > >>peer before rebooted peer gets packets with old SPI, IKE-SA. >> > > If the rebooted peer knows that the SA is needed, it can do that. If it > sets them up based on traffic, it has to wait until a packet comes in from > one side or the other. > > >>- On the Rebooted peer side: If an implementation receives a protected >>packet from an unkown SPI, >> - simply relying on sending back an unprotected INVALID_SPI is not a > > good > >>idea. It is too easy to DoS the persisting peer by simply spoofing the >>rebooted peer's address. >> - initiate IKE to the persisting peer. > > This is allowed, although sending what looks like protected messages from > randomly chosen IP addresses to cause the node to attempt lots of IKE > connections is also a plausible DOS attack. Sending the INVALID_SPI message > will tell the other end to probe this end for liveness and initiate its own > new IKE connection if that liveness test fails. That's the path guaranteed > to work. Others will speed things up if implementations choose to do them. > > >>- On the Persisting Peer: >> - If you get a new IKE request from a peer already in your SADB, respond >>with the under-attack, 6 message method. This will mitigate the DoS > > attack. > >>If you get all the way through SA and TS negotiation successfully, you > > are > >>assured (unless I'm missing something) that this really is your peer, and >>that he re-initiated because he lost the original IKE-SA. Start using the >>new IKE-SA and the new CHILD-SA and delete the previous ones after some > > wait > >>period. >> > > Only if there is an INITIAL_CONTACT notification message. Otherwise it's > possible that the peer is opening multiple IKE SAs, perhaps because he is > replicated. In some configurations this might be acceptable. In firewall to > firewall tunnels, it would not and an implementation might reasonably treat > any IKE-SA as an INITIAL_CONTACT. > > >>Would this proposal explicitly solve things? >> >>Gregory. > > > --Charlie > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Thu May 15 01:17:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4F8H0AF079048; Thu, 15 May 2003 01:17:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA14700 Thu, 15 May 2003 03:48:53 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66D8D@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Ravi'" , Charlie_Kaufman@notesdev.ibm.com Cc: "'ddukes@cisco.com'" , ipsec@lists.tislabs.com, Michael Choung Shieh , owner-ipsec@lists.tislabs.com, "Geoff Huang (E-mail)" Subject: RE: Peer liveliness Date: Thu, 15 May 2003 00:46:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Moving the discussion back to IKEv2, for the moment... Several of us have spent a lot of time discussing this issue in the past few weeks. A main problem we are trying to solve (though not the only one) is rapid recovery from a rebooted peer. If you look at the current DPD draft for IKEv1, it calls for sending INITIAL-CONTACT whenever a peer thinks this is its first contact, i.e. has no established SAs with the remote peer. This is done, even in the case where DPD is running on both peers, to let the other peer -- the persisted peer (as opposed to the rebooted peer) -- know to delete the old SAs asap. Because the DPD timers might not catch it fast enough. It is a very good idea to do this because sending the empty notify (DPD), and the timer setting for how often, are totally optional. Therefore, depending on settings, and *without* the INITIAL-CONTACT, it could be quite some time before the persisted peer relinquishes its current SAs. Charlie, I can't remember, is the sending of INITIAL-CONTACT a MUST in the latest IKEv2 draft? Would it be a good idea to make INITIAL-CONTACT notification a MUST, if it is not already? Doing so would help shorten the tunnel black hole in most cases, regardless of dpd settings. The next question is: what is the best behavior for a (rebooted) peer who receives an invalid SPI? Today the mandate is to drop silently. But, if two rules are checked first, it can be fine (i think) to respond. Those rules are: - do I have an active SA with the sender of the invalid SPI? If yes, drop silently. If no, go to next rule check... - do I have the source IP of the sender in my SPD? i.e. is the sender a valid peer? If no, drop silently. If yes... - initiate IKE per SPD definition. If these two rules are followed, the only threat I see to responding with IKE initiation is that an attacker who knew all of my valid peers' IPs could, at the moment of recovery from reboot (or power up), cause me to establish IKE with all my peers listed in SPD, even though I might not have otherwise made those establishmetns. Attacker would do so by sending me invalid SPIs spoofed with source of each of my peers. I guess I see this as a pretty tough attack to pull-off in the real world (given spoof checking used on most ISP routers these days), and the pay-off of the attack likely doesn't merit the difficulty of execution. Does the value merrit the risk? Summary: IKEv2 aliveness checking doesn't ensure fast recovery. It provides a mechanism that MAY be used for fast detection and recovery, but doesn't guarantee it. However, combining the initiate-IKE response behavior + INITIAL-CONTACT + liveness detection would ensure VERY fast re-establishments for valid peers after one rebooted (and covers all other cases too). If the liveness checking doesn't catch the failure fast enough, the initiate IKE response w/ IC will. Thoughts? Gregory. > -----Original Message----- > From: Ravi [mailto:ravivsn@roc.co.in] > Sent: Wednesday, May 14, 2003 9:59 PM > To: Charlie_Kaufman@notesdev.ibm.com > Cc: Gregory Lebovitz; 'ddukes@cisco.com'; ipsec@lists.tislabs.com; > Michael Choung Shieh; owner-ipsec@lists.tislabs.com > Subject: Re: Peer liveliness > > > Hi, > In IKEv2, the IKE SA are bound to the IPSEC SA and IPSEC SAs (Child > SAs) are deleted whenever IKE SA is dead. Due to this, I > don't see any > problem with the approach mentioned in IKEv2 specifications. But, in > IKEv1, this binding is not mandated and IPSEC SA can exist without > corresponding IKE SA. This is where I see problem and current DPD > specification does not seem to be considering this. I was proposing > before, the need for Dead Tunnel detection on the remote > SGs. I plan to > come out with draft in 1 to 2 weeks on this. It is only applicable > for IKEv1 implementations. > > Regards > Ravi > > Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > > > > I believe that the current IKEv2 spec addresses this issue > in a way that > > puts minimal requirements on implementations, guarantees > interoperability > > (though with less than ideal convergence time), and allows > implementations > > to do better. > > > > But it's quite possible that I don't understand all of the > things that > > could go wrong, or have inadequately expressed what > implementations MUST > > do, or just plain screwed up. > > > > The implementation requirements for robust interoperability are: > > > > (1) An IKE SA and all of its associated child SAs fail > together. You aren't > > allowed a "partial crash" where some of the state is lost > but some is kept. > > This will fall out naturally in most implementations, but > may require some > > modular designs to have different modules poll one another > for liveness. > > > > (2) A node may not send on a set of SAs associated with a > single IKE SA > > indefinitely without hearing something back. If it hears > nothing for long > > enough, it should send an IKE message requiring a reply, > and if no reply > > comes it must declare all of the SAs dead. > > > > (3) A node that has packets to send according to its SPD > and no SA to send > > them on must periodically attempt to open an SA for them. > > > > I believe these three requirements along guarantee that the > right thing > > will happen eventually. But it doesn't prescribe what the > timers should be. > > So it's possible it will take unacceptably long for things > to converge. (If > > network delays are long enough and timeouts short enough, > the system could > > fail to work at all, but I believe that problem is unavoidable). > > > > The problem with more sophisticated strategies is that they may be > > exploitable for denial of service attacks. Anyone can forge > an INVALID_SPI > > notification message from an IP address of their choice > (since such a > > message is not cryptographically protected). If such a message were > > sufficient to cause its recipient to shut down and restart > the SA, it would > > be a very effective attack. So the spec says that such a > message may be > > used only as a hint to a problem - for example to trigger a > > cryptographically protected liveness test. This will cause > the failure to > > be detected more quickly, but will never cause one to be > detected falsely. > > > > Similarly, the INITIAL_CONTACT notification can be used > when setting up an > > SA to assure the other end that it should abandon any SAs > it has open to > > the same identity. This is useful in - for example - the > firewall case > > where an identity is tied to a single box and it would be > an error for that > > box to bring up two connections at once. It would not be > useful in the case > > of a user who is allowed to remotely log in from multiple > workstations at > > the same time. Again, this makes convergence happen faster > while never > > making the wrong thing happen. > > > > Responding to the individual comments below... > > > > Gregory Lebovitz wrote on 04/29/2003: > > > >> [WE] won't achieve interoperability unless it's mandated that > >>[IMPLEMENTORS] must > >> > >>>reply INVALID_SPI (in clear or initiate IKE back to the > >>>sender) whenever it > >>>receives bad spi packets. Current IKEv2 draft doesn't > >>>address this issue > >>>(only states you MAY reply a clear notify message). > >>> > >>>IKEv1 vendors has implemented many ways to solve it which > leave poor > >>>interoperability. We should just pick a method and clarify > >>>it in IKEv2. > >>>=============== > >>>Michael Shieh > >>> > >> > > I think we did, but if you don't think it works, explain why. > > > > > >>We have been having quite a debate in the ICSA IPsec > consortium mail list > >>recently trying to figure out how to handle this in IKEv1 > (YES, STILL!!!) > >> > >>Here is what we know for sure of this problem statement: > >>(a) detecting liveness/deadness of peer is a good thing, > but does not > > > > solve > > > >>all the failure cases in and of itself > > > > Which ones does it not solve? > > > > > >> (b) the behavior of a recently rebooted device when it receives an > >>encrypted packet for an SPI or IKE-SA not in its SADB MUST > be mandated, > > > > or > > > >>else implementations will not interoperate (as is the case > in IKEv1, 5 > > > > years > > > >>later). > > > > Can you give an example of how two implementations > following IKEv2 could > > fail to interoperate? > > > > > >> (c) the behavior of a peer that receives a new IKE from a > peer that it > > > > has > > > >>an existing IKE-SA with (i.e. the rebooted peer that is trying to > > > > initiate a > > > >>new connection) MUST be mandated, or else implementations will not > >>interoperate (as is the case in IKEv1, 5 years later). > > > > I believe it is mandated that the new IKE-SA must be > accepted, and the old > > one either closed immediately or closed after a timeout, > though perhaps > > that's just what I was thinking and not what I wrote. Is > there anything > > specific you would recommend? > > > > > >>Darren Dukes wrote: > >> > >>>I believe INVALID_SPI does what you are looking for. If I > receive an > >>>INVALID_SPI notify via an IKE SA I know to delete the SA and > >>>traffic will > >>>bring up a new one. > >> > >>I don't believe this will work, since it assumes that an IKE SA is > >>established. In the scenario, the IKE-SA would have been > lost along with > > > > the > > > >>SPI of the CHILD-SA by the rebooted peer. > >> > > > > Until a new IKE-SA is established, any INVALID_SPI message would be > > cryptographically unprotected and therefore not to be taken as other > > than a hint. If a new IKE-SA is established, the INVALID_SPI could > > be taken as trustworthy and used to abandon the old SA. Without the > > INVALID_SPI message, abandonment would still happen but it > would take > > longer. > > > > > >>Recommendations to solve the solution: > >>- the empty notify as an aliveness check is a good idea. It > accomplishes > >>what the DPD draft did. Keep using this. > >> > > > > Generating them is not mandated, but the ability to respond > to them is. > > > > > >>- do what you can to use empty notify to detect dead peer ASAP. The > > > > faster > > > >>the persisting peer can delete the old SPI and IKE-SA, the > better. The > > > > best > > > >>case is for Persisting Peer to detect death and initiate new IKE to > > > > rebooted > > > >>peer before rebooted peer gets packets with old SPI, IKE-SA. > >> > > > > If the rebooted peer knows that the SA is needed, it can do > that. If it > > sets them up based on traffic, it has to wait until a > packet comes in from > > one side or the other. > > > > > >>- On the Rebooted peer side: If an implementation receives > a protected > >>packet from an unkown SPI, > >> - simply relying on sending back an unprotected > INVALID_SPI is not a > > > > good > > > >>idea. It is too easy to DoS the persisting peer by simply > spoofing the > >>rebooted peer's address. > >> - initiate IKE to the persisting peer. > > > > This is allowed, although sending what looks like protected > messages from > > randomly chosen IP addresses to cause the node to attempt > lots of IKE > > connections is also a plausible DOS attack. Sending the > INVALID_SPI message > > will tell the other end to probe this end for liveness and > initiate its own > > new IKE connection if that liveness test fails. That's the > path guaranteed > > to work. Others will speed things up if implementations > choose to do them. > > > > > >>- On the Persisting Peer: > >> - If you get a new IKE request from a peer already in your > SADB, respond > >>with the under-attack, 6 message method. This will mitigate the DoS > > > > attack. > > > >>If you get all the way through SA and TS negotiation > successfully, you > > > > are > > > >>assured (unless I'm missing something) that this really is > your peer, and > >>that he re-initiated because he lost the original IKE-SA. > Start using the > >>new IKE-SA and the new CHILD-SA and delete the previous > ones after some > > > > wait > > > >>period. > >> > > > > Only if there is an INITIAL_CONTACT notification message. > Otherwise it's > > possible that the peer is opening multiple IKE SAs, perhaps > because he is > > replicated. In some configurations this might be > acceptable. In firewall to > > firewall tunnels, it would not and an implementation might > reasonably treat > > any IKE-SA as an INITIAL_CONTACT. > > > > > >>Would this proposal explicitly solve things? > >> > >>Gregory. > > > > > > --Charlie > > > > > -- > > > The views presented in this mail are completely mine. The > company is not > responsible for whatsoever. > -------------------------------------------------------------- > ---------- > Ravi Kumar CH > Rendezvous On Chip (i) Pvt Ltd > Hyderabad, India > Ph: +91-40-2335 1214 / 1175 / 1184 > > ROC home page > > > From owner-ipsec@lists.tislabs.com Thu May 15 01:28:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4F8S3AF080198; Thu, 15 May 2003 01:28:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14808 Thu, 15 May 2003 04:02:55 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Paul Hoffman / VPNC'" , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: RE: Confirm decision on identity handling. Date: Thu, 15 May 2003 01:01:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul is totally right on this one. From experience with Project Dploy, where we tried to get better interop between IPsec vendors and PKI vendors after talking to many customers about actual usage issues, this is what we found: It is a daunting task for the deployers to get the cert contents to match exactly what the VPN application needs. This is true for a variety of reasons, many of which Paul noted below. The biggest is that often the VPN deployer has little or zero impact/control/say in how the CA builds certs. It's just not reality to expect that the VPN can dictate or ensure some field in the Cert will contain what they need. This is why many of us have been pushing for disassociating the two. ... [sarcasm ahead] or maybe we can just forget the whole issue because, in reality, so few deployers even care to try to make certs work with VPNs anymore because we have screwed it up so badly for them for so long ... > So, yes you can make this work, but the likelihood of > interoperability quickly approaches zero. And there is a big difference between being able to be configured to be interoperable, and being practically *usable*. Matching ID to something in the cert CAN be done successfully, but actual deployment experience has proven it almost impossible. Just ask the support teams from the major IPsec vendors. Lets try to build something people can actually USE this time, eh? I vote for disassociating ID from cert contents. (BUT, I proposed text that would allow for those who desired/required to be able to match if they wanted to). > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Tuesday, May 13, 2003 4:30 PM > To: Scott G. Kelly; ipsec@lists.tislabs.com > Subject: Re: Confirm decision on identity handling. > > > At 3:18 PM -0700 5/13/03, Scott G. Kelly wrote: > >Basically, every example given so far uses an ID value which can be > >verified against the cert. Can anyone give a realistic > example of a case > >where we would *not* want the ID to match something in the cert? > > The ID can always match something in the cert. The question is > really, can we force the specific ID to match something in the > specific cert. In order to do so: > > - The VPN administrator has to control the CA that issues the certs > so that he/she can get the right value into the right slot of the > certs. Sometimes this is easy, sometimes this is impossible (such as > when some other person in IT controls the CA and as a "better idea" > for how the identities in the certs should look, or when the company > has chosen an inflexible CA product). > > - The user has to know which identities are in their cert. > > - The UI for the user's VPN system (often client software) has to be > flexible enough to handle the different types of identities. > > Even if those three requirements are met, the receiving software has > to know where in the cert to look for the identity. Email addresses > and FQDNs can be in either the Subject or SubjectAltName. And I've > even see IP addresses in the Subject, as the CommonName. > > So, yes you can make this work, but the likelihood of > interoperability quickly approaches zero. Even if we said "the cert > must have the identities here", there is lots of CA software out > there that will ignore that new rule. Further, since lots of IKEv1 > software will expect the certs to look differently, boxes that want > to speak both IKEv1 and IKEv2 may need (at least) two certificates > for the same identity. The admin interface for that situation will be > ugly, to say the least. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Thu May 15 06:16:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FDGDAF003045; Thu, 15 May 2003 06:16:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15671 Thu, 15 May 2003 08:35:54 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66D8F@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Ravi'" Cc: Michael Choung Shieh , "'ddukes@cisco.com'" , ipsec@lists.tislabs.com Subject: RE: Peer liveliness Date: Thu, 15 May 2003 01:15:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31ABA.36B819E0" 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_01C31ABA.36B819E0 Content-Type: text/plain; charset="WINDOWS-1252" w/in... -----Original Message----- From: Ravi [mailto:ravivsn@roc.co.in] Sent: Sunday, May 04, 2003 9:21 PM To: Gregory Lebovitz Cc: Michael Choung Shieh; 'ddukes@cisco.com'; ipsec@lists.tislabs.com Subject: Re: Peer liveliness Hi, In the text below, I also try to use the same terminology used by you. Rebooted Peer and Persistent Peer. In your email, under 'Recommendations to solve the solution', regarding second point: In my view, whether Peer is alive or not does not solve the problem completely. Persistent node should know aliveness of Tunnel on the other side. It is possible that peer reboots and responds to DPD requests, but tunnels are not there. We should have a mechanism to detect the Tunnel aliveness. [GML] I think Charlie addressed this by saying that once the IKE-SA is revived, one or the other would have sent the INITIAL-CONTACT. When this happens, the other peer will delete old SAs, including CHILD-SAs. So, once IKE establishes, traffic will cause creation of new CHILD-SA (IPsec), so tunnel will come alive. Does this address your concern? With respect to DoS attack: You addressed the issue of DoS attack on the persistent side. I am also concerned about DoS attack on rebooting machine. If MITM keeps sending the packets with some dummy SPI and valid source IP, then the IPSEC SG keeps sending the INVALID_SPI and for this,it keeps creating IKE SAs. That is one of the reason, some implementations do not support generationof INVALID_SPI notifications. [GML] I'm not proposing use of INVALID_SPI; I specifically said I thought INVALID_SPI was bad. Im proposing rebooted-peer initates IKE to sender of invalid SPI if -- and ONLY IF-- two conditions are met: (1) no current valid SAs with sender, (2) sender is valid peer in SPD These two checks mitigate the DoS issue almost completely. (see my other email for discussion of threat analysis on this one). The more I hash this through with various people, the more I'm becoming convinced that INITIAL-CONTACT + rebooted-peer initiating IKE (with above two conditions) + aliveness detection is the only way to catch all the failure cases. Gregory. ------_=_NextPart_001_01C31ABA.36B819E0 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable w/in... -----Original Message----- From: Ravi=20 [mailto:ravivsn@roc.co.in] Sent: Sunday, May 04, 2003 9:21=20 PM To: Gregory Lebovitz Cc: Michael Choung Shieh; = 'ddukes@cisco.com'; ipsec@lists.tislabs.com Subject: Re: = Peer=20 liveliness Hi, In the text below, I also try to use the same terminology used by you. Rebooted Peer and Persistent Peer. In your email, under 'Recommendations to solve the solution', = regarding second point: In my view, whether Peer is alive or not does not solve the = problem completely. Persistent node should know aliveness of Tunnel on the other side. = It is possible that peer reboots and responds to DPD requests, but tunnels are not = there. We should have a mechanism to detect the Tunnel aliveness. [GML] I think Charlie addressed this by saying that once = the IKE-SA is revived, one or the other would have sent the = INITIAL-CONTACT. When this happens, the other peer will delete old SAs, = including CHILD-SAs. So, once IKE establishes, traffic will cause = creation of new CHILD-SA (IPsec), so tunnel will come alive. Does this = address your concern? With respect to DoS attack: You addressed the issue of DoS attack on the persistent side. I am = also concerned about DoS attack on rebooting machine. If MITM keeps sending the = packets with some dummy SPI and valid source IP, then the IPSEC SG keeps = sending the INVALID_SPI and for this,it keeps creating IKE SAs. That is one of = the reason,=20 some implementations do not support generationof INVALID_SPI = notifications. [GML] I'm not proposing use of = INVALID_SPI; I specifically said I thought INVALID_SPI was bad. Im = proposing rebooted-peer initates IKE to sender of invalid SPI if -- and = ONLY IF-- two conditions are met: (1) no current valid SAs with = sender, (2) sender is valid peer in SPD These two checks mitigate the DoS issue almost = completely. (see my other email for discussion of threat analysis on = this one). The more I hash this through with various people, the more I'm = becoming convinced that INITIAL-CONTACT + rebooted-peer initiating IKE = (with above two conditions) + aliveness detection is the only way to = catch all the failure cases. Gregory. ------_=_NextPart_001_01C31ABA.36B819E0-- From owner-ipsec@lists.tislabs.com Thu May 15 06:19:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FDJgAF003644; Thu, 15 May 2003 06:19:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15732 Thu, 15 May 2003 08:49:28 -0400 (EDT) To: Gregory Lebovitz Cc: "'Paul Hoffman / VPNC'" , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> Reply-To: EKR From: Eric Rescorla Date: 15 May 2003 06:00:13 -0700 In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gregory Lebovitz writes: > I vote for disassociating ID from cert contents. (BUT, I proposed text that > would allow for those who desired/required to be able to match if they > wanted to). The problem, then, of course, is that you've just made it near impossible to make a system which works in the generic "I want to establish an SA with some I've never heard of before" mode. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu May 15 07:42:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FEgWAF007173; Thu, 15 May 2003 07:42:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15951 Thu, 15 May 2003 10:08:17 -0400 (EDT) Message-Id: <200305151413.h4FED4of081571@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: EKR cc: Gregory Lebovitz , "'Paul Hoffman / VPNC'" , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of 15 May 2003 06:00:13 PDT. Date: Thu, 15 May 2003 16:13:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: The problem, then, of course, is that you've just made it near impossible to make a system which works in the generic "I want to establish an SA with some I've never heard of before" mode. => note this was the main argument against the full IPsec security solution of Mobile IPv6... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu May 15 08:23:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FFNEAF009222; Thu, 15 May 2003 08:23:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16146 Thu, 15 May 2003 10:54:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 15 May 2003 07:59:24 -0700 To: EKR , Gregory Lebovitz From: Paul Hoffman / VPNC Subject: Re: Confirm decision on identity handling. Cc: "Scott G. Kelly" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:00 AM -0700 5/15/03, Eric Rescorla wrote: >Gregory Lebovitz writes: > > I vote for disassociating ID from cert contents. (BUT, I proposed text that > > would allow for those who desired/required to be able to match if they >> wanted to). >The problem, then, of course, is that you've just made it near >impossible to make a system which works in the generic >"I want to establish an SA with some I've never heard >of before" mode. Could you explain why? For this scenario, how is binding an ID to the cert any different than ignoring the ID and getting an identity out of the cert? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 15 08:27:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FFRiAF009690; Thu, 15 May 2003 08:27:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16175 Thu, 15 May 2003 10:57:50 -0400 (EDT) To: Paul Hoffman / VPNC Cc: Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> Reply-To: EKR From: Eric Rescorla Date: 15 May 2003 08:08:35 -0700 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 6:00 AM -0700 5/15/03, Eric Rescorla wrote: > >Gregory Lebovitz writes: > > > I vote for disassociating ID from cert contents. (BUT, I proposed text that > > > would allow for those who desired/required to be able to match if they > >> wanted to). > >The problem, then, of course, is that you've just made it near > >impossible to make a system which works in the generic > >"I want to establish an SA with some I've never heard > >of before" mode. > > Could you explain why? For this scenario, how is binding an ID to the > cert any different than ignoring the ID and getting an identity out of > the cert? Hmm... I see your point. I was speculating that this would mean that you didn't much care what was in the certificate. What would be the point of using an ID payload if you didn't care what was in it? -Ekr From owner-ipsec@lists.tislabs.com Thu May 15 08:44:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FFiWAF010168; Thu, 15 May 2003 08:44:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16253 Thu, 15 May 2003 11:08:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 15 May 2003 08:13:26 -0700 To: EKR From: Paul Hoffman / VPNC Subject: Re: Confirm decision on identity handling. Cc: Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: >Hmm... I see your point. I was speculating that this would mean >that you didn't much care what was in the certificate. You could have a security policy that ignored the identity in the cert ("allow an SA with these restrictions to anyone who has a cert from XYZRoot"), or one that was identity-based ("let chris@example.com make an SA"). >What would be the point of using an ID payload if you didn't >care what was in it? There isn't one. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 15 08:50:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FFoWAF010498; Thu, 15 May 2003 08:50:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16318 Thu, 15 May 2003 11:18:49 -0400 (EDT) To: Paul Hoffman / VPNC Cc: Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> Reply-To: EKR From: Eric Rescorla Date: 15 May 2003 08:29:35 -0700 In-Reply-To: Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: > >Hmm... I see your point. I was speculating that this would mean > >that you didn't much care what was in the certificate. > > You could have a security policy that ignored the identity in the cert > ("allow an SA with these restrictions to anyone who has a cert from > XYZRoot"), or one that was identity-based ("let chris@example.com make > an SA"). But you would presumably want to have some restrictions on the IP addresses they were allowed to front for, right? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu May 15 09:02:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FG2OAF012118; Thu, 15 May 2003 09:02:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16396 Thu, 15 May 2003 11:37:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 15 May 2003 08:43:06 -0700 To: EKR From: Paul Hoffman / VPNC Subject: Re: Confirm decision on identity handling. Cc: Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:29 AM -0700 5/15/03, Eric Rescorla wrote: > > You could have a security policy that ignored the identity in the cert >> ("allow an SA with these restrictions to anyone who has a cert from >> XYZRoot"), or one that was identity-based ("let chris@example.com make >> an SA"). >But you would presumably want to have some restrictions >on the IP addresses they were allowed to front for, right? Sure. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu May 15 10:43:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FHhJAF018273; Thu, 15 May 2003 10:43:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16738 Thu, 15 May 2003 13:01:03 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66D96@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Paul Hoffman / VPNC'" , "'EKR'" Cc: Gregory Lebovitz , "'Scott G. Kelly'" , "'ipsec@lists.tislabs.com'" Subject: RE: Confirm decision on identity handling. Date: Thu, 15 May 2003 09:58:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > At 8:29 AM -0700 5/15/03, Eric Rescorla wrote: > > > You could have a security policy that ignored the > identity in the cert > >> ("allow an SA with these restrictions to anyone who has a > cert from > >> XYZRoot"), or one that was identity-based ("let > chris@example.com make > >> an SA"). > >But you would presumably want to have some restrictions > >on the IP addresses they were allowed to front for, right? > > Sure. you could, but there are plenty of cases (the roaming user) where there is no need. Those of us advocating the disassociation are not saying 100% disassociate. We are saying make the base-line MUST disassociation, but allow the user's the ability in configuration to associate and look for ID in a certain place in the cert IF THEY WANT. That way, the 10% of the cert users that want to associate will get what they need, and the rest of the 90% will have something that works easily. This is the basic convenience vs. security continuum. Our job as protocol designers is to give the people something they can use. 20% want it super secure at the cost of convenience. 80% want it secure, but convenient, and are willing to make the trade-off from the super-secure. The text I proposed tried to reach this goal. From owner-ipsec@lists.tislabs.com Thu May 15 10:43:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FHhPAF018288; Thu, 15 May 2003 10:43:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16739 Thu, 15 May 2003 13:01:04 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66D97@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Subject: RE: feedback on algorithms-00 Date: Thu, 15 May 2003 09:59:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk including the list... > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, May 15, 2003 7:49 AM > To: Gregory Lebovitz > Subject: Re: feedback on ipsec-algorithms-00 > > > >- Makes perfect sense to have this separate from the actual > proto docs. > >Thanks for getting it done. > > Your welcome. See below. > > >- Sect 2, first sentence, typo "used in IKEv2 for may security..." > > Thanks, go it. > > >- format help: would be nice in 2.1-2.4 to add a 4th column > to each chart > >that holds MUST, SHOULD, etc. That way the reader can see > what's what very > >quickly. > > I didn't do that because of the difference between "MUST today" and > "MUST tomorrow". That is, I wanted to keep the wording below the > tables being definitive. no argument about keeping the wording; I wouldn't have suggested removing it. Adding the column will make ingestion easier on the reader. Additionally, you could put a "*" by the SHOULD that calls to text below highlighting the "MUST Later" stuff. > >- 2.4 - the DH values for 1-5 are currently defined in > [IKEv2]. Since this > >is the crypto doc, shouldn't we pull those definitions out > of the [IKEv2] > >and into this doc, along with the definitions of values for > the others? > > Yes, but no one had a strong opinion on this. I'd say just do it and see if anyone screams. Probably no one will care, and most will think its a good idea. > > > - second sentence says values 6-200. But really it is > 6-13, 19-200, right? > >Because 14-18 are defined in [MODP]? > > Correct; good catch. > > > >- 3.0 1st para, last sentence, TYPO: "Instead *they* give..." > > Fixed. > > >-3.x - I really like the idea of doing suites via > "profiling" that dictates > >the suites we will all use in practice, while the actual > protocol should > >call for "a la carte" method of SA proposal. It makes for > (a) a much more > >powerful and flexible protocol, while (b) providing the ease > of use and > >crypto sanity checking that are needed on both ends of the > >security/convenience spectrum. We can even name them the > same thing in our > >UI's, which will make interop all that much easier. > > Exactly. From owner-ipsec@lists.tislabs.com Thu May 15 12:08:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FJ8EAF022395; Thu, 15 May 2003 12:08:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17076 Thu, 15 May 2003 14:37:21 -0400 (EDT) Message-Id: <5.0.2.1.0.20030515113452.024cd510@10.1.5.10> X-Sender: suren@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 May 2003 11:41:10 -0700 To: Gregory Lebovitz , "'Ravi'" From: suren Subject: RE: Peer liveliness Cc: Michael Choung Shieh , "'ddukes@cisco.com'" , ipsec@lists.tislabs.com In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66D8F@SARATOGA.netscreen. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gregory, The mechanism you suggested (INITIAL-CONTACT + rebooted-peer initiating IKE (with those two conditions) + aliveness detection) may not work with in the scenario of a roaming client. Suppose, a Roaming client (with a dynamic IP address) tunnels to a Corporate network, and corporate SG is acting as responder only. Now if corporate SG is rebooted, it is not able to send INITIAL_CONTACT to the Roaming client (dynamic IP address). Corporate SG can not even initiate the IKE, since it does not contain IP address of roaming client, which is dynamic. Suren. Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA www.intotoinc.com At 01:15 AM 5/15/2003 -0700, Gregory Lebovitz wrote: >w/in... -----Original Message----- From: Ravi [mailto:ravivsn@roc.co.in] >Sent: Sunday, May 04, 2003 9:21 PM To: Gregory Lebovitz Cc: Michael Choung >Shieh; ddukes@cisco.com'; ipsec@lists.tislabs.com Subject: Re: eer >liveliness Hi, In the text below, I also try to use the same terminology >used by you. Rebooted Peer and Persistent Peer. In your email, under >'Recommendations to solve the solution', regarding second point: In my >view, whether Peer is alive or not does not solve the problem completely. >Persistent node should know aliveness of Tunnel on the other side. It is >possible that peer reboots and responds to DPD requests, but tunnels are >not there. We should have a mechanism to detect the Tunnel aliveness. >[GML] I think Charlie addressed this by saying that once the IKE-SA is >revived, one or the other would have sent the INITIAL-CONTACT. When this >happens, the other peer will delete old SAs, including CHILD-SAs. So, once >IKE establishes, traffic will cause creation of new CHILD-SA (IPsec), so >tunnel will come alive. Does this address your concern? With respect to >DoS attack: You addressed the issue of DoS attack on the persistent side. >I am also concerned about DoS attack on rebooting machine. If MITM keeps >sending the packets with some dummy SPI and valid source IP, then the >IPSEC SG keeps sending the INVALID_SPI and for this,it keeps creating IKE >SAs. That is one of the reason, some implementations do not support >generationof INVALID_SPI notifications. [GML] I'm not proposing use of >INVALID_SPI; I specifically said I thought INVALID_SPI was bad. Im >proposing rebooted-peer initates IKE to sender of invalid SPI if -- and >ONLY IF-- two conditions are met: (1) no current valid SAs with sender, >(2) sender is valid peer in SPD These two checks mitigate the DoS issue >almost completely. (see my other email for discussion of threat analysis >on this one). The more I hash this through with various people, the more >I'm becoming convinced that INITIAL-CONTACT + rebooted-peer initiating IKE >(with above two conditions) + aliveness detection is the only way to catch >all the failure cases. Gregory. From owner-ipsec@lists.tislabs.com Thu May 15 14:10:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FLA4AF028057; Thu, 15 May 2003 14:10:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17520 Thu, 15 May 2003 16:43:54 -0400 (EDT) Message-Id: <200305152049.h4FKnBtN003703@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Peer liveliness In-reply-to: Your message of "Thu, 15 May 2003 11:41:10 PDT." <5.0.2.1.0.20030515113452.024cd510@10.1.5.10> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 May 2003 16:49:10 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "suren" == suren writes: suren> The mechanism you suggested (INITIAL-CONTACT + rebooted-peer suren> initiating IKE (with those two conditions) + aliveness detection) suren> may not work with in the scenario of a roaming client. I partially agree. I think that DPD can be made to work for most remote-access scenarios. suren> Suppose, a Roaming client (with a dynamic IP address) tunnels to a suren> Corporate network, and corporate SG is acting as responder only. suren> Now if suren> corporate SG is rebooted, it is not able to send INITIAL_CONTACT The situation of rebooting the SG is not an isolated case. This is a general problem with any system where all the policy is not known at boot time. In the end game of IPsec on every host, and applications asking for security, this will be very common. The Opportunistic Encryption system that the FreeS/WAN team has developped has this problem as well. I have been working on a system of birth certificates, as first suggested by Bill Summerfeld. In such a system, when a system receives an ESP (AH) packet with an unknown SPI, it emits a digitally signed message giving its boot count. The signature need only been done once per boot. If one receives such a message, and it is greater than a boot count sent in IKE for that connection, then one starts phase 1 again. Sounds simple, doesn't it? There are a number of details that need to be resolved: 1) what is the form of the message? ICMP? UDP to port 500? ICMP may be hard for the IKE daemon to actually get, but is architecturally cleaner. 2) the signature block should be kept as simple as possible. What is the host has multiple identities? Is the IP address that one originates included in the signature? 3) the boot count keeps replays from previous reboots, but does not keep the packet from the current reboot from being replayed, causing potential DOS on IKE. As such, I'd want to have the IKE do some kind of acclerated DPD in IKE when it gets this signal that the host has rebooted. An attacker could also be generating ICMP port unreachables as well. suren> Suren. suren> Intoto Inc. suren> 3160, De La Cruz Blvd #100 suren> Santa Clara, CA suren> www.intotoinc.com ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsP9KYqHRg3pndX9AQFCMwP/UYYbQYKSGefNFTJWcjAm7VV1s74kAmjT wvCEumzfzfHGDFjnPJ5GFCzskLYEY1nFDm6dEr/GqkrvaRXWuYBbM26C8jHON/k2 eAXG+vGL9kLxb4nZyIWV3d5E0aZ2M7tptIUIua8Q2oeLkG7gky958FajfDdQtRz2 qIuPspnbXP0= =BpFF -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu May 15 14:11:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FLBbAF028150; Thu, 15 May 2003 14:11:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17454 Thu, 15 May 2003 16:28:00 -0400 (EDT) Message-ID: <3EC3F9F8.CA64006A@airespace.com> Date: Thu, 15 May 2003 13:35:04 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Lebovitz CC: "'Paul Hoffman / VPNC'" , "'EKR'" , "'ipsec@lists.tislabs.com'" Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D96@SARATOGA.netscreen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2003 20:32:52.0393 (UTC) FILETIME=[28812990:01C31B21] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Gregory, Gregory Lebovitz wrote: > you could, but there are plenty of cases (the roaming user) where there is > no need. Those of us advocating the disassociation are not saying 100% > disassociate. We are saying make the base-line MUST disassociation, but > allow the user's the ability in configuration to associate and look for ID > in a certain place in the cert IF THEY WANT. That way, the 10% of the cert > users that want to associate will get what they need, and the rest of the > 90% will have something that works easily. > > This is the basic convenience vs. security continuum. Our job as protocol > designers is to give the people something they can use. 20% want it super > secure at the cost of convenience. 80% want it secure, but convenient, and > are willing to make the trade-off from the super-secure. The text I proposed > tried to reach this goal. In terms of convenience, I can't think of a more convenient way to configure a cert-authenticated tunnel for an ipsec client than by saying "use this cert" and leaving it at that. Having to select a cert *and* an ID is not simpler than just selecting a cert. This may be slightly less convenient for the one who codes the receiver (since the receiver now has to extract an ID from the cert prior to doing a policy lookup), but forcing the client configuration to contain an ID acceptable to the sgw is not, but any stretch, more convenient than this. And leaving off the ID config is more secure in some cases as well. Scott From owner-ipsec@lists.tislabs.com Thu May 15 14:59:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FLxCAF029518; Thu, 15 May 2003 14:59:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17655 Thu, 15 May 2003 17:25:26 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16068.1766.561003.133227@thomasm-u1.cisco.com> Date: Thu, 15 May 2003 14:30:14 -0700 (PDT) To: EKR Cc: Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Paul Hoffman / VPNC writes: > > > At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: > > >Hmm... I see your point. I was speculating that this would mean > > >that you didn't much care what was in the certificate. > > > > You could have a security policy that ignored the identity in the cert > > ("allow an SA with these restrictions to anyone who has a cert from > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > an SA"). > But you would presumably want to have some restrictions > on the IP addresses they were allowed to front for, right? Why? Are you thinking of this only in terms of tunnels? Mike From owner-ipsec@lists.tislabs.com Thu May 15 15:01:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FM1ZAF029576; Thu, 15 May 2003 15:01:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17686 Thu, 15 May 2003 17:32:48 -0400 (EDT) To: Michael Thomas Cc: Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 15 May 2003 14:43:29 -0700 In-Reply-To: <16068.1766.561003.133227@thomasm-u1.cisco.com> Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > > Paul Hoffman / VPNC writes: > > > > > At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: > > > >Hmm... I see your point. I was speculating that this would mean > > > >that you didn't much care what was in the certificate. > > > > > > You could have a security policy that ignored the identity in the cert > > > ("allow an SA with these restrictions to anyone who has a cert from > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > > an SA"). > > But you would presumably want to have some restrictions > > on the IP addresses they were allowed to front for, right? > > Why? Are you thinking of this only in terms of > tunnels? No. Many of the same considerations apply for machine to machine SAs. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu May 15 15:02:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FM29AF029600; Thu, 15 May 2003 15:02:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17711 Thu, 15 May 2003 17:35:57 -0400 (EDT) Message-Id: <200305152141.h4FLfG1S004936@sandelman.ottawa.on.ca> To: "'ipsec@lists.tislabs.com'" Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Thu, 15 May 2003 13:35:04 PDT." <3EC3F9F8.CA64006A@airespace.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 May 2003 17:41:16 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> In terms of convenience, I can't think of a more convenient way to Scott> configure a cert-authenticated tunnel for an ipsec client than by Scott> saying "use this cert" and leaving it at that. Having to select a Scott> cert *and* an I agree with you here. But, I think that you still want to drop the IDi payload here. Can we add something like the hash of the public key (or cert) here as the ID? That can be derived automatically by the client, and it provides a hook by which a server might be able to lookup the right key, should it find the certificate itself not to its liking. I really do not want to make the IDi optional. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsQJeoqHRg3pndX9AQGYTgQAqzIns2gt5R7dw9t9Cp5nmAFedIzDZ2rz BZFYtJIyJfCzPx+KDUXtmmJPxFOLB4YmWl7D39d3LrKsslS5gx1Dsk53t3BliAy+ PV8TQLr+Opg+AbKPv/HjgYT0dFMptmat8AZ9b6R6dW+lA8tPtOxe9tuHsrkZrDAE Q5x3ZYfuwwU= =3rx1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu May 15 15:12:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FMBwAF029783; Thu, 15 May 2003 15:12:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17742 Thu, 15 May 2003 17:43:55 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16068.2874.797405.258729@thomasm-u1.cisco.com> Date: Thu, 15 May 2003 14:48:42 -0700 (PDT) To: EKR Cc: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Michael Thomas writes: > > > Eric Rescorla writes: > > > Paul Hoffman / VPNC writes: > > > > > > > At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: > > > > >Hmm... I see your point. I was speculating that this would mean > > > > >that you didn't much care what was in the certificate. > > > > > > > > You could have a security policy that ignored the identity in the cert > > > > ("allow an SA with these restrictions to anyone who has a cert from > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > > > an SA"). > > > But you would presumably want to have some restrictions > > > on the IP addresses they were allowed to front for, right? > > > > Why? Are you thinking of this only in terms of > > tunnels? > No. > > Many of the same considerations apply for machine to machine SAs. Well, I don't see it. The desire to restrict or permit based on header classification seems completely orthogonal to the policy decision of what constitutes "authenticated enough". Why should a policy of "*@foo.com" have to be further qualified with "from 1.2.3.0/24" as well? You might want to do that, but then again you might not. The former may be perfectly adequate securitywise. Mike From owner-ipsec@lists.tislabs.com Thu May 15 15:26:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FMQnAF030188; Thu, 15 May 2003 15:26:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17817 Thu, 15 May 2003 18:03:29 -0400 (EDT) To: Michael Thomas Cc: Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 15 May 2003 15:14:14 -0700 In-Reply-To: <16068.2874.797405.258729@thomasm-u1.cisco.com> Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > > Michael Thomas writes: > > > > > Eric Rescorla writes: > > > > Paul Hoffman / VPNC writes: > > > > > > > > > At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: > > > > > >Hmm... I see your point. I was speculating that this would mean > > > > > >that you didn't much care what was in the certificate. > > > > > > > > > > You could have a security policy that ignored the identity in the cert > > > > > ("allow an SA with these restrictions to anyone who has a cert from > > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > > > > an SA"). > > > > But you would presumably want to have some restrictions > > > > on the IP addresses they were allowed to front for, right? > > > > > > Why? Are you thinking of this only in terms of > > > tunnels? > > No. > > > > Many of the same considerations apply for machine to machine SAs. > > Well, I don't see it. The desire to restrict or > permit based on header classification seems > completely orthogonal to the policy decision of > what constitutes "authenticated enough". Huh? Because I want to be able to have applications make security decisions based on the IP address of the peer and that means that the certificate has to be bound to the IP address. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu May 15 15:41:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FMfQAF030546; Thu, 15 May 2003 15:41:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17858 Thu, 15 May 2003 18:17:37 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16068.4891.347265.835899@thomasm-u1.cisco.com> Date: Thu, 15 May 2003 15:22:19 -0700 (PDT) To: EKR Cc: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Michael Thomas writes: > > > Eric Rescorla writes: > > > Michael Thomas writes: > > > > > > > Eric Rescorla writes: > > > > > Paul Hoffman / VPNC writes: > > > > > > > > > > > At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: > > > > > > >Hmm... I see your point. I was speculating that this would mean > > > > > > >that you didn't much care what was in the certificate. > > > > > > > > > > > > You could have a security policy that ignored the identity in the cert > > > > > > ("allow an SA with these restrictions to anyone who has a cert from > > > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > > > > > an SA"). > > > > > But you would presumably want to have some restrictions > > > > > on the IP addresses they were allowed to front for, right? > > > > > > > > Why? Are you thinking of this only in terms of > > > > tunnels? > > > No. > > > > > > Many of the same considerations apply for machine to machine SAs. > > > > Well, I don't see it. The desire to restrict or > > permit based on header classification seems > > completely orthogonal to the policy decision of > > what constitutes "authenticated enough". > Huh? Because I want to be able to have applications make security > decisions based on the IP address of the peer and that means that > the certificate has to be bound to the IP address. But that doesn't imply that has to be done in every scenario. Suppose I set up a service at to view pictures on a protected web site. I issue certificates to my friends which allows them past the IPsec barrier on my web server host. I don't care who they are -- just that it's somebody who I issued a cert to -- and most especially don't care where they happen to have internet connectivity at the time. Are you saying this is an illegitimate use of IPsec/IKE? Mike From owner-ipsec@lists.tislabs.com Thu May 15 21:29:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4G4TsAF039643; Thu, 15 May 2003 21:29:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA18951 Thu, 15 May 2003 23:56:09 -0400 (EDT) To: Michael Thomas Cc: Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <16068.4891.347265.835899@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 15 May 2003 21:06:52 -0700 In-Reply-To: <16068.4891.347265.835899@thomasm-u1.cisco.com> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > But that doesn't imply that has to be done in > every scenario. Suppose I set up a service at to > view pictures on a protected web site. I issue > certificates to my friends which allows them past > the IPsec barrier on my web server host. I don't > care who they are -- just that it's somebody who I > issued a cert to -- and most especially don't care > where they happen to have internet connectivity at > the time. > > Are you saying this is an illegitimate use of > IPsec/IKE? No, but I'd like to see the more complete case specified and the case you're describing as a less complete variation rather than simply ignoring the complete case as people seem wont to do. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu May 15 22:54:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4G5s6AF042841; Thu, 15 May 2003 22:54:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA19220 Fri, 16 May 2003 01:21:42 -0400 (EDT) Message-ID: <3EC4789D.8010904@roc.co.in> Date: Fri, 16 May 2003 11:05:25 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gregory Lebovitz CC: Michael Choung Shieh , "'ddukes@cisco.com'" , ipsec@lists.tislabs.com Subject: Re: Peer liveliness References: <541402FFDC56DA499E7E13329ABFEA87E66D8F@SARATOGA.netscreen.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Gregory, I agree that Initial-Contact solves the problem most part, but not always.It works fine when there are site-to-site tunnels where both SGs have static IP addresses. But, this is not the case always atleast in my part of world. Let me take an example: Branch office network Head office network | | | | Security Gateway1-----Internet-------Security Gateway2 SG2 has static IP address and that can be configured as Peer SG IP address in Security Gateway1. But SG1 does not have static IP address and it gets the public IP address via DHCP client OR PPP from ISP. In the above configuration, SG2 is always responder and SG1 is always intiator. The way it works is that, whenever SG1 gets the IP address, it makes the tunnel with SG2. Considering above scenario: When SG2 restarts, since it does not know the SG1's IP address, it can't send the INITIAL-CONTACT message. 2. There is no way to guarantee that Initial contact message is sent/received reliably. I feel it is always better to find out liveness of tunnel pro-actively, rather than entirely depending on peer to inform that it is dead and cameback. Regards Ravi Gregory Lebovitz wrote: > w/in... > > -----Original Message----- > From: Ravi [mailto:ravivsn@roc.co.in] > Sent: Sunday, May 04, 2003 9:21 PM > To: Gregory Lebovitz > Cc: Michael Choung Shieh; 'ddukes@cisco.com'; ipsec@lists.tislabs.com > Subject: Re: Peer liveliness > > Hi, > In the text below, I also try to use the same terminology used by you. > Rebooted Peer and Persistent Peer. > > In your email, under 'Recommendations to solve the solution', regarding > second point: > In my view, whether Peer is alive or not does not solve the problem completely. > Persistent node should know aliveness of Tunnel on the other side. It is possible that > peer reboots and responds to DPD requests, but tunnels are not there. We should > have a mechanism to detect the Tunnel aliveness. > [GML] I think Charlie addressed this by saying that once the IKE-SA is revived, one or the other would have sent the INITIAL-CONTACT. When this happens, the other peer will delete old SAs, including CHILD-SAs. So, once IKE establishes, traffic will cause creation of new CHILD-SA (IPsec), so tunnel will come alive. Does this address your concern? > > With respect to DoS attack: > You addressed the issue of DoS attack on the persistent side. I am also concerned > about DoS attack on rebooting machine. If MITM keeps sending the packets with > some dummy SPI and valid source IP, then the IPSEC SG keeps sending the > INVALID_SPI and for this,it keeps creating IKE SAs. That is one of the reason, > some implementations do not support generationof INVALID_SPI notifications. > [GML] I'm not proposing use of INVALID_SPI; I specifically said I thought INVALID_SPI was bad. Im proposing rebooted-peer initates IKE to sender of invalid SPI if -- and ONLY IF-- two conditions are met: > > (1) no current valid SAs with sender, > > (2) sender is valid peer in SPD > > These two checks mitigate the DoS issue almost completely. (see my other email for discussion of threat analysis on this one). > > The more I hash this through with various people, the more I'm becoming convinced that INITIAL-CONTACT + rebooted-peer initiating IKE (with above two conditions) + aliveness detection is the only way to catch all the failure cases. > > Gregory. > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Thu May 15 23:07:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4G671AF045271; Thu, 15 May 2003 23:07:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA19314 Fri, 16 May 2003 01:41:10 -0400 (EDT) Message-ID: <3EC47D20.1090800@roc.co.in> Date: Fri, 16 May 2003 11:24:40 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gregory Lebovitz CC: "'Paul Hoffman / VPNC'" , "'EKR'" , "'Scott G. Kelly'" , "'ipsec@lists.tislabs.com'" Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D96@SARATOGA.netscreen.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am trying to understand the issues. Some time back, there was rough consensus that 'Matching ID payload data with certificate Identification' is local matter as a receiver. As a sender, implementation need to make sure to send ID payload data same as Certificate ID as the receiver may be checking for equality of both IDs. If the sender knows that receiver does not check for the equality, then the sender can send different IDs between ID payload from certificate ID. Some implementations already do this for supporting remote access. In remote access, road warriors are initiators and Corporate SG is typically configured in 'Responder' only mode. One IKE policy is created with - Wild card domain name as peer ID. For example, *.abc.com can be give as Peer ID. Then all remote access users whose IDs are ending with abc.com will be authenticating using this IKE policy. - Accept any whose signing CA is 'DN of CA'. This is typically useful when corporate office has their own CA and anybody got certificate from this CA is authenticated using this policy. In above examples, really there is no check between ID payload and Certificate in verbatim. It is local decision. Can't we leave the decision of IDs check as local decision? What type of additional simplification are we trying to make it for easy deployment? Thanks and regards Ravi Gregory Lebovitz wrote: > >>At 8:29 AM -0700 5/15/03, Eric Rescorla wrote: >> >>> > You could have a security policy that ignored the >> >>identity in the cert >> >>>> ("allow an SA with these restrictions to anyone who has a >>> >>cert from >> >>>> XYZRoot"), or one that was identity-based ("let >>> >>chris@example.com make >> >>>> an SA"). >>> >>>But you would presumably want to have some restrictions >>>on the IP addresses they were allowed to front for, right? >> >>Sure. > > > you could, but there are plenty of cases (the roaming user) where there is > no need. Those of us advocating the disassociation are not saying 100% > disassociate. We are saying make the base-line MUST disassociation, but > allow the user's the ability in configuration to associate and look for ID > in a certain place in the cert IF THEY WANT. That way, the 10% of the cert > users that want to associate will get what they need, and the rest of the > 90% will have something that works easily. > > This is the basic convenience vs. security continuum. Our job as protocol > designers is to give the people something they can use. 20% want it super > secure at the cost of convenience. 80% want it secure, but convenient, and > are willing to make the trade-off from the super-secure. The text I proposed > tried to reach this goal. > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Fri May 16 05:58:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GCwSAF089629; Fri, 16 May 2003 05:58:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20292 Fri, 16 May 2003 08:25:24 -0400 (EDT) Message-ID: <3EC406DC.2458A307@airespace.com> Date: Thu, 15 May 2003 14:30:04 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Fwd: Confirm decision on identity handling.] Content-Type: multipart/mixed; boundary="------------F4E004E56894710C02B639AD" X-OriginalArrivalTime: 15 May 2003 21:27:53.0129 (UTC) FILETIME=[D7E58190:01C31B28] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------F4E004E56894710C02B639AD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Meant to reply to the list... --------------F4E004E56894710C02B639AD Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3EC406AD.A97EB58@airespace.com> Date: Thu, 15 May 2003 14:29:17 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Lebovitz Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Gregory, Gregory Lebovitz wrote: > > Paul is totally right on this one. From experience with Project Dploy, where > we tried to get better interop between IPsec vendors and PKI vendors after > talking to many customers about actual usage issues, this is what we found: > It is a daunting task for the deployers to get the cert contents to match > exactly what the VPN application needs. This is true for a variety of > reasons, many of which Paul noted below. The biggest is that often the VPN > deployer has little or zero impact/control/say in how the CA builds certs. > It's just not reality to expect that the VPN can dictate or ensure some > field in the Cert will contain what they need. > > This is why many of us have been pushing for disassociating the two. I agree with Paul (and you) that it is difficult to reconcile the way some PKI vendors build certs with the way identities are expressed in ipsec policies (and ID payloads), although there are ways to build DN filters if one is determined to solve these problems. However, the bottom line is that if certs are to be meaningful as ipsec authenticators, then there must be *some* way to identify acceptable certs in the recipient's policy. And as an aside, I'll point out that IPsec deployments are not constrained to using a particular PKI vendor's certs - many vpn vendors have fielded CAs which *can* build appropriately structured certs (if only we could all agree on what that means from an interop standpoint). Even if you say the ID is not related to the cert in any way, you still have a problem, though: you must, upon deriving a policy based on the ID, verify that the cert matches the policy somehow - you must be able to represent a certificate filter in your policy no matter which way you do this. And you must ensure that if there are multiple policies for which the same cert might be acceptable, that only the "correct" one is chosen. This implies the ID must be bound to the cert somehow. Again, I suggest that we consider not *requiring* ID payloads with certs (relying instead upon the recipient to derive an identity from the cert), and that if we must support ID payloads when certs are used, that processing the ID payloads be optional, so that two independent implementations are able to interoperate whether they are present or not (even if the recipient ignores the ID payload). Scott --------------F4E004E56894710C02B639AD-- From owner-ipsec@lists.tislabs.com Fri May 16 08:06:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GF6UAF097556; Fri, 16 May 2003 08:06:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20612 Fri, 16 May 2003 10:29:29 -0400 (EDT) To: Uri Blumenthal Cc: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 07:40:15 -0700 In-Reply-To: <3EC4F58A.1000200@bell-labs.com> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal writes: > Eric Rescorla wrote: > >> > > > > You could have a security policy that ignored the identity in the cert > >> > > > > ("allow an SA with these restrictions to anyone who has a cert from > >> > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > >> > > > > an SA"). > >>Well, I don't see it. The desire to restrict or > >>permit based on header classification seems > >>completely orthogonal to the policy decision of > >>what constitutes "authenticated enough". > > Huh? Because I want to be able to have applications make security > > > decisions based on the IP address of the peer and that means that > > the certificate has to be bound to the IP address. > > I jumped in late, so probably missed some important parts of this > conversation. But binding certificates to IP addresses doesn't > seem like a good idea at all, because of how short IP address > lifespan may be. Given the kind of information the stack has, there are many cases where this is the only reasonable thing they might be bound to. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 08:11:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFBaAF097741; Fri, 16 May 2003 08:11:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20638 Fri, 16 May 2003 10:42:01 -0400 (EDT) Cc: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Message-ID: <3EC4F58A.1000200@bell-labs.com> Date: Fri, 16 May 2003 10:28:26 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: EKR Original-CC: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla wrote: >> > > > > You could have a security policy that ignored the identity in the cert >> > > > > ("allow an SA with these restrictions to anyone who has a cert from >> > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make >> > > > > an SA"). >>Well, I don't see it. The desire to restrict or >>permit based on header classification seems >>completely orthogonal to the policy decision of >>what constitutes "authenticated enough". > > Huh? Because I want to be able to have applications make security > decisions based on the IP address of the peer and that means that > the certificate has to be bound to the IP address. I jumped in late, so probably missed some important parts of this conversation. But binding certificates to IP addresses doesn't seem like a good idea at all, because of how short IP address lifespan may be. AFTER the authentication it may be reasonable to "fix" the IP address to the just-established SA and dance from there for the SA's duration... But that has little to do with certs. If I really didn't get it, feel free to clue me in. From owner-ipsec@lists.tislabs.com Fri May 16 08:21:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFLDAF098274; Fri, 16 May 2003 08:21:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20678 Fri, 16 May 2003 10:53:05 -0400 (EDT) Cc: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Message-ID: <3EC4FB5E.3090002@bell-labs.com> Date: Fri, 16 May 2003 10:53:18 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: EKR Original-CC: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla wrote: >>I jumped in late, so probably missed some important parts of this >>conversation. But binding certificates to IP addresses doesn't >>seem like a good idea at all, because of how short IP address >>lifespan may be. > > Given the kind of information the stack has, there are many > cases where this is the only reasonable thing they might be > bound to. The only information - perhaps. That still doesn't make it reasonable. For example, (I know you anticipate this :-) think DHCP. From owner-ipsec@lists.tislabs.com Fri May 16 08:25:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFOwAF098413; Fri, 16 May 2003 08:25:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20703 Fri, 16 May 2003 10:58:27 -0400 (EDT) To: Uri Blumenthal Cc: Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <3EC4FB5E.3090002@bell-labs.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 08:09:13 -0700 In-Reply-To: <3EC4FB5E.3090002@bell-labs.com> Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal writes: > Eric Rescorla wrote: > >>I jumped in late, so probably missed some important parts of this > >>conversation. But binding certificates to IP addresses doesn't > >>seem like a good idea at all, because of how short IP address > >>lifespan may be. > > Given the kind of information the stack has, there are many > > > cases where this is the only reasonable thing they might be bound to. > > > The only information - perhaps. That still doesn't make it > reasonable. For example, (I know you anticipate this :-) > think DHCP. Think DHCP certificates :) -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 08:53:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFrTAF000237; Fri, 16 May 2003 08:53:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20814 Fri, 16 May 2003 11:20:08 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16069.704.149820.605667@thomasm-u1.cisco.com> Date: Fri, 16 May 2003 08:24:48 -0700 (PDT) To: EKR Cc: Uri Blumenthal , Michael Thomas , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Uri Blumenthal writes: > > > Eric Rescorla wrote: > > >> > > > > You could have a security policy that ignored the identity in the cert > > >> > > > > ("allow an SA with these restrictions to anyone who has a cert from > > >> > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > >> > > > > an SA"). > > >>Well, I don't see it. The desire to restrict or > > >>permit based on header classification seems > > >>completely orthogonal to the policy decision of > > >>what constitutes "authenticated enough". > > > Huh? Because I want to be able to have applications make security > > > > > decisions based on the IP address of the peer and that means that > > > the certificate has to be bound to the IP address. > > > > I jumped in late, so probably missed some important parts of this > > conversation. But binding certificates to IP addresses doesn't > > seem like a good idea at all, because of how short IP address > > lifespan may be. > Given the kind of information the stack has, there are many > cases where this is the only reasonable thing they might be > bound to. Ok, I'll bite: what are some of those cases? It can't be the actual IPsec SA since that's fully described by the SPI (excepting multicast). And a CA which issues a cert for mat@cisco.com is a fully unique identifier, so I don't need additional information in the form of the routing tag to disambiguate the identity. So what information is it that the stack is lacking that would *require* use of an IP address in the credential itself? I'm with Uri. Binding IP addresses to certs sucks. Think mobile IP. Mike From owner-ipsec@lists.tislabs.com Fri May 16 09:07:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GG71AF001768; Fri, 16 May 2003 09:07:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20873 Fri, 16 May 2003 11:33:50 -0400 (EDT) To: Michael Thomas Cc: Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 08:44:36 -0700 In-Reply-To: <16069.704.149820.605667@thomasm-u1.cisco.com> Message-ID: Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > > Uri Blumenthal writes: > > > > > Eric Rescorla wrote: > > > >> > > > > You could have a security policy that ignored the identity in the cert > > > >> > > > > ("allow an SA with these restrictions to anyone who has a cert from > > > >> > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > > >> > > > > an SA"). > > > >>Well, I don't see it. The desire to restrict or > > > >>permit based on header classification seems > > > >>completely orthogonal to the policy decision of > > > >>what constitutes "authenticated enough". > > > > Huh? Because I want to be able to have applications make security > > > > > > > decisions based on the IP address of the peer and that means that > > > > the certificate has to be bound to the IP address. > > > > > > I jumped in late, so probably missed some important parts of this > > > conversation. But binding certificates to IP addresses doesn't > > > seem like a good idea at all, because of how short IP address > > > lifespan may be. > > Given the kind of information the stack has, there are many > > cases where this is the only reasonable thing they might be > > bound to. > > Ok, I'll bite: what are some of those cases? It > can't be the actual IPsec SA since that's fully > described by the SPI (excepting multicast). And a > CA which issues a cert for mat@cisco.com is a > fully unique identifier, so I don't need > additional information in the form of the routing > tag to disambiguate the identity. So what > information is it that the stack is lacking that > would *require* use of an IP address in the > credential itself? Huh? The user asks you to initiate a TCP connection to 1.2.3.4. How else do you propose to ensure that you've done that other than by checking the certificate at SA establishment time? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 09:24:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GGOgAF002443; Fri, 16 May 2003 09:24:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20954 Fri, 16 May 2003 11:50:12 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16069.2510.321906.770452@thomasm-u1.cisco.com> Date: Fri, 16 May 2003 08:54:54 -0700 (PDT) To: EKR Cc: Michael Thomas , Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Michael Thomas writes: > > > Eric Rescorla writes: > > > Uri Blumenthal writes: > > > > > > > Eric Rescorla wrote: > > > > >> > > > > You could have a security policy that ignored the identity in the cert > > > > >> > > > > ("allow an SA with these restrictions to anyone who has a cert from > > > > >> > > > > XYZRoot"), or one that was identity-based ("let chris@example.com make > > > > >> > > > > an SA"). > > > > >>Well, I don't see it. The desire to restrict or > > > > >>permit based on header classification seems > > > > >>completely orthogonal to the policy decision of > > > > >>what constitutes "authenticated enough". > > > > > Huh? Because I want to be able to have applications make security > > > > > > > > > decisions based on the IP address of the peer and that means that > > > > > the certificate has to be bound to the IP address. > > > > > > > > I jumped in late, so probably missed some important parts of this > > > > conversation. But binding certificates to IP addresses doesn't > > > > seem like a good idea at all, because of how short IP address > > > > lifespan may be. > > > Given the kind of information the stack has, there are many > > > cases where this is the only reasonable thing they might be > > > bound to. > > > > Ok, I'll bite: what are some of those cases? It > > can't be the actual IPsec SA since that's fully > > described by the SPI (excepting multicast). And a > > CA which issues a cert for mat@cisco.com is a > > fully unique identifier, so I don't need > > additional information in the form of the routing > > tag to disambiguate the identity. So what > > information is it that the stack is lacking that > > would *require* use of an IP address in the > > credential itself? > Huh? The user asks you to initiate a TCP connection to > 1.2.3.4. How else do you propose to ensure that you've > done that other than by checking the certificate at > SA establishment time? You didn't answer my question. And I hardly know where to start on the identity/routing tag conflation you seem to be making. There isn't a binding in IPsec between TCP connection -- or any sort of transport connection -- and the SA establishment, so your question is a non-sequitur. IP addresses can be used as identities, but so can RFC 822 addresses, etc. And IP addresses have huge downsides, especially for mobility, unlike RFC 822 addresses. Any desire to use IP addresses as identities should be considered harmful. Mike From owner-ipsec@lists.tislabs.com Fri May 16 09:40:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GGeMAF004617; Fri, 16 May 2003 09:40:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21048 Fri, 16 May 2003 12:12:43 -0400 (EDT) To: Michael Thomas Cc: Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 09:23:28 -0700 In-Reply-To: <16069.2510.321906.770452@thomasm-u1.cisco.com> Message-ID: Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > > Huh? The user asks you to initiate a TCP connection to > > 1.2.3.4. How else do you propose to ensure that you've > > done that other than by checking the certificate at > > SA establishment time? > > You didn't answer my question. Obviously I didn't understand it, then. Try rephrasing it. > And I hardly know > where to start on the identity/routing tag > conflation you seem to be making. There isn't a > binding in IPsec between TCP connection -- or any > sort of transport connection -- and the SA > establishment, so your question is a non-sequitur. I'm afraid it's not. One of the major arguments in favor of IPsec is that it allows security-oblivious applications to be secured by enhancing the kernel. The only information that the kernel has about the desired peer endpoint when an application tries to transmit data is the IP address. Therefore it's the only information on which the decision can be made. Yes, I'm perfectly aware that the SAs aren't bound to TCP connections, but they can be bound to IP addresses and in this case the difference is a red herring. > IP addresses can be used as identities, but so can > RFC 822 addresses, etc. And IP addresses have huge > downsides, especially for mobility, unlike RFC 822 > addresses. RFC822 addresses have the disadvantage that the kernel doesn't know anything about them when you're trying to transmit packets. > Any desire to use IP addresses as > identities should be considered harmful. That's just, like, your opinion, man. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 10:19:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GHJJAF008929; Fri, 16 May 2003 10:19:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21244 Fri, 16 May 2003 12:51:09 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16069.6161.52480.563103@thomasm-u1.cisco.com> Date: Fri, 16 May 2003 09:55:45 -0700 (PDT) To: EKR Cc: Michael Thomas , Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Michael Thomas writes: > > Eric Rescorla writes: > > > Huh? The user asks you to initiate a TCP connection to > > > 1.2.3.4. How else do you propose to ensure that you've > > > done that other than by checking the certificate at > > > SA establishment time? > > > > You didn't answer my question. > Obviously I didn't understand it, then. Try rephrasing it. > > > And I hardly know > > where to start on the identity/routing tag > > conflation you seem to be making. There isn't a > > binding in IPsec between TCP connection -- or any > > sort of transport connection -- and the SA > > establishment, so your question is a non-sequitur. > I'm afraid it's not. One of the major arguments in favor of > IPsec is that it allows security-oblivious applications to > be secured by enhancing the kernel. The only information > that the kernel has about the desired peer endpoint when > an application tries to transmit data is the IP address. > Therefore it's the only information on which the decision > can be made. I think that what you're confusing here is the identity used to establish an SA and the general filtering mechanism that IPsec provides. It may be perfectly reasonable to have a policy which states: "For all transport mode connections, the filters should discard any source IP addresses != the IP address used in the IKE session." Or something like this. Note that this doesn't have anything to do with the *IKE* identity, it's completely a property of the SA and its filters that were derived from the policy which matched for the mode and identity. It does, however, enforce the property that you desired above, especially when combined with the fact that you need several round trips which establish that that entity is, in fact, reachable at the outgoing address. > > IP addresses can be used as identities, but so can > > RFC 822 addresses, etc. And IP addresses have huge > > downsides, especially for mobility, unlike RFC 822 > > addresses. > RFC822 addresses have the disadvantage that the kernel > doesn't know anything about them when you're trying to > transmit packets. Again, you seem to be conflating the IKE session identity and the packet filtering mechanism of IPsec. > > Any desire to use IP addresses as > > identities should be considered harmful. > That's just, like, your opinion, man. Well, mine and a lot of other people's I'd say. Mike From owner-ipsec@lists.tislabs.com Fri May 16 10:23:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GHNgAF009048; Fri, 16 May 2003 10:23:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21318 Fri, 16 May 2003 12:58:38 -0400 (EDT) To: Michael Thomas Cc: Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> <16069.6161.52480.563103@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 10:09:23 -0700 In-Reply-To: <16069.6161.52480.563103@thomasm-u1.cisco.com> Message-ID: Lines: 57 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > I think that what you're confusing here is the > identity used to establish an SA and the general > filtering mechanism that IPsec provides. It may > be perfectly reasonable to have a policy which > states: > > "For all transport mode connections, the filters > should discard any source IP addresses != the IP > address used in the IKE session." > > Or something like this. Note that this doesn't > have anything to do with the *IKE* identity, it's > completely a property of the SA and its filters > that were derived from the policy which matched > for the mode and identity. It does, however, > enforce the property that you desired above, > especially when combined with the fact that you > need several round trips which establish that that > entity is, in fact, reachable at the outgoing > address. You must be joking. What, you've never heard of active attacks? IP spoofing? Much of the purpose of the exercise is to protect ourselves from people who can arbitrarily manipulate the IP packet delivery service. > > > IP addresses can be used as identities, but so can > > > RFC 822 addresses, etc. And IP addresses have huge > > > downsides, especially for mobility, unlike RFC 822 > > > addresses. > > RFC822 addresses have the disadvantage that the kernel > > doesn't know anything about them when you're trying to > > transmit packets. > > Again, you seem to be conflating the IKE session > identity and the packet filtering mechanism of > IPsec. It's not that I'm conflating them but rather that they're bound by the logic of the desired security service. > > > Any desire to use IP addresses as > > > identities should be considered harmful. > > That's just, like, your opinion, man. > > Well, mine and a lot of other people's I'd say. That's fine, but you haven't convinced me and it doesn't really follow from anything you've said. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 11:20:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIKCAF010743; Fri, 16 May 2003 11:20:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21546 Fri, 16 May 2003 13:52:00 -0400 (EDT) To: Michael Thomas Cc: Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> <16069.6161.52480.563103@thomasm-u1.cisco.com> <16069.9666.270402.827655@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 11:02:45 -0700 In-Reply-To: <16069.9666.270402.827655@thomasm-u1.cisco.com> Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > > Michael Thomas writes: > > > Or something like this. Note that this doesn't > > > have anything to do with the *IKE* identity, it's > > > completely a property of the SA and its filters > > > that were derived from the policy which matched > > > for the mode and identity. It does, however, > > > enforce the property that you desired above, > > > especially when combined with the fact that you > > > need several round trips which establish that that > > > entity is, in fact, reachable at the outgoing > > > address. > > You must be joking. > > > > What, you've never heard of active attacks? IP spoofing? > > Yeah, yeah, and the application starting the TCP > connection got that IP address from DNS which > isn't secure either. What, you've never heard of DNSSEC? > > Much of the purpose of the exercise is to protect ourselves > > from people who can arbitrarily manipulate the IP packet > > delivery service. > > IPsec is an authenticated ACL traversal mechanism > not a miracle worker. It raises the bar > substantially, but there's a security/convenience > tradeoff that needs to be allowed. Tying > identities to routing tags has a substantial > number of drawbacks and leads us down some rather > unfortunate paths taken to its logical ends. Like, > oh say, ICAAN doling out IP address ownership > certificates. Ick. We also need to account for > deployability and unintended consequences. Strangely enough, this has worked just fine for TLS. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 11:22:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIMeAF010937; Fri, 16 May 2003 11:22:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21520 Fri, 16 May 2003 13:49:29 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16069.9666.270402.827655@thomasm-u1.cisco.com> Date: Fri, 16 May 2003 10:54:10 -0700 (PDT) To: EKR Cc: Michael Thomas , Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> <16069.6161.52480.563103@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Michael Thomas writes: > > Or something like this. Note that this doesn't > > have anything to do with the *IKE* identity, it's > > completely a property of the SA and its filters > > that were derived from the policy which matched > > for the mode and identity. It does, however, > > enforce the property that you desired above, > > especially when combined with the fact that you > > need several round trips which establish that that > > entity is, in fact, reachable at the outgoing > > address. > You must be joking. > > What, you've never heard of active attacks? IP spoofing? Yeah, yeah, and the application starting the TCP connection got that IP address from DNS which isn't secure either. Them's the breaks when you don't have tight binding between application layer logic and the security layer. Is it better than nothing? I'd say so. Thus we've already made our peace with various active attacks and all kinds of other insecure things that apps do in the global scheme of things. > Much of the purpose of the exercise is to protect ourselves > from people who can arbitrarily manipulate the IP packet > delivery service. IPsec is an authenticated ACL traversal mechanism not a miracle worker. It raises the bar substantially, but there's a security/convenience tradeoff that needs to be allowed. Tying identities to routing tags has a substantial number of drawbacks and leads us down some rather unfortunate paths taken to its logical ends. Like, oh say, ICAAN doling out IP address ownership certificates. Ick. We also need to account for deployability and unintended consequences. > > Again, you seem to be conflating the IKE session > > identity and the packet filtering mechanism of > > IPsec. > It's not that I'm conflating them but rather that they're > bound by the logic of the desired security service. You're not acknowledging the engineering tradeoffs that need to be accounted for. Very secure but undeployable isn't a solution. More secure and deployable often is, depending on the risks. Note that there are other routes that can be taken to shore up the security while using IPsec. An API down to the kernel IPsec as well as keying layer that apps could use would be an even larger improvement on the security front than IP addresses being used as identifiers. Regardless of what layer crypto is being done at, this is what is ultimately needed (and one thing that TLS has a large advantage over IPsec, IMO). Mike From owner-ipsec@lists.tislabs.com Fri May 16 11:24:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIOmAF010990; Fri, 16 May 2003 11:24:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21604 Fri, 16 May 2003 13:58:27 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16069.10202.513997.950745@thomasm-u1.cisco.com> Date: Fri, 16 May 2003 11:03:06 -0700 (PDT) To: EKR Cc: Michael Thomas , Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> <16069.6161.52480.563103@thomasm-u1.cisco.com> <16069.9666.270402.827655@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Michael Thomas writes: > > > Eric Rescorla writes: > > > Michael Thomas writes: > > > > Or something like this. Note that this doesn't > > > > have anything to do with the *IKE* identity, it's > > > > completely a property of the SA and its filters > > > > that were derived from the policy which matched > > > > for the mode and identity. It does, however, > > > > enforce the property that you desired above, > > > > especially when combined with the fact that you > > > > need several round trips which establish that that > > > > entity is, in fact, reachable at the outgoing > > > > address. > > > You must be joking. > > > > > > What, you've never heard of active attacks? IP spoofing? > > > > Yeah, yeah, and the application starting the TCP > > connection got that IP address from DNS which > > isn't secure either. > What, you've never heard of DNSSEC? Ah, I see we're in the land of pixies and unicorns. Glad we've cleared that up. Mike From owner-ipsec@lists.tislabs.com Fri May 16 11:27:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIRfAF011072; Fri, 16 May 2003 11:27:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21620 Fri, 16 May 2003 14:02:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> Date: Fri, 16 May 2003 14:05:54 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: some thoughts on identity handling Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, I've been listening to the discussion about whether there ought to be a requirement to match an asserted ID payload to any field in a cert that was passed in IKE, or maybe pre-configured into the SPD, etc. I certainly can't dispute the bad experiences that Paul and Gregory have reported. But, I think we ought to back up from the mechanistic discussion (the "how") and try to figure out what problem we are solving (the "why") to see if we are heading down the right path. One can imagine several models for what we want to accomplish by using certs for initial authentication in IPsec. I believe that we perform this authentication in order to make an access control decision. This assumes that we are generally NOT prepared to communicate with arbitrary peers. At a minimum we need to be able to determine their identity, and then use that to decide if we wish to communicate and if so, with what constraints. (This may be in conflict with the opportunistic encryption model of operation. If so, that may be a source of confusion, i.e., we don't agree on the problem we are trying to solve. However, I don't know if this is an issue yet and I'll defer to Mike to say what he thinks on this topic, relative to my notes below.) Note that there is a difference between not wanting to make an access control decision based on an authenticated identity, and wanting to make such a decision but not knowing the identity of specific peers in advance. The latter goal is easily accommodated using PKI technology, for example. The former is not well aligned with the overall thrust of IPsec, since IPsec is an IP layer security protocol in which access control is a fundamental service, not just an IP layer confidentiality or integrity protocol. So, we need to explore the ways in which an ID established by a cert, with or without an ID payload, might be used in access control decisions. In IPsec, these decisions are centralized in the SPDs. But, what is the type, granularity, and scope of the cert-based authentication, i.e., what type and range of identities does the cert serve to verify, and to what SPD entries does it apply? There has been discussion about the utility of different types of IDs, e.g., IP addresses, FQDNs, etc. I don't want to add to that debate, since I believe that there are contexts on which each of these ID types is useful. So let's assume that we are dealing with any of these ID types in the following discussion, and focus instead on scope. One might adopt a various models. In the examples below, when I say "valid cert" I mean an X.509 cert that can be validated relative to one or more pre-configured trust anchors in the responder. Recall that a trust anchor is a (CA) public key and associated data that is used for cert path validation. (It need not be a self-signed cert, although that may be a convenient format.) When I say "assert an ID" I mean send an ID payload in IKE. 1. when a peer presents a valid cert, one could allow the peer assert any ID and then compare it against any SPD entry. This is probably a bad idea in general, as it allows any configured TA to assert any identity without constraints. However, if you configure only one TA, and that TA is managed by the folks responsible for securing your environment, then even this simple case may be OK. It has moved all responsibility to that TA (CA) to ensure that the entities to which/whom certs are issued will only do "good" things. it really means trusting all these entities to not abuse the certs they have. Nonetheless, this does not strike me as a good approach for more general authorization requirements. 2. when a peer presents a valid cert, one could allow the peer to assert any ID against any SPD entry that is linked to the cert. the linkage could be direct, e.g., a pointer to the cert in each SPD entry to which the cert applies, or it might be indirect, e.g., a pointer to a trust anchor from each SPD entry to which ... This model constrains the scope of the authenticated peer, allowing different certs or TAs to be applied to different SPD entries. If the cert/SPD entry binding is 1-1, then there may be no security concerns here because the asserted ID may be irrelevant. If multiple SPD entries link to the cert, then the implications of the asserted ID may still be quite limited, based on which SPD entries are links to which certs. When a cert can apply to multiple SPD entries, then there is an opportunity to make use of an ID payload to match against a subset of these entries. For example, a TA might represent Company A, which issues certs to all its employees. When a company a employee tries to establish an SA to the Company B IPsec SG, the intent is to limit the access to that accorded to those employees. But, within that context, different employees may have different permissions and thus have different SPD entries. The danger here is that an error in managing the cert/SPD entry table could allow one of these certs to be applied to other SPD entries that should be out of scope relative to the intended access control policy. if the goal is to allow assertion of different IDs for different authorizations relative to the Company A context, one could achieve the same goal by binding the certs for the individuals to the relevant SPD entries, but this would require much more management overhead. So, in this example, it does seem that there is benefit to asserting an ID separate from the ID(s) in the cert used in establishing the IKE SA. However, one might prefer to limit the range of IDs that might be asserted, e.g., by requiring the equivalent of name constraints to be applied to the asserted ID. 3. when a peer presents a valid cert, and asserts an ID, one could require that the ID be matched to the Subject DN or to a Subject AltName. If we did this we would need to know how to map the asserted ID to the cert, i.e., which fields to compare and with which "matching rules." And, we still have to address the question of the scope of the cert validation. is it global, i.e., applies to all SPD entries, or is it linked to specific SPD entries? the latter case looks like #2 above, in terms of linkage options, but this time we apply some rules for matching. This is where #2 ended, discussing not direct matches but rather looking at matching rules like the name constraints extension. if the scope is global, then the cert may be implicitly linked to SPD entries, depending on the type of ID asserted. For example, a FQDN, 822Address, or DN would match only those SPD entries that used symbolic names for the IP address selector fields. If one used the name constraints extension in the configured trust anchors, this might be a fairly safe scope. But, without name constraints, any trust anchor could, in principle, issue a cert with any ID type and value and the resulting scope might not be any better than in #1 above. I don't claim that this brief analysis resolves the question, but at least it may provide a context on which to clarify the discussions. It seems that there are situations in which being able to assert an ID distinct from the cert used in the IKE exchange is valuable. So, I don't believe we ought to consider deleting that facility. Rather, the problems seem to be how we describe the use of certs relative to SPD entries (something 2401 did not address), and what sort of matching rules we use to decide if an asserted ID is valid relative to a provided cert. The problem I hear from Paul et al. is that often it is not possible for the administrators of IPsec systems to specify the data that CAs put into the certs that are exchanged (different unions?). if so, then it will be hard to take advantage of that data to constrain asserted IDs, and we need to make other provisions for achieving similar or equivalent scoping. However, we might want to specify mechanisms for how to match ID against cert data, in a standard (vs. purely local) fashion, to facilitate interoperability and make this all more understandable when it is possible to take advantage of certs in a more sophisticated fashion. We could make the former capabilities (for mapping certs to SPD entries) a MUST, as they will work in all cases, and the latter capability (matching rules for asserted IDs relative to certs) a SHOULD or MAY. Steve From owner-ipsec@lists.tislabs.com Fri May 16 11:31:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIVGAF011217; Fri, 16 May 2003 11:31:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21646 Fri, 16 May 2003 14:05:07 -0400 (EDT) To: Michael Thomas Cc: Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> <16069.6161.52480.563103@thomasm-u1.cisco.com> <16069.9666.270402.827655@thomasm-u1.cisco.com> <16069.10202.513997.950745@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 11:15:52 -0700 In-Reply-To: <16069.10202.513997.950745@thomasm-u1.cisco.com> Message-ID: Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > > Michael Thomas writes: > > > > > Eric Rescorla writes: > > > > Michael Thomas writes: > > > > > Or something like this. Note that this doesn't > > > > > have anything to do with the *IKE* identity, it's > > > > > completely a property of the SA and its filters > > > > > that were derived from the policy which matched > > > > > for the mode and identity. It does, however, > > > > > enforce the property that you desired above, > > > > > especially when combined with the fact that you > > > > > need several round trips which establish that that > > > > > entity is, in fact, reachable at the outgoing > > > > > address. > > > > You must be joking. > > > > > > > > What, you've never heard of active attacks? IP spoofing? > > > > > > Yeah, yeah, and the application starting the TCP > > > connection got that IP address from DNS which > > > isn't secure either. > > What, you've never heard of DNSSEC? > > Ah, I see we're in the land of pixies and unicorns. > > Glad we've cleared that up. Given that you're the one suggesting that we ought to ignore known possible active attacks, the appropriate response seems to be: Pot. Kettle. Black. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 11:43:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIhgAF011573; Fri, 16 May 2003 11:43:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21721 Fri, 16 May 2003 14:17:28 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16069.11343.845985.738007@thomasm-u1.cisco.com> Date: Fri, 16 May 2003 11:22:07 -0700 (PDT) To: EKR Cc: Michael Thomas , Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> <16069.6161.52480.563103@thomasm-u1.cisco.com> <16069.9666.270402.827655@thomasm-u1.cisco.com> <16069.10202.513997.950745@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eric Rescorla writes: > Given that you're the one suggesting that we ought to ignore > known possible active attacks [...] Live With != Ignore. I'm interested in raising the bar for security, not boiling the ocean. This entire exchange is pretty much illustrative of why security protocols are deployed so few and far between. Mike From owner-ipsec@lists.tislabs.com Fri May 16 11:53:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIrwAF011814; Fri, 16 May 2003 11:53:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21762 Fri, 16 May 2003 14:25:24 -0400 (EDT) To: Michael Thomas Cc: Uri Blumenthal , Paul Hoffman / VPNC , Gregory Lebovitz , "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D8E@SARATOGA.netscreen.com> <16068.1766.561003.133227@thomasm-u1.cisco.com> <16068.2874.797405.258729@thomasm-u1.cisco.com> <3EC4F58A.1000200@bell-labs.com> <16069.704.149820.605667@thomasm-u1.cisco.com> <16069.2510.321906.770452@thomasm-u1.cisco.com> <16069.6161.52480.563103@thomasm-u1.cisco.com> <16069.9666.270402.827655@thomasm-u1.cisco.com> <16069.10202.513997.950745@thomasm-u1.cisco.com> <16069.11343.845985.738007@thomasm-u1.cisco.com> Reply-To: EKR From: Eric Rescorla Date: 16 May 2003 11:36:10 -0700 In-Reply-To: <16069.11343.845985.738007@thomasm-u1.cisco.com> Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > Eric Rescorla writes: > > Given that you're the one suggesting that we ought to ignore > > known possible active attacks [...] > > Live With != Ignore. I'm interested in raising the > bar for security, not boiling the ocean. The belief that active attacks are important is part of the IPsec threat model. IPsec is riddled with features that assume it to be the case. If we were going to design a system that doesn't provide protection against those attacks, we'd design an entirely different system. > This > entire exchange is pretty much illustrative of why > security protocols are deployed so few and far > between. And yet, strangely, the most widely deployed security protocol in the world depends entirely on a universal PKI. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri May 16 11:56:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GIuFAF011883; Fri, 16 May 2003 11:56:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21791 Fri, 16 May 2003 14:27:17 -0400 (EDT) Message-ID: <3EC52F29.F76B864D@airespace.com> Date: Fri, 16 May 2003 11:34:17 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ravi CC: Gregory Lebovitz , "'Paul Hoffman / VPNC'" , "'EKR'" , "'ipsec@lists.tislabs.com'" Subject: Re: Confirm decision on identity handling. References: <541402FFDC56DA499E7E13329ABFEA87E66D96@SARATOGA.netscreen.com> <3EC47D20.1090800@roc.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2003 18:32:09.0502 (UTC) FILETIME=[75D173E0:01C31BD9] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ravi wrote: > Some implementations already do this for supporting remote access. > In remote access, road warriors are initiators and Corporate SG is > typically configured in 'Responder' only mode. One IKE policy is > created with > - Wild card domain name as peer ID. > For example, *.abc.com can be give as Peer ID. > Then all remote access users whose IDs are ending with > > abc.com will be authenticating using this IKE policy. > > - Accept any whose signing CA is 'DN of CA'. > This is typically useful when corporate office has their own > CA and anybody got certificate from this CA is authenticated > using this policy. > > In above examples, really there is no check between ID payload and > Certificate in verbatim. It is local decision. No, in this case which policy is used is the sender's decision. If you'll accept any cert from your CA, and you have one policy for abc.com and another for def.com, what assurance do you have that the presenter is who he claims to be? The point is that for remote access, the IP address is not known a priori, so the only way to configure a policy for a remote access user at the recipient (i.e. SGW) end is in terms of a "name" of some sort. If this is to be meaningful from a security perspective, there must be a cryptographically sound way to bind this name to the user presenting it. If you are using certs, it makes sense to use an identifier which is contained within (or otherwise verifiable using) the cert, to ensure cryptographic binding. What is being suggested by some is that we decouple the name used to select the policy from the authenticator which, in my view, makes little sense from a security perspective. It opens the door to misconfigurations in which the same cert may be acceptable for more than one policy rule, where the selected rule is controlled by the sender of the ID payload - not exactly secure from the perspective of the SGW. It is also argued (correctly, I think) that the lack of standard cert profile for ipsec makes it practically impossible to specify universally which cert field(s) will be presented by the sender, and configured/accepted by the receiver, in an interoperable way. This leads to my suggestion that the would-be-interoperable sender not bother trying to guess what should be in the ID payload, since he cannot be sure of doing so correctly, and for the receiver to have the option of ignoring any ID sent along with a cert, and to have the ability to select the correct policy with or without the ID payload, gleaning whatever is needed from the cert. Clearly, this applies to certs only, and not to raw rsa/dsa keys. This allows folks who are using the ID payload as a convenient policy key for cert-based policies to continue to do so, while ensuring that they will interoperate with someone who doesn't send a particular ID, and vice versa. Of course, we assume that those using the unbound ID for convenience actually do some additional policy verification from a security perspective, although I suspect that in some cases this is not the case - and such behavior should not be standardized by a security area working group. Scott From owner-ipsec@lists.tislabs.com Fri May 16 13:04:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GK4qAF014834; Fri, 16 May 2003 13:04:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22171 Fri, 16 May 2003 15:35:49 -0400 (EDT) Message-Id: <200305161941.h4GJf9hr000693@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: some thoughts on identity handling In-reply-to: Your message of "Fri, 16 May 2003 14:05:54 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 16 May 2003 15:41:08 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> communicate and if so, with what constraints. (This may be in Stephen> conflict with the opportunistic encryption model of Stephen> operation. If so, Stephen> that may be a source of confusion, i.e., we don't agree on the Stephen> problem we are trying to solve. However, I don't know if this Stephen> is an Stephen> issue yet and I'll defer to Mike to say what he thinks on this Stephen> topic, Stephen> relative to my notes below.) We have specifically avoided PKIX certificates, preferring raw keys in DNS reverse map, authenticated with SIG records for *precisely* the problems that have come up. Solveable in theory, a disaster in practice. Stephen> "valid cert" I mean an X.509 cert that can be validated relative Stephen> to one or more pre-configured trust anchors in the Stephen> responder. Recall One major deployment issue in IKEv1 with certificates is that numerous vendors making configuring these "trust anchors" essentially impossible for the admin who owns the box, and they have very poorly documented what they expect to be in the certificate. Stephen> 2. when a peer presents a valid cert, one could allow the Stephen> peer to assert any ID against any SPD entry that is linked to the Stephen> cert. the linkage could be direct, e.g., a pointer to the cert in Stephen> each SPD entry to which the cert applies, or it might be indirect, This has always seemed like the best way to me. How do you link to the cert is a question, but there are many different ways. I still think that this has the same problem that #3 has - it is just now under the control of the gateway administrator. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsU+y4qHRg3pndX9AQHgAAQAv1e7uAWoQAAERC3ndUpeA1e/2weUJfoV koNdbtaZXTxXN3hCwLHNZATFOxVtNaH+1A2DN/GbUgxTosOLZ3JQKZz0789ROwMn NtlgpX4JqAV74Bje499+9wuGmuNnRxZagq47KQkFHHu+EDxpPfD0rLG9ijT0w3G5 Su7YKp2Gfmc= =pSsr -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri May 16 15:20:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GMJxAF019300; Fri, 16 May 2003 15:20:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22571 Fri, 16 May 2003 17:43:59 -0400 (EDT) Message-ID: <3EC55CC0.3090205@cisco.com> Date: Fri, 16 May 2003 14:48:48 -0700 From: Geoffrey Huang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gregory Lebovitz CC: "'Ravi'" , Charlie_Kaufman@notesdev.ibm.com, "'ddukes@cisco.com'" , ipsec@lists.tislabs.com, Michael Choung Shieh , owner-ipsec@lists.tislabs.com Subject: Re: Peer liveliness References: <541402FFDC56DA499E7E13329ABFEA87E66D8D@SARATOGA.netscreen.com> In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66D8D@SARATOGA.netscreen.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just for clarification, DPD makes no mention of sending IC. It's "out of scope" ;-). -g Gregory Lebovitz wrote: > Moving the discussion back to IKEv2, for the moment... > > Several of us have spent a lot of time discussing this issue in the past few > weeks. A main problem we are trying to solve (though not the only one) is > rapid recovery from a rebooted peer. > > If you look at the current DPD draft for IKEv1, it calls for sending > INITIAL-CONTACT whenever a peer thinks this is its first contact, i.e. has > no established SAs with the remote peer. This is done, even in the case > where DPD is running on both peers, to let the other peer -- the persisted > peer (as opposed to the rebooted peer) -- know to delete the old SAs asap. > Because the DPD timers might not catch it fast enough. > > It is a very good idea to do this because sending the empty notify (DPD), > and the timer setting for how often, are totally optional. Therefore, > depending on settings, and *without* the INITIAL-CONTACT, it could be quite > some time before the persisted peer relinquishes its current SAs. > > Charlie, I can't remember, is the sending of INITIAL-CONTACT a MUST in the > latest IKEv2 draft? Would it be a good idea to make INITIAL-CONTACT > notification a MUST, if it is not already? Doing so would help shorten the > tunnel black hole in most cases, regardless of dpd settings. > > The next question is: what is the best behavior for a (rebooted) peer who > receives an invalid SPI? Today the mandate is to drop silently. But, if two > rules are checked first, it can be fine (i think) to respond. Those rules > are: > - do I have an active SA with the sender of the invalid SPI? If yes, drop > silently. If no, go to next rule check... > - do I have the source IP of the sender in my SPD? i.e. is the sender a > valid peer? If no, drop silently. If yes... > - initiate IKE per SPD definition. > > If these two rules are followed, the only threat I see to responding with > IKE initiation is that an attacker who knew all of my valid peers' IPs > could, at the moment of recovery from reboot (or power up), cause me to > establish IKE with all my peers listed in SPD, even though I might not have > otherwise made those establishmetns. Attacker would do so by sending me > invalid SPIs spoofed with source of each of my peers. I guess I see this as > a pretty tough attack to pull-off in the real world (given spoof checking > used on most ISP routers these days), and the pay-off of the attack likely > doesn't merit the difficulty of execution. Does the value merrit the risk? > > Summary: IKEv2 aliveness checking doesn't ensure fast recovery. It provides > a mechanism that MAY be used for fast detection and recovery, but doesn't > guarantee it. However, combining the initiate-IKE response behavior + > INITIAL-CONTACT + liveness detection would ensure VERY fast > re-establishments for valid peers after one rebooted (and covers all other > cases too). If the liveness checking doesn't catch the failure fast enough, > the initiate IKE response w/ IC will. > > Thoughts? > > Gregory. > > >>-----Original Message----- >>From: Ravi [mailto:ravivsn@roc.co.in] >>Sent: Wednesday, May 14, 2003 9:59 PM >>To: Charlie_Kaufman@notesdev.ibm.com >>Cc: Gregory Lebovitz; 'ddukes@cisco.com'; ipsec@lists.tislabs.com; >>Michael Choung Shieh; owner-ipsec@lists.tislabs.com >>Subject: Re: Peer liveliness >> >> >>Hi, >> In IKEv2, the IKE SA are bound to the IPSEC SA and IPSEC SAs (Child >> SAs) are deleted whenever IKE SA is dead. Due to this, I >>don't see any >> problem with the approach mentioned in IKEv2 specifications. But, in >> IKEv1, this binding is not mandated and IPSEC SA can exist without >> corresponding IKE SA. This is where I see problem and current DPD >> specification does not seem to be considering this. I was proposing >> before, the need for Dead Tunnel detection on the remote >>SGs. I plan to >> come out with draft in 1 to 2 weeks on this. It is only applicable >> for IKEv1 implementations. >> >>Regards >>Ravi >> >>Charlie_Kaufman@notesdev.ibm.com wrote: >> >>> >>> >>>I believe that the current IKEv2 spec addresses this issue >> >>in a way that >> >>>puts minimal requirements on implementations, guarantees >> >>interoperability >> >>>(though with less than ideal convergence time), and allows >> >>implementations >> >>>to do better. >>> >>>But it's quite possible that I don't understand all of the >> >>things that >> >>>could go wrong, or have inadequately expressed what >> >>implementations MUST >> >>>do, or just plain screwed up. >>> >>>The implementation requirements for robust interoperability are: >>> >>>(1) An IKE SA and all of its associated child SAs fail >> >>together. You aren't >> >>>allowed a "partial crash" where some of the state is lost >> >>but some is kept. >> >>>This will fall out naturally in most implementations, but >> >>may require some >> >>>modular designs to have different modules poll one another >> >>for liveness. >> >>>(2) A node may not send on a set of SAs associated with a >> >>single IKE SA >> >>>indefinitely without hearing something back. If it hears >> >>nothing for long >> >>>enough, it should send an IKE message requiring a reply, >> >>and if no reply >> >>>comes it must declare all of the SAs dead. >>> >>>(3) A node that has packets to send according to its SPD >> >>and no SA to send >> >>>them on must periodically attempt to open an SA for them. >>> >>>I believe these three requirements along guarantee that the >> >>right thing >> >>>will happen eventually. But it doesn't prescribe what the >> >>timers should be. >> >>>So it's possible it will take unacceptably long for things >> >>to converge. (If >> >>>network delays are long enough and timeouts short enough, >> >>the system could >> >>>fail to work at all, but I believe that problem is unavoidable). >>> >>>The problem with more sophisticated strategies is that they may be >>>exploitable for denial of service attacks. Anyone can forge >> >>an INVALID_SPI >> >>>notification message from an IP address of their choice >> >>(since such a >> >>>message is not cryptographically protected). If such a message were >>>sufficient to cause its recipient to shut down and restart >> >>the SA, it would >> >>>be a very effective attack. So the spec says that such a >> >>message may be >> >>>used only as a hint to a problem - for example to trigger a >>>cryptographically protected liveness test. This will cause >> >>the failure to >> >>>be detected more quickly, but will never cause one to be >> >>detected falsely. >> >>>Similarly, the INITIAL_CONTACT notification can be used >> >>when setting up an >> >>>SA to assure the other end that it should abandon any SAs >> >>it has open to >> >>>the same identity. This is useful in - for example - the >> >>firewall case >> >>>where an identity is tied to a single box and it would be >> >>an error for that >> >>>box to bring up two connections at once. It would not be >> >>useful in the case >> >>>of a user who is allowed to remotely log in from multiple >> >>workstations at >> >>>the same time. Again, this makes convergence happen faster >> >>while never >> >>>making the wrong thing happen. >>> >>>Responding to the individual comments below... >>> >>>Gregory Lebovitz wrote on 04/29/2003: >>> >>> >>>>[WE] won't achieve interoperability unless it's mandated that >>>>[IMPLEMENTORS] must >>>> >>>> >>>>>reply INVALID_SPI (in clear or initiate IKE back to the >>>>>sender) whenever it >>>>>receives bad spi packets. Current IKEv2 draft doesn't >>>>>address this issue >>>>>(only states you MAY reply a clear notify message). >>>>> >>>>>IKEv1 vendors has implemented many ways to solve it which >> >>leave poor >> >>>>>interoperability. We should just pick a method and clarify >>>>>it in IKEv2. >>>>>=============== >>>>>Michael Shieh >>>>> >>>> >>>I think we did, but if you don't think it works, explain why. >>> >>> >>> >>>>We have been having quite a debate in the ICSA IPsec >> >>consortium mail list >> >>>>recently trying to figure out how to handle this in IKEv1 >> >>(YES, STILL!!!) >> >>>>Here is what we know for sure of this problem statement: >>>>(a) detecting liveness/deadness of peer is a good thing, >> >>but does not >> >>>solve >>> >>> >>>>all the failure cases in and of itself >>> >>>Which ones does it not solve? >>> >>> >>> >>>>(b) the behavior of a recently rebooted device when it receives an >>>>encrypted packet for an SPI or IKE-SA not in its SADB MUST >> >>be mandated, >> >>>or >>> >>> >>>>else implementations will not interoperate (as is the case >> >>in IKEv1, 5 >> >>>years >>> >>> >>>>later). >>> >>>Can you give an example of how two implementations >> >>following IKEv2 could >> >>>fail to interoperate? >>> >>> >>> >>>>(c) the behavior of a peer that receives a new IKE from a >> >>peer that it >> >>>has >>> >>> >>>>an existing IKE-SA with (i.e. the rebooted peer that is trying to >>> >>>initiate a >>> >>> >>>>new connection) MUST be mandated, or else implementations will not >>>>interoperate (as is the case in IKEv1, 5 years later). >>> >>>I believe it is mandated that the new IKE-SA must be >> >>accepted, and the old >> >>>one either closed immediately or closed after a timeout, >> >>though perhaps >> >>>that's just what I was thinking and not what I wrote. Is >> >>there anything >> >>>specific you would recommend? >>> >>> >>> >>>>Darren Dukes wrote: >>>> >>>> >>>>>I believe INVALID_SPI does what you are looking for. If I >> >>receive an >> >>>>>INVALID_SPI notify via an IKE SA I know to delete the SA and >>>>>traffic will >>>>>bring up a new one. >>>> >>>>I don't believe this will work, since it assumes that an IKE SA is >>>>established. In the scenario, the IKE-SA would have been >> >>lost along with >> >>>the >>> >>> >>>>SPI of the CHILD-SA by the rebooted peer. >>>> >>> >>>Until a new IKE-SA is established, any INVALID_SPI message would be >>>cryptographically unprotected and therefore not to be taken as other >>>than a hint. If a new IKE-SA is established, the INVALID_SPI could >>>be taken as trustworthy and used to abandon the old SA. Without the >>>INVALID_SPI message, abandonment would still happen but it >> >>would take >> >>>longer. >>> >>> >>> >>>>Recommendations to solve the solution: >>>>- the empty notify as an aliveness check is a good idea. It >> >>accomplishes >> >>>>what the DPD draft did. Keep using this. >>>> >>> >>>Generating them is not mandated, but the ability to respond >> >>to them is. >> >>> >>>>- do what you can to use empty notify to detect dead peer ASAP. The >>> >>>faster >>> >>> >>>>the persisting peer can delete the old SPI and IKE-SA, the >> >>better. The >> >>>best >>> >>> >>>>case is for Persisting Peer to detect death and initiate new IKE to >>> >>>rebooted >>> >>> >>>>peer before rebooted peer gets packets with old SPI, IKE-SA. >>>> >>> >>>If the rebooted peer knows that the SA is needed, it can do >> >>that. If it >> >>>sets them up based on traffic, it has to wait until a >> >>packet comes in from >> >>>one side or the other. >>> >>> >>> >>>>- On the Rebooted peer side: If an implementation receives >> >>a protected >> >>>>packet from an unkown SPI, >>>>- simply relying on sending back an unprotected >> >>INVALID_SPI is not a >> >>>good >>> >>> >>>>idea. It is too easy to DoS the persisting peer by simply >> >>spoofing the >> >>>>rebooted peer's address. >>>>- initiate IKE to the persisting peer. >>> >>>This is allowed, although sending what looks like protected >> >>messages from >> >>>randomly chosen IP addresses to cause the node to attempt >> >>lots of IKE >> >>>connections is also a plausible DOS attack. Sending the >> >>INVALID_SPI message >> >>>will tell the other end to probe this end for liveness and >> >>initiate its own >> >>>new IKE connection if that liveness test fails. That's the >> >>path guaranteed >> >>>to work. Others will speed things up if implementations >> >>choose to do them. >> >>> >>>>- On the Persisting Peer: >>>>- If you get a new IKE request from a peer already in your >> >>SADB, respond >> >>>>with the under-attack, 6 message method. This will mitigate the DoS >>> >>>attack. >>> >>> >>>>If you get all the way through SA and TS negotiation >> >>successfully, you >> >>>are >>> >>> >>>>assured (unless I'm missing something) that this really is >> >>your peer, and >> >>>>that he re-initiated because he lost the original IKE-SA. >> >>Start using the >> >>>>new IKE-SA and the new CHILD-SA and delete the previous >> >>ones after some >> >>>wait >>> >>> >>>>period. >>>> >>> >>>Only if there is an INITIAL_CONTACT notification message. >> >>Otherwise it's >> >>>possible that the peer is opening multiple IKE SAs, perhaps >> >>because he is >> >>>replicated. In some configurations this might be >> >>acceptable. In firewall to >> >>>firewall tunnels, it would not and an implementation might >> >>reasonably treat >> >>>any IKE-SA as an INITIAL_CONTACT. >>> >>> >>> >>>>Would this proposal explicitly solve things? >>>> >>>>Gregory. >>> >>> >>> --Charlie >>> >> >> >>-- >> >> >>The views presented in this mail are completely mine. The >>company is not >>responsible for whatsoever. >>-------------------------------------------------------------- >>---------- >>Ravi Kumar CH >>Rendezvous On Chip (i) Pvt Ltd >>Hyderabad, India >>Ph: +91-40-2335 1214 / 1175 / 1184 >> >>ROC home page >> >> >> From owner-ipsec@lists.tislabs.com Fri May 16 18:33:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4H1XbAF023343; Fri, 16 May 2003 18:33:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23050 Fri, 16 May 2003 21:02:56 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66DC6@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'suren'" , "'Ravi'" Cc: Michael Choung Shieh , "'ddukes@cisco.com'" , ipsec@lists.tislabs.com Subject: RE: Peer liveliness Date: Fri, 16 May 2003 18:00:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To both your and Ravi's point, this method *can* be made to work with remote-dynamically assigned clients (it's not pretty, and I don't necessarily recommend the method we've come up with, but it can be done). In light of my earlier proposal, in the dynamically addressed scenario, the second condition would fail; the rebooted peer would not be able to find a match in SPD, so no IKE would be initiated. In this case we would be depending solely on INITIAL-CONTACT and aliveness detection. So I'll edit what my proposal to: "INITIAL-CONTACT + rebooted-peer-initiating-IKE + aliveness detection is the fastest and most sure way to get an SA back up for fixed ip peers, as it covers the conditions and responses for both the persistent and rebooted-peers. " For case where one side is dynamically addressed, INITIAL-CONTACT + Aliveness is sufficient, and the speed of recover will depend 100% on (a) aliveness detection being configured "ON", and (b) the timer configuration on the persistent peer. Gregory. > -----Original Message----- > From: suren [mailto:suren@intotoinc.com] > Sent: Thursday, May 15, 2003 11:41 AM > To: Gregory Lebovitz; 'Ravi' > Cc: Michael Choung Shieh; 'ddukes@cisco.com'; ipsec@lists.tislabs.com > Subject: RE: Peer liveliness > > > Gregory, > > The mechanism you suggested (INITIAL-CONTACT + rebooted-peer > initiating IKE > (with those two conditions) + aliveness detection) may not > work with in the > scenario of a roaming client. > > Suppose, a Roaming client (with a dynamic IP address) tunnels to a > Corporate network, and corporate SG is acting as responder > only. Now if > corporate SG is rebooted, it is not able to send > INITIAL_CONTACT to the > Roaming client (dynamic IP address). Corporate SG can not > even initiate the > IKE, since it does not contain IP address of roaming client, > which is dynamic. > > > Suren. > > Intoto Inc. > 3160, De La Cruz Blvd #100 > Santa Clara, CA > www.intotoinc.com > > > At 01:15 AM 5/15/2003 -0700, Gregory Lebovitz wrote: > >w/in... -----Original Message----- From: Ravi > [mailto:ravivsn@roc.co.in] > >Sent: Sunday, May 04, 2003 9:21 PM To: Gregory Lebovitz Cc: > Michael Choung > >Shieh; ddukes@cisco.com'; ipsec@lists.tislabs.com Subject: Re: eer > >liveliness Hi, In the text below, I also try to use the same > terminology > >used by you. Rebooted Peer and Persistent Peer. In your email, under > >'Recommendations to solve the solution', regarding second > point: In my > >view, whether Peer is alive or not does not solve the > problem completely. > >Persistent node should know aliveness of Tunnel on the other > side. It is > >possible that peer reboots and responds to DPD requests, but > tunnels are > >not there. We should have a mechanism to detect the Tunnel > aliveness. > >[GML] I think Charlie addressed this by saying that once the > IKE-SA is > >revived, one or the other would have sent the > INITIAL-CONTACT. When this > >happens, the other peer will delete old SAs, including > CHILD-SAs. So, once > >IKE establishes, traffic will cause creation of new CHILD-SA > (IPsec), so > >tunnel will come alive. Does this address your concern? With > respect to > >DoS attack: You addressed the issue of DoS attack on the > persistent side. > >I am also concerned about DoS attack on rebooting machine. > If MITM keeps > >sending the packets with some dummy SPI and valid source IP, > then the > >IPSEC SG keeps sending the INVALID_SPI and for this,it keeps > creating IKE > >SAs. That is one of the reason, some implementations do not support > >generationof INVALID_SPI notifications. [GML] I'm not > proposing use of > >INVALID_SPI; I specifically said I thought INVALID_SPI was bad. Im > >proposing rebooted-peer initates IKE to sender of invalid > SPI if -- and > >ONLY IF-- two conditions are met: (1) no current valid SAs > with sender, > >(2) sender is valid peer in SPD These two checks mitigate > the DoS issue > >almost completely. (see my other email for discussion of > threat analysis > >on this one). The more I hash this through with various > people, the more > >I'm becoming convinced that INITIAL-CONTACT + rebooted-peer > initiating IKE > >(with above two conditions) + aliveness detection is the > only way to catch > >all the failure cases. Gregory. > From owner-ipsec@lists.tislabs.com Sat May 17 05:15:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HCFJAF073384; Sat, 17 May 2003 05:15:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA24520 Sat, 17 May 2003 07:45:21 -0400 (EDT) Message-ID: <3EC6241F.8090003@roc.co.in> Date: Sat, 17 May 2003 17:29:27 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Scott G. Kelly" CC: ipsec@lists.tislabs.com Subject: Re: [Fwd: Confirm decision on identity handling.] References: <3EC406DC.2458A307@airespace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I think you are also saying that comparison of ID in the ID payload and Certificate is local matter. As a sender ID payload should be sent. ID in ID payload might have to match with certificate ID while sending as the receiver might be comparing the ID in ID paylaod and certificate. Regards, Ravi. Scott G. Kelly wrote: > Meant to reply to the list... > > > ------------------------------------------------------------------------ > > Subject: > Re: Confirm decision on identity handling. > From: > "Scott G. Kelly" > Date: > Thu, 15 May 2003 14:29:17 -0700 > To: > Gregory Lebovitz > > > Hi Gregory, > > Gregory Lebovitz wrote: > >>Paul is totally right on this one. From experience with Project Dploy, where >>we tried to get better interop between IPsec vendors and PKI vendors after >>talking to many customers about actual usage issues, this is what we found: >>It is a daunting task for the deployers to get the cert contents to match >>exactly what the VPN application needs. This is true for a variety of >>reasons, many of which Paul noted below. The biggest is that often the VPN >>deployer has little or zero impact/control/say in how the CA builds certs. >>It's just not reality to expect that the VPN can dictate or ensure some >>field in the Cert will contain what they need. >> >>This is why many of us have been pushing for disassociating the two. > > > I agree with Paul (and you) that it is difficult to reconcile the way > some PKI vendors build certs with the way identities are expressed in > ipsec policies (and ID payloads), although there are ways to build DN > filters if one is determined to solve these problems. However, the > bottom line is that if certs are to be meaningful as ipsec > authenticators, then there must be *some* way to identify acceptable > certs in the recipient's policy. And as an aside, I'll point out that > IPsec deployments are not constrained to using a particular PKI vendor's > certs - many vpn vendors have fielded CAs which *can* build > appropriately structured certs (if only we could all agree on what that > means from an interop standpoint). > > Even if you say the ID is not related to the cert in any way, you still > have a problem, though: you must, upon deriving a policy based on the > ID, verify that the cert matches the policy somehow - you must be able > to represent a certificate filter in your policy no matter which way you > do this. And you must ensure that if there are multiple policies for > which the same cert might be acceptable, that only the "correct" one is > chosen. This implies the ID must be bound to the cert somehow. > > Again, I suggest that we consider not *requiring* ID payloads with certs > (relying instead upon the recipient to derive an identity from the > cert), and that if we must support ID payloads when certs are used, that > processing the ID payloads be optional, so that two independent > implementations are able to interoperate whether they are present or not > (even if the recipient ignores the ID payload). > > Scott -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Sat May 17 09:46:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HGjtAF085223; Sat, 17 May 2003 09:46:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25241 Sat, 17 May 2003 12:12:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66D97@SARATOGA.netscreen.com> References: <541402FFDC56DA499E7E13329ABFEA87E66D97@SARATOGA.netscreen.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sat, 17 May 2003 09:18:18 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: More on algorithms for IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Based on Gregory's comments and talking to Charlie, I revised my IKEv2 algorithms document. It's now at . The major change was to move the MODP groups from the main IKEv2 document into the algorithms document, but I also corrected the typos that Greogy pointed out and updated the reference to RFC 3526 and made the IANA considerations clearer. On thing that Gregory asked for that I didn't do (yet) is: > > >- format help: would be nice in 2.1-2.4 to add a 4th column >> to each chart >> >that holds MUST, SHOULD, etc. That way the reader can see >> what's what very >> >quickly. >> >> I didn't do that because of the difference between "MUST today" and >> "MUST tomorrow". That is, I wanted to keep the wording below the >> tables being definitive. > >no argument about keeping the wording; I wouldn't have suggested removing >it. Adding the column will make ingestion easier on the reader. >Additionally, you could put a "*" by the SHOULD that calls to text below >highlighting the "MUST Later" stuff. I'm willing to do that if people want it, but I don't consider it all that hard for someone reading the document to look at the paragraph after the table to figure out the MUST and SHOULD requirements. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun May 18 01:56:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4I8uRAF036560; Sun, 18 May 2003 01:56:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27607 Sun, 18 May 2003 04:23:45 -0400 (EDT) From: "Yoav Nir" To: "'Paul Hoffman / VPNC'" , Subject: RE: More on algorithms for IKEv2 Date: Sun, 18 May 2003 11:27:35 +0200 Message-ID: <003201c31d1f$b825c2e0$292e1dc2@YnirNew> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul. Sorry I didn't ask about this earlier. With some vendors already offering AES with larger keys (192- and 256-bit), why aren't there numbers assigned for these transforms (section 2.1) Also, in the same section, you have the following: For IKEv2, ENCR_3DES (3) MUST be implemented and ENCR_AES_128_CBC (12) SHOULD be implemented. However, the number for ENCR_AES_128_CBC is 10, not 12. Similarly, in section 2.3, the number of AUTH_AES_XCBC_96 is 4, not 5. Yoav Nir -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC Sent: Saturday, May 17, 2003 6:18 PM To: ipsec@lists.tislabs.com Subject: More on algorithms for IKEv2 Based on Gregory's comments and talking to Charlie, I revised my IKEv2 algorithms document. It's now at . The major change was to move the MODP groups from the main IKEv2 document into the algorithms document, but I also corrected the typos that Greogy pointed out and updated the reference to RFC 3526 and made the IANA considerations clearer. On thing that Gregory asked for that I didn't do (yet) is: > > >- format help: would be nice in 2.1-2.4 to add a 4th column >> to each chart >> >that holds MUST, SHOULD, etc. That way the reader can see >> what's what very >> >quickly. >> >> I didn't do that because of the difference between "MUST today" and >> "MUST tomorrow". That is, I wanted to keep the wording below the >> tables being definitive. > >no argument about keeping the wording; I wouldn't have suggested removing >it. Adding the column will make ingestion easier on the reader. >Additionally, you could put a "*" by the SHOULD that calls to text below >highlighting the "MUST Later" stuff. I'm willing to do that if people want it, but I don't consider it all that hard for someone reading the document to look at the paragraph after the table to figure out the MUST and SHOULD requirements. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon May 19 09:11:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JGBXAF045765; Mon, 19 May 2003 09:11:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05824 Mon, 19 May 2003 11:28:56 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: To: EKR Cc: Gregory Lebovitz , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "'Paul Hoffman / VPNC'" , "Scott G. Kelly" Subject: Re: Confirm decision on identity handling. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Mon, 19 May 2003 11:32:01 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/19/2003 11:32:26 AM, Serialize complete at 05/19/2003 11:32:26 AM Content-Type: multipart/alternative; boundary="=_alternative 000B6C3985256D2B_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 000B6C3985256D2B_= Content-Type: text/plain; charset="US-ASCII" EKR wrote: > Gregory Lebovitz writes: > > I vote for disassociating ID from cert contents. (BUT, I proposed text that > > would allow for those who desired/required to be able to match if they > > wanted to). > The problem, then, of course, is that you've just made it near > impossible to make a system which works in the generic > "I want to establish an SA with some I've never heard > of before" mode. Many conventions need to be established to be able to establish SAs with someone you've never heard of before. The easiest would be opportunistic encryption, where both ends would ignore both the ID fields and the cert contents (if any). There is no authentication. You have no idea who you're talking to. But you're protected from passive eavesdroppers. To replace what SSL/TLS does, you would need a convention at least on the responder end as to what goes in IDs and/or certs. My recommendation for a convention would be that IDr is ignored, the responder's cert must pass whatever rules it must pass in SSL/TLS. I don't know whether those rules are spelled out in the spec, but I believe the convention is that the cert must have a CN= the DNS name the initiator was looking up. This is very un-IPsec like, because IPsec likes to pretend that DNS names are irrelevant. But I think it's what's most appropriate in this scenario. For initiator certs, I'd use the same rules as SSL/TLS. Except I don't know if there are any rules in the spec and in practice no one uses client certs with SSL/TLS other than in very specific (and probably non-interoperable) ways. It's hard to use IPsec between gateways that have never heard of each other. The only access control they enforce is who can talk to who, and if they will allow parties they have never heard of to talk, it seems unlikely they are protecting against much. --Charlie --=_alternative 000B6C3985256D2B_= Content-Type: text/html; charset="US-ASCII"
EKR <ekr@rtfm.com> wrote:
> Gregory Lebovitz <Gregory@netscreen.com> writes:
> > I vote for disassociating ID from cert contents. (BUT, I proposed text that
> > would allow for those who desired/required to be able to match if they
> > wanted to).
> The problem, then, of course, is that you've just made it near
> impossible to make a system which works in the generic
> "I want to establish an SA with some I've never heard
> of before" mode.
Many conventions need to be established to be able to establish SAs with someone you've never heard of before.

The easiest would be opportunistic encryption, where both ends would ignore both the ID fields and the cert contents (if any). There is no authentication. You have no idea who you're talking to. But you're protected from passive eavesdroppers.

To replace what SSL/TLS does, you would need a convention at least on the responder end as to what goes in IDs and/or certs. My recommendation for a convention would be that IDr is ignored, the responder's cert must pass whatever rules it must pass in SSL/TLS. I don't know whether those rules are spelled out in the spec, but I believe the convention is that the cert must have a CN= the DNS name the initiator was looking up. This is very un-IPsec like, because IPsec likes to pretend that DNS names are irrelevant. But I think it's what's most appropriate in this scenario. For initiator certs, I'd use the same rules as SSL/TLS. Except I don't know if there are any rules in the spec and in practice no one uses client certs with SSL/TLS other than in very specific (and probably non-interoperable) ways.

It's hard to use IPsec between gateways that have never heard of each other. The only access control they enforce is who can talk to who, and if they will allow parties they have never heard of to talk, it seems unlikely they are protecting against much.

        --Charlie --=_alternative 000B6C3985256D2B_=-- From owner-ipsec@lists.tislabs.com Mon May 19 09:11:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JGBXAF045766; Mon, 19 May 2003 09:11:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05821 Mon, 19 May 2003 11:28:55 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66D8D@SARATOGA.netscreen.com> To: Gregory Lebovitz Cc: "'ddukes@cisco.com'" , "Geoff Huang (E-mail)" , ipsec@lists.tislabs.com, Michael Choung Shieh , owner-ipsec@lists.tislabs.com, "'Ravi'" Subject: RE: Peer liveliness MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Mon, 19 May 2003 11:32:01 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/19/2003 11:32:25 AM, Serialize complete at 05/19/2003 11:32:25 AM Content-Type: multipart/alternative; boundary="=_alternative 0007DA6D85256D2B_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 0007DA6D85256D2B_= Content-Type: text/plain; charset="US-ASCII" > Charlie, I can't remember, is the sending of INITIAL-CONTACT a MUST in the > latest IKEv2 draft? Would it be a good idea to make INITIAL-CONTACT > notification a MUST, if it is not already? Doing so would help shorten the > tunnel black hole in most cases, regardless of dpd settings. > The current spec acknowledges in section 1.1 that there are different usage scenarios for IKE, but does not in later sections specify MUSTs and SHOULDs according to usage scenario. You make a good argument for INITIAL-CONTACT in the gateway to gateway tunnel scenario, where after a gateway reboots you want to other end to start sending packets to the new gateway asap (hopefully before the TCP connections time out for the nodes behind the gateways). But it makes little or no sense when a mobile node is connecting to a corporate gateway. If the mobile node crashed, all of its existing connections crashed with it, so there is likely nothing to gain by trying to rapidly get packets to those dead connections running. And if the corporate gateway crashed, it can't call back the mobile node anyway. It must wait for the mobile node to figure out that something went wrong and restart the connection. So the current spec says only that you MAY send the INITIAL_CONTACT, and the recipient is also allowed to ignore it. My view is that this is OK, though a plausible enhancement would be to include as an implementer hint that in the gateway to gateway case use of INITIAL_CONTACT would be a really good idea and explain why. Do you have a concrete proposal? > The next question is: what is the best behavior for a (rebooted) peer who > receives an invalid SPI? Today the mandate is to drop silently. But, if two > rules are checked first, it can be fine (i think) to respond. Those rules > are: > - do I have an active SA with the sender of the invalid SPI? If yes, drop > silently. If no, go to next rule check... > - do I have the source IP of the sender in my SPD? i.e. is the sender a > valid peer? If no, drop silently. If yes... > - initiate IKE per SPD definition. Today the mandate is to either drop silently or to send a NOTIFY message of type INVALID_SPI to the source IP address. If there is an IKE SA to the source IP address, that message can be sent protected and interpreted as definitive by the other end. Otherwise, it is sent unprotected and at most can be a hint to the other end that something is wrong. Because these messages are easily forged (as are the messages with invalid SPIs that cause them to be generated), there is no way to use them to speed up failover (i.e. avoiding a timeout) without risking a denial of service attack. --Charlie --=_alternative 0007DA6D85256D2B_= Content-Type: text/html; charset="US-ASCII"
> Charlie, I can't remember, is the sending of INITIAL-CONTACT a MUST in the
> latest IKEv2 draft? Would it be a good idea to make INITIAL-CONTACT
> notification a MUST, if it is not already? Doing so would help shorten the
> tunnel black hole in most cases, regardless of dpd settings.
>
The current spec acknowledges in section 1.1 that there are different
usage scenarios for IKE, but does not in later sections specify
MUSTs and SHOULDs according to usage scenario. You make a good argument
for INITIAL-CONTACT in the gateway to gateway tunnel scenario, where after
a gateway reboots you want to other end to start sending packets to
the new gateway asap (hopefully before the TCP connections time out for
the nodes behind the gateways). But it makes little or no sense when
a mobile node is connecting to a corporate gateway. If the mobile node
crashed, all of its existing connections crashed with it, so there is
likely nothing to gain by trying to rapidly get packets to those dead
connections running. And if the corporate gateway crashed, it can't
call back the mobile node anyway. It must wait for the mobile node to
figure out that something went wrong and restart the connection.

So the current spec says only that you MAY send the INITIAL_CONTACT, and
the recipient is also allowed to ignore it.

My view is that this is OK, though a plausible enhancement would be to
include as an implementer hint that in the gateway to gateway case use
of INITIAL_CONTACT would be a really good idea and explain why. Do you
have a concrete proposal?


> The next question is: what is the best behavior for a (rebooted) peer who
> receives an invalid SPI? Today the mandate is to drop silently. But, if two
> rules are checked first, it can be fine (i think) to respond. Those rules
> are:
>   - do I have an active SA with the sender of the invalid SPI? If yes, drop
> silently. If no, go to next rule check...
>   - do I have the source IP of the sender in my SPD? i.e. is the sender a
> valid peer? If no, drop silently. If yes...
>   - initiate IKE per SPD definition.
Today the mandate is to either drop silently or to send a NOTIFY message
of type INVALID_SPI to the source IP address. If there is an IKE SA to the
source IP address, that message can be sent protected and interpreted as
definitive by the other end. Otherwise, it is sent unprotected and at
most can be a hint to the other end that something is wrong. Because these
messages are easily forged (as are the messages with invalid SPIs that
cause them to be generated), there is no way to use them to speed up
failover (i.e. avoiding a timeout) without risking a denial of service
attack.

        --Charlie --=_alternative 0007DA6D85256D2B_=-- From owner-ipsec@lists.tislabs.com Mon May 19 09:39:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JGdvAF047703; Mon, 19 May 2003 09:39:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06155 Mon, 19 May 2003 12:14:13 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3EC16F2D.123CEA1D@airespace.com> To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Mon, 19 May 2003 11:32:01 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05122003NP|May 12, 2003) at 05/19/2003 11:32:25 AM, Serialize complete at 05/19/2003 11:32:25 AM Content-Type: multipart/alternative; boundary="=_alternative 0009786F85256D2B_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 0009786F85256D2B_= Content-Type: text/plain; charset="US-ASCII" "Scott G. Kelly" wrote: > Basically, every example given so far uses an ID value which can be > verified against the cert. Can anyone give a realistic example of a case > where we would *not* want the ID to match something in the cert? Realistic is in the eye of the beholder, but here is an example that works for me. Today, lots of mobile laptop to corporate firewall systems use static keys because certificates are simply too painful. Suppose I want to use public keys while making the smallest possible investment in PKI. So at the corporate firewall, instead of storing a username and password, I store a username and certificate. The certificate might be one I got for some other purpose and it contains - say - my email address. I put my username in the IDi field. It is what the firewall wants to use to look up my authentication information. For some users, it has static keys. But for me, it has a certificate. In this case, the ID and the cert must match in the sense that the cert has to be stored by the firewall associated with my ID. But there is no relationship between the names that could be pinned down in the spec. A foolish use of technology? Well, yes. But likely better security than with the static shared keys (since the firewall's database is no longer so sensitive to disclosure), and a useful transition step. --Charlie --=_alternative 0009786F85256D2B_= Content-Type: text/html; charset="US-ASCII"
"Scott G. Kelly" <scott@airespace.com> wrote:
> Basically, every example given so far uses an ID value which can be
> verified against the cert. Can anyone give a realistic example of a case
> where we would *not* want the ID to match something in the cert?
Realistic is in the eye of the beholder, but here is an example that
works for me.

Today, lots of mobile laptop to corporate firewall systems use
static keys because certificates are simply too painful. Suppose
I want to use public keys while making the smallest possible
investment in PKI. So at the corporate firewall, instead of
storing a username and password, I store a username and
certificate. The certificate might be one I got for some other
purpose and it contains - say - my email address. I put my
username in the IDi field. It is what the firewall wants to use to
look up my authentication information. For some users, it has
static keys. But for me, it has a certificate.

In this case, the ID and the cert must match in the sense that
the cert has to be stored by the firewall associated with my ID.
But there is no relationship between the names that could be
pinned down in the spec.

A foolish use of technology? Well, yes. But likely better
security than with the static shared keys (since the firewall's
database is no longer so sensitive to disclosure), and a
useful transition step.

        --Charlie --=_alternative 0009786F85256D2B_=-- From owner-ipsec@lists.tislabs.com Mon May 19 09:57:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JGv1AF048292; Mon, 19 May 2003 09:57:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06281 Mon, 19 May 2003 12:31:51 -0400 (EDT) Message-ID: <3EC90893.999FEF42@airespace.com> Date: Mon, 19 May 2003 09:38:43 -0700 From: "Scott G. Kelly" Organization: airespace X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2003 16:36:47.0885 (UTC) FILETIME=[D773C3D0:01C31E24] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Charlie, Thanks for commenting on this. I've seen some other comments that lead me to see that this is indeed useful under some circumstances. I guess my objections would be overcome if we implemented what I think was one of Steve Kent's suggestions, i.e. if we specify (somewhere) how an ID which does not match the cert in some way is bound to the cert (and the policy rule) in the SPD. I think mcr's and Jim Knowles' suggestions for see-the-cert-dummy ID payload type would be useful as well. Scott Charlie_Kaufman@notesdev.ibm.com wrote: > > "Scott G. Kelly" wrote: > > Basically, every example given so far uses an ID value which can be > > verified against the cert. Can anyone give a realistic example of a > case > > where we would *not* want the ID to match something in the cert? > > Realistic is in the eye of the beholder, but here is an example that > works for me. > > Today, lots of mobile laptop to corporate firewall systems use > static keys because certificates are simply too painful. Suppose > I want to use public keys while making the smallest possible > investment in PKI. So at the corporate firewall, instead of > storing a username and password, I store a username and > certificate. The certificate might be one I got for some other > purpose and it contains - say - my email address. I put my > username in the IDi field. It is what the firewall wants to use to > look up my authentication information. For some users, it has > static keys. But for me, it has a certificate. > > In this case, the ID and the cert must match in the sense that > the cert has to be stored by the firewall associated with my ID. > But there is no relationship between the names that could be > pinned down in the spec. > > A foolish use of technology? Well, yes. But likely better > security than with the static shared keys (since the firewall's > database is no longer so sensitive to disclosure), and a > useful transition step. > > --Charlie From owner-ipsec@lists.tislabs.com Mon May 19 11:18:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JIIXAF054885; Mon, 19 May 2003 11:18:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06956 Mon, 19 May 2003 13:51:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16073.6801.328459.209963@pkoning.dev.equallogic.com> Date: Mon, 19 May 2003 13:55:29 -0400 From: Paul Koning To: Charlie_Kaufman@notesdev.ibm.com Cc: ekr@rtfm.com, Gregory@netscreen.com, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, paul.hoffman@vpnc.org, scott@airespace.com Subject: Re: Confirm decision on identity handling. References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Charlie" == Charlie Kaufman writes: Charlie> ...To replace what SSL/TLS does, you would need a convention at Charlie> least on the responder end as to what goes in IDs and/or Charlie> certs. Cynically... to replace what SSL does, you also have to build into the product a set of certs that you've decided to use, and count on customers not to be aware of this or worried by it. :-) paul From owner-ipsec@lists.tislabs.com Mon May 19 11:21:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JILRAF054985; Mon, 19 May 2003 11:21:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06942 Mon, 19 May 2003 13:49:54 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16073.6755.278480.571828@thomasm-u1.cisco.com> Date: Mon, 19 May 2003 10:54:43 -0700 (PDT) To: Charlie_Kaufman@notesdev.ibm.com Cc: "Scott G. Kelly" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-Reply-To: References: <3EC16F2D.123CEA1D@airespace.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com writes: > Today, lots of mobile laptop to corporate firewall systems use > static keys because certificates are simply too painful. Suppose > I want to use public keys while making the smallest possible > investment in PKI. So at the corporate firewall, instead of > storing a username and password, I store a username and > certificate. The certificate might be one I got for some other > purpose and it contains - say - my email address. I put my > username in the IDi field. It is what the firewall wants to use to > look up my authentication information. For some users, it has > static keys. But for me, it has a certificate. > > In this case, the ID and the cert must match in the sense that > the cert has to be stored by the firewall associated with my ID. > But there is no relationship between the names that could be > pinned down in the spec. It's transitional cases like this that I always wonder why people don't just use a hash of the public key as the "password" instead. Since it's a baby step as you state, it *does* eliminate the (manfiestly) daunting task of issuing certificates, and still gets rid of static keys and all of their downsides. Has a BCP ever been written about all of this? My sense is that confusion and timidity is one of the larger problems here since it's about "security" and thus frightening. There seems to be a pretty large gap with people's professed desires (certs) and its mismatch with reality (ie, legacy creds...), helping the transition to public key based authentication would be a generally Good Thing, I'd think -- even if it doesn't make it to the PKI promised land. Mike From owner-ipsec@lists.tislabs.com Mon May 19 11:33:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JIXDAF055268; Mon, 19 May 2003 11:33:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07037 Mon, 19 May 2003 14:03:24 -0400 (EDT) To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <3EC16F2D.123CEA1D@airespace.com> From: Greg Troxel Date: 19 May 2003 14:08:45 -0400 In-Reply-To: <3EC16F2D.123CEA1D@airespace.com> Message-ID: Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Basically, every example given so far uses an ID value which can be verified against the cert. Can anyone give a realistic example of a case where we would *not* want the ID to match something in the cert? Perhaps this is far afield, but consider Kerberos usage. A user has a principal, which is akin to a certificate with a name (different namespaces and way of proving identity, but conceptually similar). Many protocols using Kerberos enable one to say 'log in to the remote machine as user foo', and the normal ACL check looks at ~foo/.klogin and sees if the Kerberos principal that authenticated the request is on the list. So, I might have a certificate with a name, and want to use that to prove identity but select different roles on the remote system by use of the ID field. The question then becomes if the proved ID is authorized access under the requested ID. Given that IPsec currently has no way to link the proved/requested ID in the IKE negotiation to the application that gets packets over an SA, this is not yet very relevant. And, one could claim that this ID mapping should be done closer to the application. But, the '{[k]r,s}login hostname -l username' usage was and is useful. Greg Troxel From owner-ipsec@lists.tislabs.com Mon May 19 15:16:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4JMFxAF065137; Mon, 19 May 2003 15:16:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08251 Mon, 19 May 2003 17:35:49 -0400 (EDT) Message-Id: <200305190320.h4J3Jjqp019907@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Thu, 15 May 2003 08:13:26 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 18 May 2003 23:19:45 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 8:08 AM -0700 5/15/03, Eric Rescorla wrote: >> Hmm... I see your point. I was speculating that this would mean >> that you didn't much care what was in the certificate. VPNC> You could have a security policy that ignored the identity in the VPNC> cert ("allow an SA with these restrictions to anyone who has a cert VPNC> from XYZRoot"), or one that was identity-based ("let VPNC> chris@example.com make an SA"). >> What would be the point of using an ID payload if you didn't >> care what was in it? VPNC> There isn't one. The parties involved are not the same. You guys keep flipping between "VPN" and "two random parties" in your discussion. a) If the initiator doesn't know who it is talking to, then it can't know if the responder will look at the ID payload or the CERT, so it should include both. b) if the initiator *does* know who it is talking to (it is pre-configured to talk to it), then the ID payload is probably more useful than the certificate, since they two parties have probably spoken before! Consider SSH-style leap-of-faith security with parties that are on the phone with each other. You initiator with some ID, along with a CERT payload. Responder records them both - perhaps, because it is signed by a CA that the responder knows and trusts, only the DN (WHATEVER it might be). The responder then stores enough info, and the admin of the responder then adds some policy to it. Is this realistic? I've watched the SSH IPsec products do exactly this. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPshNT4qHRg3pndX9AQFjzwQAvTiJqHgFTXqzTLQSldS/sBoQSjwZz4UY 2abZHWVtObSDas8efilJ4CNpavVEQ3A9ja0EtvfrEfhgAtL1KMxL4GBmVqGPquaU 0Mr88uf97vnKYEnY3Yh8sY15KsrwGHacei9KNmMD040dk4Dz/VKB/XpqiLcHo/YA 8lGeS4WC6dI= =NDA6 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon May 19 22:04:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4K53wAF077409; Mon, 19 May 2003 22:04:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11498 Tue, 20 May 2003 00:27:12 -0400 (EDT) From: "George Hadjichristofi" To: "Ipsec" Subject: IPSec Implementation Date: Tue, 20 May 2003 00:31:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a question related to the different implementations of IPSec. I am currently looking into the FreeBSD, FreeSWAN Linux, and the one that comes with the new version of linux. Does anyone know the basic differences between these implementations? Which one has the best documentation? Which one is "easiest" to understand and modify? Thank you, George ************************************************* George C. Hadjichristofi Graduate Student,Computer Engineering Department Virginia Tech,Blacksburg,VA 24061,U.S.A TEL:(540)-951-8936 ************************************************* From owner-ipsec@lists.tislabs.com Tue May 20 08:46:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KFk0AF041214; Tue, 20 May 2003 08:46:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16216 Tue, 20 May 2003 11:09:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200305190320.h4J3Jjqp019907@sandelman.ottawa.on.ca> References: <200305190320.h4J3Jjqp019907@sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 20 May 2003 08:19:31 -0400 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Confirm decision on identity handling. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:19 PM -0400 5/18/03, Michael Richardson wrote: > VPNC> You could have a security policy that ignored the identity in the > VPNC> cert ("allow an SA with these restrictions to anyone who has a cert > VPNC> from XYZRoot"), or one that was identity-based ("let > VPNC> chris@example.com make an SA"). > > >> What would be the point of using an ID payload if you didn't > >> care what was in it? > > VPNC> There isn't one. > > The parties involved are not the same. You guys keep flipping between >"VPN" and "two random parties" in your discussion. Sorry, but that's not true at all. I have consistently been talking about VPNs. (No surprise there.) In this thread, it seems like you're the one who is consistently speaking about "two random parties". (No surprise there, either.) As shown above, a VPN with certificates where the receiving party doesn't know or care about the specific identity of the sending party can still let the sending be part of a VPN on the receiving party's system. These are not random parties. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue May 20 09:05:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KG56AF042082; Tue, 20 May 2003 09:05:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16344 Tue, 20 May 2003 11:28:14 -0400 (EDT) Message-Id: <200305201126.HAA06290@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-ikev2-algorithms-00.txt Date: Tue, 20 May 2003 07:26:54 -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 : Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-00.txt Pages : 6 Date : 2003-5-19 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ikev2-algorithms-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-ikev2-algorithms-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: <2003-5-19142112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-algorithms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19142112.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue May 20 10:10:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KHAdAF047916; Tue, 20 May 2003 10:10:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16790 Tue, 20 May 2003 12:24:21 -0400 (EDT) Message-ID: <20030520162948.74320.qmail@web11507.mail.yahoo.com> Date: Tue, 20 May 2003 09:29:48 -0700 (PDT) From: Feng Ye Subject: Re: IPSec Implementation To: Ipsec Cc: George Hadjichristofi In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hey George, I was doing the same thing a while ago, I looked into Kame, and briefly went through the code, seems the Kame is ok to understand, anyway they are all based on the standard (I mean, the IKE part). I think there're some difference between the open source implementations: 1.FreeS/wan: they do not support those they think are unsecure, like single DES, DH group 1, agressive mode, etc. Besides, freeswan is not used in VPNC testing. 2.openbsd (isakmpd): they have hardware support (like Hifn chips), they do not support multiple ESP/AH headers as required by an iterated VPN cloud. Model IPsec tunnel as pseudo interfaces. 3.kame (racoon): do not model IPsec tunnel as pseudo interfaces (maybe a good thing). Does not implement byte lifetime for both phase 1 and phase 2. As for the documentation, Kame has some documents in Japanese. The best way still is to go over the code, I think the open source documentation is not sufficient enough. As for the modification, I only looked into Kame, which is based on PF_KEY socket implementation, so if your system is socket based it should be easier. I am still very interested in this, if you have any result, can you let me know? Regards, Feng Ye --- George Hadjichristofi wrote: > Hi, > > I have a question related to the different > implementations of IPSec. > > I am currently looking into the FreeBSD, FreeSWAN > Linux, and the one that > comes with the new version of linux. > > Does anyone know the basic differences between these > implementations? > > Which one has the best documentation? > Which one is "easiest" to understand and modify? > > Thank you, > > George > > > > > ************************************************* > George C. Hadjichristofi > Graduate Student,Computer Engineering Department > Virginia Tech,Blacksburg,VA 24061,U.S.A > TEL:(540)-951-8936 > ************************************************* > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From owner-ipsec@lists.tislabs.com Tue May 20 10:46:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KHkGAF050823; Tue, 20 May 2003 10:46:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17149 Tue, 20 May 2003 13:13:21 -0400 (EDT) Message-ID: <3ECA65EA.8000500@creeksidenet.com> Date: Tue, 20 May 2003 13:29:14 -0400 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: v7 nits Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As long as we are still stuck in the bogs of identity usage, a couple of points of v7 clarification would be also appreciated: Text on protocol for notifications states: For notifications concerning IPsec SAs this field will contain either (2) to indicate AH or (3) to indicate ESP. For notifications for which no protocol ID is relevant, this field MUST be sent as zero and MUST be ignored. What about "no prop chosen" for child props that include both AH and ESP? What about "ipcomp supported" requests with both AH and ESP props? I would claim that protocol ID is not relevant, but the sentence above says I still need a "2" or "3". Also, what SPI in these cases? For "nat detection source/dest ip" notifies, text says to hash SPIs, address and port. Which spis are to be used and in which order? Jeff From owner-ipsec@lists.tislabs.com Tue May 20 11:26:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KIQlAF051989; Tue, 20 May 2003 11:26:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17344 Tue, 20 May 2003 13:44:01 -0400 (EDT) Message-Id: <200305201749.h4KHnPgb004768@sandelman.ottawa.on.ca> To: "George Hadjichristofi" cc: "Ipsec" Subject: Re: IPSec Implementation In-reply-to: Your message of "Tue, 20 May 2003 00:31:54 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 13:49:25 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "George" == George Hadjichristofi writes: George> I have a question related to the different implementations of George> IPSec. George> I am currently looking into the FreeBSD, FreeSWAN Linux, and the George> one that George> comes with the new version of linux. Best documented would be FreeS/WAN. Easiest to modify for someone who has never looked at the code, might be *BSD. I'd say that the NetBSD 1.6 code is probably the easiest to understand, because it is the least efficient - i.e. most poorly optimized!! That will change very soon, I think. Easiest to test with would be FreeS/WAN, because it has "make check" that runs about 100 test cases using User-Mode-Linux. I have (intentionally) never looked at the Linux 2.5 code, so I can not comment. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPspqo4qHRg3pndX9AQEaFgP8CaTJoH7jGhr1XBOUnMi2Og4hfUg54nTq HI1i2288T4R/pGfQi8XgbT8ywkNw+l3tf6z6WEIG3m4v5IakdirE7RQYXYxzdGnS U6LwniMTAFpsDUdnKKFzKX4aSh+yjuWPmAq0q+6Bw2x/EBDi32AMJnTivDB6C92V cixTdwo8saI= =3Kl1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue May 20 11:28:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KISiAF052052; Tue, 20 May 2003 11:28:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17479 Tue, 20 May 2003 13:59:32 -0400 (EDT) Date: Tue, 20 May 2003 11:04:53 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: State of IPSec NAT Traversal drafts? From: Joshua Graessley To: Ipsec Content-Transfer-Encoding: 7bit Message-Id: <8E63FBDC-8AED-11D7-908D-000A959D832C@apple.com> X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What is the state of the IPSec NAT traversal drafts? The following two drafts contain very useful modifications to IKE and a very useful method of encapsulating IPSec so it will pass through NATs. I haven't seen any discussion of these drafts in quite some time. Is there a reason? We need a solution now and don't have time to wait for IKEv2. These drafts seem to fill that solution except that vendor id specified in the ike draft is incomplete until the draft becomes an RFC. That makes creating interoperable implementations impossible. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt Thanks, -josh From owner-ipsec@lists.tislabs.com Tue May 20 12:33:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KJXuAF054082; Tue, 20 May 2003 12:33:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17834 Tue, 20 May 2003 14:55:54 -0400 (EDT) Message-Id: <200305201901.h4KJ1I5p006442@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Tue, 20 May 2003 08:19:31 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 15:01:17 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "VPNC" == VPNC writes: VPNC> At 11:19 PM -0400 5/18/03, Michael Richardson wrote: VPNC> You could have a security policy that ignored the identity in the VPNC> cert ("allow an SA with these restrictions to anyone who has a cert VPNC> from XYZRoot"), or one that was identity-based ("let VPNC> chris@example.com make an SA"). >> >> >> What would be the point of using an ID payload if you didn't >> >> care what was in it? >> VPNC> There isn't one. >> >> The parties involved are not the same. You guys keep flipping between >> "VPN" and "two random parties" in your discussion. VPNC> Sorry, but that's not true at all. I have consistently been talking VPNC> about VPNs. (No surprise there.) In this thread, it seems like VPNC> you're I've barely commented :-) What I do hear is that the VPN has to work for two parties who have picked random CAs, and can't control what goes into the certificate. That sure sounds like "rwo random parties" to me. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue May 20 13:04:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KK4kAF055911; Tue, 20 May 2003 13:04:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18014 Tue, 20 May 2003 15:35:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200305201901.h4KJ1I5p006442@sandelman.ottawa.on.ca> References: <200305201901.h4KJ1I5p006442@sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 20 May 2003 15:40:31 -0400 To: Michael Richardson , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Confirm decision on identity handling. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:01 PM -0400 5/20/03, Michael Richardson wrote: > What I do hear is that the VPN has to work for two parties who have >picked random CAs, and can't control what goes into the certificate. That >sure sounds like "rwo random parties" to me. We hear differently. No one creating a VPN (as compared to opportunistic encryption) can pick random CAs. For VPNs, there is a shared trusted CA. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue May 20 14:19:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KLJjAF059847; Tue, 20 May 2003 14:19:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18362 Tue, 20 May 2003 16:42:53 -0400 (EDT) Message-Id: <200305202048.h4KKmHam009030@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Tue, 20 May 2003 15:40:31 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 16:48:16 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "VPNC" == VPNC writes: VPNC> At 3:01 PM -0400 5/20/03, Michael Richardson wrote: >> What I do hear is that the VPN has to work for two parties who have >> picked random CAs, and can't control what goes into the >> certificate. That sure sounds like "rwo random parties" to me. VPNC> We hear differently. No one creating a VPN (as compared to VPNC> opportunistic encryption) can pick random CAs. For VPNs, there is a VPNC> shared trusted CA. So, why is there a problem with telling the CA what needs to go into the certificate? ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue May 20 16:33:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KNXpAF063681; Tue, 20 May 2003 16:33:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18986 Tue, 20 May 2003 19:00:27 -0400 (EDT) Message-ID: <3ECAB4B1.8000006@parc.com> Date: Tue, 20 May 2003 16:05:21 PDT From: "D. K. Smetters" Organization: PARC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <200305202048.h4KKmHam009030@sandelman.ottawa.on.ca> In-Reply-To: <200305202048.h4KKmHam009030@sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: >>>>>>"VPNC" == VPNC writes: > > VPNC> At 3:01 PM -0400 5/20/03, Michael Richardson wrote: > >> What I do hear is that the VPN has to work for two parties who have > >> picked random CAs, and can't control what goes into the > >> certificate. That sure sounds like "rwo random parties" to me. > > VPNC> We hear differently. No one creating a VPN (as compared to > VPNC> opportunistic encryption) can pick random CAs. For VPNs, there is a > VPNC> shared trusted CA > > So, why is there a problem with telling the CA what needs to go into the > certificate? > You might not control the CA you are using. Even if you do, you might have some constraints on what goes in the certificate imposed by some other piece of (frequently broken) software that you also use that certificate with. Or what you put in the certificates to work with your previous VPN software might not work with your shiny new VPN software, and you might not want to reissue all your certs that still have a certain amount of time left on them. Or you might not want to put ugly things into your current certificates to cope with the vagaries of the software you currently use with them, in the hopes you'll be able to get better software later. (Horror stories deleted in the interests of space.) --Diana ==================================== D. K. Smetters Member of the Research Staff Palo Alto Research Center From owner-ipsec@lists.tislabs.com Tue May 20 17:03:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4L03lAF064378; Tue, 20 May 2003 17:03:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19151 Tue, 20 May 2003 19:33:44 -0400 (EDT) Message-Id: <200305202338.h4KNcwmT012912@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. In-reply-to: Your message of "Tue, 20 May 2003 16:05:21 PDT." <3ECAB4B1.8000006@parc.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 19:38:57 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "D" == D K Smetters writes: VPNC> At 3:01 PM -0400 5/20/03, Michael Richardson wrote: >> >> What I do hear is that the VPN has to work for two parties who have >> >> picked random CAs, and can't control what goes into the >> >> certificate. That sure sounds like "rwo random parties" to me. >> VPNC> We hear differently. No one creating a VPN (as compared to VPNC> opportunistic encryption) can pick random CAs. For VPNs, there is a VPNC> shared trusted CA >> >> So, why is there a problem with telling the CA what needs to go into the >> certificate? D> You might not control the CA you are using. Even if you do, you might have D> some constraints on what goes in the certificate imposed by some other piece of D> (frequently broken) software that you also use that certificate with. Okay, so we have to do silly things with IKE*v2* so that a piece of software, installed in only one place, for which there are multiple commercial and open-source implementations does not have to be replaced. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsq8kIqHRg3pndX9AQH4gQQAquzlxZuTB1vTrfKTtqzRTPlPgdFGevJC Hv8KVjFiK1iMi0qlGr0XtE/Z/YVQa8AxnT0oYnCNu5QU9ZKtxoXsmxvEfNgmYuEk wHfF58ThC720MwNWTbCafnlNSizdy1mvGN2LJelHfxcGJPx7B55YWoiQZK7jRPMq k1ddDWlalZ4= =unIN -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue May 20 21:55:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4L4t0AF073259; Tue, 20 May 2003 21:55:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20559 Wed, 21 May 2003 00:17:30 -0400 (EDT) From: "George Hadjichristofi" To: "Michael Richardson" Cc: "Ipsec" Subject: RE: IPSec Implementation Date: Wed, 21 May 2003 00:22:20 -0400 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.2910.0) In-reply-to: <200305201749.h4KHnPgb004768@sandelman.ottawa.on.ca> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Michael, Which implementation has the best documentation? Which one is the "easiest" to understand and modify? Thank you, George ************************************************* George C. Hadjichristofi Graduate Student Bradley Department of Electrical and Computer Engineering Virginia Tech,Blacksburg,VA 24061,U.S.A TEL:(540)-951-8936 ************************************************* -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Tuesday, May 20, 2003 1:49 PM To: George Hadjichristofi Cc: Ipsec Subject: Re: IPSec Implementation -----BEGIN PGP SIGNED MESSAGE----- >>>>> "George" == George Hadjichristofi writes: George> I have a question related to the different implementations of George> IPSec. George> I am currently looking into the FreeBSD, FreeSWAN Linux, and the George> one that George> comes with the new version of linux. Best documented would be FreeS/WAN. Easiest to modify for someone who has never looked at the code, might be *BSD. I'd say that the NetBSD 1.6 code is probably the easiest to understand, because it is the least efficient - i.e. most poorly optimized!! That will change very soon, I think. Easiest to test with would be FreeS/WAN, because it has "make check" that runs about 100 test cases using User-Mode-Linux. I have (intentionally) never looked at the Linux 2.5 code, so I can not comment. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPspqo4qHRg3pndX9AQEaFgP8CaTJoH7jGhr1XBOUnMi2Og4hfUg54nTq HI1i2288T4R/pGfQi8XgbT8ywkNw+l3tf6z6WEIG3m4v5IakdirE7RQYXYxzdGnS U6LwniMTAFpsDUdnKKFzKX4aSh+yjuWPmAq0q+6Bw2x/EBDi32AMJnTivDB6C92V cixTdwo8saI= =3Kl1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue May 20 21:55:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4L4t2AF073269; Tue, 20 May 2003 21:55:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20585 Wed, 21 May 2003 00:20:30 -0400 (EDT) From: "George Hadjichristofi" To: "Michael Richardson" Cc: "Ipsec" Subject: RE: IPSec Implementation Date: Wed, 21 May 2003 00:25:19 -0400 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.2910.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please disregard the previous email. I got confused :-) Thank you, George ************************************************* George C. Hadjichristofi Graduate Student Bradley Department of Electrical and Computer Engineering Virginia Tech,Blacksburg,VA 24061,U.S.A TEL:(540)-951-8936 ************************************************* -----Original Message----- From: George Hadjichristofi [mailto:ghadjich@vt.edu] Sent: Wednesday, May 21, 2003 12:22 AM To: Michael Richardson Cc: Ipsec Subject: RE: IPSec Implementation Hi Michael, Which implementation has the best documentation? Which one is the "easiest" to understand and modify? Thank you, George ************************************************* George C. Hadjichristofi Graduate Student Bradley Department of Electrical and Computer Engineering Virginia Tech,Blacksburg,VA 24061,U.S.A TEL:(540)-951-8936 ************************************************* -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Tuesday, May 20, 2003 1:49 PM To: George Hadjichristofi Cc: Ipsec Subject: Re: IPSec Implementation -----BEGIN PGP SIGNED MESSAGE----- >>>>> "George" == George Hadjichristofi writes: George> I have a question related to the different implementations of George> IPSec. George> I am currently looking into the FreeBSD, FreeSWAN Linux, and the George> one that George> comes with the new version of linux. Best documented would be FreeS/WAN. Easiest to modify for someone who has never looked at the code, might be *BSD. I'd say that the NetBSD 1.6 code is probably the easiest to understand, because it is the least efficient - i.e. most poorly optimized!! That will change very soon, I think. Easiest to test with would be FreeS/WAN, because it has "make check" that runs about 100 test cases using User-Mode-Linux. I have (intentionally) never looked at the Linux 2.5 code, so I can not comment. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPspqo4qHRg3pndX9AQEaFgP8CaTJoH7jGhr1XBOUnMi2Og4hfUg54nTq HI1i2288T4R/pGfQi8XgbT8ywkNw+l3tf6z6WEIG3m4v5IakdirE7RQYXYxzdGnS U6LwniMTAFpsDUdnKKFzKX4aSh+yjuWPmAq0q+6Bw2x/EBDi32AMJnTivDB6C92V cixTdwo8saI= =3Kl1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed May 21 19:36:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4M2aHAF066030; Wed, 21 May 2003 19:36:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28893 Wed, 21 May 2003 21:50:01 -0400 (EDT) Message-ID: <3ECC2DFC.3000101@parc.com> Date: Wed, 21 May 2003 18:55:08 PDT From: "D. K. Smetters" Organization: PARC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: Confirm decision on identity handling. References: <200305202338.h4KNcwmT012912@sandelman.ottawa.on.ca> In-Reply-To: <200305202338.h4KNcwmT012912@sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: >>>>>>"D" == D K Smetters writes: > > VPNC> At 3:01 PM -0400 5/20/03, Michael Richardson wrote: > >> >> What I do hear is that the VPN has to work for two parties who have > >> >> picked random CAs, and can't control what goes into the > >> >> certificate. That sure sounds like "rwo random parties" to me. > >> > VPNC> We hear differently. No one creating a VPN (as compared to > VPNC> opportunistic encryption) can pick random CAs. For VPNs, there is a > VPNC> shared trusted CA > >> > >> So, why is there a problem with telling the CA what needs to go into the > >> certificate? > > D> You might not control the CA you are using. Even if you do, you might have > D> some constraints on what goes in the certificate imposed by some other piece of > D> (frequently broken) software that you also use that certificate with. > > Okay, so we have to do silly things with IKE*v2* so that a piece of > software, installed in only one place, for which there are multiple > commercial and open-source implementations does not have to be replaced. I don't see that "leave the final decision about whether the ID has to exactly match something in the certificate up to local policy" would be a horrible option for IKEv2 (or better, making such a match a suggested, but not required option). It still lets correct software continue doing exactly what it's doing now, it just makes things a little more flexible to allow people to handle situations they might not have forseen when they issued their certs. There are good arguments for both sides of this question (which have already appeared in this thread), but to rephrase a bit the argument for allowing a flexible mapping: Certificates are fairly long-lived objects, and whether they ought to be or not, they can be difficult to issue, or reissue if wrong (if nothing else, you have to touch all the clients). And once they're issued, they can't be altered. This means that the decisions I made for what to put into my certificates can have long-lasting repercussions, and may have to survive several changes of underlying software. And even though there are pieces of software out there that do handle certificates correctly, there are even more that make incorrect assumptions about what certificates look like, that put constraints on what certificates you can use -- it's not just one piece of software installed in one place, unfortunately. (e.g. I'd love to have a quarter for every piece of software that assumes a cert can contain only one subjectAltName.). And often people have a wide variety of constraints controlling their choice of software, well beyond its certificate handling capabilities -- they may be stuck with some piece of silly code for very good reasons. (Not to mention the fact that you may not find out the particular ways a piece of cert-handling code is broken until you've already gone fairly far along in dealing with it.) What seems to happen in practice is that facing these choices, they prefer to give up certificates than to give up the software that won't work with them. --D From tangelonk1tl3s3jpa@msn.com Wed May 21 22:09:25 2003 Received: from hotmail.com (bay3-dav85.bay3.hotmail.com [65.54.169.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4M59PAF070293 for ; Wed, 21 May 2003 22:09:25 -0700 (PDT) (envelope-from tangelonk1tl3s3jpa@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 May 2003 22:09:23 -0700 Received: from 204.191.80.98 by bay3-dav85.bay3.hotmail.com with DAV; Thu, 22 May 2003 05:09:23 +0000 X-Originating-IP: [204.191.80.98] X-Originating-Email: [tangelonk1tl3s3jpa@msn.com] To: "Schnabl Giarratano" Subject: Work Out Your Debt Troubles From: "Perez Decinti" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: KMail [version 1.2] Organization: w77R1676sg6w0v5Dnln070l X-Accept-Language: en Content-Type: multipart/alternative; boundary="kbme6p118EaI1T826041Y5kKFf0iL05i2P2G48CEslRCY62Y8H8We567kDI65kxQo842u211" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 22 May 2003 05:09:23.0770 (UTC) FILETIME=[4F4881A0:01C32020] Date: 21 May 2003 22:09:23 -0700 --kbme6p118EaI1T826041Y5kKFf0iL05i2P2G48CEslRCY62Y8H8We567kDI65kxQo842u211 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="US-ASCII"
Is Your Debt Out of Control?
Reduce your monthly payments by consolidating your Debt!

Get A Free Debt Consultation Right Here

Pay your debts off with one monthly payment!
Save hundreds of dollars by eliminating high interest bills!

Get Started Right Now And Remember It's FREE


To be Taken Off click here
--kbme6p118EaI1T826041Y5kKFf0iL05i2P2G48CEslRCY62Y8H8We567kDI65kxQo842u211-- From owner-ipsec@lists.tislabs.com Fri May 23 09:11:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NGBfAF027707; Fri, 23 May 2003 09:11:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11685 Fri, 23 May 2003 11:27:52 -0400 (EDT) Message-Id: <5.2.0.9.2.20030523111709.03b2ea70@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 23 May 2003 11:33:13 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: draft-ietf-ipsec-ikev2-algorithms-00.txt In-Reply-To: <200305201126.HAA06290@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am glad to see that this draft was finally posted, but it does not reflect my recollection of the working group consensus prior to the San Francisco IETF meeting. I am very pleaded to see SHOULD+, SHOULD-, and MUST-. These provide important guidance to product planners. In section 4.1.1 on IKEv2 Encrypted Payload Algorithms, I expected: MUST Three-key Triple-DES in CBC mode SHOULD+ 128-bit AES in CBC mode In section 4.1.2, I expected no mention of elliptic curves. The working group abandoned work in this area many months ago. Also, I expected: MUST 1024 SHOULD 1536 SHOULD+ 2048 In section 4.1.3 on IKEv2 Transfer Type 1 Algorithms, I expected two of the entries to have different requirements: MUST ENCR_3DES (assuming that this is 3-key 3DES in CBC mode) SHOULD+ ENCR_AES_128_CBC In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two of the entries to have different requirements: MAY PRF_HMAC_MD5 SHOULD PRF_AES128_CBC I also thought that we were going to define a shorthand way to configure different devices to use the same selections from the a la carte menu. At a minimum, we should come up with a name for the collection of MUST algorithms. Do others have different recollections and expectiations? Russ From owner-ipsec@lists.tislabs.com Fri May 23 12:53:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NJrHAF040991; Fri, 23 May 2003 12:53:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12818 Fri, 23 May 2003 15:23:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <003201c31d1f$b825c2e0$292e1dc2@YnirNew> References: <003201c31d1f$b825c2e0$292e1dc2@YnirNew> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 23 May 2003 05:35:31 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: How will we specify AES key lengths? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:27 AM +0200 5/18/03, Yoav Nir wrote: >Sorry I didn't ask about this earlier. With some vendors already offering >AES with larger keys (192- and 256-bit), why aren't there numbers assigned >for these transforms (section 2.1) Thank you for highlighting a problem that the WG doesn't seem to have noticed before now. The WG needs to decide how to specify the key length for AES. We now have WG documents that do this in two different ways: with the Key Length attribute in IKEv1 and IKEv2, or with a different identifier for each of the three key lengths. draft-ietf-ipsec-ciph-aes-cbc-05.txt for AES in CBC mode says: 5.3 Key Length Attribute Since the AES allows variable key lengths, the Key Length attribute MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 exchange [DOI]. draft-ietf-ipsec-ciph-aes-ctr-03.txt for AES in CTR mode says: 9. IANA Considerations IANA has assigned three ESP transform numbers for use with AES-CTR with an explicit IV, one for each AES key size: for AES-CTR with a 128 bit key; for AES-CTR with a 192 bit key; and for AES-CTR with a 256 bit key. I propose that the WG standardize on one method. Given that there are a fair number of deployed implementations of draft-ietf-ipsec-ciph-aes-cbc but few or none of draft-ietf-ipsec-ciph-aes-ctr, it seems like draft-ietf-ipsec-ciph-aes-ctr should be changed to use the method that has already been deployed. Thoughts? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun May 25 23:01:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4Q61ZAF018153; Sun, 25 May 2003 23:01:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26255 Mon, 26 May 2003 01:14:21 -0400 (EDT) Message-Id: <5.2.0.9.2.20030526011908.030d09c0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 26 May 2003 01:19:52 -0400 To: Charlie_Kaufman@notesdev.ibm.com From: Russ Housley Subject: Re: IKEv2-07 Comment on Signature Usage Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.2.20030509171300.038cf0e8@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie: Your proposed action resolves my concern. Russ > > IKEv2-07 says: > > > > Optionally, messages 3 and 4 MAY include a certificate, or > > certificate chain providing evidence that the key used to compute a > > digital signature belongs to the name in the ID payload. The > > signature or MAC will be computed using algorithms dictated by the > > type of key used by the signer, an RSA-signed PKCS1-padded-hash for > > an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital > > ... > > > > Unfortunately, this does not really work. Consider a certificate with an > > > RSA public key. The subject public key info contains the rsaEncryption > > algorithm identifier. This public key can be used to validate signatures > > > generated with PKCS #1 version 1.5 or PSS. And, each of these signature > > algorithms can be used with many different one-way hash functions. > > > > A signature value needs to be coupled with an algorithm identifier. > > > > Russ > > >I agree. There is a one byte field in the AUTH payload called Auth Method >that could be used to specify the algorithm. Currently, it has three >defined values: 1=RSA signature formatted using PKCS#1; 2=PRF computed >using the shared key; and 3=DSS signature currently specified as "using a >DSS private key over a SHA-1 hash" (I believe the DSS signature standard >(unlike RSA) specifies the padding and the use of a SHA-1 hash). > >If I changed the wording of the text you quoted to list those as examples >rather than mandates with a pointer to section 3.8, and changed section 3.8 >to specify that in the future new codes could be assigned to existing key >types, would that satisfy your concern? > >Related issues: should these algorithms be listed in the algorithms spec >instead of or in addition to this one, and should we define a code for PSS >signatures now or should it wait? (And is there an RFC to reference?). > > --Charlie From owner-ipsec@lists.tislabs.com Sun May 25 23:03:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4Q63dAF018739; Sun, 25 May 2003 23:03:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26417 Mon, 26 May 2003 01:36:16 -0400 (EDT) Date: Mon, 26 May 2003 14:43:10 +0900 From: Kazunori Miyazawa To: ipsec@lists.tislabs.com Subject: About representation of IPv6 address in Traffic Selector in IKEv2 Message-Id: <20030526144310.74c9329f.kazunori@miyazawa.org> X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I'm Miyazawa a member of USAGI Project. I read draft-ietf-ipsec-ikev2-07.txt and I have a question about representation of Traffic Selector for IPv6. The question is Why don't we use subnet prefix to represent Traffic Selector of IPv6? Does anyone know the reason? Of course we can specify a subnet with address range. I think however it is useful to represent IPv6 Traffic Selector with subnet prefix because it suits IPv6 address architecture and IPv6 equipments use it. IMHO we should add TS_IPV6_ADDRESS_PREFIX to TS type and its specification into section 3.13.1. # Please notice me if there was discussion of this in the past. Thank you, --Kazunori Miyazawa (Yokogawa Electric Corporation) From owner-ipsec@lists.tislabs.com Mon May 26 16:12:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4QNC7AF091937; Mon, 26 May 2003 16:12:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01601 Mon, 26 May 2003 18:42:07 -0400 (EDT) Message-Id: <200305262247.h4QMle0p030267@sandelman.ottawa.on.ca> To: Kazunori Miyazawa cc: ipsec@lists.tislabs.com Subject: Re: About representation of IPv6 address in Traffic Selector in IKEv2 In-reply-to: Your message of "Mon, 26 May 2003 14:43:10 +0900." <20030526144310.74c9329f.kazunori@miyazawa.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 26 May 2003 18:47:39 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Kazunori" == Kazunori Miyazawa writes: Kazunori> The question is Kazunori> Why don't we use subnet prefix to represent Traffic Selector of Kazunori> IPv6? Kazunori> Does anyone know the reason? Because ranges are more general than prefixes, and we only want to have one way to encode a given TS. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPtKZioqHRg3pndX9AQESsQP+LgMhzEH1YD1TGh+bTyJfDfJQqjrttcGb mQCShMPMgJirV5RAErYqIEWIJL+WhYFQZ39EnO0q/oT0f/BKQKJbr7Gv1DOVulme irNWOukdOp6PReZooqRpq0jYJBNfqv5D4MPJ5zmcVtMOoZ6NJ83Vko3qwJCJsN1u qzhI+uKPa6k= =+/a9 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue May 27 05:04:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RC4bAF049254; Tue, 27 May 2003 05:04:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05463 Tue, 27 May 2003 07:31:57 -0400 (EDT) From: "Laurent GARCES" To: Subject: IPSEC implementation to do... Date: Tue, 27 May 2003 13:37:28 +0200 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm student in last year of computer science and I have to develop an IPSEC implementation for my final project. I know it's a really hard task but I will do what I can... I read the RFC 2401, 2402, 2406... parts of KAME code, and all the mail on this mailing list wich can interest me for now, but I still have question about the IPSEC architecture ie SAD/SPD. They are essentially due to the differences between that I 've undertsand from the RFC and that I've understand from the KAME code. So, how does the relation between SAD end SPD entries must be done? ie how the SA(s) on wich SPDs entries will point (RFC 2401 5.1.1 1.) are found? Reading the RFC I was thinking that each SAD entry have its own selector but It doesn't work like that in KAME. From owner-ipsec@lists.tislabs.com Tue May 27 06:49:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RDn9AF055192; Tue, 27 May 2003 06:49:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05996 Tue, 27 May 2003 09:20:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 May 2003 18:45:48 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: LAST CALL: ESP and AH ESN drafts Cc: tytso@mit.edu, byfraser@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_364919486==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_364919486==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed This is a working group last call for comments on the following drafts, for progression to Proposed Standard: draft-ietf-ipsec-esp-v3-05.txt draft-ietf-ipsec-rfc2402bis-03.txt draft-ietf-ipsec-esn-addendum-01.txt These drafts have not received a great amount of attention so Ted and I would like to urge everyone to take a good look at them. We are extending the working group last call to 3 weeks to give folks adequate time to comment. This last call will expire on June 16. thanks, Barb and Ted --=====================_364919486==_.ALT Content-Type: text/html; charset="us-ascii" This is a working group last call for comments on the following drafts, for progression to Proposed Standard:

draft-ietf-ipsec-esp-v3-05.txt
draft-ietf-ipsec-rfc2402bis-03.txt
draft-ietf-ipsec-esn-addendum-01.txt

These drafts have not received a great amount of attention so Ted and I would like to urge everyone to take a good look at them. We are extending the working group last call to 3 weeks to give folks adequate time to comment. This last call will expire on June 16. 

thanks,
Barb and Ted --=====================_364919486==_.ALT-- From owner-ipsec@lists.tislabs.com Tue May 27 07:31:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4REVDAF056925; Tue, 27 May 2003 07:31:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06334 Tue, 27 May 2003 10:06:22 -0400 (EDT) Message-ID: <3ED36AAA.1030003@polito.it> Date: Tue, 27 May 2003 15:39:54 +0200 From: Corrado Derenale Reply-To: derenale@polito.it User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKE_SA SPI with a changed address Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, what would happen in IKEv2 if the Initiator and Responder change their IP adresses after have established an IKE_SA? It is still possible refernce the SAD with the SPI (the IKE_SA SPI) found in the CREATE_CHILS_SA header in order to retrieve the parametres to generate a new CHILD_SA? Thanks, /cdr From owner-ipsec@lists.tislabs.com Tue May 27 08:18:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RFIIAF062006; Tue, 27 May 2003 08:18:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06557 Tue, 27 May 2003 10:49:28 -0400 (EDT) From: "Laurent GARCES" To: Subject: IPSEC implementation to do... Date: Mon, 26 May 2003 09:34:27 +0200 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm student in last year of computer science and I have to develop an IPSEC implementation for my final project. I know it's a really hard task but I will do what I can... I read the RFC 2401, 2402, 2406... parts of KAME code, and all the mail on this mailing list wich can interest me for now, but I still have question about the IPSEC architecture ie SAD/SPD. They are essentially due to the differences between that I 've undertsand from the RFC and that I've understand from the KAME code. How the relation between SAD end SPD entries must be done? ie how the SA(s) on wich SPDs entries will point (RFC 2401 5.1.1 1.) are found? Reading the RFC I was thinking that each SAD entriy have its own selector but It doesn't work like that in KAME. From owner-ipsec@lists.tislabs.com Tue May 27 08:18:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RFIfAF062024; Tue, 27 May 2003 08:18:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06542 Tue, 27 May 2003 10:48:27 -0400 (EDT) Message-ID: <3ED36A6F.5010309@polito.it> Date: Tue, 27 May 2003 15:38:55 +0200 From: Corrado Derenale Reply-To: derenale@polito.it User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKE_SA SPI with a changed address Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070204050108010405010900" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms070204050108010405010900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, what would happen in IKEv2 if the Initiator and Responder change their IP adresses after have established an IKE_SA? It is still possible refernce the SAD with the SPI (the IKE_SA SPI) found in the CREATE_CHILS_SA header in order to retrieve the parametres to generate a new CHILD_SA? Thanks, /cdr --------------ms070204050108010405010900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV4zCC BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV 6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6 Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ 506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW 1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm 053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+ Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci 6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE +ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0 cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3 LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0 ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6 RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U 79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn CaPNvqphRz5KhJGOTJpc8CZ+UDCCBgkwggTxoAMCAQICAgEZMA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMjEw MzEwNzAwMDBaFw0wMzEyMzEwOTAwMDBaMHwxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh IGUgSW5mb3JtYXRpY2ExGjAYBgNVBAMTEUNvcnJhZG8gIERlcmVuYWxlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo9UqtuwtaPmMSHeee4DPi2fiRCbSUCG32jlAYeAqoXvx 3rBwfDWHoZvvSn73sYlHptbHdQpp/M0N1RkCSDQGMxSvzoXhy3GYrM63Oy/Tjpfe8R05gnVn 6Q4x9CGNr5Zm5RZWOp12KY2jCb9Q4+krFESFSgB6PUBr/WJnCM4NotvhrYBsdjl1Jaww0A9Y Dyc70Igw9ZqEJ1n5iK3EA8kcv3HyA+NkANXZbz0nCuPkcCw/ixvbGmne09TFTDxwZeXAZtS5 FthofBMk6XOfKE5kgv+6qSUGOh9/myZ3xIS0smbI3BlFqlCawfRrK6YbNjGJRDY7t9hqcrFf Vw1GcwiPowIDAQABo4ICqjCCAqYwgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0 cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA1BgNVHREELjAsgRJkZXJlbmFs ZUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYwMDQzMTcwgc0GA1UdIASBxTCBwjBDBgor BgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9v dC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsGAQUFBwIBFhxo dHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUfv1U IDpaQBgx9HOFgy8jgA6oWikwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmPLzeghMUwDQYJ KoZIhvcNAQEFBQADggEBAMe3Au36OVIuXcODCOye1r9cPdvyy7DzQuGqJEP3JPt06c+WEMzH mtJK2rb879X03wOsHxP4QyQxhiplQUkpw/9nx895PHZhOGm7gagpDuIu9UeFC6Pxn64i0iQV phyxUYtY0veDDLXngYbZpgTuD96ljonB1hRlZqopndrY3J/lIk5zqEei31Di5SslYhT2jsEw bQ+vhNtdo7+1Jpzj/movT5zvkD6gdBuwQqHG6oaLaoPECYOpvN8UW0Xy7J1mX/S3+G86HF2R 4xhNzl2LOnnsXhLPkOwucZVzy/G7c764T9OAdnB5djgd/u9afP11wkHjVIOxu8DFlF9oiRGf lx4wggYJMIIE8aADAgECAgIBGTANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJJVDEeMBwG A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMDMxMDcwMDAwWhcNMDMxMjMx MDkwMDAwWjB8MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5v MTEwLwYDVQQLEyhEaXBhcnRpbWVudG8gZGkgQXV0b21hdGljYSBlIEluZm9ybWF0aWNhMRow GAYDVQQDExFDb3JyYWRvICBEZXJlbmFsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKPVKrbsLWj5jEh3nnuAz4tn4kQm0lAht9o5QGHgKqF78d6wcHw1h6Gb70p+97GJR6bW x3UKafzNDdUZAkg0BjMUr86F4ctxmKzOtzsv046X3vEdOYJ1Z+kOMfQhja+WZuUWVjqddimN owm/UOPpKxREhUoAej1Aa/1iZwjODaLb4a2AbHY5dSWsMNAPWA8nO9CIMPWahCdZ+YitxAPJ HL9x8gPjZADV2W89Jwrj5HAsP4sb2xpp3tPUxUw8cGXlwGbUuRbYaHwTJOlznyhOZIL/uqkl Bjoff5smd8SEtLJmyNwZRapQmsH0ayumGzYxiUQ2O7fYanKxX1cNRnMIj6MCAwEAAaOCAqow ggKmMIGVBglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8v d3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5v cmcvY2EvaXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZI AYb4QgEBBAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3Au ZXVyb3BraS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9j YS9pdC8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwu ZGVyMAwGA1UdEwEB/wQCMAAwNQYDVR0RBC4wLIESZGVyZW5hbGVAcG9saXRvLml0oBYGCisG AQQBlWICAQGgCBYGMDA0MzE3MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMGCCsG AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw cy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0by5p dC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFH79VCA6WkAYMfRzhYMvI4AOqFop MB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IBAQDH twLt+jlSLl3Dgwjsnta/XD3b8suw80LhqiRD9yT7dOnPlhDMx5rSStq2/O/V9N8DrB8T+EMk MYYqZUFJKcP/Z8fPeTx2YThpu4GoKQ7iLvVHhQuj8Z+uItIkFaYcsVGLWNL3gwy154GG2aYE 7g/epY6JwdYUZWaqKZ3a2Nyf5SJOc6hHot9Q4uUrJWIU9o7BMG0Pr4TbXaO/tSac4/5qL0+c 75A+oHQbsEKhxuqGi2qDxAmDqbzfFFtF8uydZl/0t/hvOhxdkeMYTc5dizp57F4Sz5DsLnGV c8vxu3O+uE/TgHZweXY4Hf7vWnz9dcJB41SDsbvAxZRfaIkRn5ceMYICxTCCAsECAQEwazBl MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQD Ey1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgEZMAkG BSsOAwIaBQCgggEvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAzMDUyNzEzMzg1NVowIwYJKoZIhvcNAQkEMRYEFLRaXP4GiCuGNku07o9Qr0hwtI8lMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYD VQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xp dGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgEZMA0GCSqGSIb3 DQEBAQUABIIBAD8z/mR0J8bFwzEr+lEuMy2r8zMkUkCtKQk+phtGKhaCaszZMeatURdF9rl9 8oYqH9jtesXvFCE8/XKnJzd6pFfRsXOjxz211HeiCB/RiOXljeksZbbvxRt4x7srAbPuu8t2 k+uZ3kLsgSIxztanFQWKykzwOvf+hgNy6TlmRhvZ2MPoVNNXP83H+ivtHpD6QnK/EH9eKLBF nLfomu7XtewOapix28tolVqH10YF/F+YYzo/mA6q6FzN/D1xGnoqp+LiwTD6MC19dhttagrP 0zVtpXCPp53mh1pLgV1jteA9d/I+QTGG9l3cvktFror0v/vRmGL65g/I7zbal7su3B0AAAAA AAA= --------------ms070204050108010405010900-- From owner-ipsec@lists.tislabs.com Tue May 27 09:12:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4RGCeAF064140; Tue, 27 May 2003 09:12:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06883 Tue, 27 May 2003 11:42:43 -0400 (EDT) Message-Id: <200305271547.h4RFlnof044936@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: derenale@polito.it cc: ipsec@lists.tislabs.com Subject: Re: IKE_SA SPI with a changed address In-reply-to: Your message of Tue, 27 May 2003 15:39:54 +0200. <3ED36AAA.1030003@polito.it> Date: Tue, 27 May 2003 17:47:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: what would happen in IKEv2 if the Initiator and Responder change their IP adresses after have established an IKE_SA? => nothing very good: - NAT traversal includes an optional automatic peer address update for all SAs for a peer which is detected to be behind a NAT. - responses are required to be sent with source/destination address/port reversed, so received requests will be correctly answered. - without an explicit peer address update mechanism (there is a WG agreement to study such a thing in the close future) the best is just to rekey the IKE_SA. It is still possible refernce the SAD with the SPI (the IKE_SA SPI) => yes, this is the role of the SPI and any IKEv2 implementation which uses addresses to look up an IKE_SA should be nuked. found in the CREATE_CHILS_SA header in order to retrieve the parametres to generate a new CHILD_SA? => an IKE_SA rekey will use the addresses IKE runs over so this should work. BTW as the peer addresses are not protected in this case and some attacks can be built using this security flaw, it is possible a future draft will change this... For instance I interpret Jari and Tero's proposal as keeping the peer addresses seen in the first message where they are indirectly protected, note the proposal includes an explicit update mechanism too. Nothing is really decided, only my firm intention to raise a concern if nothing is done about peer address protection before the last call. Thanks Francis.Dupont@enst-bretagne.fr PS: read draft-dupont-transient-pseudonat-01.txt for an example of an attack based on the lack of protection, and RFC 3519 for a defense against a similar problem in Mobile IP which was never claimed to be a security protocol... From owner-ipsec@lists.tislabs.com Wed May 28 08:39:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SFd7AF050864; Wed, 28 May 2003 08:39:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13717 Wed, 28 May 2003 10:49:20 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16084.52590.695586.636858@ryijy.hel.fi.ssh.com> Date: Wed, 28 May 2003 17:53:34 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: New draft-ietf-ipsec-nat-t-ike-06 draft X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 9 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I updated the NAT-T draft (the old one was about to expire next week). The changes to old version are: - Updated references. - Changed some words in following paragraph ({+this is added text+} [-this was removed-]): ---------------------------------------------------------------------- If there is no NAT between then the first NAT-D payload {+received+} should match one of the local NAT-D [-packet-] {+payloads+} (i.e [-the-] local NAT-D payloads this host is sending out), and the one of the other NAT-D payloads must match the remote ends IP address and port. If the first check fails (i.e first NAT-D payload does not match any of the local IP addresses and ports), then it means that there is dynamic NAT between, and this end should start sending keepalives as defined in the [-[Hutt02].-] {+[Hutt03].+} ---------------------------------------------------------------------- - Replaced ---------------------------------------------------------------------- It is not normally useful to propose both normal tunnel or transport mode and UDP-Encapsulated modes. If there is a NAT box between normal tunnel or transport encapsulations may not work, and if there is no NAT box between, there is no point of wasting bandwidth by adding UDP encapsulation of packets. Because of this initiator SHOULD NOT include both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP- Encapsulated-Transport in its proposals. ---------------------------------------------------------------------- with this: ---------------------------------------------------------------------- It is not normally useful to propose both normal tunnel or transport mode and UDP-Encapsulated modes. If there is a NAT box between normal tunnel or transport encapsulations may not work and in that case UDP-Encapsulation SHOULD be used. If there is no NAT box between, there is no point of wasting bandwidth by adding UDP encapsulation of packets, thus UDP-Encapsulation SHOULD NOT be used. Also initiator SHOULD NOT include both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport in its proposals. ---------------------------------------------------------------------- I.e say clearly that if there is NAT between then NAT-T SHOULD be used and if no NAT is detected then NAT-T SHOULD NOT be used. The old text was not clear on this point. This document should now be finished (we only need to modify the VID when we know the RFC number). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed May 28 13:22:51 2003 Received: from lists.tislabs.com ([192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4SKMoAF065467; Wed, 28 May 2003 13:22:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15004 Wed, 28 May 2003 15:45:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20030528122947.04a11f00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 May 2003 12:47:06 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: crypto algorithm documents for IKEv2 Cc: tytso@mit.edu, byfraser@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi folks, Over the past few weeks we've seen two similar drafts submitted that describe the cryptographic algorithms for use in IKEv2. After discussions, we're going to keep draft-ietf-ipsec-ikev2-algorithms-00.txt as simply the set of algorithms (MUSTs, SHOULDs, and MAYs) and Paul has agreed to modify his document so that it focuses on the definition of a set of standard UI suites. These two documents together with the IKEv2 draft will form a cohesive group. Thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Thu May 29 01:20:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4T8KpAF010204; Thu, 29 May 2003 01:20:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18432 Thu, 29 May 2003 03:48:10 -0400 (EDT) Message-ID: <3ED59027.3080303@polito.it> Date: Thu, 29 May 2003 06:44:23 +0200 From: Corrado Derenale Reply-To: derenale@polito.it User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IKE_SA SPI with a changed address References: <200305271547.h4RFlnof044936@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Francis Dupont wrote: > In your previous mail you wrote: > > what would happen in IKEv2 if the Initiator and Responder change their > IP adresses after have established an IKE_SA? > > => nothing very good: > - NAT traversal includes an optional automatic peer address update > for all SAs for a peer which is detected to be behind a NAT. > - responses are required to be sent with source/destination address/port > reversed, so received requests will be correctly answered. > - without an explicit peer address update mechanism (there is a WG > agreement to study such a thing in the close future) the best is > just to rekey the IKE_SA. I was against the NAT yet before reading the draft-dupont-transient-pseudonat-01.txt but now, after that reading I'm even more against it! The problem was not for NAT traversal, I hope that with the IPv6 coming all that problems with NAT will vanish with the NAT itself, but with the mobile user. I was thinking about keep-up an IKE_SA even if one of the peers change his network access (change WLAN hot spot) end conseguently its IP address > > It is still possible refernce the SAD with the SPI (the IKE_SA SPI) > > => yes, this is the role of the SPI and any IKEv2 implementation > which uses addresses to look up an IKE_SA should be nuked. This sounds very good to me. > > found in the CREATE_CHILS_SA header in order to retrieve the parametres > to generate a new CHILD_SA? > > => an IKE_SA rekey will use the addresses IKE runs over so this should work. > BTW as the peer addresses are not protected in this case and some attacks > can be built using this security flaw, I think that you refer to some DoS attacks, because only the authenticated peers can negotiate a new CHILD_SA and derive new cryptographic material from the one negotiated and authenticated during the IKE_SA_INIT. Am I right? > it is possible a future draft > will change this... For instance I interpret Jari and Tero's proposal > as keeping the peer addresses seen in the first message where they are > indirectly protected, note the proposal includes an explicit update > mechanism too. That will be very usefull in the mobile/nomadic user scenario. > Nothing is really decided, only my firm intention to > raise a concern if nothing is done about peer address protection > before the last call. > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: read draft-dupont-transient-pseudonat-01.txt for an example > of an attack based on the lack of protection, and RFC 3519 for > a defense against a similar problem in Mobile IP which was never > claimed to be a security protocol... :) > Thank you, /cdr From owner-ipsec@lists.tislabs.com Fri May 30 07:28:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UESJAF030756; Fri, 30 May 2003 07:28:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26962 Fri, 30 May 2003 09:54:23 -0400 (EDT) Message-Id: <200305301115.HAA28456@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-06.txt Date: Fri, 30 May 2003 07:15:09 -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-06.txt Pages : 13 Date : 2003-5-29 This document describes how to detect one or more network address trans- lation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-06.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-06.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: <2003-5-29161759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-t-ike-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161759.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri May 30 07:28:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UESKAF030760; Fri, 30 May 2003 07:28:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26955 Fri, 30 May 2003 09:53:23 -0400 (EDT) Message-Id: <200305301114.HAA28418@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-dpd-03.txt Date: Fri, 30 May 2003 07:14:59 -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 : A Traffic-Based Method of Detecting Dead IKE Peers Author(s) : G. Huang, S. Beaulieu, D. Rochefort Filename : draft-ietf-ipsec-dpd-03.txt Pages : 11 Date : 2003-5-29 This draft describes a method of detecting a dead IKE peer. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to limit the number of IKE messages sent. DPD, like other keepalive mechanisms, is often necessary to perform IKE peer failover, or to reclaim lost resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dpd-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dpd-03.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-dpd-03.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: <2003-5-29161647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dpd-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dpd-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161647.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri May 30 07:28:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UESiAF030783; Fri, 30 May 2003 07:28:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26956 Fri, 30 May 2003 09:53:24 -0400 (EDT) Message-Id: <200305301115.HAA28435@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-ui-suites-00.txt Date: Fri, 30 May 2003 07:15:04 -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 : Cryptographic Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-00.txt Pages : 0 Date : 2003-5-29 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ui-suites-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-ui-suites-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: <2003-5-29161729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ui-suites-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ui-suites-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161729.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri May 30 07:31:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UEVBAF030841; Fri, 30 May 2003 07:31:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26928 Fri, 30 May 2003 09:47:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.2.20030523111709.03b2ea70@mail.binhost.com> References: <5.2.0.9.2.20030523111709.03b2ea70@mail.binhost.com> Date: Fri, 30 May 2003 09:46:45 -0400 To: Russ Housley From: Stephen Kent Subject: Re: draft-ietf-ipsec-ikev2-algorithms-00.txt Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:33 AM -0400 5/23/03, Russ Housley wrote: >I am glad to see that this draft was finally posted, but it does not >reflect my recollection of the working group consensus prior to the >San Francisco IETF meeting. > >I am very pleaded to see SHOULD+, SHOULD-, and MUST-. These provide >important guidance to product planners. > >In section 4.1.1 on IKEv2 Encrypted Payload Algorithms, I expected: > > MUST Three-key Triple-DES in CBC mode > SHOULD+ 128-bit AES in CBC mode > >In section 4.1.2, I expected no mention of elliptic curves. The >working group abandoned work in this area many months ago. Also, I >expected: > > MUST 1024 > SHOULD 1536 > SHOULD+ 2048 > >In section 4.1.3 on IKEv2 Transfer Type 1 Algorithms, I expected >two of the entries to have different requirements: > > MUST ENCR_3DES (assuming that this is 3-key 3DES >in CBC mode) > SHOULD+ ENCR_AES_128_CBC > >In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two >of the entries to have different requirements: > > MAY PRF_HMAC_MD5 > SHOULD PRF_AES128_CBC > >I also thought that we were going to define a shorthand way to >configure different devices to use the same selections from the a la >carte menu. At a minimum, we should come up with a name for the >collection of MUST algorithms. > >Do others have different recollections and expectiations? > >Russ Russ, Your comments above match my recollection of what was agreed upon and documented in earlier drafts by Paul. Steve From owner-ipsec@lists.tislabs.com Fri May 30 14:07:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UL71AF051896; Fri, 30 May 2003 14:07:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29030 Fri, 30 May 2003 16:36:07 -0400 (EDT) Message-Id: <200305302034.QAA26931@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipsec@lists.tislabs.com From: The IESG Subject: Protocol Action: The AES Cipher Algorithms and Their Use With IPsec to Proposed Standard Date: Fri, 30 May 2003 16:34:45 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved the Internet-Draft 'The AES Cipher Algorithm and Its Use With IPsec' as a Proposed Standard. This document is the product of the IP Security Working Group (IPSEC). The IESG contact persons are Russ Housley and Steven Bellovin. Technical Summary Since IPsec was first developed, the U.S. National Institute of Standards and Technology (NIST) has completed a process for selecting the new Advanced Encryption Standard (AES). AES uses longer keys than the original Data Encryption Standard (DES) that is used by IPsec for confidentiality. AES also uses a larger encryption block size. This document describes the use of the AES Cipher Algorithm in Cipher Block Chaining (CBC) mode as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP) protocol. Working Group Summary The Working Group came to consensus on this document. Protocol Quality This document was reviewed by Jeffrey I. Schiller for the IESG. From owner-ipsec@lists.tislabs.com Fri May 30 14:07:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UL76AF051908; Fri, 30 May 2003 14:07:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29016 Fri, 30 May 2003 16:33:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20030530080238.04becf00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 08:43:38 -0700 To: Russ Housley , smb@research.att.com From: Barbara Fraser Subject: NAT docs ready for IETF Last Call Cc: byfraser@cisco.com, tytso@mit.edu, ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_95597702==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_95597702==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The NAT Traversal docs went through wg last awhile back. With the latest revision of the nat-t document, these are all ready to be progressed: draft-ietf-ipsec-nat-t-ike-06.txt ready for IETF last call for proposed standard draft-ietf-ipsec-udp-encaps-06.txt is ready for IETF last call for proposed standard draft-ietf-ipsec-nat-reqts-04.txt: ready for IETF last call for informational rfc Thanks, Barb and Ted --=====================_95597702==_.ALT Content-Type: text/html; charset="us-ascii" The NAT Traversal docs went through wg last awhile back.  With the latest revision of the nat-t document, these are all ready to be progressed:

draft-ietf-ipsec-nat-t-ike-06.txt ready for IETF last call for proposed standard
draft-ietf-ipsec-udp-encaps-06.txt is ready for IETF last call for proposed standard
draft-ietf-ipsec-nat-reqts-04.txt: ready for IETF last call for informational rfc

Thanks,
Barb and Ted --=====================_95597702==_.ALT-- From owner-ipsec@lists.tislabs.com Fri May 30 14:08:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UL87AF051950; Fri, 30 May 2003 14:08:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29023 Fri, 30 May 2003 16:34:08 -0400 (EDT) Message-ID: <3ED7BFB3.5000205@mit.edu> Date: Fri, 30 May 2003 16:31:47 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Housley CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ikev2-algorithms-00.txt References: <5.2.0.9.2.20030523111709.03b2ea70@mail.binhost.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig704BBD2CA19EC9E20646A092" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig704BBD2CA19EC9E20646A092 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I just submitted a new version to the I-D Directory that I believe addresses these comments. -Jeff Russ Housley wrote: > I am glad to see that this draft was finally posted, but it does not > reflect my recollection of the working group consensus prior to the San > Francisco IETF meeting. > > I am very pleaded to see SHOULD+, SHOULD-, and MUST-. These provide > important guidance to product planners. > > In section 4.1.1 on IKEv2 Encrypted Payload Algorithms, I expected: > > MUST Three-key Triple-DES in CBC mode > SHOULD+ 128-bit AES in CBC mode > > In section 4.1.2, I expected no mention of elliptic curves. The working > group abandoned work in this area many months ago. Also, I expected: > > MUST 1024 > SHOULD 1536 > SHOULD+ 2048 > > In section 4.1.3 on IKEv2 Transfer Type 1 Algorithms, I expected two of > the entries to have different requirements: > > MUST ENCR_3DES (assuming that this is 3-key 3DES in CBC mode) > SHOULD+ ENCR_AES_128_CBC > > In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two of > the entries to have different requirements: > > MAY PRF_HMAC_MD5 > SHOULD PRF_AES128_CBC > > I also thought that we were going to define a shorthand way to configure > different devices to use the same selections from the a la carte menu. > At a minimum, we should come up with a name for the collection of MUST > algorithms. > > Do others have different recollections and expectiations? > > Russ > > > > --------------enig704BBD2CA19EC9E20646A092 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+17+68CBzV/QUlSsRAg0jAJ0d5br7RDgtJZLwqDdT4H80+ao5mgCgudyN Fx2ipx/kjPqhq8mqVQ/SD68= =aC0F -----END PGP SIGNATURE----- --------------enig704BBD2CA19EC9E20646A092-- From owner-ipsec@lists.tislabs.com Fri May 30 14:10:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4ULAeAF052069; Fri, 30 May 2003 14:10:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29017 Fri, 30 May 2003 16:33:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20030530091223.04aa1ed8@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 09:15:33 -0700 To: Stephen Kent From: Barbara Fraser Subject: Re: draft-ietf-ipsec-ikev2-algorithms-00.txt Cc: Russ Housley , ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.2.20030523111709.03b2ea70@mail.binhost.com> <5.2.0.9.2.20030523111709.03b2ea70@mail.binhost.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_95807824==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_95807824==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I agree. Jeff indicated in a conversation earlier this week that he is updating his draft accordingly. thanks, Barb At 06:46 AM 5/30/2003, Stephen Kent wrote: >At 11:33 AM -0400 5/23/03, Russ Housley wrote: >>I am glad to see that this draft was finally posted, but it does not >>reflect my recollection of the working group consensus prior to the San >>Francisco IETF meeting. >> >>I am very pleaded to see SHOULD+, SHOULD-, and MUST-. These provide >>important guidance to product planners. >> >>In section 4.1.1 on IKEv2 Encrypted Payload Algorithms, I expected: >> >> MUST Three-key Triple-DES in CBC mode >> SHOULD+ 128-bit AES in CBC mode >> >>In section 4.1.2, I expected no mention of elliptic curves. The working >>group abandoned work in this area many months ago. Also, I expected: >> >> MUST 1024 >> SHOULD 1536 >> SHOULD+ 2048 >> >>In section 4.1.3 on IKEv2 Transfer Type 1 Algorithms, I expected two of >>the entries to have different requirements: >> >> MUST ENCR_3DES (assuming that this is 3-key 3DES in >> CBC mode) >> SHOULD+ ENCR_AES_128_CBC >> >>In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two of >>the entries to have different requirements: >> >> MAY PRF_HMAC_MD5 >> SHOULD PRF_AES128_CBC >> >>I also thought that we were going to define a shorthand way to configure >>different devices to use the same selections from the a la carte >>menu. At a minimum, we should come up with a name for the collection of >>MUST algorithms. >> >>Do others have different recollections and expectiations? >> >>Russ > >Russ, > >Your comments above match my recollection of what was agreed upon and >documented in earlier drafts by Paul. > >Steve --=====================_95807824==_.ALT Content-Type: text/html; charset="us-ascii" I agree. Jeff indicated in a conversation earlier this week that he is updating his draft accordingly.

thanks,
Barb

At 06:46 AM 5/30/2003, Stephen Kent wrote:
At 11:33 AM -0400 5/23/03, Russ Housley wrote:
I am glad to see that this draft was finally posted, but it does not reflect my recollection of the working group consensus prior to the San Francisco IETF meeting.

I am very pleaded to see SHOULD+, SHOULD-, and MUST-.  These provide important guidance to product planners.

In section 4.1.1 on IKEv2 Encrypted Payload Algorithms, I expected:

        MUST            Three-key Triple-DES in CBC mode
        SHOULD+ 128-bit AES in CBC mode

In section 4.1.2, I expected no mention of elliptic curves.  The working group abandoned work in this area many months ago.  Also, I expected:

        MUST            1024
        SHOULD  1536
        SHOULD+ 2048

In section  4.1.3 on IKEv2 Transfer Type 1 Algorithms, I expected two of the entries to have different requirements:

        MUST            ENCR_3DES (assuming that this is 3-key 3DES in CBC mode)
        SHOULD+ ENCR_AES_128_CBC

In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two of the entries to have different requirements:

        MAY             PRF_HMAC_MD5
        SHOULD  PRF_AES128_CBC

I also thought that we were going to define a shorthand way to configure different devices to use the same selections from the a la carte menu.  At a minimum, we should come up with a name for the collection of MUST algorithms.

Do others have different recollections and expectiations?

Russ

Russ,

Your comments above match my recollection of what was agreed upon and documented in earlier drafts by Paul.

Steve
--=====================_95807824==_.ALT-- From owner-ipsec@lists.tislabs.com Sat May 31 15:36:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4VMaTAF050594; Sat, 31 May 2003 15:36:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02633 Sat, 31 May 2003 17:47:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20030531144540.02e34930@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 31 May 2003 14:49:16 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: New roles for Angelos and Tero Cc: tytso@mit.edu, byfraser@cisco.com, "Angelos D. Keromytis" , Tero Kivinen , Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, We're approaching the last mile in the working group (unbelievable, right?). To help us successfully meet the remaining objectives, we're going to take advantage of a couple of roles described in RFC 2418 and add both a secretary and a facilitator to our working group. When I think of all the issues and decisions that Ted and I have tried to manage over the past couple of years (and for the working group as a whole over many years), I wish we'd used these roles more. Well, better late than never :-) Secretary: Angelos Keromytis RFC 2418 says: "Taking minutes and editing working group documents often is performed by a specifically-designated participant or set of participants. In this role, the Secretary's job is to record WG decisions, rather than to perform basic specification." Angelos is going to run a ticket system that will keep track of wg decisions that we make going forward. Each issue with each document becomes a trouble ticket in the system. The system is used to track the issues and document their resolution. This system will provide a publicly visible record so it should prevent flip-flopping such as what happened with suites vs a la carte. As we progress IKEv2, it will get broader visibility from the IETF community and this tracking will be very important. We also have another piece of work, the update to RFC 2401, that we want to move through the process as smoothly as possible. And, of course, there are documents still in the pipeline for which issues might still be raised. Facilitator: Tero Kivinen RFC 2418 says: "When meetings tend to become distracted or divisive, it often is helpful to assign the task of "process management" to one participant. Their job is to oversee the nature, rather than the content, of participant interactions. That is, they attend to the style of the discussion and to the schedule of the agenda, rather than making direct technical contributions themselves." We don't intend to take this so literally that Tero is now unable to make technical contributions to the discussion. That would be a terrible mistake and loss for the working group. Rather, he will make additional postings with a facilitator hat on to keep the discussion on track. Tero's job will be to keep each thread on track, spawning new issues on separate threads as appropriate. Ted and I have, in the past, allowed discussions to continue on various topics in the spirit of free speech. But we recognize that sometimes these discussions are confusing to working group members, especially when they continue to focus on an issue for which a decision has been made. Assuming the mantel of facilitator, Tero will be more assertive in moving this sort of discussion to other venues. :-) Please join Ted and I in thanking Angelos and Tero for their willingness to take on these roles. Thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Sat May 31 18:44:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h511iNAF058235; Sat, 31 May 2003 18:44:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03238 Sat, 31 May 2003 21:15:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sat, 31 May 2003 18:21:07 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New IKEv2 draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie has posted a new version of the main IKEv2 document. A temporary version can be found at --Paul Hoffman, Director --VPN Consortium